A workflow can publish events an Enterprise Service Bus (ESB.) And a workflow instance may also wait for certain event or message to arrive: once the message arrives, the workflow process will proceed.
FlowWright v9.6 introduced this latter feature so that placing a "wait for message" step within a workflow will cause the workflow to "sleep" at that point until a message is received to continue. So for example, let's say a workflow that automates food ordering includes stages such as "order created", "payment processed", "food prepared", "food delivered", and "order completed". Tasks such as "food delivered" can take place over a vague time period and the workflow will wait until a message is received signifying the task is complete before moving on to "order completed".
Within the above workflow process example, even payment processing can be done through another system: the workflow will sleep/wait until the payment processing is completed and a message is received over the publish/subscribe ESB.
Below is a simple example of a workflow where the workflow sleeps at 2 points and waits for incoming messages for Alarm ACK and Alarm Cleared.
The next graphic shows the executing and waiting workflow instance.
Messages can be sent to this workflow using two methods, 1) through the .Net API or the REST API, or 2) - through the FlowWright user interface. So, in order to continue processing this workflow instance, let's select the workflow instance and send some messages from the UI.
Using the next UI dialog, a message can be selected and sent to the workflow instance.
Once messages are sent, the workflow will receive them via the ESB and continue to execute. Here's the executed workflow instance.
As you can see from the above example, you can make any workflow process wait for incoming messages. This is very important in asynchronous processes, FlowWright always supported development and use of asynchronous steps, but the "wait for message" step makes building asynchronous processes more rapid and efficient!