Help: A workaround to not having non-interrupting event subprocesses?

[pitagoras]

Hi.
I do know: "Activiti only supports interrupting Event Sub-Processes."

unfortunately I have the need for non-interrupting event sub-processes. In this diagram:

[img]http://snag.gy/fYOMM.jpg[/img]

IF the task 1 is active, when a message is sent to activate a subprocess, the task 1 is deleted. The DELETE_REASON_ in act_hi_taskinst is:
"Event subprocess triggered using activity test_message_start_2tasks"

Now, for my problem I can see some possible solutions:

1) Use the patch that someone put somewhere in github as a pull request, and build my own sources and have non-interrupting subprocesses in experimental state.
2) Separate the subrpcess in other proecesses. But then they won´t share the businesskey.
3) Rewrite the subprocesses as somethig else to use available features.

So my question is: has anyone faced this situation, and how did you solve it.

[trademak]

1) which pull request are you referring to?

Best regards,

[pitagoras]

Hello Tijs
http://jira.codehaus.org/browse/ACT-1478
Mentioned in this thread http://forums.activiti.org/content/current-limitations-event-sub-process

[pitagoras]

up!

[yourboogieman]

What does "up!" mean?  I too have need for the non-interrupting event subprocess functionality.  I saw that someone created an experimental implementation of this, but I can't ascertain how far that ever got.  Are there plans to put this into an upcoming release some time soon?

[frederikherema1]

We are indeed looking into adding the "non-interupting" part to the 5.15 release. But no 100% guarantee that it will get in, though.

Never tested this, but for a current workaround, you could have a subprocess wrapping your original process (not including the event-subprocesses). You can throw the events as normal, from within the process and have a NON-INTERUPTING boundary event that catches those events and re-fires them as an intermediate throw event. Since the boundary-event handling is non-interuptive, it will have it's own scope which will be destroyed when the event-subprocess starts interrupting, without affecting the original executing process. It's a long shot, so don't take my words for truth, just looking for a temporal workaround