Useful Tips with Workflows and Parallel Activities

Like all technologies, it is often not until Workflows are used in anger that the techniques to get the most out of them become clear. Here are some things that our deployment engineers have picked up on when using parallel activities in flowcharts.

It is important always to remember that a workflow uses a single thread. This is key for understanding how a flowchart behaves when acting as a high level client to components in the (multi-threaded) CoreTegral environment. For example, if a 'parallel' activity is started that may be initiating some actions to the equipment at the same time as listening for events from it, then it is important to remember that 'parallel' activities are not really parallel. The leftmost sub-activity within the 'parallel' activity will be activated first, and only after it reaches a blocking point will the next sub-activity be kicked off. In practice, this typically means that if one of the parallel sub-activities is listening to an event that may result from logic in the other, then that sub-activity should be placed on the left.

Another feature of parallel activities to be aware of is the behaviour when a completion condition is set. Each parallel activity can have a completion condition, and if this is set to true then all the sub activities will complete at the next blocking point. The completion will not ripple upwards like a try-catch though, and the next activity in the flow should handle all completion states. The CoreTegral Event Listener activity can be used within parallel activities, but if listening for multiple different events it often makes more sense to use a single CoreTegral Event Listener in a traditional event handling loop. Once activated, each instance of the CoreTegral Event Listener has its own queue of events and will continue to receive events even though it is not currently active. This means that as long as the logic resulting from the received event does not take longer to complete than the queue expiry timer (default 30 seconds) then no events will be lost and they can be removed in order for processing from the queue.

‍