QPR ProcessAnalyzer Project Workspace - Revision history

TeeHiet: TK-63602

2026-04-16T12:36:31Z

TK-63602

← Older revision		Revision as of 12:36, 16 April 2026
Line 348:		Line 348:
	# Select the datatable to be duplicated.		# Select the datatable to be duplicated.
	# Click the '''Duplicate''' button. A duplicate of the datatable is created.		# Click the '''Duplicate''' button. A duplicate of the datatable is created.

			== Data Schema ==
			See [[Data Schema Dialog]].

	== Bin ==		== Bin ==

Ollvihe: /* Exporting Project */

2026-04-02T18:48:29Z

Exporting Project

← Older revision		Revision as of 18:48, 2 April 2026
Line 52:		Line 52:
	# The project is exported to a file.		# The project is exported to a file.

	Notes about ~~exporting projects~~:		Notes about the project export files:
	* Export files don't contain object ID's, and new ID's are created in the import. If there are scripts that refer to objects by their ID's, the imported scripts won't work. It's a good practice to write scripts to refer to other objects by their names rather than ID's.		* Export files don't contain object ID's, and new ID's are created in the import. If there are scripts that refer to objects by their ID's, the imported scripts won't work. It's a good practice to write scripts to refer to other objects by their names rather than ID's.
	* In the export file, the ''ModelId'' dashboard variable is replaced with the ''ModelName'' variable containing the model name. In the import, the ''ModelName'' variable is replaced by the ''ModelId'' variable referring to a corresponding model created in the import. This is required because model ID's are not part of the export file, and the model name is used to refer to the model. This replacement is not supported by the chart-specific model selection, so the setting needs to be set manually after the import.		* In the export file, the ''ModelId'' dashboard variable is replaced with the ''ModelName'' variable containing the model name. In the import, the ''ModelName'' variable is replaced by the ''ModelId'' variable referring to a corresponding model created in the import. This is required because model ID's are not part of the export file, and the model name is used to refer to the model. This replacement is not supported by the chart-specific model selection, so the setting needs to be set manually after the import.

Ollvihe: /* Exporting Project */

2026-04-02T18:47:37Z

Exporting Project

← Older revision		Revision as of 18:47, 2 April 2026
Line 53:		Line 53:

	Notes about exporting projects:		Notes about exporting projects:
	* ~~New id~~'s ~~for all objects~~ are ~~generated~~ in the import. If there are scripts that refer to objects by their id's, the imported scripts ~~might not~~ work. It's a good practice to write scripts to refer to other objects by their names rather than id's.		* Export files don't contain object ID's, and new ID's are created in the import. If there are scripts that refer to objects by their ID's, the imported scripts won't work. It's a good practice to write scripts to refer to other objects by their names rather than ID's.
			* In the export file, the ''ModelId'' dashboard variable is replaced with the ''ModelName'' variable containing the model name. In the import, the ''ModelName'' variable is replaced by the ''ModelId'' variable referring to a corresponding model created in the import. This is required because model ID's are not part of the export file, and the model name is used to refer to the model. This replacement is not supported by the chart-specific model selection, so the setting needs to be set manually after the import.
	* Child projects are not part of the export file.		* Child projects are not part of the export file.
	* The public and default filters or the model are exported.
	* Project permissions are not part of the export file.		* Project permissions are not part of the export file.
			* Project secrets are not part of the export file.
			* Private filters are not part of the export file.
	* Datatables data is not part of the export file. If you also want to export data, use the CSV export. If the data is in Snowflake and there is great amount of data, it's recommended to use Snowflake tools for exporting and importing data.		* Datatables data is not part of the export file. If you also want to export data, use the CSV export. If the data is in Snowflake and there is great amount of data, it's recommended to use Snowflake tools for exporting and importing data.
	* In the export file, the ''ModelId'' dashboard variable is replaced with the ''ModelName'' variable containing the model name. In the import, the ''ModelName'' variable is replaced by the ''ModelId'' variable referring to a corresponding model created in the import. This needs to be done because model id's are not part of the import, and the model name is the method to refer to the model. This replacement is not supported by the chart-specific model selection, so the setting needs to be set manually after the import.

	=== Importing Project ===		=== Importing Project ===

TeeHiet: TK-63223

2026-03-31T11:13:02Z

TK-63223

← Older revision		Revision as of 11:13, 31 March 2026
Line 55:		Line 55:
	* New id's for all objects are generated in the import. If there are scripts that refer to objects by their id's, the imported scripts might not work. It's a good practice to write scripts to refer to other objects by their names rather than id's.		* New id's for all objects are generated in the import. If there are scripts that refer to objects by their id's, the imported scripts might not work. It's a good practice to write scripts to refer to other objects by their names rather than id's.
	* Child projects are not part of the export file.		* Child projects are not part of the export file.
	* ~~Model's~~ filters are ~~not part of the export file~~.		* The public and default filters or the model are exported.
	* Project permissions are not part of the export file.		* Project permissions are not part of the export file.
	* Datatables data is not part of the export file. If you also want to export data, use the CSV export. If the data is in Snowflake and there is great amount of data, it's recommended to use Snowflake tools for exporting and importing data.		* Datatables data is not part of the export file. If you also want to export data, use the CSV export. If the data is in Snowflake and there is great amount of data, it's recommended to use Snowflake tools for exporting and importing data.

TeeHiet: TK-61208

2025-09-23T09:36:46Z

TK-61208

← Older revision		Revision as of 09:36, 23 September 2025
Line 167:		Line 167:
	* [[Email_Notifications\|Email notifications]] (only for in-memory models)		* [[Email_Notifications\|Email notifications]] (only for in-memory models)
	* [[Case_Level_Permissions\|Case level permissions]] (only for in-memory models)		* [[Case_Level_Permissions\|Case level permissions]] (only for in-memory models)

			=== Hiding Object Count Statistics ===
			To help optimize the model for performance, it's possible to hide the object count statistics information in dropdown menus. To do this:
			# Select the project where the model is located.
			# Open the '''Models''' tab.
			# Select the model and select '''Properties'''.
			# Switch to the '''Details''' tab.
			# Remove the selection from '''Show Object Count Statistics'''.
			The Show Object Count Statistics setting can be overridden in [[Chart_On-screen_Settings#Configuration\|Chart On-screen Settings]].

	=== Change Snowflake Warehouse for Model===		=== Change Snowflake Warehouse for Model===

Ollvihe: /* Change Snowflake Warehouse for Model */

2025-09-17T14:14:04Z

Change Snowflake Warehouse for Model

← Older revision		Revision as of 14:14, 17 September 2025
Line 169:		Line 169:

	=== Change Snowflake Warehouse for Model===		=== Change Snowflake Warehouse for Model===
	The Snowflake warehouse can be specified for a specific model. When defined, all queries for that model originating from dashboards use the specified warehouse instead of the (default) warehouse from the [[PA_Configuration_database_table#SnowflakeConnectionString\|Snowflake connection string]]. You can use smaller warehouse for smaller models, and a larger warehouse for large models, to optimize costs and achieve similar performance for different sizes of models. When leaving the model's warehouse setting empty, the default warehouse in the Snowflake connection string will be used~~. In case an invalid warehouse is defined, a "No active warehouse selected in the current session. Select an active warehouse with the 'use warehouse' command." error message will be shown~~.		The Snowflake warehouse can be specified for a specific model. When defined, all queries for that model originating from dashboards use the specified warehouse instead of the (default) warehouse from the [[PA_Configuration_database_table#SnowflakeConnectionString\|Snowflake connection string]]. You can use smaller warehouse for smaller models, and a larger warehouse for large models, to optimize costs and achieve similar performance for different sizes of models. When leaving the model's warehouse setting empty, the default warehouse in the Snowflake connection string will be used.

	A good practice is to use a smaller Snowflake warehouse as the default warehouse, and specify a larger warehouse for specific models that need it due to performance. Note that different warehouses should not be used unnecessarily because a common warehouse used by multiple models serves as a shared resource for all the usage which may be more cost effective than using different warehouses.		A good practice is to use a smaller Snowflake warehouse as the default warehouse, and specify a larger warehouse for specific models that need it due to performance. Note that different warehouses should not be used unnecessarily because a common warehouse used by multiple models serves as a shared resource for all the usage which may be more cost effective than using different warehouses.

	Note that the Snowflake user used by QPR ProcessAnalyzer to access Snowflake needs to have permissions to use the specified warehouse. If there are no permissions or the specified warehouse doesn't exist in the Snowflake account, there will be an error message ~~about~~ an ~~unspecified~~ warehouse.		Note that the Snowflake user used by QPR ProcessAnalyzer to access Snowflake needs to have permissions to use the specified warehouse. If there are no permissions or the specified warehouse doesn't exist in the Snowflake account, there will be an error message: "No active warehouse selected in the current session. Select an active warehouse with the 'use warehouse' command."

	Model's warehouse can be changed as follows:		Model's warehouse can be changed as follows:

Ollvihe: /* Change Snowflake Warehouse for Model */

2025-09-17T14:12:52Z

Change Snowflake Warehouse for Model

← Older revision		Revision as of 14:12, 17 September 2025
Line 169:		Line 169:

	=== Change Snowflake Warehouse for Model===		=== Change Snowflake Warehouse for Model===
	The Snowflake warehouse can be specified for a specific model. When defined, all queries for that model originating from dashboards use the specified warehouse instead of the (default) warehouse from the Snowflake connection string. You can use smaller warehouse for smaller models, and a larger warehouse for large models, to optimize costs and achieve similar performance for different sizes of models. When leaving the model's warehouse setting empty, the default warehouse in the Snowflake connection string will be used. In case an invalid warehouse is defined, a "No active warehouse selected in the current session. Select an active warehouse with the 'use warehouse' command." error message will be shown.		The Snowflake warehouse can be specified for a specific model. When defined, all queries for that model originating from dashboards use the specified warehouse instead of the (default) warehouse from the [[PA_Configuration_database_table#SnowflakeConnectionString\|Snowflake connection string]]. You can use smaller warehouse for smaller models, and a larger warehouse for large models, to optimize costs and achieve similar performance for different sizes of models. When leaving the model's warehouse setting empty, the default warehouse in the Snowflake connection string will be used. In case an invalid warehouse is defined, a "No active warehouse selected in the current session. Select an active warehouse with the 'use warehouse' command." error message will be shown.

	A good practice is to use a smaller Snowflake warehouse as the default warehouse, and specify a larger warehouse for specific models that need it due to performance. Note that different warehouses should not be used unnecessarily because a common warehouse used by multiple models serves as a shared resource for all the usage which may be more cost effective than using different warehouses.		A good practice is to use a smaller Snowflake warehouse as the default warehouse, and specify a larger warehouse for specific models that need it due to performance. Note that different warehouses should not be used unnecessarily because a common warehouse used by multiple models serves as a shared resource for all the usage which may be more cost effective than using different warehouses.

Ollvihe: /* Change Snowflake Warehouse for Model */

2025-09-17T14:09:24Z

Change Snowflake Warehouse for Model

← Older revision		Revision as of 14:09, 17 September 2025
Line 173:		Line 173:
	A good practice is to use a smaller Snowflake warehouse as the default warehouse, and specify a larger warehouse for specific models that need it due to performance. Note that different warehouses should not be used unnecessarily because a common warehouse used by multiple models serves as a shared resource for all the usage which may be more cost effective than using different warehouses.		A good practice is to use a smaller Snowflake warehouse as the default warehouse, and specify a larger warehouse for specific models that need it due to performance. Note that different warehouses should not be used unnecessarily because a common warehouse used by multiple models serves as a shared resource for all the usage which may be more cost effective than using different warehouses.

	Note that the Snowflake user used by QPR ProcessAnalyzer needs to have permissions to use the specified ~~Snowflake~~ warehouse. If there are no permissions or the specified warehouse doesn't exist ~~at all~~, there will be an error message about an unspecified warehouse.		Note that the Snowflake user used by QPR ProcessAnalyzer to access Snowflake needs to have permissions to use the specified warehouse. If there are no permissions or the specified warehouse doesn't exist in the Snowflake account, there will be an error message about an unspecified warehouse.

	Model's warehouse can be changed as follows:		Model's warehouse can be changed as follows:

Ollvihe: /* Change Snowflake Warehouse for Model */

2025-09-17T14:08:22Z

Change Snowflake Warehouse for Model

← Older revision		Revision as of 14:08, 17 September 2025
Line 178:		Line 178:
	# 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 desired model and press '''Properties''' button.		# Select the desired model and press the '''Properties''' button.
	# In the '''Overview''' tab ~~in the dialog~~, specify the name of the Snowflake warehouse to the '''Snowflake Warehouse''' field.		# The model properties dialog opens. In the '''Overview''' tab, specify the name of the Snowflake warehouse to the '''Snowflake Warehouse''' field.
	# Press the '''Save''' button to close the dialog.		# Press the '''Save''' button to close the dialog.

TeeHiet: TK-59320

2025-09-15T08:35:23Z

TK-59320

← Older revision		Revision as of 08:35, 15 September 2025
Line 169:		Line 169:

	=== Change Snowflake Warehouse for Model===		=== Change Snowflake Warehouse for Model===
	The Snowflake warehouse can be specified for a specific model. When defined, all queries for that model originating from dashboards use the specified warehouse instead of the (default) warehouse from the Snowflake connection string. You can use smaller warehouse for smaller models, and a larger warehouse for large models, to optimize costs and achieve similar performance for different sizes of models. When leaving the model's warehouse setting empty, the default warehouse in the Snowflake connection string will be used.		The Snowflake warehouse can be specified for a specific model. When defined, all queries for that model originating from dashboards use the specified warehouse instead of the (default) warehouse from the Snowflake connection string. You can use smaller warehouse for smaller models, and a larger warehouse for large models, to optimize costs and achieve similar performance for different sizes of models. When leaving the model's warehouse setting empty, the default warehouse in the Snowflake connection string will be used. In case an invalid warehouse is defined, a "No active warehouse selected in the current session. Select an active warehouse with the 'use warehouse' command." error message will be shown.

	A good practice is to use a smaller Snowflake warehouse as the default warehouse, and specify a larger warehouse for specific models that need it due to performance. Note that different warehouses should not be used unnecessarily because a common warehouse used by multiple models serves as a shared resource for all the usage which may be more cost effective than using different warehouses.		A good practice is to use a smaller Snowflake warehouse as the default warehouse, and specify a larger warehouse for specific models that need it due to performance. Note that different warehouses should not be used unnecessarily because a common warehouse used by multiple models serves as a shared resource for all the usage which may be more cost effective than using different warehouses.