Skip to Content

Building offline native apps with Gateway and LBO’s

I’m not sure if this approach has been done before, but when searching SCN for LBO it only returned 11 results for my search, and none of them covering the use of LBO’s in this scenario. So I thought I would share this approach that I have been using in native app development to enable offline functionality.

Over the past few months I have been using the Gateway productivity tools for Android native development as a means to get started with consuming Netweaver Gateway OData services. The tool is a great way to accelerate the development of native apps, however given that OData does not currently support offline capability (although apparently this will be possible soon, according to SAP) it is only really useful for online apps at this point in time. Which can be expensive on bandwidth if the same data needs to constantly be downloaded every time the user accesses the app. Although the OData SDK does currently have persistence capabilities, it seems rather basic and not suitable for more complex requirements. 

Initially I went down the path of creating MBO’s which consumed the Gateway REST services, which worked however performance didn’t seem great. Also it felt as if by doing this, I lost all the benefits of using the OData SDK.

I initially considered the idea of creating my own sql lite database in the app, but due to the manual effort required to do that on each mobile platform, I started exploring the idea of using Local Business Objects (LBO’s).

Local Business Objects are also created in the SAP Mobile SDK eclipse development environment, in a similar way to creating MBO’s except they are not bound to a backend datasource. This means that all attributes need to be created manually. Once created they do not need to be deployed to the SAP Mobile Platform as you would do with MBO’s. The Object API code can be generated for the chosen platform: Android, iOS, Blackberry, etc. The code can then be copied into your IDE, whether it be eclipse or xcode and you can start using almost all of the features of the Object API,  excluding synchronization as they LBO’s are not deployed on the SAP Mobile Platform server and are purely used for persisting the data for offline capability.

I thought I would list what I thought are the advantages and disadvantages of using this approach:


  • Relational Database designed centrally and can be deployed to multiple mobile platforms such as Android, iOS etc.
  • Easy to use Graphical Database design tool (SAP/Sybase Mobile SDK)
  • Benefits of using the Object API excluding synchronization
  • No need to deal directly with SQL statements in native code as Object API generates all the entity classes and query methods
  • Easy generation of CRUD (Create, Read, Update and Delete) methods and any custom queries can also be easily defined in LBO in SAP Mobile SDK
  • Benefits of encrypted UltraLite Database
  • Can be used with or without SAP Mobile Platform


  • Requires manual coding to map from ODP Entities to Object API Entities
  • Requires manual handling of delta query. This can be handled on the server side, by passing through a filter such as a last updated datetime stamp. Or alternatively using the OData Delta Query Support (Which I have not tried myself yet)
  • May not strictly stick to REST principals
  • Requires slightly manual means of dealing with links
  • Requires manual method of dealing with pending operations

I am by no means saying that this is the ideal or even best way to deal with offline scenarios, but I am just putting it out there as an idea of a possible approach to it. In fact once SAP do introduce offline capability into the OData SDK this approach will most likely become redundant.

I would be interested to hear how others have dealt with offline scenarios in native apps while using Netweaver Gateway, as well as any criticism, recommendations or alternative approaches.

You must be Logged on to comment or reply to a post.
  • hi,

    nice information. this scenario is entirely new to me. well done.

    if possible, please share some snapshots of the small app(using NWGW+LBO), would be really helpful.



    • Hi Jitendra,

      Thanks for the feedback, I will put together another blog with a basic demo. I will try get to that later this week. But in the mean time happy to answer any questions you may have.



  • Hi Brad,

    I would be interested to hear how others have dealt with offline scenarios in native apps while using Netweaver Gateway

    I built a couple of Android applications which have used Content Providers (SQLite and File) for persisting data from Gateway services. For syncing the data i have used a combination of Push and Pull.

    For the Push I used the Subscription and Notification Flow feature with C2DM/GCM, the apps would receive notification of changes to the subscribed entities and trigger a pull to refresh for the entity or collection, at the time i extended this feature to add a scheduled push sync from the back-end, it looks like the code has improved a lot since then and now supports payload pushes and pull scenarios.

    For the Pull i used the deltatoken functionality as you mentioned, you can easily do this with queries using stored ‘lastChanged’ and ‘deleted’ properties on the persisted data. 

    When designing these applications i wanted to keep the client as thin as possible, the services manage the conflicts and constraints and take advantage of ETags and Cache HTTP headers. 


    John P  

    Update: good presentation goes into best practices of developing RESTful Android apps, some good patterns for managing transitional states of the data

    • Hi John,

      Thanks for your input. Interesting to hear how others have done it.

      While reading through the delta query support I noticed the following constraint: “Deleted records are not supported at present” – this was one of the main reasons I opted to handle the delta query manually in my case.

      The approach of using Delta Query Support and ETags would require development in the backend on the Gateway service, which is probably a better approach when developing custom Gateway services. However since I was using a SAP std Gateway service and did not want to redefine it to customise it I went with handling all of this on the client side, but I definately agree with you about keeping the client as thin as possible and handling as much in the Gateway service as possible.

      Also going to look into the Subscription and Notification Flow features more.

      Thanks for the link to the google I/O session…..looks interesting.



      • Hi Brad

        I saw that the “Deleted records are not supported at present”, SAP introduced this feature early, in ODATA v4 the delta query protocol has just been adopted and uses the property odata.kind=”deletedEntry” this makes it obvious to the client that the entry or link is a Tombstone. The issue i had with the deltatoken feature wasn’t so much deleted entries, but finding an ODATA client library which supported it.

        I guess there is a trade off, if you want to use the back-end functionality as/is you need to put some smarts in the front end, for my mind concurrency is one problem that takes a bit of thought no matter where you manage it.

        The google I/O session is really good and helped a lot, the take-away’s i got were persist early and often before and after service calls and use exponential back offs with your services.

        The concept behind exponential backoff is to gradually make the wait time longer between retries. Eg first time wait 400ms, then 1600ms, then 6400ms etc. you can set a threshold of the number of retries and then determine the action to take when the number is reached, like put in a queue, change processing status or inform the user.

        I found there are many things you need to take into account when calling Gateway services, not just connectivity, but latency, availability and various HTTP error codes from the server etc.


        John P

    • Hi Midhun,

      Yes I do mean offline operations too, however this would be a very manual way of handling it.
      As you know, an operation will only connect to the gateway service while online, so how I have handled it is by checking connectivity.
      If there is a network connection, then proceed to post to the gateway service, if there is no network connection then save the operation contents to a table/LBO which serves as a queue to process later.

      The same will happen if the app is online but is unable to connect to the Gateway server.
      The structure of your “queue” table will depend on your specific requirements.



  • Hi Brad,

    I am really very happy  to offline capability in

    SAP NW Gateway.

    But where we can save the data in gateway?



    • Hi Syam,

      I am not talking about saving the data in gateway.
      I‘m referring to saving the data locally on the device so that it can be viewed offline and does not need to be downloaded everytime the app loads.


    • Syam, offline capability support for NW gateway will only come in future. Brad has given a workaround to do offline capability to the application through the use of LBOs.

      Midhun VP

    • Hi Jeroen,

      Unfortunately I haven’t had a moment to build a demo app. I’m still hoping to do this but probably wont be for another month or 2.

      I’m happy to help and to answer any questions you may have.