Skip to Content

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

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).

/wp-content/uploads/2013/07/task_type_fields_254050.png

[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:

/wp-content/uploads/2013/07/task_field_254066.png

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.

/wp-content/uploads/2013/07/process_def_fields_254067.png

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_ekkomemory = ‘X’. “ABAP_TRUE
        “Incomplete Document. Do not proceed
        CONTINUE.
     ENDIF.

 

* compose event
    CLEAR ls_event.
    ls_eventbo_id = im_ekkoebeln.     ” Purchase Order ID
    ls_eventitem_id = <fs_ekpo>ebelp. ” item ID

    ls_eventbo_type = ‘001’.       

              ” BO Type ID (001 = Purchase Order)
    CALL FUNCTION ‘TH_GET_TRANSACTION_ID’       ” Kernel Transaction ID
         IMPORTING
            transaction_id = lv_transaction_id.   

    ls_eventtransaction_id = lv_transaction_id.

    GET TIME STAMP FIELD lv_time.                ” Execution Date/time
    ls_eventexecuted_at = lv_time.              ” Execution Date/time
    ls_eventexecuted_by = syuname.             ” user

    IF sytcode IS NOT INITIAL.
        ls_eventcbe_category = ’01’.   

             ” Callable Business Entity: cat ‘01’ = Transaction
        ls_eventcbe_type = sytcode.              ” tcode
    ENDIF.        

“Predecessor Business Objects (document flow) – loop over schedule line items
    ls_pre_bopre_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_bopre_bo_id = ls_pre_bo_prbanfn.
         ls_pre_bopre_item_id = ls_pre_bo_prbnfpo.                                  

                     APPEND ls_pre_bo TO ls_eventprevious_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_eventevent_type = ‘901’.     

                   ” task type ID (901 = Create item)
       WHEN ‘U’.                     

                   ” purchase order item was updated

          IF im_ekko_oldmemory = ‘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_eventevent_type = ‘912’.               

                                        ” Line Item Quantity Changed
               
APPEND ls_event TO lt_event.
            ENDIF.

                          IF <fs_ekpo>netpr <> ls_ekpo_oldnetpr OR

                             <fs_ekpo>peinh <> ls_ekpo_oldpeinh.
               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.

  /wp-content/uploads/2013/07/process_monitor_fields_254086.png

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.

KPI_def_field.png

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.

/wp-content/uploads/2013/07/threshold_field_254100.png

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.

/wp-content/uploads/2013/07/report_fields_254112.png

[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:

/wp-content/uploads/2013/07/task_exception_254127.png

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_eventevent_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!

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply