4
votes

I'm quite new to the Odata topic and try to understand what is the best practice scenario when working with OData service.

Sceanrio 1:

I have an complex application with several EntitySets coming from an remote Odata model, which is loaded from SAP Backend. I can read data and bind it to UI controls, thats not the problem, but what I am confused about is how I can/should write back data to the backend.

First assumption Odata is One-Way Binding:

The user manipulates inputFields , dropdowns ,tables and so on, and all data is writen to the Odata Model with createEntry() or setProperty(). Right? Or should i use another JSONModel and collect all user changes ?

Question : How do i transfer now this changes made on the Odata model to backend ? What is the best practive I have read something about batchprocessing or having an own service and trigger this one with the create() function ? Can someone just give some hints or some kind of a recipe.

Sceanrio 2:

Odata in Two-Way Binding ?

How does that work ? Which prerequisite must the backend provide in the OdataServices ? I read something that it's experimental.

YOu see I'm quite a little bit confused.

1

1 Answers

13
votes

It's important to know what you will be getting if you use one-way or two-way binding. None of these binding actually involve writing data back to the back-end OData service.

In short:

  • One-way binding means that the model (e.g. ODataModel) only keeps your UI controls in sync. Changes made to the model, will also be cascaded to the UI controls bound to the model. However, when you change values in your UI controls, the updated value will not automatically be written back to the model.
  • Two-way binding means that the model keeps your UI in sync (similar to one-way binding), but on top of that, changes in your UI controls will also cascade back to the model. Two-way binding

In the one-way model, you would indeed need to programmatically update the model using createEntry and setProperty methods. Using two-way binding, this will be done automatically for you.

If you want changes to your model to be written back to your OData service on the server, you could run the 'submitChanges' method. This method will look at all changes made in the ODataModel and will send corresponding OData requests to the server to synchronise the changes with the back-end.

To make sure this is done in a consistent fashion, the ODataModel will wrap the required changes into a so-called change-set. The back-end then knows which requests belong together and will be able to roll-back all changes in a change-set whenever one of the changes fails. In ABAP you would call this a logical unit of work (LUW).

Because it may be necessary to send multiple requests to the server (e.g. if the change set change multiple entities), the ODataModel (v2) groups as many requests as possible in one batch. When this is switched on (which is the default), only one request is sent to the server instead of multiple requests, which increases performance. It would be advisable to only switch batching off for debugging purposes.

Please note that two way binding in sap.ui.model.odata.ODataModel used to be experimental, but please don't use that class anymore as it's old. Use sap.ui.model.odata.v2.ODataModel instead, as it is way better and supports lots more OData features (such as batches and two-way binding).

That's actually multiple answers in one, but I hope it clarifies some of the confusion.