QPR ProcessAnalyzer Project Workspace: Difference between revisions
(→Models) |
|||
(63 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
In QPR ProcessAnalyzer, ''dashboards'', ''models'', ''datatables'' and ''scripts'' are organized into projects. '''Project Workspace''' shows all projects in a hierarchy (on the left side) and contents of the selected project (on the right side) | In QPR ProcessAnalyzer, ''dashboards'', ''models'', ''datatables'' and ''scripts'' are organized into projects. '''Project Workspace''' shows all projects in a hierarchy (on the left side) and contents of the selected project (on the right side) divided into tabs based on the type of the entity. There are tabs for dashboards, models, datatables and scripts. Dashboards and datatables are described in this article and script are described in [[Managing Scripts]]. | ||
The Project Workspace can be opened by clicking the ''QPR Software'' logo on top left, or in the '''Home''' screen by clicking the '''Workspace''' button. All actions, such as open, create, modify and delete, are available as buttons in the toolbar and also in the context menu, which can be opened by right clicking the target project, dashboard, datatable or script. | The Project Workspace can be opened by clicking the ''QPR Software'' logo on top left, or in the '''Home''' screen by clicking the '''Workspace''' button. All actions, such as open, create, modify and delete, are available as buttons in the toolbar and also in the context menu, which can be opened by right clicking the target project, dashboard, datatable or script. | ||
The projects hierarchy can be hidden by clicking the blue ''Collapse'' button in the top of the divider, to make more space for the contents table. If the Collapse button is not visible, hover the upper side of the divider with the mouse to make the button visible. To show the projects hierarchy again, click the grey ''Expand'' button on the top left of the screen. | |||
Access control is not taking the projects hierarchy into account. If user has permissions to a project but not its parent project, the project is accessible and shown in the top level of the projects hierarchy. Moving the project is not allowed though because it requires access to the parent project. | |||
There are the following requirements for names given to objects: it cannot be empty, maximum length is 440 characters, and it cannot contain the slash (/) character. | There are the following requirements for names given to objects: it cannot be empty, maximum length is 440 characters, and it cannot contain the slash (/) character. | ||
Line 22: | Line 26: | ||
# Either select a single project on the left side hierarchy (only one can be selected), or one or several projects in the '''Projects''' tab. | # Either select a single project on the left side hierarchy (only one can be selected), or one or several projects in the '''Projects''' tab. | ||
# Click the '''Delete''' button and click '''Delete''' for the confirmation message. (The deleted project goes to the recycle bin.) | # Click the '''Delete''' button and click '''Delete''' for the confirmation message. (The deleted project goes to the recycle bin.) | ||
Note that project cannot be deleted if the project or its child projects contain the currently selected model. | |||
=== Renaming Project === | === Renaming Project === | ||
Line 30: | Line 36: | ||
=== Moving Project === | === Moving Project === | ||
Projects can be moved by dragging them with a mouse from the '''Projects''' tab to a new parent project in the left side hierarchy. Projects can also be moved by selecting the project in the left side hierarchy or in the '''Projects''' tab, selecting the '''Move''' option in the context menu, and then selecting the new parent project in the opening list of projects. | Projects can be moved by dragging them with a mouse from the '''Projects''' tab to a new parent project in the left side hierarchy. Projects can also be moved by selecting the project in the left side hierarchy or in the '''Projects''' tab, selecting the '''Move''' option in the context menu, and then selecting the new parent project in the opening list of projects. | ||
=== Project-level Snowflake Connection === | |||
[[Snowflake_Connection_Configuration#Set_Snowflake_ODBC_connection|Snowflake connection string]] can be set for each project separately, and then datatables in the project will use the project-level connection string instead of the global [[PA_Configuration_database_table#SnowflakeConnectionString|Snowflake connection string]]. Also the cache tables will be created to the location in the Snowflake defined by the project-level connection string. Note that the connection string can also be set for each datatable separately which will override the project-level connection string. Project-level connection string can be used to define following settings as project-specific: | |||
# Snowflake account | |||
# Snowflake user | |||
# Snowflake warehouse | |||
# Snowflake database and schema | |||
Project-level Snowflake connection string is set as follows: | |||
# Add a [[Storing_Secrets_for_Scripts|secret]] for the connection string using the [[QPR_ProcessAnalyzer_Objects_in_Expression_Language#SetSecret|SetSecret]] function. | |||
# Set SnowflakeConnectionStringKey property for the project referring to the secret using the [[QPR_ProcessAnalyzer_Objects_in_Expression_Language#ModifyProject|Modify]] function. | |||
==== Set connection string ==== | |||
Example script to set project-level connection string (for project with id 1): | |||
<pre> | |||
ProjectById(1) | |||
.SetSecret("externaldatatableconnection", "SnowflakeKey", `...`) | |||
.Modify(#{ | |||
"SnowflakeConnectionStringKey": "SnowflakeKey" | |||
}); | |||
</pre> | |||
==== See current settings ==== | |||
You can check the stored secrets for a project: | |||
<pre> | |||
ToJson(ProjectById(1).Secrets); | |||
</pre> | |||
You can check whether the Snowflake connection string key for a project has been set: | |||
<pre> | |||
ProjectById(1).ConfigurationJson; | |||
</pre> | |||
==== Snowflake Native App ==== | |||
When running QPR ProcessAnalyzer as Snowflake Native App, the connection string is set as partial with only following parameters: '''Database''', '''Schema''', and '''Warehouse'''. Rest of the connection string parameters are determined automatically. The partial connection string can be for example: | |||
<pre> | |||
Database=MyDatabase;Schema=MySchema;Warehouse=MyWarehouse | |||
</pre> | |||
When running QPR ProcessAnalyzer as Snowflake Native App, it's not possible to connect to other Snowflake account or use other user in the connection string. | |||
== Dashboards == | == Dashboards == | ||
Line 69: | Line 115: | ||
=== Importing Dashboard === | === Importing Dashboard === | ||
Dashboards can be exported and imported as .qprpa files containing the dashboard structure | Dashboards can be exported and imported as .qprpa files containing the dashboard structure (e.g., charts with their settings) without the actual data. A single .qprpa file can contain several dashboards. | ||
To import a | When dashboards are imported, the selected model will be set for the imported dashboards. Note also that when exporting and imported dashboards, the filter rules are preserved but the stored filter is lost (because the .qprpa files don't contain stored filters). | ||
# From the left side projects hierarchy select the project where you want to import the dashboard. | |||
Dashboard file can be imported if it has been exported using same or earlier QPR ProcessAnalyzer version. If the dashboard was exported using later version, it might not be possible to import it, if the dashboard structure supported by QPR ProcessAnalyzer has been improved between the versions. | |||
To import dashboards from a file: | |||
# From the left side projects hierarchy, select the project where you want to import the dashboard(s). | |||
# Open the '''Dashboards''' tab. | # Open the '''Dashboards''' tab. | ||
# In the header, select a model that will be used for the imported dashboards. | |||
# Click the '''New''' button, and select '''Import Dashboard'''. | # Click the '''New''' button, and select '''Import Dashboard'''. | ||
# Select a '''.qprpa file''' to be imported. | # Select a '''.qprpa file''' to be imported. | ||
# Dashboards are imported, after which they appear as selected. | |||
=== Exporting Dashboard === | === Exporting Dashboard === | ||
# Navigate to the project where the dashboard to be exported | Dashboards can be exported to a .qprpa file, and the same file can contain several dashboards. Dashboards can be exported as follows: | ||
# Open the '''Dashboards''' tab and select the dashboard. | # Navigate to the project where the dashboard(s) to be exported are located. | ||
# Click the '''Export''' button. The | # Open the '''Dashboards''' tab and select the dashboard(s). | ||
# Click the '''Export''' button. The file can is stored to disk. | |||
== Models == | == Models == | ||
'''Models''' tab shows all models in the selected project. Models can be opened, created, edited, deleted, imported and exported (you can go through an end-to-end instructions how to [[Creating_Process_Mining_Model|create model from eventlog data from a CSV file]]). | '''Models''' tab shows all models in the selected project. Models can be opened, new created, edited, deleted, imported and exported (you can go through an end-to-end instructions how to [[Creating_Process_Mining_Model|create model from eventlog data from a CSV file]]). | ||
In-memory models need to be ''online'' to use them. Model status is visible as an icon left of the model name, denoting whether the model is in the server memory or being loaded into memory. The memory capacity of the server limits how many models there can be in the memory at the same time. Also loading a model into memory might take a while depending the model size. Model is one of the following statuses: | |||
* '''Online''': Model is currently in the memory and available to dashboards and analyses. Applicable only for in-memory models. | * '''Online''' (for in-memory models): Model is currently in the memory and available to dashboards and analyses. Applicable only for in-memory models. | ||
* '''Offline''': Model is currently not the memory (and thus it's not consuming any memory resources). Applicable only for in-memory models. | * '''Offline''' (for in-memory models): Model is currently not the memory (and thus it's not consuming any memory resources). Applicable only for in-memory models. | ||
* '''Loading''': Model is currently being loaded into the memory. The loading needs to complete until the model can be used. Applicable only for in-memory models. | * '''Loading''' (for in-memory models): Model is currently being loaded into the memory. The loading needs to complete until the model can be used. Applicable only for in-memory models. | ||
* ''' | * '''Case-centric model''': Model is a (traditional) case-centric Snowflake model, and processing is done in the Snowflake. Thus the model will not be loaded into QPR ProcessAnalyzer memory and the model doesn't have any of the other statuses that are for in-memory models. | ||
* '''Object-centric model''': Model is an object-centric Snowflake model, and processing is done in the Snowflake. | |||
* (no icon): When no icon is shown, datasource for the model hasn't been defined and the model cannot yet be used. To define the datasource, open the [[#Editing_Model_Settings|model properties]] and configure the events and cases datasources. | |||
Note that in QPR ProcessAnalyzer, all processing is performed in the server/cloud side, so the model does not need to be loaded into user workstation, and thus it doesn't consume resources in the workstation side. | Note that in QPR ProcessAnalyzer, all processing is performed in the server/cloud side, so the model does not need to be loaded into user workstation, and thus it doesn't consume resources in the workstation side. | ||
Line 99: | Line 154: | ||
=== Editing Model Settings === | === Editing Model Settings === | ||
Model level settings are organized into following dialogs: Properties (general settings), Attributes, Notifications and Business calendar. Most settings can be changed while the model is in the memory, but changing datasource related settings and attribute settings will drop the model from the memory. | Model level settings are organized into following dialogs: Properties (general settings), Attributes, Notifications and Business calendar. Most settings can be changed while the model is in the memory, but changing datasource related settings and attribute settings will drop the model from the memory. | ||
# Select the project where the model is located. | # Select the project where the model is located. | ||
# Open the '''Models''' tab. | # Open the '''Models''' tab. | ||
# Select the model and select one of the following options: '''Properties''', '''Attributes''', '''Notifications''' or '''Business Calendar''' | # Select the model and select one of the following options: '''Properties''', '''Attributes''', '''Notifications''' or '''Business Calendar'''. | ||
# After viewing or editing properties, close the dialog by clicking '''OK'''. | # After viewing or editing properties, close the dialog by clicking '''OK'''. | ||
See more about model level settings: | See more about model level settings: | ||
* [[QPR_ProcessAnalyzer_Model_Datasources|Setting up datasources]] | * [[QPR_ProcessAnalyzer_Model_Datasources|Setting up datasources]] | ||
* [[ | * [[Business_Calendar|Business calendar]] | ||
* [[Calculated_Attributes_in_QPR_ProcessAnalyzer|Calculated case and event attributes]] | * [[Calculated_Attributes_in_QPR_ProcessAnalyzer|Calculated case and event attributes]] | ||
* [[Email_Notifications|Email notifications]] | * [[Email_Notifications|Email notifications]] | ||
Note that Attributes, Notifications | * [[Case_Level_Permissions|Case level permissions]] | ||
Note that Attributes, Notifications and Case level permissions are not available for Snowflake models. | |||
=== Loading, Dropping and Reloading Model === | === Loading, Dropping and Reloading Model === | ||
Line 128: | Line 183: | ||
=== Deleting Model === | === Deleting Model === | ||
When a model is deleted, it's not permanently removed, and can be recovered from the [[#Recycle_Bin|recycle bin]]. Note that possible datatables used by the deleted models, are not deleted. Steps to delete models: | When a model is deleted, it's not permanently removed, and can be recovered from the [[#Recycle_Bin|recycle bin]]. Note that possible datatables used by the deleted models, are not deleted. Note also that the currently selected model cannot be deleted. | ||
Steps to delete models: | |||
# Select the project where the model(s) to be deleted are located. | # Select the project where the model(s) to be deleted are located. | ||
# Open the '''Models''' tab. | # Open the '''Models''' tab. | ||
Line 145: | Line 202: | ||
=== Duplicating Model === | === Duplicating Model === | ||
Steps to duplicate a model: | |||
# Select the project where the model to be duplicated is located. | # Select the project where the model to be duplicated is located. | ||
# Open the '''Models''' tab. | # Open the '''Models''' tab. | ||
# Select the model to be duplicated. | # Select the model to be duplicated. | ||
# Click the '''Duplicate''' button. A duplicate of the model is created. | # Click the '''Duplicate''' button. A duplicate of the model is created. | ||
Notes: | |||
* When a model is duplicated, datatables used by the model, are not duplicated. Thus, the duplicate model will refer to the same datatables as the original model. Datatables can be duplicated separately if desired. | |||
* The model may contain [[Filtering_in_QPR_ProcessAnalyzer|filters]] which are duplicated with the model. Only those filters that the user making the duplicate can see, are duplicated. | |||
=== Importing Model === | === Importing Model === | ||
Models can be imported in .pacm and .xes formats. Importing a file creates a new model, so it's not possible to import data to an existing model. | |||
Steps to import model: | Steps to import model: | ||
Line 158: | Line 219: | ||
# Open the '''Models''' tab. | # Open the '''Models''' tab. | ||
# Click the '''New''' button, and select '''Import Model'''. | # Click the '''New''' button, and select '''Import Model'''. | ||
# Select a | # Select a .pacm or .xes file to be imported. | ||
=== Exporting Model === | === Exporting Model === | ||
Line 169: | Line 230: | ||
'''Datatables''' store tabular data in QPR ProcessAnalyzer. Datatables containing events and cases data, can be loaded into a model by selecting an events and cases datatable for the model. Datatables can also be used as part of the ETL process to store intermediate results. Datatables can be created, moved and deleted in the '''Datatables''' tab, which shows all datatables in the selected project. | '''Datatables''' store tabular data in QPR ProcessAnalyzer. Datatables containing events and cases data, can be loaded into a model by selecting an events and cases datatable for the model. Datatables can also be used as part of the ETL process to store intermediate results. Datatables can be created, moved and deleted in the '''Datatables''' tab, which shows all datatables in the selected project. | ||
Datatables can be stored | Datatables can be stored in either SQL Server or, if the [[Snowflake Connection Configuration|Snowflake connection]] is available, datatables can be created to the Snowflake, which enables to create models that perform calculations in the Snowflake. Snowflake datatables can be distinguished in the Workspace by the snowflake icon (left of the datatable name). If both SQL Server and Snowflake connections are available, the datasource needs to be selected (either SqlServer or Snowflake), and after that managing the datatables, such as importing data, moving, renaming and deleting, works identically between the SQL Server or Snowflake datatables. | ||
To create datatables, the global ''Create models'' permissions is needed (by default system administrators have it), and for deleting datatables, the project-specific ''Delete models'' permission is needed (by default projects administrators have it). | To create datatables, the global ''Create models'' permissions is needed (by default system administrators have it), and for deleting datatables, the project-specific ''Delete models'' permission is needed (by default projects administrators have it). | ||
Datatable names need to be unique within a project. Datatables stored to SQL Server have the following limitations: Maximum number of columns in a datatable is '''300''', and maximum string length that can be stored into a datatable cell is '''4000''' characters. | |||
=== Opening Datatable === | === Opening Datatable === | ||
Line 189: | Line 250: | ||
* Dimensioning can be taken into use which will show the '''Measures''' tab (for more information, see the [[QPR_ProcessAnalyzer_Chart#Introduction|chart]]. | * Dimensioning can be taken into use which will show the '''Measures''' tab (for more information, see the [[QPR_ProcessAnalyzer_Chart#Introduction|chart]]. | ||
* Datatable can be exported as an .xlsx or .csv file. | * Datatable can be exported as an .xlsx or .csv file. | ||
=== Changing Datatable Properties === | |||
Datatable properties can be viewed and edited in the [[Datatable_Properties_Dialog|Datatable properties dialog]] that can be opened by selecting a datatable and clicking '''Properties'''. | |||
=== Creating Datatable === | === Creating Datatable === | ||
Line 194: | Line 258: | ||
# Open the '''Datatables''' tab. | # Open the '''Datatables''' tab. | ||
# Click the '''New''' button and click '''Datatable'''. | # Click the '''New''' button and click '''Datatable'''. | ||
# Define '''Name | # Define '''Name''' for the datatable. Note that datatable names must be unique within the project. | ||
# Define the '''Datasource''' for the datatable as either '''Snowflake''' (for storing and processing data in Snowflake) or '''Local''' (for storing data in SQL Server and processing in-memory). If either the [[Snowflake Connection Configuration|Snowflake]] or [[PA_Configuration_database_table#SqlServerConnectionString|SQL Server storage]] is not available, this selection is not available and the datatable will be created to the location that is available. If neither are available, datatables cannot be created. | |||
# Click '''Create'''. | # Click '''Create'''. | ||
Line 203: | Line 268: | ||
# Check the suggested data type and conversion settings for the columns, and adjust them if needed. You can import data to the existing datatable columns, new datatable columns, or ignore individual CSV file columns in the import (see: [[Importing_Data_to_Datatable_from_CSV_File|CSV file import]]). | # Check the suggested data type and conversion settings for the columns, and adjust them if needed. You can import data to the existing datatable columns, new datatable columns, or ignore individual CSV file columns in the import (see: [[Importing_Data_to_Datatable_from_CSV_File|CSV file import]]). | ||
# Click '''Start import'''. | # Click '''Start import'''. | ||
=== Refreshing Datatable from Datasource === | |||
When a database table behind a datatable is changed, the datatable needs to be refreshed from the datasource (such as Snowflake) to get the data current status to QPR ProcessAnalyzer. Typically the refresh is done after ETL run to load new data has completed. The refresh is the same operation is [[Datatable_in_Expression_Language#Datatable_Functions|Synchronize]] in the expression language. | |||
Refresh can be done as follows in the UI: | |||
# Select the project where the datatable(s) to be refreshed are located. | |||
# Open the '''Datatables''' tab. | |||
# Select one or several datatables to be refreshed. | |||
# Click the '''Refresh from datasource''' button. | |||
=== Deleting Datatable === | === Deleting Datatable === | ||
Line 208: | Line 282: | ||
# Open the '''Datatables''' tab. | # Open the '''Datatables''' tab. | ||
# Select one or several datatables to be deleted. | # Select one or several datatables to be deleted. | ||
# Click the '''Delete''' button and click '''Delete''' to the confirmation message. | # Click the '''Delete datatable''' button and click '''Delete''' to the confirmation message. | ||
=== Deleting Datatable Rows === | |||
When a datatable rows are deleted, the datatable itself is preserved including its columns (column names and data types). Datatable rows can be deleted, e.g., when importing the data again from a CSV file. | |||
Datatable rows can be deleted as follows: | |||
# Select the project where the datatable(s) where to delete rows are located. | |||
# Open the '''Datatables''' tab. | |||
# Select one or several datatables to be deleted. | |||
# Click the '''Delete all rows''' button and click '''Delete''' to the confirmation message. | |||
=== Renaming Datatable === | === Renaming Datatable === | ||
Line 222: | Line 305: | ||
=== Duplicating Datatable === | === Duplicating Datatable === | ||
Datatable duplication (copying) creates a full copy of the datatable where also the data contents is duplicated. If the datatable contains lot of data, duplicating the data might take some time. Copying the data from the original datatable to the new datatable is performed in the background, so the user doesn't need to wait for it. Note that during the data copying, the workspace might temporarily show that the new datatable has less rows than the original. | Datatable duplication (copying) creates a full copy of the datatable where also the data contents is duplicated. If the datatable contains lot of data, duplicating the data might take some time. Copying the data from the original datatable to the new datatable is performed in the background, so the user doesn't need to wait for it. Note that during the data copying, the workspace might temporarily show that the new datatable has less rows than the original. | ||
When duplicating a Snowflake datatable that uses a [[Datatable_Properties_Dialog#Data_location|custom table]], the duplicate datatable will refer to the same table in Snowflake (and not create a new table). | |||
# Select the project where the datatable to be duplicated is located. | # Select the project where the datatable to be duplicated is located. | ||
Line 247: | Line 332: | ||
# Click '''Bin''' in the left side projects hierarchy. | # Click '''Bin''' in the left side projects hierarchy. | ||
# Select items in the recycle bin that you want to restore. | # Select items in the recycle bin that you want to restore. | ||
# Click the '''Restore''' button. | # Click the '''Restore''' button. | ||
Selected items are restored to their original locations. | |||
[[Category: QPR ProcessAnalyzer]] | [[Category: QPR ProcessAnalyzer]] |
Latest revision as of 18:20, 17 October 2024
In QPR ProcessAnalyzer, dashboards, models, datatables and scripts are organized into projects. Project Workspace shows all projects in a hierarchy (on the left side) and contents of the selected project (on the right side) divided into tabs based on the type of the entity. There are tabs for dashboards, models, datatables and scripts. Dashboards and datatables are described in this article and script are described in Managing Scripts.
The Project Workspace can be opened by clicking the QPR Software logo on top left, or in the Home screen by clicking the Workspace button. All actions, such as open, create, modify and delete, are available as buttons in the toolbar and also in the context menu, which can be opened by right clicking the target project, dashboard, datatable or script.
The projects hierarchy can be hidden by clicking the blue Collapse button in the top of the divider, to make more space for the contents table. If the Collapse button is not visible, hover the upper side of the divider with the mouse to make the button visible. To show the projects hierarchy again, click the grey Expand button on the top left of the screen.
Access control is not taking the projects hierarchy into account. If user has permissions to a project but not its parent project, the project is accessible and shown in the top level of the projects hierarchy. Moving the project is not allowed though because it requires access to the parent project.
There are the following requirements for names given to objects: it cannot be empty, maximum length is 440 characters, and it cannot contain the slash (/) character.
Projects
Projects are organized into a hierarchy, where projects can contain child projects. The hierarchy is visible in the left side of the workspace, where a project can be selected to see its contents on the right side. In addition, there is the Projects tab showing child projects of the selected project.
Opening Project
Project can be opened in the workspace to see its contents, by clicking the project in the left side hierarchy. Alternatively the Projects tab can be used browse projects by drilling down into child projects by double-clicking projects.
Creating Project
- On the left side projects hierarchy, select the project where you want to create a new project.
- Click the New button and click Project.
- Define a name for the projects and click Create.
Deleting Project
- Either select a single project on the left side hierarchy (only one can be selected), or one or several projects in the Projects tab.
- Click the Delete button and click Delete for the confirmation message. (The deleted project goes to the recycle bin.)
Note that project cannot be deleted if the project or its child projects contain the currently selected model.
Renaming Project
- Select the project to be renamed either in the left side hierarchy or in the Projects tab.
- Click the Rename button.
- Change the project name in the opening dialog and click OK.
Moving Project
Projects can be moved by dragging them with a mouse from the Projects tab to a new parent project in the left side hierarchy. Projects can also be moved by selecting the project in the left side hierarchy or in the Projects tab, selecting the Move option in the context menu, and then selecting the new parent project in the opening list of projects.
Project-level Snowflake Connection
Snowflake connection string can be set for each project separately, and then datatables in the project will use the project-level connection string instead of the global Snowflake connection string. Also the cache tables will be created to the location in the Snowflake defined by the project-level connection string. Note that the connection string can also be set for each datatable separately which will override the project-level connection string. Project-level connection string can be used to define following settings as project-specific:
- Snowflake account
- Snowflake user
- Snowflake warehouse
- Snowflake database and schema
Project-level Snowflake connection string is set as follows:
- Add a secret for the connection string using the SetSecret function.
- Set SnowflakeConnectionStringKey property for the project referring to the secret using the Modify function.
Set connection string
Example script to set project-level connection string (for project with id 1):
ProjectById(1) .SetSecret("externaldatatableconnection", "SnowflakeKey", `...`) .Modify(#{ "SnowflakeConnectionStringKey": "SnowflakeKey" });
See current settings
You can check the stored secrets for a project:
ToJson(ProjectById(1).Secrets);
You can check whether the Snowflake connection string key for a project has been set:
ProjectById(1).ConfigurationJson;
Snowflake Native App
When running QPR ProcessAnalyzer as Snowflake Native App, the connection string is set as partial with only following parameters: Database, Schema, and Warehouse. Rest of the connection string parameters are determined automatically. The partial connection string can be for example:
Database=MyDatabase;Schema=MySchema;Warehouse=MyWarehouse
When running QPR ProcessAnalyzer as Snowflake Native App, it's not possible to connect to other Snowflake account or use other user in the connection string.
Dashboards
Dashboards can be created, opened, moved, deleted, imported and exported in the Dashboards tab, which shows all dashboards in the selected project.
Opening Dashboard
- Select the project where the dashboard to be opened is located.
- Open the Dashboards tab.
- Double-click the dashboard in the list, or select the dashboard with a single click and click the Open button.
Creating Dashboard
- On the left side projects hierarchy, select the project where you want to create the dashboard.
- Open the Dashboards tab.
- Click the New button and click Dashboard. The dashboard designer opens.
- The dashboard can be named by opening the menu on the right and clicking Dashboard properties. The name can be defined in the General tab. The dialog can be closed by clicking the Done button.
- The dashboard is saved when clicking the Save button.
Deleting Dashboard
- Select the project where the dashboard(s) to be deleted are located.
- Open the Dashboards tab.
- Select one or several dashboards to be deleted.
- Click the Delete button and click Delete to the confirmation message.
Renaming Dashboard
- Select the project where the dashboard to be renamed is located.
- Open the Dashboards tab.
- Select the dashboard to be renamed.
- Click the Rename button.
- Change the dashboard name in the opening dialog and click OK.
Moving Dashboard
Dashboards can be moved by dragging them with a mouse from the right side list to the target project in the left side hierarchy. Alternatively, dashboards to be moved can be selected and from the context menu, select Move to and then select the target project.
Duplicating Dashboard
- Select the project where the dashboard to be duplicated is located.
- Open the Dashboards tab.
- Select the dashboard to be duplicated.
- Click the Duplicate button. A duplicate of the dashboard is created.
Importing Dashboard
Dashboards can be exported and imported as .qprpa files containing the dashboard structure (e.g., charts with their settings) without the actual data. A single .qprpa file can contain several dashboards.
When dashboards are imported, the selected model will be set for the imported dashboards. Note also that when exporting and imported dashboards, the filter rules are preserved but the stored filter is lost (because the .qprpa files don't contain stored filters).
Dashboard file can be imported if it has been exported using same or earlier QPR ProcessAnalyzer version. If the dashboard was exported using later version, it might not be possible to import it, if the dashboard structure supported by QPR ProcessAnalyzer has been improved between the versions.
To import dashboards from a file:
- From the left side projects hierarchy, select the project where you want to import the dashboard(s).
- Open the Dashboards tab.
- In the header, select a model that will be used for the imported dashboards.
- Click the New button, and select Import Dashboard.
- Select a .qprpa file to be imported.
- Dashboards are imported, after which they appear as selected.
Exporting Dashboard
Dashboards can be exported to a .qprpa file, and the same file can contain several dashboards. Dashboards can be exported as follows:
- Navigate to the project where the dashboard(s) to be exported are located.
- Open the Dashboards tab and select the dashboard(s).
- Click the Export button. The file can is stored to disk.
Models
Models tab shows all models in the selected project. Models can be opened, new created, edited, deleted, imported and exported (you can go through an end-to-end instructions how to create model from eventlog data from a CSV file).
In-memory models need to be online to use them. Model status is visible as an icon left of the model name, denoting whether the model is in the server memory or being loaded into memory. The memory capacity of the server limits how many models there can be in the memory at the same time. Also loading a model into memory might take a while depending the model size. Model is one of the following statuses:
- Online (for in-memory models): Model is currently in the memory and available to dashboards and analyses. Applicable only for in-memory models.
- Offline (for in-memory models): Model is currently not the memory (and thus it's not consuming any memory resources). Applicable only for in-memory models.
- Loading (for in-memory models): Model is currently being loaded into the memory. The loading needs to complete until the model can be used. Applicable only for in-memory models.
- Case-centric model: Model is a (traditional) case-centric Snowflake model, and processing is done in the Snowflake. Thus the model will not be loaded into QPR ProcessAnalyzer memory and the model doesn't have any of the other statuses that are for in-memory models.
- Object-centric model: Model is an object-centric Snowflake model, and processing is done in the Snowflake.
- (no icon): When no icon is shown, datasource for the model hasn't been defined and the model cannot yet be used. To define the datasource, open the model properties and configure the events and cases datasources.
Note that in QPR ProcessAnalyzer, all processing is performed in the server/cloud side, so the model does not need to be loaded into user workstation, and thus it doesn't consume resources in the workstation side.
Opening Model
- Select the project where the model to be opened is located.
- Open the Models tab.
- Double-click the model in the list, or select the model with a single click and click the Open button. Model is opened in the Process Discovery view.
Editing Model Settings
Model level settings are organized into following dialogs: Properties (general settings), Attributes, Notifications and Business calendar. Most settings can be changed while the model is in the memory, but changing datasource related settings and attribute settings will drop the model from the memory.
- Select the project where the model is located.
- Open the Models tab.
- Select the model and select one of the following options: Properties, Attributes, Notifications or Business Calendar.
- After viewing or editing properties, close the dialog by clicking OK.
See more about model level settings:
- Setting up datasources
- Business calendar
- Calculated case and event attributes
- Email notifications
- Case level permissions
Note that Attributes, Notifications and Case level permissions are not available for Snowflake models.
Loading, Dropping and Reloading Model
This functionality is only available for in-memory models.
- Select the project where the model is located.
- Open the Models tab.
- Select the model and select one of the following options:
- Load to start loading the model into memory. This option is available when the model is offline.
- Drop to drop the model from the memory (for example to free memory resources). This option is available when the model is online or loading.
- Reload to reload the model into the memory (i.e. drop and immediately start loading). Reloading is needed in order to get the latest data into the model after new data is imported to datatables. This option is available when the model is online or loading.
Creating Model
- On the left side projects hierarchy, select the project where you want to create the model.
- Open the Models tab.
- Click the New button and click Model. Define a name for the model and click Create. Note that model names must be unique within a project.
Deleting Model
When a model is deleted, it's not permanently removed, and can be recovered from the recycle bin. Note that possible datatables used by the deleted models, are not deleted. Note also that the currently selected model cannot be deleted.
Steps to delete models:
- Select the project where the model(s) to be deleted are located.
- Open the Models tab.
- Select one or several models to be deleted.
- Click the Delete button and click Delete to the confirmation message.
Renaming Model
- Select the project where the model to be renamed is located.
- Open the Models tab.
- Select the model to be renamed.
- Click the Rename button.
- Change the model name in the opening dialog and click OK.
Moving Model
Models can be moved by dragging them with a mouse from the right side list to the target project in the left side hierarchy. Alternatively, models to be moved can be selected, from the context menu select Move to and then select the target project.
Duplicating Model
Steps to duplicate a model:
- Select the project where the model to be duplicated is located.
- Open the Models tab.
- Select the model to be duplicated.
- Click the Duplicate button. A duplicate of the model is created.
Notes:
- When a model is duplicated, datatables used by the model, are not duplicated. Thus, the duplicate model will refer to the same datatables as the original model. Datatables can be duplicated separately if desired.
- The model may contain filters which are duplicated with the model. Only those filters that the user making the duplicate can see, are duplicated.
Importing Model
Models can be imported in .pacm and .xes formats. Importing a file creates a new model, so it's not possible to import data to an existing model.
Steps to import model:
- From the left side projects hierarchy select the project where you want to import the model.
- Open the Models tab.
- Click the New button, and select Import Model.
- Select a .pacm or .xes file to be imported.
Exporting Model
Models can be exported to a .pacm file (QPR ProcessAnalyzer compressed model file) to easily move models between QPR ProcessAnalyzer environments. The file contains all the eventlog data and also all model related settings. Steps to export:
- Navigate to the project where the model to be exported is located.
- Open the Models tab and select the model.
- Click the Export button. The exported file can be downloaded.
Datatables
Datatables store tabular data in QPR ProcessAnalyzer. Datatables containing events and cases data, can be loaded into a model by selecting an events and cases datatable for the model. Datatables can also be used as part of the ETL process to store intermediate results. Datatables can be created, moved and deleted in the Datatables tab, which shows all datatables in the selected project.
Datatables can be stored in either SQL Server or, if the Snowflake connection is available, datatables can be created to the Snowflake, which enables to create models that perform calculations in the Snowflake. Snowflake datatables can be distinguished in the Workspace by the snowflake icon (left of the datatable name). If both SQL Server and Snowflake connections are available, the datasource needs to be selected (either SqlServer or Snowflake), and after that managing the datatables, such as importing data, moving, renaming and deleting, works identically between the SQL Server or Snowflake datatables.
To create datatables, the global Create models permissions is needed (by default system administrators have it), and for deleting datatables, the project-specific Delete models permission is needed (by default projects administrators have it).
Datatable names need to be unique within a project. Datatables stored to SQL Server have the following limitations: Maximum number of columns in a datatable is 300, and maximum string length that can be stored into a datatable cell is 4000 characters.
Opening Datatable
Datatable contents can be viewed as follows:
- On the left side projects hierarchy, select the project where the datatable to be opened is located.
- Open the Datatables tab.
- Double-click the datatable in the list, or select the datatable with a single click and click the Open button.
- If you want to change the shown information, click the Settings button and edit the settings.
- The dialog can be closed by clicking Close button.
Following settings are available:
- Visible columns can be removed and changed in the Columns tab.
- Number of shows row can be changed.
- Sorting of the data can be changed.
- Dimensioning can be taken into use which will show the Measures tab (for more information, see the chart.
- Datatable can be exported as an .xlsx or .csv file.
Changing Datatable Properties
Datatable properties can be viewed and edited in the Datatable properties dialog that can be opened by selecting a datatable and clicking Properties.
Creating Datatable
- On the left side projects hierarchy, select the project where you want to create a datatable.
- Open the Datatables tab.
- Click the New button and click Datatable.
- Define Name for the datatable. Note that datatable names must be unique within the project.
- Define the Datasource for the datatable as either Snowflake (for storing and processing data in Snowflake) or Local (for storing data in SQL Server and processing in-memory). If either the Snowflake or SQL Server storage is not available, this selection is not available and the datatable will be created to the location that is available. If neither are available, datatables cannot be created.
- Click Create.
Importing Data to Datatable from CSV File
- On the left side projects hierarchy, select the project where the target datatable is located.
- Open the Datatables tab, and select the datatable where to import data.
- Click the Import button, and select the CSV file to be imported.
- Check the suggested data type and conversion settings for the columns, and adjust them if needed. You can import data to the existing datatable columns, new datatable columns, or ignore individual CSV file columns in the import (see: CSV file import).
- Click Start import.
Refreshing Datatable from Datasource
When a database table behind a datatable is changed, the datatable needs to be refreshed from the datasource (such as Snowflake) to get the data current status to QPR ProcessAnalyzer. Typically the refresh is done after ETL run to load new data has completed. The refresh is the same operation is Synchronize in the expression language.
Refresh can be done as follows in the UI:
- Select the project where the datatable(s) to be refreshed are located.
- Open the Datatables tab.
- Select one or several datatables to be refreshed.
- Click the Refresh from datasource button.
Deleting Datatable
- Select the project where the datatable(s) to be deleted are located.
- Open the Datatables tab.
- Select one or several datatables to be deleted.
- Click the Delete datatable button and click Delete to the confirmation message.
Deleting Datatable Rows
When a datatable rows are deleted, the datatable itself is preserved including its columns (column names and data types). Datatable rows can be deleted, e.g., when importing the data again from a CSV file.
Datatable rows can be deleted as follows:
- Select the project where the datatable(s) where to delete rows are located.
- Open the Datatables tab.
- Select one or several datatables to be deleted.
- Click the Delete all rows button and click Delete to the confirmation message.
Renaming Datatable
- Select the project where the datatable to be renamed is located.
- Open the Datatables tab.
- Select the datatable to be renamed.
- Click the Rename button.
- Change the datatable name in the opening dialog and click OK.
Moving Datatable
Datatables can be moved by dragging them with a mouse from the right side list to the target project in the left side hierarchy. Alternatively, datatables to be moved can be selected, from the context menu select Move to and then select the target project.
Duplicating Datatable
Datatable duplication (copying) creates a full copy of the datatable where also the data contents is duplicated. If the datatable contains lot of data, duplicating the data might take some time. Copying the data from the original datatable to the new datatable is performed in the background, so the user doesn't need to wait for it. Note that during the data copying, the workspace might temporarily show that the new datatable has less rows than the original.
When duplicating a Snowflake datatable that uses a custom table, the duplicate datatable will refer to the same table in Snowflake (and not create a new table).
- Select the project where the datatable to be duplicated is located.
- Open the Datatables tab.
- Select the datatable to be duplicated.
- Click the Duplicate button. A duplicate of the datatable is created.
Recycle Bin
Deleted projects and models go to the Recycle bin, where they can be either deleted forever or restored. Purpose of the recycle bin is that accidentally deleted items can still be restored. Note that currently dashboards and scripts don't go to the recycle bin, but they are deleted forever right away. Note also that when a project is deleted (moved to the recycle bin), also models in the project appear in the recycle bin.
Only the system administrators can see the recycle bin, and delete forever and restore items from there.
Emptying Recycle Bin
- Click Bin in the left side projects hierarchy.
- Click the Empty bin button on top right.
- Click Delete forever for the confirmation dialog.
Deleting Items Forever
- Click Bin in the left side projects hierarchy.
- Select items in the recycle bin that you want to delete forever.
- Click the Delete forever button.
- Click Delete forever for the confirmation dialog.
Restoring Items
- Click Bin in the left side projects hierarchy.
- Select items in the recycle bin that you want to restore.
- Click the Restore button.
Selected items are restored to their original locations.