Architecture and Processing

How Workflows Fit within IFS Cloud

The majority of the workflow logic resides within the middle-tier through tight integration between the Camunda Workflow Engine offering and the IFS oData provider. Wrapping every oData transaction, the lightweight communications between the components come to life when Events are triggered within the IFS Event Framework.

Events are stored in the database using the Event framework. An Event action with the type “Workflow” that is referenced to a custom event will allow the deployed BPMN to be invoked within IFS Cloud. For information about how to invoke a Workflow, refer here.

When an event action is triggered, the oData Provider prepares to execute the Workflow. The middle tier communicates with the database and logs the intent to execute the Workflow in the database. After the initial action, the Workflow is executed using the Camunda Workflow Engine in the middle-tier. Once the execution has been completed, the database session is checked to see if any other Workflows need to be executed. This sequence occurs within a single transaction.

If the Workflow is registered with a "Before" timing, a predictive service is used to retrieve data from the database related to the projection it will be running. However, since the projection may run other projections that are not known ahead of time, this can only predict some things for the Workflow to be executed.

How Workflows are processed

How Cascade works

Figure: Diagram depicting the flow of Workflows being run with the projection action that triggered them.

The configuration timings Before, After and Async refer to when the Workflow is run relative to when the projection action that triggers the Workflows is run. "Before" Workflows are run right before the projection action and "After" Workflows are run immediately after. "Async" Workflows have a listener that polls for the Async Workflows and runs each Async Workflow on its thread in the background.

While a projection action is being executed in the database it may call another projection or otherwise trigger an event without the middle tier’s involvement. In this case, we still want to run any Workflows that are linked to the additional projections that got executed. Unfortunately, since we don’t know beforehand that additional projections would be called there is no way to run any of the additional before Workflows before the additional projection actions are executed. Instead, all the additional Workflows will get called after the additional projection has been executed. These additional Workflows are referred to as the cascading Workflows. After running any After Workflows that the original projection has a list of all the synchronous Workflows that were triggered is checked and any that haven’t been run are then taken care of. Any additional Async Workflows that got triggered will be picked up and handled the same way Async Workflows normally are.

Additionally, after an Async Workflow is run cascades are checked just in case the Workflow triggered projections or events with Workflows attached. The list of cascading Workflows is thread-specific so there is no concern with an Async Workflow accidentally running cascading Workflows before the main projection flow can get to them.

Figure: Diagram depicting the flow when a Workflow triggers another Projection. Note that in this diagram an After Workflow triggers the projection as an example; any Workflow could invoke the second projection.

In the case that the IfsProjectionDelegate is used in a Workflow then when that Workflow is run the projection will be called and handled before proceeding on with where the original flow was left off. This means if a Before Workflow calls the IfsProjectionDelegate then the projection it calls will be executed before the projection that originally invoked the Workflows. If an After Workflow calls IfsProjectionDelegate then the called projection will execute after the original projection. Asynchronous Workflows can also call the IfsProjectionDelegate and have the called projection happen in the background. If one of these nested projections is called then only its Before Workflows are executed. Any After Workflows will be picked up when looking for cascading Workflows. Only the original projection will search and run cascading Workflows. Asynchronous Workflows of nested projections will be handled the same as the original projection’s Asynchronous Workflows.