mpmX Help Documentation

 

In the customizing script folder you can find the custom_logic.qvs file where a table EventLog is defined.

 

The fields in this table are divided in two categories ProcessAnalyzer information and Event information.

 

 

 

ProcessAnalyzer information

 

This part of the EventLog table needs to be filled with CaseID and activity-related information. Rename the fields before the "as", this represents the field name (column name) of the event log that is read in.

 

 

1.Change the field names before "as" to match the names of your data.

If your data fields (as in the Helpdesk example) are already named like CaseID, ActivityType, ActivityTypeID, ActivityStartTimestamp and ActivityEndTimestamp, you can keep them unchanged.

 

2.If you don't have an ActivityTypeID, you don't need to do anything. The script recognizes automatically the necessary fields. In the case this field is not in your table, it will be created automatically. Otherwise, include it in your EventLog table.

 

3.If there are timestamps in your data, format them as your data is structured. The syntax is:

 

Timestamp(Timestamp#("DataTimestampFieldName", 'YYYY-MM-DD hh:mm:ss')) as ActivityStartTimestamp

 

 

In this example, the value in the field DataTimestampFieldName looks like this: 2019-11-26 15:20:04. For this reason, the formatting in the ActivityStartTimestamp line is 'YYYY-MM-DD hh:mm:ss'.

If the timestamp in your data is structured like 26/11/2019 15:25, use 'DD/MM/YYYY hh:mm'.

Another example could be 26.Nov.19 16:22:11:000, which is formatted as 'DD.MMM.YY hh:mm:ss:fff'. If you want to display the milliseconds in the app, then delete the square brackets surrounding the .fff in the variable timestamp format (Simple_Init tab). See the Qlik help for more information.

 

4.If for the activities exists a specific sorting criteria apart from their timestamp, add it as SortingColumn. If not, define the column as Null() as SortingColumn.

 

SortingField as SortingColumn

 

 

In the Helpdesk example, the timestamps are already formatted. For this reason, it was not necessary to add the clause timestamp#().

For further information on timestamp conversion, please see Qlik's help.

 

 

EventLog: //Log table name: "EventLog"

LOAD

//ProcessAnalyzer information

 CaseID,

 "ActivityName" as ActivityType,

 Timestamp(ActivityStartTimestamp) as ActivityStartTimestamp,

 Timestamp(ActivityEndTimestamp) as ActivityEndTimestamp

 

 Helpdesk example:

 

EventLog: //Log table name: "EventLog"

LOAD

//ProcessAnalyzer information

 CaseID,

 ActivityType,

 Timestamp(ActivityStartTimestamp) as ActivityStartTimestamp,

 Timestamp(ActivityEndTimestamp) as ActivityEndTimestamp

 

 

5.If you want to calculate automation rates in the front-end, and activate the sheet Automation, add a field to the EventLog called RealUser, where you mark if the event was carried out by a real user (then put 1) or if it was carried out automatedly (then put 0)

 

 

EventLog: //Log table name: "EventLog"

LOAD

//ProcessAnalyzer information

 CaseID,

 "ActivityName" as ActivityType,

 Timestamp(ActivityStartTimestamp) as ActivityStartTimestamp,

 Timestamp(ActivityEndTimestamp) as ActivityEndTimestamp,

 UserName as ActivityUserName,

 if(wildmatch(UserName,'*batch'),0,1) as RealUser

 

 

6.If you want to calculate rework rates in the front-end, and activate the sheet Rework, add a field to the EventLog called ReworkEvent, where you mark if the event is a type of rework (then put 1) or not (then put 0)

 

 

EventLog: //Log table name: "EventLog"

LOAD

//ProcessAnalyzer information

 CaseID,

 "ActivityName" as ActivityType,

 Timestamp(ActivityStartTimestamp) as ActivityStartTimestamp,

 Timestamp(ActivityEndTimestamp) as ActivityEndTimestamp,

 if(wildmatch(ActivityName,'*change),1,0) as ReworkEvent

 

For the definition of rework you have even more options. Just write your preferred option to the variable mvSetExpressionReworkDefinition

•ReworkEvent: only events, that are marked as rework by their type directly in the eventLog are considered as rework

•RepeatedEvent: only events, that are a repeated/looped in the eventLog are considered as rework

•ReworkAndRepeatedEvent: events, that are marked as rework by their type directly in the eventLog and by the same time are repeated are considered as rework

•ReworkOrRepeatedEvent: events, that are marked as rework by their type directly in the eventLog or are repeated are considered as rework

 

SET mvSetExpressionReworkDefinition = ReworkOrRepeatedEvent;