LSPS Documentation
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.
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:
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.
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.
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.
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.
{ -> <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()).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:
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.
A Reusable Sub-Process references a Process: when triggered, it instantiates the Process as a subprocess.
Reusable Sub-Process Attributes
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.
Note: Inline Sub-Processes cannot use the looping mechanism.
Looping Activities are executed multiple times: however, the individual loop runs are not considered different Activity instances, that is, looping does not change the amount of tokens.
Loops can be executed in the following ways:
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 enables you to execute a loop of one Activity on a defined list of objects, and that, in a parallel or sequential way: when a token enters a multi-instance looping Activity, the system creates multiple instances of the Activity, for example, multiple To-dos generated by the same Task. However, all the instances represent the execution of the single Activity: only one token exists even though there are multiple instances of the Activity. The activity becomes accomplished only after all its instances are finished; and similarly, if one of the Activities fail with an Error for example, all the instances finish.
Looping iterator is initialized to 0 and incremented by 1 after each loop.
Multi-instance looping defines the following:
Multi-Instance Looping Notation
Multi-Instance Looping Attributes
Activity with a Standard looping definition is repeated serially.
On each loop of standard looping, the system checks before each loop if the loop condition is true. If it is false, the looping finishes. This check can be performed also after each loop. The maximum number of loops is determined explicitly by the loop maximum. Once this maximum is reached, the looping finishes regardless of loop condition. When the looping is finished the Activity release a single 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 evaluated false the Activity will be never performed.
Looping iterator is initialized to 0 and incremented by 1 after each loop.
Standard Looping Notation
Standard Looping Attributes