QPR ProcessAnalyzer System Architecture

QPR ProcessAnalyzer is natively a cloud-based software, and also an on-premise installation is available. Users access the QPR ProcessAnalyzer through their PCs, laptops or tables using web browser.

System Architecture and Components

The following figure shows the QPR ProcessAnalyzer system architecture.

QPR ProcessAnalyzer consists of the following components:

• Web UI: Web UI is a web browser based user interface for QPR ProcessAnalyzer using HTML5 and Angular as technologies. The Web UI works with all modern browsers without separate add-ons. For more information, see the list of supported browser.
• ScriptLauncher: ScriptLauncher is a tool to trigger QPR ProcessAnalyzer scripts used for ETL (extract, transform and load). The ScriptLauncher is installed on-premise, so it is able to fetch eventlog data from on-premise systems and store to the QPR ProcessAnalyzer cloud. In practice, ScriptLauncher can run scripts that are managed in QPR ProcessAnalyzer environment, allowing the scripts to execute data extraction commands from the on-premise source systems.
• QPR ProcessAnalyzer Server: QPR ProcessAnalyzer Server is the server or cloud side component for QPR ProcessAnalyzer environment. It holds the eventlog data in-memory allowing very fast processing and calculation for the data based on the QPR ProcessAnalyzer's own expression language optimized for process mining calculations. QPR ProcessAnalyzer Server also manages users, sessions and other system configurations. QPR ProcessAnalyzer Server is based on the .Net Framework and it runs hosted by IIS (Internet Information Services). Currently Windows Server is required, but in future, migration to .Net 5 allows also support for Linux servers.
• QPR ProcessAnalyzer Server Database: This is the main database used by the QPR ProcessAnalyzer Server, storing for examples models, projects, dashboards, datatables, scripts, users and system configurations. Currently SQL Server is supported as the database system and connection to the database uses .NET Framework Data Provider for SQL Server (SqlClient).
• QPR ProcessAnalyzer Scripting Database: Scripting Database is used to run SQL commands in the QPR ProcessAnalyzer scripts. The scripting database can be configured to store data only temporarily during the script runs (for the permanent storage datatables stored to the QPR ProcessAnalyzer Server Database can be used). For custom usecases, the scripting database can also have write access to store data permanently.
• SQL Server tempdb: Each SQL Server instance has a database called tempdb, used to store data temporarily. The tempdb sizing and performance needs to be considered carefully when running QPR ProcessAnalyzer, as the SQL scripts use the tempdb intensively. See the system requirements section for the tempdb sizing. More information about tempdb: https://docs.microsoft.com/en-us/sql/relational-databases/databases/tempdb-database?view=sql-server-ver15.

Connecting to External Data Sources

QPR ProcessAnalyzer is designed and built for easy integration to a wide range of data sources to fetch the event logs data. The power of the product comes from having different process information accessible from one point and where it can be analyzed from any angle. The data sources can include:

• ERP systems e.g. SAP R/3 and SAP HANA (for Order to Cash and other processes)
• CRM systems e.g. Salesforce (for sales process)
• Customer support systems e.g. Jira
• Case Management Systems
• Supply Chain Management systems
• Configuration Management Databases

For a basic analysis an event log is needed containing events as rows and at least following three columns: Case id, timestamp and event type. The event log can optionally contain event attributes such as sales person, location, customer, sale amount, time stamp for start and end of sale.

As data security is always key, the architecture is built so that the data is protected when collected from the source. The data can be fetched from any source using integration interfaces whether they are located on premise or in the cloud.

Authentication, Authorization and Security Model

QPR ProcessAnalyzer supports the following methods for authenticating users:

• QPR ProcessAnalyzer user management: QPR ProcessAnalyzer has its own user management which provides password authentication for users.
• SAML authentication (fererated authentication): To use organization's own identity management system (IdP), QPR ProcessAnalyzer can be integrated with it using the SAML protocol. SAML is the optimal solution for QPR Cloud. More information about SAML authentication.
• LDAP/AD authentication: QPR ProcessAnalyzer can also use traditional AD/LDAP authentication, although the SAML authencation as more flexible is the recommended option. More information about LDAP/AD authentication.

QPR ProcessAnalyzer has its own robust and flexible authorization mechanisms that controls user's access to data. Permissions are managed for individual projects, which contain models, datatables and scripts. It's recommended to use groups to make user management easier: the project permissions can be assigned to groups, and then users can be assigned to groups. More information about permissions in QPR ProcessAnalyzer and user session management.

QPR ProcessAnalyzer also supports case level security, allowing to determine permissions for each case (i.e. process execution instance) separately based on information in the model data. You can for example assign permissions for cases from each company code for persons working in the respective area. More information about case level permissions.

For the database connection, QPR ProcessAnalyzer uses one connection string and common connection pool with a single SQL Server user (login) for all database operations. The database user can use db_owner permission for easy configuration, but a hardened configuration with minimum privilege principle is recommended.

QPR ProcessAnalyzer Server API

All connections to QPR ProcessAnalyzer Server are established using the QPR ProcessAnalyzer API. For example, the web UI and the QPR ProcessAnalyzer ScriptLauncher uses it and also external integrations can use it to fetch and store data from and to QPR ProcessAnalyzer.