This blog post summarizes the improvements of the OData V4 model with SAPUI5 versions 1.58, 1.60, and 1.61. A comprehensive documentation of the OData V4 model is available in the SAPUI5 Developer Guide (https://sapui5.hana.ondemand.com/#/topic/5de13cf4dd1f4a3480f7e2eaaee3f5b8).

Message processing (experimental; 1.58 and 1.60)

It is now possible to transport success, information, warning, and error messages for the end user in success and error responses from the OData server to the UI5 client. Messages transported via an OData V4 service response are parsed and reported to the message model. Applications can retrieve the messages and display them in a suitable control, for example in sap.m.MessageView.

See “Server Messages in OData V4 Model” for the detailed description. The Sales Orders sample application demonstrates the message handling.

Deep paths (1.60 and 1.61)

As a consequence of the message implementation, we also had to adapt the handling of paths. With the underlying concept, it makes a difference whether data is accessed with the “deep path” or a shorter path. The “deep path” is the path starting from the root business object to the entity at hand using navigation properties. To this end it must be possible for an application to consequently use deep paths.

With SAPUI5 1.60, the path of a transient context changes to the key predicate path when the new entity is successfully created on the server. The key predicate path can be used for binding the entity elsewhere.

For the calculation of the path for reading data, relative bindings use the path of the context ‘as is’ as of SAPUI5 1.61 instead of the canonical path computed from the context. Similarly, the creation of new entities now uses the deep path.

Improvements when working with update groups with submit mode Auto (1.60 and 1.61)

A serialization of batch requests with changes has been introduced to avoid problems with parallel batch requests. For example, the ETags used in the second batch request may be outdated when this request is getting processed by the server. To this end, batch requests for update groups (with a submit mode different from $direct) are queued per group ID. A batch request with changes is only sent, if the previous batch request for the same group ID is returned and processed. In this case, all submitted changes for that group ID are combined in one batch request; changes associated with different calls to ODataModel.submitBatch use different change sets inside the batch request. See also “Batch Control” in the SAPUI5 Developer Guide.

The patchSent and patchCompleted events have been introduced so that applications can react to the sending and processing of PATCH requests. Both events are fired by ODataContextBinding and ODataListBinding, if they send their own service request:

• The patchSent event is fired when the first PATCH request for this binding is sent to the backend.
• The patchCompleted event is fired when the backend has responded to the last PATCH request for this binding.

See also section “Events for applications” in “Binding Events” in the SAPUI5 Developer Guide.

When saving changes performed by the user directly with an update group with submit mode Auto, it is typically not intended to block the UI for every PATCH request that is sent to the server. To avoid updating the fields on the UI with the entity data sent back in the PATCH response, binding parameter $$patchWithoutSideEffects was introduced for ODataContextBindings. See also ODataModel.bindContext in the SAPUI5 Developer Guide. Note that this feature should be used only if the service returns an ETag header even for “204 No Content” responses (for example, if the “return=minimal” preference is used).

In addition, we introduced sap.ui.model.odata.v4.Context.requestSideEffects with SAPUI5 1.61. This method can be used to specifically reload properties that are known to change in the backend if another property is patched. For example, after entering the ZIP code, the city may be filled accordingly. The method must only be called on the bound context of a context binding, or on the return value context of an operation binding. With SAPUI5 1.61, there is only basic support for :n navigations, that is, the complete context is refreshed. As part of this development, we also enabled sap.ui.model.odata.v4.Context.refresh for contexts of context bindings.

Further improvements

The filter operators sap.ui.model.FilterOperator.NB, sap.ui.model.FilterOperator.NotContains, sap.ui.model.FilterOperator.NotEndsWith, and sap.ui.model.FilterOperator.NotStartsWith introduced with SAPUI5 1.58 are also available with the OData V4 Model as of SAPUI5 1.58.

As of SAPUI5 1.58, we synchronize the entity returned by a bound operation to the binding parameter if the criteria for the return value context are fulfilled, see sap.ui.model.odata.v4.ODataContextBinding.execute, and if the same entity was returned.

As of SAPUI5 1.60, the ValueList annotation may be used instead of the ValueListMapping annotation. Both annotations are part of the SAP Common vocabulary. The ValueList annotation would also be used in local annotation files.

Also as of SAPUI 1.60, it is possible to call sap.ui.model.odata.v4.ODataListBinding.create without specifying initial values and bind the transient context. Properties that are not part of the initial data show the default value from the service metadata on the UI. These default values are not sent to the server with the POST request to create the new entity.

We introduced an automatic refresh of a created entity after the successful POST to the server with SAPUI5 1.54. This automatic refresh can be switched off as of SAPUI5 1.60 using parameter bSkipRefresh of sap.ui.model.odata.v4.ODataListBinding.create.

Previous post: UI5ers Buzz #42

Mathias is Product Owner in SAPUI5 development and he and his team are focusing on the development of the OData V4 Model for SAPUI5 and OpenUI5. Before joining SAPUI5, Mathias worked in various roles for SAP Solution Manager development and the service development of former Active Global Support.