Please enable JavaScript to view this site.

 

Navigation: Data Engineer Guide > How to's

How to Create an Event Log for OCPM

Scroll Previous Topic Top Next Topic More

 

 

The main difference between the traditional event log and the object-centric event log are:

 

1.One process can have several objects, which bring their own type of Case ID. Hence, the Case ID is no longer one common identifier for the process instance to which all events are related but the identifier for the object itself, which caused the event to happen. For this reason, the former process instance is now captured in the new field Link in the CaseInformation table, while the object ID is captured in the field CaseID. To decide which CaseID belongs to which type of object, a new field ObjectType is implemented.

2.To see the interaction of objects in the ProcessAnalyzer some key activities are used as touchpoints, which means that an activity which originates from one object, is also shown in the process flow of another object. Example: items are packed into one package. In this case the touchpoint activity between the item and the package object could be "pack item", which originates from the item object but is also used in the package object to reflect the interaction or better said touchpoint between the two objects. The new field PrincipalObjectType has been implemented to keep the information from which object an activity was originally caused.

3.To keep the information from which source an event stems, the field ActivityOriginID is now obligatory. Furthermore, by tracking this information the counts on number of events are always correct when referring to this unique event identifier. Most important is the correct use of the ActivityOriginID when the activities are used as touchpoints. Here, the ActivityOriginID is the same ID when used in different objects, to prevent duplicates when counting or analyzing events.

This table shows the new fields and their purpose. We see three different caseIDs, which come from two item objects and one package object. The three objects are related via the Link field, which contains in this example the customer order ID. The field ObjectType holds the information of the object type for the CaseIDs. The ActivityType and ActivityStartTimestamp fields are well known. Finally, the purpose of the PrincipalObjectType and the field ActivityOriginID become clear when you take a closer look onto the blue highlighted cells. The two pack item events from the items 10010 and 10020 are repeated in the package object 20010. The PrincipalObjectType of this activity is always Item because we want to make clear that these pack item events are touchpoints between the item and the package, and that the package did not cause the event. Also, the ActivityOriginID is the same for the event Pack Item when used in the item process flow and in the package process flow. This prevents erroneous event counts as the distinct ActivityOriginID always gives the correct number of events.

Link

CaseID

ObjectType

ActivityType

PrincipalObjectType

ActivityOriginID

ActivityStartTimestamp

100

10010

Item

Pick Item

Item

10010_pick

04.04.2022 10:01:02

100

10010

Item

Pack Item

Item

10010_pack

04.04.2022 10:05:32

100

10020

Item

Pick Item

Item

10020_pick

04.04.2022 10:03:44

100

10020

Item

Pack Item

Item

10020_pack

04.04.2022 10:06:21

100

20010

Package

Create Package

Package

20010_create

04.04.2022 10:04:45

100

20010

Package

Pack Item

Item

10010_pack

04.04.2022 10:05:32

100

20010

Package

Pack Item

Item

10020_pack

04.04.2022 10:06:21

100

20010

Package

Send Package

Package

20010_send

04.04.2022 10:12:23

 

To sum up: for OCPM four new (now obligatory) fields are required:

 

1.Object Type

2.Principal Object Type

3.Activity Origin ID

4.Link

 

Given this information the creation of an object-centric event log is straight forward. We will show this with an example, shown below. Imagine a purchase-to-pay process (P2P) including purchase orders, purchase order items, deliveries as well as invoices and payments. Every objects has its own process flow, with interactions / touchpoints to other objects. The touchpoints are marked in blue.

 

The purchase order is created, released and closed with the last order-related payment and the last item-related delivery.

The purchase order item is created and may have price or quantity changes. It has touchpoints with the order when the order is created, with the delivery, when goods are receipt, .

The delivery document is created, a goods receipt is created upon delivery, and the delivery document is closed.

The invoice document is received and booked and closed with the last invoice-related payment.

The payment is scheduled and carried out.

 

To create the object-centric event log we recommend to follow these steps:

 

1.Create the event log for every object on its own without touchpoint events at first. Add the ObjectType,  the PrincipalObjectType field, and the ActivityOriginID to the event log table. The PrincipalObjectType equals the ObjectType as long as the event is not a touchpoint to another object. It should look like this:

CaseID

ObjectType

PrincipalObjectType

ActivityType

ActivityOriginID

ActivityStartTimestamp

ActivityEndTimestamp

1000

Purchase Order

Purchase Order

Order Created

1000_orderCreated

0205.2022 11:55:01

02.05.2022 11:58:41

1000

Purchase Order

Purchase Order

Order Released

1000_orderReleased

03.05.2022 14:15:08

03.05.2022 14:16:58

2000

Purchase Order

Purchase Order

Order Created

2000_orderCreated

03.05.2022 14:15:08

03.05.2022 14:16:58

 

 

 

 

 

 

 

CaseID

ObjectType

PrincipalObjectType

ActivityType

ActivityOriginID

ActivityStartTimestamp

ActivityEndTimestamp

100010

Order Item

Order Item

Item Created

100010_itemCreated

05.05.2022 14:15:01

05.05.2022 14:17:51

100010

Order Item

Order Item

Change Price

100010_changePrice

05.05.2022 18:15:08

05.05.2022 18:15:18

100020

Order Item

Order Item

Item Created

100020_itemCreated

05.05.2022 14:15:01

05.05.2022 14:17:51

 

 

 

 

 

 

 

CaseID

ObjectType

PrincipalObjectType

ActivityType

ActivityOriginID

ActivityStartTimestamp

ActivityEndTimestamp

4000101

Delivery

Delivery

Delivery Doc Created

4000101_docCreated

08.05.2022 14:15:01

08.05.2022 14:17:51

4000101

Delivery

Delivery

Goods Receipt

4000101_goodsReceipt

09.05.2022 18:15:08

09.05.2022 18:15:18

4000102

Delivery

Delivery

Delivery Doc Created

4000102_docCreated

09.05.2022 14:15:01

09.05.2022 14:17:51

4000102

Delivery

Delivery

Goods Receipt

4000102_goodsReceipt

10.05.2022 18:15:08

10.05.2022 18:15:18

 

 

 

 

 

 

 

CaseID

ObjectType

PrincipalObjectType

ActivityType

ActivityOriginID

ActivityStartTimestamp

ActivityEndTimestamp

5000101

Invoice

Invoice

Invoice Receipt

5000101_invReceipt

09.05.2022 18:16:08

09.05.2022 18:16:18

5000101

Invoice

Invoice

Invoice Booked

5000101_invBooked

10.05.2022 18:15:08

10.05.2022 18:15:18

5000102

Invoice

Invoice

Invoice Receipt

5000102_invReceipt

10.05.2022 18:16:08

10.05.2022 18:16:18

5000102

Invoice

Invoice

Invoice Booked

5000102_invBooked

11.05.2022 18:15:08

11.05.2022 18:15:18

 

 

 

 

 

 

 

CaseID

ObjectType

PrincipalObjectType

ActivityType

ActivityOriginID

ActivityStartTimestamp

ActivityEndTimestamp

6000101

Payment

Payment

Payment Scheduled

6000101_payScheduled

10.05.2022 15:16:08

10.05.2022 15:16:18

6000101

Payment

Payment

Payment

6000101_payment

11.05.2022 16:15:08

11.05.2022 16:15:18

6000102

Payment

Payment

Payment Scheduled

6000102_payScheduled

11.05.2022 16:16:08

11.05.2022 16:16:18

6000102

Payment

Payment

Payment

6000102_payment

12.05.2022 17:15:08

12.05.2022 17:15:18

2.Create the CaseInformation table which contains the CaseID and add the link to every CaseID so that the objects become related to each other. How do you choose the Link level? We recommend taking the former traditional CaseID as the Link. In our P2P example this would be the purchase order ID. The CaseInformation table contains the case context information as you know from the traditional process mining approach.

CaseID

Link

CaseDimension1

CaseDimension2

CaseDimension3

CaseDimension4

CaseDimension5

1000

1000

...

...

...

...

...

2000

2000

 

 

 

 

 

100010

1000

 

 

 

 

 

100020

1000

 

 

 

 

 

4000101

1000

 

 

 

 

 

4000102

1000

 

 

 

 

 

5000101

1000

 

 

 

 

 

5000102

1000

 

 

 

 

 

6000101

1000

 

 

 

 

 

6000102

1000

 

 

 

 

 

 
Having created the single objects event logs and the object links, the different logs can already be loaded to the MPM Template App as one concatenated event log. Since the touchpoint between the objects are still missing, the ProcessAnalyzer would show the five objects without any interaction:
OCPM_createLog_simpleExample_Analyzer_noTouchpoints

 

3.Create the touchpoints between the objects. You have several options here, we recommend you re-use events from other objects to create the interactions.

CaseID

ObjectType

PrincipalObjectType

ActivityType

ActivityOriginID

ActivityStartTimestamp

ActivityEndTimestamp

1000

Purchase Order

Delivery

Goods Receipt

4000102_goodsReceipt

10.05.2022 18:15:08

10.05.2022 18:15:18

1000

Purchase Order

Payment

Payment

6000102_payment

12.05.2022 17:15:08

12.05.2022 17:15:18

 

 

 

 

 

 

 

CaseID

ObjectType

PrincipalObjectType

ActivityType

ActivityOriginID

ActivityStartTimestamp

ActivityEndTimestamp

100010

Order Item

Purchase Order

Order Created

1000_orderCreated

0205.2022 11:55:01

02.05.2022 11:58:41

100010

Order Item

Delivery

Goods Receipt

4000101_goodsReceipt

09.05.2022 18:15:08

09.05.2022 18:15:18

100020

Order Item

Delivery

Goods Receipt

4000102_goodsReceipt

10.05.2022 18:15:08

10.05.2022 18:15:18

 

 

 

 

 

 

 

CaseID

ObjectType

PrincipalObjectType

ActivityType

ActivityOriginID

ActivityStartTimestamp

ActivityEndTimestamp

5000101

Invoice

Payment

Payment

6000101_payment

11.05.2022 16:15:08

11.05.2022 16:15:18

5000102

Invoice

Payment

Payment

6000102_payment

12.05.2022 17:15:08

12.05.2022 17:15:18

100020

Order Item

Delivery

Goods Receipt

4000102_goodsReceipt

10.05.2022 18:15:08

10.05.2022 18:15:18

 

 

 

 

 

 

 

 
In general the selection / definition of touchpoints is up to the data engineer and the definition during the process mining project. Different touchpoint definitions may be helpful for different purposes. In case the objects are less kind of an object and more kind of a sub-process it may be feasible to create artificial start and end events for the sub-processes and add them as touchpoints to the parent-process.
After modeling the touchpoints and concatenating them to the event logs from step 1, the ProcessAnalyzer shows this process flow:
OCPM_createLog_simpleExample_Analyzer

 

In the next section How to Configure the MPM Template App for OCPM (fast track) we will show you in a summed-up guide how to configure the MPM Template App correctly for OCPM.

 

 

© by MEHRWERK GmbH