nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Start Event Subscriptions for suspended process definitions

jakobtonn

In Activiti 5.16.4, the start events subscriptions for a process definition are not removed when the process definition is suspended, which makes it impossible to deploy another process definition using the same start event even if the definition originally using it is suspended. Is this done intentionally, or would it be possible to change this behavior to removing the start event subscriptions when suspending a process definition and only allow re-activation if no other active process definition is currently subscribed for the same start event?

Find more posts tagged with

Comments

deva

I am using activi rest with php. I can't able to get the start variables of the deployed process. Can you help me?

jbarrez

This is done intentionally … what would be the desired behaviour if it would be reactived?

jakobtonn

The reactivation would have to check if there is another subsription for the start message present, and either disallow the reactivation or register for the start event again.

My motivation was that deactivating process instances could provide an easy solution to a deployment problem we were experiencing. An example scenario was that we had 2 process definitions, named "1" and "2" for the example. Definition 1 uses a message "A" as start event and definition 2 a message "B". Now, we wanted to deploy a new set of process definitions, where now definition 1 uses message "B" to start, and definition 2 uses something else. If now definition 1 gets processed first during the deployment, deployment will fail, as the current state is that definition 2 starts on message B.
Of cause, this looks easily solvable for 2 process definitions, but as our application uses a set of 20-30 process definitions, manually figuring out a working deployment order is not going to work. Deleting deployments is also not an option, as we need the history.
We have currently implemented a solution that deactivates the old definitions and removes their subscriptions manually, the main intent behind creating this topic was to find out if keeping the subscriptions for deactivated process definitions was done intentionally, or if we should provide a pull request to change that behaviour.