QPR ProcessAnalyzer Wiki - User contributions [en]

PA Configuration database table

2026-01-29T09:41:33Z

Jaakko.knuutinen: Added a note that the SAML user group names are case sensitive.

QPR ProcessAnalyzer database has a configuration table '''PA_Configuration''' containing settings listed in the tables below. You need '''SQL Server Management Studio''' to edit the settings in the configuration table. QPR ProcessAnalyzer Server needs to be restarted (e.g. IIS application pool recycled) for the changes to take effect.

For boolean values, ''true'' and ''1'' are valid values for yes, and ''false'' and ''0'' are valid for no.

== General Settings ==
{| class="wikitable" style="text-align: left"
!Name !!Default value !!Description
|-
||SessionIdleTimeout
||3600
||Idle user session expiration timeout in seconds. User session expires if the session hasn't been used after this amount of time.
|-
||SessionMaximumDuration
||86400
||Maximum duration for a user session in seconds. Even if a session is used so that the SessionIdleTimeout is not reached, the session is expired after this amount of time.
|-
||SandboxDatabaseConnectionString
||
||Connection string to scripting sandbox database (ETL). If not defined, SQL-based ETL scripts cannot be run. Connection string for the scripting sandbox database is similar to the [[Server_settings_in_appsettings.json|QPR ProcessAnalyzer database connection string]]. More information: [[Setting up Scripting Sandbox]].
|-
||DefaultUiLanguage
||en_US
||Language code for the UI language that new user accounts get by default. Thus, a created user account has this language until the user changes her/his language. Also the login page is translated using this language when QPR ProcessAnalyzer is used for the first time in that web browser (when user has changed the language, it's remembered by the browser). This setting must be one of the supported language codes (xx_XX):
* English: '''en_US'''
* Finnish: '''fi_FI'''
* French: '''fr_FR'''
* German: '''de_DE'''
* Polish: '''pl_PL'''
* Portuguese: '''pt_BR'''
* Spanish: '''es_ES'''
* Swedish: '''sv_SE'''
* Ukrainian: '''uk_UK'''
|-
||DefaultDateFormat
||MM/dd/yyyy
||Default date format that new user accounts get by default. The date format does not contain the time part (e.g. hours, minutes and seconds). Defined using the .Net date format (https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings).
|-
||DefaultFirstDayOfWeek
||0
||Default first day of the week that new user accounts get by default. '''0''' is Sunday and '''1''' is Monday. This information is used by the UI when showing e.g. calendars.
|-
||DefaultUse12HourClock
||false
||Defines whether the 12-hour clock is used by default (instead of the 24-hour clock) for the new user accounts when showing time information in the UI. Defined as '''true''' or '''false'''. More information about the 12-hour clock: https://en.wikipedia.org/wiki/12-hour_clock.
|-
||DefaultDataSource
||
||Datasource where datatables data is stored when datatables are created by a script when the datasource is not explicitly specified in the script. Possible values are '''Snowflake''' and '''SqlServer'''. Value ''snowflake'' can be used when the ''SnowflakeConnectionString'' setting is defined, and value ''sqlserver'' can be used when the setting ''SqlServerConnectionString'' is configured. The setting can be changed without affecting the existing datatables, as the setting only affect new datatables. When this setting is empty, datatables are created in the metadata database.
|-
||SqlServerConnectionString
||
||Connection string for the SQL Server database containing the datatables data. It's recommended to use a separate database, but it's also possible to connect to the same database as the configuration data. If this setting is not configured, local datatables cannot be created (SQL Server stored). Existing datatables located in the configuration datatabase still work even if this setting has not be configured. Note that the connection uses ADO.Net (not ODBC), so the connection string is similar to the configuration database ([[Installing_QPR_ProcessAnalyzer_Server#Server_settings_file_(appsettings.json)|appsettings.json]] file).
|-
||SnowflakeConnectionString
||
||ODBC connection string for the Snowflake account. This setting is needed to make analytics calculations in the Snowflake. More information how to configure the [[Snowflake_Connection_Configuration#Set_Snowflake_ODBC_connection|Snowflake connection string]]. The Snowflake ODBC driver also needs to be installed in the machine running the QPR ProcessAnalyzer Server. When this setting has been configured, users can create Snowflake stored datatables and models using Snowflake calculation.

When running QPR ProcessAnalyzer in the Snowpark Container Services, leave the SnowflakeConnectionString empty because then the connection string is created automatically using the method provided by the Snowpark Container Services.
|-
||OpenAIAPIKey
||
||API key for the OpenAI API (https://platform.openai.com/docs/api-reference). It needs to be configured to use the [[AI_Assistant_for_QPR_ProcessAnalyzer|AI Assistant]] and [[Generic_Functions_in_QPR_ProcessAnalyzer#OpenAIChatCompletion|OpenAIChatCompletion]] function.
|-
||OpenAIDefaultModelName
||gpt-4o
||OpenAI large language model (LLM) to use for the [[AI_Assistant_for_QPR_ProcessAnalyzer|AI Assistant]] and [[Generic_Functions_in_QPR_ProcessAnalyzer#OpenAIChatCompletion|OpenAIChatCompletion]] function. If not defined, '''gpt-4o''' will be used. Note that only LLM's that support the function calling feature, are suitable for the AI Assistant. More information about OpenAI models: https://platform.openai.com/docs/models.
|-
||DefaultCortexAgentsModelName
||llama3.1-70b
||Specifies the default language model when using Snowflake Cortex Agents (https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-rest-api). If not defined, "llama3.1-70b" is used.
|-
||AllowExternalDatasources
||true
||Can be used to disallow all connections to external datasources in the expression language and SQL scripts to improve security. Disallowed operations include ODBC, OLE DB, SQL Server (Ado.Net), SAP, Salesforce, and call web service. Note that this setting does not prevent the Snowflake processing. Regardless of this setting, QPR ScriptLauncher can be used to extract data from source systems.
|-
|DatabaseId
|
||Unique identifier for the QPR ProcessAnalyzer environment. Any characters between a-z, A-Z, 0-9 and _ (underscore) can be used in the DatabaseId. If the DatabaseId is missing or set to null, the system will generate a new GUID during startup and use it as the DatabaseId. The DatabaseId can also be an empty string. If using several QPR ProcessAnalyzer environments, make sure each use a different DatabaseId. The DatabaseId is used as part of the table names in Snowflake and SQL Server (in the datatables database). Thus if the DatabaseId is changed, all tables in Snowflake and SQL Server named with qprpa_dt_<DatabaseId>_<DatatableId> need to be renamed.
|-
||NumberOfParallelModelReaders
||4
||Models and datatable contents can be loaded with multiple simultaneous connections to the database to speed up the loading. This setting determines how many parallel loaders/readers at maximum (loaders are loading at the same time). For smaller models there are less parallel loaders than the defined limit: If there are less than 100000 rows in the table, there is only one loader. If there are less than 200000 rows in the table, there are only two loaders, and so on.

The more there are parallel loaders, the more processor load and network bandwidth is consumed, and other operations in QPR ProcessAnalyzer might slow down. Note also that the performance optimum is achieved with a certain number of parallel loaders which differs between environment. Thus to achieve the best performance, data loading should be tested with different number of parallel loaders. Increasing number of parallel loaders beyond the optimum decreases the performance.

|-
||StartupModelLoadingMaxParallelism
||2
||Maximum number of QPR ProcessAnalyzer models that are loaded into memory simultaneously by the [[Automatic_Model_Loading_on_Server_Startup|Automatic Loading on Server Startup]]. If there are more models to be loaded on the server startup than this setting, loading for the rest of the models is started one by one when previous model loadings are completed. If this setting is not defined, '''2''' is used as a default value.

Loading more models at the same time will speed up the whole model loading process, but on the other hand, it causes more load on the system, which affects the system responsiveness for users. Model loading consists of (1) transferring data from the datasource to QPR ProcessAnalyzer and (2) loaded data preprocessing into a model. The former uses mainly network bandwidth (if datasource is in a different server) and the latter uses mainly processor capacity in the QPR ProcessAnalyzer server.

This setting affects only the model loading during the server startup and it doesn't restrict models loadings initiated by users.
|-
||QueryTimeout
||300
||Timeout (in seconds) for requests made to /api/expression/query and /api/expression endpoints. When the timeout is exceeded, the query is stopped and a timeout error is returned. Purpose of the timeout is to protect the system against potentially too long running or even never-ending queries which might otherwise jam the system.
|-
||CacheOnlyPrimaryKeysForFilters
||false
||Defines whether to include all columns in the Snowflake event cache filter tables (''false''), or only the primary key columns (''true''). When ''false'', cache table creation is slower, but the analysis calculation is faster because the original event table is not used anymore. When ''false'', also the cache tables require more storage space in Snowflake.
|-
||AllowNonTemporaryETLTargetTable
||false
||Defined whether ETL scripts are allowed to create global temporary database tables (tables starting with ##). More information about temporary tables: https://docs.microsoft.com/en-us/sql/t-sql/statements/create-table-transact-sql?view=sql-server-ver15#temporary-tables.
|-
||DatabaseBulkCopyTimeout
||600
||Timeout used for data import operations to datatables.
|-
|SandboxDatabaseBulkCopyTimeout
||600
||Timeout used for data import operations to sandbox tables in the SQL scripts.
|-
||DatabaseBulkCopyBatchSize
||5000
||BulkCopyBatchSize given for QPR ProcessAnalyzer database SqlBulkCopy operations.
|-
||SandboxDatabaseBulkCopyBatchSize
||5000
||BulkCopyBatchSize given for sandbox SqlBulkCopy operations.
|}

== SAML 2.0 Federated Authentication Settings ==
Note that the SAMLMetadataUrl and ServiceProviderLocation are mandatory for the federated authentication to work.

{| class="wikitable" style="text-align: left"
!Name !!Description
|-
||SAMLMetadataUrl
||
Metadata URL of the identity provider (IdP). Check that the metadata url can actually be opened using a web browser and is publicly available. The metadata is an XML document starting with '''<?xml version="1.0" encoding="UTF-8"?>''' followed by an '''EntityDescriptor''' tag. The metadata URL might look '''<nowiki>https://your.federated.identity.provider.com/saml/metadata</nowiki>'''. This setting is mandatory for the SAML authentication to work.
|-
||ServiceProviderLocation
||
Specifies the QPR ProcessAnalyzer server location (the root path which contains e.g. the ''ui'' folder). It's used by the url to redirect back to QPR ProcessAnalyzer after a successful authentication from the identity provider. The setting is defined in the following form: '''https://<hostname>/qprpa''', for example '''<nowiki>https://customer.onqpr.com/qprpa</nowiki>'''. Note that the actual redirect back url is '''https://<hostname>/qprpa/api/Saml2/Acs''' (/api/Saml2/Acs is automatically included to the url). This setting is mandatory for the SAML authentication to work. Note that if this reply url is configured the identity provider, it must match with the ServiceProviderLocation setting.
|-
||SAMLUserIdAttribute
||
Name of the SAML attribute in the assertion that will be used as the user's login name. If this field is not defined, the '''saml:Assertion''' > '''saml:Subject''' > '''saml:NameID''' attribute in the assertion is used. If this setting is given, one of the '''saml:Assertion''' > '''saml:AttributeStatement''' > '''saml:Attribute''' elements in the assertion is used (the '''Name''' attribute in the '''saml:Attribute''' element is used for matching). Please note that the saml:NameID element is different than the usual SAML attributes that are defined by the saml:Attribute elements. For example, if an email address is used as a user id, the value of the setting could be for example ''<nowiki>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress</nowiki>''.
|-
||SAMLGroupsAttribute
||Attribute name in SAML assertion that is mapped to user groups in QPR ProcessAnalyzer. The user group names are case sensitive. When a user logs in, the user is added to and removed from groups based on the information in the SAML assertion. If this setting is not configured, users are not added to or removed from groups automatically. Note that the user needs to login for the groups to be synchronized. If a group doesn't exist in QPR ProcessAnalyzer, that group is skipped.

In the SAML assertion, attributes are in the saml:Assertion > saml:AttributeStatement > saml:Attribute elements (the Name attribute in the saml:Attribute element is used for matching).
|-
||SAMLEncryptionCertificate
||This setting defines a PFX formatted X.509 certificate (defined in RCF 1422) used to encrypt SAML assertions. The public key of the certificate is published in the service provider metadata, where the identity provider can read it and encrypt SAML assertions. QPR ProcessAnalyzer as the service provider uses the corresponding private key of the certificate to decrypt SAML assertions. The setting needs to be a PFX formatted certificate file that is base64 encoded and it doesn't contain the BEGIN CERTIFICATE etc. header or footer lines. This setting is needed only when using the SAML assertions encryption. Even though this setting is defined, the SAML assertions are not required to be encrypted. More information how to create the certificate file (https://stackoverflow.com/questions/16480846/x-509-private-public-key) and convert it to base64 (https://stackoverflow.com/questions/46959822/base-64-encoded-form-of-the-pfx-file).
|-
||SAMLSigningCertificate
||This setting defines a PFX formatted X.509 certificate (defined in RCF 1422) used to sign SAML authentication requests sent from QPR ProcessAnalyzer to the identity provider. The public key of the certificate is published in the service provider metadata, where the identity provider can read it, to verify the authenticity of the SAML requests. The setting needs to be a PFX formatted certificate file that is base64 encoded and it doesn't contain the BEGIN CERTIFICATE etc. header or footer lines. If this setting is not defined, the internal hard-coded signing certificate is used. More information how to create the certificate file (https://stackoverflow.com/questions/16480846/x-509-private-public-key) and convert it to base64 (https://stackoverflow.com/questions/46959822/base-64-encoded-form-of-the-pfx-file).
|}

== SMTP Server Settings ==
SMTP server settings are needed for QPR ProcessAnalyzer to send email messages. Email sending is used by the [[Email_Notifications|notifications]] and the [[Generic_Functions_in_QPR_ProcessAnalyzer#SendEmail|SendEmail]] function in the expression language.

{| class="wikitable" style="text-align: left"
!Name !!Description
|-
||SmtpServer
||DNS name, host name or IP address of the SMTP server. Mandatory setting for the email sending to work.
|-
||SmtpPort
||TCP port number of the SMTP server. If not defined, port 25 is used by default.
|-
||SmtpAuthenticationUsername
||User name for authenticating to the SMTP server. If not defined, no authentication is used to connect to the SMTP server.
|-
||SmtpFromAddress
||Email address where email messages sent by QPR ProcessAnalyzer appear to be coming from. This doesn't need to be a real email address, although the address used may affect email spam filters. The setting configured here is the default email address to use in following cases:
* ''From address'' is not set for the email notifications
* ''From'' parameter is not defined for the expression language ''SendEmail'' function
* ''EmailFrom'' parameter is not defined for the SQL Scripting SendEmail operation
|-
||SmtpAuthenticationPassword
||Password for authenticating to the SMTP server.
|-
||SmtpEnableSSL
||Use value '''True''' or '''False''' depending whether TLS connection to the SMTP server is used or not. If not defined, ''False'' is the default value.
|}

== Readonly Information ==

{| class="wikitable" style="text-align: left"
!Name !!Description
|-
|DatabaseVersion
||Database schema version. It will be updated automatically when the newer version of QPR ProcessAnalyzer Server connects to the database and performs migration for the database schema.
|-
||InitializationScriptDatabaseVersion
||Database version that was when the database was initialized when the software was installed. Do not change this setting.
|-
||MinimumDatabaseVersion
||Minimum allowed database version for QPR ProcessAnalyzer Server connecting to the database. This is a legacy setting and it should not be used.
|}

Create Simulated Eventlog

2025-04-15T07:07:35Z

Jaakko.knuutinen: /* Removed "_marhink" from the end of PredictionProcedureName value. Previous value was: "qprpa_sp_prediction_marhink" which caused an error when running the script. */

This article has instructions how to install, configure and use eventlog simulations. The simulation creates a new model that contains both the source model data and the new simulated data. Case attribute '''Simulated''' can be used to determine whether the case is in the source data (''false'') or whether the simulation generated it as a new simulated case (''true'').

== Prerequisites for simulation ==
As prerequisite, prediction must be installed into the used Snowflake as described in [[Create Predicted Eventlog|Install prediction in Snowflake]].

== Create simulation script in QPR ProcessAnalyzer ==
You can create your own simulation script from scratch, or use one of the scripts provided below as a starting point.

=== Creating a simulation model that deletes specific events ===
1. Create the following example expression script (e.g., with name "'''Create simulation model''' '''- delete events'''"):<syntaxhighlight lang="typescript">
let sourceModel = ProjectByName("<project name>").ModelByName("<model name>");
let flowFromEventType = "<from event type of a flow to modify>", flowToEventType = "<to event type of a flow to modify>";

let targetProject = Project;
_system.ML.ApplyTransformations(#{
"Name": "My simulation model - delete", // Name of the PA model to generate to the target project.
"SourceModel": sourceModel, // Snowflake-based PA model used for training the prediction model.
"TargetProject": targetProject, // Target project to create the model into.
"Transformations": [#{ // Transformation configurations.
"type": "modify_flow_durations",
"column": sourceModel.EventsDataTable.ColumnMappings["EventType"],
"flows": [#{
"from": flowFromEventType,
"to": flowToEventType,
"probability": 1.0,
"operation": #{
"type": "set_value",
"value": 0.0
},
"delete": true
}]
}]
});

</syntaxhighlight>2. Configure simulation for the previously created script as instructed in the next chapter. At minimum, replace the tags listed below with some suitable values:

* '''<project name>''': Name of the project in which the source model is located.
* '''<model name>''': Name of the model to be used as source model. This data in this source model will be used as source data to be modified by the simulation transformations.
* '''<from event type of a flow to modify>''': From-event type name of flows from which the from-event is to be deleted.
* '''<to event type of a flow to modify>''': To-event type name of flows from which the from-event is to be deleted.

=== Create simulation model automating all the resources belonging to the same role as specified resource ===
1. Create the following example expression script (e.g., with name "'''Create simulation model''' '''- automate'''"):<syntaxhighlight lang="typescript">
let sourceModel = ProjectByName("<project name>").ModelByName("<model name>");
let resourceColumnName = "<event data column having resource names>";
let resourceNameToAutomate = "<resource value whose role should be automated>";

let targetProject = Project;
_system.ML.ApplyTransformations(#{
"PredictionProcedureName": "qprpa_sp_prediction",
"Name": "My simulation model - automate", // Name of the PA model to generate to the target project.
"SourceModel": sourceModel, // Snowflake-based PA model used for training the prediction model.
"TargetProject": targetProject, // Target project to create the model into.
"Transformations": [#{ // Transformation configurations
"type": "resources_to_roles",
"resource_column": resourceColumnName,
"role_column": "Role",
"role_name_template": "Role %d"
}, #{
"type": "modify_flow_durations",
"input": #{
"role_name": #{
"input": "resource_to_role_map",
"value_path": [resourceNameToAutomate]
}
},
"column": "Role",
"flows": [#{
"from_input": "role_name",
"operation": #{
"type": "set_value",
"value": 1,
"probability": 0.5
}
}]
}]
});

</syntaxhighlight>2. Configure simulation for the previously created script as instructed in the next chapter. At minimum, replace the tags listed below with some suitable values:
* '''<project name>''': Name of the project in which the source model is located.
* '''<model name>''': Name of the model to be used as source model. This data in this source model will be used as source data to be modified by the simulation transformations.
* '''<event data column having resource names>''': Name of the event data column that contains resource names.
* '''<resource value whose role should be automated>''': Name of the resource whose role is to be automated.

== Configure simulation ==
Simulation script has the following settings in the ApplyTransformations call:

* '''Name''': Name of the QPR ProcessAnalyzer model that is created to the target project. The model will contain the source model content and the predictions.
* '''SourceModel''': Source model for which the simulation is made. Model can be selected for example based on id with ModelById function or by name with ModelByName function.
* '''TargetProject''': Target project to create the new model into.
* '''Transformations''': Array of transformation configuration objects. Each object supports the following parameters:
** '''type''': Defines the type of the transformation to perform. See below for more details on the supported transformations. Supported values are:
*** '''enforce_resource_limits''': Used to modify given event log using given maximum resource limits.
*** '''extract_max_resource_usages''': Used to extract, for every value of a specified column, the maximum number of concurrent cases in given event log that have that value.
*** '''generate''': Used to generate a new event log using a trained ML model.
*** '''modify_flow_durations''': Used to modify durations of flows and possibly remove events having specific flows.
*** '''modify_values''': Used to modify values of a dictionary given as input (e.g., dictionary generated by extract_max_resource_usages).
*** '''resources_to_roles''': Performs "organization mining" by trying to group together column values (e.g., resources) that are used in similar fashion in given event log (e.g., resources that are often present in similar set of activities).
**'''input''': Can be used to specify that given transformation input parameters get their values from the previous transformation result.
***Value can be either direct mapping by just the name of the transformation result property, or it can be a value mapping configuration object that supports the following parameters:
****'''input''': Name of the parameter to get from the previous transformation result as the root object of the actual value to extract.
****'''value_path''': An array of property names to traverse into the root object.

=== Transformation: event_resource_limits ===
Using given input data, this transformation generates a new event log which does not exceed the concurrency limitations of specified column values.

Event rows are traversed in time order, and if at some point a limit would be exceeded, instead of outputting the actual event, a new copy of the actual event, with copied event properties, is created to represent the queue for the actual event.

Only after an event leaves from the column value that contains a queue, the event that had been waiting for the longest in the queue will be generated (following the FIFO-principle).

==== Supported parameters ====
* '''column''': Name of the column having the values whose concurrent usage is to be limited by specified limits
* '''limits''': Specifies an object containing key-value -pairs where keys are column values and values contain an integer specifying the maximum number of concurrent cases in the given event log that can contain given value.
* '''queue_event_activity_name''': If set, specifies the name template used for queue-events. In this template, when a queue event is created, %s is replaced with the name of the activity this queue event is queuing to.
** If not set, the activity name is not altered at all for the queue event.
* '''queue_event_column''':
** If queue_event_activity_name is set:
*** If the event represents a queue-event, the value in this column specifies the name of the queue-activity.
*** Otherwise, the value is null.
** If queue_event_activity_name is not set:
*** If the event represents a queue-event, the value in this column True.
*** Otherwise, the value is False.

==== Inputs ====
Event log to operate on.

==== Outputs ====
Event log with resource limits enforced.

==== Example ====
<syntaxhighlight lang="json">
#{
"type": "enforce_resource_limits",
"queue_event_column": "Queue",
"queue_event_activity_name": "%s - Queue",
"limits": #{
"Role 3": None
},
"input": #{
"limits": "role_limits",
"column": "role_column"
}
}
</syntaxhighlight>

=== Transformation: extract_max_resource_usages ===
Extract, for every value of a specified column, the maximum number of concurrent cases in given event log that have that value.

==== Supported parameters ====

* '''resource_column''':
** The name of the column representing the resources whose maximum concurrent case usages are to be calculated.

==== Inputs ====
Event log to operate on.

==== Outputs ====

* max_resource_usages:
** A dictionary object containing resource names as keys (unique resource_column values) and their maximum usage in the event log.

==== Example ====
<syntaxhighlight lang="json">
#{
"type": "extract_max_resource_usages",
"resource_column": "SAP_User"
}
</syntaxhighlight>

=== Transformation: generate ===
Generate a new event log using the configured model [[Create Predicted Eventlog|prediction generation parameters (GenerationConfiguration)]].

==== Supported parameters ====
Supports all the same parameters as those supported by model prediction generation configuration.

==== Inputs ====
Does not support inputs.

==== Outputs ====
Generated event log.

==== Example ====
<syntaxhighlight lang="json">
#{
"type": "generate",
"model_name": "ML model",
"cases_to_generate": 100,
"max_num_events": 20
}
</syntaxhighlight>

=== Transformation: modify_flow_durations ===
Modify durations of flows and possibly remove events having specific flows.

==== Supported parameters ====

* '''column''': The name of the column based on which the flows are created. Usually this is the column containing activities, but could also be, e.g., organization units, users, …
* '''flows''': Flows to transform. Contains an array of flow transformation configuration objects. Each object defines transformations performed on one flow type defined by starting and ending column values. Supports the following properties:
** '''delete''': Same as delete_from.
** '''delete_from''': If defined, specifies whether the "from event" of the matched flow should be removed after applying the operation (if defined).
** '''delete_to''': If defined, specifies whether the "to event" of the matched flow should be removed after applying the operation (if defined).
** '''from''': Column value starting the flow.
*** If this and from_input are both undefined, any starting value is accepted.
** '''from_input''': If defined, specifies the name of the transformation-level parameter from which the actual column value starting the flow is read from.
*** Overrides the value defined in from-parameter.
** '''operation''': Specifies the actual flow duration modification operation to perform as value modification configuration object where the value is the duration in seconds. Supports the following properties:
*** '''probability''': If defined, specifies the percentage probability of applying the operation to any matching instance of the flow.
**** Value should be a numeric value between 0 and 1.0.
**** This probability applies only to this operation.
**** The default value is 1.0.
*** '''type''': Type of the operation. The following types are supported:
**** '''add''': Sets the value to be the current value plus the number specified by the value.
**** '''multiply''': Sets the value to be the current value multiplied by the number specified by the value.
**** '''set_value''': Sets the value to be exactly the number specified by the value.
*** '''value''': Value used by the operation.
** '''probability''': If defined, specifies the percentage probability of applying the operation to any matching instance of the flow.
*** Value should be a numeric value between 0 and 1.0.
*** This probability applies, in addition to the operation specified by the operation-parameter, also to any possible other transformations, such as event deletion.
*** Default value is 1.0
** '''to''': Column value ending the flow.
*** If this and to_input are both undefined, any ending value is accepted.
** '''to_input''': If defined, specifies the name of the transformation-level parameter to which the actual column value ending the flow is read from.
*** Overrides the value defined in to-parameter.

==== Inputs ====
Event log to operate on.

==== Outputs ====
Transformed event log.

==== Example ====
<syntaxhighlight lang="json">
#{
"type": "modify_flow_durations",
"column": "Organization",
"flows": [#{
"from": "Delivery",
"operation": #{
"type": "set_value",
"value": 0.0
},
"delete": true
}]
}
</syntaxhighlight>

=== Transformation: modify_values ===
Modify values of an object given as input (e.g., object generated by extract_max_resource_usages).

Due to the required inputs, this transformation can't be the first transformation to perform.

==== Supported parameters ====

* '''values''': Array of value configuration objects. Each object supports the following properties:
** '''input''': Name of the result to modify, where the result is the output of the previous transformation.
** '''input_key_from''': If defined, specifies the the name of the property of a input object whose value contains the name of the property whose value is to be modified.
** '''input_key_value_path''': If input_key_from is defined and is represented as an object, this configuration should specify an array of property names to traverse into the object.
*** The value at the end of this path will be used as the name of the property to modify in the input.
** '''operation''': Specifies the actual value modification operation to perform as value modification configuration object. Supports the following properties:
*** '''probability''': If defined, specifies the percentage probability of applying the operation to any matching instance of the flow.
**** Value should be a numeric value between 0 and 1.0.
**** This probability applies only to this operation.
**** The default value is 1.0.
*** '''type''': Type of the operation. The following types are supported:
**** '''add''': Sets the value to be the current value plus the number specified by the value.
**** '''multiply''': Sets the value to be the current value multiplied by the number specified by the value.
**** '''set_value''': Sets the value to be exactly the number specified by the value.
*** '''value''': Value used by the operation.

==== Inputs ====
Output of the previous transformation operation.

==== Outputs ====
The same output as the previous performed transformation, except with the specified value modifications applied.

==== Example ====
<syntaxhighlight lang="json">
#{
"type": "modify_values",
"values": [#{
"input": "role_limits",
"input_key_from": "resource_to_role_map",
"input_key_value_path": ["Tina"],
"operation": #{
"type": "multiply",
"value": 0.5
}
}]
}
</syntaxhighlight>

=== Transformation: resources_to_roles ===
Performs "organization mining" by grouping together column values (e.g., resources) that are used in similar fashion in given event log. E.g., resources that are often present in similar set of activities.

==== Supported parameters ====

* '''resource_column''': The name of the column containing names of resources.
* '''resource_limits''': Contains an object dictionary containing resource names with their maximum concurrent usages.
** If set, when building role_limits output, these values will be summed for each resource into the resulting role-based usage limit.
** If not set, each resource in a role will be counted as one, when calculating the role_limits.
* '''role_column''': The name of the column to be created and whose values will indicate the role in which the resource belongs to.
* '''role_name_template''': If set, specifies the name template used for role names. In this template, %d will be replaced by a numeric value starting from 1.
** The default value is "Role %d".
* '''similarity_threshold''': The minimum value of Pearson correlation coefficient calculated between two resources in order for them to be considered as having the same role.
** The default value is 0.7

==== Inputs ====
Event log to operate on.

==== Outputs ====

* Transformed event log.
* Result dictionary object containing the following properties:
** '''resource_column''': The name of the column containing names of resources.
** '''resource_to_role_map''': An object containing resource names as property names and role names as value.
** '''role_column''': The name of the generated column whose values will indicate the role in which the resource belongs to.
** '''role_limits''': An object containing role names as property names and maximum usage for that role as value.

==== Example ====
<syntaxhighlight lang="json">
#{
"type": "resources_to_roles",
"resource_column": "SAP_User",
"role_column": "Role",
"role_name_template": "Role %d",
"input": #{
"resource_limits": "max_resource_usages"
}
}
</syntaxhighlight>

Chart Linked Settings

2025-01-10T13:08:55Z

Jaakko.knuutinen: Added an example Linked settings to filter events based on event attribute values.

Chart linked settings are used to bind together selected settings in a chart, that will make sure the bound settings have always same values. The settings are defined to a ''linked settings group'', and when any of the linked settings is changed, other linked settings in the same group are also changed automatically.

== Usage ==
Tips when creating linked settings:
* Finding the correct technical setting name requires to investigate the chart settings json (in the ''Advanced'' tab). The label names in the settings dialog are different than the technical names that need to be used in the linked settings.
* Make sure to bind only settings that are of same data type. For example, trying to bind string and integer settings will likely not work. An an exception, it's possible to bind string array and individual string values, because the individual values are automatically converted into arrays.
* It's possible to define as many linked settings to the group as needed. Obviously, there needs to be at least two settings in the group, for the linked settings to work meaningfully. There can also be as many linked setting groups in the same chart as needed.
* Measures, dimensions and columns cannot be changed using the linked settings, but their parameters can be bound to linked settings.
* Dashboard variables are available in custom expressions by using tags (syntax: ''<#tagName>''), which does not require linked settings.

== Configuration ==
Linked settings are configured in the '''Advanced''' tab of chart/flowchart by clicking '''Linked settings'''. Linked settings json consists of ''setting groups'' which are array of objects. Each object points to an individual setting and it has the following properties:
* '''type''': One of the following type of setting:
** '''measure''': For measure parameters.
** '''dimension''': For dimension and column parameters.
** '''eventtypemeasure''': For flowchart event measure parameters.
** '''flowmeasure''': For flowchart flow measure parameters.
** '''root''': For analyzed objects parameters.
** '''generic''': For other settings in the chart, such as ''Maximum rows'' (technical name: maxRows), ''Visualization'' (technical name: maxRows), ''Show Data Labels'' (technical name: datalabels), ''Model'' (technical name: modelId), etc.
** '''tag''': For binding to a tag. Tags can be used in the custom expressions.
** '''variable''': For binding to a dashboard variable. Dashboard variables can be used to bind together settings across multiple charts. Linked settings need to be defined for all the bound charts.
** '''filtervalue''': For binding to filter rule parameters, such as case/event attribute values or event types.
** '''filterattribute''': For binding to case or event attribute name in filter rule.
* '''index''': Defines the order number (starts from 0). Used hen ''type'' is a ''measure'', ''dimension'', ''eventtypemeasure'', ''flowmeasure'', or ''filtervalue''.
* '''parameter''': Name of the chart setting or parameter. All properties stored to the ''expressionParameters'' in chart json settings, can be used. In addition, following property names are available: "aggregate", "decimals", "unit" and "dateGranularity".
* '''tagName''': When ''type'' is ''tag'', defines the bound tag name. The tag can be used in custom expressions similar to variables with syntax <#MyTagName>. Linking to tags is one-way: when a setting is changed, the tag is changed accordingly. On the other hand, the tag value itself cannot be changed directly.
* '''variableName''': When linked setting type is ''variable'', defines the variable name. Linking to variables is two-way: when a variable value is changed, the other linked setting is changed accordingly, and when the other setting is changed, a linked variable value is changed accordingly.
* '''variableFormat''': Defines whether the linked variables use the '''stringified''' (default) ([[Stringified Value Format|more about stringified value format]]) or '''json''' format (https://en.wikipedia.org/wiki/JSON). When working with Snowflake models, use the ''stringified'' format. The ''json'' format is required when using in-memory models with the [[Dropdown List Selector]] because for in-memory models, the Dropdown List Selector uses the ''json'' format (due to backward compatibility).
* '''filterGroupType''': When ''type'' is ''filtervalue'' or ''filterattribute'', defines the filter group type as one of the following: ''IncludeCases'', ''ExcludeCases'', ''IncludeEvents'', ''ExcludeEvents'', ''IncludeEventTypes'', ''ExcludeEventTypes''.
* '''filterRuleType''': When ''type'' is ''filtervalue'' or ''filterattribute'', defines the filter rule type as one of the following: ''CaseAttributeValue'', ''EventAttributeValue'', ''Attribute'', ''EventType'', ''Case''.
* '''attribute''': When ''type'' is ''filtervalue'', defines the attribute name. Used for filter rule types ''CaseAttribute'', ''EventAttribute'' and ''Attribute''. This setting is optional, and when not defined, the linked setting is bound to the first filter rule matching with the ''filterGroupType'' and ''filterRuleType''.
* '''expressionCategory''': When ''type'' is ''filtervalue'' or ''filterattribute'', and referring to a measure/dimension/column level filter, defines the measure/dimension/colum as one of the following: ''measure'', ''dimension'', ''eventtypemeasure'', ''flowmeasure''. When the expressionCategory is not defined, the linked setting refers to a chart level filter rule.

== Examples ==

=== Measure and dimension parameters ===
[[File:Linkedsettings.png|right|700px]]
<syntaxhighlight lang="json" line>
[
[
{
"type": "measure",
"index": 0,
"parameter": "Start event"
},
{
"type": "measure",
"index": 1,
"parameter": "Start event"
}
],
[
{
"type": "measure",
"index": 0,
"parameter": "End event"
},
{
"type": "measure",
"index": 1,
"parameter": "End event"
}
],
[
{
"type": "measure",
"index": 0,
"parameter": "Time unit"
},
{
"type": "measure",
"index": 1,
"parameter": "Time unit"
}
]
]
</syntaxhighlight>

=== Analyzed objects parameters ===
This example binds together ''Analyzed objects'' parmeter ''Start event'' with similar parameter of a measure.
<syntaxhighlight lang="json" line>
[
[
{
"type": "root",
"parameter": "Start event"
},
{
"type": "measure",
"index": 0,
"parameter": "Event"
}
]
]
</syntaxhighlight>

=== Generic settings ===
This example binds together the ''Maximum rows'' and ''Analyzed objects sample size'' settings.
<syntaxhighlight lang="json" line>
[
[
{
"type": "generic",
"parameter": "rootSampleSize"
},
{
"type": "generic",
"parameter": "maxRows"
}
]
]
</syntaxhighlight>

=== Filter rules===
This example binds dimension's filter rule (which type is cases going through event types) to the same dimension's parameter.
<syntaxhighlight lang="json" line>
[
[
{
"type": "filtervalue",
"expressionCategory": "dimension",
"index": 0,
"filterGroupType": "IncludeCases",
"filterRuleType": "EventType"
},
{
"type": "dimension",
"index": 0,
"parameter": "Event"
}
]
]
</syntaxhighlight>

=== Dashboard variables ===
This example binds ''Maximum rows'' setting to dashboard variable ''MaxItems''. If several charts use the same variable, settings can be bound across several charts.
<syntaxhighlight lang="json" line>
[
[
{
"type": "variable",
"variableName": "MaxItems"
},
{
"type": "generic",
"parameter": "maxRows"
}
]
]
</syntaxhighlight>

=== Custom expression tags ===
This example binds tag named ''CaseAttributeName'' to a measure parameter to select the case attribute. The tag ''<#CaseAttributeName>'' can be used an all custom expressions of this chart.
<syntaxhighlight lang="json" line>
[
[
{
"type": "tag",
"tagName": "CaseAttributeName"
},
{
"type": "measure",
"index": 0,
"parameter": "Attribute"
}
]
]
</syntaxhighlight>

=== Binding to case attribute filters with attribute name and attribute values ===
This example binds dashboard variables ''CaseAttributeName'' and ''CaseAttributeValues'' to the chart filter rule to include case attribute values. The filter rule need to pre-exist for these linked settings to work.
<syntaxhighlight lang="json" line>
[
[
{
"type": "variable",
"variableName": "CaseAttributeName"
},
{
"type": "filterattribute",
"filterGroupType": "IncludeCases",
"filterRuleType": "CaseAttributeValue"
}
],
[
{
"type": "variable",
"variableName": "CaseAttributeValues"
},
{
"type": "filtervalue",
"filterGroupType": "IncludeCases",
"filterRuleType": "CaseAttributeValue"
}
]
]
</syntaxhighlight>

=== Filter events based on event attribute name and event attribute value ===
This example binds dashboard variables ''dbAttributeName'' and ''dbAttributeValue1'' to the chart filter rule to include events with the chosen event attribute values. The filter rule need to pre-exist for these linked settings to work.<syntaxhighlight lang="json" line="1">
[
[
{
"type": "variable",
"variableName": "dbAttributeName"
},
{
"type": "filterattribute",
"filterGroupType": "IncludeEvents",
"filterRuleType": "Attribute"
}
],
[
{
"type": "variable",
"variableName": "dbAttributeValue1"
},
{
"type": "filtervalue",
"filterGroupType": "IncludeEvents",
"filterRuleType": "Attribute"
}
]
]
</syntaxhighlight>