Community
Technology Blog Posts by SAP
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Read only

ABAP's Parallel Processing Frameworks: Practical Guide to Performance Tuning of Mass Data Processing

marc_steinert
Associate
Associate
‎2025 Sep 29 7:52 AM
10,312

While working on a project to optimize a standard SAP report that struggled with large data volumes, I took a deep dive into performance tuning in ABAP, specifically focusing on parallel processing. This journey led me to a comprehensive analysis of the various methods SAP provides for running processes in parallel.

I discovered that parallel processing in ABAP is achieved using one of two core technologies. The first is the Remote Function Call (RFC), where both asynchronous (aRFC) and background (bgRFC) variants can be used to run tasks in parallel. The second technology is based on  background processes. To make implementation easier, several frameworks have been built on top of these technologies, simplifying the development process.

This blog post is a summary of the theoretical research I conducted for my bachelor's thesis. Its goal is to provide a comprehensive overview of the different technologies and the six key frameworks I identified. Think of it as a practical guide to help you choose the most suitable framework for your needs, with linked resources for anyone who wants to dive deeper into a specific topic.

The Landscape of Parallel Processing in ABAP

As mentioned in the introduction, parallel processing in ABAP is based on two core technologies. To simplify their use, multible frameworks have been developed for easier implementation. The following table provides an overview of these technologies and their corresponding frameworks:

marc_steinert_0-1758550065480.png

Now, let's explore how each of these core technologies enables parallel processing.

Asynchronous Remote Function Call (aRFC)

The Asynchronous Remote Function Call is one of the older and established SAP technology for parallel processing in ABAP. It works by starting a session in a separate dialog work process, which then executes a function module in parallel with the main program. The calling program does not wait for the function to finish and continues its own processing immediately.

By starting multiple aRFCs in a row, you can achieve a significant parallelization effect, as each call runs simultaneously in its own process. This is implemented using the STARTING NEW TASK addition to the standard CALL FUNCTION statement. A example call could look like this:

CALL FUNCTION '<function_module_name>'
STARTING NEW TASK '<task_name>'
DESTINATION IN GROUP <server_group>
PERFORMING <callback_form> ON END OF TASK.

For a more detailed guide on aRFCs, check out these resources:

 

Background Remote Function Call (bgRFC)

The Background Remote Function Call is a newer method for parallelization. While it also uses dialog work processes for execution like the aRFC, its operational logic is quite different.

Instead of executing immediately, a bgRFC call is first saved to a persistent queue in the database. The actual processing is only triggered by an explicit COMMIT WORK statement and is managed by a dedicated scheduler. This approach makes it possible to execute tasks with an "Exactly Once" or even an "Exactly Once in Order" guarantee, which provides a high degree of reliability.

The implementation is nearly identical to that of an aRFC. The key difference is the use of the IN BACKGROUND UNIT statement, which groups one or more function calls into a single, logical unit of work.

CALL FUNCTION '<function_module_name>'
IN BACKGROUND UNIT <unit_object>.

You can find more information about this technology here:

 

Background Processes

Using dedicated Background Processes is another established method for achieving parallelism in SAP Systems, especially suitable for long-running and resource-intensive tasks that can be clearly divided.

Parallelizing with background processes follows the same core principle as with aRFCs: multiple tasks are started to run simultaneously. This can be achieved in two main ways. The first approach is done purely through configuration. Here, an administrator can manually schedule the same ABAP program multiple times, where each parallel job uses a unique variant with a different dataset.

The second approach is to implement this parallelization within a single ABAP program. This is done using a set of function modules that control the job lifecycle:

  • JOB_OPEN creates a new job.
  • JOB_SUBMIT adds the program and its variant as a step.
  • JOB_CLOSE releases the job to the system for execution.

For more details on implementing parallel background jobs, check out these resources:

 

Frameworks for Easier Implementation

While the core technologies provide the fundamental mechanisms for parallel processing, implementing them directly requires handling details like load balancing, package creation and managing parallel tasks. To simplify this process, SAP provides several frameworks that build on these technologies. These frameworks offer a structured, reusable and often easier way to implement robust parallel processing.

To select the most suitable framework, the following decision matrix based on the Qualitative Weight and Summ (QWS) method provides a visual comparison. The darker the green shade, the better a framework fulfills a specific criterion. Please note that this matrix reflects my subjective evaluation for a specific use case. Your assessment will likely differ based on your project's unique requirements.

marc_steinert_1-1758550429007.png

Evaluation Criteria Explained

Here is a brief summary of each criterion used in the matrix:

  • Platform Compatibility: Runs on both SAP ECC and S/4HANA systems.
  • Timeout Robustness: Handles long-running tasks without timing out.
  • Package Creation: Automatically divides data into work packages.
  • Configurable Package Size: Allows the developer to define the size of work packages.
  • Parallel Execution: Automatically starts and manages the execution of parallel tasks.
  • Result Aggregation: Helps collect and consolidate results from parallel tasks.
  • Multi-Server Function: Can distribute tasks across multiple application servers.
  • Processing Server Selection: Allows specifying a server or server group for execution.
  • Load Balancing: Automatically distributes tasks based on system load.
  • System Load Control: Allows setting limits on the maximum system resources used.
  • Implementation Effort: The complexity and time required to implement the framework.
  • Documentation Quality: The availability and quality of supporting documentation.

Now lets have a look at the individual Frameworks.

 

SPTA Framework

The SPTA Framework provides a straightforward, function-module-based approach to simplify parallel processing with aRFCs. Instead of requiring the developer to manage the aRFC calls manually, the framework encapsulates the entire parallelization logic within a single, reusable function module, SPTA_PARA_PROCESS_START_2.

To use the SPTA framework, a developer implements three specific form routines that serve as callbacks, filling them with the custom logic required for the application. The BEFORE_RFC_CALLBACK_FORM is responsible for preparing the data and creating the work packages. The core processing logic, which is to be executed in parallel, is placed within the IN_RFC_CALLBACK_FORM. After all the parallel tasks have been completed, the AFTER_RFC_CALLBACK_FORM is called to consolidate the results and make them available for further processing.

For more information on the SPTA Framework, see these resources:

 

SHDB Framework

The SHDB Framework is a more powerful and modern, object-oriented framework that also simplifies the use of aRFCs. It is structured into four main components that work together to provide a robust parallelization environment: the Package Provider, the Resource Provider, the Parallelizer and the Dispatcher.

The Package Provider is responsible for automatically dividing the total dataset into smaller, processable packages according to configurable rules. The Resource Provider actively monitors the system's memory and process utilization to determine the maximum allowed number of parallel tasks, thereby preventing system overloads. The Parallelizer then calls the application-specific logic for each package in a separate aRFC task, while the Dispatcher coordinates the entire process by requesting packages and resources and launching the asynchronous tasks.

Implementation is done in an object-oriented manner, starting with the factory class CL_SHDB_PFW_FACTORY and using configuration objects from CL_SHDB_PFW_CONFIG to define parameters like the number of parallel processes or package parameters.

While a complete guide for the SHDB Framework is not publicly available at this time, some information can be found on the SAP for Me portal. Relevant resources are available there using the search terms "SHDB Framework" or "SHDB PFW".

 

CL_ABAP_PARALLEL

The CL_ABAP_PARALLEL framework is another object-oriented solution for aRFC-based parallelization. Its name, while not official, comes from its original project folder. It is a lightweight solution centered around a main class and an interface that developers use to structure their parallel logic.

The implementation pattern requires the developer to create a processing class that implements the IF_ABAP_PARALLEL interface. All the custom logic intended to run in parallel is then placed within its DO method. Finally, the entire process is managed by an instance of the main CL_ABAP_PARALLEL class and the parallel execution is triggered by calling the RUN_INST method.

For more information on CL_ABAP_PARALLEL, see these resources:

 

Background Processing Framework (bgPF)

The Background Processing Framework serves as the dedicated framework for the bgRFC technology.

The implementation pattern requires a developer to encapsulate the business logic in a dedicated class that implements a framework interface. For most use cases, IF_BGMC_OP_SINGLE is used to ensure the process follows strict transactional rules for data consistency.

Once this class with the business logic is ready, it is passed to the CL_BGMC_PROCESS_FACTORY. This is a helper class provided by the framework that constructs the main process object for the background task. The task is then registered by calling the save_for_execution() method and the entire process is finally triggered by a COMMIT WORK statement.

For more information on the bgPF, see these resources:

 

Parallel Processing Framework (PPF)

The Parallel Processing Framework, sometimes also referred to as the Framework for Parallel Processing (FPP), is a framework based on background processes used to structure and execute mass-data processing runs in parallel.

Its implementation requires both settings in Customizing and the development of custom ABAP function modules. A developer first defines an application type using transaction BANK_CUS_PPC. This application type links specific processing steps, such as data packaging or execution, to the custom-developed function modules that contain the business logic.

The entire process is then initiated from a report by calling the central function module BANK_MAP_PP_START, which uses the application type's configuration to manage the parallel jobs.

For more information on the PPF, see these resources:

 

Mass Data Framework

The Mass Data Framework is a comprehensive solution for structuring and controlling complex projects that involve large-scale data changes and is often used in migration scenarios.

The implementation requires just like the Parallel Processing Framework a combination of Customizing and development. In Customizing (via transaction SM30), a developer defines the entire project structure. This involves creating a Project Type (FINSV_MPROJ_TYP), which consists of a sequence of Activities (FINSV_MASSF_SET). Each activity is made up of one or more Steps (FINSV_MASSF_STEP), where the custom ABAP logic is assigned.

The developer's main task is to create an application class that contains the business logic for a step. This class must implement the interface IF_FINS_MASS_DATA, which includes three key methods. The GET_PACKAGES method is called to define the work packages. The PREPARE method can be used for any setup tasks before the parallel processing starts. Finally, the PROCESS method contains the core logic that is executed in parallel for each individual package.

As it is an older framework, further resources for the Mass Data Framework are primarily located on internal SAP platforms and are not publicly available.

 

I hope you found this overview informative and that it helps you tackle your own performance tuning challenges.

A special thanks to @ManuS  for the help and guidance!

1 Comment