BPMN (Processes)

In Toqio Workflow Design, a process is a predefined sequence of steps or tasks designed to achieve a specific goal. It's like a blueprint that defines how work flows through different activities, decisions, and roles within an organization.

Think of a process as a flowchart that guides how certain tasks are carried out, such as handling a customer order, approving a document, or onboarding a new employee. In workflows, these processes are automated, allowing you to create efficient, repeatable flows that ensure the right tasks are completed by the right people or systems.

Workflows use BPMN 2.0 (Business Process Model and Notation), a graphical representation to model these processes. BPMN diagrams visually depict the steps in a process, such as:

• Tasks (e.g., user tasks, automated tasks, scripts, HTTP calls),
• Events (e.g., start, end, or intermediate events)
• Gateways (e.g., decisions or branching paths)

By defining a process in Toqio Workflow Design, you can streamline business operations, automate repetitive tasks, and ensure that processes are executed consistently, reducing manual effort and errors. Key benefits of workflow processes include:

• Automation: Simplify complex workflows by automating routine tasks.
• Consistency: Ensure that tasks are always executed in a standardized manner.
• Visibility: Obtain real-time tracking of tasks and processes, making it easier to monitor progress.
• Integration: Connect to external systems, such as databases or web services.

In summary, a process in Toqio Workflow Design is a powerful way to model, automate, and improve the flow of work within an organization. Here’s an example of a workflow process:

A process instance can be launched by an HTTP call (rest buttons in forms) using the following values:

Method: POST
Endpoint: {{endpoints.process}}/runtime/process-instances
Body: (example)

From outside workflows (From BE or Postman): It is necessary to add a bearer token for being authenticated.

{
"processDefinitionKey":"EX_P053",
"variables":[{"name":"customer","type":"string","value":"TOQIO"}]
}

Every process model must start with a start process event and finish with an end event.

Back end expressions

Back end expressions are a tool to get or set variables during the execution of processes, cases, or decision tables. Back end expressions can also be used to implement custom logic or to delegate that logic to a Java service deployed on the server. Examples of using expressions include setting dynamic task names, evaluating sequence flows after a gateway, or creating a variable of a certain type. As the name implies, these expressions run on the back end, during execution. As such, they have no access to the front end data at the time of evaluation.

In Toqio Workflow Design, expressions are allowed in fields marked with a lightning bolt.

Toqio Workflow Design uses the Unified Expression Language (UEL) for resolving expressions. The documentation for UEL is a good reference for syntax and available operators. Each expression starts with ${ and ends with }.

There are two types of expressions:

• Value expressions provide a value. Supported values include Boolean, string, integer, floating-point number, and null. A typical value expression is ${variable.property} or ${bean.property}.

• Method expressions invoke a method with or without parameters. An example of method expression is ${bean.setPropertyValue('newValue')}. To distinguish between a value expression and a method expression without any parameters, use empty parentheses at the end of the method call. For example, ${variable.toString()}.

Keywords

The process and CMMN engines support context-dependent objects. Both engines resolve hierarchy objects like root and parent and can be used to access their local properties. root stands for the object on the top of the execution hierarchy, which can be a process instance or case instance. parent is a reference to the first process or case instance immediately above the current object in the hierarchy.

For process instances and case instances definition grants access to the definition and all its attributes.

In the context of BPMN execution, additional reserved keywords are execution and authenticatedUserId:

• Execution references the current “path of execution” or “token”. It provides access to properties like name, businessKey, processDefinitionId, and parentExecution (technically, it is backed by the ExecutionEntity class).

Process instance properties​

The following properties are available on a process instance, for example when using root or parent.

Example usage: ${root.businessKey}.

Variable functions​

Variable manipulation is an important use case of expressions. Setting variables can be done through the runtimeService:

• ${runtimeService.setVariable(processInstanceId, variableName, variableValue)}
• ${cmmnRuntimeService.setVariable(caseInstanceId, variableName, variableValue)}

Or they can be done on a keyword object (depending on the context):

• ${execution.setVariable(varName, varValue)} sets the value varValue to the variable varName of the current process instance.
• ${caseIstance.setVariable(varName, varValue)} sets the value varValue to the variable varName of the current case instance.
• ${planItemInstance.setVariable(varName, varValue)} sets the value varValue to the variable varName of the current case instance.
• ${task.setVariable(varName, varValue)} sets the value varValue to the variable varName of the current process/case instance.

String utilities​

String manipulation methods are a classic use case for expressions. The following methods are available:

Formatting utilities​

The following methods are available if you need to format values:

Example: ${flwFormatUtils.formatDate(flwTimeUtils.now(), 'dd.MM.yyyy')} formats today's date as dd.MM.yyyy .

Date and time utilities​

JSON utilities​

The following functions are available when working with JSON objects in expressions. They work in BPMN and CMMN contexts.

Mathematical utilities​

The following methods are available when you need to do mathematical operations:

Components {#components}

Initialize variables

To initialize a variable, the initialize variable task can be used. This task allows you to create a new variable or overwrite an existing one.

Script task

In Workflows, script tasks are used to execute scripts in a JSR-223 compatible scripting language, such as Groovy.

Script tasks are mainly used to perform simple calculations or operations. For more complex use cases, you should consider writing a Java service and calling it via a service task.

In the following example, a user is prompted to enter a first and last name.

A script generates an e-mail address and stores it in the variable "email":

The following example shows a very simple sample script that could be used to achieve this task:

var firstName = execution.getVariable("firstName").toLowerCase();
var lastName = execution.getVariable("lastName").toLowerCase();
var email = firstName + "." + lastName + "@yourCompany.com";
execution.setVariable("email", email);

Exclusive gateway

A diverging exclusive gateway (decision) is used to create alternative paths within a process flow. This is basically the "diversion point in the road" for a process. For a given instance of the process, only one of the paths can be taken:

-BPMN 2.0.2 Standard, 10.6.2, Exclusive Gateway

Exclusive gateways are one of the most common sights within a process model. They are used to model decisions within a process.

To decide which route the process follows, the conditions on the outgoing sequence flows are checked. The conditions are modelled as an expression and must always evaluate to a boolean value of true or false. It is important to understand that the conditions of an exclusive gateway are not modelled on the gateway itself but rather on the outgoing sequence flows.

If more than one condition evaluates to true, the path that was defined first is chosen. This should obviously never happen. If no condition evaluates to true, the process is stuck.
There is the possibility to mark a sequence flow as the default flow. If you do so, the flow follows this route if no condition matches.

The following example shows how an exclusive gateway is used to model a simple decision:

Parallel gateway

A parallel gateway is used to synchronize (combine) or create parallel flows. A parallel gateway creates parallel paths without checking any conditions; each outgoing sequence flow receives a token upon execution of this gateway. For incoming flows, the parallel gateway will wait for all incoming flows before triggering the flow through its outgoing sequence flows.

-BPMN 2.0.2 Standard, 10.6.4, Parallel Gateway

Parallel gateways are used to model situations where more than one path is executed in parallel. These gateways do not have any conditions since all paths are always executed. To join parallel branches, use another parallel gateway. The execution only continues once all paths have been completed.

In the following example, the process immediately starts with a parallel gateway which triggers the execution of all three tasks. Once all of them are completed, the process is completed.

HTTP task

The HTTP Task allows the user to submit and store the result of an HTTP call.

This is an example of an HTTP that consults an API that generates a fake user profile:

Call activity

A call activity identifies a point in the process where a global process or a global task is used. The call activity acts as a “wrapper” for the invocation of a global process or global task within the execution.

The activation of a call activity results in the transfer of control to the called global process or global task.

-BPMN 2.0.2 Standard, 10.3.6, Call Activity

BPMN 2.0 makes a distinction between a regular sub-process, often also called embedded sub-process, and the call activity, which looks very similar. From a conceptual point of view, both call a sub-process when the process execution arrives at the activity.

The difference is that the call activity references a process that is external to the process definition, whereas the sub-process is embedded within the original process definition. The main use case for the call activity is to have a reusable process definition that can be called from multiple other process definitions.