Calculated Attributes in QPR ProcessAnalyzer: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
Line 1: | Line 1: | ||
Calculated attributes enable to create case and event attributes using an expression (calculation formula) based on data in the QPR ProcessAnalyzer model. | |||
== Introduction and Usecases== | == Introduction and Usecases== | ||
Data to '''case attributes''' and '''event attributes''' can be originated | Data to '''case attributes''' and '''event attributes''' can be originated as follows: | ||
* '''importing''' them into QPR ProcessAnalyzer from a source system, csv file etc. | * '''importing''' them into QPR ProcessAnalyzer from a source system, csv file etc. | ||
* '''calculating''' attribute values | * '''calculating''' attribute values when the model is loaded using an [[QPR ProcessAnalyzer Expressions|expression]]. | ||
Calculated attributes have following use cases: | Calculated attributes have following use cases: | ||
* Conversions: If an imported attribute data is not in a suitable format, the data can be overridden by defining a calculated attribute with the same name. The calculated attribute expression performs conversions for the data. | * Conversions: If an imported attribute data is not in a suitable format, the data can be overridden by defining a calculated attribute with the same name. The calculated attribute expression performs conversions for the data. | ||
* Aggregations: It's possible to aggregate e.g. event level information to case level using a calculated case attribute. | * Aggregations: It's possible to aggregate e.g. event level information to case level using a calculated case attribute. | ||
* Performance | * Performance: If there is an expression to aggregate event level information to a case level, the aggregation can be done already in the model loading using a calculated case attribute for better performance. | ||
== Functioning Principle == | == Functioning Principle == | ||
Calculated attributes work as follows: | Calculated attributes work as follows: | ||
* | * After the model is loaded, the calculated and imported attributes work similarly, e.g. both are available in the profiling and influence analyses. | ||
* Calculated attributes are calculated when the model is loaded, and thus calculated attribute values don't change after the model loading during the time the model is in the memory. If attributes need to be calculated again, the model needs to be reloaded. | * Calculated attributes are calculated when the model is loaded, and thus calculated attribute values don't change after the model loading during the time the model is in the memory. If attributes need to be calculated again, the model needs to be reloaded. | ||
* Calculated attribute values are stored into the memory | * Calculated attribute values are stored into the memory like the imported attributes, meaning the model requires more memory, the more there are calculated attributes. | ||
* For calculated case attributes, the expression is evaluated in each case's context, and for calculated event attributes, for each event's context. It's thus possible to | * For calculated case attributes, the expression is evaluated in each case's context, and for calculated event attributes, for each event's context. It's thus possible to access the entire model data in the expressions, such as variations, event types, flow and flow occurrences. | ||
* Calculated event attributes are processed before calculated case attributes, so it's possible to use calculated event attributes in calculated case attributes expressions. Also, calculated case and event attributes are processed in the order they are defined, so it's possible to use an earlier defined calculated attribute in expressions of later attributes. | * Calculated event attributes are processed before calculated case attributes, so it's possible to use calculated event attributes in calculated case attributes expressions. Also, calculated case and event attributes are processed in the order they are defined, so it's possible to use an earlier defined calculated attribute in expressions of later attributes. | ||
* Calculated attribute will replace an imported attribute, if there is an imported attribute with the same name. Note that it's not possible to override event timestamp, event type name or case id. | * Calculated attribute will replace an imported attribute, if there is an imported attribute with the same name. Note that it's not possible to override event timestamp, event type name or case id. |
Revision as of 20:33, 31 March 2019
Calculated attributes enable to create case and event attributes using an expression (calculation formula) based on data in the QPR ProcessAnalyzer model.
Introduction and Usecases
Data to case attributes and event attributes can be originated as follows:
- importing them into QPR ProcessAnalyzer from a source system, csv file etc.
- calculating attribute values when the model is loaded using an expression.
Calculated attributes have following use cases:
- Conversions: If an imported attribute data is not in a suitable format, the data can be overridden by defining a calculated attribute with the same name. The calculated attribute expression performs conversions for the data.
- Aggregations: It's possible to aggregate e.g. event level information to case level using a calculated case attribute.
- Performance: If there is an expression to aggregate event level information to a case level, the aggregation can be done already in the model loading using a calculated case attribute for better performance.
Functioning Principle
Calculated attributes work as follows:
- After the model is loaded, the calculated and imported attributes work similarly, e.g. both are available in the profiling and influence analyses.
- Calculated attributes are calculated when the model is loaded, and thus calculated attribute values don't change after the model loading during the time the model is in the memory. If attributes need to be calculated again, the model needs to be reloaded.
- Calculated attribute values are stored into the memory like the imported attributes, meaning the model requires more memory, the more there are calculated attributes.
- For calculated case attributes, the expression is evaluated in each case's context, and for calculated event attributes, for each event's context. It's thus possible to access the entire model data in the expressions, such as variations, event types, flow and flow occurrences.
- Calculated event attributes are processed before calculated case attributes, so it's possible to use calculated event attributes in calculated case attributes expressions. Also, calculated case and event attributes are processed in the order they are defined, so it's possible to use an earlier defined calculated attribute in expressions of later attributes.
- Calculated attribute will replace an imported attribute, if there is an imported attribute with the same name. Note that it's not possible to override event timestamp, event type name or case id.
- If there is an error in the calculated attribute expression, the model loading fails, and the error needs to be corrected before the model can be used.
Calculated case and event attributes are configured to the model JSON settings are follows:
Property | Description |
---|---|
CaseAttributes |
Array of calculated case attributes with the following properties:
|
EventAttributes |
Calculated event attributes are defined using the same structure as calculated case attributes. |
Examples
Example 1: One calculated case attribute:
{ "CaseAttributes": [ { "name": "Cost", "expression": "Cost * 1.5" } ] }
Example 2: Two calculated event attributes:
{ "EventAttributes": [ { "name": "Event Month", "expression": "Timestamp.Truncate(\"month\")" }, { "name": "Duration to Next Event", "expression": "If(IsNull(_.NextInCase), null, (_.NextInCase.Timestamp-_.Timestamp))" } ] }
Example 3: Several calculated case and event attributes:
{ "CaseAttributes": [ { "name": "myBooleanAttribute1", "expression": "CURRENCYCODE == \"RUB\"" }, { "name": "Combined status", "expression": "PurchaseStatus+ \" \" + PurchaseType" }, { "name": "Repeated Events Count", "expression": "Count(_.Events)-Count(Distinct(_.Events.Type))" }, { "name": "Duration between \"Invoice Sent\" and \"Payment Received\"", "expression": "if(Count(_.EventsByType(\"Invoice Sent\")) == 0 || Count(_.EventsByType(\"Purchase Order Line Created\")) == 0, null, (GetAtReverse(0,_.EventsByType([\"Invoice Sent\", \"Payment Received\"])).Timestamp-GetAt(0,_.EventsByType([\"Invoice Sent\", \"Payment Received\"])).Timestamp))" } ], "EventAttributes": [ { "name": "Event type occurrence number", "expression": "Let(\"name\", _.Typename);Count(_.Recurse(_.PreviousInCase).Where(_.Typename==name))" } ] }