Lesson 2 of 5
Behavior definition: operations, managed and unmanaged
10 min
Listen to this lesson
The behavior definition (BDEF) is written in the RAP Behavior Definition Language (BDL). It declares, for each entity of the BO, which operations exist, which fields are read-only or mandatory, how locking and concurrency work, and which validations, determinations and actions the behavior pool must implement. Reading a BDEF is the fastest way for a tester to learn what an app is supposed to allow.
Managed or unmanaged
The first line of the BDEF chooses the implementation type. In a managed BO, SAP's cheat sheet explains, standard create, read, update and delete work out of the box, including the transactional buffer and saving; you add only your business logic. SAP describes managed as typical for greenfield development. In an unmanaged BO the developer must provide the transactional buffer and implement every operation, which SAP describes as typical for brownfield scenarios where existing application logic is embedded into RAP. Managed BOs can also be managed with additional save (for example to write change documents or raise events) or managed with unmanaged save (to replace the save with your own logic).
- Is there existing, trusted logic that must do the saving?Yes → unmanaged, or managed with unmanaged save · No → managed
- Do you need extra work after the standard save, such as change documents?Yes → managed with additional save · No → plain managed
- Are the tables new or simple custom tables?Yes → managed with a mapping to the table fields · No → assess the legacy logic first
Contoso's agreements live in plain custom tables with no special save logic, so Kenji chooses managed. Because the ECC-era table fields have short technical names, the BDEF contains a mapping for zcmc_core_agr block that maps CDS element names such as ValidTo to table fields.
Anatomy of Contoso’s BDEF
| BDL statement | Meaning for Contoso |
|---|---|
| managed implementation in class zbp_r_cmc_coreagreement unique; | Managed BO; logic in the named behavior pool |
| strict ( 2 ); | Strict mode: extra syntax checks; SAP recommends the latest version |
| with draft; | Draft handling for the whole BO (details in the advanced RAP course) |
| define behavior for ZR_CMC_CoreAgreement alias Agreement | Behavior of the root entity |
| persistent table zcmc_core_agr; draft table zcmc_core_agr_d; | Where active and draft data live |
| lock master; total etag LastChangedAt; etag master LocalLastChangedAt; | Locking and optimistic concurrency |
| authorization master ( instance ); | Instance authorization checks are implemented in the pool |
| field ( readonly ) Status, TotalDeposit; field ( mandatory ) Customer, ValidFrom, ValidTo; | Who may set which field |
| create; update; delete; association _Item { create; with draft; } | CRUD on the header; items created through the header (with draft: the item is created as a draft too) |
| validation validateDates on save { create; field ValidFrom, ValidTo; } | Check the date range on save |
| determination setInitialStatus on modify { create; } | Set status Open when an agreement is created |
| action closeAgreement result [1] $self; | A non-standard operation the user triggers |
Key statements in Contoso’s behavior definition (simplified).
Operations, validations, determinations and actions
Standard operations are create, update and delete; read is always available. Operations along a composition, such as association _Item { create; }, let consumers create children through the parent. Validations check consistency during the save sequence and can reject data with messages. Determinations change data when trigger conditions are met, either on modify, immediately in the transactional buffer, or on save, during the save sequence. Actions are non-standard operations implemented in handler methods, such as closing an agreement; they can take parameters, return results, and be restricted by feature or authorization control. SAP notes that the execution order of several determinations is arbitrary, so never design one that depends on another having run first.
| Validation | Determination | Action | |
|---|---|---|---|
| Purpose | Check consistency and reject bad data | Calculate or set data automatically | Perform a business operation on request |
| Triggered by | Save sequence when trigger conditions are met | Modify or save when trigger conditions are met | An explicit call from the UI or EML |
| Changes data? | No; returns failed and reported entries | Yes | Usually yes |
| Contoso example | validateDates: ValidTo after ValidFrom | setInitialStatus: Status = Open on create | closeAgreement: Status = Closed |
The projection BDEF
The projection layer has its own behavior definition. It starts with projection; and lists which base behavior the service may use, for example use create; use update; use action closeAgreement;. Leaving use delete out means the UI service cannot delete agreements, even though the base BO can. That is a clean way to give Maria's app a narrower behavior than a future integration API might need.
What would you do?
A developer adds a second on save determination that calculates TotalDeposit and assumes the first one, which defaults DepositPerUnit, has already run. Tests pass on some runs and fail on others. What is wrong?
- The BDEF declares operations, field characteristics, locking and custom behavior.
- Managed: CRUD and saving out of the box; unmanaged: you provide buffer and operations.
- Validations check, determinations calculate, actions perform requested operations.
- Determinations run on modify or on save; their order is arbitrary.
- The projection BDEF selects which behavior a service may use.
Check your understanding · not graded
Lesson check
1. Which implementation type gives you CRUD and saving out of the box?
2. Which BDEF statement forbids the consumer from setting Status?
3. How do you stop the UI service from deleting agreements while the base BO allows delete?
4. What does SAP say about the execution order of several determinations?