Calculated Attributes in QPR ProcessAnalyzer: Difference between revisions

From QPR ProcessAnalyzer Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
Case and event attributes data can be originated either
Data to '''case attributes''' and '''event attributes''' can be originated either by
* by '''importing''' them into QPR ProcessAnalyzer, or
* '''importing''' them into QPR ProcessAnalyzer
* by '''calculating''' attribute values during model loading using an [[QPR ProcessAnalyzer Expressions|expression]].
* '''calculating''' attribute values during model loading using an [[QPR ProcessAnalyzer Expressions|expression]].


Notes about calculated attributes:
Notes about calculated attributes:
* Calculated attributes are treated as the imported attributes, e.g. they can be used in the profiling or influence analyses.
* Calculated attributes are treated as the imported attributes, e.g. they can be used in the profiling or influence analyses.
* Calculated attributes are calculated when the model is loaded. 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.
* Filtering doesn't affect the values of calculated attributes, but filtering affects the aggregated results from calculated attributes, e.g. in the profiling analysis.
* Filtering doesn't affect the values of calculated attributes, but filtering affects the aggregated results from calculated attributes, e.g. in the profiling analysis.
* Calculated attribute values are stored into the memory as the imported attributes, meaning the model requires more memory, if there are more new calculated attributes.
* Calculated attribute values are stored into the memory as the imported attributes, meaning the model requires more memory, if there are more new calculated attributes.

Revision as of 13:39, 13 March 2019

Data to case attributes and event attributes can be originated either by

  • importing them into QPR ProcessAnalyzer
  • calculating attribute values during model loading using an expression.

Notes about calculated attributes:

  • Calculated attributes are treated as the imported attributes, e.g. they can be used in the profiling or 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.
  • Filtering doesn't affect the values of calculated attributes, but filtering affects the aggregated results from calculated attributes, e.g. in the profiling analysis.
  • Calculated attribute values are stored into the memory as the imported attributes, meaning the model requires more memory, if there are more new 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 use the entice model in the expressions, such as variations, event types, flow and flow occurrences.
  • Calculated event attributes are processed first, so it's possible to use calculated event attributes in calculated case attributes expressions.
  • 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 later ones.
  • Calculated attribute can replace an imported attribute. 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, so the error needs to be corrected before the model can be used.

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 improvement: If there is an expression to aggregate event level information to a case level, the aggregation can be done using a calculated case attribute to provide better performance. Then the expression can process case level only without going to the event level, which performs considerably faster, because usually there are much less cases than events.

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:

  • name: Calculated attribute name.
  • expression: Expression to calculate the calculated attribute. When an expression has been defined, the attribute is a calculated attribute.

EventAttributes

Calculated event attributes are defined using the same structure as calculated case attributes.

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))"
  }
]
}