How to replace an ODataModel by a JSON Model

For local testing and unit testing, you can replace an ODataModel by a JSON model. The semantics of these two models is quite different. For testing, the following differences are relevant.

First, you have to replace the ODataModel by a JSONModel.  The function createAlertListWith2Alerts creates a JSON Model with 2 Alerts.

    this.createAlertListWith2Alerts = function() {

      var aAlerts = {

        “AlertQueries(name’Alerts’)” :

  { Alerts :

                [{      RawKey : “A1”,

                         AlertID : “1”,

                         InvestigationObjectType : “CLAIM_RS”, …

  };

       return new JSONModel(aAlerts);

   };

After the JSONModel has been created, the model can be injected with setModel().

Second, the ODataModel knows keys that the JSON Model does not know. The JSON model is purely string based. E.g. with the following statement a list of alerts shall be bound to items of a list.

    alertList.bindAggregation( “items”, {

      path : “/AlertQueries(name’Alerts’)/Alerts” ,

The name ‘Alerts’ is interpreted by the ODataModel as key for calling a specific query in the backend. Since JSON does not know keys, the JSON data format is as follows: In the JSON data, the name’Alerts’ is part of the attribute name. For the binding to JSON model the path AlertQueries(name’Alerts’) is just a string.

      var aAlerts = {

        “AlertQueries(name’Alerts’)” :

  { Alerts :

                [{ RawKey : “A1”,

                    AlertID : “1”,

                   InvestigationObjectType : “CLAIM_RS”, …

Third, the OData expand parameter is ignored by JSON. But this does not matter. You just have to provide the required parameters in the JSON data.

Fourth, an ODataModel has also a function for reading, synchronizing from the backend and for performing changes on the backend. The JSON model does not have these functions. If the productive code uses these functions (e.g. read), you have to implement the used functions in the JSON model test double. In most cases it is sufficient to implement these functions as empty functions.

This blog post is part of a series, like the following blog post to stay tuned and get updates about more topics around software engineering with SAPUI5 and JavaScript:

http://scn.sap.com/community/developer-center/front-end/blog/2013/12/12/engineering-in-javascript