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 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 there are multiple Singal Catch Events that can consume the Signal, then it is processed exactly one time by all such events (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:
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 the 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 ascom.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.
