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
Tags
Find what you came for
We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.