Behavior Definitions Part 1: Reading a BDEF as the BO Contract

📌 KEY POINTS
✅ The BDEF is the BO contract — RAP enforces it before your code runs.
✅ Header → entity header → body: read it in this order.
✅ Missing operations are deliberate (e.g. no delete).
⚠️ Always strict ( 2 ) for new objects.

▶ WHAT THIS SERIES COVERS
The behavior definition (BDEF) is written in Behavior Definition Language (BDL). This series is the syntax guide; the Managed RAP series shows the same elements in a full build.

• Part 1 — reading a BDEF as the BO contract (this lesson)
• Part 2 — CRUD, field control, numbering, locking and authorization syntax
• Part 3 — actions, functions, determinations and validations syntax
• Part 4 — associations, compositions and draft declarations
• Part 5 — projection and interface BDEFs, strict mode and stable contracts

WHY "CONTRACT"
The BDEF states what the business object can do and under which conditions: which operations exist, which fields may be changed, how instances are locked, numbered and authorized, which rules run automatically. RAP enforces this contract before your code runs. A request for an operation that is not declared never reaches your implementation. That is why a good BDEF makes the implementation smaller.

━━━━━━━━━━━━━━━━━━━━
▶ THE THREE LEVELS OF A BDEF

1. Header (top of the file, once)

• Implementation type and class: "managed implementation in class zbp_r_purchreq unique;" (or unmanaged, projection, interface).
• "strict ( 2 );" — strictest syntax checks; always for new development.
• "with draft;" — draft enabled for the whole BO.

1. Entity header (one per entity: "define behavior for ZR_PurchReq alias PurchaseRequest")

• alias — a short name used in EML and handler method names.
• persistent table / draft table — where data is stored (managed).
• lock master / lock dependent by _Assoc
• authorization master ( global, instance ) / authorization dependent by _Assoc
• etag master Field / total etag Field
• early numbering / late numbering (when you number yourself)
• implementation in class … — optional, to put one entity's code into its own class.

1. Entity body (in braces)

• Standard operations: create; update; delete; — each can have options in parentheses.
• Field characteristics: field ( readonly ) …; field ( mandatory ) …; etc.
• Association operations: association _Item { create; }
• Business logic: determination, validation, action, function, determine action, side effects.
• Draft actions (if with draft).
• mapping for <table> { CDS field = column; } — CDS names to table columns.

━━━━━━━━━━━━━━━━━━━━
▶ HOW TO READ AN UNKNOWN BDEF IN FIVE MINUTES

1. Header: managed or unmanaged? Draft? Strict?
2. Root entity header: where are locks, authorization and ETag?
3. Which operations are declared — and which are missing on purpose (e.g. no delete)?
4. Which fields are read-only or mandatory?
5. Which determinations/validations/actions exist, and on which triggers?
6. Children: how are they locked and authorized; can they be created only via the parent?

The annotated example in the code shows every line with its meaning.

━━━━━━━━━━━━━━━━━━━━
▶ HOW BDEF AND CODE CONNECT
Every determination, validation, action, authorization and feature-control declaration becomes a method in the behavior pool. In ADT, place the cursor on the element and press Ctrl+1 to generate the method; F2 on a keyword shows the ABAP keyword documentation — the most reliable reference for your release.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER PART 1
The ability to read any BDEF and explain what the BO allows. Part 2 goes through the syntax options of operations and fields.

A new developer joined a project with 30 RAP business objects and was asked why the Purchase Request API allowed deleting items but not requests. Instead of reading hundreds of lines of handler code, the lead showed how to read the BDEFs: the request entity had no "delete" declared on purpose, while the item entity did.
The team turned this into an onboarding exercise: for each BO, read the BDEF with the five-minute checklist and write a one-paragraph contract summary. New developers became productive in days, and design reviews started from the BDEF rather than from code.

• Reading the handler code to understand a BO instead of the BDEF.
• Declaring every operation by habit, then blocking unwanted ones in code.
• Enforcing read-only or mandatory rules in code instead of field characteristics.
• Forgetting the mapping block when CDS names differ from column names.
• Omitting strict ( 2 ) in new objects.
• Allowing children to be created standalone instead of via the parent association.

• Treat the BDEF as the primary design document of the BO.
• Declare only operations that are valid for the business.
• Express rules declaratively (field characteristics, features) before writing code.
• Use aliases that read well in EML and method names.
• Use F2 keyword documentation in ADT for release-specific syntax details.

Questions: "What is a behavior definition?", "What goes into the entity header vs the body?", "How do BDEF declarations connect to ABAP code?"
Strong answer: the BDEF is the transactional contract in BDL; header defines implementation type, strict mode and draft; entity header defines alias, persistence, lock, authorization, ETag and numbering; the body declares operations, fields, associations, determinations, validations, actions and mapping. RAP enforces it before code runs; each logic element maps to a generated method in the behavior pool.