RAP Basics Part 6: Behavior Definition — CRUD, Field Control and Features

📌 KEY POINTS
✅ The BDEF is the contract of the BO: which operations exist, which fields are editable, which actions are available, and under which conditions.
✅ Static field control: field ( readonly ), ( mandatory ), ( readonly : update ) — applies always, no code.
✅ Dynamic control: features : instance on operations/actions/fields → implemented in get_instance_features, evaluated per instance (e.g. no update when status = Accepted).
✅ mapping for <table> maps CDS aliases to table fields when names differ (needed for some scenarios, e.g. unmanaged save or when the framework cannot derive mapping).
⚠️ Hiding a button in the UI is not protection — only BDEF feature control (and authorization) enforces it for every consumer, including APIs and EML.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 5 built the composition tree. Now we control what each entity allows.

━━━━━━━━━━━━━━━━━━━━
▶ 1. OPERATIONS

• create; update; delete; — standard operations.
• Leave out delete if the BO must never be deleted.
• Children: create via association on the parent; update/delete on the child.

━━━━━━━━━━━━━━━━━━━━
▶ 2. STATIC FIELD CONTROL

• field ( readonly ) TravelID, OverallStatus; — set only by logic.
• field ( mandatory ) AgencyID, CustomerID; — must be filled (checked on save, marked in UI).
• field ( readonly : update ) CustomerID; — editable on create only.
• field ( readonly, numbering : managed ) TravelUUID;

━━━━━━━━━━━━━━━━━━━━
▶ 3. DYNAMIC FEATURE CONTROL

• update ( features : instance ); delete ( features : instance );
• action ( features : instance ) acceptTravel …;
• field ( features : instance ) BookingFee;
• Implement get_instance_features: read the instance, return enabled/disabled per operation.

━━━━━━━━━━━━━━━━━━━━
▶ 4. GLOBAL FEATURES

• ( features : global ) — independent of an instance, e.g. disable create outside business hours or by configuration.

━━━━━━━━━━━━━━━━━━━━
▶ 5. STRICT MODE AND MAPPING

• strict ( 2 ); enforces current best practice syntax checks — always use it for new BOs.
• mapping for ztravel_a { TravelID = travel_id; AgencyID = agency_id; … }

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. List fields: editable, readonly, mandatory, create-only.
2. Add static field control in the BDEF.
3. Add features : instance for status-dependent update/delete/actions.
4. Implement get_instance_features in the handler class.
5. Test in the Fiori preview and via EML.

✅ CHECKPOINT: an accepted travel shows no Edit/Delete buttons in Fiori and an EML UPDATE on it is rejected.

On a pricing-agreement BO, the UI team hid the Edit button for approved agreements using a UI5 extension. Three months later, an integration partner used the Web API binding of the same BO and changed approved agreements, which triggered a compliance finding. The fix was to move the rule into the BDEF: update ( features : instance ) with get_instance_features returning disabled for status Approved. Now the Fiori app, the API and every EML caller are blocked consistently, and the UI extension was deleted.

• Enforcing editability only in the UI instead of feature control in the BDEF.
• Marking fields readonly that a determination must set, then being surprised the user cannot set them — readonly applies to the consumer, not IN LOCAL MODE logic.
• Forgetting features : instance in the BDEF after implementing get_instance_features (method never called).
• Using mandatory without also validating business rules on save.
• Not using strict ( 2 ) for new BOs.

• Put every "may the user do this?" rule in the BDEF (features/authorization), never only in the UI.
• Use static field control where possible; dynamic control only for state-dependent rules.
• Read only the fields you need in get_instance_features.
• Always start new BDEFs with strict ( 2 ).
• Test feature control through EML as well as through Fiori.

Questions: "How do you make a RAP field read-only depending on status?", "Difference between static and dynamic feature control?", "Why is hiding a button not enough?"
Strong answer: static control (readonly, mandatory, readonly : update) is declared in the BDEF and needs no code; dynamic control uses features : instance and get_instance_features, returning enabled/disabled per instance. Because every consumer — Fiori, Web API, EML — goes through the BO, only BDEF control is real enforcement; UI hiding is cosmetic.