Process Observer: Working with Tasks Made Easy

[bernd_schmitt]

Hi community,

In this new blog, I want to focus on the definition and the use of tasks in Process Observer and on how specific tools can make your life easier.

Task Definition

Let me start with the meta-model:



Tasks are representatives of activities performed by users on business objects in the back-end application. The information about the execution of BO activities is published via events by the back-end application. In the process definition, tasks are assigned to process activities (= Activity Binding). While process activities are defined only in the context of a process definition, tasks are independent, reusable entities.

Before tasks can be used they are defined as a combination of a Business Object Type and a Task Type in the process façade (transaction POC_FACADE ‘Maintain Objects in Façade Layer’).



You can define header level tasks and item level tasks. Please select the checkbox accordingly. By adding customer-defined Business Object Types and Task Types (with key Z…) you can also create new custom tasks.

In the case of direct [non-BOR] events being raised by the back-end application (see blog Process Observer (POB) Direct Event API for Logging Processes from SAP and Non-SAP Systems ) no further mapping is required between a direct event and a task. It is assumed that the direct event contains information about the predecessor BO that is then used for the binding of the process instance.

If you are using BOR events in your application, you need to provide additional mapping between the BOR event and a task defined in the process façade as defined above. In order to do this, you can :

1) Maintain the mapping in the Customizing transaction ‘Maintain BOR Instrumentation’



or 2) Implement the BAdI ‘Mapping of BOR Events to Tasks’.



For BOR events you may also need to consider adding information about the predecessor BO to the event (only the object itself is considered a predecessor and does not need to be added). You have the following options for defining the predecessor. The options are executed in the given order.

1) Implement BAdI ‘Previous BO Determination’



2) Customizing: Map Previous Objects from Business Object Repository Payload



3) (Do nothing but) use the built-in functionality of the Document Relationship Browser (DRB) function module (find additional information about the DRB  here )

While options 1) and 2) are recommended for productive environments, you may use option 3) for rapid prototyping, but you must be aware of potential performance issues that using the DRB module during runtime can cause.

After the tasks are received by Process Observer, you can further manipulate them before process definition mapping is performed. The following BAdIs are available:

• Enrichment of Task Event Data (only for BOR events)


• Enhance/Split Tasks (all events)

Note: Up to now BOR Events and direct Events have been processed in separate jobs, one after the other, which may have some side-effects (see blog article Process Observer (POB) - working with BOR events made easy). When working with direct events for Process Observer and finding duplicate events in the log, please check that the same event is not also provided as a BOR event by the system as the default. If necessary, deactivate the BOR event by removing the mapping from BOR to task in transaction POC_BOR. You may also check the transaction_ID linked to the events (see blog article … direct event…), as the system normally filters out the duplicate events by comparing the transaction_IDs.

Now, with note 2030279, we have a report for unified processing of BOR events and direct events available. Events of all types are now processed together, and in the order in which the events  occur. In order to use unified event processing, you need so top the currently scheduled event processing report with SM37, the reschedule the event processing (transaction POC_JOB_SCHEDULER), and select the ‘Unified BOR-/non_BOR Event Processing’ checkbox.



If you want to execute the new report manually, execute report POCR_PROCESS_EVENTQUEUE_UNI in transaction SE38.

Task Binding

In order to enable Process Observer to create process logs, tasks are assigned to process activities in Customizing transaction POC_MODEL (‘Create and Maintain Process Definition’). You may assign multiple tasks to the same process activity. The activity is logged when one of the assigned tasks is observed by POB.

You can modify the way tasks are assigned to a process activity:

1) In a BAdI or a BRFplus rule, you can further evaluate a detected task-activity assignment at runtime and discard the assignment (compare with the meta-model given above).



Using this concept, you may use the same task (for example ‘Create Object’) to bind the BO activity to different process definitions (variants of a process). Depending on an attribute, such as the object type, you may bind it to the one or the other process definitions when you check this in the relevant starting steps of the processes.

Use BAdI ‘Rule-Based Binding of Task to a Process Activity’ as an alternative to creating a BRFplus rule.



Note: Another approach to solve this use case is to use different tasks in the instrumentation of the application. In some cases this may be more efficient as it may avoid overhead processing, or the generation of orphaned tasks (see below).

2) You may also flag tasks assigned to activities as additional tasks. This means that the tasks are only considered as additional information. Logging of the activity only takes place if at least one non-additional (or main) task occurs. Additional tasks are logged and assigned in this context, but if only the additional task occurs, no activity is logged.

Also in finding the predecessor instance, additional tasks behave differently: they are not included in finding predecessors. (Note: If you really rely on this behavior, please apply note 1994183).

You may use this feature in order to store additional information in the context of the activity, where the BO-ID in the additional task does not need to be specific for the process, but you can still use it in the extended search of the process monitor.

As an example you may have a change ID that represents the change of a material. You use the change object and ID in the main task. In an additional task, you could add the task executed with the material ID (not specific to the tracked process). In the monitor search you can find all change processes for a
given material ID.

Orphaned Tasks

Tasks not bound to logged process instances at runtime are called orphaned tasks.Together with bound tasks they are stored in table POC_D_BA_LOG. Orphaned tasks may occur due to:

• Activation of logging on BO type level (all tasks in the context of a certain BO type are logged)


• Extended logging of a process (not only tasks assigned to the active process definition are logged, but also all other tasks related to BO types referenced in the process definition. You normally use this setting only in testing environments.)


• Discarding of process binding in the binding BAdI or BRFplus rule (see above)


• Errors in the process definition or application instrumentation (for example, the predecessor BO is missing and so the binding of the task to a process instance does not take place.

So orphaned tasks may be of interest to you for detecting errors of process definition and instrumentation, especially at design time.

Task Monitor and Additional Tools

There are different transactions that you can use to review the logged tasks without entering via the process monitor. This is especially helpful in the implementation and testing time of your process definition and instrumentation to check whether events or tasks have successfully reached Process Observer, and whether they are bound to a process.

• POC_TASK_ORPHAN: Lists orphaned task


• POC_TASK: Lists all tasks with their assignments to processes and activities

While there is no general Process Observer setting to prevent the logging of orphaned tasks, we have provided a sample BAdI implementation that filters out orphaned tasks before writing the process logs to the DBs. To use this feature, please implement note 2018078.

The corrections from the notes mentioned in this document are also available with these SPs:

• SP 13 for SAP Business Suite Foundation 7.31


• SP 08 for SAP Business Suite Foundation 7.46