Hi again,
In one of my last blog postings about Process Observer, I introduced the Direct Event API as an alternative to using BOR events for logging. The implementation sample given at the end of that posting can easily be extended to perform the tracking of changes that are made to orders on field level. This information is then available for process monitoring and analysis.
Tracking of Field Changes
[To work in the customer namespace, you enter task type IDs starting with Z here.]
You combine the task type with the corresponding task, thereby defining a new task:
Then you can create one or more new activities in the process definition and assign the new task for monitoring (transaction POC_MODEL). In our example, we create just one new activity for ‘Change Purchase Order’ and add the different change tasks. As a result, the activity will be logged when any of the tasks is being observed. Item level tasks are flagged.
In the application instrumentation, you have to add the creation of the field change events. To identify the change, you compare the new value with the old value as provided by the interface. The new coding is highlighted here:
METHOD IF_EX_ME_PURCHDOC_POSTED~POSTED.
* data definitions
FIELD-SYMBOLS: <fs_ekpo> TYPE uekpo.
DATA ls_event TYPE poc_s_event.
DATA lt_event TYPE poc_t_event.
DATA ls_pre_bo TYPE poc_s_pre_bo_event.
DATA lv_time TYPE poc_execution_time.
DATA lv_transaction_id TYPE poc_transaction_id.
* loop at purchase order items
LOOP AT im_ekpo ASSIGNING <fs_ekpo> WHERE bstyp = 'F'. "Purchase Orders
"Check the field MEMORY to see if the PO document is COMPLETE.
IF im_ekko-memory = 'X'. "ABAP_TRUE
"Incomplete Document. Do not proceed
CONTINUE.
ENDIF.
* compose event
CLEAR ls_event.
ls_event-bo_id = im_ekko-ebeln. " Purchase Order ID
ls_event-item_id = <fs_ekpo>-ebelp. " item ID
ls_event-bo_type = '001'.
" BO Type ID (001 = Purchase Order)
CALL FUNCTION 'TH_GET_TRANSACTION_ID' " Kernel Transaction ID
IMPORTING
transaction_id = lv_transaction_id.
ls_event-transaction_id = lv_transaction_id.
GET TIME STAMP FIELD lv_time. " Execution Date/time
ls_event-executed_at = lv_time. " Execution Date/time
ls_event-executed_by = sy-uname. " user
IF sy-tcode IS NOT INITIAL.
ls_event-cbe_category = '01'.
" Callable Business Entity: cat ‘01’ = Transaction
ls_event-cbe_type = sy-tcode. " tcode
ENDIF.
"Predecessor Business Objects (document flow) – loop over schedule line items
ls_pre_bo-pre_bo_type = '108'.
" BO Type ID (108 = Purchase Requisition)
LOOP AT im_eket INTO ls_pre_bo_pr WHERE ebeln = <fs_ekpo>-ebeln
AND ebelp = <fs_ekpo>-ebelp.
ls_pre_bo-pre_bo_id = ls_pre_bo_pr-banfn.
ls_pre_bo-pre_item_id = ls_pre_bo_pr-bnfpo.
APPEND ls_pre_bo TO ls_event-previous_bo.
CLEAR ls_pre_bo .
ENDLOOP.
* check the change type of thepurchase order item
CASE <fs_ekpo>-kz.
WHEN 'I'.
" purchase order item was created
ls_event-event_type = '901'.
" task type ID (901 = Create item)
WHEN 'U'.
" purchase order item was updated
IF im_ekko_old-memory = 'X'.
"we need to consider this as a new CREATE.
ls_event-event_type = '901'. " Create item
APPEND ls_event TO lt_event.
ELSE.
READ TABLE im_ekpo_old INTO ls_ekpo_old
WITH KEY banfn = <fs_ekpo>-banfn
bnfpo = <fs_ekpo>-bnfpo.
IF <fs_ekpo>- menge <> ls_ekpo_old- menge OR
<fs_ekpo>- meins <> ls_ekpo_old- meins.
ls_event-event_type = '912'.
" Line Item Quantity Changed
APPEND ls_event TO lt_event.
ENDIF.
IF <fs_ekpo>-netpr <> ls_ekpo_old-netpr OR
<fs_ekpo>-peinh <> ls_ekpo_old-peinh.
ls_event-event_type = '913'.
" Change of Net Amount
APPEND ls_event TO lt_event.
ENDIF.
ENDIF.
WHEN OTHERS.
…
APPEND ls_event TO lt_event.
ENDCASE.
ENDLOOP.
* finally raise list of events to Process Observer
IF lt_event[] IS NOT INITIAL.
CALL FUNCTION 'POC_RAISE_EVENT'
EXPORTING
it_event = lt_event
iv_commit = abap_false.
ENDIF.
CLEAR lt_pre_bo_pr.
ENDMETHOD.
Note: Predecessor information has to be filled only if the predecessor is a different business object (item).
After you have created a Process Requisition (ME51N) and a corresponding Purchase Order item (ME21N), you change the observed ‘Purchasing Group’ field. When you have saved the change, you find the following entries in the process monitor (transaction POC_MONITOR). The information about the
actual observed task - which field was changed – can be found in the ‘Related Activities’ section.
To further operationalize this, that is, to be informed or to automatically react to such field changes, you create a counter KPI which counts the corresponding field changes (transaction POC_MODEL). In addition to the article ‘Create KPI definitions for Process Observer’, it is important to know that KPIs can also be defined on task level. This means that instead of defining an activity for counting, you specify the BO type and the task type.
Then you set a threshold value (same transaction). You can set the threshold to the value when you want to be informed. If you want to be informed about any changes that are taking place in a field, just set the field value to 1. You will then be informed when the first change to the field is made.
Note: A BAdI and a BRF+ function that allow you to set thresholds specific to a process instance during process runtime are also available.
You can then use the threshold event created by Process Observer to create notifications and actions as it is described in blog Using Thresholds and Alerting in Process Observer.
To analyze field changes, you perform a BI analysis using the data source ‘Process KPIs’ (see also BI Content for Process Observer) or aggregate data contained in table POC_D_KPI in a SAP HANA system, for example, by using SAP Operational Process Intelligence.
[Screenshot taken from Bex report on changes in Sales Orders]
Related Use Cases (Exception Tracking)
Instead of just tracking simple field changes, you can combine the tracking with more complex calculations. You may, for example, want to evaluate whether a quantity within an order is within a predefined limit. If it is not, you want to be informed of this.
If this is the case, you define a new task type and the ‘Quantity Exceeds Limits’ task as described above and add it to the process definition. Here it may make sense to have a separate activity for the event that is considered to be the exception:
In the application BAdI, you first check whether the quantity was changed. If so, calculate whether the quantity is still within the limit, if not, add the ‘Quantity Exceeds Limits’ event.
IF <fs_ekpo>-menge > lv_qty_upper_limit
" Schedule Line Quantity Exceeds Limits
ls_event-event_type = 'Z001'.
…
APPEND ls_event TO lt_event.
ENDIF.
…
You have seen how easy it is to leverage Process Observer for tracking field changes in your documents or for monitoring related issues such as exceptions.
Stay tuned for more tips and tricks about Process Observer!
In one of my last blog postings about Process Observer, I introduced the Direct Event API as an alternative to using BOR events for logging. The implementation sample given at the end of that posting can easily be extended to perform the tracking of changes that are made to orders on field level. This information is then available for process monitoring and analysis.
Tracking of Field Changes
First we need to add the changes we want to track to the process definition. The best practice is to create your own task types for each event to be tracked. To do so, you create corresponding entries in the task type table of the process façade (transaction POC_FACADE).
[To work in the customer namespace, you enter task type IDs starting with Z here.]
You combine the task type with the corresponding task, thereby defining a new task:
Then you can create one or more new activities in the process definition and assign the new task for monitoring (transaction POC_MODEL). In our example, we create just one new activity for ‘Change Purchase Order’ and add the different change tasks. As a result, the activity will be logged when any of the tasks is being observed. Item level tasks are flagged.
In the process monitor, you can see which tasks have actually been executed (see below).
In the application instrumentation, you have to add the creation of the field change events. To identify the change, you compare the new value with the old value as provided by the interface. The new coding is highlighted here:
METHOD IF_EX_ME_PURCHDOC_POSTED~POSTED.
* data definitions
FIELD-SYMBOLS: <fs_ekpo> TYPE uekpo.
DATA ls_event TYPE poc_s_event.
DATA lt_event TYPE poc_t_event.
DATA ls_pre_bo TYPE poc_s_pre_bo_event.
DATA lv_time TYPE poc_execution_time.
DATA lv_transaction_id TYPE poc_transaction_id.
* loop at purchase order items
LOOP AT im_ekpo ASSIGNING <fs_ekpo> WHERE bstyp = 'F'. "Purchase Orders
"Check the field MEMORY to see if the PO document is COMPLETE.
IF im_ekko-memory = 'X'. "ABAP_TRUE
"Incomplete Document. Do not proceed
CONTINUE.
ENDIF.
* compose event
CLEAR ls_event.
ls_event-bo_id = im_ekko-ebeln. " Purchase Order ID
ls_event-item_id = <fs_ekpo>-ebelp. " item ID
ls_event-bo_type = '001'.
" BO Type ID (001 = Purchase Order)
CALL FUNCTION 'TH_GET_TRANSACTION_ID' " Kernel Transaction ID
IMPORTING
transaction_id = lv_transaction_id.
ls_event-transaction_id = lv_transaction_id.
GET TIME STAMP FIELD lv_time. " Execution Date/time
ls_event-executed_at = lv_time. " Execution Date/time
ls_event-executed_by = sy-uname. " user
IF sy-tcode IS NOT INITIAL.
ls_event-cbe_category = '01'.
" Callable Business Entity: cat ‘01’ = Transaction
ls_event-cbe_type = sy-tcode. " tcode
ENDIF.
"Predecessor Business Objects (document flow) – loop over schedule line items
ls_pre_bo-pre_bo_type = '108'.
" BO Type ID (108 = Purchase Requisition)
LOOP AT im_eket INTO ls_pre_bo_pr WHERE ebeln = <fs_ekpo>-ebeln
AND ebelp = <fs_ekpo>-ebelp.
ls_pre_bo-pre_bo_id = ls_pre_bo_pr-banfn.
ls_pre_bo-pre_item_id = ls_pre_bo_pr-bnfpo.
APPEND ls_pre_bo TO ls_event-previous_bo.
CLEAR ls_pre_bo .
ENDLOOP.
* check the change type of thepurchase order item
CASE <fs_ekpo>-kz.
WHEN 'I'.
" purchase order item was created
ls_event-event_type = '901'.
" task type ID (901 = Create item)
WHEN 'U'.
" purchase order item was updated
IF im_ekko_old-memory = 'X'.
"we need to consider this as a new CREATE.
ls_event-event_type = '901'. " Create item
APPEND ls_event TO lt_event.
ELSE.
READ TABLE im_ekpo_old INTO ls_ekpo_old
WITH KEY banfn = <fs_ekpo>-banfn
bnfpo = <fs_ekpo>-bnfpo.
IF <fs_ekpo>- menge <> ls_ekpo_old- menge OR
<fs_ekpo>- meins <> ls_ekpo_old- meins.
ls_event-event_type = '912'.
" Line Item Quantity Changed
APPEND ls_event TO lt_event.
ENDIF.
IF <fs_ekpo>-netpr <> ls_ekpo_old-netpr OR
<fs_ekpo>-peinh <> ls_ekpo_old-peinh.
ls_event-event_type = '913'.
" Change of Net Amount
APPEND ls_event TO lt_event.
ENDIF.
ENDIF.
WHEN OTHERS.
…
APPEND ls_event TO lt_event.
ENDCASE.
ENDLOOP.
* finally raise list of events to Process Observer
IF lt_event[] IS NOT INITIAL.
CALL FUNCTION 'POC_RAISE_EVENT'
EXPORTING
it_event = lt_event
iv_commit = abap_false.
ENDIF.
CLEAR lt_pre_bo_pr.
ENDMETHOD.
Note: Predecessor information has to be filled only if the predecessor is a different business object (item).
After you have created a Process Requisition (ME51N) and a corresponding Purchase Order item (ME21N), you change the observed ‘Purchasing Group’ field. When you have saved the change, you find the following entries in the process monitor (transaction POC_MONITOR). The information about the
actual observed task - which field was changed – can be found in the ‘Related Activities’ section.
To further operationalize this, that is, to be informed or to automatically react to such field changes, you create a counter KPI which counts the corresponding field changes (transaction POC_MODEL). In addition to the article ‘Create KPI definitions for Process Observer’, it is important to know that KPIs can also be defined on task level. This means that instead of defining an activity for counting, you specify the BO type and the task type.
Then you set a threshold value (same transaction). You can set the threshold to the value when you want to be informed. If you want to be informed about any changes that are taking place in a field, just set the field value to 1. You will then be informed when the first change to the field is made.
Note: A BAdI and a BRF+ function that allow you to set thresholds specific to a process instance during process runtime are also available.
You can then use the threshold event created by Process Observer to create notifications and actions as it is described in blog Using Thresholds and Alerting in Process Observer.
To analyze field changes, you perform a BI analysis using the data source ‘Process KPIs’ (see also BI Content for Process Observer) or aggregate data contained in table POC_D_KPI in a SAP HANA system, for example, by using SAP Operational Process Intelligence.
[Screenshot taken from Bex report on changes in Sales Orders]
Related Use Cases (Exception Tracking)
Instead of just tracking simple field changes, you can combine the tracking with more complex calculations. You may, for example, want to evaluate whether a quantity within an order is within a predefined limit. If it is not, you want to be informed of this.
If this is the case, you define a new task type and the ‘Quantity Exceeds Limits’ task as described above and add it to the process definition. Here it may make sense to have a separate activity for the event that is considered to be the exception:
In the application BAdI, you first check whether the quantity was changed. If so, calculate whether the quantity is still within the limit, if not, add the ‘Quantity Exceeds Limits’ event.
IF <fs_ekpo>-menge > lv_qty_upper_limit
OR <fs_ekpo>- menge < lv_qty_lower_limit
…
" Schedule Line Quantity Exceeds Limits
ls_event-event_type = 'Z001'.
…
APPEND ls_event TO lt_event.
ENDIF.
…
You have seen how easy it is to leverage Process Observer for tracking field changes in your documents or for monitoring related issues such as exceptions.
Stay tuned for more tips and tricks about Process Observer!
- SAP Managed Tags:
