With ABAP programming, every report program executed in the background takes up one background work process for its execution, and each one has a sequential execution plan. For example, every statement waits for the completion of the previous one, and therefore the total execution time is the sum of the individual execution times.

We will show you how to find places in the code where you can distribute the load to different background work processes, which will allow you to decrease the processing time by the number of processes to which you can distribute them.

Implementation Approach

Before you implement background parallel processing, you must make sure that your application and your SAP CRM system meet certain requirements.

First, ensure that your system has logically independent units of work. The data processing task that will be carried out in parallel must be logically independent of other instances of the task. That is, the task can occur without reference to other records from the same data set that are also being processed in parallel, and the task is not dependent upon the results of others in parallel operations.

For example, parallel processing is not suitable for a scenario in which there is a mandate for data to be sequentially processed or in which the processing of one data item in a task is dependent upon the processing of another item of data executed in a parallel task. By definition, there is no guarantee that data will be processed in a particular order in parallel processing, or that a particular result will be available at a given point in processing.

Next, make sure that your system meets the appropriate ABAP requirements. Identify the queries that consume the most time in the report or program, and create a separate child program that will contain this set of queries. Multiple instances of this child program will be created and submitted to parallel background jobs by the main program. Both the main program and the child program (which will be executed in parallel) should be created as “executable” program types.

Finally, to process tasks from parallel background jobs, a server in your SAP system must have at least three background work processes. It must also meet the workload criteria of the parallel processing system. The dispatcher queue must be less than 10 percent full, and at least one background work process must be free to process tasks from the parallel job.

Implementing a Sample Program

We have created two programs for demonstrating this approach: The main program YHR_MAIN_PROGRAM, which consolidates the data, and the child program YHR_CHILD_PROGRAM, which queries the data based on the variant passed. You can find the code for the main program in the Download at the end of this article. Figure 1 contains the code snippet for the child program. (Click here for a downloadable version of this code: child program code download.)

Figure 1

The code for the child program

The main program is built so that you have the option of a sequential approach as well as a parallel approach. (This is helpful for comparing the results for these approaches.) For the parallel approach, create three subroutines, each of which will submit a job, and then create a fourth that will consolidate the results. The three subroutines submit the query as a job and do not wait for the results.

Next, use function module JOB_OPEN to create a background job for an instance of the child program with a unique number and name. Each background job will be executed in an independent background work process. Function module JOB_SUBMIT sets the variant for a background job run based on the parameters passed. Function module JOB_CLOSE completes the procedure of job creation. In JOB_CLOSE, mark the parameter STRTIMMED as X so that the background job starts immediately.

Multiple instances of the child program, each with a different set of variant values, are executed in parallel through background jobs. Each instance of the child program fetches and manipulates data and produces output. You might be wondering where to store this data so that the main program can get it back—here, knowledge of cluster tables comes in handy. You can use the cluster table indx to store the intermediate data using a simple EXPORT TO DATABASE command to a particular cluster. The syntax for exporting data to cluster is:

EXPORT var_name TO DATABASE indx(st) ID key.

Here, var_name is the variable whose value will be exported to cluster table indx, and key is the unique identifier for records in this table.

The subroutine F_CONSOLIDATE in the main program checks for all the submitted jobs and their completion status by querying table TBTCO. Once all submitted jobs are completed, the data is imported from the indx table using the cluster key. The import and export of data takes a negligible amount of time. The syntax for reading the data from cluster table is:

IMPORT var_name FROM DATABASE indx(st) ID key.

The data location in the indx table is cleared after the import so that you can use the same index again.

The Results

After executing the sample program, you should see the following results in your comparison of parallel and sequential execution methods. First, the execution times should be recorded using the GET TIME STAMP FIELD statement. Second, with parallel processing, a total of 242,011 records are queried from table BSEG in approximately ten seconds (Figure 2).

Figure 2

Parallel processing results

Finally, you’ll also see that with sequential processing, a total of 242,011 records are queried from BSEG table in approximately 22 seconds (Figure 3). Therefore, with parallel processing, the time necessary is cut almost in half and there is a 100 percent improvement in speed.

Figure 3

Sequential processing results

With the advantages of parallel processing in the background come some drawbacks that you should be aware of:

1. This kind of processing can take up more resources compared to sequential processing and make them unavailable for other programs.
2. If background processes are unavailable, then this approach can take an unusually long time.
3. You need to have a load strategy in order to optimize the query times across processes.

All that said, the background approach can be extremely useful if you have powerful production machines with multiple application servers that have many unutilized processes.

Click here for a downloadable version of the main code: main program code download.