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

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.

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:

1. Open SBGRFCMON
   
2. Go to: Inbound → BGPF → Transactional Units
   
3. View running, waiting, or failed processes
   
4. 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.

In ABAP, the FILTER operator provides a powerful way to reduce internal tables based on a filter table. This enables an elegant and high-performance data filtering approach without explicit loops.

Basic Syntax

This syntax allows filtering an internal table (itab) based on conditions and values from a filter table (ftab).

For complete documentation, refer to the official SAP ABAP documentation: ABAP FILTER Operator – Filtertabelle

How the FILTER Operator Works

🔹 The internal table itab is filtered based on the values of a filter table ftab.
🔹 A comparison is made between the columns of itab and the key columns of ftab.
🔹 The result depends on the use of EXCEPT:

• Without EXCEPT → Only rows from itab that have matching values in ftab are retained.
• With EXCEPT → Only rows from itab that do not have matching values in ftab are retained.

Optimizing Performance with USING KEY

The USING KEY clause allows specifying an explicit key for either itab or ftab to optimize the lookup process. The key can be a sorted key or a hash key:

✅ Using a key for ftab → ftab must have a sorted key or hash key, which is used to efficiently check for matches. There are no special requirements for itab.
✅ Using a key for itab → itab must have a sorted key or hash key, which is used to improve lookup performance. There are no requirements for ftab.
✅ Without USING KEY → ftab must be a sorted table or a hash table, and the primary key is used implicitly. There are no requirements for itab.

🔹 The choice of which table to specify a key for depends on your optimization goals. If the filter table (ftab) is large and frequently accessed, defining a key for ftab can significantly improve performance. On the other hand, if the main table (itab) is large, defining a key for itab will optimize the filtering process. By specifying a key for the table that benefits most from indexing, you can ensure faster lookups and better performance.

Example 1 – Filtering a Table with a Sorted Key on the Filter Table

In this example, we filter a list of customers (customers) using a filter table (filter). Since filter is a standard table without a primary key, we need to use USING KEY:

Explanation:

1. Loading customer data into customers from the database table scustom.
2. Defining a filter table (filter) that contains a list of allowed customer IDs.
3. Using FILTER with USING KEY to compare the id field of customers with table_line from filter.

Example 2 – Filtering with a Sorted Key on the Main Table (customers)

Here, we define a sorted key on the main table (customers) instead of the filter table:

Explanation:

1. customers is now a sorted table with a unique key (id), improving lookup efficiency.
2. The filter table (filter) has no key defined, so we use USING KEY primary_key for customers.
3. Using a sorted key allows ABAP to efficiently filter data by leveraging optimized lookups.

Example 3 – Filtering Table Fields with EXCEPT

A common use case for the FILTER operator is to dynamically exclude specific fields from a component list based on configurable criteria. This example demonstrates how to achieve that using a custom filter table and the EXCEPT option.

Explanation

1. Retrieving Fields to Be Excluded
   
   • We select field names from the custom table zexclude_fields, where the field is marked as active (active = abap_true).
   • This table can be maintained dynamically, meaning users or administrators can modify the fields to be excluded without changing the code.
2. Extracting Components from BUT000
   
   • The BUT000 structure contains multiple fields (components).
   • We use cl_abap_typedescr=>describe_by_name to retrieve the list of components dynamically.
3. Applying the Filter Using EXCEPT
   
   • The FILTER … EXCEPT operation removes all components whose name matches any entry in the filter table.
   • Since filter is a sorted table with a unique key, lookups are optimized for performance.

---

Conclusion

By leveraging the FILTER operator with a filter table, you can significantly improve performance in ABAP. Always evaluate where to use USING KEY based on the size of the tables involved, and make use of the EXCEPT clause when excluding records. Try implementing these techniques in your own projects to experience the performance benefits firsthand.