Background Processing in ABAP Made Simple

Using Uncontrolled bgPF to Boost ABAP Performance

In today’s SAP development landscape, performance and responsiveness are critical for a great user experience. Users expect applications to deliver results quickly, even when the backend is doing heavy lifting like complex data processing or background validations.

This is where the Background Processing Framework (bgPF) comes in — a modern tool that enables asynchronous execution of tasks, improving user experience without compromising system integrity.

In this article, we’ll explore bgPF with a focus on the uncontrolled flow — a lightweight and pragmatic approach for non-RAP scenarios.

For complete documentation, refer to the official SAP ABAP documentation:

Background Processing Framework

Why Background Processing?

Imagine a customer places an order in your online shop. As soon as the customer confirms the purchase, the system starts checking product availability across multiple warehouses, calculates delivery options, and triggers invoicing — all in the background. Meanwhile, the customer is instantly redirected to a confirmation page with their order summary and estimated delivery.

Instead of waiting for all background steps to complete, bgPF decouples these operations, ensuring a smooth, fast shopping experience.

What Is the Background Processing Framework?

The bgPF is built on top of bgRFC (Background Remote Function Call). It is the successor to tRFC and qRFC, supporting reliable, asynchronous execution.

Core Features:

Based on inbound processing — same system, different session
Two processing types:
- Transactional (unordered)
- Queued (exact order)
Integrated with ABAP RAP for transactional control
Provides monitoring and recovery tools

Why Use the Uncontrolled Flow?

In cases where RAP isn’t used — for example, in classical applications or standalone service classes — the uncontrolled mode of bgPF offers a straightforward way to run logic in the background.

Advantages:

Quick to implement
Ideal for simple, independent tasks
Still asynchronous and reliable

Trade-offs:

No transactional separation (i.e., no modify/save phases)
Data consistency must be handled manually

Implementation: Uncontrolled Background Process

A common use case for uncontrolled bgPF is writing change history in the background — e.g., logging changes to customer or partner master data without delaying user interaction.

To implement this, define an operation class that implements IF_BGMC_OP_SINGLE_TX_UNCONTR. Your logic resides in the ~execute method.

Operation Class

CLASS zcl_bgpf_history_op DEFINITION
  PUBLIC CREATE PUBLIC.
  INTERFACES if_bgmc_op_single_tx_uncontr.
  METHODS constructor IMPORTING i_history TYPE your_type_table.
  METHODS if_bgmc_op_single_tx_uncontr~execute.
PRIVATE SECTION.
  DATA history TYPE your_type_table.
ENDCLASS.

METHOD constructor.
  history = i_history.
ENDMETHOD.

METHOD if_bgmc_op_single_tx_uncontr~execute.
  LOOP AT history INTO DATA(entry).
    TRY.
      INSERT zbgpf_history FROM @entry.
    CATCH zcx_bgpf_exception INTO DATA(bgpf_exception).
      " handle exception and log
    ENDTRY.
  ENDLOOP.
ENDMETHOD.

CLASS zcl_bgpf_history_op DEFINITION

PUBLIC CREATE PUBLIC.

INTERFACES if_bgmc_op_single_tx_uncontr.

METHODS constructor IMPORTING i_history TYPE your_type_table.

METHODS if_bgmc_op_single_tx_uncontr~execute.

PRIVATE SECTION.

DATA history TYPE your_type_table.

ENDCLASS.

METHOD constructor.

history = i_history.

ENDMETHOD.

METHOD if_bgmc_op_single_tx_uncontr~execute.

LOOP AT history INTO DATA(entry).

TRY.

INSERT zbgpf_history FROM @entry.

CATCH zcx_bgpf_exception INTO DATA(bgpf_exception).

" handle exception and log

ENDTRY.

ENDLOOP.

ENDMETHOD.

The logic is simple and linear — no need for a transactional buffer.

Starting the Background Process

To trigger the background process, you create a dedicated static method in a starter (or scheduler) class. Inside this method, you instantiate your operation class, pass it to the bgPF process factory, and schedule it for execution. This design keeps your application logic clean, modular, and testable, while clearly separating background orchestration from business functionality.

CLASS zcl_bgpf_history_scheduler DEFINITION
  PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    CLASS-METHODS schedule_insert
      IMPORTING i_history TYPE your_type_table.
ENDCLASS.

CLASS zcl_bgpf_history_scheduler IMPLEMENTATION.

  METHOD schedule_insert.
    DATA operation TYPE REF TO if_bgmc_op_single_tx_uncontr.
    DATA factory   TYPE REF TO if_bgmc_process_factory.
    DATA process   TYPE REF TO if_bgmc_process_single_op.

    operation = NEW zcl_bgpf_history_op( i_history ).

    TRY.
        factory = cl_bgmc_process_factory=>get_default( ).
        process = factory->create( ).
        process->set_name( 'Insert Change History' ).
        process->set_operation_tx_uncontrolled( operation ).
        process->save_for_execution( ).

     COMMIT WORK.
      
      CATCH cx_bgmc INTO DATA(bgmc_exception).
        " Log the error (simplified for demo)
        MESSAGE bgmc_exception->get_text( ) TYPE 'E'.        
    ENDTRY.
  ENDMETHOD.
ENDCLASS.

CLASS zcl_bgpf_history_scheduler DEFINITION

PUBLIC FINAL CREATE PUBLIC.

PUBLIC SECTION.

CLASS-METHODS schedule_insert

IMPORTING i_history TYPE your_type_table.

ENDCLASS.

CLASS zcl_bgpf_history_scheduler IMPLEMENTATION.

METHOD schedule_insert.

DATA operation TYPE REF TO if_bgmc_op_single_tx_uncontr.

DATA factory TYPE REF TO if_bgmc_process_factory.

DATA process TYPE REF TO if_bgmc_process_single_op.

operation = NEW zcl_bgpf_history_op( i_history ).

TRY.

factory = cl_bgmc_process_factory=>get_default( ).

process = factory->create( ).

process->set_name( 'Insert Change History' ).

process->set_operation_tx_uncontrolled( operation ).

process->save_for_execution( ).

COMMIT WORK.

CATCH cx_bgmc INTO DATA(bgmc_exception).

" Log the error (simplified for demo)

MESSAGE bgmc_exception->get_text( ) TYPE 'E'.

ENDTRY.

ENDMETHOD.

ENDCLASS.

Without COMMIT WORK, the background process won’t start!

Good to Know

Avoid global variables unless they implement IF_SERIALIZABLE_OBJECT
The constructor is not called again in the async session
COMMIT WORK is required, unless you’re inside a RAP-managed LUW

Monitoring bgPF

Use transaction SBGRFCMON to track background tasks:

Open SBGRFCMON
Go to: Inbound → BGPF → Transactional Units
View running, waiting, or failed processes
Right-click to delete or restart errored entries

Tip: Use ABAP Cross Trace or SAP Application Interface Framework for deeper analysis and debugging.

When to Use Uncontrolled Flow

Use uncontrolled bgPF when:

You’re not inside a RAP-managed LUW
You need fast, decoupled execution
You can manage consistency on your own

Avoid it if:

You require rollback consistency across background and foreground logic
You need to control the execution order of background steps
→ Use queued bgPF instead

Conclusion

The uncontrolled flow in bgPF is a powerful yet simple way to offload tasks into the background — even in traditional ABAP environments.

It avoids the overhead of RAP but still delivers the core benefit: a responsive and scalable user experience. If you’re working on reports, historization, migration logic, or other decoupled updates — this is a great tool to consider.