The ABAP RESTful Application Programming Model (RAP) and classic Business Add-Ins (BAdIs) both exist to extend SAP S/4HANA without modifying the SAP standard. They are not competing technologies — they solve different problems. But their overlap is significant enough that choosing the wrong one creates unnecessary complexity, rework, and upgrade risk.
This post maps out precisely when to use each, with practical examples from real S/4HANA extension scenarios — and a decision framework you can apply immediately.
🗺 Decision Framework: RAP or BAdI?
Start with this diagram before reading anything else. It covers 90% of real extension scenarios in a single flow:
⚙ The Core Distinction: Process Hook vs. Object Extension
This is the key mental model that resolves most architectural debates:
BAdI = You want to inject custom logic at a specific point in an SAP process — a posting transaction, a batch job step, a workflow trigger. You do not own the object; you hook into it at a predefined enhancement spot.
RAP = You want to add or modify the behavior of an SAP business object exposed as an OData service — adding fields, changing validation, triggering side effects on save, or building an entirely new transactional BO.
Both can overlap: a RAP-based business object often calls BAdIs internally, and RAP extensions can trigger BAdI-implemented side effects. But from a developer perspective, the entry point differs fundamentally.
🏗 RAP Technical Architecture
Understanding RAP’s four-layer architecture helps clarify what it actually builds — and why it differs from a classic BAdI implementation:
✅ When to Use Classic BAdI
🔵 Scenario 1: Standard SAP Posting Process
You need to auto-populate a custom cost assignment during Goods Receipt posting (MIGO). The process runs through MM posting — not a RAP BO. Use the released BAdI MB_DOCUMENT_BADI via an Enhancement Spot. RAP is not the right tool here.
🔵 Scenario 2: Non-RAP Standard Transaction
Block a vendor payment if a custom approval flag is not set. The payment run (F110) is not a RAP BO. A BAdI hook is your only Clean Core option. Wrapping the entire payment object in RAP would be architectural over-reach.
🔵 Scenario 3: Filter-Dependent Logic
Country-specific or plant-specific logic that should only fire for company code 1000. BAdIs support filter values — your implementation fires only for matching context. RAP has no native equivalent to BAdI filter semantics.
🔵 Scenario 4: Batch Job Side Effects
Add custom validation or enrichment to a background job (MRP, depreciation run, billing). These processes use the ABAP call stack, not OData. BAdI hooks are the correct integration point — RAP has no role here.
🚀 When to Use RAP
⚙ Scenario 1: Custom Fields in a RAP-Based Fiori App
Add a custom approval status to the Sales Order Fiori app. S/4HANA 2022+ exposes Sales Order as a RAP BO — use a RAP BO extension: EXTEND VIEW ENTITY, extend the behavior definition, implement the extension behavior class. The field appears in Fiori UI without BAPIs.
⚙ Scenario 2: New Custom Business Object
Build a custom approval workflow tracker, service request system, or asset register. RAP Managed BO gives you OData v4, draft handling, optimistic locking, Fiori Elements compatibility, and event publishing. No reason to use classic BAPIs or function modules for new BOs in 2024+.
⚙ Scenario 3: OData API for BTP or Fiori
Expose custom ABAP logic as a consumable API for BTP CAP services, SAPUI5 apps, or third-party integrations. RAP is the only Clean Core way to build OData v4 services in ABAP Cloud. BAdIs have no OData exposure capability.
⚙ Scenario 4: Extend Existing RAP Business Object
SAP delivers core S/4HANA objects (Purchase Order, Service Order, Business Partner) as RAP BOs with published extension points. Use RAP BO Extension (EXTEND BEHAVIOR) to add validations, determinations, and actions — without touching SAP standard code.
📊 Quick Reference: Decision Table
| Requirement | Use BAdI | Use RAP |
|---|---|---|
| Hook into standard SAP posting process (GR, FI, MM) | ✅ Yes | ✗ No |
| Add custom field to existing SAP BO in Fiori app | ✗ No | ✅ Yes (if BO is RAP-based) |
| Build a new business object from scratch | ✗ No | ✅ Yes — Managed BO |
| Expose ABAP logic as OData v4 API | ✗ No | ✅ Yes — only option |
| Country/plant-specific logic fork | ✅ Yes — filter-dependent | Possible but complex |
| Add validation to a standard transaction (non-RAP) | ✅ Yes | Only if transaction is RAP-based |
| Batch job side effects | ✅ Yes | ✗ No |
| Draft handling + optimistic locking | ✗ No | ✅ Yes — built-in |
| Fiori Elements UI auto-generation | ✗ No | ✅ Yes — from CDS annotations |
| BTP Event Mesh integration | ✗ No | ✅ Yes — RAP publishes business events |
⚡ The Combined Pattern: BAdI + RAP Together
The most sophisticated clean core extensions use both frameworks deliberately:
Example: Custom Approval Workflow with S/4HANA Integration
A RAP Managed BO manages the custom approval entity (create, update, submit for approval, with full draft handling and OData v4 exposure). When the RAP action Submit fires, it calls a released BAdI that fires in the FI payment posting flow — keeping object management clean in RAP and process integration clean in BAdI.
RAP owns the object model · BAdI owns the process integration · Both are ABAP Cloud compliant
🛡 The Upgrade Safety Rule
Both modern BAdIs (Enhancement Framework) and RAP are upgrade-safe when you use released APIs. The risk points are:
⚠ Upgrade Risk Patterns — These Will Break
• Using unreleased BAdI definitions (internal SAP BAdIs not published for customer use)
• Accessing internal RAP infrastructure classes directly instead of the published facade
• Implementing BAdIs that SAP later redesigns or removes in a major release
• Direct table access (SELECT from EKKO, VBAK, etc.) instead of Released CDS views
ATC clean core checks (ABAP Test Cockpit) will flag most of these at development time — run ATC before every transport.
• SAP Help Portal: ABAP RESTful Application Programming Model (ABAP Cloud)
• SAP Help Portal: ABAP Cloud Development Model Overview
• SAP Help Portal: Clean Core Extensibility — S/4HANA Cloud
Working on an S/4HANA extension and unsure which framework fits your requirement? We run focused ABAP architecture sessions — typically a two-hour session with clear output on which pattern to use, and a prototype to validate the approach.