QPR ProcessAnalyzer System Architecture

From QPR ProcessAnalyzer Wiki
Jump to navigation Jump to search

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 overall system architecture for QPR ProcessAnalyzer with all the main components.

QPR ProcessAnalyzer System Architecture.png

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 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 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.