LSPS Documentation
Management features serve to manage the LSPS Server and its resources:
You can perform most of the related management task with any of the following tools:
Command-Line Console: command-line management tool
The tool is primarily intended for application and LSPS administrators. However, also process designers and application developers might benefit from its features.
Often it is possible to perform a task in any of the tools; the choice will depend on your preference and specific requirements, such as, automation of the task or integration in a script; ability to apply security restriction on the feature, etc.
Important: Feature accessibility might be restricted by your security rights: Consult your administrator if necessary.
Modules and model instances are the most basic concepts in LSPS, with module being the designed part and model instance the runtime part of your business process.
Generally, you can think of the module as of a package and model instance as the application: You can run multiple applications based on the same package.
Modules are bundles of GO-BPMN resources with one main module that might import other modules. When uploaded, all the imported modules are uploaded to the LSPS Server.
Modules can be marked as executable: such modules can be instantiated on the server, which means that the server creates a model instance of the given module.
Model instances are the execution or runtime versions of models: models serve as a blueprint and the model instance follows the workflows defined by its model. Model instances store only their runtime data, that is, the data on the current and previous execution, such as, which task is currently being running and in what state it is, the current value of variables, etc.
When a Model instance is created it goes through a set of execution statuses:
Created: Model context is created and contexts of individual module instances are created.
Generally, this is a transient state and if your model instance is stuck in this state, it means that something went wrong in the first transaction and the transaction was rolled back..
While a model instance is Running, you can suspend or finish it:
When you suspend a model instance, the execution is halted. To marked this state, the model instance and all running elements become Suspended. You can then resume the execution whenever required.
Important: It is not possible to resume a model instance that is being updated.
For detailed information on behavior of Model instances, refer to the GO-BPMN Model Language Guide.
When you finish a model instance, the execution of the model instance is halted and it instance becomes Finished immediately:
For detailed information on behavior of Model instances, refer to the GO-BPMN Model Language Guide.
Users are represented by persons with personal details and access rights to the application.
A person defines the following:
You can manage all of the data from the Management perspective and the Management Console.
Important: The built-in substitute mechanism is provided as a base for custom substitution mechanism.
The substitution mechanism serves to define stand-ins for persons: when activated any unlocked to-dos assigned to the user are assigned also to all their substitutes. The to-dos are displayed in the to-do lists of both the users and their substitutes.
Note: If a substitute lacks a modeled role required by the to-do, they cannot see the content of a to-do.
At the moment the substitution is deactivated, all to-dos listed in the substitute’s to-do list which were originally allocated to the substituted person and are not locked by the substitute are removed from the to-do list of the substitute and only displayed in the to-do list of the person.
Substitution is transitive: If a substitute has also activated their substitution, the substitution applies also the to-dos assigned due to a previous substitution.
When substitution is deactivated, any unlocked to-dos listed in the substitute’s to-do list are removed; locked to-dos remain in the to-do list.
Individual users can activate and deactivate substitution from their Application User Interface, while administrators can manage substitution of all users for the Management perspective or web console.
Modeled roles represent groups of persons that have the same role in a process. They are defined as part of a GO-BPMN Module. Once these elements are uploaded they can be assigned to persons as their runtime roles.
For parametric modeled roles, you can define the parameter values on their runtime versions.
A role is defined by the module name and its own name, not the module version. As a result, an organization element can define multiple parameters, which can originate from different module versions with the modeled roles.
You can assign a person to the role and units, and remove them as necessary either programatically using the addPersonToRole() function or from the management perspective and web console on runtime manually.
A typical usage of Roles is represented by To-Do performers: For example, you create an organization definition with a role. Then you create a process with a User Task. The User Task will define as its Performer parameter persons with the given role, for example, Admins(). When executed, the generated to-do will be allocated only to the persons with the runtime role Admins. Note that if you add a person to the role, the to-do is allocated to this person as well.
More information on roles and organization units is available in the GO-BPMN Modeling Language Specification.
Parametric roles are modeled roles with defined parameter names. A runtime role created based on a parametric role may have a parameter value attached to the parameter name.
Runtime roles, based on parametric modeled roles, contain parameter definitions (parameter names and values).
If no parameter value is defined, the runtime role is considered superior to any roles with a parameter value and if a parameter value is defined, the runtime role is inferior to the runtime role without a defined parameter value.
Example: Consider a parametric modeled role, Developer, with a parameter, Language.
There are three persons in the system: Javan, Cee, and Deve. Each has the Developer runtime role but with a different Language value: Javan has the Developer role with the parameter Language set to Java, Cee with the parameter Language set to C, and Deve with no parameter value.
When a process dispatches a to-do with the initial performers set to the role Developer with parameter Java, the to-do will appear in to-do lists of Javan and Deve – the person with the role with no parameter value receives to-dos assigned to the role regardless of the required parameter value. However, since Cee has the parameter set to C, he will not receive the to-do.
Security management is implemented as a role-based security manager: A person's security rights are defined by the security roles the person has. Each security role defines the security rights it actually grants: The user can perform an action in front-end application (over runtime) only if they have a security role with the security right required for the action; otherwise, the respective feature is inaccessible or the action is interrupted.
The following predefined security roles are available:
Person details serve to define properties of a person on runtime. They are defined as maps with key-value pairs. In your model, you can get the person details with the getPersonProperties() function.
A to-do represents a job that an end user has to accomplish: it is generated by the User Tasks, which is a type of task provided by the Standard Library.
When the execution flow enters the User Task, the task becomes alive, just like any other task, and the system generates a to-do. The to-do is allocated to its initial users: it is displayed in the To-Do lists of the Application User Interface to the users defined by the Performers property of the User Task.
Note: If the Performers property returns a set of Roles or Organization Units and the administrator or the system assigns or unassigns the Role or Organization Unit to a Person, the system allocates the to-do to this person accordingly.
The moment one of the users opens the to-do, it becomes locked: the to-do is removed from the To-Do lists of other users. Only the user who locked it, can access and accomplish the to-do. They can also decide to reset it so as to release the to-do.
As a result of such actions, assignees of the to-do change and to-do might end up with no assignees. Such to-dos are referred to as orphaned and require the attention of an administrator: in the Management Console, the administrator can search specifically for such to-dos.
When the user accomplishes the to-do task, that is, they submit the form of the to-do: the User Task becomes accomplished and the underlying process workflow proceeds to the next element.
The accessibility of the actions can be restricted by user security roles.
Important: The built-in delegation mechanism is provided as a base for custom mechanism.
Delegation enables users to assign an alive to-do to other users, for example, to ask for assistance or simply because they know better. When a user delegates their to-do, the to-do disappears from the to-do lists of all current assignees and appears in the to-do list of the selected users–delegates. A delegate can delegate the to-do further–delegation can take place on several levels.
To-do escalation provides the user a mechanism that sends a special type of Signal, an escalation Signal, to the server while keeping the to-do locked. The underlying Model is expected to catch the signal and process it as appropriate: hence, the underlying process flow must define how the signal is caught and handled.
Important: Note that the to-do escalation mechanism is not related to the Escalation of the GO-BPMN Modeling Language.
Rejection allows a front-end user who is an assignee of a to-do to reject the to-do: when rejected, the to-do is removed from their to-do list and the fact is recorded by the server.
You can check the assignees who have rejected a to-do in the Assignees box of a to-do detail view: They are indicated by a red assignee icon. From the view, you can cancel the rejection and reallocate the to-do to the assignee again.
Todo reset ( 
) erases the data in a saved to-do. This feature is useful if the data used by the saved to-do have changed. Note that a reset to-do remains locked by the user.
Important: The built-in reassignment mechanism is provided as a base for custom mechanism.
Reassignment enables an administrator to assign an Alive to-do to another set of performers, who become the initial performers. That means you can reassign a to-do to roles, organization units, or persons.
When you reassign a to-do, you modify the current performers as well as its initial performers: The to-do disappears from the to-do list of the original assignees and appears in the to-do lists of the new assignees, which become the current and initial assignees of the to-do. The information on original assignees are lost.
Important: Reassignment cannot be undone.
Logs are dedicated LSPS Application logs: they are created by the Log tasks and log() functions, which are part of the Standard Library and stored in system database table LSPS_LOGS.
When a model instance fails with an Exception, the Execution Engine rolls back the transaction that caused the exception. Such error on model instances is recorded in the Exceptions log (for further information on transactions in model instance, refer to Transactions in Model Instances).
As part of the management features, you can resend inputs to such model instances.