Hi everyone, I am struggling to change a parallel multi-instance subprocess into a parallel multi-instance called activity using a REST api call to execute migration after deployment.
Everything else stays the same, I only changed the parallel multi-instance subprocess into a parallel multi-instance call activity, all the activities inside the subprocess are now in the process definition called by the call activity.
All the activites will keep the same id.
Activities like Timer intermediate catch event should continue the timer without interrupting.
All the variables from each subprocess should also be moved into the corresponding called activity.
I am stuck at creating the migration plan inside the code:
Hey @Karlo - are you getting a specific error when you try and run the migration? I have some direct experience of trying to migrate away from an event gateway which led to an understanding that the migration capabilities are quite limited with respect to migrating activities to other types - I think you will get an error something like …
“Activities have incompatible types etc”
(this comes from this migration validator: SameBehaviorInstructionValidator in the engine code)
If that is the case then you will need to rethink. My advice is experiment with migrating the simplest possible model you can for each of the requirements to understand what can be done and what cannot.
The migration docs do cover some of the other things you mention such as events.
Not an answer as such, but hopefully somewhat helpful.
I get different errors depending if I use the ID of the activities with or without the #multiInstanceBody part of the ID, or both.
With #multiInstanceBody:
Migration instruction MigrationInstructionImpl{sourceActivityId='subprocessID#multiInstanceBody', targetActivityId='callActivityID#multiInstanceBody', updateEventTrigger='false'} is not valid:
Must map the inner activity of a multi-instance body when the body is mapped
Cannot remove the inner activity of a multi-instance body when the body is mapped
With no #multiInstanceBody:
Migration instruction MigrationInstructionImpl{sourceActivityId='subprocessID', targetActivityId='callActivityID', updateEventTrigger='false'} is not valid:
Activities have incompatible types (SubProcessActivityBehavior is not compatible with CallActivityBehavior)
Target activity 'callActivityID' is a descendant of multi-instance body 'callActivityID#multiInstanceBody' that is not mapped from the source process definition.
With both, using instruction .mapActivities with #multiInstanceBody before the one without it:
Migration instruction MigrationInstructionImpl{sourceActivityId='subprocessID', targetActivityId='callActivityID', updateEventTrigger='false'} is not valid:
Activities have incompatible types (SubProcessActivityBehavior is not compatible with CallActivityBehavior)
As I see it it’s not possible to do it this way… the solution could be to cancel activities, swap subprocess with call activity, then restart before call activity.
The multiple instance subprocess consists of business, service, user tasks, it uses a process variable of type ArrayList of Objects to generate separate subprocess instances. It has some input variables from the object it’s created from.
The goal is to migrate existing process instances which are currently inside the subprocess to use a multiple instance Call Activity instead. The called activity would be a BPMN process instance exactly the same as what’s inside the subprocess and same inputs.
Hey @Karlo, I don’t think this is easily achievable without some heavy modification and migration gymnastics or some bespoke migration code manipulating the underlying Camunda data.
Migrating from an flight embedded sub-process to a call activity (a separate, related process instance) isn’t supported as I understand it. A multi-instance embedded sub-process to multi-instance call-activity migration is obviously more complex than that.
Could you sidestep the problem by not migrating your instances that are waiting in the sub-process and let them complete naturally? You can provide a query on a process migration request to sub-select from all instances of a particular deployment of your process. Use this query capability to migrate your “easy” instances to your new version and leave the rest that are waiting in the sub-process. New instances of your process start with your new version (with the call activity instead of embedded sub-process).
The only other idea would be to modify your process instances in the sub-process to a new wait state before the sub-process. Then migrate to your new version and release the waiting instances. This would rely on the activities of the sub-process/call-activity being idempotent.