LSPS documentation logo
LSPS Documentation
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.

ActivityWith2IncomingFlows.png
Caption text
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.

lifecycle_Task.png
Task Lifecycle

Task types can be reflected as Records: this allows you to create instances of tasks by instantiating them as Record instances. Typically you will then 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.png
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

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.

EmbeddedSubprocess.png
Embedded Sub-Process notation

Reusable Sub-Process

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

ReusableSubprocess.png
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.

EscalationInlineEventSubProc.png

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 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:

  • 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 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:

  • 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.

Multi-Instance Looping Notation

Activity_multiinstance.png
Activity with multi-instance loop

Multi-Instance Looping Attributes

  • Loop activity defines the activity to be looped.
  • For each contains a list of objects to be used in the loops.
  • Ordering defines loop ordering strategy (sequential or parallel).

Standard Looping

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

Activity_loop.png
Activity with standard loop

Standard Looping Attributes

  • Loop: name of the loop iterator
  • 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