LSPS documentation logo
LSPS Documentation
Process Modeling

A process contains workflows consisting of modeling elements with execution semantics, which define how it is executed; this includes processes themselves, goals and plans, process body elements with semantics, such as, gateways, intermediate events, start events, activities, etc.

Every modeling element has at least the following properties:

  • Name: optional identifier of an element in its namespace
  • Description: free-text description
  • Assignments and Monitoring: set of expressions executed at a certain point of the element's life


Assignments serve to define expressions that are executed when an element changes to a life-cycle status from another named status. They are execution hooks where you can define the actions taken for the life-cycle status: You can define what should happen when an Achieve Goal becomes running, when a Task is accomplished, etc.

  • On workflow elements, some or all of the following assignments can be defined depending on the element:
    • Start assignment is performed when the token enters the element.
    • End assignment is performed always when a token leaves the element or is removed from the element, for example, due to failure, termination, or restart.
    • Accomplish assignment is performed when a token when the flow element finishes "successfully" and the token leaves using the outgoing flow. The Accomplish assignment is performed always before the End assignment.
  • Goals and Plans can define assignment for individual life-cycle statuses.

Monitoring an Element

To define monitoring related activities, modeling elements can define

  • monitoring assignments: a special type of Assignment intended to implement the monitoring logic

    Monitoring assignments are available on modeling elements with execution semantics. It is identical to the Assignment mechanism and is executed right after assignments.

  • monitoring flags: an indicator that a variable or a Record is used for monitoring purposes


A signal is a means of communication within a model instance or with other model instances, the recipients of a signal.

A signal is targeted at particular model instances: when sent, it is either consumed by at least one Signal Catch Event or added to the signal queue of the model instances: If multiple Signal Catch Events can consume the Signal, then all of them consumed the Signal one time (Signal Start Events and Catch Signal Events). If the signal is not consumed by at least one event in a target model instance, it remains in its signal queue.

Depending on the transaction that adds the signal to the signal queue of the target model instance, we distinguish synchronous and asynchronous signals:

  • Synchronous signals are added to the signal queue of the target model instance in the same transaction that produced them. As a result, the signal can be caught and processed in the same transaction.
  • Asynchronous signals are added to the signal queue of the target model instance only in the next transaction.

Signals are produced by Throw Signal Events or using the sendSignal() function. and can be any object that is not and does not recursively contain a reference, closure, Goal, Plan, or Process instance.


An error represents a critical problem in execution of your process, which stops the execution immediately unless explicitly handled and corrected.

Once generated, the error is gradually propagated through its immediate context. If the error is not consumed in the this context, it is gradually propagated throughout higher contexts. If not consumed within its process instance, an exception is thrown and the last model transaction which caused the error is rolled back.

An error can be thrown by an Activity or an Error End Event.

Note: Additionally, you can throw an error with the error() function of the Standard Library or from your custom implementations as com.whitestein.lsps.common.ErrorException.

An error can be caught and consumed by a Error Intermediate Event or by Plans.



The escalation mechanism resembles the signal mechanism; however, while signals can be consumed by multiple elements in the model instance, an escalation signal is consumed by a single element within its model instance.

Similarly to signals, to perform escalation, you need to create an escalation object with the Throw Escalation Event or Escalation End Event positioned at the appropriate location in your workflow. When the workflow enters a Throw Escalation Event or Escalation End Event event, the event produces an Escalation object, which is then propagated through its own context and then through parent contexts and "up" to higher contexts until caught by an Escalation Start Event or Catch Escalation Intermediate Event or until no higher context exists. Once caught by an Escalation Start Event or Catch Escalation Intermediate Event, the Escalation object is not propagated further. If there are multiple Escalation Catch elements in the same context, only one of the elements consumes the Escalation signal and only the catch event that consumes the escalation object produces a token.

The object must define its escalation code, a string that serves as its identifier: the code can be then used by filters of the Escalation Catch Events to filter the objects.

Demonstration of escalation with an Escalation produced in a subprocess and caught be a Catch Escalation Event
Process that terminates in an Escalation End Event which triggers the Escalation Start Event of its Inline Event Subprocess
Plan and BPMN Modeling Elements Goal Model