LSPS documentation logo
LSPS Documentation
Management

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:

  • Tools in the Management perspective: perspective in the PDS development environment
  • Management Web Console: web-based front-end application intended for Management of model instances, users, and the LSPS front-end applications, that is, the Process Management Console and the Application User Interface.
  • 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.

Module Management

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:

  • Do nothing with database schema: Existing schema remains unchanged.
  • Update the schema by model: New tables, columns and relationships are added; however, no data is deleted.
  • Validate schema first: Existing schema is validated against the new model schema (if inconsistencies are detected, the model launching fails).
  • Drop/create schema: Existing schema is dropped and a new schema following the new model definitions is created.

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 Instance Management

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.

Person Management

Users are represented by persons with personal details and access rights to the application.

A person defines the following:

  • User information: user details, such as login, password
  • Application data: person data, such as, name, email, phone
  • Security roles: enable or restrict access to general system features, for example, to to-do rejection, document submit, person management, etc.
  • Modeled roles: roles that define the person role in a model instance created based on organization models of the model. Typically they will restrict the access to to-dos and documents.
  • Substitution: list of substitutes

You can manage all of the data from the Management perspective and the Management Console.

Substitution

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.

Role Management

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.

  • If another version of the same module with an updated organization definition is uploaded, the role is identified as the same role as the one created by the previous module version (assuming the role name remained unchanged).
  • If another version of the same module contains the same role with a new parameter name, the parameter name is added to the already-existing parameter names of the modeled role.

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

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.

rolesViewWithParametricValue.png
Roles view with a parameter runtime role outlined

Security-Role Management

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:

  • Admin represents a security role with rights of an administrator. Admin has all security rights and hence an unrestricted access to management features. The security role is read-only and cannot be deleted.
  • ApplicationRoleManager can manage system users and application roles (both the modeled roles and the security roles).
  • ProcessExecutor has access to end-user features.
  • ProcessManager can manage model instances.

To-Do Management

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.

Delegation

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.

Escalation

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

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.

Resetting

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.

Reassignment

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 and Exceptions

Logs

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.

Exceptions

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.