OData V2 Part 2: Deep Insert, Batch and Navigation Design

📌 KEY POINTS
✅ Navigation properties (from associations) let clients read related data: /Header('1')/ToItems or $expand.
✅ Deep insert = POST a header with its items in one request; SEGW implements CREATE_DEEP_ENTITY.
✅ $batch (multipart) with changesets groups writes into one logical unit of work.
⚠️ In SEGW you implement all of this yourself — in RAP V2 bindings the framework does it.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 covered reading V2 services. This part covers relationships and complex writes — where many V2 projects struggle.

━━━━━━━━━━━━━━━━━━━━
▶ 1. NAVIGATION DESIGN

• In the model: Association (Header 1 : n Item) + NavigationProperty (ToItems on Header, ToHeader on Item).
• Clients: /PurchaseRequestSet('4711')/ToItems or ?$expand=ToItems.
• Design rule: model navigation the UI actually needs; avoid huge $expand chains in lists.
• In SEGW, $expand is handled generically (calls item GET_ENTITYSET per header) unless you implement GET_EXPANDED_ENTITYSET for performance.

━━━━━━━━━━━━━━━━━━━━
▶ 2. DEEP INSERT

• Client sends one POST with nested items: { "RequestID": "", "Description": "…", "ToItems": [ { … }, { … } ] }.
• Server (SEGW): redefine /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CREATE_DEEP_ENTITY in the DPC_EXT class; read the nested data with io_data_provider->read_entry_data into a deep structure; create header and items in one call to your business logic; return the created structure.
• RAP V2 binding: deep insert works via the composition automatically.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 3. $BATCH AND CHANGESETS\n• V2 $batch is a multipart/mixed request: read requests outside changesets, write requests inside changesets.
• A changeset should be processed as one LUW: all or nothing.
• SEGW: redefine CHANGESET_BEGIN (accept the changeset, e.g. set cv_defer_mode for deferred processing) and CHANGESET_END (commit). Without this, each operation may commit separately.
• UI5 V2 model sends $batch by default (useBatch: true) and groups changes with deferred groups.

━━━━━━━━━━━━━━━━━━━━
▶ 4. COMMITS IN SEGW
The gateway framework commits at the end of a successful request/changeset. Don't call COMMIT WORK inside CRUD methods; raise /IWBEP/CX_MGW_BUSI_EXCEPTION on errors so the framework rolls back and returns messages.

━━━━━━━━━━━━━━━━━━━━
▶ 5. ETAGS IN V2
Entity types can have an ETag property (e.g. timestamp); clients send If-Match; the framework compares for PUT/MERGE/DELETE.

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

1. Check the Header–Item association and navigation in $metadata.
2. Read with $expand=ToItems.
3. Send a deep insert (code example).
4. For SEGW services: implement CREATE_DEEP_ENTITY and changeset handling as shown.

✅ CHECKPOINT: you can design and implement V2 navigation and complex writes.

A SEGW service accepted header and items in separate calls from a UI5 app. When item creation failed, headers without items remained, and users created them again — leading to duplicates and manual cleanup.
The team implemented CREATE_DEEP_ENTITY with a single business-logic call and proper exception handling, so header and items were created together or not at all. For multi-step edits, changeset handling ensured one commit per changeset. Orphan headers disappeared.

• Creating header and items in separate requests without atomicity.
• COMMIT WORK inside CRUD methods.
• Not raising business exceptions, so errors return as success.
• Relying on generic $expand for large lists (N+1 calls).
• Ignoring changeset handling in SEGW.
• Over-modeling navigation the UI never uses.

• Use deep insert for header-item creation.
• Let the framework commit; raise /IWBEP/CX_MGW_BUSI_EXCEPTION on errors.
• Handle changesets as one LUW.
• Implement expanded entity sets for performance-critical $expand.
• Prefer RAP (even with V2 binding) for new services — the framework handles this.

Questions: "How do you implement deep insert in SEGW?", "What is a changeset?", "How is $expand handled in Gateway?"
Strong answer: deep insert posts header with nested items; SEGW redefines CREATE_DEEP_ENTITY, reads the deep structure via io_data_provider->read_entry_data, calls business logic once and returns er_deep_entity. $batch groups requests; changesets are write units processed as one LUW (CHANGESET_BEGIN/END). $expand is generic unless GET_EXPANDED_ENTITYSET is implemented. RAP V2 bindings do this automatically.