Process Observer (POB) Direct Event API for Logging Processes from SAP and Non-SAP Systems
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 with Process 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.
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.
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.
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.
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:
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.
* 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
* check the change type of the purchase order item
WHEN ‘I’. ” purchase order item was created
* compose 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)
ls_event–event_type = ‘901’. ” task type ID (901 = Create item)
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’.
” Callable Business Entity: cat ‘01’ = Transaction
ls_event–cbe_type = sy–tcode. ” tcode
* 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_bo–pre_bo_id = ls_pre_bo_pr–banfn. ” predecessor BO-ID
ls_pre_bo–pre_item_id = ls_pre_bo_pr–bnfpo. ” predecessor item ID
APPEND ls_pre_bo TO ls_event–previous_bo.
CLEAR ls_pre_bo .
APPEND ls_event TO lt_event. ” event table
* raise list of events to Process Observer
IF lt_event IS NOT INITIAL.
CALL FUNCTION ‘POC_RAISE_EVENT’
it_event = lt_event
iv_commit = abap_false.
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!