📚 Architectural Blueprint

SAP Clean Core High-Performance Parallel Processing Guide

A definitive guide to replacing obsolete asynchronous RFCs (aRFC) with cl_abap_parallel, cursor chunking, and worker pool throttling in SAP S/4HANA.

1. The Death of Asynchronous RFC (CALL FUNCTION STARTING NEW TASK)

For over two decades, SAP ABAP developers relied on CALL FUNCTION ... STARTING NEW TASK to achieve concurrency in high-volume processing (such as billing runs, mass payment runs, and EDI dispatching).

In ABAP Cloud (Language Version: ABAP for Cloud Development):

• CALL FUNCTION ... STARTING NEW TASK is strictly prohibited by ATC checks (syntax error in ABAP Cloud).
• RFC destinations pointing to NONE or internal RFC server groups (e.g. parallel_generators) are inaccessible in cloud environments.
• Unchecked background task spawning leads to SAP work process starvation and tenant throttling in BTP ABAP Environment.

2. Modern Concurrency: `cl_abap_parallel`

SAP introduced the Parallel Processing Framework (`cl_abap_parallel`) to provide safe, object-oriented concurrency compliant with Clean Core standards.

Capability	Legacy aRFC	ABAP Cloud (`cl_abap_parallel`)
Clean Core Status	Deprecated / Prohibited	Released (Contract C1)
Payload Serialization	Flat table parameters via RFC buffers	Type-safe deep object serialization
Worker Quota Throttling	Manual SPBT_* function calls	Built-in iv_max_threads parameter
Timeout Handling	Custom polling loop with RECEIVE RESULTS	Built-in iv_timeout_sec with graceful abort
Cloud Safety	Bypasses tenant resource governance	Monitored and throttled by SAP Cloud Kernel

3. The Architecture of a Clean Core Worker Pool

A resilient concurrent architecture consists of three distinct layers:

1. Chunking Layer: Reads database records in small packages using OPEN CURSOR ... PACKAGE SIZE to keep memory below 50 MB on the orchestrator node.
2. Worker Pool Dispatcher: Instantiates task classes implementing if_abap_parallel and executes them across background worker processes up to a defined ceiling (typically 4–8 threads).
3. Result Aggregator: Collects serialized payloads from completed workers, aggregates execution metrics, and logs any chunk failures into the Application Log (cl_bali_log).

4. Golden Rules for Parallel Worker Design

• Partition by Hash or Document Range: Always sort keys and assign contiguous chunks to avoid cross-worker lock overlap.
• Stateless Workers: Worker instances must not rely on global package memory or session static attributes.
• Independent Commit LUWs: Each worker thread manages its own internal database commit or RAP EML transaction independently.