Behavior Definitions Part 5: Projection Behavior, Strict Mode and Stable Contracts

📌 KEY POINTS
✅ Projection BDEF = what one service may use ("use …").
✅ Interface BDEF = stable EML API for other developers.
✅ strict ( 2 ) for all new BDEFs.
⚠️ Breaking changes need a new projection/service version.

▶ WHERE WE ARE
Parts 1–4 covered the base BDEF (ZR_PurchReq) where behavior is defined. Consumers do not use it directly. This part covers the layers on top and how to change a BO without breaking its consumers.

━━━━━━━━━━━━━━━━━━━━
▶ 1. PROJECTION BDEF — ONE CONSUMER'S VIEW
A projection BDEF sits on a projection CDS view (provider contract transactional_query) and starts with "projection;".

• It does not define behavior; it selects it with "use": "use create; use update; use action approve; use association _Item { create; with draft; }".
• Anything not listed is not available to this service — e.g. an API projection without delete, or without draft ("use draft;" omitted).
• It can add consumer-specific behavior on top (augmentation, e.g. defaulting a field only for this app) with its own implementation class — use this sparingly.

Typical setup: ZC_ projection for the Fiori UI (with draft), a separate API projection without draft (Service Bindings Part 4).

━━━━━━━━━━━━━━━━━━━━
▶ 2. INTERFACE BDEF — A STABLE ENTRY POINT FOR OTHER DEVELOPERS
An interface BDEF starts with "interface;" and sits on an interface projection view with "provider contract transactional_interface" (often named with a TP suffix, e.g. ZI_PurchReqTP).

• Purpose: give other developers (other BOs, reports, extensions) a stable EML API to your BO, decoupled from the internal base BO.
• SAP uses this pattern for its released BO interfaces (e.g. I_…TP), which you call with EML in clean-core development.
• You release the interface (API state) so others may depend on it; the base BO can then change internally.

━━━━━━━━━━━━━━━━━━━━
▶ 3. STRICT MODE

• strict — the first strict mode; enforces best practices at syntax-check level.
• strict ( 2 ) — the current, stricter version; for example it requires explicit authorization declarations and stricter checks on draft and field definitions.

Always use strict ( 2 ) for new BDEFs. When raising an older BDEF from strict to strict ( 2 ), expect new syntax errors that point to real design gaps; fix them rather than lowering strictness.

━━━━━━━━━━━━━━━━━━━━
▶ 4. KEEPING CONTRACTS STABLE
Once a service or interface is consumed, treat its BDEF as a contract:
Compatible (usually safe):

• Adding a new optional field, a new action, a new determination or validation that does not reject previously valid data.

Incompatible (breaking):

• Removing an operation, action, field or association from a projection or interface.
• Making an optional field mandatory, or a writable field read-only.
• Changing action parameters or result types.
• Renaming entities or aliases used by consumers.

For breaking changes, create a new projection/interface and service version and migrate consumers, rather than changing the existing contract.

━━━━━━━━━━━━━━━━━━━━
▶ 5. EXTENSIBILITY
Base BDEFs can be marked "extensible" so that others can add behavior via BDEF extensions without modifying the original. SAP's released BOs use this for customer extensions; for your own BOs, plan it only if other teams will extend them.

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

1. For each consumer, create a projection with exactly the operations it needs.
2. If other developers call your BO via EML, provide an interface BDEF and release it.
3. Keep all new BDEFs on strict ( 2 ).
4. Before changing a released projection or interface, classify the change as compatible or breaking.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER THE SERIES
Full command of BDL: structure, operations, fields, logic, relationships, draft and stable layering. Next topic: Behavior Implementations — the ABAP side.

Two teams called a Purchase Request BO directly with EML on the base BO ZR_PurchReq. When the owning team refactored an action parameter, both consumer programs broke in the next transport to QAS.
The owning team introduced an interface layer (ZI_PurchReqTP with an interface BDEF), released it, and asked consumers to switch. From then on, internal changes to the base BO did not affect consumers, and the interface followed an explicit rule: only compatible changes in place, breaking changes via a new interface. In the same review, a projection for an external API was reduced to create, update and approve — delete had been exposed by accident.

• Exposing the base BO directly to services or other developers.
• Listing every base operation with "use" in every projection.
• Draft in API projections.
• Downgrading from strict ( 2 ) to silence errors instead of fixing them.
• Making breaking changes to a consumed projection or interface in place.
• Heavy augmentation logic in projections, splitting behavior across layers.

• One projection per consumer, exposing only what it needs.
• Interface BDEF (transactional_interface) for EML reuse by other developers; release it.
• strict ( 2 ) for all new BDEFs.
• Classify every change to a consumed contract as compatible or breaking.
• Keep behavior in the base BO; keep projections thin.

Questions: "What is a projection BDEF?", "What is an interface BDEF and when do you need one?", "What does strict ( 2 ) do?", "How do you change a released RAP API?"
Strong answer: projection BDEFs select behavior for one consumer with "use"; interface BDEFs on transactional_interface projections provide a stable, releasable EML API (the pattern of SAP's released TP interfaces); strict ( 2 ) enforces stricter checks such as explicit authorization. Classify changes as compatible or breaking and version breaking changes. Mentioning that clean-core code calls SAP's released interface BOs via EML shows current knowledge.