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