Generally, there is a sorting column which you can alter the number per activity. So in the case below:
A will always come before B, if there is no timestamp and the dates are identical like above.
SELECT DISTINCT
"V_ORDERS"."_CASE_KEY" AS "_CASE_KEY"
,'Change Container ID' AS "ACTIVITY_EN"
, CAST("CDHDR"."UDATE" AS DATE) + CAST("CDHDR"."UTIME" AS TIME) AS "EVENTTIME"
, 100 AS "_SORTING"
,"CDHDR"."USERNAME" AS "USER_NAME"
,"USR02"."USTYP" AS "USER_TYPE"
,"CDPOS"."TABNAME" AS "CHANGED_TABLE"
,"CDPOS"."FNAME" AS "CHANGED_FIELD"
,"CDPOS"."VALUE_OLD"
,"CDPOS"."VALUE_NEW"
,"CDPOS"."CHANGENR" AS "CHANGE_NUMBER"
,"CDHDR"."TCODE" AS "TRANSACTION_CODE"
,"V_ORDERS"."MANDT" AS "MANDT"
,"V_ORDERS"."VBELN" AS "VBELN"
,"V_ORDERS"."POSNR" AS "POSNR"
Generally, there is a sorting column which you can alter the number per activity. So in the case below:
A will always come before B, if there is no timestamp and the dates are identical like above.
SELECT DISTINCT
"V_ORDERS"."_CASE_KEY" AS "_CASE_KEY"
,'Change Container ID' AS "ACTIVITY_EN"
, CAST("CDHDR"."UDATE" AS DATE) + CAST("CDHDR"."UTIME" AS TIME) AS "EVENTTIME"
, 100 AS "_SORTING"
,"CDHDR"."USERNAME" AS "USER_NAME"
,"USR02"."USTYP" AS "USER_TYPE"
,"CDPOS"."TABNAME" AS "CHANGED_TABLE"
,"CDPOS"."FNAME" AS "CHANGED_FIELD"
,"CDPOS"."VALUE_OLD"
,"CDPOS"."VALUE_NEW"
,"CDPOS"."CHANGENR" AS "CHANGE_NUMBER"
,"CDHDR"."TCODE" AS "TRANSACTION_CODE"
,"V_ORDERS"."MANDT" AS "MANDT"
,"V_ORDERS"."VBELN" AS "VBELN"
,"V_ORDERS"."POSNR" AS "POSNR"
Hello, thank you for your answer.
There is a process flow lets say A comes before B.
So A's sorting number is smaller than B. thats fine.
In our case, we changed the sorting numbers to enable A comes before B.
But we still see some cases B comes before A, we dont want that.
We give smaller sorting number to A.
What we can do more?
Hello, thank you for your answer.
There is a process flow lets say A comes before B.
So A's sorting number is smaller than B. thats fine.
In our case, we changed the sorting numbers to enable A comes before B.
But we still see some cases B comes before A, we dont want that.
We give smaller sorting number to A.
What we can do more?
Hello, thank you for your answer.
There is a process flow lets say A comes before B.
So A's sorting number is smaller than B. thats fine.
In our case, we changed the sorting numbers to enable A comes before B.
But we still see some cases B comes before A, we dont want that.
We give smaller sorting number to A.
What we can do more?
The Sorting Column can help with enforcing activity order when the timestamp of both activities is equal.
So if you have Activity A and B on the 06/03/2023, if the integer in sorting column A is smaller than B, then A comes before B in the process flow. However if for instance there is an activity C with a date 05/03/2023 and sorting value larger then B and A, than it will still be before A and B in the process flow, as the timestamp is earlier.
This is quite common unwanted behavior and usually has its origin in data quality or usage of source systems underlying data structure and storage. If you want to alter the dates, you can do so manually in the data job (data transformations).
Kind Regards,
Maurits
Hello, thank you for your answer.
There is a process flow lets say A comes before B.
So A's sorting number is smaller than B. thats fine.
In our case, we changed the sorting numbers to enable A comes before B.
But we still see some cases B comes before A, we dont want that.
We give smaller sorting number to A.
What we can do more?
Let me explain what happens in our case.
We want A --> B, so sorting number of A is 10, B is 20.
But we still see B --> A, we don't want that.
If I remove Event time column, the process will not flow :(
Because timestamp is one of the compulsory columns of Event log.
The Sorting Column can help with enforcing activity order when the timestamp of both activities is equal.
So if you have Activity A and B on the 06/03/2023, if the integer in sorting column A is smaller than B, then A comes before B in the process flow. However if for instance there is an activity C with a date 05/03/2023 and sorting value larger then B and A, than it will still be before A and B in the process flow, as the timestamp is earlier.
This is quite common unwanted behavior and usually has its origin in data quality or usage of source systems underlying data structure and storage. If you want to alter the dates, you can do so manually in the data job (data transformations).
Kind Regards,
Maurits
Okay, I got it now.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.