Configuring widgets

Change the title displayed in the header of your widget.

Choose where your data comes from: the event log, the object tables, or both.

If an object table is joined with CaseStats, you can use it together with CaseStats without using event log 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 ones you removed. For example, you can select a certain event log with its joined object tables and remove the event log from the data sources. All object tables with joins dependent on the event log are removed as well.

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. Custom metrics created in Advanced mode can directly include object table in the queries.

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.

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 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 have the following values:

• A name
• A query
• A formatter

When you start typing a query, 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 (" ").

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 Data structure 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
• Date and time
• Duration
• Lead time
• Number
• Percentage
• Text
• Amount

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:

Order by option 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.

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.

For example, use the following 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 alongside the filters that are applied on the event log.

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.

You can use the following examples to configure the activity interval in a 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.

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

If you select this option, 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.

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.

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

Advanced query mode is available only in elastic widgets. With the advanced query mode, you can configure your widget by using SQL queries. To use the advanced query mode, complete the following steps:

1. In the edit window of the elastic widget, set the toggle to Show advanced query.
2. Write your SQL query. Use the autocomplete to access all your data sources, table names, column names, and functions.
3. Click the test button to test your code. If your code is correct, the results from it populate the Dimension and Measures sections.
4. Optional: Edit the measure type. For more information, see Measures.
5. Set the Apply dashboard filters toggle to yes or no. For more information, see Apply dashboard filters.
6. Click Apply.

When you write a query, follow MonetDB syntax guidelines, particularly when you work with date functions.

Example 1

To extract the year and month from a date field, use the EXTRACT function with sys.epoch. The following query retrieves the number of stories that are opened per month.

SELECT count( *) AS frequency, (EXTRACT(YEAR FROM (sys.epoch(cs.starttime/1000))) || '-' ||EXTRACT(MONTH FROM (sys.epoch(cs.starttime/1000)))) AS period
FROM eventlog el JOIN case_stats cs
ON cs.caseid = el.CASEID
WHERE el.ISSUE_TYPE = 'Request'
GROUP BY EXTRACT(YEAR FROM (sys.epoch(cs.starttime/1000))) || '-' || EXTRACT(MONTH FROM (sys.epoch(cs.starttime/1000)))

You can view the results in a bar chart.

Example 2

For example, the following query retrieves the number of invoices that are opened in a month. The invoices are recorded in an object table.

SELECT count( *) AS frequency, (EXTRACT(MONTH FROM (sys.epoch(invoices.INVOICE_DATE/1000))) || '-' || EXTRACT(DAY FROM (sys.epoch(invoices.INVOICE_DATE/1000)))) AS period
FROM invoices 
GROUP BY (EXTRACT(MONTH FROM (sys.epoch(invoices.INVOICE_DATE/1000))) || '-' || EXTRACT(DAY FROM (sys.epoch(invoices.INVOICE_DATE/1000))))