Data Load Automation: Moving away from Event Collectors, to use Process Chains.

[Former Member]

Introduction

An event collector enables us to wait for several events that have been successfully completed, independent of each other in a given time frame and as a response to the successful completion of events allows us to raise a new event.

This functionality is extensively used for automating the data loads in BW, especially in cases where there are several dependencies that have to be taken into consideration before we carry out loading an object. Until BW 3.5 Event collectors were being used to provide an efficient way to in automated data loads, where other load dependencies would have to be considered.

From BI 7.0 onwards SAP has not provided this option from the Admin Workbench, however we could still use event collectors from RSA1OLD -> Tools -> Event Collector. But as SAP suggests us to move on from using Event Collectors to start using Process Chains, this article discusses an example of how a Process Chains can be used to replace Event Collectors. In this article we make use of the new Process Type called Interrupt Process. A brief description about Interrupt Process is provided below.

Interrupt Process Type

Interrupt is a process type which is used in the process chains for interrupting the processing of a process chain up to the point till a condition is met.

This process type can be useful in cases where more than one start condition is to be filled. Using this process type enables us to specify the additional conditions which are to be met before the execution of the process chain is completed.

The Process chain execution starts when the start condition of the start process is met. However, the interrupt process will interrupt the processing of the chain up until the point till the condition of the interrupt process is met. In case the start process condition be met again before the interrupt process condition is met, the chain will start again and would only run up until the point of interruption. As soon as the interrupt process condition is met, the system continues the latest run of the chain, any other earlier runs remain unchanged. In case the interrupt processes are condition is met even before the start process condition is met, in such situation the chain starts as soon as the start condition is met and the interrupt process no longer interrupts the process chain execution as the interrupt condition has already met.

The interrupt process schedules an additional background job that starts based on the relevant condition. Therefore the interrupt process is not really active during the interrupt phase; it does not use any resources during this time.

Interrupt Process can be found in the General Services section as shown below.

Scenario

We consider the below scenario for the purpose of our Article. The ABAP report has to be executed between 6AM to 9AM every day. But before it can be ran, the run has to wait until the load to three DSOs is completed, as in the ABAP report we use the three DSOs for doing lookup. This kind of situations are quite common in most of the BW implementations, where in the instead of ABAP report, there could be a situation where some other Process Chain or job has to be started.

When the loading of data to DSO 1 is completed, it would raise an event called DEMO_EVT_1. Similarly for DSO 2, event is DEMO_EVT_2 and DEMO_EVT_3 for DSO 3.

Approach 1: Using Event Collectors

In order to achieve the dependencies as per the above scenario, firstly, we would need to create an Event Collector that would have reaction times between 6 AM to 9AM and then add all the three events  (DEMO_EVT_1, DEMO_EVT_2 and DEMO_EVT_3) to this event collector. As a Subsequent Process, we can give a new event, DEMO_EVT_START as an event following the successful processing as shown below.

Once the Event Collector is created and scheduled, it would wait for three events DEMO_EVT_1, DEMO_EVT_2 and DEMO_EVT_3, within the time frame of 6AM to 9AM, to raise the event DEMO_EVT_START. If any of the above conditions is not met, such as any one or more of the events, for which the event chain looks for, is not triggered or the time frame when all the three events triggered is not in between 6AM to 9AM, the subsequent success event DEMO_EVT_START would not be triggered.

In order to automate the execution of the ABAP report upon the successful triggering of the events within the time frame, we can create a Process chain as show below. The start variant of the Process Chain waits for the success event of the Event Collector, DEMO_EVT_START and then runs the ABAP program.

Approach 2: Without using the Event Collectors

In order to move away from Event Collectors and still achieve the necessary dependencies before the ABAP program is run, we could make use of the new Process Type called as Interrupt Process, which has been provided in BI 7.x onwards.

In order to meet the necessary dependencies of the scenario in discussion, a process chain has been created as below.

In the process chain the Start Process is made to be active in the time frame of 6AM to 9AM and for each of the Interrupt Process used are made to wait for each of the events from three DSOs as shown below (only the start condition of Demo Interrupt 1 is shown below, for other two DEMO_EVT_2 and DEMO_EVT_3 are used respectively).

Testing both the Approaches

For testing both the approaches, all the three events DEMO_EVT_1, DEMO_EVT_2 and DEMO_EVT_3 have been triggered manually from SM64, in the time frame of 6AM to 9AM.

Test Results of Approach 1

Below screen shows the Event Collector from the Approach 1, where we can see the times when the events have been registered with the Event Collector.

Below is the Process chain run log for the Approach 1.

We can observe from the Process chain log, that the Process Chain ran successfully at 07:22:23, which was right after the time when the DEMO_EVT_1 has registered with Event Collector.

Test Results of Approach 2

Below are the results for the Process chain using the Interrupt Process Type. From the logs it can be seen that the Process chain has started at 07:22:09, though the last event was triggered only at 07:22:23. This is because the start condition of this process chain is based on time, hence the process chains execution started immediately when we scheduled it. However, the execution stops at the Interrupt Process types and waits for the events to continue with execution.

Log of the first process type, Start Process.

Log of the First Interrupt process, it started at 07:22:12. Similarly the other interrupt processes run as per their respective events.

Below is the log of the last process type, the ABAP process type, which completed at 07:22:17

Conclusion

It is necessary to understand the functionality of each of the new Process Types that have been and would be added in future, in order to effectively use them for automating the jobs.

With the above scenario and illustration, we can conclude that we can achieve same functionality that was being provided by Event Collectors, by using the new Interrupt Process type. However, depending on the scenario, we might also need to use the Decision Process types at times. We can conclude that we can move away from Event Collectors and achieve same functionality using the new process types in the Process Chains.