The following applies:
There are two process definitions “A” and “B” deployed in the process engine in a productional environment. Process definition “A” has a message start event. Process definition “B” has no message start event. Both process definitions are deployed and a lot of running and finished process instances exists in the engine.
After the next development cylce both process definitions are changed. Now the message start event from process definition “A” is moved to process definition “B”. Process definition “A” has no longer a message start event.
During deployment we receive the error “Cannot deploy process definition … There already is a message event subscription for the message …”.
The only way to get a clean deployment is, at first to execute the following SQL query: delete FROM ACT_RU_EVENT_SUBSCR avs WHERE avs.PROC_INST_ID_ IS NULL;
This query removes the registration of all message start events. Is there another way to do the deployment and to avoid using of SQL?
The problem happens because there is still a definition deployed with the message name associated to the start event. If the message happens, how can the engine know which definition to use to start a process? Messages are targeted towards a single process instance. To be able to trigger multiple instances with an event, a signal must be used. But this is not the case, because as you described, you don’t want the definition A to be triggered when B is deployed.
It is not possible to keep multiple definitions with the same message as the start event trigger since that would break the BPMN spec. If you still need the A definition, B must reference a different message. If you don’t need A definition anymore, you can try to delete the deployment with an API call.
Summarizing: BPMN has its own rules and “moving” message references from one definition to another is not a supported concept. If you want more flexibility in the way you trigger processes, cases, etc., I’d recommend to explore the Event Registry engine components.
In any case, it’s not a good idea to execute destructive SQL queries against the database.
Hi Jorge,
thank you for your answer. I have two questions:
If I do delete the old deployment, what’s happen with the running process instances using process definitions of this deployment.
Is it a good idea to delete a deployment in a production environment? What is the effect on the traceability regarding to historical process instances. The customer has high demands on the transparency and traceability of all processes.