Configuring widgets

From clause

The from clause is an equivalent of FROM SQL query. You can choose where your data comes from. eventlog is your main source data, but you can choose to use data from object tables. If an object table is joined with CaseStats, you can use it together with CaseStats without using eventlog as a data source. For more information, see Object tables.

You can add dimensions that are based on an object table. For example, you can use the role column from your object table to filter the data of your event logs.

You can choose multiple sources of data. However, if you select a certain event log, you cannot also select an object table that is not joined with it.

When you remove a certain data source, all other data sources dependent on it also get removed. This happens when the data sources that you chose cannot be joined without the one you removed. Example: You select a certain event log, and then some object tables that are joined with it. Then, you remove the event log from the data sources. All the object tables with joins dependent on the event log also get removed.

To use a custom metric where the Group by clause includes an event log column, include the statistics table in the from clause. Make sure that the table is created for the respective column.

Dimensions

Dimensions represent the category of information that you want to track, such as activities, referrers, pages, country of origin, product category, and other items whose attributes are often nonnumerical. A dimension produces a GROUP BY clause in the underlying SQL query. Depending on the widget, these fields can be case-id, activity, resource, role, pathtime, or any custom field. The analysis can be grouped by the end-time or start-time of the cases (on either an hourly, daily, monthly, or yearly time frame).

More than one dimension might be required depending on the widget.

From an SQL perspective, the dimensions are the values of the columns you select from the eventlog or object tables (in the From clause) and on which you group by your selection.

Set Case fill to On to auto-fill custom fields that have empty values by using previous value in the same case.

When you create an analytics widget that uses a field name with special characters, you must enter the custom field names in double quotation marks (" ").

Measures (Query)

Measures indicate the quantities that you want to measure such as number of visits, page views, hits, bounce rates, and other items that can be strings or dates. Measures can be used as an SQL builder. Each measure needs to specify the following values:

• A label (the alias of the measure)
• A query

When you start typing, you can see all the available data sources (event logs and object tables) in the autocomplete dropdown list. Add a dot after the data source name to see all the columns available for that table.

When you create an analytics widget by using a field name with special characters, you must enter the custom field names in double quotation marks (" ").

As Measures are displayed in the widget, insert custom queries to specify what you want to analyze. For example, you can compose a measure query by using operators together with columns, parameters or custom metrics.

Along with the standard SQL operators and functions such as AVG, COUNT, SUM, or DISTINCT and in addition to the data columns imported by the user (they can be viewed in the Help section), IBM Process Mining calculates parameters that are designed for process analysis.

The COUNT(*) operator is applied on the rows that are filtered by the widget, which includes the set of filters that are applied at PM, dashboard and widget where clause levels.

When you use a COUNT function with an input argument, the function counts only the rows that are retrieved by the widget.

IBM Process Mining facilitates the use of the following functions:

casecost()
This computes the cost of a case, according to the defined cost model. This custom function is a CASE property.

leadtime()
This precomputed parameter is a CASE property and it returns the lead time of the case that the event belongs to. Leadtime() indicates the timespan between the start time of the first event and the end time of the last event.

keeplast()
This function keeps only the last eventlog record for each case. This prevents cardinality issues while using leadtime and functions from case_stats table. The following code is an example of this function:

select avg(leadtime), keeplast(Region)
from case_stats, join eventlog
group by Region

The formatter shows the value of a measure. It can be set to the following configurations:

• Auto
• Date
• Duration
• Lead time
• Heatmap
• Number
• Percentage
• Text

When you select duration as formatter, business hours and calendar are expressed in hours.
When you select lead time as formatter, business hours and calendar are expressed in days.

The following table presents the numerical functions that you can use inside queries:

Filters

Filters direct analytics to the cases on which you want to run the query. A filter produces a WHERE clause in the underlying SQL query.

Set specific filters for the widget to analyze the dimensions and measures only for the filtered events. When you start typing, you can see all the available data sources (event logs and object tables) in the autocomplete dropdown list. Add a dot after the data source name to see all the columns available for that table.

From an SQL point of view, filters express WHERE conditions. You can use subquery statements to make them more specific. Example: Subquery to select cases awaiting validation:

caseid in (select caseid from eventlog where eventlog.ACTIVITY = 'Waiting validation')

To apply filters with Boolean values, such as parameters or custom metrics, use 1 for true and 0 for false.

Dashboard filters are applied on top of the filters that are applied on the event log.

Activity interval

You can restrict the measure computation to the activities in the defined interval.

You must activate and select the activity interval to compute the Pathtime based measure.

For both the start and the end activity of the path, you can choose whether to consider the following settings:

First instance
If reworks occurred on the activity, the path considers the first execution.
Last instance
If reworks occurred on the activity, the path considers the last execution.

For both the start and the end activity of the path, you can choose whether to consider the following settings:

The start time
The start activity execution time is included in the path or the end activity execution time is excluded from the path.
The end time (if available)
The start activity execution time is excluded from the path or the end activity execution time is included in the path.

For example, the following picture shows the differences on the computation of the average pathtime from the start of “Warehouse Loading” to the end of “Invoice Check”:

You can use the following examples to configure the Activity interval widget:

• Setting the Activity interval to “from last instance by using start time to first instance by using end time” excludes all the reworks from the computation.

• Setting the Activity interval to “from first instance by using start time to first instance by using start time” includes all the reworks on the start activity.

• Setting the Activity interval to “from last instance by using end time to last instance by using end time” includes all the reworks on the start activity. Then, the path also includes “Goods check” and “Wait” activities.

• Setting the Activity interval to “from first instance by using start time to last instance by using end time" includes all the reworks in the computation.

Apply dashboard filters

You can choose whether the dashboard filters are used in the chosen filter. If you do not use them, only IBM Process Mining filters are applied. This decision can be useful when comparing measures with and without specific filters.

Activities conformance

You can choose whether you want to keep conformant or non-conformant activities.

Keep last event for each case

If selected, only the last event per case is considered for the selected measures.

The following table represents a part of an event log.

The values in the Amount column cannot be defined as case-level or event-level.

If you calculate the average of the data in the Amount field, the returned value is 83.333(3) because the average is calculated by considering each event separately.

If you want to calculate the average at a case-level, enable the Keep last event for each case function.

This toggle allows you to keep the last events (from a timestamp perspective) that are returned for each case, and filter out all the other filters. These events are filtered through the Date column.

The following table represents the data that is returned by the event log filter with the Keep last event for each case function enabled:

If you calculate the average of the data in the Amount field with Keep last event for each case switch that is enabled, the returned value is 75.

Keep last event for each case is applied on top of the other widget filters, including activity interval.

For example, the filtering can be applied without the Keep last event for each case option:

Filters: activity = 'Activity2'

The following table represents the 3 events from the event log that is returned with this configuration:

The following table represents the 2 events from the event log that is returned with the Keep last event for each case enabled:

The widget filter is applied first, then the Keep last event for each case option keeps the last event of each case.

Order by

Order by specifies the measure or dimension by which the underlying SQL query must be sorted. The results might vary depending on the selected ordering. You can view the results in a descending or ascending order.