Activities

An Activity represents a piece of work that need to be done and that either by a human or a system (machine). The term covers Tasks, which are considered atomic, and the Sub-Process, which encapsulate other elements.

An Activity is executed whenever it receives a token: the token is typically passed by the incoming flow of the Activity: each token results in a single Activity execution.

In the example above, the parallel gateway "splits" the incoming tokens into two tokens: further down your execution flow, the tokens enter an Activity: each token will result in its own Activity execution, in this case, the activity is executed twice: once for the token from the Condition Intermediate Event and once for the token from the Timer End Event.

The logic of the execution depends on the activity type and additional mechanisms, such as, looping. Mind that looping does not influence the number of Activity executions.

An activity has an arbitrary number of incoming and one or none outgoing sequence flow. The flows influence the execution in the following ways:

• Incoming flows:
  • If an activity does not have an incoming Flow, it is instantiated when the process is instantiated. If there are multiple Activities with no incoming flows in one Process, all such Activities are instantiated (multiple tokens are produced).
  • If it has one or multiple incoming flow, it is instantiated always when the any of the flows send a token to the activity.
• Outgoing flows:
  • If an activity has no outgoing flow, the execution finishes along with the Activity execution (its token ceases to exist after the activity is accomplished).

Activities can have intermediate events attached to their boundary. These events react to specific events or conditions that can occur during the activity execution; for example, they can be used if the execution of an activity should time out after a certain amount of time.

Tasks

A Task is an atomic Activity in a workflow: it represents the smallest logical piece of work, which cannot be broken down any further (for example, sending a file, filling in a questionnaire, displaying a text, etc.).

A Task can have none or multiple incoming, and none or one outgoing Normal Flow.

When the workflow hits a task, the task becomes alive and its logic is executed: if the execution is successful, the task becomes accomplished. If the parent model instance is suspended, an alive task also becomes Suspended.

Task Lifecycle

Activities of task types can be reflected as Records: this allows you to create instances of tasks by instantiating them as Record instances. Typically you will send the Record as a parameter to the Execute Task which makes sure its gets executed as a task in your workflow. In the LSPS implementation, a task type is reflected after you set the Create activity reflection type flag.

Note: To-dos generated by human tasks can be saved. The human task remains alive while the to-do is saved.

Every task is of a particular task type: the task type determines what kind of action the task performs. Depending on the type, every task has a set of parameters, which define the input and output data for the task execution.

You can execute a task multiple times in one execution using the looping mechanism.

Task notation

In addition to the common modeling element attributes and apart from attributes specific for a task type, tasks define the following attributes:

• Public: task type visibility

  If not Public, the task type cannot be used by any importing modules.

• Deprecated: flag which signalizes that the task will be removed in the next version of the model or application If the flag is selected, on validation, a warning notification is logged about that the user is using a deprecated task.
• Parameters: task specific parameters Parameters define the following properties:
  • Name: parameter name
  • Type: data type of the parameter
  • Required: if true the parameter is obligatory
  • Dynamic: if true the parameter value is wrapped in a non-parameteric closure automatically (the parameter is then processed as { -> <parameter_value> }.) This is the case of the uiDefinition parameter in the User task. Hence the user does not need to define the uiDefinition parameter as { -> <form()> } but only provides directly the call to the form (form()).
• Class name: name of the task class

Sub-Process

A Sub-Process is a compound Activity encapsulating a workflow: it is a “process within a process” that serves to organize the workflow content.

It exists in its own context with its variables and parameters and its workflow is triggered as part of its process. It can be triggered by token passed by its incoming flow or by an event: if you want to trigger a Sub-Process with events, use an Inline Event Sub-Process.

A Sub-Process can be of the following types:

• Embedded Sub-Process defines its workflow in-place inside the parent Process or Sub-Process
• Reusable Sub-Process defines a reference to a process and uses this process as its content

Embedded Sub-Process

An Embedded Sub-Process is a Sub-Process that is defined as part of its parent Process or Sub-Process. Its workflow must contain one None Start Event or one or multiple Activities with no incoming Flows.

On runtime, a sub-process instance is created when the token passes to the Sub-Process through its incoming flow: then the None Start Event produces a token and Activities with no incoming Flow are triggered. The execution finishes when there are no tokens in the sub-process instance.

Also, an embedded Sub-Process can be marked as a transaction embedded Sub-Process to mark it as comprising a business transaction that is "atomic". Its workflow can finish with a Cancel End Event: the subprocess must have a Cancel Intermediate Event on its border with an outgoing flow: When the flow finishes with the Cancel End Event, the outgoing flow of the border Cancel Intermediate Event is taken.

Embedded Sub-Process notation

Reusable Sub-Process

A Reusable Sub-Process references a Process: when triggered, it instantiates the Process as a subprocess.

Reusable Sub-Process notation

Reusable Sub-Process Attributes

• Referenced Process Name defines the assigned Reusable Process.
• Parameters are key-value pairs used as parameters when the Sub-Process is instantiated (similar to process parameters)

Inline Event Sub-Process

When you mark a Sub-Process as an inline sub-process, its Start Events are considered part of the parent context, which is either a process or another sub-process. Such start events can be of different types so they are triggered when a particular event occurs in their parent Process or sub-process: When they start with a None Start Event they are triggered when the parent is triggered and in the case of other Start Events whenever the trigger event occurs in the parent.

Note: Also a BPMN-based process can contain any type of Start Events: this allows you to trigger it when it is used in a Reusable Subprocesses.

For example, if a process instance finishes with an Escalation End Event, all Escalation Start Events in its inline event subprocesses receive the escalation and one creates its sub-process instance. This allows you to consume a token and at the same time, produce a token somewhere else while keeping the process instance running.

An Inline Event Sub-Process can be placed into the workflow with an incoming and outgoing Flow or with no incoming or outgoing Flow.

• When used as part of a Process or Sub-Process workflow with at least one incoming Flows and one outgoing Flow, the workflow inside the Sub-Process must contain a None Start Event or one or multiple Activities without an incoming Flow and it can contain an arbitrary number of Start Events other than the None Start Event. The subprocess is then triggered as follows:
  • None Start Event is triggered when a token passes through the incoming Flow into the Sub-Process: a new Sub-Process instance is created and the None Start Event produces a token.
  • Start Events of other types are triggered whenever their event occurs during the life of the parent instance, that is, either a Process or Sub-Process instance.
  • Activities with no incoming Flow are triggered whenever a Sub-Process instance is created and that as part of the Sub-Process instance.
• When part of a Process or Sub-Process with no incoming or outgoing Flows:
  • None Start Event is triggered when the parent Process or Sub-Process is triggered.
  • Start Events of other types are triggered whenever their event occurs during the entire life of the parent Process or Sub-Process.
  • Activities with no incoming flow are triggered whenever a Sub-Process instance is created and that as part of the Sub-Process instance.

Note: Inline Sub-Processes cannot use the looping mechanism.

Looping

Looping allows you to execute the logic of an Activity multiple times: individual loop runs are considered part of the Activity execution: looping does not change the amount of tokens.

Loops can be executed in the following ways:

• standard (for): Activity is repeated successively (serially) the defined number of times unless the loop condition becomes false.
• multi-instance (foreach): Activity is repeated in parallel or in sequential manner over a list of items.

Note: Alternatively, loops can be also created by cycling the workflow using flow elements: In such loops, a Gateway has an outgoing flow “returning” to a preceding Gateway.

Looping defines its iterator, which stores the number of the loop starting from 0 and is incremented by 1 after each loop.

Multi-Instance Looping

Multi-instance looping enables you to execute the logic of one Activity on each object of a list of objects. The looping can be either parallel or sequential.

Multi-instance looping defines the following:

• list of elements the looping is performed for (For each attribute);
• how the multi-instance loop is to be executed:
  • sequential: when one instance of the Activity finishes, a new instance is created
  • parallel: activity instances for all list objects are started at once; the Activity finishes after all its instances finished.
• looping iterator: name used to refer to the currently iterated object.

Multi-Instance Looping Notation

Activity with multi-instance loop

Multi-Instance Looping Attributes

• Iterator: name of the iterator (you can use it in the For each expression and anywhere within the activity to get the current loop object)
• For each: list of objects to be used in the loops
• Ordering: loop ordering strategy (sequential or parallel)

Standard Looping

Activity with a Standard looping definition is repeated serially for a set number of times.

On each loop of standard looping, the server checks either before or after each loop whether the loop condition is true. If it is false, the looping finishes.

When the looping finishes, the Activity releases one token to its outgoing flow.

Note: If the loop condition is evaluated always before the execution of the loop and the condition is at the first evaluation false, the Activity is never performed.

The looping iterator is initialized to 0 and incremented by 1 after each loop.

Standard Looping Notation

Activity with standard loop

Standard Looping Attributes

• Iterator: name of the iterator (you can use it in the loop condition or anywhere within the Activity to gets the number of loop that is currently executed (The iterator is initialized to 0 and bumped after or before each loop.)
• Loop condition: condition that finishes the loop; it defines also its time time, the moment when the loop condition is checked (before or after a loop)
• Loop maximum: maximum number of loops (Once the maximum number of loops has been reached, the looping finishes regardless of the value of the loop condition.)