4 Replies Latest reply on Apr 4, 2013 10:32 AM by Anonymous User Anonymous User

    Terminate end event in subprocess must not terminate parent process?

    Ted Pan Newbie



      from the issue


      it says that Terminate end event in subprocess must not terminate parent process.

      the following is copied from the issue, in case someone could not access the issue tracker.

          According to the spec a terminate node in the subprocess aborts the execution in the subprocess. "Then the process continues on the normal flow" out of the subprocess [Bruce Silver, BPMN Method & Style, p. 82]

      The spec says:

      Sub-process level end events

      For a "terminate" End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Sub-Process, only the affected instance is terminated—no other ongoing Sub-Process instances or higher-level Sub-Process or Process instances are affected.



      but from document http://docs.jboss.org/jbpm/v5.4/userguide/ch.core-basics.html#d0e1529

        Note that, if you use a terminating event node inside a sub-process, you are terminating the top-level process instance, not just that sub-process.



      in my case, a subprocess will signal an event to parent process, then goes to a terminating node. in parent process, there is a Catching Signal Event to catch the event, then go to other node.


      when running same code in different machines,

      one faster machine always works as what I want. the process go to the Catching Signal Event.


      On the other slower machine, there is always an exception thrown out in the backend log

      Gateway:104] -- XOR split could not find at least one valid outgoing connection for split Gateway

      ( the content of this exception is not important, as my understanding, the process is still going on after the subprocess).



      So my question is that which one is correct? and why the behavior is different?





      (I'm using jPBM5.4 and I have tried setting the "Independent" to false, but there is no difference)