LSPS Documentation
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:
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:
To define monitoring related activities, modeling elements can define
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 ascom.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.
