Management of RAP in contrast to. unmanaged scenarios: What to Select for your next S/4HANA Project
Meta Description Managed vs. unmanaged RAP scenarios clarified - an approach to deciding on S/4HANA development in greenfield areas vs wrapping function modules from the past. Find out what RAP method is best suited to your project.
Introduction: The Decision Every RAP Project Starts With
Before you even write one line of a Behavior Definition prior to constructing your very first CDS View Entity each SAP RESTful Application Programming Model (RAP) project will require you to answer a essential issue: should this business object be managed or left unmanaged?
Make the right choice and your development will move quickly -and SAP creates the majority of transactional plumbing for you and your team can concentrate at business logic. Make a mistake and you'll be fighting the framework or getting buried in boilerplate persistence codes you did not need for writing, or squeezing an object managed into a form it wasn't designed to be able to hold.
This is among the most frequently encountered problems for ABAP developers moving from classic development to the S/4HANA Cloud or RAP-based structures. This guide provides an easy-to-follow decision structure based on real-world scenarios so that you can determine which option to take for the next greenfield construction or wrap-up project from the past.
A Quick Refresher: What Is RAP?
The ABAP RESTful Applications Programming Model (RAP) is SAP's preferred framework for creating business objects in S/4HANA both on-premise and cloud. It replaces the earlier BOPF (Business Framework for Object Processing) and the traditional ABAP OO patterns with a integrated model that is based on:
- CDS View Entities -- for data modeling
- behavior definitions as well as Behavior implementations -- to support business logic (create and update deletion, create (decisions, actions)
- Service Definitions, Service Bindings for exposing the object using OData in Fiori Elements UIs and external consumers
In this framework, each business object is built with any of these two runtime types: managed or unmanaged. This is not just a style decision, but it fundamentally alters who is responsible for writing an application's persistence logic. It also affects the amount of code you write and how much control you can have.
Managed RAP: SAP Handles the Plumbing
What Managed Means
In the case of a monitored RAP scenario it is in a managed RAP scenario, the RAP framework itself creates and handles the typical database functions -- create and update, as well as delete (CUD) -- in a way that is automated. The data model is defined by you and business rules. SAP's runtime is able to read of and writing into the table(s) in the background.
Your job as a developer is now:
- Definition of how to define the CDS View Entity and its base database table
- Writing the Behavior Definition in order to identify what operations are allowed
- Only implementing what is necessary for essential business processes such as validations determinations, validations, and other custom actions, but not the persistence itself.
When Managed Is the Right Choice
Managed RAP by SAP is the declared preferred strategy for development that is new, and it's the best option in the following situations:
- You are creating an enterprise object that is greenfield without any existing old-fashioned database structure or function module logic to protect
- The data structure you use is simple generally an entity at the root with zero, one or a couple of children entities that are in a clear composition of hierarchy
- You're looking for speedy value-to-time. Managed objects can move from a CDS-based entity to an operational Fiori Elements draft-enabled UI in less than a quarter of the time that a non-managed build would require.
- You'll need the standard features in the standard runtime including draft handling (save-for-later and edit-in-place UX) as well as optimistic concurrency control and ETag-based change tracking, all of which managed runtime can provide automatically
- This team relatively new than RAP and is able to benefit from the framework's guardrails instead of having complete control over persistence
The Trade-Off
Managed RAP offers granular control over the specific SQL that is executed for CUD-related operations. The vast most custom developedmaster data objects that are new or new configuration objects customized transactional itemsthis is not a problem, since there's no existing persistence pattern that you have to keep.
Unmanaged RAP: You Control Everything
What Unmanaged Means
In an unmanaged RAP situation the framework offers an interface contract (the Structure of Behavior Definition structure and OData exposure, the OData exposure, and the Fiori interconnection points) however, it is your responsibility to write the persistent logic by yourself within the Behavior Implementation class, by using explicit ABAP code.
This means that each create edit, delete, or create procedure is programmed manually typically using existing logic, rather than creating brand-new database statements.
When Unmanaged Is the Right Choice
Unmanaged RAP is designed specifically for situations in which full automation of the framework isn't suitable:
- Wrapping function modules from the past and BAPIs. This is the most popular reason to use a non-managed RAP. If a proven, well-tested function module is already handling the creation/update process for an object in the business world -- including validation as well as handling of number ranges and downstream integration you shouldn't have to recreate the process. You'll want to name it.
- Complex non-standard persistent logic that isn't mapped well to standard CUD table operations, for instance items that are able to write data across several tables that are not related, with complex sequence, or objects that have an old-fashioned custom number-range and status-management logic that is pre-dates RAP.
- You require specific control over transactional behavior -- the precise operation's sequence, a custom locking logic or integration with non-standard persistence patterns
- You're exposing an existing custom on-premise development as an API-consumable object and not rebuilding its logic inside
The Trade-Off
Unmanaged RAP will require significantly more code. The automated draft handling the automatic optimistic locking, as well as the general saving sequences that objects managed can get for free, unless you implement similar logic your own. The time to develop is longer and the object needs more thorough testing because you are the sole owner of accuracy of the transaction.
Managed vs. Unmanaged: Side-by-Side Comparison
| Dimension | Managed RAP | Unmanaged RAP |
|---|---|---|
| Persistence logic | Automatically generated by the framework | Manually written for the Behavior Implementation |
| Best fit | Greenfield custom-made objects | Wrapping function modules/BAPIs from the past |
| Speed of development | Quick -- no boilerplate | Slower -- Full CUD logic needed |
| Draft handling | Built-in, automatic | Manually implemented if required |
| Control of concurrency | Automated ETag-based locks | Logical locking is required manually |
| Code volume | Low | High |
| Control of SQL/persistence | Limited (framework-controlled) | Complete control |
| Common use cases | Master data updated, custom transactional objects | Utilizing validated logic from the past, complicated non-standard persistence |
| SAP's strategic suggestion | The default choice in cases where it is feasible | Reserved for scenarios that cannot be supported in a clean manner. |
The Decision Framework: Five Questions to Ask
This sequence of questions should be used for each new RAP object you want to explore. Answer them in the order you want - that first "yes" that fires usually decides the issue.
1. Does a function module from the past or BAPI already use this business logic with confidence?
If so, and the logic is complicated testable, validated, and connected to other processes or systems, lean unmanaged. Rewriting established logic into new managed persistence is usually more risky than wrapping it in a new way.
If not, this is actually a new function --- manage lean.
2. Are you able to identify this as a greenfield object that has clear, simple data model?
A root entity that is simple in its child compositions and no peculiar persistence requirements is a typical managed scenario. When your model for data is easy and fresh, managed is almost always right.
3. Do you require automatic draft handling or Fiori Elements UX straight out right out of the bag?
If your users require the basic "edit, save draft, resume later" experience, which is standard within Fiori Elements apps, managed allows this to happen automatically. Re-creating draft handling manually in a non-managed object is an expensive, but often unnecessary engineering expense.
4. Is the logic for persistence able to extend to multiple tables, with complicated non-standard sequencing?
If your logic for creating or updating must be able to interact with a number of tables that are not related in a certain sequence, using the conditional logic that isn't mapped to simple validation of fields managed gives you the ability to sequence this in a correct manner. Managed's save sequence, which is generic, follows an almost normal composition pattern.
5. Are you and your team optimizing speed of delivery for projects with short timelines?
If everything else is the same, managed can bring you to a functioning prototype more quickly. If there's no compelling technical argument that would lead you to managed RAP, the speed benefit of RAP managed is an important determinant especially when it comes to MVP prototypes or proof-of-concept designs.
Real-World Scenario Walkthroughs
Scenario A: New Custom Approval Workflow Object
A company requires a brand new custom object that tracks multi-level approbation requests to approve capital expendituresThere is no existing equivalent to the legacy model. Data models are an entity with a root (Approval Request) with a sub-entity (Approval steps).
Review managed. This is textbook greenfield development that has a clear composition structure. Managed RAP offers Draft handling and CUD, as well as standard and a functioning Fiori Elements' UI, with only custom code, which lets the team concentrate on the approval-routing business logic.
Scenario B: Wrapping a Legacy Sales Order Creation BAPI
A company runs a highly customized sales order generation procedure that relies on a BAPI that has a multitude of pricing and validation integrations along with the downstream EDI triggers. Leadership is looking to make this available in a modern API-consumptable RAP object in the new Fiori application, but without altering the logic behind it.
Verdict Not managed. Rebuilding this logic in a managed way would require the re-implementation of years of valid business rules and integration touchpoints - high risk, expensive with little benefit. The wrapping of the current BAPI in an unmanaged behavior Implementation keeps the logic that has been proven and provides it with a contemporary RAP-based interface.
Scenario C: New Custom Master Data Object for Equipment Categories
A business requires a straightforward master data object to be created Equipment categories with descriptions, and a couple of attributesthat can be used in a brand new customized Fiori application.
Verdict Managed. Simple, flat master data in greenfield is the best possible argument to manage RAP. The logic is not legacy to keep and there is no complicated persistence sequencing to be involved.
Scenario D Complex Multi-Table Customized Object with Number Ranges from the past
A business requires a brand new custom object, however it has to be integrated with the existing number-range logic, which spans three tables interdependently custom designed that have conditional status transitions which don't translate well to the standard field validations.
Verdict: Probably unmanaged or an hybrid method with unmanaged as the primary entity and making sure that the child entities are managed when feasible. This is an instance where the complexity of persistence is greater than the speed benefits of complete automation.
Hybrid Approaches: You Don't Always Have to Choose Just One
RAP allows mixing both managed and unmanaged processes in the same composition hierarchysuch as, for instance an entity that is managed with an unmanaged sub-entity that covers legacy logic for a specific sub-process or in reverse. This flexibility means that the decision framework described above doesn't need to provide an all-or-nothing solution for large-scale projects. Assess each component of your composition tree by answering the same five questions rather than thinking that the entire object has to be managed uniformly or in no way.
Common Mistakes to Avoid
Unmanaged as a default due to the habit. Developers coming from traditional ABAP and BOPF background may opt for unmanaged since the unmanaged option "feels" more familiar -fully manual control. This practice creates excessive code volume and negates the efficiency of draft handling and the concurrency advantages managed RAP offers for free. Set default to managed until an explicit requirement forces the user away.
The choice of managed for a legacy wrapping scenario in order to "modernize" old logic. The idea of rewriting complex, validated old business rules in a fresh managed persistence rather than wrapping an existing function modulecreates a risk of regression that's not worth the architectural sanity that is gained.
Overestimating the manual effort for draft handling in draft handling that isn't managed. If your project requires Fiori Elements UX with draft capabilities and you've chosen to go unmanaged make sure you budget for significant additional time for development in order to replicate the results that managed can do automatically.
Not considering the hybrid choice. Teams sometimes force an entire object into one type of runtime, in the event that a mix of managed and unmanaged components will better suit the actual demands of the data and logic.
Frequently Asked Questions
Q: What's the different between unmanaged and managed RAP within SAP? In managed RAP the framework generates automatically the create the, update and delete logic for persistence. In unmanaged RAP the developer creates this persistence logic manually within the Behavior Implementation generally to wrap existing function modules, or BAPIs.
Q When should I utilize managed RAP in the S/4HANA application? Use managed RAP for custom business objects that are greenfield with a simple, clean data model, particularly when you require automatic draft handling, control of concurrency and speedy fiori elements UI service delivery.
Q: When should I utilize Unmanaged RAP? Use unmanaged RAP when wrapping validated, existing BAPIs and function modules that are older than the framework or if your persistence logic requires complicated, non-standard sequencing over multiple tables which don't match the framework's standard save pattern.
Question: Could an RAP business object combine managed and unmanaged objects? Yes. RAP allows hybrid compositions in which certain entities within the object's hierarchy are managed while others are not managed, allowing teams to use the correct method at the level of the entity instead of the entire-object level.
Q Is SAP recommend unmanaged or managed RAP as a standard? SAP's stated strategic preference is for managed RAP to be the standard approach for new development, while allowing unmanaged RAP in cases in which managed persistence is not able to satisfy the need for wrapping legacy code.
A: Are managing unmanaged RAP more laborious over controlled RAP? Yes. Unmanaged RAP involves manually programming the entire CUD logic as well as in the event of need, duplicate draft handling and control of concurrency that managed RAP offers automatically, which results in substantially more testing and development effort.
Final Thoughts
The managed-versus-unmanaged decision isn't about which approach is "better" in the abstract -- it's about matching the runtime type to the actual shape of your business object and the logic behind it. Clean, simple, greenfield objects should be in managed RAP and SAP's framework handles the heavy lifting so that your team can deliver quicker. The older wrapping scenarios, as well as objects that have genuinely complicated and non-standard persistence requirements, are best handled in unmanaged RAP with full control to retain your existing business logic without having to shape it into something it wasn't designed to be.
Make sure to run each brand new RAP objects through the framework of five questions above before writing your first Behavior Definition. This will protect your team from two of the most costly and costly mistakes made by RAP teams Over-engineering basic objects using unmanaged code, and ignoring complex legacy wraps, by forcing them to use managed persistence that they weren't designed for.