Odata for SAP Mobile: Offline Capabilities Using Delta Queries

What is Offline OData Client SDK?

Offline capabilities using Delta Queries is an emerging concept in SAP and this blog provides an overview of Offline OData client SDK and key implementation aspects of Delta Token functionality.

As of releases 2.x.x., the SUP OData Client SDK was primarily for applications transacting online with live back-end data. However, there was an option provided to temporarily cache or persist small amounts of data for the applications to resume to work seamlessly if there exists any drop in connectivity over a short period of time. Accordingly, starting from SAP Mobile Platform (SMP 3.0), the existing offline capabilities are enhanced further, wherein the application that works online 99% of its running time can now work seamlessly like an offline/online application. The notable difference is that the application can perform changes to the data when there is no connectivity and later those changes can get propagated to the back-end with order respected.

Hence, to ensure that the client SDK performs like a typical offline enabled library, changes were executed not only to incorporate a persistent cache, but also have a request queue to store the change requests (HTTP(s), as OData SDK still deals with REST over HTTPs) in that order in which they were created, when the application was not connected to the desired server. This feature was not supported in SUP versions 2.x.x. The best part here is that all offline capabilities have been included as a part of the client SDK itself with no additional work needed from the server side.

Now, let’s take a typical business case. Let’s assume you have downloaded a large collection of products and we have cached this product list. How can we update it?

In order to take care of this aspect, the Delta Query functionality has been introduced starting from SAP Netweaver Gateway 2.0 SP07.

Overview of Delta Query Support

Delta query protocol defines a pull-model protocol for clients to get changes for a store. Clients can poll the store for changes periodically or as required or capable stores can provide change notifications to the client when changes are available to be pulled.
This delta query is particularly relevant for projects where performance is critical, wherein loading takes place continuously every time, when full payload is not acceptable, say for instance for projects where the client often polls to get the latest data and any updates. Hence, for client and server performance, it can be very helpful to always display the current state in a poll-interaction, but with the lowest overhead on both client and server.

Implementation of Delta Queries & Delta Token functionality
An OData service can implement delta queries. This implies for each GET request to the OData service, the service will responds with the data, along with an additional delta link. This delta link is a combination of an identifier and a timestamp. Next time, whenever the device wants to request data, it will send a GET request including the delta link, wherein the ODataService will respond to only those objects that were new, updated or deleted (according to the timestamp inside the delta link). This way, you will drastically save time for getting the data and also on the device for parsing the data. The response can be merged to the existing data by using the cache object. However, you need to note that the developer of the OData service has to implement this delta query functionality, either by using Delta Exchange Tables (retrieved from the Syclo framework) or by its own (for example, by calling a BAPI, which gets the timestamp as input and returns the corresponding items).

Implementation of Delta Token functionality
OData exposes collection of records as EntitySets. These EntitySets supports varied options like sorting, filtering or paging to reduce the amount of the data that is sent across the wire.

In this context, paging can be considered as a very robust option to minimize the size of the payload and enhance performance. In order to use paging on client side, the OData request need to specify the $skip and $top tokens. If you work with server-driven paging, you need to use the $skiptoken.

However, some applications prefer to use client side caching, instead of paying. In such scenarios, SAP NetWeaver Gateway provides Delta Tokens that enables you to reduce resource consumption on the server and wire, when the same request is sent multiple times from the same client. The OData Delta Token lets clients to use caching when retrieving entity sets.

Accordingly, the client gets only the modified records, once all the initial records are retrieved. Hence, the initial request will return all records and a Delta Token. The consequent request consisting of the exact query options sends the Delta Token from the initial request. The response will then consist only the modified records. However, if no records have been modified, since the initial request, then the response will not contain any records.

There are two main approaches to implement Delta Token functionality such as:

1. Syclo Exchange Framework based approach: It calculates deltas at modification time, wherein the ABAP system tracks relevant changes, as they occur. At request time, the deltas are already prepared, making them available. Though this approach needs higher development efforts, however, it’s more scalable and ensures an optimized overall performance.
2. Delta determination at request time approach: In this type of approach, the system compares old and new states to check which records have been modified/deleted. Here, though the implementation effort is small, it however does not optimize the backend performance. This implies, if you have more records in the full collection, the response time of the request tends to get longer.
However, with both the approaches, the payload of the response is minimized, though the first approach seems to be more prudent, as it ensures optimization of the backend performance.

For more information on Innovapptive’s Portfolio of SAP Certified Mobile Applications, please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.

Data modeling in SAP Gateway for OData Services

Data Model Definition

OData services require a data model definition, referred as model provider class. For client development projects, the development process mandatorily commences with a previously-defined data model, which is outside-in approach. Based on your specific requirements, you can define a data model in the following formats:

• Define new data model
• Import
• Redefine Service
• Include Service

Let’s have a brief overview of each format:

Define new data model

This model offers optimum flexibility, wherein it requires manual definition of individual data model elements and their properties.

What are data model elements?

Within the tree view of the Service Builder, you can use the data model folder structure to create and edit the individual data model elements. The data model consists of various sub-folders for each of the element types as listed below:

• Entity Types
• Complex Types
• Associations
• Entity Sets
• Association Sets
• Function Imports

You can create and define any of the above data elements, directly in the data model folder of your project. Once you create a new model element, it is inserted in the relevant predefined sub-folder within the data model folder.

There are three types of methods for creating a new data model:

• Double click the specific data model element in the data model folder and enter the relevant information.
• Right click the data model folder, click Create and then click the data model element you want to create.
• Expand the data model folder, right click the data model element you want to create and then click Create.

Import

You can use any of the 3 methods to accomplish the import process:

• DDIC structure (ABAP Data Dictionary)
• Data source (RFC/BOR interface)
• Data Model

DDIC structure (ABAP Data Dictionary)

This structure minimizes the time required to create entity and complex types in your data model.
In order to minimize the time required to create complex types and entity types in your data model, SAP NetWeaver Gateway Service Builder provides the Import DDIC structure function that lets you import an existing ABAP (DDIC) structure and later reuse this data to create new complex types and entity types with minimal effort.

You can import the following DDIC structures into the Service Builder:

• Search Help
• Views
• Database tables
• Structures

Data source (RFC/BOR interface)

This lets you to reuse existing remote function calls (RFC)/business object repository (BOR) parameters to create entity types with minimal effort. Hence, you can tap into a multitude of RFCs and business application interfaces (BAPIs) from the BOR. Once you have imported an existing interface definition, you can map the operations from the same RFC or BAPI to get the service operations you require, eliminating the need to write additional ABAP source code.

Data model

It enables you to reuse an existing data model for more than one service. The file import function is incorporated to enable import of data model files, as defined by external model editors such as Visual Studio (edmx files) and metadata file types (xml) into the Service Builder to create a data model. You can import such files into the Service Builder for the 2 types of projects, such as:

• Service with SAP Annotations
• Service with Vocabulary-Based Annotations

You can use this feature in the following scenarios:

• To import a metadata/edmx file for a new project in certain instances where you create a project and import a file.
• To import a metadata/edmx file for an existing project that already has a data model created (re-import).

Redefine service

It lets you redefine existing SAP NetWeaver Gateway services or services created from a framework within your SAP system landscape (Ex: Service Provider Interface (SPI), SAP Business Information Warehouse (BW Query), Generic Interaction Layer (GenIL).

Using the Redefine service, you can reuse the diverse business objects and services, existing in your SAP system landscape. Apart from that, it connects existing service operations, eliminating the need to create an individual service implementation. Accordingly, you can skip the service implementation phase. The Service Builder enables you to redefine both OData services created in NetWeaver Gateway and external services like SPI, BW Query, GenIL that have been created with the help of varied backend frameworks.

Include service

You can use this service to incorporate an existing SAP NetWeaver Gateway service without the need to recreate its data model. For enhanced usage, it lets you integrate one or more existing services in a new service. You can even skip the service implementation phase, if you choose to include one or more existing services.
Including an OData service

At the time of creating an association, there may be instances when you wish to link to an existing model without the necessity to recreating it. In such scenarios, you can use the Including OData Service function to include models in the Service Builder and then create associations using the included models.

Let’s take an example of a purchase order. To create a purchase order, we require list of vendors and products. For the purchase order service, two types of master data are required such as vendor and product. You can utilize the Include Model function, since the vendor and product services already exist, enabling you to reuse them.

If you would like to request a demo of Innovapptive’s SAP Certified Mobile Aplications, please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.

OData: Implementing Multiple Origin Composition in SAP

Multiple Origin Composition (MOC) is a new and an emerging concept in SAP that describes the ability to collect data from different backend systems, integrate them into a single service and update diverse backend systems, while using the same user. Thus a service can be made available for various system aliases. For instance, you could have two identical systems, one that is located in US and one in Japan and accordingly integrate them. You can also use MOC to CREATE calls and the metadata. At present, CREATE calls cannot be processed in all the configured backend systems, but only in the default system. However, before we jump into the actual implementation of MOC, we need to understand few constraints (limitations) for implementing MOC, which are as follows:

• This feature is only supported in standard mode.
• This feature is applicable only for entity sets with an annotation of addressable=true.
• Implementing this feature generates a different version of the service, if the SAP_Origin field is added.

MOC implementation In order to implement MOC, follow the below outlined steps: I. Customize your service to support MOC.

1. Open the SAP NetWeaver Gateway system and activate the desired service.
2. Open the transaction SPRO and click SAP Reference IMG.
3. Click SAP NetWeaver > Gateway > OData Channel > Administration > General Settings > Activate and Maintain Services to open Activate and Maintain Services screen to add the system aliases for the appropriate backend systems and then define the desired default system. In order to do so, follow the below sub-steps:

• In the Service Catalog list, click the desired service. The service appears in the ICF Nodes section on the lower left corner of the screen.
• In the ICF Nodes section, click Standard Mode ICF Node.
• In the System Aliases section, click Add System Alias to add the system alias.
• Choose New Entries or select an existing entry and click Copy.
• In the Service Doc. Identifier field, type the ID of the service document, along with an underscore and the 4-digit version number (for example, _0001).
• In the SAP System Alias field, type the appropriate system alias.

             Note: You need to define only one system as the default.

• Repeat as required to add the desired backend systems.

Note The default system is used whenever the service is not called as MOC. In case, you have defined more than one default system alias, then the first system is used as the default.    

II. Test the service.

1. In the SAP NetWeaver Gateway system, open the SAP Reference IMG in transaction SPRO and click SAP NetWeaver Gateway > OData Channel Administration > General Settings > Activate and Maintain Services to open the Activate and Maintain Services screen.
2. Click the filter icon to search for the desired service.
3. Select the desired service and under ICF Nodes, click Call Browser.
4. Ensure that the SAP_Origin field is visible in the service’s metadata.

Parallelization of Multiple Origin Composition When using multiple origin composition, you can find out the minimum number of backend systems and the maximum number of parallel backend calls. For accomplishing this, you have an IMG activity available. To do this, follow the below step:

• In the SAP NetWeaver Gateway system, open the SAP Reference IMG in transaction SPRO and navigate to SAP NetWeaver > Gateway > OData Channel > Composition > Define Parallelization for Multiple Origin Composition.

You can apply this parallelization of READ_ENTITYSET for several backend systems to get the optimized performance. In the IMG activity, you can set the following configuration parameters:

1. The values that you can have for the minimum number of backend systems are:

• 0: No parallelization
• n: Parallelization will only be performed from n backend systems onwards

2.  The maximum number of parallel backend calls is mandatorily based on the current resources of the SAP NetWeaver Gateway hub system. Added to that, you can use the parameter: Maximum Number of Parallel Backend Calls to limit the usage of the current system resources. The default value zero (0) implies that it only depends on current system resources.Performance Improvement In case of serialization, the duration of a READ_ENTITYSET within a hub system is the aggregate of all backend calls. On the contrary, the duration in parallel mode is just the maximum duration of all backend calls, implying a minimal overhead for parallelization. Parallelization and Skiptoken If server paging is realized for any backend data providers, then the OData consumer will only get results up to this backend with skiptoken included. The next call with skiptoken or any other call with skiptoken will not be parallelized, as the result has to be resumed by the backend system that had returned this skiptoken earlier. Changesets Changesets are also supported in the context of MOC. All changeset operations for one backend are collected and sent to this backend through one RFC. If you would like to request a demo of Innovapptive’s SAP Enterprise Mobile solutions, please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.

Native vs HTML5 apps – The best option to drive your Enterprise Mobile strategy

This blog attempts to throw some light on some of the pros and cons of using native vs HTML5 apps from  technical, functional and business perspectives.  Any app that is directly installed onto a device, normally from its associated app store is called as a native app, though a native app can have HTML5 elements. One of the key disadvantages of native apps is that they are platform dependent, which means any app developed for iPhone can work on an iPhone only and not on an Android device.

On the other hand, a web app delivered through an HTML5 enabled browser may be called as an HTML5 app. This implies instead of downloading your app from the app store, a user would access his/her browser and navigate to a URL to use your app.

HTML5 for web development is mostly liked by the developers, since it leverages familiar programming languages like HTML, Javascript and CSS.

Though it seems enticing to use HTML5 at first instance considering its prime benefits, however, HTML5 lacks maturity in having enough set of web standards to fully deliver on its promises. Some of the key shortcomings include missing APIs and weaker UIs as compared to native apps, apart from having difficulty to route ads into HTML5 sites.

Benefits of native apps

• Superior performance: A native app has full access to a phone’s hardware resources and the app also interacts directly with the phone without the mediation of a web browser. This way native apps provide superior performance, which is more visible when rendering graphics and animation.
• Minimized development efforts: Developers can easily leverage platform SDKs to create native apps, which ensures easier and minimized development efforts – requires talented and experienced professionals who can understand the programming models.
• Better distribution: Native apps provides a better distribution mechanism, wherein they can be distributed directly through relevant app stores. App stores serves as a stupendous distribution channel that not only makes app installation and updates easier, but can also help reduce the marketing costs through app stores’ built in discovery features.
• Superior monetization: Since native apps are associated with app stores, they can take the benefit of store’s built-in monetization features like one-click payments.
• Superior user experience: Native apps offer better execution experience with respect to certain core features like accelerometer, camera, calendar, GPS, microphone, etc., as compared to HTML5 apps on various devices.

Shortcomings of native apps

• Increased development and costs: The overall development time might be considerably greater than an equivalent HTML5 app, as developers need to build separate apps for each platform. This also enhances costs since development efforts for varied platforms needs mastery over different languages and development environments. App developers themselves tend to be on a higher cost range, in contrast to their HTML5/JavaScript counterparts.
• Higher maintenance costs: When development costs are more, it is quite obvious that maintenance costs are also on a higher scale. A business might solicit the services of a separate iOS, Android and Windows phone developers to keep its apps up and running that directly diminishes their profits.
• Restriction on app store content: Every app distributed through app store must comply with strict content guidelines.
• App store fees: High app store fees may eat into your profit margins that is really daunting, in addition to the higher development and maintenance costs of native apps.

Some of the pros and cons of HTML5 apps are outlined as follows:

Pros of HTML5 Apps

• Platform independent: This is a major benefit of using HTML5 apps as compared to native apps. Irrespective of whether your users are on Android, iOS or Windows Phone, all of them can access your app, since they need only a web browser.
• Easier updates: Native apps takes longer time for updates – the user has to download each update individually. On the other hand, HTML5 apps support centralized updates, wherein every time the user accesses the app through his/her browser, he/she views the latest version of your app, eliminating additional download requirements.
• Faster development: As HTML5 apps are developed using the HTML, CSS, JavaScript, and server-side languages (such as ASP.NET), it cuts down the development time. This is because there are already vast libraries for these languages (such as jQuery and JavaScript) and a vast group of trained developers.
• Cuts down developer costs: As HTML5 apps are built on comparatively simpler technologies like HTML5 and JavaScript, you can easily hire affordable HTML5 developers, as compared to native app developers.
• No content restrictions: As HTML5 apps need to require approval from a closed app store, they can carry whatever content you need.
• No fees: When you deliver your apps directly through the browser, you can cut down the app store costs, which means you save almost 30% of your store fees.
• Distribution through app store: New frameworks such as Phnegap and Trigger.io have simplified the distribution problem substantially bundling up HTML5 apps as native apps. These bundled apps can then be distributed through the app store.

Cons of HTML5 Apps

• Inferior performance: Since an HTML5 app has limited access to a phone’s hardware, it results in inferior performance, especially when dealing with heavy graphics. Some of the new platforms like Famo.us are trying to solve this problem.
• Device fragmentation: Device fragmentation within browsers is a real thing. Varied devices might render the same app quite differently. This implies your developers might require extensive testing and refining to get the UI right, particularly when working on more complex apps.
• Technical restrictions: HTML5 apps lacks complete access to a device’s features and events. This poses a serious challenge on what you can do with an HTML5 app. Apart from that, the UI options for HTML5 apps are also limited.
• Limited monetisation opportunities: A native app can earn substantial revenue through direct app sales and in-app purchases. This monetization option is not available for HTML5 apps, which is particularly challenging if you want to offer your apps for “free”.

So which is the best option to choose?

It is difficult to decide which one is best, since both native and HTML5 apps have their respective flavors. The type of app you choose is totally dependent on your requirements, core expertise, budget and the type of human resources you can hire.

If you would like to request a demo of Innovapptive’s Native, HTNL5 or Hybrid apps, please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.