Skip to Content

Hi Process Observer community,

In this blog, I want to introduce the direct event API, which can be used as an alternative to BOR events, for the instrumentation of Business Suite applications to work withProcess Observer.

An overview and a description of Process Observer’s architecture were given in previous posts of this series. And – as described in these posts – Process Observer can process BOR and workflow events that are very common in the SAP Business Suite area when interacting with Business Workflow. More than 7000 BOR events are predefined in the SAP Business Suite. Up to now, you needed to create new BOR events in the Business Object Repository (see the Complete Guide for Events in Workflows in SAP ECC 6.0.) when new BOR events were required for Process Observer observation  and you needed to raise the new BOR events in appropriate application exits.

As an alternative to using BOR events, Process Observer additionally offers the direct event API (see note 1689819). You can use it to raise application events directly in the application exits to Process Observer (without the indirection overdetour via BOR events). In the event API’s interface, you can directly use the “tasks” as used in the process definition (seeCreate Process Definition for Business Process Monitoring & Analytics for Business Suite Processes (POB)). No further mapping of the tasks to BOR events is required.

  

Technically, the direct event API is a function module that can be called directly in an application exit. The function module is mass-enabled – events are passed as tables – and it supports asynchronous processing in the same way as BOR events: The events received as input by the function module are first stored in a buffer table, then with the POB Event Scheduler (transaction POC_JOB_SCHEDULER,
see also Setup of Component Process Observer for Built-In Processes
the events are processed asynchronously. The event scheduler works as follows: First the buffered BOR events are processed by Process Observer, then non-BOR events are processed, finally the threshold is checked.

Note: Due to this processing order,  some unwanted effects may occur during logging (events processed in the wrong order, which
results in lost events), if you mix BOR and non-BOR events in one process and they may occur together within a very short timeframe.

p2p_process definition.png


The normal use case of using the direct event API is to just call it from a SAVE BAdI of the application that you want to track. Process Observer is normally configured to run in each local system in which processes will be tracked.

 

But the direct event API is also remote-enabled (available as RFC), so that it can also be used to log the events and processes of a remote SAP or non-SAP system. To use it from another SAP system (such as SAP System < ERP 6.00 EhP 4), it is called in the same way as a normal RFC, for use in non-SAP systems, the RFC can be wrapped and made available as a web service using NetWeaver standard tools.

/wp-content/uploads/2013/06/sap_nonsap_232388.png

You create the process definition in Process Observer, just as if the process ran in the local system, then the direct event API is called, passing on a list of events. The interface has a parameter for the ID of the remote system. In the local Process Monitor, the system information or the remote process is available. 

/wp-content/uploads/2013/06/log_system_232369.png

Even though the interface is mass-enabled, you must consider performance (the number of events that you create in the remote system) for the communication load, and the fact that the direct event API is currently only available as a synchronous interface (requires system availability). To optimize communication performance, you may, for example, first store the events locally in the remote system and later pass them to the Process Observer system in a single call.

You can also think of scenarios, where only one step of a process modelled in the local is executed in an external system, and you use the direct event API to informa about the execution of the single step.

 

One example, in which the direct event API has been used cross-system, is the monitoring of master data distribution in SAP MDG. (See also Monitoring of cross system workflows with SAP Process Observer). In this scenario, the MDG Hub (>= ERP 6.00 Ehp 6) runs Process Observer. Local events in an MDG client, such as receiving and manipulating of local master data, are transferred remotely as an RFC via the direct event interface.

/wp-content/uploads/2013/06/mdg_process_232389.png

Very essential for the understanding of the direct event API is this example. With a sample process definition, we want to track a procurement process on item level. It looks like this:

  p2p_process definition.png

We create the corresponding event information ’Purchase Order item is created’ in an implementation of the POSTED method of BAdI ME_PURCHDOC_POSTED (which is called when Purchase Orders have been created or changed) using the direct event. In the code given below, we check the creation of an item evaluating the change type (field KZ). We create the event corresponding to the ‘Purchase Order Item Created‘ task by adding the Purchase Order ID and item ID, as well as adding the business object type for Purchase Order and the task type for creation of an item. We additionally store the ABAP kernel transaction ID (which may be relevant in cross-system federation scenarios), an event execution time stamp (e.g. current time), user information (e.g. SY-UNAME) and transaction information (e.g. SY-TCODE). Information about predecessor objects (document flow, here: Purchase Requisitions) can be added in a table. Predecessor information is required to connect the activities within the logged process instance. Finally, the event is added to an event list and the event list is raised using the direct event API.

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.

* check the change type of the purchase order item

      CASE <fs_ekpo>kz.
     
WHEN ‘I’.                      ” purchase order item was created
* compose event
       
CLEAR ls_event.
        ls_eventbo_id = im_ekkoebeln.     ” Purchase Order ID
        ls_event
item_id = <fs_ekpo>ebelp. ” item ID

         ls_eventbo_type = ‘001’.           ” BO Type ID (001 = Purchase Order)
        ls_event
event_type = ‘901’.     
  ” task type ID (901 = Create item)
        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_event
executed_at = lv_time.              ” Execution Date/time
        ls_event
executed_by = syuname.             ” user

        IF sytcode IS NOT INITIAL.
          ls_event
cbe_category = ’01’.     
       

                             ” Callable Business Entity: cat ‘01’ = Transaction
          ls_event
cbe_type = sytcode.              ” tcode
       
ENDIF.        
*
Predecessor Business Objects (document flow) – loop over schedule line items
        ls_pre_bo
pre_bo_type = ‘108’.               

                    ” predecessor BOType 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.     ” predecessor BO-ID
            ls_pre_bo
pre_item_id = ls_pre_bo_prbnfpo.   ” predecessor item ID


           
APPEND ls_pre_bo TO ls_eventprevious_bo.
           
CLEAR ls_pre_bo .
       
ENDLOOP.

        APPEND ls_event TO lt_event.      ” event table

     WHEN OTHERS.

          …

      ENDCASE.
 
ENDLOOP.
* 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.

We hope this new interface makes the instrumentation of the application much easier, especially if you do not have any experience with using BOR events. This blog post should briefly illustrate how to use it. Here you find further information Tracking Field Changes Using the Process Observer (POB) Direct Event API and  an instrumentation for tracking the procure-to-pay process on item level that was implemented completely using the direct event API.

Watch out for our news!

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