Show TOC

Batch ControlLocate this document in the navigation structure

OData V4 allows you to group multiple operations into a single HTTP request payload, as described in the official OData V4 specification Part 1, Batch Requests (see the link under Related Information for more details).

The OData V4 model sends requests in the following cases:

  • Implicit read requests to retrieve data for a binding

    Example: A list binding with the absolute path /SalesOrderList triggers a GET SalesOrderList to read data.

  • Implicit update requests via two-way binding

    Example: Update a sales order's note through a property binding with the relative path Note, which has a context with path /SalesOrderList(SalesOrderID='42') triggering PATCH SalesOrderList(SalesOrderID='42') with the note'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. Except for the group ID "$direct", requests created for the same group ID are grouped in one batch request. The following group IDs can be used:

  • "$auto": Predefined batch group ID which is the default if no group ID is specified. With this group ID, the batch request containing the associated requests is sent automatically before rendering.

  • "$direct": Predefined batch group ID which "switches off" batch; the request is sent directly as a single request, not via OData batch. For more information, see Performance Aspects.

  • An application group ID which is a non-empty string consisting of alphanumeric characters from the basic Latin alphabet, including the underscore. Use the ODataModel.submitBatch API with this group ID as a parameter to send the batch request which bundles the associated requests. For more information, see the ODataModel.submitBatch API documentation in the Demo Kit.

To specify the group ID for implicit requests, use the parameters $$groupId (group ID for read requests) and $$updateGroupId (group ID for update requests) for the binding which triggers the request (see the ODataModel.bindList, ODataModel.bindContext and ODataModel.bindProperty API documentation).

Code example: Updates for the sales order note through two-way binding will use the group ID "myGroup", whereas data is read with the group "$auto".

Batch group usage for binding created via JavaScript:

sap.ui.define(["sap/ui/model/odata/v4/ODataModel"], function (ODataModel) {
    var oModel = new ODataModel({serviceUrl : "/myService/", synchronizationMode : "None"}),
        oContextBinding = oModel.bindContext("/SalesOrderList(SalesOrderID='42')", /*oContext*/ undefined, {$$updateGroupId : "myGroup"}), 
        oPropertyBinding = oModel.bindProperty("Note", oContextBinding.getBoundContext());
});

XML view sample: Declares controls which create the context binding (in the SimpleForm) and the property binding (in the Input) as sketched in the above JavaScript code sample.

Batch group usage for bindings created via XML view:

<form:SimpleForm binding="{path : '/SalesOrderList(SalesOrderID=\'42\')', parameters : {$$updateGroupId : 'myGroup'}}" editable="true" ...>
    <Label labelFor="Note" text="Note" /> 
    <Input id="Note" value="{Note}" />
    ...
</form:SimpleForm>

On instantiation of an OData V4 model, you can provide both a group ID and an update group ID; they are used as defaults if the corresponding binding parameter is not specified. The default for the group ID is "$auto". The value of group ID is used as a default for the update group ID.

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. For more information, see the ODataContextBinding.execute, ODataContextBinding.refresh, ODataListBinding.refresh, ODataPropertyBinding.refresh and ODataPropertyBinding.setValue API documentation in the Demo Kit.

Change Sets and Order of Requests Inside a Batch Request

The OData V4 model automatically puts all non-GET requests into a single change set, which is located at the beginning of a batch request. All GET requests are put after it. If there is only a single request within the change set, it is replaced by that single request when submitting the batch group (saves overhead on the wire). Adjacent PATCH requests for the same entity are merged into a single request. No additional reordering takes place.

Resetting Property Changes

You can set an update group ID for a binding so that property changes are collected in a batch queue. The ODataModel.submitBatch method sends all these changes for a given batch group at once and the ODataModel.resetChanges method resets the changes. With these methods, you can, for example, implement a Save and a Cancel button for a form: Save triggers submitBatch, and Cancel triggers resetChanges.

Note The resetChanges method only resets all implicit update requests via two-way binding for the given group, while read requests or requests from ODataContextBinding.execute remain in the queue and are sent when the submitBatch method is called.

The list and context binding also offer the resetChanges method which resets changes for the binding and its child bindings.

Example: View

<Toolbar design="Transparent">
    <content>
        <Button icon="sap-icon://save" press="onSaveSalesOrder"/>
        <Button icon="sap-icon://sys-cancel-2" press="onCancelSalesOrder"/>
    </content>
</Toolbar>
<form:SimpleForm binding="{path: '/SalesOrderList(ID=\'42\')', $$updateGroupId: 'SalesOrderUpdateGroup'}">
    <Label text="Sales Order ID" />
    <Text text="{SalesOrderID}" />
    <Label labelFor="Note" text="Note" />
    <Input id="Note" value="{Note}" />
</form:SimpleForm>

Example: Controller

onCancelSalesOrder : function (oEvent) {
    this.getView().getModel().resetChanges("SalesOrderUpdateGroup");
},

onSaveSalesOrder : function (oEvent) {
    this.getView().getModel().submitBatch("SalesOrderUpdateGroup");
},
Related Information