[feature][converter/cli]: defaultJobTypeEnabled as flag

[jonathanlukas]

Description

Currently, the converter assumes that the adapter is used afterwards to execute the service tasks being implemented with gateways before.

This new feature allows to not automatically define a job type.

Additional context

closes #264

Testing your changes

There are tests in place that assert the positive and negative flag behaviour

Types of changes

• Bug fix (non-breaking change which fixes an existing open issue)
• New feature (non-breaking change which adds functionality to an extension)
• Breaking change (fix or feature that would cause existing functionality of an extension to change)
• Documentation update (changes made to an existing piece of documentation)

Checklist:

• My code adheres to the syntax used by this extension.
• My pull request requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the Camunda Community Hub documentation.
• I have read the Pull Request Process documentation.
• I have added or suggested tests to cover my changes suggested in this pull request.
• All new and existing CI/CD tests passed.
• I will /assign myself this issue, and add the relevant [issue labels] to it if they are not automatically generated by Probot.
• I will tag @camunda-community-hub/devrel in a new comment on this issue if 30 days have passed since my pull request was opened and I have not received a response from the extension's maintainer.

[github-actions]

Test Results

  26 files  +  26    26 suites  +26   2m 15s ⏱️ + 2m 15s
214 tests +214  214 ✔️ +214  0 💤 ±0  0 ❌ ±0 
332 runs  +332  332 ✔️ +332  0 💤 ±0  0 ❌ ±0 

Results for commit de0b88d. ± Comparison against base commit a7c9159.

♻️ This comment has been updated with latest results.

[ingorichtsmeier]

Hi @jonathanlukas and @ManuelDittmar, as this change leaves the task type empty, the process model requires rework depending on the amount of service tasks before you can deploy it to the Zeebe engine.

It's no problem for the test model with a single task. But in case you have 20 or more service tasks, it's a tedious task to fill all task types.

My suggestions: use the --adapter-job-type as a default task type. Or provide a neutral default name logging.

As a developer it is easier to start the migration at the beginning of your process and move from task to task, create the worker for the next task, deploy and test the process.

What do you think?

[ManuelDittmar]

Hi @ingorichtsmeier,

I agree, maybe it's better if the diagram can be deployed easily. Should not make a difference if one needs to replace a job type or provide a value for an empty job type.

My main motivation for the FR was to not only allow the adapter implementation as a migration option (currently you would need to remove the header for each service task).

I would vote for the neutral default name, as using the --adapter-job-type would lead to "camunda-7-adapter" as a default value.

If defining your custom job type, the command would look confusing:

java -Dfile.encoding=UTF-8 -jar backend-diagram-converter-cli.jar local --adapter-job-type my-job-type --disable-adapter

[jonathanlukas]

@ManuelDittmar actually the stated command would not add any job type.

The logic is:

• configure nothing:adapter is applied
• configure adapter-job-type: the custom adapter job type is applied
• configure disable-adapter: no job type is applied

Is there a documentation gap we should close?

[ManuelDittmar]

@jonathanlukas I was referring to @ingorichtsmeier s comment about no job type vs. using --adapter-job-type as a default task type. Or provide a neutral default name logging. And not to your implementation.

based on ingos comment I understood the scenario "configure disable-adapter: no job type is applied" is not ideal, because you cannot deploy the diagram. So he would like to see the scenario

"configure disable-adapter: --adapter-job-type as a default task type /neutral job type is applied"

If the job type should not be empty, I think it would be better to have a neutral job type instead of using the --adapter-job-type

[jonathanlukas]

I see.

Sorry, this was not clear.

I would suggest to just rename the parameter adapter-job-type to default-job-type and remove the second flag.

wdyt @ingorichtsmeier @ManuelDittmar ?

[ingorichtsmeier]

Sounds much better than the first approach.

And to clarify: --default-job-type=logging will remove the original Camunda 7 service task implementation from the generated process diagram?

[jonathanlukas]

Great that we are aligned now.

But still, it would add a header that contains the implementation details of the C7 service task

[jonathanlukas]

@ManuelDittmar @ingorichtsmeier I added a commit that would change the names of the flags:
--default-job-type to use another job type than the adapter
--disable-default-job-type to not provide a job type AT ALL.

I think the first flag will help to understand what happens here. I think the problem was that the understanding of the term adapter job type is not clear to everybody, so default job type will suit better.

Also, I thought about the second flag and remembered a customer conversion from last year. I presented to them the converter and the adapter and they said they would like to refactor their code, so there was no need for them to have a job type in place at all.

Also, when using External Tasks or C7 Connectors, these flags will have no effect.