Feature request: Modularize the Process Instance Migration

[ingorichtsmeier]

Is your feature request related to a problem? Please describe.

In the future, users want to migrate a huge number of process instances from Camunda 7 to Camunda 8. Or migrate from other process engines to Camunda 8.

This topic should be discussed in this issue.

Describe the solution you'd like

• A clear separation between exporting active process instances to a structured file format.
• An interface to import active process instances into Camunda 8.
• An connection between exporter and importer.
• A pluggable exporter to read the process instances from other process engines.

Describe alternatives you've considered

nothing

Additional context

nothing

[ingorichtsmeier]

As the documented result of an in-person discussion with @ingorichtsmeier and @jonathanlukas, I added this pull request: #225.

It is expected to change and help us find the best APIs and data structure.

@pierre-yves-monnet, from the Slack discussion, I think that the example of the process instances JSON file is what you asked for: exampleProcessInstances.json.

I'm curious about your opinion. Please add your input here.

[pierre-yves-monnet]

The example looks great. I love the idea of having a clear Importer, then, it will be possible to inject data from any other sources.

Is this importer accept a JSON, or will it be a Java API like we already see?

We have to take into account two others migrations features:

• local variables
• multi instances

What about this JSON description for multi-instance:

"activities": [
        {
          "approveInvoice": {
            "type": "userTask",
            "name": "Approve Invoice"
          }
        },
        {
          "review": {
            "type": "userTask",
            "name": "Review",
            "executedInstances" : [2,5]
          }
        },
        {
          "review": {
            "type": "serviceTask",
            "name": "Send",
            "executedLoopCardinality" : 5
          }
        }
      ],

Assuming:

• The definition knows Review and Send are multi-instance task (actually, the definition know that Approved Invoice is a UserTask; do we need to put it in the JSON?

• What is important is to know which instances were already executed. When the instance is based on parallel, the executed instances have to be known when it's based on LoopCardinality, where we are in the loop.

We don't need to give the collection itself (it's on the process definition).

In Camunda 7, it isn't possible to define local variables per instance. The only local variable is the "elementVariable", which can be recalculated from the collection or the Loop.

[jonathanlukas]

I would like the multi-instance be a separate activity to be able to distinguish its data from the data that is inside the actual multi-instances:

"activities": [
  {
    "reviewInvoices": {
      "type": "multiInstance",
      "inputVariableName": "invoice",
      "completedInstanceVariableValues": [...]
      "instances": [
        {
         "type": "callActivity"
          "inputVariableValue": {...}
          "variables": {...}
        }
      ]
    }
  }
]

The same could apply for a loop multi-instance, there would be no completedInstanceVariableValue, but completedIndices and not inputVariableValue, but index.