You can configure and monitor the LSPS Server via JMX or in the LSPS_SETTINGS database table and can be changed via JMX:
To check the health of the LSPS Application, open a JMX-compliant monitoring tool, such as JConsole, and check the attributes under com.whitestein.lsps.HealtCheck:
AverageMILockWaitTime and AverageOfLastTenMILockWaitTimes: total average and average of the last 10 waiting times when accessing model instances
Model instances run in a single thread and can be hence accessed by one entity at a time. While accessed, the instance is locked and other entities wait for the lock to be released: this time is used to calculate the average model-instance-lock wait time. when synchronizing model instances
NumberOfMaxLoopExceeded: the number of times that a loop exceeded the maximum allowed number of loop runs
The maximum number of loops is set by the MaxNumberOfEngineLoops setting.
LSPS configuration is generally stored in the LSPS_SETTINGS database table and can be changed directly in the database or via JMX. For some setting changes, the server needs to be restarted: the applicable information is provided with individual settings.
Note that some settings, such as debugging settings, are passed as system properties to the server, that is, in the format -Dkey=value
.
When true and the application server is configured to use SSO, the application checks if the current user exists in the application and is active when creating a new Vaadin UI.
Default setting: false
The setting is loaded on server startup and can be changed in the LSPS_SETTINGS table or via JMX. When changed via JMX, the database value remains unchanged.
Default setting: false
The setting is loaded on server startup and can be changed in the LSPS_SETTINGS table or via JMX. When changed via JMX, the database value remains unchanged.
Default setting: true
When changed in the LSPS_SETTINGS table, the change is reflected in runtime immediately.
SQL that returns IDs of model that should be loaded on server launch.
The setting is loaded only on server launch.
The setting is loaded on server launch and can be changed in runtime via JMX (When changed via JMX, the database value remains unchanged).
Default setting: false
Default setting: serialize
When changed in the LSPS_SETTINGS table, the change is reflected in runtime immediately.
A single execution step in a model instance is referred to as a loop: A loop moves tokens and checks repeatedly the status of various elements and data to make sure that the data, such as goal statuses, is correct when the loop finishes.
If the loop ends up in an infinite loop, for example, if one condition is switched from true to false within the loop continuously, the server terminates the looping based on the MaxNumberOfEngineLoops and ThresholdNumberOfEngineLoops setting:
Default setting: false
On change, restart the server to apply the change.
Default setting: 600000 (10 minutes)
Note: You can access the user-activity data through the UserTrack shared record.
Interpretation strategy of the LSPS Execution Engine
Default setting: FULL_PARALLEL
The setting is loaded on server startup and can be changed in runtime via JMX (When changed via JMX, the database value remains unchanged).
The smallest interval for sending a timed trigger in milliseconds. If there are multiple time notifications scheduled for a Model instance (for example, by multiple Timer Intermediate Events), and the time difference between the notifications is smaller that the TIMER_INTERVAL value, the notifications are merged into one (multiple Timer Intermediate Events are notified by a single timer notification)
If set to 0, timer notifications are not merged.
Default setting: 0
The setting is loaded on server startup and can be changed in runtime via JMX (When changed via JMX, the database value remains unchanged).
Availability of Hibernate statistics (equivalent of hibernate.generate_statistics
)
The option is by default disabled. You can enable it from JConsole: you can enable the setting for individual modules from the MBeans tab under com.whitestein.lsps > Statistics > MODULE > Attributes > StatisticsEnabled. To enable the setting for the entire application, modify the server.properties file in the application EAR (lsps-app-ear/lsps-app-ejb.jar/server.properties
)
Do not enable the setting in production environments since it can cause performance issues.
If set to true, model instance state is dumped when an exception occurs. The setting is loaded on server startup and can be changed in runtime via JMX (When changed via JMX, the database value remains unchanged).
Default setting: false
The setting defines whether events that occur during model-instance execution are logged. The events include such information as when the model and process started, when a process elements was executed, etc.
They are stored in the LSPS_PROCESS_LOGS system-database table. The data is used, for example, by views in the Management Perspective and Management Console.
Note: If you are looking for information on other logging mechanisms, please, refer to FAQ
Possible values:
MODULE
: the setting of the module is respected.YES
: process logs are created for all modules regardless of the Create process log module setting.NO
: process logs are not created for any modules regardless of the Create process log module setting.Default setting: MODULE
To clean old entries from the process log, use the delete-old-process-logs.<DB_NAME>.sql
script available in <LSPS-RUNTIME>/scripts/lsps/<YOUR_DB>/
Important: If you set the property to
NO
, information about model-instance status and execution history, such as, when a model instance started, a to-do was submitted, timer event triggered, etc. will not be available. As a result:
- Model Instance details in the Management Perspective and Management Console will not be available.
- BAM reports might not contain correct data.
Number of lines before and after the statement with the problem included in the stack trace (0 means all: the entire expression is returned). The setting is loaded on server startup and can be changed in runtime via JMX (When changed via JMX, the database value remains unchanged).
Default setting: -1
Note: You can display SQL statements issued by Designer to the server in the console to troubleshoot the statements. Refer to information on performance tuning.
Important: In production, the debugging parameters must not be active.
The debugging parameters are passed as JVM properties -Dkey=value
.
If true, the modeling ID set on form components is used as Vaadin debug ID on all Vaadin components.
If true, the Execution Engine runs in debug mode (usually activated in combination with remote socket debugging).
If set to true
, profiler is enabled.
LSPS uses the authentication mechanism of the underlying application server. The users are authenticated against the LSPSRealm.
If you want to authenticate users against other directory services, modify the configuration of your application server.
For example, to authenticate against LDAP in WildFly, add another login module to the security domain.
Note that you need to make sure that all persons from your directory service have their counterpart in the LSPS: For example, insert a new person to the LSPS using the web service API. Similarly, remove any removed persons.
Example WildFly login module configuration
<subsystem xmlns="urn:jboss:domain:security:1.1"> <security-domains> <security-domain name="lspsRealm" cache-type="default"> <authentication> <login-module code="com.whitestein.lsps.security.jboss.LSPSRealm" flag="optional" module="com.whitestein.lsps.security"> <module-option name="password-stacking" value="useFirstPass" /> <module-option name="dsJndiName" value="/jdbc/LSPS_DS" /> </login-module> <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="optional"> <module-option name="password-stacking" value="useFirstPass" /> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory" /> <module-option name="java.naming.provider.url" value="ldap://myurl:111" /> <module-option name="bindDN" value="cn=SA_LDAPReadOnly,ou=Service Accounts,dc=uss,dc=net" /> <module-option name="bindCredential" value="passwd" /> <module-option name="baseCtxDN" value="ou=INCOMM,dc=uss,dc=net" /> <module-option name="baseFilter" value="(sAMAccountName={0})" /> <module-option name="rolesCtxDN" value="ou=INCOMM,dc=uss,dc=net" /> <module-option name="roleFilter" value="(sAMAccountName={0})" /> <module-option name="roleAttributeID" value="memberOf" /> <module-option name="roleAttributeIsDN" value="true" /> <module-option name="roleNameAttributeID" value="cn" /> <module-option name="parseRoleNameFromDN" value="false" /> <module-option name="allowEmptyPasswords" value="false" /> <module-option name="searchScope" value="SUBTREE_SCOPE" /> <module-option name="allowEmptyPasswords" value="false" /> <module-option name="throwValidateError" value="false" /> </login-module> <login-module code="org.jboss.security.auth.spi.RoleMappingLoginModule" flag="optional"> <module-option name="rolesProperties" value="../standalone/configuration/roles.properties" /> <module-option name="replaceRole" value="false" /> </login-module> </authentication> </security-domain>