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, plus with functions and methods provided by the Standard Library; 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 security rights for security roles.
Modules are created in PDS and once ready you can upload them to an LSPS Server and execute them. On the server, they live in the Module Repository. On upload, a module with all its module imports is uploaded into the Module Repository. If you need a copy of an uploaded module, you can download it from the repository. Once a module is no longer needed, you can unload it to keep the repository clean.
Whenever you are uploading a module, you need to define how to deal with any database changes. This is set as the database update strategy:
If the database already contains data and you want to upgrade the schema, generate the schema update scripts and use the scripts to migrate the schema with your business data.
To require confirmation on model upload, set confirmModelUpload to true. The flag is exposed as the MXBean property com.whitestein.lsps.Settings -> Attributes -> ConfirmModelUpload. You can change the setting also with a database insert into the LSPS_SETTINGS table:
INSERT INTO LSPS_SETTINGS(ID, VALUE) VALUES ('CONFIRM_MODEL_UPLOAD', 'true');
Model instances are runtime versions of models (a model designates an executable module with all its module imports): when you create a model instance, you "run a model". You can run multiple instances of a model possibly with different parameters.
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:
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 showcase for a custom mechanism
and is under no circumstances to be considered production-ready.
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.
To-do reset ( 
) erases the data in a saved to-do. This feature is useful if the data used by the saved to-do have changed; typically on model update. Note that the reset to-do remains locked by the same user. You can reset a to-do from the management console or management perspective.
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.