In this comprehensive guide, we'll explore all 5 types of behavior definitions available in SAP RAP, understand when to use each one, and see practical examples that will help you make the right choice for your projects.
What is a Behavior Definition?
I know it's too late to go through the definition as we have already created RAP apps in the previous blogs. But still, a Behavior Definition (BDEF) is where you specify:
- Which operations (Create, Read, Update, Delete) are possible on your entities
- Whether these operations are controlled by the RAP framework or implemented by you
- Additional business logic like validations, determinations, and actions
- How entities relate to each other through associations and composition
The header of your behavior definition declares the implementation type, which determines who's in charge of what. Let's dive into each type.
1) Managed Behavior Definition (managed)
What it is:
In a managed behavior definition, the RAP framework takes full responsibility for handling your business object's lifecycle. This means the framework automatically manages:
- CRUD operations (Create, Read, Update, Delete)
- Transactional buffer management
- Save sequence execution
- Draft capabilities (if enabled)
- Persistence to database table
You simply declare your persistent table and field mappings, and the framework does the heavy lifting.
When to use:
Use this for most transactional apps where you want RAP to take care of persistence and save logic without writing custom save code.
Example header snippet:
managed;
define behavior for ZI_BILLING_ROOT alias Billing
persistent table zbilling_root
{
...
}SAP Help Reference:
Managed Behavior Definition - SAP Help
2) Managed Behavior with Save Options (with additional save / with unmanaged save)
What it is:
Variants of managed behavior that allow injecting custom save logic at certain points without fully taking over persistence.
-
with additional saveallows you to extend the standard managed save process with custom logic after the framework completes its standard persistence. The framework handles all standard operations, and you add supplementary processing. -
with unmanaged savegives you complete control over the save sequence while keeping the managed interaction phase. The framework handles all user interactions, validations, and buffer management, but you implement the entire persistence logic.
When to Use Additional Save?
- Audit logging - Track changes for compliance
- Change documents - Generate change history
- Notifications - Send alerts after data changes
- Data replication - Sync changes to other systems
- Analytics updates - Update reporting tables
When to Use Unmanaged Save?
- BAPI integration - Use existing BAPIs for persistence
- Legacy system updates - Save through existing update function modules
- Multi-system persistence - Save to multiple backend systems
- Custom persistence logic - Specialized save requirements that don't fit standard patterns
SAP Help Reference:
Save Options in Behavior Definitions - SAP Help
3) Unmanaged Behavior Definition (unmanaged)
What it is:
In unmanaged behavior definition, you take full control over everything. The RAP framework provides only the structural foundation, but you must implement:
- All CRUD operations manually in behavior implementation methods
- Transactional buffer management (typically using singleton classes)
- Custom save logic and persistence handling
- Error handling and validation logic
- Draft handling (if needed)
When to use:
Use when persistence involves external systems, complex distributed transactions, or when full custom control is required.
Example header snippet:
unmanaged implementation in class zbp_billing unique;
define behavior for ZI_BILLING_ROOT alias Billing
{
implementation in class zbp_billing unique;
...
}SAP Help Reference:
Unmanaged Behavior Definition - SAP Help
4) Projection Behavior Definition (projection)
What it is:
Projections define service-specific behavior on top of a base Business Object (BO). They control which actions and operations are exposed, and can restrict or rename actions for different consumers.
When to use:
Use when you need multiple service views on the same BO, for example a read-only service vs. a full CRUD service, or roles with limited permissions.
SAP Help Reference:
Projection Behavior Definitions - SAP Help
5) Interface Behavior Definition (interface)
What it is:
An Interface BDEF defines a RAP Business Object (BO) interface that serves as a contract for stable consumption, typically released under the C1 contract. It specifies the behavior included in the interface, allowing for a standardized interaction with the BO.
Key Characteristics:
-
No persistence; not backed by a database table.
-
Defines actions, associations, and events the BO supports.
-
Serves as a stable API contract for consumers.
When to use:
Use Interface BDEFs to expose a stable and consistent API, ensuring consumers rely on defined behaviors without implementation details.
SAP Help Reference:
RAP - Interface Behavior Definition
6) Abstract Behavior Definition (abstract)
What it is:
An Abstract BDEF serves as a typing mechanism for deep parameters in actions or functions. It is based on a CDS abstract entity and does not implement persistence or behavior logic itself. Instead, it provides structure used by other BDEFs.
Key Characteristics:
-
No persistence; not backed by a database table.
-
Defines typed structures for deep parameters in actions/functions.
-
Cannot be used directly; must be extended or implemented.
When to use:
Use Abstract BDEFs to define structured types for deep parameters, ensuring type safety and consistency in your RAP app.
SAP Help Reference:
RAP - Abstract Behavior Definitions
Quick Summary
| BDEF Type | Use Case |
|---|---|
| Managed | Most transactional apps needing full RAP persistence and save logic handled automatically. |
| Managed + Save Options | Managed persistence plus custom save steps for specific needs. |
| Unmanaged | Full control over persistence and save logic; for complex or external persistence. |
| Projection | Multiple service views with different access or actions on the same BO. |
| Interface | Define reusable behavior contracts without persistence. |
| Abstract | Base behavior for reuse without persistence implementation. |
