When using multiple process chains, you can face problems with the system executing them at appropriate times. Sometimes the system executes several process chains at once, slowing down the system. Or, process chains that are supposed to happen sequentially fail to execute at proper times, leaving long gaps between chain execution and causing inefficiency.

A process chain mechanism implemented in SAP NetWeaver BI supports a tree model structure with a single scheduler root node (Figure 1). This model does not cover complicated situations like that shown on the left side of Figure 2; in that case, you can decompose it to simple tree models that you can implement, as shown on the right side of Figure 2. I’m going to explain one of the ways to approximate an implementation for a real-life situation by dynamic delay capability.

Figure 1

Process chain model

Figure 2

Simplifying the model

You can develop a process chain component that implements dynamic delay functionality to synchronize the activities of different process chains. I suggest developing the ABAP type process chain block that implements debug loop functionality with dynamic execution time.

I propose two variations of this solution supported by two alternative delay blocks:

• Time-synchronizing delay block in the master process chain (Figure 3)

Figure 3

T-delay solution

• Process chain-synchronizing delay block with independently scheduled process chains (Figure 4)

Figure 4

PC-delay solution

I’m going to take you through a simple example to show you how this works. I’ll show you how to implement each solution, including the code you need, and then I’ll compare the two solutions. Finally, I’ll go over some pitfalls you may encounter. This article applies to BW 3.x and SAP NetWeaver BI versions up to 7.0.

Example Situation

Suppose that you have a data flow model such as the one shown in Figure 5. An InfoCube called IC’s data is based on two DataSources: DS1 and DS2. The system loads DataSource DS-1 into DataStore object (formerly operational data store [ODS]) DSO- 1 and DS-2 into DSO-2, respectively.

Figure 5

Sample data flow model

The system uses the content from DSO-1 for data completion during loading from DS- 2 to DSO-2.

The company also faces these additional conditions (Figure 6):

Figure 6

Sample scheduling requirements

• It had to complete loading activity 1 before starting activity 2
• The DS-1-to-DSO-1 loading is a long-term activity that could take hours for the system to complete
• DS-1 is ready for extraction at 01 (1:00) a.m. while DS- 2 is ready at 06 (6:00) a.m.

You need to supply the actual data (InfoCube IC) as soon as possible so the process chain can begin.

I created sample process chains PC-1 and PC-2 to demonstrate different solutions. Both are the simplest possible chains with immediate scheduling Start blocks with debug loop delay to ensure prolonged execution time. If the DS-1-to-DSO-1 activity (1) is collected in the process chain PC-1 and activities 2 and 3 are collected in PC-2, you can view the situation as follows:

• Process chains PC-1 and PC-2 should be scheduled at t1 and t2 time points, respectively
• PC-2 cannot start until PC-1 is finished

Figure 7 shows a graphical representation of this.

Figure 7

Process chains’ schedule requirements

Standard Solution

Can you implement these requirements with standard process chain mechanism tools? If you schedule both process chains at t1 and t2 independently, you cannot ensure the dependency condition in the case when PC-1 execution time overlaps the t2 time point (Figure 8).

Figure 8

Overlapping process chains execution

To ensure this dependency condition, you need to combine PC-1 and PC-2 into a master process chain (PC-M). The delay capability of this condition (standard delay capability) allows you to shift the PC-2 start time related to when PC-1 finishes. In this case, the PC-2 start time depends on the PC-1 elapsed time. Therefore, you cannot ensure the PC-2 start condition will be when PC-2 needs to start or after PC-1 finishes, as shown in the bottom two bars of Figure 9.

Figure 9

PC scheduling with standard constant delay capability

To solve this problem, you need to use one of the variations of dynamic delay functionality that I mentioned earlier: time-synchronizing delay block or process chain-synchronizing delay block. I’ll go over each of these next.

Time-Synchronizing Delay Block

You use a time-synchronizing delay block (T-delay) for managing process chains executed as part of a master process chain (Figure 10). T-delays ensure the successor process chain’s (PC- 2) start time condition.

Figure 10

Time synchronizing delay block

The T-delay process chain block starts immediately after PC-1 and implements the delay functionality until achieving t2 absolute time.

A T-delay block is zero time length, as you can see in the bottom bar of Figure 10. It finishes immediately because its start time is after t2. As you can see in Figure 10, master process chain PC-M contains PC-1 and PC-2 as components. PC-M starts at t1 and runs PC-1 immediately. After PC-1 finishes, T-delay block starts and executes until t2. After the T-delay block finishes, PC-2 starts.

The T-delay block code to create the sample program ZBI_T_DELAY, which corresponds to the implementation strategy in Figure 10, is available for download by clicking this link.

ZBI_T_DELAY has two parameters:

• Wait until Time (P_STIME) defines the block finishing time point
• Midnight Over (P_MDNGHT) indicates if the delay should continue past midnight

To include the T-delay block in a process chain, you need to perform the following steps:

Step 1. Implement the T-delay ABAP program in your environment. (You need to have a developer’s permission to do this.) Run transaction SE38, fill the Program field with the program name and click on the Create button. In the screen that appears, fill the Type field and click on the Save button, which takes you to ABAP Editor. Insert the T- delay ABAP code for ZBI_T_DELAY, then save and activate the program.

Step 2. Define the ABAP type variant. Click on the buttons next to Synchronous and Local. Then click on the button next to Program and enter the program name (ZBI_T_DELAY, in this case) and Program Variant (T2). Click on the Change button to define the t2 variant.

Step 3. Include it in the process chain. Drag and drop the ABAP type item to your process chain and select the defined variant.

Process Chain-Synchronizing Delay Block

A process chain-synchronizing delay block (PC-delay) is applicable for independently scheduled process chains. This delay block supplies the dependency condition by controlling when the predecessor PC- 1 finishes (Figure 11).

Figure 11

Process chain synchronizing delay block

The PC-delay process chain block starts at t2 and runs while PC-1 executes. The PC synchronizing is based on analyzing the process chain execution status that the system logs in the RSPCLOGCHAIN and RSPCPROCESSLOG tables. Table RSPCLOGCHAIN contains log information for the process chain run. Table RSPCPROCESSLOG contains an execution log for each process item. The information in the STATE and ACTUAL_STATE columns tells you the whole process chain state of each process chain item. You can also use standard function module RSPC_API_CHAIN_GET_STATUS, which simplifies obtaining the process chain status.

Sample program ZBI_PC_DELAY demonstrates the PC-delay block implementation. You can find the ABAP code for this program for download at this link.

The program scans process chain log tables to check if there are active predecessor process chains. If one exists, it performs this check again after a one-minute delay; otherwise it finishes.

The main problem is determining the relevant predecessor process chain. Usually you will find some logs for a specific process chain. In the proposed algorithm I chose the last instance based on the start time.

To get the process chain log population, you should specify the back-time period that is relevant for that case. By default, ZBI_PC_DELAY scans the current day logs.

The ZBI_PC_DELAY program has the following parameters:

• Predecessor Process Chain (S_PC) defines the predecessor process chains technical names
• Back Days (P_BCPDAY) defines the back-time period for predecessor process chains scanning
• Time Limit (P_W_MAX) designates the maximum execution time
• Predecessor process chain status for successful continue:

  - P_OK: Successfully finished
  - P_CANCEL: Error finished
  - P_ANY: Finished with any status

In my example, you would enter PC_1_T1 in the Predecessor Process Chain field, 30 in the Time Limit field, and check the P_OK button.

The PC-delay block ABAP program finishes with an error if it exceeds the time limit. The standard ABAP process chain type does not react to it. I recommend you define a custom process chain type as described in David Eady’s article, “Enable Your Process Chains to React to Outcomes of ABAP Programs." To include the PC-delay block in a process chain, you need to perform the following steps:

Step 1. Implement the PC-delay ABAP program in your environment. This is the same as for the T- delay block.

Step 2. Define the custom process chain item: ABAP program with return code. This is outlined in David Eady’s article, which I mentioned above.

Step 3. Define the ABAP type variant. Click on the buttons next to Synchronous and Local. Then click on the Program button and enter the Program Name (ZBI_PC_DELAY, in this case) and Program Variant (PC_1).

Step 4. Include it in the process chain. This step is the same as for the T-delay block.

Delay Approach Comparisons

It’s important to consider the differences between the two approaches so you can decide which is best for you. I’ll compare the two with reference to screenprints in different parts of the system.

T-delay block. T-delay block is simple and easy to implement. You just need to develop the ABAP program, define the ABAP process chain variant with specific parameters, and include it in your process chain. On the other hand, it is sensitive to PC-M schedule conditions. As described earlier, T-delay block is preferable if you combine two process chains that you want to synchronize in the master process chain (PC- M). If you change the master process chain start time, you should consider T-delay block tuning.

Suppose that the master process chain is scheduled at 12:00 and the T-delay block is customized for 15:00. If you change the main process chain scheduling (16:00, for example), you need to correct the T-delay block definition.

The T-delay approach is available only for daily-based periodic scheduling. This approach is expensive for a long- time delay because it permanently uses a background work process (Figure 12).

Figure 12

T-delay block executions

In Figure 12, the bar graphic demonstrates a long-term T-delay block case. The next two figures on the right show that the T-delay block is executed as a separate job (transaction SM37) and permanently uses a background work process (transaction SM50). The figure on the left demonstrates the T-delay block execution in the process chain’s log view.

Each item in the process chain mechanism is executed as a separate job (Figure 12). Each job requires a separate background work process (BGD) to perform it. Work process (WP) is a system resource for executing ABAP program modules. The number of work processes is limited (see transaction SM50) and determines the number of program modules that you can execute in parallel. If you use a work process for a long time you reduce system resources (Figure 12). To perform the ABAP program you need a free work process (Status Waiting). If there is not one free, the program waits.

PC-delay block. PC-delay block is relatively complicated to implement because of the problem of determining the relevant predecessor process chain, but it is not sensitive to schedule conditions.

This approach is better than the T-delay block for any periodic value. PC-delay block allows synchronization with some process chains (Figure 13).

Figure 13

PC-delay block execution

For example, if your process chain is hourly-based periodic, you could not use a T-delay block. If you need to perform the process after performing some predecessors (if you collect information from various sources, for example) you can ensure it by using the PC-delay block.

The PC-delay approach supplies a satisfactory solution for process chain scheduling disturbance caused by anomalous system starts (e.g., after a weekend system backup). In this case, some process chains start simultaneously and can lock each other (Figure 14). You can use the PC-delay to control the situation.

Figure 14

PC scheduling disturbance caused by irregular system start. The left image shows planned regular scheduling, the middle image shows simultaneous scheduling after an anomalous start, and the right image shows the solution.

Pitfalls

Avoid recursive dependencies that can lead to a deadlock. For example, PC-1 contains the PC- 1-to-PC-2 PC-delay block and PC-2 includes the PC-2-to- PC-1 delay block. Simultaneously running these process chains causes a deadlock.

Anomalous situations exist when a process chain stays in an active status while nothing is executing. This status may continue for hours. Therefore, you should take this situation into consideration by setting the PC-delay execution time limit. An example of this is when you have the “yellow” loading state that continues for hours after the de facto process failed.

Both T-delay and PC-delay blocks require background work processes for their execution (Figures 12 and 13). Be aware of long time delay blocks: The best way to do this is first to choose the optimal approach (T-delay or PC-delay) for your situation, and if you choose PC-delay, then set a time-limit value for the PC-delay blocks.

Michael Shtulaizen

Michael Shtulaizen is the SAP NetWeaver technical manager of Strauss Group Ltd., Israel. He has been working with SAP BW since 2002. He has rich development experience in SAP environments (more than 10 years) that allows him to propose original solutions in SAP NetWeaver BW systems.

You may contact the author at Michael.Shtulaizen@Strauss-Group.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.