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.

QPR ProcessAnalyzer Server API

All connections to QPR ProcessAnalyzer Server are performed using the QPR ProcessAnalyzer API (more information: QPR ProcessAnalyzer Web Service API). There are two technologies in use: Web API and traditional WFC API (Windows Communication Foundation). The web UI uses the Web API, and Excel client and ScriptLauncher are using the WCF API. New feature development is done to the Web API and the WCF API will be removed in future, when the Excel Client is not needed anymore (all functionalities are available in the web UI).

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.