Introduction
One of the issues we are seeing in mobile is that there is a move to frequently but not always connected applications. Unfortunately there there is a knowledge gap not just around online vs offline vs cached implementations but also the impact of choosing the wrong one for a project. I have seen a number of projects where the data requirements have not been articulated well and what was required was an offline model but in fact a caching and online model was developed leading to greatly reduced partner, customer and user expectations. It is vital then the online, caching and offline models are clearly understood before embarking on an enterprise mobile project. This is true for both the Hybrid and for Native applications as it is the data being transferred that is the key here, not the device or SDK.
Three models have been identified that developers can choose from, each of which has an increasingly high tolerance for the absence of connectivity. The models are Online, Offline and Frequently Connected.
When thinking about your application it is best to not think of the entire application but just focus on the data layer. This is the one that sends and receives oData from the remote server. This is where the logic of the offline vs online implementation will reside and this is the layer we will look at to decide the best way to provide an experience your users will engage with.
A normal HTML application will have the HTML created on the server and then uploaded to the client. In recent years there has been a move to the REST based model for API development. Here the developer exposes an API for consumption by third parties and the javascript application on the device consumes these API’s and renders the content on the client. If the existing architecture is not already architected to use REST based API’s (and of course oData is a REST based API by design) then the backend will be required to be re-engineered to expose an API. In all these solutions being discussed it is assumed that the data is being exposed as oData already.
Often the backend data is locked in behind a firewall and a DMZ so protect the enterprise data from hackers. To expose the data to be consumed by mobile applications either the SAP Cloud connector is used on premise to connect to the HCP Tenant instance and the tenant manages the mobile device connections through the HCP Mobile Services service or if the on premise version of the SAP Mobile Platform is being used then the SAP Relay Server needs to be installed in the DMZ in order to allow connections from devices to get to the backend SMP on premise server.
Online
The online model is best thought of as a browser application. By definition the online application are generally HTML based applications as all the logic and code need to be downloaded from the server each time the user access the application/URL. The oData calls are expected to execute immediately and a response obtained immediately so a network connection always needs to be present. Often overlooked is the bandwidth of the device. If the user is connecting over a 2G or HSDPA connection and the amount of data to transfer is very large then the user experience will be poor. This is why it is often preferable to try to cache large infrequently changed files on the device rather than downloading them every time. SAP have done this with the Fiori client that adds sophisticated caching to the Fiori application to make the user experience better over a high latency low bandwidth connection. This model though is very easy to develop for and quick to get to market but its downside is that performance on mobile devices (including tablets) can be less than optimal.
Offline
The opposite to the online model is the offline model. This model is traditionally implemented as a native application, though recently it is also a more towards using so called Hybrid applications which are applications developed using HTML such as SAPUI5 and then wrapped in a native wrapper using platforms such as Cordova or PhoneGap. Cordova and PhoneGap help bridge the gap between developing in native code on each platform and developing in HTML and sacrificing access to device specific native functionality. Typically the application will need to be able to create transactions and store large databases then provide an API to access these whilst offline. SAP provides an SDK for both Native and for Hybrid applications that make it easy to develop offline line applications but there are some caveats that need to be born in mind.
The first of which is that the data on the server needs to be easily partitioned so that a subset of the entire database can be downloaded to an individuals device. This could be the list of customers in an area the salesperson is going to visit or it could be a WorkList for the current week. Backend servers have access to huge databases that it will not be possible to replicate to the device.
The second issue is that the oData provider should support both oData Delta Tokens and oData Skip Tokens. The Skip and Delta Token functionality was added to oData to provide an optimal replication scenario. Delta tokens provide a mechanism to report to the caller the list of changes that have occurred on the collection since the caller last queried the collection. Each time the caller queries the collection they will receive a checkpoint token. When they query the collection again and supply the token they will get back the changes since the last token and a new token. Obviously if the table changes infrequently or there are not a lot of changes on the table then this is a highly optimised replication strategy. Skip tokens on the other hand provide a mechanism to break up large collections into chunks. If the collection is extremely large then the client may be unable to process it all at once and so by providing a skip token the client can process the collection in batches.
Frequently Connected
I strategy that can work for non essential application is to have the application cache as much oData as possible through the use of the SAP oData SDK Technical Cache. Whilst it is possible to do this type of caching in other SDK’s (Angular being the one that springs to mind) the SAP Native SDK provides the so called technical cache to cache data so that calls to the backend can return the last successful query when the device does not have a network connection. Of course if there is no network connection then for a good user experience the developer should disable those functions that cannot be used such as creating new records.
Of course the technical cannot be used with the offline store since they are mutually exclusive, however in the case where the backend already exposes the services as oData then the use of the technical cache can help the native application get to market quicker than doing a full offline application where the backend might need to be redesigned to enable data partitioning.
In Summary
We have looked at the three types of data models for applications.
Online:
Always on application model that is run from the browser and largely independent of operating system.
Restrictions
- Must be always connected
- Slow startup
- Source code always downloaded
- Sometimes the HTML is created on the server and there is no API
Benefits
- Easiest development cycle
- Fastest to market
- Widest platform support
- Always up to date
Offline
A Disconnected application model. User perception is this is a true application, working when they need it to work even in the absence of a network connection.
Restrictions
- Complex to code
- Limited operating systems support
- Deploy via app store
- Backend infrastructure required
Benefits
- User can work in disconnected environments
- User can work in frequently connected environments
- Application can access native facilities on the device
- Can use Enterprise Plugins to improve integration (e.g. Kapsel)
Frequently Connected
A partially disconnected model where the some oData calls are cached so the user has the perception of working online even if they are not connected.
Restrictions
- Cannot run in conjunction with the offline scenario in SAP SDK apps
- If using SAP SDK then native solution only
- Technical cache architecture also available in other SDKs such as Angular
- User will not be able to do some operations on device such as creating new records
Benefits
- Provide some offline functionality when the data connection is bad
- Simpler than full offline to deploy and manage
- No backend changes required
Final Comments
For a Proof of Concept with a new application it is best to start off with the Online model and SAPUI5, this will see if the idea for the application is feasible. Getting an application up and running can be a valuable proof point to see if users accept the design and workflow of the application.
If the users accept the application but require the application to function offline because for example they are working underground or in a mobile blackspot then the more complex work which will typically involve changes to the backend as well can be started. The changes on the backend will generally not affect the existing application.
With support for extracting subsets of data, delta token and possibly skip token support implemented on the backend services, offline support can be added to the application. If it is designed and developed in SAP UI5 then this is normally an easy affair to get integrated.
