1. Deployment & Integration Approach
   1. Where is this RAP Business Object running and being developed?
      1. On‑stack (S/4HANA / Steampunk embedded) vs ABAP Cloud (BTP) changes connectivity options, release constraints, and extensibility approach.
   2. Is this an embedded RAP scenario (same system as the data and UI)?
      1. Yes → prefer local service consumption and keep latency assumptions tight.
      2. Pay attention to in-app extensibility and reuse of standard CDS/authorizations.
   3. Is this a side-by-side ABAP Cloud application consuming S/4 SAP data remotely?
      1. Yes → plan remote consumption (OData / events) and treat S/4 as the system of record.
      2. API design should favor stable contracts, versioning, and clear ownership boundaries.
   4. What is the primary integration style?
      1. Synchronous APIs (OData/REST) → design for latency, retries, idempotency, and throttling.
      2. Asynchronous events (business events / messaging) → design event payloads, ordering, and eventual consistency.
      3. File/batch integration → design staging, reconciliation, and restartability.
   5. What connectivity constraints apply? (important for ABAP Cloud)
      1. ABAP Cloud restricts classic RFC and unreleased APIs.
      2. Prefer released APIs, Communication Arrangements, and Integration Suite patterns when required.
   6. Is there a required integration middleware?
      1. Integration Suite / API Management → plan routing, authentication (OAuth2 client credentials), monitoring, and error handling responsibilities.
   7. What is the transactional consistency requirement across systems?
      1. If you need cross-system consistency, plan a saga-style pattern (compensation) rather than distributed commits.
2. Domain & Business Object Foundation
   1. What real-world business entity does this BO represent?
      1. Transactional document (order, POD, request) vs. master/configuration data changes your numbering strategy, draft need, and locking model fundamentally.
   2. Does this entity have a meaningful lifecycle with discrete statuses?
      1. Yes → you need a state machine, feature control matrix, and status-driven actions.
      2. No → simpler CRUD BO, minimal action design needed.
   3. How deep is the composition hierarchy?
      1. Root only → single-entity BO.
      2. Root + children → plan composition tree and lock dependency before writing CDS.
      3. Root + children + grandchildren → validate that grandchildren genuinely cannot exist outside the parent; if they can, they belong in a separate BO with an association, not a composition.
   4. Is this greenfield or wrapping existing Database tables / legacy data?
      1. Greenfield → UUID primary keys, managed persistence, full framework ownership.
      2. Wrapping legacy → unmanaged or managed + additional save; you lose some framework benefits but gain compatibility with existing data.
   5. Does this Business Object need to coexist with standard SAP business objects (PO, Sales Order, etc.)?
      1. Yes → plan associations to standard CDS views (I_ namespace), consider impact on authorizations inherited from standard objects, and confirm whether standard extensibility (BADI, extension field) is sufficient or a custom BO is genuinely necessary.
3. Persistence Model
   1. Does a legacy API (BAPI, FM, class) own the database writes at commit time?
      1. Yes → Unmanaged or Managed + Additional Save.
      2. No → Managed preferred.
   2. Is the data persisted purely in custom tables under your control?
      1. Yes → Managed.
      2. Managed + Additional Save only if a downstream system must also be triggered at save.
   3. Do you need fine-grained control over every INSERT / UPDATE / DELETE?
      1. Yes → Unmanaged.
      2. In practice this is rare for new developments; prefer managed unless there is a clear technical reason.
   4. Does saving this BO trigger a document in another system (GR posting, FI entry, workflow)?
      1. Yes → Managed + Additional Save.
      2. The save_modified method in the saver class handles the external call.
      3. Plan rollback strategy if the external call fails.
4. Draft Handling
   1. Do users need to save incomplete work and return to it later?
      1. Yes → Draft enabled. Tables must be generated for each entity node.
   2. Is the editing session short-lived (seconds to minutes, single screen)?
      1. Yes → Draft may be unnecessary overhead. Consider no-draft CRUD with immediate save.
   3. Will multiple users ever hand off an in-progress document?
      1. Yes → Draft with administrative draft handling. Plan who can resume or delete another user’s draft.
   4. Is this a background / batch / integration scenario with no human editor?
      1. Yes → No draft. Possibly no UI binding at all — Web API service binding only.
   5. What is the draft expiry and cleanup strategy?
      1. Stale drafts accumulate in draft tables. Plan a periodic cleanup job or use the framework’s draft garbage collection.
5. Numbering
   1. Should a unique business key be assigned at the moment of creation before save?
      1. Yes → Early numbering. Assign in the early numbering handler; key is stable from creation.
   2. Is the business key generated by a number range, external system, or only at commit?
      1. Yes → Late numbering. UUID is the internal key during the draft lifecycle. Semantic key is assigned in adjust_numbers at activation.
      2. The projection must expose the semantic key as the consumer-facing identifier.
   3. Is the primary key purely technical (UUID) with no business meaning?
      1. Acceptable for internal objects but consider whether downstream integrations, reporting, or users need a readable identifier.
      2. If yes, add a separate human-readable number field even if UUID is the key.
   4. Are child entity keys meaningful (e.g. line item 10, 20, 30) or technical?
      1. Line number semantics → plan the numbering determination for child nodes.
      2. Technical child keys → UUID, simpler but less readable in error messages and APIs.
6. CDS View Layer
   1. What is the intended CDS view stack?
      1. Interface / base view (R_ namespace or I_ prefix convention)
         1. Sits directly on the database table.
         2. Contains all fields, associations, compositions.
         3. No UI annotations.
         4. Contract for reuse across consumers.
         5. Never expose directly in a service.
      2. Restricted / behavior view
         1. Often identical to interface view.
         2. May restrict fields from the transactional surface.
         3. Place access control too broad for projection.
      3. Projection view (P_ or C_ namespace)
         1. Consumer-specific selection of fields.
         2. Adds UI annotations.
         3. Redirects associations to projection counterparts.
         4. Defines aliases exposed in OData.
         5. Usually one per consumer scenario.
      4. Metadata extension (MDE)
         1. Carries @UI annotations.
         2. Keeps projection view clean.
   2. Are there multiple consumer scenarios requiring different field sets from the same BO?
      1. Yes → Multiple projection views on the same interface view.
   3. Do any fields require computation that shouldn’t live in the database table?
      1. Yes → Virtual elements in the interface view, implemented in the ABAP handler.
      2. Use sparingly; virtual elements are calculated on every read and do not support filtering/sorting in OData unless explicitly handled.
   4. Are there fields that should be exposed differently in different contexts (e.g. masked for some roles)?
      1. Yes → Handle via separate projections or DCL conditions.
      2. Do not use a single projection and try to conditionally hide fields; OData metadata is static.
   5. Do you need CDS value help views?
      1. Plan a separate VH_ prefixed CDS view for every field that presents a dropdown or F4 help in Fiori Elements.
      2. Each value help view needs @Search.searchable: true and @ObjectModel.resultSet.sizeCategory annotations for performance.
   6. Do you need CDS abstract entities for action parameters or return types?
      1. Any action that takes structured input or returns structured output beyond $self needs an abstract entity.
      2. Plan these upfront; they are part of the public API contract.
   7. Are there analytical or reporting consumers of this data?
      1. Yes → Plan a separate analytical projection with @Analytics annotations and cube/dimension CDS view types.
      2. Transactional and analytical projections should not be mixed.
7. Actions, Functions & Operations
   1. Map every user-initiated transition on your state machine to an action type:
      1. Instance action → operates on one selected record (most common).
      2. Static action → no record context (mass import, generate from template).
      3. Factory action → creates a new instance, optionally copying from a source record.
      4. Function → read-only operation returning data without side effects.
   2. Are there actions that need structured input beyond the record itself?
      1. Yes → define a CDS abstract entity as the action parameter.
   3. Are there actions that need to return structured data beyond the modified record?
      1. Yes → define a return abstract entity.
      2. Plan how Fiori Elements handles the return (result table, message, navigation).
   4. Which actions need to work on multiple selected records simultaneously?
      1. These are mass-enabled actions.
      2. Handler must use FOR ALL ENTITIES and process in bulk.
      3. A single-instance handler promoted to mass action without refactoring is a performance risk.
   5. Are there read-only queries that Fiori Elements needs to call without modifying state?
      1. Yes → OData functions exposed as RAP functions in the behavior definition.
      2. Examples: checkAvailability, calculateTotalsPreview, validateExternalReference.
8. Performance
   1. What is the expected data volume per BO instance (number of child records)?
      1. Under 100 items → standard expand is fine.
      2. Over 500 items → plan server-side pagination for child collections.
      3. Over 10,000 items → reconsider whether composition is the right model.
   2. Are all determination and validation handlers written for bulk processing?
      1. Use FOR ALL ENTITIES.
      2. Collect results instead of per-instance loops.
   3. Are virtual elements used?
      1. Every virtual element is calculated on every read request.
      2. Cannot be filtered/sorted in OData without additional implementation.
      3. Use sparingly; document cost.
   4. Are there database reads in on-modify handlers?
      1. Handlers fire on every field change.
      2. Minimise DB reads.
      3. Use transient fields to cache results.
9. Extensibility
   1. Will this BO need to be extended by customers or partners (if building a product)?
      1. Yes → plan extension includes in the behavior definition from the start.
      2. Extension points must be declared; retrofitting requires a release upgrade.
   2. Are there side-by-side extension scenarios on BTP?
      1. Yes → ensure the BO raises events that the extension can subscribe to.
      2. Event payload must carry enough context for the extension to act without calling back into the core.
   3. Is this BO a candidate for inclusion in a RAP facade (releasing as an API)?
      1. Yes → interface view and behavior definition must be C1-released.
      2. Plan the release contract early; breaking changes require deprecation cycles.
10. Validations & Determinations
    1. Classify every business rule by trigger type:
       1. On-modify field trigger → fires when a specific field changes during editing.
          1. Use for immediate user feedback (format check, range check).
          2. Keep lightweight; fires frequently.
       2. On-modify create/update/delete trigger → fires on structural changes.
          1. Use for cross-field derivations.
       3. On-save → fires before commit, after all on-modify processing.
          1. Use for invariants that must hold at persistence time.
       4. On action → fires when an action is executed.
          1. Use for preconditions that only matter at that transition point.
    2. Are there cross-entity validations (e.g. header total must match sum of items)?
       1. Yes → place at the root entity level.
       2. Validation accesses child data via EML (e.g. READ ENTITIES ... BY \\\\_Child). Plan the navigation path.
    3. Are there expensive validations requiring external API calls?
       1. Minimise these.
       2. Avoid calling external APIs on every keystroke.
       3. Consider caching in transient fields, or moving the check to on-save only.
    4. What is your warning vs. error strategy?
       1. ABAP RAP validations natively support only error severity.
       2. Warnings require a confirmation pattern: a dedicated action the user must explicitly trigger to acknowledge the warning state.
    5. Which fields auto-derive their value from other fields or master data?
       1. Each becomes a determination.
       2. Be explicit whether it runs on-modify (real-time derivation) or on-save (final calculation).
       3. Determinations that read master data should cache where possible.
11. OData Service Design
    1. What service binding type is required?
       1. UI (OData V4) → Fiori Elements transactional UI.
       2. Web API (OData V4) → headless API consumption (integration, mobile, etc.).
       3. OData V2 UI → legacy; avoid for new development unless required.
    2. Should the Fiori UI and the integration API share the same service binding?
       1. No → separate service bindings on separate projection views.
       2. UI projection: @UI annotations, draft exposure, Fiori-specific ordering.
       3. API projection: clean names, no draft actions, may expose different fields.
    3. What OData entity set names will be exposed?
       1. Entity set names come from projection view alias.
       2. Plan meaningful names for API consumers (e.g. DeliveryPODs).
    4. Which navigation properties need to be enabled in the service?
       1. Include only associations a consumer will genuinely navigate.
       2. Over-exposing associations increases payload and security surface.
    5. Are there $expand requirements from Fiori Elements?
       1. Object Pages often auto-expand child entities.
       2. Ensure the projection composition tree supports the required expand depth.
       3. Deep expands on large datasets are a performance risk; plan pagination for child collections.
    6. Does the API need to support $filter, $orderby, and $search on specific fields?
       1. Control via CDS annotations like @Search.defaultSearchElement and @ObjectModel.filter.transformedFilter.
       2. Plan filterable/searchable fields at the projection level.
    7. Do you need a separate count service or batch capabilities?
       1. OData V4 supports $count and $batch natively.
       2. Plan whether consumers will use batch and whether actions behave correctly in batch context.
    8. Are there custom headers, ETags, or caching requirements?
       1. ETags are managed via last_changed_at fields.
       2. Plan an ETag field on every entity node; required for optimistic locking in API consumers.
12. Fiori UX
    1. What Fiori Elements floorplan is required per use case?
       1. List Report + Object Page
       2. Worklist
       3. Overview Page
       4. Form Entry
    2. What fields appear in the List Report table?
       1. Map to @UI.lineItem on the projection.
       2. Plan column priority for responsive tables.
       3. Decide visible vs available columns.
    3. What filter fields appear in the Filter Bar?
       1. Map to @UI.selectionField.
       2. Align with how users actually search.
    4. What is the Object Page structure?
       1. Map sections/subsections to @UI.facets.
       2. Child compositions become table facets.
       3. Header fields map to @UI.headerInfo and @UI.headerFacets.
       4. Plan layout with UX before annotating.
    5. Are there smart controls needed (charts, micro-charts, progress indicators, rating)?
       1. Requires specific @UI.dataPoint and @UI.chart annotations.
       2. Plan field type and max/reference values.
    6. Are there side effects (refreshing related parts of the UI after an action)?
       1. Declared in behavior definition with @Sideeffects on the projection.
       2. Missing declarations cause stale UI after actions.
    7. Are there field groups needed for different display contexts?
       1. @UI.fieldGroup controls grouping within Object Page sections.
       2. Plan groupings to match the business mental model.
13. Authorization
    1. What authorization objects govern access to this BO?
       1. List every authorization object.
       2. Reuse standard objects where applicable.
       3. Define custom objects now, not retrofitted.
    2. Is row-level restriction needed?
       1. Yes → DCL (Data Control Language) access control on the interface view.
       2. Plan DCL using authorization-relevant fields (plant, company code, cost center).
       3. DCL affects all consumers of the view; design it at the interface layer.
    3. Are there operation-specific authorization checks (e.g. only a supervisor can approve)?
       1. Yes → authorization checks in behavior implementation (usually in action handler or dedicated method).
       2. Combine with feature control so unauthorized actions are also visually suppressed.
    4. Is #NOT_REQUIRED ever acceptable?
       1. Only for internal or integration-only BOs where the service is not exposed to end users.
       2. Never for a UI-facing BO.
       3. Flag every #NOT_REQUIRED as security debt.
    5. Does the BO need privileged access for internal framework operations?
       1. WITH PRIVILEGED ACCESS in EML is appropriate only for framework-internal calls.
       2. Document every usage; misuse is a security risk.
14. Feature Control
    1. Which operations (create, update, delete) should be restricted by status?
       1. Map each operation against each status in a matrix (dynamic feature control spec).
    2. Which individual fields should become read-only or hidden in certain statuses?
       1. Field-level feature control.
       2. Every field that changes editability by status must be declared in the feature control handler.
    3. Are there actions that should be invisible (not just disabled) in certain statuses?
       1. Feature control can hide or disable.
       2. Confirm with UX whether hidden vs disabled is preferred.
    4. Is feature control purely status-driven or does it also depend on user role?
       1. Role-based feature control combines authorization checks with feature control logic.
       2. Do not try to implement role-based field visibility purely through feature control.
       3. Use authorization and separate projections for structurally different role experiences.
15. Integration
    1. Does this Business Object call external APIs?
       1. Synchronous in action/determination → keep calls short.
       2. Move long-running calls to a fire-and-forget pattern using RAP business events or a separate integration flow.
    2. Does this BO publish events for downstream consumers?
       1. Plan RAP Business Events in the behavior definition.
       2. Define event name and payload (abstract entity).
       3. Define which transitions raise the event.
       4. Raise events via RAISE ENTITY EVENT in behavior implementation.
    3. Are there inbound integration scenarios (external system creating/updating this BO)?
       1. Web API service binding is the right surface.
       2. Plan whether external system uses CRUD, actions, or integration-optimised actions.
    4. Is Integration Suite involved as a mediator?
       1. Yes → plan the iFlow contract: payload shape, entity set, authentication (OAuth2 client credentials, basic auth via communication arrangement).
       2. Web API projection becomes the iFlow target.
    5. Are there RFC / BAPI calls to on-premise systems?
       1. In ABAP Cloud (public cloud) RFC is restricted.
       2. Use released APIs only.
       3. If the required FM is not released, raise an extensibility request or route via Integration Suite using an on-premise connector.
    6. Do we need to connect to other systems? SBPA or Integration Suite
       1. Setup desiinations in BTP
       2. Build Communication Scenarios, Systems & Users
       3. Link to OData Action Projects
16. Built by Warren Eiserman
    1. https://www.linkedin.com/in/warrenei
    2. https://medium.com/@warren_eiserman