I have version 1 of a process with a simple message intermediate catch event .
Because this event needs Timer boundary catch event I refactored it in version 2 of my process to a Receive task.
Now I have to migrate running process instances in production from version 1 to version 2 of my process.
Tokens on message intermediate catch event should be migrated to receive task but I analyzed that this is not possible because it is an other type of activity ( task vs. event).
What is the correct way to do such kind of migration, because in my opinion both elements have the same semantic.
instead of a receive task with boundary timer event, you may use an event-based gateway which is connected to a timer event and the existing message event.
Does this help you?
thanks for your reply.
Yes you are right, this is a modeling alternative which is valid.
I would prefer to use the Receive Task but if there is no possibility to migrate it I will refactor model to your solution.
I think when I do your refactoring I have to migrate the message intermediate catch events from process version 1 to the event based gateway of process version 2.
I think this will also not be possible or am I wrong?
good point. I think you reached the current limits of the process instance migration. Maybe you can use process instance modification before and/or afterwards to “repair” the migrated process instance.
In case that anyone stumbles upon this thread, I would like to show our solution for this issue.
We had basically the same challenge: Tokens on a Message Intermediate Catch Event which should now have a preceding Event Based Gateway.
The event and the event based gateway are not compatible (IntermediateCatchEventActivityBehavior is not compatible with EventBasedGatewayActivityBehavior), so we used a temporary migration to reach the final model. We added another Message Intermediate Catch Event (let’s call it “Migration”) preceding the new event gateway. Now we moved the token from the old event (let’s call it “My-Event”) to the migration event:
runtimeService.createMigrationPlan( ... )
.mapActivities( "My-Event", "Migration" ).updateEventTrigger( )
After this migration we correlated all process instances which would remain on the new “Migration” event:
.createMessageCorrelation( "Message_Migration" )
Afterwards all token which were previously on “My-Event” were now on the event gateway. Now we performed another migration to the final model without the temporary migration event.