Migrate running processes to Activiti

[dbmalkovsky]

We are currently tasked with migrating running workflow instances from our proprietary workflow engine to the Activiti engine. We are looking for additional insight and/or advice regarding this type of migration.

We only see two options to migrate running instances:

1. DB Migration – Create the state of a running process in the Activiti tables via JDBC/SQL.
2. Template Modification – Add events when converting our proprietary template to an Activiti/BPMN template which allows a process to be started at a particular task. This approach modifies the engine behavior slightly and is described in more detail here: https://github.com/camunda/camunda-consulting/tree/master/snippets/migrate-third-party-to-camunda

Does anyone have experience with either of these approaches? Would you recommend one approach over the other?

We've started off down the path of option 1 but we are running into the following issues:

1. Determining when to create an execution.
2. Determining how to set the ACT_ID_ column appropriately.

Based on a few simple examples (listed below):

1. <b>One Task</b>  This results in: 1 Execution with ACT_ID_ set to the started UserTask’s id.
2. <b>Two Parallel Tasks </b>
   • <b>Both tasks Started</b> This results in: 3 Executions. Root execution with ACT_ID_ set to the startEvent’s id. The Task executions with the ACT_ID_ set to the UserTask’s id.
   • <b>One task Started and one task Finished</b> This results in: 1 Execution with ACT_ID_ set to the started UserTask’s id.
3. <b>One Task In Subprocess</b>
   • <b>Two Parallel Tasks In Subprocess with both Started</b> This results in:  4 Executions. Root execution with ACT_ID_ set to NULL. Subprocess Execution with ACT_ID_ set to the startEvent’s id. The Task executions with the ACT_ID_ set to the UserTask’s id.
   • <b>Two Parallel Tasks In Subprocess with one Started and one Finished</b>  This results in   2 Executions. Root execution with ACT_ID_ set to NULL. Subprocess Execution with ACT_ID_ set to the started UserTask’s id.

So are questions for this approach are:

1. Are there some general rules that can be used to know when an execution should be created during migration?
2. Is there a general way to determine what the ACT_ID_ value should be for a particular execution based on the state of the process and/or the template? For the simple examples, it seems if there is only a single started task associated with a execution then the ACT_ID_ value should be set to the UserTask’s id. When there are multiple started tasks associated with an execution then the ACT_ID_ is associated to the startEvent’s id (maybe this changes if the process is more complex) and when there are no tasks associated with an execution (such as the root execution in example 3) then the ACT_ID_ is null. Is this correct? Will this behavior continue for more complex processes such as (nested subflows, gateways before a task, etc).

Thank you for any and all insight you can share with regards to our migration task.

[trademak]

Template modification would be the best approach with the current codebase to my opinion. Option 1 is really hard because you would need to duplicate the Engine logic in the database. But I expect that template modification is not something you would prefer. Would having an expression on a task to skip it if it evaluates to true help? I would be happy to work together and get that implemented in the Engine on a short notice.

Best regards,

[rhafner]

We are not against modifying the templates but it's unclear at this point that it would be less complex than duplicating the engine logic needed by Option 1.

I'm not sure I understand your idea for adding an expression on a task to skip tasks. Can you elaborate on it some more? Would the expression be used for both service tasks and user tasks? Are you thinking of a possible third option in which the migration process starts and drives the process instance to the required state?

Are there plans to change the current codebase sometime in the future which would make Option 1 easier? I noticed Camunda is considering moving away from the concept of an "Execution" to an "Activity Instance Model" in future versions which (from a quick look) sounds like it would make Option 1 more feasible.

http://blog.camunda.org/2013/06/introducing-activity-instance-model-to.html

[trademak]

What I mean is that we could an expression that would only evaluate to true when you start the process instance for migration with specific variable values. Then the Engine will skip the execution of the service task and user task logic and will proceed with the next activity as if it were a manual task. In this way it would be possible to migrate a process instance state to the Activiti Engine in an easy way.

We have plans to make the concept of executions a lot easier, but that will be work starting next year. The article you are referencing is already quite old, so it doesn't seem like there's much progress there either.

Best regards,

[rhafner]

Thanks for the explanation. I think the expression idea is worth evaluating on our end. Please proceed with a prototype of the concept. Once it is available I will evaluate some of our migration scenarios on it and see what kinds of issues we run up against. A few potential issues that come to mind immediately are the following:

1) Task Listeners - we might need the ability to disable them on skipped task as well.
2) Execution Listeners - we might need the ability to disable them until we reached the state desired.
2)  Exclusive Gateways - How do we determine the values needed to take the appropriate path of execution?

Any chance you can share the changes you are considering regarding the concept of an execution (publicly or privately)? In terms of migration I think we are very interested in the direction.

Rob 

[trademak]

Ok great. As I said in my previous post I'm happy to work on this together. It's not something I can prototype without input from your side. I would need to understand the use cases a bit better and see if it really fits with the expression approach. Task and execution listeners won't be an issue I think, we can include that in the skip logic. Exclusive gateways is interesting and one of the reasons I think we need to discuss this in a bit more details before I can start with a prototype. Shall we continue with sharing more details via email? I'll make sure this thread gets updated when necessary.

Best regards,

[rhafner]

Yes, let's take this offline and flush out the details. I'll send you an email. Thanks!