We recently encountered an issue while working on a POC with Pega Process Mining. Upon closer inspection, we noticed a discrepancy between the data in the History class of our environment and the case-level analysis within the tool. To address this, we have a few inquiries that we believe will help us rectify the data inconsistency:
There seems to be a discrepancy in the number of events displayed in Process Mining compared to the History table for certain cases.
We observed that the StartDateTime and EndDateTime for some events are identical.
We are curious about the methodology used to calculate the end timestamp for an event in a view configuration.
Kindly review the attached screenshots for reference. Your assistance in addressing these queries would be immensely appreciated.
The Pega connector that Pega Process mining 1.1.1 ships with does not ingest all the history records for a case instance. The records are filtered out to bring in only those that are relevant for process analysis.
Some of the events like Created, Stage change, Status Change do not involve any effort. Only Flow actions involve a time for performance of the action.
The EndTimeStamp of an event should match the pxTimeCreated column in the work history table. The StartTimeStamp is derived using the formula, StartTimeStamp = EndTimeStamp - pxTaskElapsedTime. This includes both waiting time and perform time at a specific step.
I understand that the tool does not ingest all the data from the history class but doesn’t that cause reworks or a model violation when we make use of the case level analysis in the tool
We wanted to understand how the StartTimeStamp and the EndTimeStamp is ingested by the tool. Is the data taken for the entire case or a specific event in time like a stage or a status.
Also, we noticed the tool is duplicating events like the Created or a specific status but there is only one record available in the history class of the application. Is this a correct method the tool is taking.
I have attached the screenshot for point 3.Please help us resolve these queries
were page-list fields selected for this case type? If so, can you check if the event log for this case instance included a field with multiple values? we are currently recommending not selecting page-list properties to be ingested into PM because of this issue.
If this is not the case, please create an incident / support ticket for this to be looked into.
Regarding StartTimeStamp and EndTimeStamp, these are per event but they really make sense only for those events that are corresponding to ‘Flow action’ completions. (history records with pyHistoryType = ‘F’ in the history table)
Once we removed the pagelist properties, the duplicate events were no longer coming up. But could you also help us here, where you mentioned the tool does not ingest all the data/ events from the history class but doesn’t that cause reworks or a model violation when we make use of the case level analysis in the tool.
The connector ingests ‘flow action’ history records which are central to how a case is processed. What is not ingested are custom history records that an application author may decide to log, SLA events etc.
I do not see an issue with reworks from RCA or with model conformance checking features in process mining because these events are not being ingested. if you have a specific use-case where a desired result is not seen, please reach out to the team. thanks.
