Calculated Attributes in QPR ProcessAnalyzer: Difference between revisions

From QPR ProcessAnalyzer Wiki
Jump to navigation Jump to search
No edit summary
 
(24 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Case and event attributes data can be originated either
Calculated attributes enable to create case and event attributes using a expressions (calculation formula) based on data in the QPR ProcessAnalyzer model. Calculated attributes can be modified and Model attributes dialog that can be opened in the models list in the header. Note that when calculated attributes are changed, the model is dropped from the memory, so that the changed attributes can be recalculated (reloading large models might take time).
* by '''importing''' them into QPR ProcessAnalyzer, or
* by '''calculating''' attribute values during model loading using an [[QPR ProcessAnalyzer Expressions|expression]].


Notes about calculated attributes:
== Setting calculated attributes ==
* Calculated attributes are treated as the imported attributes, e.g. they can be used in the profiling or influence analyses.
Calculated case and event attributes are set for each model separately in the '''Model attributes''' dialog that can be opened in the models list in the header. The dialog has '''Case attributes''' and '''Event attributes''' tabs, where each contain an ordered list of case/event attributes. Each attribute has a name, and in addition it should be defined how the attribute value is calculated. There is a list of ready made selections (same as the dimensions list in the [[QPR_ProcessAnalyzer_Chart#Measures.2C_Dimensions_and_Columns|chart settings]], and additionally a custom expression can be written for the calculated attribute. It's possible to convert a ready-made selection into a custom expression by selecting '''Custom expression''' from the list, e.g. to modify the ready-made selection.
* 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.
 
* Filtering doesn't affect the values of calculated attributes, but filtering affects the aggregated results from calculated attributes, e.g. in the profiling analysis.
== Functioning principle and use cases ==
* 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.
Data to case attributes and event attributes can be originated as follows:
* Calculated event attributes are processed first, so it's possible to use calculated event attributes in calculated case attributes expressions.
* '''Import''' them into QPR ProcessAnalyzer from a source system, csv file etc.
* 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.
* '''Calculate''' attribute values when the model is loaded using an [[QPR ProcessAnalyzer Expressions|expression]].
* 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 work as follows:
* After the model is loaded, the calculated and imported attributes work similarly, e.g. both are available in the profiling and root causes 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 in the Model properties in the '''Calculated case attributes''' and '''Calculated event attributes''' tabs. The new attributes can be created, existing modified, reordered and deleted. Each attribute has '''Name''' and '''Calculation expression'''. The expression is calculated in the case's or event's context.


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 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.
* 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.
 
== Examples of calculated case attributes ==
 
Cost:
<pre>Cost * 1.5</pre>
 
myBooleanAttribute1:
<pre>CURRENCYCODE == "RUB"</pre>
 
Combined status:
<pre>PurchaseStatus + " " + PurchaseType</pre>
 
Repeated Events Count:
<pre>Count(_.Events) - Count(Distinct(_.Events.Type))</pre>


Calculated case and event attributes are configured to the model JSON settings are follows:
Automation of first Shipment Sent:
{| class="wikitable"
<pre>If(Count(_.EventsByType("Shipment Sent"))==0, null, (_.EventsByType("Shipment Sent").Attribute("Automation"))[0])</pre>
!'''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.
Duration between "Invoice Sent" and "Payment Received":
<pre>
<pre>
"CaseAttributes": [
If(Count(_.EventsByType("Invoice Sent")) == 0 || Count(_.EventsByType("Purchase Order Line Created")) == 0,
   {
   null,
    "name": "Cost",
  GetAtReverse(0, _.EventsByType(["Invoice Sent", "Payment Received"])).Timestamp - GetAt(0, _.EventsByType(["Invoice Sent", "Payment Received"])).Timestamp
    "expression": "Cost * 1.5"
)
  }
}
</pre>
</pre>


Example 2: Two calculated event attributes:
KPI_SegregationOfDuties:
<pre>
<pre>
"EventAttributes": [
Count(
   {
   Intersect(
     "name": "Event Month",
     _.EventsByType("Purchase Order Created").Attribute("User"),
     "expression": "Timestamp.Truncate(\"month\")"
     _.EventsByType("Purchase Order Approved").Attribute("User")
   },
   ).
   {
   Where(!Isnull(_) && _ != "")
    "name": "Duration to Next Event",
) > 0
    "expression": "If(IsNull(_.NextInCase), null, (_.NextInCase.Timestamp-_.Timestamp))"
  }
]
</pre>
</pre>


Example 3: Several calculated case and event attributes:
== Example of calculated event attributes ==
<pre>
 
{
Event Month:
"CaseAttributes": [
<pre>Timestamp.Truncate("month")</pre>
  {
 
    "name": "myBooleanAttribute1",
Duration to Next Event:
    "expression": "CURRENCYCODE == \"RUB\""
<pre>If(IsNull(_.NextInCase), null, (_.NextInCase.Timestamp-_.Timestamp))</pre>
  },
 
  {
Event type occurrence number:
    "name": "Combined status",
<pre>let eventTypeName = _.Typename;Count(_.Recurse(_.PreviousInCase).Where(_.Typename==eventTypeName))</pre>
    "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))"
  }
]
}
</pre>


[[Category: QPR ProcessAnalyzer]]
[[Category: QPR ProcessAnalyzer]]

Latest revision as of 22:20, 18 April 2023

Calculated attributes enable to create case and event attributes using a expressions (calculation formula) based on data in the QPR ProcessAnalyzer model. Calculated attributes can be modified and Model attributes dialog that can be opened in the models list in the header. Note that when calculated attributes are changed, the model is dropped from the memory, so that the changed attributes can be recalculated (reloading large models might take time).

Setting calculated attributes

Calculated case and event attributes are set for each model separately in the Model attributes dialog that can be opened in the models list in the header. The dialog has Case attributes and Event attributes tabs, where each contain an ordered list of case/event attributes. Each attribute has a name, and in addition it should be defined how the attribute value is calculated. There is a list of ready made selections (same as the dimensions list in the chart settings, and additionally a custom expression can be written for the calculated attribute. It's possible to convert a ready-made selection into a custom expression by selecting Custom expression from the list, e.g. to modify the ready-made selection.

Functioning principle and use cases

Data to case attributes and event attributes can be originated as follows:

  • Import them into QPR ProcessAnalyzer from a source system, csv file etc.
  • Calculate attribute values when the model is loaded using an expression.

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 root causes 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 in the Model properties in the Calculated case attributes and Calculated event attributes tabs. The new attributes can be created, existing modified, reordered and deleted. Each attribute has Name and Calculation expression. The expression is calculated in the case's or event's context.

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.

Examples of calculated case attributes

Cost:

Cost * 1.5

myBooleanAttribute1:

CURRENCYCODE == "RUB"

Combined status:

PurchaseStatus + " " + PurchaseType

Repeated Events Count:

Count(_.Events) - Count(Distinct(_.Events.Type))

Automation of first Shipment Sent:

If(Count(_.EventsByType("Shipment Sent"))==0, null, (_.EventsByType("Shipment Sent").Attribute("Automation"))[0])

Duration between "Invoice Sent" and "Payment Received":

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
)

KPI_SegregationOfDuties:

Count(
  Intersect(
    _.EventsByType("Purchase Order Created").Attribute("User"),
    _.EventsByType("Purchase Order Approved").Attribute("User")
  ).
  Where(!Isnull(_) && _ != "")
) > 0

Example of calculated event attributes

Event Month:

Timestamp.Truncate("month")

Duration to Next Event:

If(IsNull(_.NextInCase), null, (_.NextInCase.Timestamp-_.Timestamp))

Event type occurrence number:

let eventTypeName = _.Typename;Count(_.Recurse(_.PreviousInCase).Where(_.Typename==eventTypeName))