09-28-2016 04:08 PM
12-12-2016 12:10 PM
Looking at your process diagram, i is modelled such that the process instance starts, then pauses until either a "pause" or "complete" signal is received (this is the event gateway). The only way the "resume" task can be reached is after a "pause" signal is received.
This is a somewhat confusing pattern since a user task (Resume in your case) is an implicit wait state so I'm not certain as to the purpose of the "Pause" event.
Either way, you can simply add a boundary catch event to your "Resume" task to act on the "Complete" signal.
You can have multiple signal listeners for any signal.
I have attached a simple sample process that demonstrates both inline and boundary catch events responding to the same throw event.

Hope this helps,
Greg
12-12-2016 12:10 PM
Looking at your process diagram, i is modelled such that the process instance starts, then pauses until either a "pause" or "complete" signal is received (this is the event gateway). The only way the "resume" task can be reached is after a "pause" signal is received.
This is a somewhat confusing pattern since a user task (Resume in your case) is an implicit wait state so I'm not certain as to the purpose of the "Pause" event.
Either way, you can simply add a boundary catch event to your "Resume" task to act on the "Complete" signal.
You can have multiple signal listeners for any signal.
I have attached a simple sample process that demonstrates both inline and boundary catch events responding to the same throw event.

Hope this helps,
Greg