Exception flow in Receive Message Event

The receive message event if waiting for an email to take the process flow is a blocking statement.
Meaning, the process waits for the receive message event node to executed once it is activated and it can only execute once a message is received.
However, there is no exception flow associated with the receive message event like a timer or a condition after which the message is no longer required or an alternative flow is desired.
Anyone effective way to achieve this?

OriginalPostID-258544

  Discussion posts and replies are publicly visible

  • I thought of following:
    1. Have an AND gate before the receive message event and to its parallel have a timer event.
    2. Then set a xor to merge both receive message event and timer event to read a value which tells that either receive message executed or timer event executed then go to end event else go forward.
    3. Set in the next node that either receive message or timer event has been executed.

    Any other solutions?
  • I had a similar issue with a timer node not having a way to effectively cancel it once started. I came up with 2 solutions: 1) put the timer node in a subprocess and have the exception/time out occur on the whole subprocess 2) set a process variable with a time in the node before the timer. After the timer node executes have a XOR that checks the pv variable to see if the current node is > than it, or is null and then determine if the flow should end or not. If you decide later that you don't want the flow to execute because it has been too long you can either let the XOR catch the time and cancel the flow or set the process variable to null.
  • I think I understand what you are trying to accomplish. How about wrapping the process having the receive message event in a synchronous subprocess? Then in the parent process have a rule trigger which will trigger based on some time or condition. And it should then execute the terminate event. So, when the parent terminates due to some condition/timer, the child subprocess will also terminate rather than continue waiting for receive message event