OData Batch Requests and Deep Inserts Explained

A batch request is a single HTTP call carrying multiple OData operations, split into one or more changesets. Everything inside one changeset commits or rolls back together; different changesets in the same batch are independent of each other and of any plain GET requests riding alongside them. A deep insert is a different thing entirely: it is the shape of a single create payload, where a root entity's JSON or Atom body contains its dependent entities nested under a navigation property, so the server creates parent and children as one logical operation instead of a create followed by several update-the-association calls. The structural fact that causes most confusion is that a deep insert can be sent as one flat request or as part of a batch changeset referencing newly created entities by content ID, and people assume batching and deep insert are the same mechanism when they are orthogonal: one is about transport atomicity, the other is about payload nesting.

Deep insert is right when the business object is genuinely composed: a sales order and its items, a header and its address, anything the UI presents and saves as one unit. It is wrong when the child entities have independent lifecycles or need their own authorization checks before the parent exists, because a deep create forces them through the parent's create handler. Batching is right whenever the UI must issue several logically related calls in one round trip, most obviously a Fiori Elements list report saving several new rows plus a few updates at once. Batching is the wrong tool when it is used purely to cut HTTP overhead for independent read requests that would be better served by requesting more fields or a wider expand in a single GET, or by proper server-side paging. Reaching for a giant batch of unrelated changesets to avoid several small round trips usually trades one problem for a harder one: a single slow or locked operation now stalls the whole batch response.

Batch requests sit at the protocol layer, above the RAP behavior implementation and below the UI's model layer; the Fiori Elements framework and SAPUI5's OData model construct batches automatically based on how many pending changes exist in the client-side change set. Deep insert sits one layer down from that: once a batch changeset reaches the service, the deep create payload is unpacked by the OData layer and mapped onto RAP create operations through the CDS composition and the associations marked as 'create by association' in the behavior definition. Underneath that, the transactional buffer in the RAP runtime treats the whole deep structure as one save unit. Deep insert supersedes the older pattern of issuing a create for the header, waiting for the response key, then issuing separate creates for each item referencing that key by hand; that pattern still exists for unmanaged scenarios or classic Gateway services without behavior-based composition.

A travel booking business object has a root entity for the travel header and a composition child for bookings. The behavior definition marks the association from travel to booking as usable for deep create, and both entities have their create operations implemented in the behavior pool, with the booking's create handler reading the parent key out of the mapped association rather than expecting it in the payload. In the Fiori Elements object page, a user creates a new travel and adds three booking rows before pressing save. The UI model accumulates all of this as one pending change set and sends a single $batch request containing one changeset, itself containing one deep insert POST for the travel entity whose JSON body has an array of three booking objects nested under the navigation property. The RAP save sequence executes determinations, validations and numbering for travel and its three bookings inside one transaction, and a single combined response comes back, or a single combined rollback if any booking fails validation.

Deep insert and batching are standard OData mechanics and remain fully supported in RAP-based services on S/4HANA; there is nothing here that is deprecated or discouraged under clean core, since both are protocol-level behavior rather than a custom extension technique. The clean-core relevance is indirect: when extending a standard business object to support deep create for a custom child entity, the extension must use the released composition and association extension points rather than modifying the standard behavior definition directly, otherwise the deep create logic breaks on the next upgrade. Classic Gateway-generated services (SEGW) that hand-code deep insert logic in the data provider class carry more upgrade risk than RAP-managed composition, since the RAP framework handles the deep create sequencing generically and the developer only supplies the entity-specific validations and determinations.

This is developer territory for the behavior implementation and association modeling, with architect input on whether a relationship should be modeled as a deep-create composition at all. A clean handover states which associations are enabled for create, whether late numbering is in play, and what the expected batch shape from the UI looks like, so the next developer does not have to reverse-engineer it from a failing Fiori Elements save.

Read the composition and behavior definition pages first, since deep insert only works if the association and create operations are modeled correctly there. Late numbering is directly relevant whenever a deep create needs a database-generated key before the parent row is committed. The OData V2 versus V4 comparison explains protocol-level differences in how deep structures and batch responses are represented. ETag and concurrency control matters once deep insert is followed by deep update on the same composed object.