What are Workflows?¶
A Workflow is a sequence of tasks that process a single data collection from a business and industry interaction. Anytime data is passed between humans and/or systems, a workflow may be performed. With the Business Process Automation features that actively use the workflow engine is built into the Custom Event framework and the REST API/Projection framework, we can leverage existing functionality to trigger automation but also enhance it.
How a Workflow can run?¶
There are two ways of running a Workflow,
1. Projection Action Configuration¶
Projection Action configuration is linked to a Workflow that runs when a specific action is performed within an IFS Projection. Specifically, a Workflow could be linked to a Create, Read, Update or Delete operation using any entityset available within an IFS Projection. A Workflow may also be associated with the invocation of any action or function available.
2. Event Action Configuration¶
Event Action configurations are linked to a Workflow that runs different automations such as calling an IFS Projection or prompting the user to enter additional information based on an action they perform within the IFS Cloud. Workflows can also be leveraged for data validations within a process that be configured with an error message which stops a specific action or a process and displays an error message to the user.
To read more on how to link a Workflow to a Projection Action Configuration or Event Action Configuration. Refer to the Workflow Tooling section for more details.
Let's take a look at the Workflow Types and the Workflow Timings available.
Workflow Types¶
There are 3 types of Workflows, these are:
User Interaction¶
User Interaction Workflow is used when a user performs an action and the business process requests the user to enter additional information regarding that transaction. The new data can be used to make a decision within a gateway or to invoke one of the many different projections within the IFS Cloud.
A User Interaction Workflow could only be invoked via a Projection Action Configuration. When a User Interaction Workflow is invoked, one or more forms may appear within the IFS Cloud Aurena client based on the Workflow's definition. Each form presented to the user from a user interface Workflow corresponds to a User Task within the Workflow definition. The user is expected to provide the information required based on the task configuration.
The fields that are expected to be displayed within the form are configured within User Tasks of the Workflow.
When clicking a User Task you see the Properties Panel change on the right-hand side of the Workflow Designer where you see a Forms tab and can add any fields relevant to the Workflow's intended purpose.
In this scenario, we have added the User Tasks and now will need to call the projection where the fields/variables mentioned in the User Tasks will be included in the Create operation.
The IFS Projection Delegate Task would be selected, and the user needs to choose the relevant Action, Projection Name and Entity Set Name. The projection delegate task doesn't always have to be straight after a user task. In this scenario, the user enters the information and that information is used to create the State record.
After the tasks have been added to the Workflow, the user will need to add conditions to any Gateways/Decisions that have been added to ensure that the Workflow transaction follows the correct route of the Workflow. The syntax for the conditions is JavaScript or Camunda Expression Language and more information can be found on this in the Condition Syntax section. An example of the JavaScript syntax can be seen below where the decision’s condition is evaluating a field of one of the User Tasks. If the field named “Question” - which is a non-database field/variable in this example - is answered true, then the condition is met. Once the Workflow is configured the relevant End Points need to be added to ensure the transaction completes and finishes accordingly.
Validation¶
Validation Workflows are designed to conditionally prevent a user from completing an action within the system, they populate an error message to the user which is localized and is then alerted to stop the transaction from occurring without the need for custom development. A sample validation failure message is displayed to users as a toast in the following example:
The error message text that has been configured is to show “Error message test”.
The creation of the Workflow within the Workflow Designer is similar regardless of the type configured. The difference is which BPMN symbols within the toolbox section of the Workflow Designer are applied to the Workspace section of the screen to perform the relevant automation.
When assigning the failure event and clicking on that event, the properties for the failure event will be displayed within the Properties Panel as depicted above. The user is encouraged to provide multiple locale codes and messages to support all users within the system. The messages provided within the Properties Panel will be displayed to the users when the failure conditions defined within the Workflow are met.
Once the BPMN diagram is created it can then be saved and deployed to the server which means the Workflow can be tested.
Process Enrichment¶
Process Enrichment Workflows provide the functionality where data is required to be created, altered or deleted. Process Enrichment is where the Workflow invokes automation that enriches the transaction, process or action within the system. These can be:
-
Calling IFS Cloud's internal projection operations, which are:
- Create
- Read
- Update
- Delete
- Function
- Action
Calling a projection is one of the most common steps that is required to alter data via creating, updating, deleting etc. This can be seen in the following screenshot where the user has clicked on the Create State task, in the Properties Panel section of the Workflow Designer of that task allows the user to select which action, projection and entity set to call along with passing output parameters such as projection fields to the projection to update that field within the projection accordingly.
The best resource to view the many different projections and the many operations would be the API Explorer within IFS Cloud. The API Explorer helps users to know what projections, fields and parameters to add to the different tasks within the Workflow.
Workflow Timings¶
The Workflow Timings listed below represent below different stages of a transaction where the Workflow can be invoked:
| Name | Description |
|---|---|
| Before | The Workflow is executed as part of the user's action which caused the Workflow to execute; in technical terms, the Workflow is part of the same transaction as the user's action. The Before timing means that the Workflow will be attempted to be invoked before the principle user action. Workflows registered with a Before timing are particularly useful when altering, or adding, data before to the main call being executed. Note: 'Before' Workflow Timing is only applicable for Projection Action based Workflow invocations. |
| After | If you choose the After timing option, the Workflow that is executed starts within the same transaction. The After timing means that the Workflow will be invoked on completion of the main REST call as a reaction. This allows the data within the transaction to be changed before the completion of the transaction but after the main logic of the projection has been executed. |
| Asynchronous | Asynchronous Workflows can only be used to perform Process Enrichment activities and allow functions such as Background Jobs that are on a scheduled routine to be run without waiting for a response from the server. Workflows configured using the Asynchronous timing option are logged for execution within the same transaction and each asynchronous Workflow is then executed in a separate transaction. An example of asynchronous execution is the sending of an email; in this case, program execution will log the intent to send emails and continue execution while the actual sending of the emails will happen in the future within a second transaction. |