Coffee Subscription

• temporary Z tables,
• status flags,
• or complex application logic.

• reduces code complexity,
• improves transactional robustness,
• standardizes application behavior.

• they feed CDS Interface Views (ZI),
• which are projected to the UI,
• and handled via the Behavior Definition.

• select only the fields required by the app,
• hide internal model complexity,
• adapt exposure to functional context.

• dedicated CDS (Projection or VH),
• linked to fields in the CDS Projection.

• secure user input,
• offer consistent values,
• standardize the Fiori experience.

• ZI: stable, reusable business definition
• ZC: controlled, UI-oriented exposure

• Controlled exposure of RAP entities
• Clear separation between internal model and exposed surface
• Prepared for UI consumption or future integration

• the endpoints required by Fiori Elements UI.

• better RAP integration,
• consistent, standard Fiori Elements UI generation.

• hand-built OData services (SEGW),
• manual mapping and UI-specific logic.

managed implementation in class ZBP_I_COFFEE_SUB_TRL unique;
strict ( 2 );
with draft; // active draft handling
define behavior for ZI_COFFEE_SUB_TRL
persistent table zcs_sub_trl
draft table zcs_sub_trl_d // draft persistence
lock master
total etag local_last_changed_at
etag master local_last_changed_at
authorization master ( global )
{
  create;
  update;
  delete;
  field ( numbering : managed, readonly )
  subscription_uuid;
  field ( readonly )
  created_by,
  created_at,
  last_changed_by,
  last_changed_at,
  local_last_changed_at,
  next_delivery_date,
  status;
  action ( features : instance ) pause;
  action ( features : instance ) unpause;
  action ( features : instance ) cancel;
  validation validate_qty on save { create; update; field qty_grams; }
  validation validate_start_date on save { create; field start_date; }
  validation validate_status_transition on save { create; update; field status; }
  validation validate_email on save { create; update; field customer_email; }
  validation validate_frequency on save { create; update; field frequency; }
  determination set_defaults on modify { create; field status; }
  determination calc_next_delivery on modify { create; update; field start_date; }
  draft determine action Prepare // draft prepare flow
  {
    validation validate_qty; // draft validations
    validation validate_start_date; // draft validations
    validation validate_email; // draft validations
    validation validate_frequency; // draft validations
    validation validate_status_transition; // draft validations
  }
  draft action Edit; // draft edit
  draft action Activate optimized; // draft activation
  draft action Discard; // draft discard
  draft action Resume; // draft resume
  side effects
  {
    action pause affects field status;
    action unpause affects field status;
    action cancel affects field status;
  }
}

• secure user input,
• apply business rules before activation,
• deliver a standard SAP-like experience.

• Persistence tables: active data
• Draft tables: temporary data
• CDS Interface & Projection: expose both states
• Behavior Definition: drives lifecycle (draft → active)
• Fiori Elements UI: handles draft state automatically

• User clicks Create Subscription
• A draft instance is created
• User fills fields (Value Helps, determinations)
• Validations run
• If error: draft is kept
• If OK: Activate → data copied to active table, draft removed

• validation consistency (also runs in draft),
• determinations must handle both states,
• draft table and technical fields must be correct.

validation check_quantity on save { field quantity; }
validation check_email on save { field customer_email; }

• on create,
• on update,
• and especially before draft activation.

validation check_quantity on save { field quantity; }

• quantity must be strictly positive,
• frequency must not be initial,
• coffee type must be provided.

• the save is blocked,
• an error message appears in the UI,
• the draft is kept for correction.

• use blocking messages only when necessary,
• target the exact field,
• avoid heavy validations (performance),
• do not duplicate logic with determinations.

• unnecessarily block users,
• degrade the Fiori experience,
• complicate future evolution.

• only consistent data reaches the database,
• business rules are applied uniformly,
• the app behaves like SAP standard.

• on draft creation,
• on modification.

determination set_defaults on modify { create; field status; }

• initialize subscription status on create,
• calculate next delivery date based on frequency,
• keep business fields consistent.

• do not replace validations with determinations,
• avoid side effects (unwanted loops),
• respect user-entered values when appropriate,
• keep logic simple and predictable.

• reduce manual input,
• strengthen data reliability,
• deliver a SAP-standard experience.

• exposed automatically in Fiori Elements as buttons,
• executed transactionally in the behavior implementation.

action pause;
action unpause;
action cancel;

• ACTIVE: subscription active
• PAUSED: subscription paused
• CANCELED: subscription stopped

• verify current state before allowing an action,
• prevent invalid transitions,
• handle user messages clearly,
• secure actions with authorizations if needed.

• clarify the subscription lifecycle,
• offer explicit, controlled interactions,
• stay aligned with SAP standard behavior.

• a dedicated CDS Value Help view,
• linked to the field via annotation in the CDS Projection.

• secures input data,
• improves user experience,
• centralizes selection logic.

• Create a Value Help CDS with allowed values
• Associate it with the target field via annotation
• Fiori Elements handles the UI display automatically

• coffee type,
• delivery frequency,
• subscription status.

• Validations
• Actions
• Determinations (rarely blocking)

APPEND VALUE #(
  %msg = new_message(
    id       = 'ZMSG'
    number   = '001'
    severity = if_abap_behv_message=>severity-error
    v1       = 'Invalid subscription data'
  )
) TO reported.

• severity-error blocks save
• the message is displayed automatically in the UI

• quantity is zero or negative,
• delivery frequency is missing,
• an action (Pause / Unpause / Cancel) is triggered in an invalid state.

• a blocking message is shown,
• the object remains in draft,
• the user can correct without data loss.

• use clear, business-oriented messages,
• block only when necessary,
• keep draft active for correction,
• test messages in the UI.