Operations Guide

ACTICO Platform - Workplace Operations Guide

Version 3.8.0-R107

© ACTICO GmbH. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights. Operations Guide

Table of Contents

Introduction ...... vi 1. Audience ...... vi 2. Content ...... vi 1. Overview ...... 1 1.1. High Level Deployment Diagram ...... 1 1.2. Runtime Environment Deployment View ...... 2 2. Installation ...... 3 2.1. Installation of ACTICO Workplace Web Application ...... 3 2.1.1. Installation of Database ...... 3 2.1.1.1. MySQL required Server System Variables ...... 3 2.1.2. Execution as standalone application ...... 3 2.1.2.1. Installation ...... 3 2.1.2.2. License File ...... 4 2.1.2.3. Logging ...... 4 2.1.2.4. Configuration ...... 4 2.1.2.5. Operating System Service Integration ...... 4 2.1.2.6. Execution ...... 4 2.1.2.7. Shutdown ...... 4 2.1.2.8. Embedded Webserver ...... 5 2.1.3. Execution within an application server ...... 5 2.1.4. Connection Pool Configuration ...... 5 2.1.5. Cluster Setup ...... 6 2.1.6. Search Index Location ...... 6 2.1.7. Security ...... 6 2.1.8. Authentication and Authorization ...... 6 2.1.8.1. Embedded Authentication ...... 7 2.1.8.2. LDAP and Active Directory Authentication ...... 7 2.1.8.3. LDAP Synchronization ...... 7 2.1.8.4. Remote API Authentication ...... 9 2.1.8.5. Spring Boot Actuator Web API Authentication ...... 9 2.1.9. Add-ons ...... 9 2.1.9.1. Add-on Folder Structure ...... 10 2.1.9.2. Add-on Configuration ...... 11 2.1.10. Other ...... 11 2.1.10.1. Browser-Based Spell Checking ...... 11 2.2. Installation of ACTICO Workplace Batch Application ...... 12 2.2.1. Installation ...... 12 2.2.2. Logging ...... 12 2.2.3. Configuration ...... 12

2.2.4. Operating System Service Integration ...... 12 2.2.5. Execution ...... 12 2.2.6. Shutdown ...... 12 2.2.7. Detailed Configuration ...... 13 2.2.7.1. General Parameters ...... 13 2.2.7.2. Connection Pool Configuration ...... 14 2.2.7.3. Spring Batch Job Configuration ...... 14 2.2.7.4. Transaction Configuration ...... 14 2.2.7.5. Thread Pool Configuration ...... 14 2.2.8. Starting and Stopping a Scheduler Process as Background Process ...... 15 2.2.8.1. Configuration Parameters for the Scheduler ...... 15 2.3. Installation of ACTICO Workplace Runtime API Maven Artifacts ...... 16 3. Operations and Maintenance ...... 17 3.1. Jobs ...... 17 3.1.1. User Maintenance Job ...... 17 3.1.2. Watchdog Job ...... 17 3.1.3. Stale Locks Removal Job ...... 17 3.1.4. Search Index Commit Job ...... 17 3.2. Logging ...... 17 3.2.1. Minimizing Log Messages ...... 18 3.2.2. Rules Services, Actions and Functions Exception Interceptor ...... 18 3.2.3. Web Layer ...... 18 3.2.4. Background Processes ...... 18 3.2.4.1. Quartz Scheduling ...... 18 3.3. Monitoring ...... 19 3.3.1. Endpoints ...... 19 3.4. File System ...... 19 3.4.1. Open Files ...... 19 3.4.2. Lucene Search Index ...... 20 3.4.2.1. Dealing with Stale LuceneIindex Locks ...... 20 3.4.2.2. Additional Lucene Index Logging ...... 20 3.4.2.3. Index Viewer Tool ...... 20 3.4.2.4. Experimental Feature: Search Index Verification ...... 20 3.5. Caching ...... 21 3.5.1. Rule Models ...... 21 3.6. Distributed Search Index ...... 21 3.7. Load Balancing ...... 22 3.8. Temporary Directories ...... 22 3.9. Document Migration ...... 22 3.10. Backup and Restore ...... 22 3.10.1. Database Backup and Restore ...... 22

3.10.2. Data Folder and Lucene Index Backup and Restore ...... 22 3.10.2.1. Backup steps ...... 22 3.10.2.2. Restore steps ...... 23 4. Security Information ...... 24 5. Troubleshooting ...... 28 5.1. Code Cache Size ...... 28 6. Technical Limitations ...... 29 A. Application Server ...... 30 A.1. Deployment to an Application Server ...... 30 A.1.1. Configuration and Logging ...... 30 A.1.2. Database Connection ...... 30 A.1.3. Java Virtual Machine (JVM) Configuration ...... 30 A.1.4. Resources and Libraries ...... 31 A.1.5. JBoss Deployment ...... 31 A.1.6. Tomcat Deployment ...... 32 A.1.7. Weblogic Deployment ...... 32 A.1.8. Application Server Shutdown ...... 32 B. Configuration Files ...... 33 B.1. Web Application Configuration ...... 33 B.2. Batch Application Configuration ...... 40

Introduction

This document describes the installation and operation of ACTICO Workplace.

1. Audience

This document is intended for

• System Administrators

• Database Administrators

2. Content

This document considers the following topics

• Installation

• Maintenance

Chapter 1. Overview

1.1. High Level Deployment Diagram

An overview deployment diagram shows an example setup that consists of a Development, Test and Production environment. The rule models sources are stored within the ACTICO Team Server.

1.2. Runtime Environment Deployment View

The following diagram shows an example setup of one environment. It shows a cluster that contains two nodes on different servers and a batch component. All share the same database schema.

Chapter 2. Installation

2.1. Installation of ACTICO Workplace Web Application

2.1.1. Installation of Database

Database User. Please ask your database administrators for a database schema and a user. The user needs to have rights to create tables, indexes, views, synonyms and triggers.

Database Setup. Execute the initial database script for the chosen database brand in this order:

1. workplace--database-create.ddl (Only for MsSQL and MySQL)

2. workplace-.ddl

3. workplace--executioncore.ddl

4. workplace--batch.ddl

5. workplace--initial-user.sql

Workplace also provides a H2 database for demonstration purposes. The H2 database is included in the web application and automatically started and setup at server startup. Do not use on production

Microsoft SQL Server needs to be configured with case insensitive collation (CI) and Isolation Level READ_COMMITTED_SNAPSHOT.

2.1.1.1. MySQL required Server System Variables

To get MySQL working the follwing Server System Variables are required. See the official MySQL documentation for further information.

• --max-allowed-packet=67108864

• --character-set-server=utf8mb4

• --lower-case-table-names=1

• --sql_mode='oracle'

• --explicit-defaults-for-timestamp=true

2.1.2. Execution as standalone application

Workplace Web Standalone Application requires a Java Runtime Environment.

2.1.2.1. Installation

Unzip the file workplace-webapp-.zip.

The app folder contains

• the WAR file of the web application

The config folder contains

• the workplace-web-application.properties file that is used to store configuration settings

• the log4j2.xml file that is used to configure the logging

The bin folder contains preconfigured scripts for the web application.

The ${workplace.data.folder}, logs and work folders are created when the application starts. They contain dynamic content.

In addition to the WAR file all resources in the config folder are automatically on the classpath of the application. Place additional files, like JDBC driver JAR files, in the config/lib directory.

2.1.2.2. License File

Copy your obtained license file to one of the following folders:

• ${user.home}/.actico/config/license

• config/license

2.1.2.3. Logging

The xml file log4j2.xml needs to be stored in the same folder as the WAR file of the web application. It is used to configure the logging behaviour of the web application.

2.1.2.4. Configuration

The file workplace-web-application.properties is used to configure the web application. The specific configuration settings are described in the next chapters.

2.1.2.5. Operating System Service Integration

The web application also contains preconfigured scripts to install, start, stop and uninstall the application as a Windows service. Use the install-service.bat, start-service.bat, stop-service.bat and uninstall-service.bat scripts for this purposes.

The config.bat file contains a configuration section. Configure the given environment variables accordingly.

To overwrite specific configuration settings of the bin\windows\config.bat file, create a file config.bat in the config folder. It will be execute before the config.bat file in the bin folder.

The script environment supports additional configuration modes for the application. A configuration mode adds additional settings to operating system environment variables that were preconfigured by the config.bat script. To add a new configuration mode create a new file with the following filename schema: config-newmode.bat. Configure the settings inside the created file. The file will be executed automatically if you pass newmode as a command line argument for a script file. Note that this mechanism also works for start and stop scripts of the appplication.

2.1.2.6. Execution

On a Windows system use the start-app.bat and stop-app.bat scripts for this purpose. On a Linux system use the start-app.sh and stop-app.sh scripts. If specific configuration is necessary, configure the environment variables in the mentioned start scripts accordingly.

In a production environment it is recommended to install the web application as a system service. On a Windows system use the install-service.bat file to install the web application as a service and use start-service.bat or any operating system mechanism to start the service.

2.1.2.7. Shutdown

Always properly shutdown the web application. This is important for files to be closed (e.g. search index).

If the web application was started with start-app.bat or start-app.sh it should be stopped with stop- app.bat or stop-app.sh.

If the web application was installed as a Windows service, the stop-service.bat file or any operating system mechanism to stop a service normally can be used.

Background Information:

• The web application is looking for a stop file that is created in a configured folder with a configured filename. If the file is detected, the web application will start the shutdown process and will terminate. The stop flag file is configured using the --actico.stopfile command line argument. The --actico.stopfile.initsleep command line argument can be used in order to specifiy a sleep time in seconds. The application waits for this duration until it looks for a stop flag file. Use this argument to prevent a shutdown during the startup phase of the application. Finally the -- actico.stopfile.jvmshutdown command line argument can be used to simply create the stop flag file, that signals an already running JVM to terminate.

• Use the --actico.stopfile and --actico.stopfile.initsleep command line argument for the web application itself.

• Use the --actico.stopfile and --actico.stopfile.jvmshutdown command line argument to initiate the termination of an already running web application. Note that the stop flag file handling is preconfigured in all provided scripts.

2.1.2.8. Embedded Webserver

The web application contains an embedded Tomcat servlet container. The embedded webserver can be configured with the following options:

Property Description

tomcat.standalone.displayName Configures the display name of the embedded Tomcat servlet container.

tomcat.standalone.httpPort Configures the port for the http connector of the embedded Tomcat servlet container. Can be used in addition to the ssl connector.

tomcat.standalone.httpsPort Configures the port for the ssl connector of the embedded Tomcat servlet container. Can be used in addition to the http connector.

tomcat.https.keyalias Name of the alias that was used for the certificate in the keystore.

tomcat.https.keystore.path Path to the ssl keystore, containing the certificate. If /workplace_keystore.jks is used, the file is searched in the folder of the WAR file.

tomcat.https.keystore.password The password of the ssl keystore.

2.1.3. Execution within an application server

The preferred way is to execute the Workplace Web Application as standalone bundle. But it is also possible to run the web application within an application server. Further information can be found in the appendix chapter of this document. In this case the preconfigured scripts are not relevant.

2.1.4. Connection Pool Configuration

Workplace uses Hikari Connection Pool to manage database connections, if Spring profile direct is used. The configuration file app/workplace-web-application.properties contains properties to configure the connection pool. All connection pool specific properties are prefixed with db.datasource.direct. Please refer to the official Hikari Documentation and configuration properties overview for detailed explanations for each property. The table in chapter Connection Pool Configuration shows the mapping between the properties from workplace-web-application to Hikari configuration properties.

2.1.5. Cluster Setup

Cluster Setup does not need any special configuration. Any node connected to the same database takes part in the cluster. The node is registered automatically during startup. The registration information is stored in the file system inside ${workplace.data.folder}/cluster/.

User sessions (Web sessions): The load balancer or any other up-front server needs to be configured to use sticky sessions, sometimes referred to as session affinity, (a particular user is always delegated to the same node). Session replication between cluster nodes is not supported.

You can use an external load balancing component with the web application to handle sticky sessions and to redirect users based on their session to the cluster nodes.

If nodes are hosted on separate machines, their clocks have to be synchronized closely. The clocks must be within a second of each other (Requirement by Quartz Scheduler library). This also includes the database server.

2.1.6. Search Index Location

Besides storage of documents in the database, Workplace also stores the latest revision of each document in a search index. This redundant storage enables a fast search functionality. The search engine is embedded in Workplace. The search index is stored in the file system of each cluster node.

2.1.7. Security

It is recommended to only allow SSL connection (https://) and to enable the following properties in the workplace-web-application.properties on a production environment: web.cookie.httpOnly=true web.cookie.secure=true

2.1.8. Authentication and Authorization

Workplace has three authentication possibilities:

• Embedded against the database used by Workplace

• Active Directory

• LDAP

The chosen mode can be setup using the property spring.profiles.active within the configuration file application.properties Authorization is always done embedded. The following configuration options are available independent on the chosen configuration mode:

Property Description

auth.rememberme.enabled This will enable/disable the 'remember me' feature allowing to store authentication data within the browser (by means of a cookie). The user then has to login once and will be remembered by the application for successive sessions (provided that the user does not deliberately logout).

crrp.authentication.change.password.enabled Configures if users will be able to change their own password. It should be disabled if the user is authenticated against LDAP or AD.

Property Description

crrp.authentication.login.enabled When using single sign on, the "login" screen can be disabled (hidden). Note: Enabling single sign on requires customization of the web application.

crrp.authentication.logout.enabled When using single sign on, the "logout" functionality can be disabled. Note: Enabling single sign on requires customization of the web application.

2.1.8.1. Embedded Authentication

The default user of the Workplace Web Application is Admin. The password is also Admin. Please make sure to change the user’s password immediately after the installation. Passwords of users are hashed and stored in the database table IM_USER. Hashes are calculated with BCrypt. For further information about the BCryptPasswordEncoder please see Spring documentation. A User Maintenance Job can be enabled to, for example, lock users that have not changed their password for a certain time or to notify them to change their password in the next couple of days.

2.1.8.2. LDAP and Active Directory Authentication

Connection to any LDAP Server can be configured by the properties starting with ldap within the configuration file workplace-web-application.properties. Multiple servers (separated by spaces) can be defined. If the first one is not reachable, the next one is used. The format of an URL is "ldap://server:389/base_dn". The base_dn must be the same for all URLs. Certain restrictions apply to the supported directory structure:

• LDAP groups should use the "member" or "memberUid" attribute to specify user ids or user DNs.

• Nested LDAP groups are not supported.

• LDAP users should have an attribute "uid" or "sAMAccountName" which matches the user name in Workplace.

An example for a nested LDAP group is:

• group A with member B

• group B with member John

• Workplace will only assign the ROLE_B to John!

2.1.8.3. LDAP Synchronization

It is possible to synchronize LDAP data into the embedded user management (Workplace database). The synchronization is done frequently (e.g. every night) and can also be triggered from the User Management -> Roles -> Start LDAP sync job. Each Workplace user will be synchronized with their respective LDAP user. The following data can be synchronized:

• User to Role Mapping: When enabled, the user to role mapping is retrieved from the LDAP. Any mapping that does not exist within LDAP is removed. A manual assignment can not be done.

To enable this feature, add and adjust the following properties to the workplace-web- application.properties: # Enable synchronize job to synchronize LDAP entries into the Workplace database # This also defines if the synchronization button is shown within the User Interface # - enabled: Defines if the job should run (Default: false) # - frequency: Execute LDAP synchronization job in background

# Default: 0 0 3 * * ? (every night at 3am) # - run.as.UserName: User for audit log entries when synchronization job performs changes (Default: Admin) ldap.sync.enabled=true ldap.sync.frequency=0 0 3 * * ? ldap.sync.run.as.UserName=Admin

# One functionality of the synchronization job is to map the roles of a user from LDAP into the database # - enabled: Default: false. Please note that the sync mechanism needs to be enabled in this case # - groupsOU: path where groups are defined # - groupsSearchFilter: LDAP search criteria to search for members of the group, defaults to (|(member={0})(memberUid={1})(uniqueMember={0})) ldap.sync.userRoleMapping.enabled=true ldap.sync.userRoleMapping.groupsOU=ou=Groups #ldap.sync.userrolemapping.groupSearchFilter=(|(member={0})(memberUid={1}) (uniqueMember={0}))

• User attribute mapping: If LDAP synchronization is enabled this functionality can not be disabled. User attribute mapping retrieves the attributes "fullname", "description", "department", phoneNumber" and "eMailAddress" from LDAP and writes this information to the respective user. If an attribute of a user can not be found in LDAP the existing values are not overwritten. In this case a warning message will be logged.

To configure this feature, adjust the following properties in the workplace-web-application.properties file:

# Another functionality of the synchronization job is to map the attributes of a user from LDAP into the database # Please specify the names of the fields in your LDAP below. # - fullname: Name of the field in your LDAP which contains the full name of the user # - description: Name of the field in your LDAP which contains the description of the user # - department: Name of the field in your LDAP which contains the department of the user # - phoneNumber: Name of the field in your LDAP which contains the phone number of the user # - eMailAddress: Name of the field in your LDAP which contains the Email address of the user ldap.sync.userAttributeMapping.fullname=displayName ldap.sync.userAttributeMapping.description=description ldap.sync.userAttributeMapping.department=departmentNumber ldap.sync.userAttributeMapping.phoneNumber=homePhone ldap.sync.userAttributeMapping.eMailAddress=mail

• Automatic creation of users: This function creates users which exist in LDAP but not in the applications' database. New users are created either on their first log-in or with the next LDAP synchronization job, depending on which event occurs first. Users are created on their first log-in if they are successfully authenticated via LDAP and do not yet exist in the applications' database. Users are created during the LDAP synchronization job if they match the provided LDAP userFilter inside the previously defined users path (see property ldap.usersOU). The synchronization maps the username to the LDAP field specified by the property ldap.userNameAttributes=uid,sAMAccountName.

User Role Mapping should be enabled, otherwise the necessary roles will not be assigned to the newly created users.

To configure this feature, adjust the following properties in the workplace-web-application.properties file:

# Users which exist in LDAP but not in the applications' database can be created automatically. # - enabled: Users which do not exist in the applications' database will be auto-created

# on their first log-in or with the next synchronization job. (Default: false) # - userFilter: LDAP filter to use for selecting desired users inside the users path. # - userNameField: Name of the field in your LDAP which contains the user name (uid|sAMAccountName) ldap.sync.autocreateUsers.enabled=true ldap.sync.autocreateUsers.userFilter=objectClass=person

2.1.8.4. Remote API Authentication

The Remote API requires Basic Authentication.

2.1.8.5. Spring Boot Actuator Web API Authentication

The Spring Boot Actuator Web API requires Basic Authentication in the requests. Note that the info and health endpoints does not require any authentication. They can be used to test if the application is up and running. The shutdown endpoint requires the permission PERM_SYSTEM_SHUTDOWN. All other endpoints require the permission PERM_SYSTEM_ADMIN. Detailed information about the actuator endpoints can be found in the Spring Boot Actuator Web API Documentation of Spring.

2.1.9. Add-ons

Workplace provides the possibility to automatically deploy and upload files with the Add-on Feature. Separately developed Add-ons can be created and integrated. The possible files to be installed are:

• Rule Models

• Database Scripts

• Report Projects

• Document Printout Projects

Only database scripts for h2 are supported. Scripts for other databases need to be executed manually by a database administrator.

Workplace includes the following Add-ons:

Add-on Name Content

Commons Contains for example flow rules for Exception Handling, Diary and Search.

Standard Rule Models that are ready for production. It is expected that changes to those rule models only need to be done in rare cases and that they can be used as is.

EURent An example use case that shows an integrated case touching a lot of features of Workplace.

Examples Example rule models that target a specific aspect. E.g. the SimpleTableElement, the GridElement, or a Search Rule Model.

2.1.9.1. Add-on Folder Structure

Add-ons can be activated by the following JVM Parameters:

JVM Parameter Valid Values Description

-DInstallWithoutWizard true, false If set to true, everything will be installed without any user interaction.

If set to false, the administrator can log in and choose the files to be installed. H2 Database scripts cannot be installed in this mode.

-DInstallOptional all Optional files will also be installed with the setting - DInstallWithoutWizard=true. Optional files are rule models, document_printouts and reports.

-DAddOnFolder file:/ or classpath:/ Path to the base folder containing one or more Add-ons. Use the "?" character to encode spaces.

Example: set VM_PARAMS = -DInstallWithoutWizard=true \ -DInstallOptional=all \ -DAddOnFolder=file:/../../all-add-ons

The add on folder is preconfigured in the script config.bat. The InstallWithoutWizard and InstallOptional JVM Parameters are also preconfigured for the script environment in the script config-preinstall.bat. Use the preinstall command line argument to activate these options. The structure of an Add-on is shown in the following example. It shows two Add-ons “Customer” and “Examples” in the base folder my_add_ons:

The installation order is:

• Primary: Order by type (first database, rulemodels, document_printouts, and last is report)

• Secondary: Ordered by name, ascending

There is no defined order between Add-Ons themselves if multiple Add-Ons are available.

2.1.9.2. Add-on Configuration

The addon.properties will be merged with the add-on.description file in the future.

Content of add-on.description and addon.properties:

Property Description

rulemodel.assignall.torole Assigns all rule models to a specific role. (Currently this needs to be specified within addon.properties)

rulemodel.activate.stateflow Activates this stateflow.

h2.check.query This query checks if the SQL scripts are already executed against this database. If the query fails, the SQL scripts included in the Add-On are executed. If the query succeeded, the system assumes that the database is already up to date for this Add-on.

Example. The scripts creates the table MY_LOOKUP. A good check query would be

• SELECT 1 FROM MY_LOOKUP

• SELECT 1 / Count(*) FROM IM_PERMISSION where NAME='MY_PERM' (creates a Div by Zero Exception if MY_PERM does not exist.

2.1.10. Other

2.1.10.1. Browser-Based Spell Checking

To enable browser-based spell checking in your browser, please visit the browser manufacturer's website. The following list provides some hints for different versions:

• In Google Chrome (version 42.0) spell-checking works out-of-the-box. In order to select your desired spellchecking language, go to "Customize and Control Google Chrome" -> "Settings" -> "Show advanced settings..." -> "Language and input settings...". Now you can select your desired language. After having selected a language, click on "Use this language for spell checking".

• In Mozilla Firefox (version 37.0.2) spell-checking has to be enabled by a third-party extension. Go to "Open menu" -> "Add-ons" -> "Get Add-ons". On the right hand side, you can search for add-ons. Type in "dictionary" and press enter. Now you can install your desired dictionary (e.g., German Dictionary or British English Dictionary) by clicking on "Install". After that, click on "Restart now". To enable the dictionary (i.e., British English Dictionary), right-click in a multi-line text box and select "Check Spelling" (or "Languages", then "English/United Kingdom").

• In Internet Explorer spell-checking works out-of-the-box. In order to select your desired spell-checking language, go to your Windows control panel and change the language. This step may vary depending on your Windows version (e.g., Windows XP/Vista/7/8/10).

2.2. Installation of ACTICO Workplace Batch Application

2.2.1. Installation

Unzip the file workplace-batch-application-.zip. The app folder contains

• the JAR file of the batch application

The config folder contains

• the workplace-batch-application.properties file that is used to store configuration settings

• the log4j2.xml file that is used to configure the logging

The bin folder contains preconfigured scripts for the batch application. The ${workplace.data.folder}, logs and work folders are created when the application starts. They contain dynamic content. In addition to the JAR file all resources in the config folder are automatically on the classpath of the application. Place additional files, like JDBC driver JAR files, in the config/lib directory.

Clustering is not supported for Workplace Batch Application. Please make sure that only one instance is started.

2.2.2. Logging

The xml file log4j2.xml needs to be stored in the same folder as the JAR file of the batch application. It is used to configure the logging behaviour of the batch application.

2.2.3. Configuration

The file workplace-batch-application.properties is used to configure the batch application. The specific configuration settings are described in the next chapters.

2.2.4. Operating System Service Integration

The batch application also contains preconfigured scripts to install, start, stop and uninstall the application as a Windows service. Use the install-service.bat, start-service.bat, stop-service.bat and uninstall-service.bat scripts for this purposes. The install-service.bat file contains a configuration section. Configure the given environment variables accordingly.

2.2.5. Execution

The batch application contains preconfigured scripts in order to start and stop the application without any service installation. On a Windows system use the start-app.bat and stop-app.bat scripts for this purpose. On a Linux system use the start-app.sh and stop-app.sh scripts. If specific configuration is necessary, configure the environment variables in the mentioned start scripts accordingly. In a production environment it is recommended to install the batch application as a system service. On a Windows system use the install-service.bat file to install the batch application as a service and use start-service.bat or any operating system mechanism to start the service.

2.2.6. Shutdown

Always properly shutdown the batch application. This is important for files to be closed (e.g. search index).

If the batch application was started with start-app.bat or start-app.sh it should be stopped with stop- app.bat or stop-app.sh.

If the batch application was installed as a Windows service, the stop-service.bat file or any operating system mechanism to stop a service normally can be used.

The batch application uses the same stop file mechanism as the web application. Same command line arguments can be used. Scripts are preconfigured.

2.2.7. Detailed Configuration

2.2.7.1. General Parameters

The following configuration parameters can be set. The configuration file can be found in app/workplace- batch-application.properties

Property Description

daf.batch.default.client Define the client. At the moment only one client is supported. The value must be “Default”.

daf.batch.default.user Define the technical user name to execute batch runs. The user configured here needs to be available in the database.

chunk.processing.threads Define the number of threads which are used to process chunks in parallel. Please adjust according to your performance needs as well as the available resources on the machine. It highly depends on the environment for which value is appropriate and should be found through testing and monitoring system resources.

Please note that H2 database (not for production use anyway) does not support parallel DML statements very well. Therefore, it is not recommended to set this property to a value higher than 1 if H2 is used.

stop.job.after.failed.chunks Define a maximum number of allowed failed chunks for one BatchRun. If this number of failed chunks is reached, the framework will automatically stop the BatchRun in order to save resources and database space. A system operator can either retry the BatchRun or abort it via the batch administration screens included in the Workplace web application.

search.max.amount.unindexed.documents This threshold defines the maximum number of unindexed Documents before starting a Batch Run. If a Batch Run is about to be started and this threshold of unindexed Documents is reached, the Batch Run will not start, reporting a status of FAILED. Indexing process might take a long time if many Documents need to be indexed. This might significantly delay the scheduled start time for a BatchRun. Therefore, this threshold can be configured to let a Batch Run fail immediately if too many Documents are missing in the Search Index. Set to -1 to disable this feature (e.g. if you don’t interact with Documents in your batch rule models).

2.2.7.2. Connection Pool Configuration

Workplace uses Hikari Connection Pool to manage database connections, if Spring profile direct is used. The configuration file app/workplace-batch-application.properties contains properties to configure the connection pool. All connection pool specific properties are prefixed with db.datasource.direct. Please refer to the official Hikari Documentation and configuration properties overview for detailed explanations for each property. The following table shows the mapping of configuration properties from workplace-batch- application to Hikari configuration properties.

Hikari property Corresponding workplace property

connectionTestQuery db.datasource.direct.validationQuery

connectionInitSql db.datasource.direct.connectionInitSql

maximumPoolSize db.datasource.direct.maximumPoolSize

minimumIdle db.datasource.direct.minimumIdle

connectionTimeout db.datasource.direct.connectionTimeout

idleTimeout db.datasource.direct.idleTimeout

maxLifetime db.datasource.direct.maxLifetime

validationTimeout db.datasource.direct.validationTimeout

leakDetectionThreshold db.datasource.direct.leakDetectionThreshold

2.2.7.3. Spring Batch Job Configuration

The Batch Platform is based on Spring Batch. The default Spring Batch job and its steps are defined in the workplace-batch-job-config.xml file. This file is included in the workplace batch JAR file. Usually nothing needs to be changed here and the config can be used as-is.

2.2.7.4. Transaction Configuration

The transaction timeout when processing batch chunks can be configured by modifying the listed configuration property:

Property Description

chunk.transaction.timeout Transaction timeout in seconds.

2.2.7.5. Thread Pool Configuration

The parameters of the thread pool used for processing can be configured as properties of the bean bp.daf.chunkProcessingThreadPool.

Property Description

keepAliveTime Sets the time limit for which threads may remain idle before being terminated. Core threads are only terminated when this property is set to true.

allowCoreThreadTimeOut Enable thread timeout for core pool threads.

shutdownDelay Time in seconds for awaiting a shutdown after shutdown() was called.

chunk.processing.threads This can be configured in workplace-batch- application.properties. It defines the number of threads used for chunk processing.

Property Description

chunk.processing.queue.size This can be configured in workplace-batch- application.properties. It defines the maximum size of the processing queue.

2.2.8. Starting and Stopping a Scheduler Process as Background Process

The Scheduler Process (which is the batch application) automatically recognizes scheduled Batch Runs and triggers the appropriate Batch Process. Use the Workplace Web Application to schedule them.

To start as scheduler process, execute the following command: start-app.sh / start-app.bat

The process starts and won't terminate until it is stopped. Please refer to your Operating Systems documentation to find out how the process can be started as background process or how to move it to the background. Note that the preconfigured script start-scheduler.sh has already the appropriate configuration in place. As an alternative the batch application can be installed as an operating system service as already described.

Once the scheduler process is started, it starts polling the database periodically to determine if there are scheduled batch runs which should be executed. It also takes care to execute only one batch run at a time by default. If multiple batch runs are scheduled within an overlapping time frame, it executes these sequentially, starting with the earliest schedule Date.

The scheduler process also takes care of keeping the batch search index up-to-date.

If the batch process is started against a database that already contains many Documents, it might take a while to initially create the search index. The process logs the remaining Documents to index into the log file.

As soon as the Scheduler triggers a Batch Run, the Status of the corresponding Batch Run is changed to TRIGGERED.

If the scheduler process was started with start-app.sh / start-app.bat, it can be stopped by executing the following script: stop-app.sh / stop-app.bat

Executing this script will gracefully stop currently running Batch Runs and terminates the process. Therefore, it might take up to several minutes until the process terminates.

The scheduler is watching for the configured stop file in order to terminate. The folder and filename can be configured by modifying the start-app.bat / start-app.sh and stop- app.bat / stop-app.shscripts accordingly.

2.2.8.1. Configuration Parameters for the Scheduler

The scheduler can be configured using the following parameters. You can find them in app/workplace- batch-application.properties.

Property Description

scheduler.polling.interval.seconds Defines (in seconds) the frequency of the scheduler. After the interval defined here, the scheduler process polls the database to lookup Batch Runs to trigger.

scheduler.batchrun.timeout.seconds Defines (in seconds) the timeout for a Batch Run in execution. If a Batch Run is not finished after the defined number of seconds, the scheduler will set the status to FAILED and log appropriate message. The value -1 disables the timeout feature.

2.3. Installation of ACTICO Workplace Runtime API Maven Artifacts

Building Workplace Rule Models with Maven or the Team Server require dependencies that need to be added to the Maven repository. Those dependencies are:

• ACTICO Rules Dependencies as documented within the ACTICO Rules Documentation. Please follow the steps described in the Builder Guide in the Chapter "Using Maven".

• Workplace Dependencies are available as a separate ZIP file "Workplace Maven Artifacts". Installation is done in the same way as the ACTICO Rules Dependencies.

Chapter 3. Operations and Maintenance

3.1. Jobs

Workplace has several jobs that run periodically.

3.1.1. User Maintenance Job

Workplace provides the possibility to specify a job, that is used to maintain the status of the users. This job is executed frequently and iterates over all users. It can be used, for example, to lock users that did not change their password for a long time. The logic is individual and can be modeled within a rule model. See User Guide for more information about this rule model.

It can be configured with the property im.user.lock.status.job.frequency within the configuration file workplace-web-application.properties.

3.1.2. Watchdog Job

A watchdog job can be used to perform certain work on a regular basis. When the job is fired, the stateflow is called with a specific event id. The job can be configured by properties starting with watchdog within the configuration file workplace-web-application.properties.

3.1.3. Stale Locks Removal Job with properties starting with crrp.staleLocks within the configuration file workplace-web- application.properties.

3.1.4. Search Index Commit Job

Search index changes are written to the file system frequently. This can be configured with the property daf.lucene.indexWriterCommit.frequency within the configuration file workplace-web- application.properties.

This setting should usually not be changed.

3.2. Logging

Logging and tracing are used to monitor events and the control flow of processes within the application. Many components of the framework log informational messages to a logging facility. Each component can be configured for different levels of logging. The levels of logging are: DEBUG, INFO, WARNING and ERROR. For tracing purposes, the logging level is often set to DEBUG for certain central components. In a production environment, setting the logging level to a higher level, such as INFO or WARNING is not recommended due to performance reasons - logging has an impact on the throughput and efficiency of the system.

Log4j 2 is used as the implementation. Log4j 2 provides extension points where logging destinations, such as files or databases, can be configured independently.

Please check the log4j 2 documentation on how to configure the logging configuration file.

Loggers can be defined to control each component or group of components and set independent severity and log levels. The next chapters will describe certain parts of the framework and classes which may log important information for troubleshooting purposes.

3.2.1. Minimizing Log Messages

Many components log information which may not be important from a system administration's point of view. Once the application is in production, certain log information can be reduced to minimize logging overhead. When rule models are modelled without using constants for internationalization of UI labels, the I18N Component of the framework will log WARNING messages for each key not found. As this depends on whether I18N (or L10N) is needed for a custom solution, the messages may be ignored by system administrators as they are only relevant for rule modelers. To disable these WARNING messages, add the following configuration fragment to log4j2.xml Loggers:

Since we have no control over log messages of other 3rd party libraries, it is suggested that the following classes be set to log level ERROR. Those classes log a few WARNING messages that are known to not affect the stability of the system.

• org.apache.wicket.Localizer

• org.apache.wicket.markup.repeater.AbstractRepeater

3.2.2. Rules Services, Actions and Functions Exception Interceptor

The following entry in the log4j2.xml will enable debug logging for exceptions passed from ACTICO Rules actions, services, and functions back into rule models. If those exceptions are caught in the rule models but are not logged, there is no way otherwise to see those exceptions in the server log to analyze potential problems.

3.2.3. Web Layer

Enable DEBUG logging for Spring Security's HttpSessionEventPublisher to log session creation and destruction events. Add a new or change the existing logger element in log4j2.xml:

Enable DEBUG logging for Spring's XmlWebApplicationContext to see all Application Context events, including the HTTP Session events. Additionally, the application events such as startup, shutdown and refresh (for redeployments) are logged. Add a new or change the existing logger element in log4j2.xml:

3.2.4. Background Processes

There are multiple background jobs running in the framework. As background jobs are not triggered by user interaction, the only way of communication for the job is to log events. The following chapters describe background processes run by the framework and what type of messages they are logging.

3.2.4.1. Quartz Scheduling

The Quartz Scheduling Service executes tasks which are created by rule models. Rule models may create arbitrary numbers of tasks to be executed at configurable schedules or intervals.

When a task is executed, that is a trigger for a task is fired, the service will log Trigger ... is firing. When a task throws an error, the service will catch the error and log An error occurred during job execution, including a full stack trace of the original cause.

3.3. Monitoring

To monitor the application, Spring Boot's Actuator Web API is enabled. The endpoints can be accessed at http://:/application/.

Please check the Spring Boot Actuator Web API documentation for further information.

3.3.1. Endpoints

The following endpoints are enabled by default:

• info - Display application name and version

• health - Display health status of application (database, disk space)

• env - Display property environment configuration

• configprops - Display configuration settings

• threaddump - Display current thread dump

• heapdump - Provide heap dump as downloadable file

• mappings - Display servlet mappings

• httptrace - Display http request trace

• beans - Display beans of started Spring application context

• conditions - Display match state of Spring Boot's conditions

• loggers - Display logger configuration

• metrics - Display application metrics

• caches - Provide cache operations

• shutdown - Shutdown the application (HTTP POST request)

The endpoints info and health do not require any permission. The endpoint shutdown requires the permission PERM_SYSTEM_SHUTDOWN. All other endpoints require the permission PERM_SYSTEM_ADMIN. Example call using POST:

$ curl 'http://localhost:8050/application/shutdown' -i -X POST

The produced response looks like:

HTTP/1.1 200 OK Content-Length: 41 Content-Type: application/vnd.spring-boot.actuator.v2+json;charset=UTF-8 { "message" : "Shutting down, bye..." }

3.4. File System

3.4.1. Open Files

The number of open files can be large, especially with a higher load on the server. For instance, the Lucene search index creates many small files during the indexing phase. The maximum number of files that can be

Copyright © ACTICO GmbH 19 Chapter 3. Operations and Maintenance opened at the same time depends on the operating system. In a Linux-based system, one can increase the maximum number of open files with the command ulimit -n.

3.4.2. Lucene Search Index

Apache Lucene is used to index documents for faster document queries. Lucene uses a file system locking mechanism to control the access to the index. Each process (e.g., web application cluster node, batch) keeps its own Lucene index file.

3.4.2.1. Dealing with Stale LuceneIindex Locks

In case of an enforced application shutdown (i.e., kill -9 on Linux systems, which is not recommended) or server failures, it might happen that a stale Lucene lock remains in the Lucene index directory. A stale Lucene lock prevents the application from indexing documents and can result in incorrect application behavior and an inconsistent search index. Therefore, on application startup the application checks for a stale lock in the Search Index directory. If it cannot grab the lock, the application will wait for a specific time and try again. The default time is 60 seconds and can be configured with the property daf.lucene.staleLockCheckTime. Once the timeout is reached the application will remove the stale lock automatically.

The lock itself is located in the file system inside ${workplace.data.folder}/lucene-index/lockDir/. It can be deleted if it can be made sure that no process accessing the index is running.

3.4.2.2. Additional Lucene Index Logging

Additional logging regarding adding new entries to the index journal table and the indexing of documents (both modification as well as deletion) can be enabled by adding the following to the log4j 2 config:

3.4.2.3. Index Viewer Tool

The tool Luke can be used to read the Lucene index, e.g., for debugging reasons. It is comparable to a SQL tool to view the database content. The tool Luke is not delivered, supported, or maintained by ACTICO. Make sure the index is not changed by using this tool as no warranty is given. It can be downloaded here. Documentation can be found here.

3.4.2.4. Experimental Feature: Search Index Verification

The Quartz job to continuously verify the Lucene index is disabled by default and can be enabled by setting the preference experimental.index.verify.job.enabled to true. The verification will run continuously for the newest revisions and nightly for all documents and verify the index regarding:

• Document in database is missing in index.

• Document in index does not exist in database.

• Revision of document is not consistent between database and index.

The found inconsistencies will be corrected automatically and logged in the table DAF_INDEX_VERIFY_PROTOCOL. The job can be configured by the following properties in workplace-web- application.properties:

Property Description

daf.index.verify.frequency.newest When to check for newest documents.

daf.index.verify.frequency.complete When to do a complete check of all documents.

Property Description

daf.index.verify.lucene.pageSize How many documents to load from Lucene in one block

daf.index.verify.secondsSinceLastChange How old a document has to be before being considered for the verification.

daf.index.verify.maxHistoryDays Set to 0 to disable the deletion of old history entries.

daf.index.verify.maxUnindexed maximum number of documents being unindexed when the job is running, set to 0 to disable this check.

3.5. Caching

For performance reasons, each node in a cluster uses caches to speed up queries. For a short period, the cached information might be obsolete (this does not affect documents; they are not cached). Each node periodically checks if and which caches need to be flushed.

The frequency of these checks can be configured with the daf.mybatis.cacheflusher.frequency property.

3.5.1. Rule Models

The following parameters can be used to tune the caching behavior of rule models. To change the value, the key needs to be added to the workplace-web-application.properties.

Key Description Default Value

artifact.lookup.threshold Time to make next check [sec] 10

artifactclassspacemanager.keepaliveperiod Time to keep classloader in memory 345600000 from last access [msec] (4 days * 24h * 60min * 60sec * 1000msec)

artifactclassspacemanager.cleanupinterval Time to reschedule cleanup task 1800000 [msec] (30 min * 60sec * 1000msec)

3.6. Distributed Search Index

The search functionality is implemented by a file based search index. Each cluster node holds its own dedicated search index. A background job on each cluster node is responsible to synchronize the index. The replication status is stored in the database. The status of the synchronization is visible in the Administration Screen.

Whenever a cluster node is added or reactivated after a while, the synchronization is done automatically in the background.

If a user is performing a search on a cluster node with an index that is out of date, an information message is displayed to the user indicating that he might search on out-of-date data. The threshold can be done by setting the maximum number of unindexed documents before warning property search.unindexed_warning_threshold.

Performance of adding new documents to search index highly depends on the environment and the size of Documents. For normal sized Documents (3000-7000 Request Data) a performance of 3-4 Documents per second can be expected (14000 Documents per hour). The smaller the average size of Documents, the faster

The property daf.lucene.staleLockCheckTime within the file workplace-web-application.properties defines the max number of milliseconds the service should try to obtain the index writer until it tries to forcibly remove the lock (if configured).

3.7. Load Balancing

You can use an external load-balancer to distribute user requests based on their sessions to individual cluster nodes. For the web application frontend, load-balancing should be configured to utilize sticky sessions.

3.8. Temporary Directories

The following temporary directories are used:

Purpose Location

Apache Wicket Page Store The page store files are stored in: /**/ WorkplaceWebApplication-filestore

3.9. Document Migration

The migration process might encounter documents it cannot migrate. This can be caused by invalid document data (opening the document might still be possible, the UI is more lenient to document errors) or by a bug in the migration process. If you encounter failures, please follow these steps:

• Download the failures CSV from the Migration Status page.

• Determine the cause for the failure and fix it.

• Open the database table MIG_REV_DATA_FAILURES and either delete the failure entry or - to keep the failure reason - set the STATE column to value 0.

• The revision will automatically be retried and the entry will be removed on success

• In case of a consecutive failure, a new entry will be created in the MIG_REV_DATA_FAILURES table. Please repeat the steps here in that case.

3.10. Backup and Restore

The database and the lucene index folder need to be considered for backups.

3.10.1. Database Backup and Restore

Please refer to the user manual of the database provider.

3.10.2. Data Folder and Lucene Index Backup and Restore

3.10.2.1. Backup steps

Backup can be taken as soon as the server is shutdown (cold backup).

The following subfolders of the data folder (property workplace.data.folder) need to be included in backups:

• lucene-index

• cluster

3.10.2.2. Restore steps

Restore can be done as soon as the server is shutdown.

Steps:

• Replace the folders data/lucene-index and data/cluster with their backups

• Restart server

The search index (data/lucene-index) can be copied from one cluster node to another belonging to the same environment. This enables to add a new cluster node without the need to wait for a clomplete re-index

It can not be copied from one environment to another, as internal IDs are used that are specific to one database instance.

Chapter 4. Security Information

The following sections provide an overview of common questions on security issues related to the web application. Please note that only default components and default behavior are considered. Due to the possibility of customizing the application and contributing developed rule models, security might be handled differently in those cases. 4.1. Authentication

4.1.1. Does the application use secure communication channels?

This is an application server configuration and not part of the configuration of the web application. The application server must be configured to use SSL/TLS transport layer security for the HTTP communication protocol.

4.1.2. Is the access to the application secured?

The framework uses Spring Security to force authentication of users. Apache Wicket provides role- based security annotations. The application provides access to fine-grained permissions in the IdentityContext of the currently authenticated user, enabling application pages to check for solution- specific permissions before executing any commands.

4.1.3. Does the application have a lockout policy?

The application does not enforce account lockout by default. This can be done by the User Maintenance Job, configured in AD or LDAP or customized.

4.1.4. Does the application log failed authentication attempts?

The application logs failed login attempts. Authentication attempts (including client IP address and reason) are logged in the Audit Log database.

4.1.5. Are there default user accounts?

The Workplace application contain a default “Admin” user with global access rights. It is suggested to remove / lock this user after setup or at least change the users password.

4.1.6. Does the application enforce password compliance policies?

The application provides the possibility to create a rule model that checks for password compliance. The rules are individual.

4.1.7. What type of backend is used by the application?

The application uses Spring Security, which provides interfaces and adapters for various authentication back ends, such as LDAP, Microsoft Active Directory. It can be customized to also use Single-Sign-On solutions.

4.1.8. Does the application use weak or strong cryptography?

The framework uses BCrypt hashes for passwords by default. BCryptEncoder will use a random 16 byte salt value. The framework does not provide any means to retrieve user passwords. The algorithm used for calculating hash codes can be customized to use other hashing algorithms.

4.1.9. What is the quality of session IDs?

The framework does not directly create Session IDs. IDs are created by Java application servers. Please consult the application server’s documentation.

4.1.10. What is 'RememberMe'?

'RememberMe' is a function that gives the user the possibility to stay logged in. The value is stored in a Cookie which is valid for 14 days (not configurable). For further imformation please consult the Spring´s documentation Remember Me

4.1.11. How are Cookies handled?

The following Cookies are generated by the Workplace server. All of them can be set to HttpOnly and Secure by setting the corresponding flag in workplace-web-application.properties

ACTICO_WORKPLACE_LOCALE This Cookie stores the locale value of the application. Example Values: 'en_US', 'de_DE'

ACTICO_WORKPLACE_UI_FRAMELESS This Cookie stores the value (true | false) to indicate the application to be frameless or not. Possible Values: 'true', 'false'

ACTICO_WORKPLACE_AUTOLOGIN This Cookie stores whether the 'Remember Me' checkbox is checked Value: Encoded, see question "What is 'RememberMe'?" above

ACTICO_WORKPLACE_SESSION_ID This Cookies stores the session id. Its name can be changed by changing the value of the web.session.cookie.name property in workplace-web-application.properties. Generated value

4.1.12. What is the timeout for sessions?

The application does not enforce any restrictions on session timeouts. Timeouts are configured in application servers or the workplace-web-application.properties configuration file of the web application. We recommend to use a short duration for inactivity timeouts. Do not circumvent such timeouts by enforcing refreshes using AJAX pings or similar methods.

The default value is set to 60 minutes one can change the session timeout by adding the web.session.timeout.minutes property to the workplace-web-application.properties 4.2. Vulnerabilities

4.2.1. Which Security HTTP Response Headers are activated by default?

X-Content-Type-Options The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. Default Value: 'nosniff'

X-XSS-Protection The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Default Value: '1; mode=block'

X-FRAME-OPTIONS Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites. Default Value: 'sameorigin'

4.2.2. Can the application be misused to perform URL redirection phishing?

The application does not provide any means to redirect users to other (external) web applications. All redirections happen by statically programmed redirects or application-internal redirects.

4.2.3. Is the application vulnerable to Cross-Site-Scripting attacks?

HTML inputs are escaped and filtered against a whitelist. Filtering is done using the library JSoup against the JSoup relaxed whitelist. JSoups list is extended by a few more allowed tags like “hr”. The filtering is done against

• Attribute value of UI Elements LabelElement

• Content of RichTextElement

• GenerateReportVRService

Also, Workplace uses Apache Wicket, which prevents many types of attacks on the web layer:

• Injection of submit actions is avoided by keeping a server-side list of allowed submit actions.

• If additional query string parameters are added, or values of selection elements are changed to values that do not exist in the backend, they are ignored.

• URLs do not expose sensitive information and all component paths are session-relative. Only explicitly bookmark-able links can expose state in the page or URL.

4.2.4. Is the application vulnerable to Cross-Site-Request-Forgery attacks?

The application uses POST actions by default. Accessing any URL using a GET request does not invoke an operation which modifies business data. 4.3. Information Sensitivity

4.3.1. Can users browse directory listing?

The application does not provide any functionality to list directories. Most Java application servers prevent directory listings for Java-based web applications by default. We recommend to disable the default servlets if the application server contains such an implementation.

4.3.2. Does the application show sensitive data on error pages?

The application provides ways to customize error page. The default error page of the Workplace example application shows very detailed technical information for troubleshooting purposes. It can be customized.

4.3.3. Does the application show sensitive comments in HTML source?

The rendered HTML and JavaScript source code transferred to clients/browsers do not contain development comments. Debug information is shown in the backend only if explicitly enabled in the Wicket configuration.

4.3.4. Does the application expose backup files?

The application does not create backup files. Hence, there is no way to download backups via the web interface.

4.3.5. Does the application allow path traversal attacks or predictable paths and filenames?

The user cannot manipulate the names of the file access by the framework. Filenames are, where used, programmatic constants or configuration settings in the backend. This includes logfile names and filenames for Lucene search index. Filenames of user-provided content, such as downloadable attachments or printable PDF documents, are rendered dynamically or retrieved from the database. URLs containing sequence numbers (e.g. for document numbers) or guessable filenames can be customized to be scrambled by using URLCodingStrategies. However, sensitive business data or personally identifiable information should never be displayed in URLs anyway. The framework uses technical IDs in URLs. 4.4. Injection

4.4.1. Does the application allow code injection?

The application dynamically executes code which is uploaded via a web interface by trusted users. In principle, any authenticated user who can produce Java code, which adheres to the general ACTICO Rules interfaces, is able to inject malicious code. Only authorized personnel must have access to the administration interface, and only such personnel should have permissions to upload rule models. Personnel with access to the database is able to upload malicious code, which is then executed with the privileges of the application server. The database does not only contain data, but also executable code.

4.4.2. Does the application allow OS command injection?

The application does not utilize any Java functionality to execute arbitrary code. Any user who can upload rule models has the ability to run arbitrary OS commands with the privileges of the application server. Rule models must not use any such functionality to execute commands provided via parameters.

4.4.3. Is the application vulnerable to buffer overflows?

Java is protected against String-based buffer overflows. There are exceptions though, such as native code via JNI, the JVM itself is written in C++, or embedded VMs which do not properly check array bounds due to memory constraints. All these exceptions do not apply to the application.

4.4.4. Is the application vulnerable to "format string" attack?

In general, Java is protected against Format-String based injections. The framework uses the String.format() utility and strongly-typed formatters, such as DateFormat, DecimalFormat, or NumberFormat.

4.4.5. Is the application vulnerable to LDAP injection?

The application does not use LDAP directly. If LDAP is configured, constant LDAP queries are used. See LDAPAuthenticationProvider of Spring Security for details.

4.4.6. Is the application vulnerable to SQL injection?

The application uses JDBC PreparedStatements to prevent SQL Injections. See the documentation of MyBatis for further details. Uploaded rule models might use ACTICO Rules Database Connectivity and need to be checked individually.

4.4.7. Is the application vulnerable to Server-Side-Includes injection?

The application does not use Server-Side-Includes or other CGI-related technologies, nor does it use JSP pages nor JSP Includes.

4.4.8. Is the application vulnerable to XPath injection?

The application does not use XPath for user-provided content.

4.4.9. Is the application vulnerable to Apache Lucene injection?

Apache Lucene provides query methods in which query terms are user-provided information. Apache Lucene does not have the ability to execute any arbitrary commands. Escaping is only required for single characters such as wildcarding terms.

4.4.10.Is the application vulnerable to MVEL/OGNL injection?

The application uses MVEL (a kind of an Object Graph Navigation library to access business values for reading and writing). The framework uses the explicit MVEL.setProperty(object, propertypath, value)method to ensure that only the given object's property can be written to or read from. Therefore, it is not possible to read other protected information, such as the platform context, the identity context, or system properties.

Chapter 5. Troubleshooting

5.1. Code Cache Size

If the JVM runs some time and gets extremely slow, it might be that the JVM Code Cache is full. Please check the JVM parameter ReservedCodeCacheSize in that case.

Chapter 6. Technical Limitations

Restrictions and recommendations which apply for the operation of the system:

• Restriction: Business parameters of type Map cannot contain structures or other complex types as keys. Recommendation: Use data type String for keys.

• Recommendation: The JVM default time zone must not be changed after data has been stored as this will lead to incorrect time information being displayed to users. Object are stored in the database using the JVM default time zone and later parsed using the JVM default time zone.

• Recommendation: All cluster nodes must run with the same JVM default time zone to prevent incorrect time information.

Appendix A. Application Server

A.1. Deployment to an Application Server

Please consult your official application server documentation on how to setup the application server. This section describes the parts specific to Workplace.

Configure the server to use SSL to avoid security issues like "unencrypted password form" (CWE-319 http://cwe.mitre.org/data/definitions/319.html or https://www.owasp.org/ index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection)

A.1.1. Configuration and Logging

The property file workplace-web-application.properties and the logging file log4j2.xml need to be on the application server classpath.

Make sure to keep relevant configuration parameters in sync between cluster nodes!

The location and name of the logging configuration file can be configured using the property log4j.xml.location with the file workplace-web-application.properties.

A.1.2. Database Connection

The user which is used to connect to the database needs the permissions to select, insert, update, delete as well as the permission to execute sequences.

The following connection possibilities exist and can be configured using the property spring.profiles.active with the file application.properties:

Type Configuration

jndi The datasource configured within the application server needs to have the JNDI name specified in the property db.datasource.jndi.name.

direct Please configure the properties starting with db.datasource.direct with the connection details like database URL, driver, user and password.

h2 Do not use the H2 database for production. It is intended for demonstration purpose only. It can be configured with the properties starting with h2database.

Unless the h2 database is used a valid database driver needs to be added to the application server setup.

XA transactions are not supported.

A.1.3. Java Virtual Machine (JVM) Configuration

Set the following required JVM arguments:

-server -Xms1024m -Xmx1024m

-XX:+UseG1GC -Dfile.encoding=UTF-8 -Dwicket.configuration=deployment -XX:+HeapDumpOnOutOfMemoryError -XX:ReservedCodeCacheSize=128m

JVM Argument Description

-server Selects the Server VM, which is optimized for productive operation of application servers. (In contrast, the Client VM is optimized for fast startup and hence used for desktop applications.)

-Xms1024m -Xmx1024m (Specific to Sun/Oracle VM) Defines the minimum and maximum heap space. Server-side applications set -Xms and -Xmx to the same values for a fixed heap size. Depending on the number and size of your rule models higher values might be required.

-XX:+UseG1GC (Specific to Sun/Oracle VM) Defines G1 garbage collection. About G1 Garbage Collector, Permanent Generation and Metaspace.

-Dfile.encoding=UTF-8 Defines the default character encoding for reading and writing files. By default, the JVM uses the system's default encoding.

-XX:+HeapDumpOnOutOfMemoryError (Specific to Sun/Oracle VM) Enables writing of memory dumps when Out-Of-Memory errors occur. Enabling this in production servers helps troubleshooting memory problems. The option does not have a negative performance impact on the runtime.

-XX:ReservedCodeCacheSize (Specific to Sun/Oracle VM) Increases the code cache size.

A.1.4. Resources and Libraries

The chapter describes where to place resources files within the application server classpath. Resources in this context are:

• Configuration File workplace-web-application.properties

• The logging file log4j2.xml

Also the deployment of libraries is described. For Workplace, this are database drivers, but those might already be available globally. Consult the Application Server Administrator for details.

A.1.5. JBoss Deployment

Recommendation is to use the JBoss module concept. A valid module xml might look like the following example:

Required deployments in this case:

• Copy libraries to >/de/innovations/configuration/main

• Copy Resources to >/de/innovations/configuration/main

• Deploy the web application using the application server’s deployment mechanism

A.1.6. Tomcat Deployment

Required deployments:

• Copy libraries to /lib

• Copy resources to /lib

A.1.7. Weblogic Deployment

Required deployments:

• Copy libraries to the designated base domain to /lib/

• Copy resources to a folder that is available on the classpath

• Deploy the web application using the application server’s deployment mechanism

A.1.8. Application Server Shutdown

Always properly shutdown the application server. This is important for files to be closed (e.g. search index). Killing the application server must not be done.

Appendix B. Configuration Files

B.1. Web Application Configuration

The Workplace Web Application is configured using the file workplace-web-application.properties:

# Profiles to activate: # for authentication mode use one of: application, ldap # application = Internal user management # ldap = Use LDAP or Active Directory for user management # for datasource configuration use one of: h2, direct, jndi # h2 = Demo mode with embedded h2 database # direct = Direct connection to database with own data source. # Connection parameters need to be provided. # jndi = Data source is looked up using JNDI spring.profiles.active=application,h2

################################################################################### # General settings ###################################################################################

# Environment name (displayed in the top area of the application) environment.name=Development

# file system directory where the workplace relevant data is stored workplace.data.folder=data

################################################################################### # Tomcat standalone Settings ###################################################################################

## These settings are only applied if the web application is launched without a servlet container (which is the recommended default) # Display name for Tomcat server tomcat.standalone.displayName=ACTICO Workplace tomcat.standalone.httpPort=8050 #Context path must start with a / #tomcat.standalone.contextPath= #tomcat.standalone.httpsPort=8043 #tomcat.https.keyalias=workplace #tomcat.https.keystore.path=/workplace_keystore.jks #tomcat.https.keystore.password=

################################################################################### # Database Settings ###################################################################################

# only used if h2 profile is active # don't change this unless you also change # the datasource url in the birt reports (*.rptdesign) h2database.tcp.port=8045 h2database.folder=data/db_h2

# only used if jndi profile is active db.datasource.jndi.name=java:comp/env/jdbc/workplace

# only used if direct profile is active

# Example connection parameters for H2 database db.datasource.direct.username= db.datasource.direct.password=

# Example connection parameters for Oracle database #db.datasource.direct.username= #db.datasource.direct.password= #db.datasource.direct.url= #db.datasource.direct.driver=oracle.jdbc.OracleDriver #db.datasource.direct.validationQuery=SELECT 1 FROM DUAL

# Example connection parameters for MsSQL database #db.datasource.direct.username= #db.datasource.direct.password= #db.datasource.direct.url= #db.datasource.direct.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver #db.datasource.direct.validationQuery=SELECT 1

# Example connection parameters for MySQL database #db.datasource.direct.username= #db.datasource.direct.password= #db.datasource.direct.url= #db.datasource.direct.driver=com.mysql.jdbc.Driver #db.datasource.direct.validationQuery=SELECT 1

# Minimum number of idle connections that HikariCP tries to maintain in # the pool. If the idle connections dip below this value and total # connections in the pool are less than maximumPoolSize, HikariCP will # make a best effort to add additional connections quickly and # efficiently. However, for maximum performance and responsiveness to # spike demands, we recommend not setting this value and instead allowing # HikariCP to act as a fixed size connection pool. Default: 10 #db.datasource.direct.minimumIdle=8

# Maximum number of milliseconds that the application will wait for a # connection from the pool. If this time is exceeded without a connection # becoming available, a SQLException will be thrown. Lowest acceptable # connection timeout is 250 ms. Default: 30000 (30 seconds) #db.datasource.direct.connectionTimeout=30000

# Maximum amount of time that a connection is allowed to sit idle in the # pool. This setting only applies when minimumIdle is defined to be less # than maximumPoolSize. Idle connections will not be retired once the # pool reaches minimumIdle connections. Whether a connection is retired # as idle or not is subject to a maximum variation of +30 seconds, and # average variation of +15 seconds. A connection will never be retired # as idle before this timeout. A value of 0 means that idle connections # are never removed from the pool. The minimum allowed value is 10000ms # (10 seconds). Default: 600000 (10 minutes) #db.datasource.direct.idleTimeout=600000

# Maximum lifetime of a connection in the pool. An in-use connection will # never be retired, only when it is closed it will be removed. On a # connection-by-connection basis, minor negative attenuation is applied # to avoid mass-extinction in the pool. We strongly recommend setting

# this value, and it should be several seconds shorter than any database # or infrastructure imposed connection time limit. A value of 0 indicates # no maximum lifetime (infinite lifetime), subject of course to the # idleTimeout setting. Default: 1800000 (30 minutes) #db.datasource.direct.maxLifetime=1800000

# Sets a SQL statement that will be executed after every new connection # creation before adding it to the pool. If this SQL is not valid or # throws an exception, it will be treated as a connection failure and the # standard retry logic will be followed. Default: none #db.datasource.direct.connectionInitSql=

# Maximum amount of time that a connection will be tested for aliveness. # This value must be less than the connectionTimeout. Lowest acceptable # validation timeout is 250 ms. Default: 5000 #db.datasource.direct.validationTimeout=5000

# Amount of time that a connection can be out of the pool before a # message is logged indicating a possible connection leak. A value of # 0 means leak detection is disabled. Lowest acceptable value for # enabling leak detection is 2000 (2 seconds). Default: 0 #db.datasource.direct.leakDetectionThreshold=0

################################################################################### # Watchdog ###################################################################################

# watchdog functionality: regularly triggers the workflow model in a # configurable frequency with a configurable event name

# the interval in that the watchdog functionality should fire # "never" fire the watchdog (never=will fire in year 2099) watchdog.time.scheduling.frequency=0 0 0 1 1 ? 2099

# fire the watchdog every 30 seconds # watchdog.time.scheduling.frequency=0/30 * * * * ? # event name that should be fired when executing the workflow model watchdog.workflow.event.name=start_watchdog

# username that is used to execute the workflow model watchdog.run.as.userName=

# client that is used to execute the workflow model watchdog.run.as.ClientName=Default

# default amount of days, the history of successful jobs will be kept watchdog.history.successful.jobs=2

# default amount of days, the history of failed jobs will be kept watchdog.history.failed.jobs=30

################################################################################### # Authentication and Authorization ###################################################################################

# This will enable/disable the 'remember me' feature allowing to store # authentication data within the browser (by means of a cookie). # The user then has to login once and will be remembered by the # application for successive sessions (provided that the user does # not intentionally logout). auth.rememberme.enabled=true

# If the user authentication is against an LDAP you can configure to # hide the "change password" field.

# If you e.g. use single sign on you can configure to hide the "login" panel. crrp.authentication.login.enabled=true

# If you e.g. use single sign on you can configure to hide the "logout" field. crrp.authentication.logout.enabled=true

# This property defines the cron expression for maintaining the user lock status. # The maintenance job has to be executed to ensure that the user lock status is # available in the database. This is necessary, for example, for reports. # Default value: 0 0 22 * * ? = every day at 10:00 p.m. im.user.lock.status.job.frequency=0 0 22 * * ?

# LDAP / AD Configuration # ------# (used in case of ldap authentication) # # Connection to LDAP Server # URL to LDAP Server (e.g. "ldap://localhost:389/base_dn"). # Multiple urls can be separated by spaces (for fail over only) ldap.server.url=

# Ldap user and password to login ldap.server.userDN=cn=admin,dc=bfs-intra,dc=net ldap.server.password=

# Path to lookup users from LDAP ldap.usersOU=OU=Users

# Ldap search criteria to search # the user-id user-id (e.g. sAMAccountName={0}, or uid={0}) # defaults to (|(uid={0})(sAMAccountName={0})) #ldap.userSearchFilter=(|(uid={0})(sAMAccountName={0}))

# Comma separated list of potential user name attributes, # defaults to uid,sAMAccountName #ldap.userNameAttributes=

# If set to true, a subtree scope search will be performed. # If false a single-level search is used. # Default is false #ldap.searchSubtree=false

# Enable synchronize job to synchronize LDAP entries into the Workplace database # This also defines if the synchronization button is shown within the UserInterface # Defines if the job should run (Default: false) #ldap.sync.enabled=true

# Execute LDAP synchronization job in background # Default: 0 0 3 * * ? (every night at 3am) #ldap.sync.frequency=0 0 3 * * ?

# User for audit log entries when synchronization job performs # changes (Default: Admin) #ldap.sync.run.as.UserName=

# One functionality of the synchronization job is to map the roles of a # user from LDAP into the database # Default: false. Please note that the sync mechanism needs # to be enabled in this case #ldap.sync.userRoleMapping.enabled=true

# Path where groups are defined

# Ldap search criteria to search for members of the group, # defaults to (|(member={0})(memberUid={1})(uniqueMember={0})) #ldap.sync.userrolemapping.groupSearchFilter=(|(member={0})(memberUid={1}) (uniqueMember={0}))

# Another functionality of the synchronization job is to map the attributes of a # user from LDAP into the database # Please specify the names of the fields in your LDAP below. # Name of the field in your LDAP which contains the full name of the user ldap.sync.userAttributeMapping.fullname=displayName

# Name of the field in your LDAP which contains the description of the user ldap.sync.userAttributeMapping.description=description

# Name of the field in your LDAP which contains the department of the user ldap.sync.userAttributeMapping.department=departmentNumber

# Name of the field in your LDAP which contains the phone number of the user ldap.sync.userAttributeMapping.phoneNumber=homePhone

# Name of the field in your LDAP which contains the email address of the user ldap.sync.userAttributeMapping.eMailAddress=mail

# Name of the field in your LDAP which contains the country code of the user ldap.sync.userAttributeMapping.countryCode=c

# Users which exist in LDAP but not in the applications' database can be created automatically. # Users which do not exist in the applications' database will be auto-created # on their first log-in or with the next synchronization job. (Default: false) #ldap.sync.autocreateUsers.enabled=true # LDAP filter to use for selecting desired users inside the users path. ldap.sync.autocreateUsers.userFilter=objectClass=person

################################################################################### # Search Index ###################################################################################

### Settings for lucene index cluster management daf.lucene.documentIndexer.frequency=0/5 * * * * ?

# cron expression which defines how often the job for committing lucene index changes to the filesystem is executed # please note that even if changes are not committed to the filesystem they'll still instantly become visible for searches # This settings is used for Lucene Version 4.7 and above # 0 0/5 * * * ? = every 5 minutes daf.lucene.indexWriterCommit.frequency=0 0/5 * * * ?

# Max amount of milliseconds the service should try to obtain the index # writer until it it tries # to forcibly remove the lock if configured. If not it prints an error message. daf.lucene.staleLockCheckTime=5000

################################################################################### # Stateflow ###################################################################################

### Stateflow Configuration # Defines if a pre state transition rule should be executed (true|false)

# When true, a flowrule named 'BEFORE_Transition' must be present in Stateflow! daf.stateflow.startPreStateTransitionRule=true

# Defines if a post state transition rule should be executed (true|false) # When true, a flowrule named 'AFTER_Transition' must be present in Stateflow! daf.stateflow.startPostStateTransitionRule=true

# Defines if a failed state transition rule should be executed (true|false) # When true a flowrule named 'FAILED_Transition' must be present in Stateflow! daf.stateflow.startFailedStateTransitionRule=true

# Defines if the application should always use the 'current active' stateflow # version (true|false). # associated to a Document. If set to false the Stateflow version is used that # was associated with the Document when it has been created. daf.stateflow.alwaysUseCurrentActiveStateflow=true

################################################################################### # Security / Web Session ###################################################################################

# Enable secure flag and http only flag for cookies # default for both properties: false #web.cookie.secure=true #web.cookie.httpOnly=true

# Name of the session cookie web.session.cookie.name=ACTICO_WORKPLACE_SESSION_ID

# Set session timeout in minutes # default: 60 (minutes) web.session.timeout.minutes=60

################################################################################### # Logging ###################################################################################

# Name and location of the log4j2 xml configuration file. # Default value: log4j2.xml # log4j.xml.location=log4j2.xml

################################################################################### # Document Stale Locks ###################################################################################

# Stale Lock Clean Up - Removes stale application/document locks after that # amount of minutes Be aware that locks are updated in certain intervals in # general (browser) - never set the frequency/maxAge below that interval # Max age of a lock before it's considered to be stale (in minutes) # 1 hour = 60 crrp.staleLocks.maxLockAge=60

# cron expression for interval which defines how often the job is removing # stale locks crrp.staleLocks.removalFrequency=0 0/30 * * * ?

################################################################################### # Misc ###################################################################################

### Settings for backward compatibility only # Number of rule model versions that should be kept in memory

# Only .jar files created with a version < 2.0 of the workplace # plugins / version < 6.0 of Visual Rules # are affected by this setting. If you did not upload such .jar files # to the application there is no need # of changing the setting daf.rulemodelloader.cache.size=20

# Properties for text rendering of documents - Max. Number of VTable Columns drs.vtable.maxcolums=4

# Properties for text rendering of documents - Max. Number of SimpleTable Columns drs.simpletable.maxcolums=10

### Settings for cluster cache flushing # Configures the cron expression for when to check for caches that should be # flushed. daf.mybatis.cacheflusher.frequency=2/5 * * * * ?

# Sets the time in minutes that a request will by default be waiting for the # previous request to be handled before giving up. #application.request.cycle.timeout=1

# user name to check the status and perform the system-updates in headless mode # typically an administrator (user must exist in database) daf.systemupdate.headlessmode.username=

# Allows to embed the web ui in a frameless mode, e.g. within an iframe. # Property is optional, default value is false #daf.web.allow.frameless.mode=true

# Defines if access to older revisions of a Document is allowed using links. # Older revisions of a Document presented in read-only mode. # Disabled here, so that it can be adjusted in Workplace Web Application. # Enable to hard code this setting. #documents.allow.access.older.revisions=true

# set to true if web resources should be merged before delivering them to the client merge.web.resources=false

# Settings for the pool for internal task execution # this settings usually should not be changed daf.taskexecution.corePoolSize=10 daf.taskexecution.maximumPoolSize=50 daf.taskexecution.queueSize=1000 daf.taskexecution.allowCoreThreadTimeOut=true daf.taskexecution.keepAliveTime=600

### Job scheduling & watchdog functionality # Defines if default scheduler should be started by default. # The default scheduler is used for monitored system jobs and should be # usually enabled. daf.quartz.default.scheduler.enabled=true

# Defines the thread count for default scheduler. Defaults to 5. daf.quartz.default.scheduler.threadCount=5

B.2. Batch Application Configuration

The Workplace Batch Application is configured using the file workplace-batch- application.properties:

# Profiles to activate: # for datasource configuration use one of: h2, direct, jndi # h2 = Demo mode with embedded h2 database # direct = Direct connection to database with own data source. # Connection parameters need to be provided. # jndi = Data source is looked up using JNDI spring.profiles.active=direct

################################################################################### # General settings ###################################################################################

# file system directory where the workplace relevant data is stored workplace.data.folder=data

################################################################################### # Database Settings ###################################################################################

# Expose mpDataSource as JNDI Resource jdbc.jndi.vrDataSource=java:comp/env/jdbc/workplace

# only used if h2 profile is active # don't change this unless you also change # the datasource url in the birt reports (*.rptdesign) h2database.tcp.port=8045 h2database.folder=data/db_h2

# only used if jndi profile is active db.datasource.jndi.name=java:comp/env/jdbc/workplace

# only used if direct profile is active

# Example connection parameters for H2 database db.datasource.direct.username= db.datasource.direct.password= db.datasource.direct.url= db.datasource.direct.driver=org.h2.Driver db.datasource.direct.validationQuery=SELECT 1

# Example connection parameters for MySQL database #db.datasource.direct.username= #db.datasource.direct.password= #db.datasource.direct.url= #db.datasource.direct.driver=com.mysql.jdbc.Driver

#db.datasource.direct.validationQuery=SELECT 1

# Maximum size that the pool is allowed to reach, including both idle and # in-use connections. Basically this value will determine the maximum # number of actual connections to the database backend. A reasonable value # for this is best determined by your execution environment. When the pool # reaches this size, and no idle connections are available, calls to # getConnection() will block for up to connectionTimeout milliseconds # before timing out. Default: 10 db.datasource.direct.maximumPoolSize=8 # Minimum number of idle connections that HikariCP tries to maintain in # the pool. If the idle connections dip below this value and total # connections in the pool are less than maximumPoolSize, HikariCP will # make a best effort to add additional connections quickly and # efficiently. However, for maximum performance and responsiveness to # spike demands, we recommend not setting this value and instead allowing # HikariCP to act as a fixed size connection pool. Default: 10 #db.datasource.direct.minimumIdle=8 # Maximum number of milliseconds that the application will wait for a # connection from the pool. If this time is exceeded without a connection # becoming available, a SQLException will be thrown. Lowest acceptable # connection timeout is 250 ms. Default: 30000 (30 seconds) #db.datasource.direct.connectionTimeout=30000 # Maximum amount of time that a connection is allowed to sit idle in the # pool. This setting only applies when minimumIdle is defined to be less # than maximumPoolSize. Idle connections will not be retired once the # pool reaches minimumIdle connections. Whether a connection is retired # as idle or not is subject to a maximum variation of +30 seconds, and # average variation of +15 seconds. A connection will never be retired # as idle before this timeout. A value of 0 means that idle connections # are never removed from the pool. The minimum allowed value is 10000ms # (10 seconds). Default: 600000 (10 minutes) #db.datasource.direct.idleTimeout=600000 # Maximum lifetime of a connection in the pool. An in-use connection will # never be retired, only when it is closed it will be removed. On a # connection-by-connection basis, minor negative attenuation is applied # to avoid mass-extinction in the pool. We strongly recommend setting # this value, and it should be several seconds shorter than any database # or infrastructure imposed connection time limit. A value of 0 indicates # no maximum lifetime (infinite lifetime), subject of course to the # idleTimeout setting. Default: 1800000 (30 minutes) #db.datasource.direct.maxLifetime=1800000 # Sets a SQL statement that will be executed after every new connection # creation before adding it to the pool. If this SQL is not valid or # throws an exception, it will be treated as a connection failure and the # standard retry logic will be followed. Default: none db.datasource.direct.connectionInitSql= # Maximum amount of time that a connection will be tested for aliveness. # This value must be less than the connectionTimeout. Lowest acceptable # validation timeout is 250 ms. Default: 5000 #db.datasource.direct.validationTimeout=5000 # Amount of time that a connection can be out of the pool before a # message is logged indicating a possible connection leak. A value of # 0 means leak detection is disabled. Lowest acceptable value for # enabling leak detection is 2000 (2 seconds). Default: 0 #db.datasource.direct.leakDetectionThreshold=0

# Default value: 0 0 22 * * ? = every day at 10:00 p.m. im.user.lock.status.job.frequency=0 0 22 * * ?

################################################################################### # Search Index ###################################################################################

### Settings for lucene index cluster management daf.lucene.documentIndexer.frequency=0/5 * * * * ?

# cron expression which defines how often the job for committing lucene index changes to the filesystem is executed # please note that even if changes are not commited to the filesystem they'll still instantly become visible for searches # This settings is used for Lucene Version 4.7 and above # 0 0/5 * * * ? = every 5 minutes daf.lucene.indexWriterCommit.frequency=0 0/5 * * * ?

# Max amount of milliseconds the service should try to obtain the index writer until # it it tries to forcibly remove the lock if configured. If not it prints # an error message. daf.lucene.staleLockCheckTime=5000

################################################################################### # Misc ###################################################################################

# Username/Client to use for IdentityContext creation daf.batch.default.client=Default daf.batch.default.user=Admin

# Transaction timeout in seconds chunk.transaction.timeout=180

# Number of threads to use for chunk processing. The more threads are configured, # the more resources (memory, database connections) are used! # Do not use values > 20 # Leave 1 if working with H2 as values >1 can cause deadlocks. chunk.processing.threads=1 # Max amount of tasks in queue chunk.processing.queue.size=100 # How many failed chunks are allowed, before the framework stops processing stop.job.after.failed.chunks=10

### Settings for cluster cache flushing # Configures the cron expression for when to check for caches that should be flushed. daf.mybatis.cacheflusher.frequency=2/5 * * * * ?

# Defines the frequency in seconds the scheduler process polls the database to lookup Batch Runs to trigger. scheduler.polling.interval.seconds=10 # Defines the timeout in seconds for a Batch Run in execution. # If a Batch Run is not finished after this amount of seconds # the scheduler will set the status to FAILED and log appropriate message. # -1 disables the feature. scheduler.batchrun.timeout.seconds=-1

# This threshold defines the maximum number of unindexed Documents before starting # a Batch Run. If a Batch Run is about to be started and this threshold of # unindexed Documents is reached, the Batch Run will not start, reporting a # status of FAILED. Indexing process might take a long time if # many Documents need to be indexed. This might significantly delay the scheduled

# start time for a BatchRun. Therefore, this threshold can be configured to let a # Batch Run fail immediately if too many Documents are missing in the Search Index. # Set to -1 to disable this feature (e.g. if you don't interact with # Documents in your batch rule models). search.max.amount.unindexed.documents=20000

### Settings for backward compatibility only # Number of rule model versions that should be kept in memory # Only .jar files created with a version < 2.0 of the workplace # plugins / version < 6.0 of Visual Rules # are affected by this setting. If you did not upload such .jar files # to the application there is no need # of changing the setting daf.rulemodelloader.cache.size=20

# corePoolSize define how many worker threads should be minimum in the pool daf.taskexecution.corePoolSize=25 # maximumPoolSize the maximum number of workers in the pool daf.taskexecution.maximumPoolSize=50 # queueSize the maximum number of tasks in the queue daf.taskexecution.queueSize=1000 daf.taskexecution.keepAliveTime=600

# user name to check the status and perform the system-updates in headless mode # typically an administrator (user must exist in database) daf.systemupdate.headlessmode.username=