The MPM eXecution Template App offers five standard MPM eXecution modules built into the MPM Template App. This section describes the differences between the standard MPM Template App script and the MPM eXecution Template script. These changes are usually also required, if a MPM Template App is enhanced with a custom build MPM eXecution module (more information you find here). Thus, this section serves as an overview which changes are required in a MPM Template App to add MPM eXecution modules.

 

In general, MPM eXecution requires three components to be added to the scripts:

 

1.Every module needs to read the changes from the data base

2.For every change made in the front-end an app reload is triggered. As a full reload takes a lot of time, every module should only trigger a minimal delta reload of the app. Thus, for every module a delta mode is defined which in- or excludes certain parts of the script.

3.The information created by the module need to be connected to the data model

 

 

Initiate MPM eXecution:

 

The first change in the MPM Template app is the larger init-section. Instead of one tab 0. Init, two general and one specific init tab per module are added.

 

4.The tab 0. Init MPM eXecution includes the MPM eXecution scripts and defines and opens the database connection.

// ::::::::::::::::::::::::::::::::: include script files for MPM eXecution :::::::::::::::::::::::::::::::

Let mvNextInclude = '[$(ScriptFolderConnection)' & 'mw_mpm_eXecution.qvs' & ']';

$(Include=$(mvNextInclude));

 

//  ::::::::::::::::::::::::::  open connection to MPM eXecution database :::::::::::::::::::::::::::::::

// change the expression for your data connection

LIB CONNECT TO 'My MPM eXecution Data Base';

 

Change the lib connect to your data connection, e.g. for a data connection to a PostgeSQL named MPM eXecution Demo DB the expression would change to LIB CONNECT TO 'MPM eXecution Demo DB'.

2.Every module has a init-tab called 0. Init Module <module name>.    

These tabs include the creation of help tables for each module (e.g. inline lists of users for the rules & actions or manual activities for the recording of manual activities). Furthermore, this tab calculates if a delta load or a full load is triggered. Every MPM eXecution module has it's own delta mode - because  fast update times after a data edit in the front-end are required. For example, the MPM Rules module does not need to trigger any other script than updating the changes from the data base table in the data model. The conformance checking module on the other side needs to trigger a re-calculation of the conformance checking with the changed happy paths. But both modules do not need to trigger for example the root cause analysis.

 

On these tabs you may need to change the data base table names, where the data are loaded from, we will specify this in the deploy-part of each module.

3.The tab 0Z. Variable & Table Control is used for debugging purposes.

 

 

General Implementation of the Delta Logic for MPM eXecution

 

If a change was done in the front-end by a user, MPM eXecution will trigger a reload of the app. To not reload all parts of the script every time, a delta logic for each MPM eXecution module is implemented.

 

This logic is based on a counter that counts up with every change that was made in the modules data base table. When reading entries from the data base table, the MPM data model stores the highest available changeCounter value from the data base table in the new data model table ChangeCounterTable.

 

 

In the ChangeCounterTable each module gets a field MaxChangeCounter<moduleName>. When a change is done in the front-end, the new or altered entry will get the module's MaxChangeCounter-value + 1 as new ChangeCounter value.

 

 

Thus, the MPM algorithms will detect in the subsequent reload, that the module's data base table has a higher ChangeCounter-number than stored in the data model table's MaxChangeCounter-field. And then the delta mode for this MPM eXecution module will be set to one - which in- or excludes specific parts of the script in the data editor.

 

E.g. when a new happy path is entered, the field ChangeCounter in the data base table we_fullData_MPM_HappyPaths will be set as MaxChangeCounterConfWrite+1 - in the example screenshot above this would be 31. But the MaxChangeCounterConfWrite in the MPM data model still contains the previously loaded highest ChangeCounter which is 31 as you see in the screenshot above, field MaxChangeCounterConfWrite.  In the next reload, the data base table we_fullData_MPM_HappyPaths will send the new maximum changeCounter, now 32, and as 32 is smaller than 31, the algorithms now detect, that a happy path was altered and that the conformance checking module should be reloaded. Hence, the delta-load variable mvDeltaLoadConformance for the MPM eXecution module Conformance Checking is set to 1.

 

To check if a update was made for a MPM eXecution module the following function is used in each module's initiating tab 0.Letter <module name>:

 

call mpm_eXecution_databasetable_update_check('HappyPathUpdate','ChangeCounterHappyPaths','ChangeCounterHappyPaths','ChangeCounterTable','mvDeltaLoadConformance','MaxChangeCounterConfWrite');

 

The parameters for this function are:

omvDatabaseTableName = name of the resident table containing the (transformed) data base table of the MPM eXecution module

omvDatabaseChangeCounterField = name of the resident table's change counter field

omvDatabaseTableChangeCounterVar = name of the variable that stores the change counter value for the module

omvChangeCounterTable = name of the data model table where the maximum change counter values are stored for each module

omvDeltaLoadVar = name of the variable that contains the delta load flag (1 for yes or 0 for no) for the MPM eXecution module

omvWriteField = name of the field in the mvChangeCounterTable to which the new maximum change counter value of the module should be written

 

 

 

 

Modifications of the Standard MPM Template App Tabs

 

First of all, every tab that originally stems from the MPM Template App is now enclosed by a if-condition, which steers if the script part is in- or excluded from the data load depending on the current delta-mode. For more information on the delta mode see below. Those MPM Template App standard tabs that furthermore are starting with _eXe_ have been modified slightly in the MPM eXecution Template.

 

 

5.the tab 1B. Load EventLog is adapted by the module Manual Activities (see Deploy MPM Manual Activties), to add the manual activities to the event log.

 

First, a new field ManualActivityTypeDummy is added to the event log, to create a dummy-field which can be used in the front-end to create new activities for a case:

 

EventLog: //Log table name: "EventLog"

LOAD

//ProcessAnalyzer information

 CaseID,

 "ActivityName" as ActivityType,

 Timestamp(ActivityStartTimestamp) as ActivityStartTimestamp,

 Timestamp(ActivityEndTimestamp) as ActivityEndTimestamp

//  LOGIC TO ADD MANUAL ACTIVITIES

 'Choose an activity' as ManualActivityTypeDummy

 

Second, the newly created activities from the front-end need to be added to the eventLog by this part of the script:

 

 

4.the tab 4. Conformance Checking is adapted by the modules Conformance Checking and BPMN Activity Mapping, to use the BPMN Activity Mapping and the new Happy Paths created by front-end users.

First a new method is called which processes the BPMN-activity mapping from the MPM eXecution module BPMN Activity Mapping.

 

call mw_get_BPMN_mapping('$(BPMNActivityTablePath)','$(eXecutionBPMNMappingDatabaseTable)');

 

A second method is added to the tab, which combines the new or edited happy paths from the MPM eXecution module Conformance Checking to the happy paths created in the back-end of those from the BPMN model.

 

call mw_combineHappyPaths_BPMN_FrontEnd_Database('$(HappyPathUpdate)');

 

 

3.a new tab 5A. ActionCreation was created, where the ActionRuleEngine for the MPM eXecution module Rules & Actions is placed.

Here you define actions that should be carried out for certain dimension values based on different metrics. More information on this topic are provided in this section: Create actions and tasks with the rule engine.

 

4.the tab 5. Root Cause Analysis is adapted by the modules Actions & Rules and Critical Paths.

First, the module Critical Paths sends the queries created in the front-end to the RCA in the back-end:

 

Second, for the module Rules & Actions the strongest detected correlations between an anomaly and a dimension-value are stored as actions with this method:

 

call mw_concate_rca_results_to_actions('ActionRules');