topic Help: A workaround to not having non-interrupting event subprocesses? in Alfresco Archive

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

pitagoras — Thu, 21 Nov 2013 22:42:00 GMT

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 DELE

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

trademak — Fri, 22 Nov 2013 14:41:07 GMT

1) which pull request are you referring to?

Best regards,

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

pitagoras — Fri, 22 Nov 2013 16:08:06 GMT

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

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

pitagoras — Fri, 13 Dec 2013 19:15:04 GMT

up!

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

yourboogieman — Sat, 14 Dec 2013 19:51:59 GMT

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?

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

frederikherema1 — Mon, 16 Dec 2013 07:30:56 GMT

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