It’s a common scenario: You want to load or process huge volumes of data in SAP CRM or need to improve the performance of a program that is taking hours to run. These situations often occur during initial project setup when data migration from a legacy system to SAP CRM occurs or when increasing volumes of data in SAP CRM cause a program to run for hours when it initially took minutes. This is where parallel processing techniques come in handy for improving system performance. There are two types of parallel processing techniques you can apply:

• Foreground work process distribution
• Background work process distribution

In this article, we cover the foreground work process. In ABAP parlance, every report program takes up one dialog work process for its execution and 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 taken by each ABAP statement. If you can find places in the code (i.e., the group of ABAP statements) and create multiple instances of this group, assigning each to dialog work processes running in parallel, then you can reduce processing time by a factor of the number of dialog work processes running in parallel. There are some limitations to this approach that we also cover.

Figure 1 shows the flow of a program during sequential processing, while Figure 2 shows how the program flow is structured when you convert it to parallel processing.

Figure 1

Reports following sequential processing

Figure 2

Parallel processing

Prerequisites

Before you implement parallel processing, you need to make sure that your application (i.e., the report or program that you are planning to execute through parallel processing) and your SAP CRM system meet certain requirements.

First, ensure there are logically independent units of work. The data processing task to be carried out in parallel must be logically independent of other instances of the task. That is, the task can be carried out without reference to other records from the same data set that are also being processed in parallel, and the task depends on the results of parallel operations. For example, parallel processing is not suitable for a scenario in which there is a mandate for sequentially processed data or in which the processing of one data item in a task depends on the processing of another data item’s execution 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.

There are also several ABAP requirements:

• The function module that you call must be marked as externally callable. This attribute is specified in the Remote Function Call (RFC)-supported field in the function module definition (found via transaction code SE37).
• The called function module should not include a function call to the destination BACK.
• The calling program should not change to a new internal session after making an asynchronous RFC call. That is, you should not use SUBMIT or CALL TRANSACTION in such a report after using CALL FUNCTION STARTING NEW TASK.  
• You cannot use the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword to start external programs.

In addition, to process tasks from parallel jobs, a server in your SAP system must have at least three dialog 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 dialog work process must be free for processing tasks from the parallel job.

The Foreground Process

To implement the foreground work process distribution technique, you start by performing Basis settings and configuration, and then you must identify the queries that consume the most time in the report or program. It is better if this particular set of queries is independent of the results of previous queries. You move this independent set of queries to the newly created asynchronous RFC, a function module that is called in parallel. You can have a variant with a fixed number of parameters, which is exported to an asynchronous RFC built for load distribution. It is critical to have a fixed number of export parameters to this function module for each asynchronous RFC call.

Step-by-Step Guide to the Foreground Process

Step 1. Ask the Basis administrator to create an RFC server group. This server group should contain the maximum allowable work processes that a parallel process generator can use. Transaction code RZ12 allows you to create and edit RFC server groups for parallel execution of RFC-enabled ABAP procedures and functions. Be cautious when you create such a group because the data you enter for group parameters (e.g., the maximum number of logons and maximum number work processes) is system wide and not restricted to your newly created RFC server group. A work process is not RFC-server-group specific; it’s applicable group wide, like all other profile parameters. Transaction code RZ12 takes you to the screen shown in Figure 3, where the Basis administrator can set up the RFC server group for your use in the parallel processing program.

Figure 3

RFC server group maintenance screen

Step 2. The ABAP developer identifies the queries that consume the most time in the report or program. Create an RFC-enabled function module that contains this set of queries and has the appropriate import and export parameters. To make a function module RFC enabled, enter transaction code SE37 and click the Attributes tab on the Function Builder screen (Figure 4). In the Processing Type section, click the Remote-Enabled Module radio button.

Figure 4

Function module attributes screen

Step 3. Create a parallel process generator as a main program. This program makes an asynchronous call to the previously created an RFC-enabled function module. Make the call to the function module using the statement syntax shown in Figure 5.

Figure 5

Syntax for making the call to the function module

In the code syntax in Figure 5, ZXXXXX is the name of the RFC-enabled function module. SUB1 is the subroutine within the main program where the coding is done to receive the output of the function module.

To achieve a balanced distribution of the system load, we used the DESTINATION IN GROUP <RFC_SERVER_GROUP_NAME> addition. This addition executes asynchronous RFC remote function modules in parallel tasks in any application server or in a predefined application server group of SAP CRM.

This addition first determines the amount of resources (i.e., work processes) currently available, either in all servers or in a group of application servers (which are comparable with login servers). The resources available for executing asynchronous calls on each application server depend on the current system load.

After determining the available resources, the asynchronous call is executed in an available application server. If no resources are available at that particular time, the system executes the exception routine RESOURCE_FAILURE (see the exceptions in Figure 5). This exception must be handled by the application program.

The process for determining available resources in an RFC group is as follows: First, the system determines the length of the dispatcher queue for the relevant application server. If it is greater than 10 percent of the overall length, the server makes no resources available. If it is smaller, the system makes available the current number of free dialog processes minus two (as a reserve instance for other purposes, such as logging on to the system or administration programs). Thus, one application server must have at least three dialog processes if RFC parallel processing is taken into account.

The results from the asynchronous RFC function module are received through the statement RECEIVE RESULTS FROM FUNCTION ZXXXXX. As mentioned earlier, this statement will be coded inside a subroutine whose name appears on the Call Function… statement.

Create a Sample Program

Let’s consider a sample program that calculates the area and perimeter of a square. Table 1 shows the inputs and outputs for this sample program.

Table 1

Table depicting the input and output from sample program

Figure 6 shows the flow of the sample program at a high level.

Figure 6

Program flow of control

Next, we’ll show you a sample program developed and tested in a training system. This is a two-step process: creating a report program in transaction code SE38 and then creating an asynchronous RFC in transaction code SE37.

Step 1. Create a program in transaction code SE38 and name it Z_SAMPLE_PARALLEL_PROCESS using the code shown in Figure 7.

Figure 7

Code for program Z_SAMPLE_PARALLEL_PROCESS

Step 2. Create two function modules in transaction code SE37 and name them Z_AREA and Z_PERI (Figure 8). Remember to make these function modules RFC enabled, as explained earlier (refer to Figure 4).

Figure 8

Two function modules in transaction code SE37

Using this parallelization approach will help with your system’s performance. However, with the advantages also come some drawbacks:

1. This approach can take up more dialog work processes and make them unavailable for other programs.
2. You need to have a load strategy to optimize the query times across processes.
3. These steps are more complex for the programmer.

Having said that, this approach can be useful when there are powerful production machines with multiple application servers and a lot of underused dialog work processes.

The available download, Appendix I, contains a few more code syntaxes that you can use during the implementation of parallel processing logic. You can base their use on your specific project requirements.