Notifications
Clear all
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.
NHIMG editorial — based on content published by Pathlock: What is RESTful Application Programming (RAP)?
Questions worth separating out
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: What breaks when RAP extensions are allowed without review?
A: Unreviewed RAP extensions can expand the application contract beyond the original control scope, which makes least privilege harder to prove and audit.
Q: How do managed and unmanaged RAP services differ for security governance?
A: Managed RAP relies more on framework defaults for transactional integrity and validations, while unmanaged RAP shifts those responsibilities into custom ABAP code.
Practitioner guidance
- Review service definitions as access boundaries Map each exposed CDS entity to the minimum business action it needs to support, then verify that service bindings do not expose unused read or write paths.
- Separate governance for managed and unmanaged objects Apply a stricter design review to unmanaged RAP objects because the framework no longer enforces transactional behavior by default.
- Control extension points with lifecycle review Track in-app and side-by-side extensions as part of change management so they do not quietly widen the application contract.
What's in the full article
Pathlock's full article covers the implementation detail this post intentionally leaves for the source:
- Step-by-step RAP development flow from database tables through behavior definition, service definition, and service binding
- Managed versus unmanaged implementation choices and the practical trade-offs between framework defaults and custom ABAP control
- Examples of RAP business object, query, business service, and business event design in SAP environments
- Naming conventions and tool usage inside ABAP Development Tools for building and testing RAP services
👉 Read Pathlock's overview of SAP RAP and cloud-ready application design →
RAP for SAP applications: what changes for developers and IAM teams?
Explore further
25/06/2026 10:34 am
RAP is a governance model as much as it is a programming model. SAP's separation of data modeling, behavior definition, and service exposure means the application contract now defines the real control boundary. That is relevant to IAM and application governance because what is not exposed in the service layer is often as important as what exists in the underlying business object. Practitioners should treat RAP design decisions as part of identity and access architecture, not just software engineering.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 23.5% of security professionals are unsure about the biggest threat to their non-human identities, indicating a significant awareness gap.
A question worth separating out:
Q: Why do RAP service bindings matter for audit and compliance?
A: Service bindings define how a RAP service is exposed, including the protocol and consumer type, so they directly shape the evidence trail for access and change control. Auditors and identity teams should treat them as part of the system boundary, not as a deployment detail.
👉 Read our full editorial: RAP changes how SAP apps expose business logic and services
