Production Architectural Blueprint

SAP RAP Behavior Augmentation & Pre-Check Guide

Extensibility Domain: On-Stack Developer Extensibility (Tier-1) Standard: BDEF Extension & Augmentation Clean Core Tier: Tier-1 On-Stack

1. The Challenge: Extending Standard SAP Business Objects Cleanly

In legacy ECC systems, developers modified standard logic by inserting code into user exits (USEREXIT_...), implicit enhancements (Enhancement Spots), or modifying SAP include programs. This created severe regression risks during system upgrades.

In SAP S/4HANA Clean Core, modifying standard code is forbidden. For released SAP standard RAP business objects (such as I_SalesOrderTP or I_PurchaseOrderTP_2), SAP provides Behavior Extensions powered by two distinct capabilities:

• RAP Augmentation (augment): Allows customer extensions to inject additional data or child entities into a standard operation before the standard behavior logic executes.
• RAP Pre-Check (precheck): Allows customer extensions to evaluate custom business rules and reject invalid requests early, before standard determinations, validations, or enqueue locks take place.

2. Augment vs Pre-Check vs Validation: Execution Lifecycle

Execution Phase	Hook Type	Triggered In	Primary Architectural Purpose
Phase 1: Early Filter	precheck	Extension Behavior Handler	Validate custom business invariants without locking resources
Phase 2: Data Injection	augment	Extension Behavior Handler	Append custom child records, default values, or sustainability tags
Phase 3: Core Execution	Standard create / update	SAP Standard Managed BO	Standard validation, determination, and pricing engine execution
Phase 4: Late Validation	validation	Extension Behavior Handler	Cross-field validations during draft prepare / save

3. The Architecture of augment

When an end user creates a Sales Order via SAP Fiori, the augment method intercepts the incoming payload. The extension can dynamically create dependent custom extension entities using MODIFY AUGMENTING ENTITIES:

CLASS lhc_salesorder IMPLEMENTATION.

  METHOD augment_create.
    DATA lt_children TYPE TABLE FOR CREATE I_SalesOrderTP\_CarbonScore.

    LOOP AT entities ASSIGNING FIELD-SYMBOL(<entity>).
      APPEND VALUE #(
        %cid_ref = <entity>-%cid
        %target  = VALUE #( (
          %cid           = |EXT_{ <entity>-%cid }|
          CarbonScorePPM = 120
        ) )
      ) TO lt_children.
    ENDLOOP.

    MODIFY AUGMENTING ENTITIES OF I_SalesOrderTP
      ENTITY SalesOrder
      CREATE BY \_CarbonScore FROM lt_children.
  ENDMETHOD.

ENDCLASS.

4. Implementing precheck for High Performance

METHOD precheck_create.
  LOOP AT entities ASSIGNING FIELD-SYMBOL(<entity>).
    IF <entity>-NetAmount > 50000.
      APPEND VALUE #( %cid = <entity>-%cid ) TO failed-salesorder.
      APPEND VALUE #(
        %cid = <entity>-%cid
        %msg = new_message_with_text(
          severity = if_abap_behv_message=>severity-error
          text     = 'Order value exceeds maximum threshold (Clean Core Governance)'
        )
      ) TO reported-salesorder.
    ENDIF.
  ENDLOOP.
ENDMETHOD.

5. Critical Anti-Patterns to Avoid

• Anti-Pattern 1: Side Effects inside Pre-Check: Never modify database tables or external APIs inside precheck. It must be a pure, read-only decision gate.
• Anti-Pattern 2: Missing %cid_ref Mappings: In augment, failing to link child entities to the root using %cid_ref causes RAP to lose correlation, resulting in unassigned orphan records.
• Anti-Pattern 3: Bypassing Released C1 Interfaces: Only extend business objects explicitly released under contract C1 (Use in Cloud Development). Extending unreleased internal standard BDEFs creates upgrade breaks.