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 figure shows the QPR ProcessAnalyzer system architecture.

File:QPR ProcessAnalyzer Architecture.png

QPR ProcessAnalyer consists of the following components:

  • QPR ProcessAnalyzer Web UI: The web UI is web browser based user interface for QPR ProcessAnalyzer. QPR ProcessAnalyzer 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). For more information, see the list of supported Excel versions.
  • QPR ProcessAnalyzer ScriptLauncher: ScriptLauncher is a tool to trigger QPR ProcessAnalyzer SQL scripts. QPR ProcessAnalyzer ScriptLauncher can 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, and the scripts can fetch data using 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 processing component for QPR ProcessAnalyzer. It holds the models data and to store the eventlog data in the memory and performs analytical calculations for the data.
  • QPR ProcessAnalyzer Server database: Database for the QPR ProcessAnalyzer Server.
  • QPR ProcessAnalyzer scripting database: Database to run SQL scripts. QPR ProcessAnalyzer Server needs to have access to the scripting sandbox database to be used for scripting. 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 sandbox database can have a write access, to store data permanently to the database.
  • QPR ProcessAnalyzer TempDB: There is one TempDB in every SQL Server out-of-the-box. TempDB sizing and performance needs to be taken into account when running QPR ProcessAnalyzer, because the SQL scripting uses the TempDB. 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).

Database Connection

QPR ProcessAnalyzer stores its data in an SQL Server database. Connection to the database uses .NET Framework Data Provider for SQL Server (SqlClient).

In addition to the system database, QPR ProcessAnalyzer can optionally use another database for SQL scripting for ETL (more information: ETL Scripting).

Connecting to Data Sources

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

For basic analysis, Event ID, Time Stamp and Attiribute data should be available from the data source. However, depending on the customer need the analysis can be expanded by other data where all provided information can be included in the analysis be it sales person, location, customer, sale amount, time stamp for start and end of sale. The data sources can include:

  • ERP systems e.g. SAP 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

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.