Topic starter
25/06/2026 1:16 am
TL;DR: ABAP RESTful Application Programming Model (RAP) standardises how SAP teams build cloud-ready transactional apps and expose business objects through OData, CDS, and service bindings, while preserving extension paths for S/4HANA and SAP BTP, according to Pathlock. The governance lesson is that application architecture now shapes access scope, service exposure, and lifecycle control as much as code quality does.
Editorial analysis by NHI Mgmt Group, based on content published by Pathlock: “ABAP RESTful Application Programming Model (RAP)”.
Key questions
Q: How should teams govern access in RAP-based SAP applications?
A: Teams should govern RAP access at the service definition and binding layer, not only in the underlying business object.
Q: Why does RAP change IAM and application security planning?
A: RAP changes planning because service exposure is created by development artefacts such as CDS models, behavior definitions, and service bindings.
Q: What risks increase when RAP uses unmanaged behavior?
A: Unmanaged behavior increases the risk that critical transactional logic is dispersed across custom code with fewer framework controls.
Practitioner guidance
- Map business object boundaries Inventory which RAP business objects carry sensitive or high-impact transactions, then align those objects to explicit ownership and access boundaries before exposing them as services.
- Review service definitions before binding Check which CDS projections and behaviours a service definition exposes, because that choice determines the effective service surface for UI and API consumers.
- Differentiate managed and unmanaged flows Treat unmanaged RAP implementations as requiring deeper control review because transactional logic, CRUD handling, and persistence are implemented manually.
Bottom line: RAP shifts SAP governance from code-centric review to model-centric control because the service surface is defined by CDS, behavior, and binding decisions.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 10:34 am
RAP turns application design into an access-governance decision. The important shift is not simply that SAP modernised its programming model. It is that service scope, behavioural authority, and lifecycle exposure are now encoded in the development artefacts that define the application. That means identity and access teams can no longer treat runtime authorization as the only control plane. Practitioners should treat RAP architecture as part of the governance model, not just the build model.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How do business object boundaries affect SAP service governance?
A: Business object boundaries determine how data, behaviour, and relationships are grouped before exposure. If those boundaries are broad or inconsistent, downstream services inherit unnecessary reach, and governance becomes harder because ownership and control are no longer mapped cleanly to the model.
👉 Read our full editorial: RAP changes how SAP apps expose business logic and services