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 diagram shows the system architecture for QPR ProcessAnalyzer with its main components.

QPR ProcessAnalyzer consists of the following components:

• QPR ProcessAnalyzer 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.
• 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 .Net 6 and it runs hosted by IIS (Internet Information Services) on Windows Server.
• QPR ProcessAnalyzer ScriptLauncher: ScriptLauncher is a tool to trigger QPR ProcessAnalyzer scripts used for ETL (extract, transform and load). The ScriptLauncher is installed on-premise, to extract data from on-premise systems and store to the QPR ProcessAnalyzer cloud. ScriptLauncher will run scripts managed in QPR ProcessAnalyzer, executing the data extraction commands to the on-premise systems.
• SQL Server metadata database: This is the system database used by QPR ProcessAnalyzer Server, storing e.g., projects, dashboards, scripts, users and system configurations. SQL Server is supported as the database system and connection to the database uses ADO.Net.
• SQL Server datatables database: This database stores contents for datatables managed by QPR ProcessAnalyzer. The datatables contain events and cases data for the process mining models and data processed by the ETL scripts. SQL Server is supported as the database system and connection to the database uses ADO.Net. When using Snowflake, this database is not used, as the datatables are stored in the Snowflake.
• SQL Server scripting database: Scripting database is used to run SQL commands in the ETL 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): SQL Server instance has a database called tempdb, to store temporary data. As a data intensive application, the tempdb performance has an essential role in QPR ProcessAnalyzer, e.g., the SQL scripts use the tempdb. 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 Data Sources

QPR ProcessAnalyzer is designed and built for easy integration to a wide range of data sources to fetch the eventlogs data. The power of process mining comes from collecting process information from differences sources to a comprehensive process mining model, where it can be analyzed from any angle. The available data sources can include for example:

• ERP systems, e.g. SAP HANA and SAP R/3 (for Order-to-Cash, Purchase-to-Pay processes etc.)
• CRM systems, e.g. Salesforce (for sales process)
• Customer support systems, e.g. Jira
• Case management systems
• Supply chain management systems
• Configuration management databases

To get started with an analysis, an eventlog is needed containing individual events as rows and at least following three properties as column: Case id, timestamp and event type. The eventlog can optionally contain event attributes such as sales person, location, customer, sale amount, time stamp for start and end of the event.

As the security of the data is essential, 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. For example, connectors to ODBC, OLEDB, ADO.net, and SOAP/REST Web Services are available (more information).

Authentication, Authorization and Security Model

QPR ProcessAnalyzer supports the following methods for authenticating users:

• QPR ProcessAnalyzer built-in authentication: QPR ProcessAnalyzer has its own user management which can provide password authentication for users. For increased security, there is a mechanism in place to prevent brute-force password guessing attacks against QPR ProcessAnalyzer built-in authentication.
• SAML authentication (federated authentication): To use organization's own identity management system (IdP), QPR ProcessAnalyzer can be integrated with it using the SAML 2.0 protocol. SAML 2.0 is also the optimal solution for QPR Cloud (more information about SAML authentication).
• LDAP/AD authentication: QPR ProcessAnalyzer can use the traditional AD/LDAP authentication, although the SAML authentication 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 consist of models, datatables, dashboards and scripts. When there are lot of users, it's recommended to use groups to make user management easier: when permissions have been configured to groups, users can be easily assigned to groups. More information about permissions and user session management.

QPR ProcessAnalyzer also supports case level permissions, allowing to determine permissions for each case separately based on flexible rules and the attribute data in the eventlog. 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 connection between QPR ProcessAnalyzer Server and SQL Server database, the system uses one connection string and a shared connection pool with a single SQL Server user (login) for all database operations. For easy setup, the database user can use the db_owner role, but the hardened configuration complying with the minimum privilege principle is recommended.

Credentials for external data sources can be managed in a separate secure strings storage, which allow to store passwords and other confidential information in a secure way, that the stored credentials cannot be seen in the UI by any user.

QPR ProcessAnalyzer Server API

All connections to QPR ProcessAnalyzer Server are established through the QPR ProcessAnalyzer API. For example, the QPR ProcessAnalyzer Web UI and the QPR ProcessAnalyzer ScriptLauncher are using it, and also any external integrations can use it to communicate with the QPR ProcessAnalyzer system.

Snowflake Powered Calculation

In addition to the in-memory processing, process mining queries for dashboards can be calculated in Snowflake (https://snowflake.com), enabling remarkable scaling in performance with very large datasets and number of simultaneous users. To use the Snowflake processing, an account to Snowflake is required and QPR ProcessAnalyzer needs to be connected to the account using an ODBC connection (more information). Any cloud platforms provided by Snowflake can be used, but for optimal performance, prefer a site that is near to the QPR ProcessAnalyzer environment.

When the Snowflake connection is set to a QPR ProcessAnalyzer environment, users can create datatables that store their data to Snowflake tables. When creating a process mining model, that uses the Snowflake stored events and cases datatables, the model will use Snowflake to process the calculations for the model. The snowflake processing has different capabilities than the in-memory processing, and thus there is a different set of KPI's available when creating dashboards. For example, machine learning and conformance calculations are only available in the in-memory processing.

The following diagram shows how QPR ProcessAnalyzer interacts with Snowflake in the process mining query processing and also options for the ETL data flows: