RAP changes how SAP apps expose business logic and services

At a glance

What this is: This is an overview of SAP's ABAP RESTful Application Programming Model and its role in building cloud-ready transactional applications with controlled service exposure.

Why it matters: It matters because application design choices in SAP increasingly determine how access, extensibility, and governance are enforced across development and operations programmes.

👉 Read Pathlock's overview of SAP RAP and cloud-ready application design

Context

RAP, or ABAP RESTful Application Programming Model, is SAP's modern application framework for transactional business services built on CDS views, behavior definitions, and OData exposure. For identity and access teams, the important point is not the syntax but the control boundary: RAP determines what business objects are exposed, how actions are constrained, and where extension logic can change the access surface.

The shift from classic ABAP to RAP mirrors a broader governance trend in SAP environments. As organisations move toward cloud-ready and hybrid application delivery, the design of service bindings, extension patterns, and transactional rules becomes part of the identity model, because application structure now shapes who or what can act on data and through which interfaces.

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. The right approach is to expose the minimum CDS entities and operations required, then review projections, extensions, and consumer bindings whenever the business process changes.

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. The risk is scope creep across custom fields, logic, and exposed services, especially when side-by-side integrations depend on the same backend objects.

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. That means unmanaged services demand tighter design review, because security and consistency depend more heavily on developer-implemented logic.

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.

Technical breakdown

CDS, behavior definition, and service exposure in RAP

RAP separates the data model from the actions that can be performed on it. Core Data Services define entities, associations, projections, and metadata, while behavior definitions specify which operations such as create, update, delete, and custom actions are allowed. Service definitions and bindings then expose only selected CDS entities through OData v2 or v4. That separation matters because the interface surface is intentionally narrower than the underlying domain model, which reduces accidental exposure and makes governance more explicit.

Practical implication: review service definitions and bindings as access-control artefacts, not just development artefacts.

Managed versus unmanaged RAP business objects

Managed RAP uses framework-provided transactional handling, validations, and determinations, which is well suited to greenfield development and standard business flows. Unmanaged RAP shifts responsibility for CRUD logic, persistence, and REST contract implementation into ABAP classes, giving developers full control when existing business logic or complex integration patterns must be preserved. The technical difference is governance depth: managed RAP constrains behavior through the framework, while unmanaged RAP depends more heavily on developer discipline and explicit implementation choices.

Practical implication: treat unmanaged RAP services as higher review priority because control enforcement moves from framework defaults to custom code.

Extensibility and stateless service consumption

RAP supports in-app and side-by-side extensibility so teams can extend standard business objects without modifying core code. It also promotes stateless service consumption, which is useful for scalability and multi-device continuity, because the service can be resumed without preserving server-side conversational state. In SAP terms, this improves cloud readiness, but it also means that business logic, service scope, and extension points must be tightly governed, because the application contract is what controls behavior across UI services and external APIs.

Practical implication: validate extension points and API bindings whenever business processes change, especially in hybrid SAP landscapes.

NHI Mgmt Group analysis

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.

Service scope drift: is the key failure mode teams should watch for in RAP-based landscapes. RAP allows selective exposure through service definitions and bindings, but unmanaged extensions and loosely reviewed projections can expand what external clients can reach. The problem is not that RAP lacks control, but that governance depends on keeping the service contract aligned with the business object contract. Practitioners need to manage that alignment as a living boundary.

RAP reinforces the move from code-centric control to contract-centric control. Classic ABAP mixed logic, data access, and UI behavior in ways that were harder to govern consistently. RAP makes the boundary clearer, which improves auditability and change control, but also places more weight on service design discipline. For SAP programmes, the practical question is whether access decisions are being made at the right layer and reviewed with the right ownership.

Extensibility is the long-term governance test in modern SAP application design. In-app and side-by-side extensions are necessary for cloud adaptability, yet they also create the most common path for scope creep if review processes are weak. The right lens is not whether extensions exist, but whether they preserve transactional integrity, service minimisation, and ownership clarity. Practitioners should align extension governance with application lifecycle controls.

RAP sits at the point where application architecture and identity governance meet. For SAP landscapes, the future control problem is not only authorisation inside the application. It is whether data models, service bindings, and extension layers are being designed to support least privilege, separation of duties, and stable audit evidence across cloud and on-premises deployments. Teams should govern RAP as part of the enterprise access surface.

From our research:

• 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.
• That governance gap is why teams should also study NHI Lifecycle Management Guide when extension points or service accounts outlive the business process they support.

What this signals

RAP is a useful reminder that application modernisation changes governance scope as much as it changes developer productivity. When service exposure, extension logic, and transactional rules are separated cleanly, identity teams get a more reviewable control surface. The challenge is sustaining that discipline as Fiori, APIs, and side-by-side extensions multiply across the SAP estate.

Service scope drift: is the recurring risk in modern SAP application delivery. Teams that let projections and bindings expand without lifecycle review create a wider access surface than the original business object intended, which makes certification, segregation of duties, and audit evidence harder to maintain.

Identity governance teams should expect more demand for evidence that application contracts, not just user roles, are being controlled. That puts RAP-adjacent work into the same conversation as NIST Cybersecurity Framework 2.0 governance, because the control objective is still the same: define, protect, detect, and recover around the exposed service boundary.

For practitioners

• 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. Reassess those boundaries whenever a projection or extension is added.
• 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. Confirm who owns CRUD logic, validations, and error handling before a service is promoted.
• 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. Require an ownership check for every new extension before it reaches production.
• Align SAP service exposure with least privilege Use RAP service bindings to expose only the operations each consumer needs, and remove unnecessary UI or API access paths as business processes change. This is especially important where Fiori, external systems, and hybrid deployments share the same backend.

Key takeaways

• RAP changes SAP governance by making service definitions and bindings the real control boundary for business actions.
• The main risk is service scope drift, especially when unmanaged extensions or projections widen what consumers can reach.
• Teams should review RAP objects as identity and access artefacts, with lifecycle and audit control applied at the service layer.

Key terms

• RAP service binding: A RAP service binding is the definition that determines how an exposed service is consumed, including protocol and consumer type. In practice, it is part of the application boundary because it controls what external systems or UI components can interact with the business object.
• Behavior definition: Behavior definition specifies which operations are allowed on a RAP business object, such as create, update, delete, and custom actions. It separates intent from implementation, which makes the application easier to govern, review, and test across cloud and hybrid SAP environments.
• Managed RAP: Managed RAP is the framework-assisted approach to building business objects where transactional behavior, validations, and determinations are handled largely by the platform. It reduces custom control code, but it also makes the service design itself more important for access governance.
• Unmanaged RAP: Unmanaged RAP is the approach where developers implement transactional logic, CRUD handling, and persistence behavior themselves. It provides flexibility for complex integration or legacy reuse, but it also increases the burden on design review, testing, and audit readiness.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pathlock: What is RESTful Application Programming (RAP)? Read the original.