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 a particular element enters a particular life cycle status. The mechanism is available on modeling elements with execution semantics within a Process and on Processes themselves. Typically, an assignment defines an expression that assigns a value to a slot, such as a variable.

You can define an assignment for the following:

  • Flows, Start Events, End Events, Exclusive Gateways:

    Assignment is performed when events are executed (token passes through the element).

  • Intermediate events, Activities, and Parallel Gateway:

    The elements can define the following assignments:

    • 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 within a Process and on Processes themselves (it is identical to the Assignment mechanism).
  • monitoring flags: available on variables and on Records If flagged as monitoring, the elements are displayed with a monitoring icon to indicate that the entity is involved in monitoring. The flag does not impose any semantics by itself.


A signal is a means of communication within a model instance or with another model instances.

It is produced by Throw Signal Events and processed by Signal Start Events and Catch Signal Events of the target model instances:

Alternatively, you can create a Signal object explicitly.

Signal object cannot be or recursively contain a reference, closure, Goal, Plan, or Process instance.


An Error represents a critical problem in execution of your process, which should cause the execution to stop immediately unless explicitly handled and corrected.

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

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

Once generated, the error is gradually propagated through its the immediate context and looking for an element, which could consume it. If the error is not consumed in the immediate context, it is gradually propagated throughout higher contexts. If not consumed within its process instance, an exception is thrown and the last transaction which caused the error is rolled back. Note that the last transaction, refers to the last EJB transaction of the model instance.

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