RAP Managed vs Unmanaged: The Real Choice

Managed and unmanaged are implementation types declared on a RAP behavior definition, and they decide who is responsible for persisting data during a save. In a managed scenario the framework generates the standard operations, create, update, delete, lock, numbering, buffering, and maps them onto the underlying CDS entity's persistence, usually a database table reachable through the associated CDS view. In an unmanaged scenario the developer writes every one of those operations by hand inside the behavior implementation class, typically to call an existing BAPI, function module or older business logic layer that already knows how to save the data. The point of confusion for people new to RAP is assuming managed means no code is written at all. It is not. Determinations, validations and actions are hand-written in both types. What managed actually removes is the boilerplate around create, update, delete and the transactional save sequence, not the business logic layered on top of it.

Managed is the default choice for any new custom business object where the developer owns the table or CDS entity end to end, particularly when draft handling, standard Fiori Elements list report and object page patterns, or ETag concurrency are wanted with minimal plumbing. Unmanaged is the right tool when the save logic already exists and cannot be duplicated safely, for example a sales order creation BAPI with its own numbering, pricing calls and update tasks, or a legacy custom program with save logic too entangled to reimplement. Reaching for unmanaged on a greenfield custom table is a common mistake; it throws away draft handling, ETag support and most of the generated plumbing for no reason. Reaching for managed to wrap an existing BAPI is the opposite mistake; the framework will fight the BAPI's own transactional assumptions, particularly around numbering and locking, and the result is fragile.

The managed or unmanaged choice sits inside the behavior definition, which sits on top of a CDS entity with a behavior binding, itself built on a projection or root CDS view. Above the behavior definition sits the service definition and service binding, which exposes the business object as OData for Fiori Elements or SAP Fiori freestyle apps. Below the behavior implementation, unmanaged scenarios typically call out to older function modules or BAPIs, meaning the RAP layer becomes a thin transactional wrapper around code that predates RAP entirely. Managed scenarios replace the old pattern of writing custom BAPI wrappers by hand for simple CRUD cases; unmanaged is essentially a controlled way of keeping that older pattern alive underneath a modern OData-exposed business object, rather than a separate architecture in its own right.

A custom quality inspection request application starts as a managed scenario. The developer creates a custom database table, a CDS interface view and projection view on top of it, and a behavior definition marked managed with early numbering. Create, update and delete operations need no manual implementation; only a validation checking that the inspection date is not in the past and a determination defaulting the status field are hand-coded in the behavior implementation class. Contrast this with a requirement to expose sales order creation through the same Fiori app pattern. Sales order creation already runs through a mature legacy function module handling pricing, credit checks and numbering. Wrapping that in managed RAP would mean reimplementing all of that logic to satisfy the framework's save contract, which is wasteful and risky. Instead the behavior definition is marked unmanaged, and the create operation implementation simply maps the RAP request structure onto the function module's import parameters, calls it, and maps the result back, leaving the existing logic entirely in charge of the save.

Managed RAP is the implementation type aligned with clean core extensibility guidance for new custom development on S/4HANA; it keeps custom logic inside the framework's generated boundaries and minimizes what has to be revisited on upgrade. Unmanaged is not deprecated, but it is positioned narrowly, as the bridge for reusing stable existing logic rather than as a general-purpose alternative. Building new custom objects unmanaged purely out of familiarity with older BAPI-based patterns runs against the direction SAP is pushing development, and it tends to accumulate technical debt that later has to be migrated to managed anyway once draft handling or standard Fiori Elements features are wanted.

This is a developer and architect decision made at design time, not something changed casually later since it reshapes the behavior implementation class. The architect should own the managed versus unmanaged call for each business object and document the reasoning, particularly for unmanaged cases, so the next developer understands why legacy logic is being wrapped rather than reimplemented. Functional consultants contribute the business rules that become determinations and validations regardless of which type is chosen.

Read the behavior definition and behavior implementation page first, since managed versus unmanaged is declared and lived out entirely inside that object. For anyone leaning toward unmanaged, the page on unmanaged scenarios with legacy code reuse covers the wrapping pattern in more depth. Draft handling and late numbering are both areas where the managed versus unmanaged choice has direct, concrete consequences worth checking before committing to a type.