Show TOC

Instantiating an OData ModelLocate this document in the navigation structure

The OData model enables the binding of controls to data from OData services.

Context

The OData model is a server-side model: the dataset is only available on the server and the client only knows the currently visible rows and fields. Sorting and filtering is done on the server. The client has to send a request to the server to accomplish these tasks. The OData model currently supports OData version 2.0.

Note Be aware of the Same-Origin-Policy security concept which prevents access to backends on different domains or sites.

Procedure

  1. Instantiate the OData model as follows::
    var oModel = new sap.ui.model.odata.ODataModel("http://services.odata.org/Northwind/Northwind.svc/");

    Requests to the service to fetch data are made automatically according to the data bindings defined in the controls.

    The service URL is the first parameter of the constructor. One OData model instance can only cover one OData service. If you need access to multiple services, you have to create multiple instances of the OData model.

  2. You can add additional parameters.

    When using OData services, you can use URL parameters for configuration. SAPUI5 sets most of the required URL parameters automatically according to the data binding. Two options for adding custom parameters to the request exist: URL parameters can be appended to the service URL and a map of parameters can be passed when using bindElement or bindAggregation.

    Additional parameters, which are added to the OData service URL, are included in every request sent to the OData server. This is useful for authentication tokens or general configuration options.

    var oModel = new sap.ui.model.odata.ODataModel("http://myserver/MyService.svc/?custom1=value1&custom2=value2");
  3. For other parameters it makes no sense to include them in every request. These parameters should only be added to specific aggregation or element bindings, for example, $expand or $select. For this, the binding methods can pass a map of parameters, which is then included in all requests for this specific binding. Currently, the ODataModel only supports $expand and $select.
    • To use the $expand parameter see the following snippet below:

      oControl.bindElement("/Category(1)", {expand: "Products"}); 
      
      oTable.bindRows({
          path: "/Products",
          parameters: {expand: "Category"}
      }); 

      In the first example all products of Category(1) are embedded inline in the server response and loaded in one request. In the second example the Category for all Products is embedded inline the response for each product.

    • The $select parameter returns only the specified properties of requested entries.

      oControl.bindElement("/Category(1)", {expand: "Products", select: "Name,ID,Products"}); 
      
      oTable.bindRows({
          path: "/Products",
          parameters: {select: "Name,Category"}
      });

      In the first example the properties Name and ID ofCategory(1) and all properties of the embedded products are returned. In the second example the properties Name and Category are included for each product. The Category property will contain a link to the related Category entry.

  4. Add custom query options.

    You can add custom query options by placing them as a query string in the URL. The name of a query string does not begin with a $ character:

    http://services.odata.org/OData/OData.svc/Products?x=y

    You can also use custom query options as input parameters for service operations. You can specify the custom parameters during aggregation binding as follows:

    oTable.bindRows({path: "/Products", parameters: { custom: { param1: "value1", param2: "value2" } }, template: rowTemplate });

    For bindElement, you can specify custom parameters as follows:

    oTextField.bindElement("/GetProducts", { custom: { "price" : "500" } });
  5. Create virtual entries.

    You can create empty objects for a specified collection name. The application can bind against these objects. By calling the submitChanges function, you can determine the point in time when these objects are persisted in the backend. The application has to trigger this explicitly. Before the objects are persisted in the backend, all created virtual entries are stored in a request queue and can still be removed. The application can choose which properties are included in the created object and may pass own default values for these properties. Otherwise, the property values remain empty.

    Make sure that the collection and properties exist on the OData service and are defined in the metadata document as well. Here is an example:

     
    // create an entry of the Products collection with the specified properties and values
     var oContext = oModel.createEntry("Products",{ID:99,Name:"Product",Description:"new Product",ReleaseDate:new Date(),Price:"10.1",Rating:1});
     // use the returned context for binding against this entry
     oLayout.setBindingContext(oContext);
     oSimpleListBox.addItem(new sap.ui.core.ListItem({text: "Added entry: " + oContext.getPath()}));
     // to delete a created entry from the request queue without persisting it provide the created context to the deleteCreatedEntry function
     oModel.deleteCreatedEntry(oContext);

    The createEntry function returns a context object which can be used to bind against the newly created entry. See the following example for how to write the entries in the request queue to the backend:

    // provide optional success and error functions which are called for each request in the queue
     oModel.submitChanges(fnSuccess, fnError); 

Next Steps

The default binding mode of the OData model is one-way, but as experimental write support is implemented, two-way binding can be enabled. For more information, see OData Write Support.

API Reference: