Workflow process instance migration

Absrtact: version 6.5 of Flowable provides the migration API for process instances. Developers can migrate process instances under the specified version to the latest version. This article focuses on the use of these APIs of Flowable and the comparison of Camunda workflow engine process instance migration function.

Process migration API description

The process migration API service class can be obtained through the process engine class, as follows:

 processMigrationService = processEngine.getProcessMigrationService();

Note: this feature is only available for Flowable6.5 and above.
The following API s can be used through processMigrationService:

 ProcessInstanceMigrationBuilder createProcessInstanceMigrationBuilder();

    ProcessInstanceMigrationBuilder createProcessInstanceMigrationBuilderFromProcessInstanceMigrationDocument(ProcessInstanceMigrationDocument document);

    ProcessInstanceMigrationValidationResult validateMigrationForProcessInstance(String processInstanceId, ProcessInstanceMigrationDocument processInstanceMigrationDocument);

    ProcessInstanceMigrationValidationResult validateMigrationForProcessInstancesOfProcessDefinition(String processDefinitionId, ProcessInstanceMigrationDocument processInstanceMigrationDocument);

    ProcessInstanceMigrationValidationResult validateMigrationForProcessInstancesOfProcessDefinition(String processDefinitionKey, int processDefinitionVersion, String processDefinitionTenantId, ProcessInstanceMigrationDocument processInstanceMigrationDocument);

    void migrateProcessInstance(String processInstanceId, ProcessInstanceMigrationDocument processInstanceMigrationDocument);

    void migrateProcessInstancesOfProcessDefinition(String processDefinitionId, ProcessInstanceMigrationDocument processInstanceMigrationDocument);

    void migrateProcessInstancesOfProcessDefinition(String processDefinitionKey, int processDefinitionVersion, String processDefinitionTenantId, ProcessInstanceMigrationDocument processInstanceMigrationDocument);

    Batch batchMigrateProcessInstancesOfProcessDefinition(String processDefinitionId, ProcessInstanceMigrationDocument processInstanceMigrationDocument);

    Batch batchMigrateProcessInstancesOfProcessDefinition(String processDefinitionKey, int processDefinitionVersion, String processDefinitionTenantId, ProcessInstanceMigrationDocument processInstanceMigrationDocument);

    ProcessInstanceBatchMigrationResult getResultsOfBatchProcessInstanceMigration(String migrationBatchId);

The above series of API s can be summarized as follows:

  • Create a migration plan (ProcessInstanceMigrationBuilder), in which a series of migration logic can be set, such as migrating the instance below that version to a specific version of the template
  • validateXX verifies that the migration logic can be executed.
  • The method at the beginning of migrateprocessistance synchronizes the execution of the migration plan. After calling the API, the engine immediately starts the migration work.
  • Starting with batchMigrateXX, batch migration instance. When you need to migrate many instances, you can use batch processing. This operation needs to turn on the timer, otherwise it will not take effect.
  • getResultsOfBatchProcessInstanceMigration: get the execution result of the batch.

Process migration API usage

Next, take two versions of the process as an example to explain the process instance migration function:
Version 1 Flowchart:

<process id="a2" name="2" isExecutable="true">
    <documentation>2</documentation>
    <startEvent id="startEvent1" flowable:formFieldValidation="true"></startEvent>
    <userTask id="sid-A8596132-C632-4DB0-81D6-5603D6516F3C" name="1" flowable:formFieldValidation="true"></userTask>
    <sequenceFlow id="sid-980E4499-6E2A-480E-B7F9-E8FD07914D49" sourceRef="startEvent1" targetRef="sid-A8596132-C632-4DB0-81D6-5603D6516F3C"></sequenceFlow>
    <endEvent id="sid-9203A5B1-FED5-429A-8039-0089AE3132A8"></endEvent>

Version 2 process:

 <startEvent id="startEvent1" flowable:formFieldValidation="true"></startEvent>
    <userTask id="sid-A8596132-C632-4DB0-81D6-5603D6516F3C" name="1" flowable:formFieldValidation="true"></userTask>
    <sequenceFlow id="sid-980E4499-6E2A-480E-B7F9-E8FD07914D49" sourceRef="startEvent1" targetRef="sid-A8596132-C632-4DB0-81D6-5603D6516F3C"></sequenceFlow>
    <userTask id="sid-84BBB613-FB20-430B-B4C1-E60F4DA02CFB" name="2" flowable:formFieldValidation="true"></userTask>
    <sequenceFlow id="sid-89B1A448-65D7-4222-B666-541DAB61BC01" sourceRef="sid-A8596132-C632-4DB0-81D6-5603D6516F3C" targetRef="sid-84BBB613-FB20-430B-B4C1-E60F4DA02CFB"></sequenceFlow>
    <endEvent id="sid-3101266D-CB58-4A8B-A3B1-B880F3C1D936"></endEvent>

The version 2 process has one more task node than the version 1 process, and the other elements are the same.

The demonstration video can be referred to video:

Deployment version 1 process

The operation is as follows:

 /**
     * 1
     */
    @Test
    public  void  deploy(){
        ProcessEngine processEngine = ProcessEngines.getDefaultProcessEngine();
        System.out.println(processEngine);
        RepositoryService repositoryService = processEngine.getRepositoryService();
       //taskWithEventProcess.bpmn20.xml
        repositoryService
            .createDeployment()
            .addClasspathResource("processMigrationService/2.1.bpmn20.xml")
            .deploy();
       runtimeService.startProcessInstanceByKey("a2");

    }

After the process is deployed in the above code, a new instance is started immediately. The current instance is on node 1.

Instance migration

Next, start to deploy the 2 process and realize the migration of 1 node to 2 node with version 2. The code is as follows:

 @Test
    public  void  batchMigrateProcessInstancesOfProcessDefinition2(){
        String processDefinitionKey="a2";
        int processDefinitionVersion=1;
        String processDefinitionTenantId="";
        ProcessInstanceMigrationDocumentImpl
            processInstanceMigrationDocument =new ProcessInstanceMigrationDocumentImpl();
        processInstanceMigrationDocument.setMigrateToProcessDefinition(processDefinitionKey,2);
        List<ActivityMigrationMapping> activityMigrationMappings = new ArrayList<ActivityMigrationMapping>();
        ActivityMigrationMapping.OneToOneMapping mappingFor = ActivityMigrationMapping.createMappingFor("sid-A8596132-C632-4DB0-81D6-5603D6516F3C", "sid-84BBB613-FB20-430B-B4C1-E60F4DA02CFB");
        activityMigrationMappings.add(mappingFor);
        processInstanceMigrationDocument.setActivityMigrationMappings(activityMigrationMappings);
        processMigrationService
            .migrateProcessInstance("12505",processInstanceMigrationDocument);

    }

Explanation and reference of the above API video:

Process migration Flowable VS Camunda workflow

  1. Compared with Camunda, the migration function of Flowable process instance is more weak and single. Some functions may be related to the commercial version, so the open source functions are relatively single. Not as powerful as Camunda.
  2. The Flowable process instance migration function is not perfect for the query. It does not have a lot of query logic and is not convenient for users to operate according to specific scenarios.
  3. For the batch module, it is not as powerful as Camunda. Because the open source version of Flowable only supports batch migration of instances, and does not support other batch operations.
  4. After the open source version of flowable mass migrates instances, the original historical data will be deleted, and Camunda will not delete the historical data. Therefore, when using this function in Flowable, you must be careful to prevent the historical data from being cleared. The entire full instance tree trace is not preserved.
  5. The open source version of flowable can migrate any data. Camunda will compare the migrated source node with the target node. If it is not in a range, migration is not allowed. Flowable is not strictly controlled.
  6. Camunda supports setting asynchronous or synchronous execution during migration. Flowable does not support it.
  7. Camunda supports setting whether to delete the original instance data information during migration. Flowable does not support it.
  8. Camunda supports setting whether node listener logic can be triggered during migration. Flowable does not.
  9. Both support developers to set thresholds and rates for batch processing tasks.

Posterior language

The official API doc document has been launched. At present, there is no Chinese version. Small partners who want to localize with Chinese can enter qq group: 1023773998
Technical team support: Pangu BPM workflow platform

196 original articles published, 574 praised, 1.72 million visitors+
His message board follow

Tags: xml

Posted on Sun, 02 Feb 2020 07:33:28 -0500 by vince81