Creating New Entities through an OData Model

The OData V4 model sends requests in the following cases:

• Implicit read requests to retrieve data for a binding

  For example, a list binding with the absolute path /UX_Customer triggers a GET UX_Customer to read data.

• Implicit update requests via two-way binding

  For example, update a customer’s name through a property binding with the relative path CustomerName, which has a context with path /UX_Customer(00505604-4e85-1edd-818f-21e64b9cd2cf) triggering PATCH UX_Customer(00505604-4e85-1edd-818f-21e64b9cd2cf) with the customer name's value as JSON payload.

• Explicit requests triggered through API calls like ODataListBinding.refresh() or ODataContextBinding.execute()

For each of these cases, it is possible to specify a Group ID of type string that allows you to group multiple operations into a single HTTP request payload (batch request).

I.e. the OData model's use of batch requests is controlled by such Group IDs. For this purpose a Group ID has one of the following submit modes:

• sap.ui.model.odata.v4.SubmitMode.API
• sap.ui.model.odata.v4.SubmitMode.Auto
• sap.ui.model.odata.v4.SubmitMode.Direct

The following figure shows the valid Group IDs in SAPUI5 and explains their corresponding submit modes.

In the example shown in the figure, Usage of Group IDs in XML Views, the binding context of the form is set to /UX_Customer(00505604-4e85-1edd-818f-21e64b9cd2cf) via the binding attribute of the <SimpleForm> tag. In addition, the Group ID for read and update requests is set to $direct ($$updateGroupId and $$groupId parameters). Therefore, the data for the form, that is, name and city of the customer with Id 00505604-4e85-1edd-818f-21e64b9cd2cf, is read directly without batch. Likewise, updates for the name and the city through two-way binding are sent directly without batch.

The default for the Group ID of the OData model is $auto. The value of Group ID is used as default for the Update Group ID of the OData model.

On instantiation of the OData model, you can also provide both a Group ID and an Update Group ID; if specified, these values are used as defaults if the corresponding binding parameters are not explicitly set.

For explicit requests, the Group ID can be specified as an optional parameter to the corresponding API method. The Group ID or Update Group ID of the binding is used as a default.

This is some more information about OData Deep Inserts:

• Complex business data is often hierarchical. Sometimes data can only be created or updated with the full hierarchy.

• For example, Sales Orders and Sales Order Line Items; they are often created in the backend system at the same time in a single transaction, not created independently.

• OData and SAPUI5 support the creation of this hierarchical data, known as Deep Insert.

• SAP NW Gateway systems support Deep Insert using the following method, CREATE_DEEP_ENTITY.

To provide a deep insert, it is necessary to implement a method on the SAP NetWeaver Gateway with the name, CREATE_DEEP_ENTITY.

This figure shows a code example for a Deep Insert.

• A Deep Insert is basically the opposite of an OData Query that uses $expand to retrieve an entity and related associations in a single call.

• Sample GET call response to a SalesOrdercollection expanding Items that contains the line item data - see the figure, OData Deep Inserts - OData Structure, Example, above.

• Notice ID and GrossAmount at the header level.

• "Items" contains an array of line item objects.

• A Deep Insert is the same thing in reverse, the nested structure is the body of the HTTP POST.

• Sample POST call body to a SalesOrder collection, including Items that contain the line item data (see figure above).

• The structure is very similar to the response from the previous GET call.

• Items contain an array of line item objects.

mParameters: An optional parameter map that contains any of the following properties:

• context: If specified , sPath has to be relative to the path given with the context.

• success: A callback function which is called when the data has been successfully retrieved. The handler can have the following parameters: oData and response. The oData parameter contains the data of the newly created entry if it is provided by the backend. The response parameter contains information about the response of the request.

• error: A callback function which is called when the request failed. The handler can have the parameter oError which contains additional error information.

• urlParameters: A map containing the parameters that will be passed as query strings.

• headers: A map of headers for this request.

• batchGroupId: Deprecated - use groupId instead.

• groupId ID of a request group; requests belonging to the same group will be bundled in one batch request.

• changeSetId: ID of the ChangeSet that this request should belong to.

• refreshAfterChange: Defines whether to update all bindings after submitting this change operation. See setRefreshAfterChange If given, this overrules the model-wide refreshAfterChange flag for this operation only.