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 ProcessAnalyer consists of the following components:
- QPR ProcessAnalyzer Web UI: The web UI is web browser based user interface for QPR ProcessAnalyzer. The Web UI works with all modern browsers without installing separate add-ons. For more information, see the list of supported browser.
- QPR ProcessAnalyzer Excel Client: Excel Client is an add-on to Microsoft Excel used to administrate users (for system administrators) and manage SQL scripts (for ETL developers). More information about supported Excel versions.
- QPR ProcessAnalyzer ScriptLauncher: ScriptLauncher is a tool to trigger QPR ProcessAnalyzer SQL scripts. QPR ProcessAnalyzer ScriptLauncher can also be used for fetching on-premise data and store to the cloud. The ScriptLauncher is typically installed to an on-premise server and scheduled there to run periodically. The ScriptLauncher can start SQL scripts in QPR ProcessAnalyzer Server in which case scripts can fetch data through the ScriptLauncher (which has a direct access to the on-premise systems, because it runs in an on-premise computer).
- QPR ProcessAnalyzer Server: QPR ProcessAnalyzer Server is the main component for QPR ProcessAnalyzer. It holds the models data in-memory, processes analyses and calculation expressions, and manages users and sessions.
- QPR ProcessAnalyzer Server Database: This is the main database for the QPR ProcessAnalyzer Server, storing for examples models, datatables, scripts, users and system configurations. Connection to the database uses .NET Framework Data Provider for SQL Server (SqlClient).
- QPR ProcessAnalyzer Scripting Database: This is a database to run SQL commands in the ETL scripts. QPR ProcessAnalyzer Server needs to have access to the scripting database to be to run SQL scripts. The scripting sandbox can be configured in a way that the data is not stored permanently there (datatables are used for permanent storage). Alternatively, the scripting database can have a write access, to store data permanently to the database. More information about, ETL Scripting.
- QPR ProcessAnalyzer TempDB: There is always one TempDB in every SQL Server which is setup already in the SQL Server installation. TempDB sizing and performance needs to be taken into account when running QPR ProcessAnalyzer, because the SQL scripting uses the TempDB quite 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 client connections to QPR ProcessAnalyzer Server are done using the QPR ProcessAnalyzer API (more information: QPR ProcessAnalyzer Web Service API). There are currently two technologies in use: Web API and WFC API (Windows Communication Foundation). The Web UI uses the Web API, and Excel client and ScriptLauncher use the WCF API. New feature development is done to the Web API and the WCF API will be removed in future, when it's not needed by any client component anymore.