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:
* 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
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'.
* 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.
[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.
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!