A comparison of the major programming API's available in SMP 2.3

[Former Member]

Introduction

When Sybase first released the Unwired Platform in 2008, it was intended to be a complete end-to-end development environment for mobile applications.  SUP developers would create the middle tier components (a.k.a. Mobile Business Objects), and the client application executables from a single, integrated Eclipse-based toolset.  There was a "PowerBuilder-like" 4GL screen painter, called the Device Application Designer (or DAD), that compiled down to native Blackberry 5/6 or Windows Mobile 6.5 applications.  (Yes, it's hard to imagine, but there was a time when iOS devices were not allowed to play in the Enterprise Mobile Application playground...) 

Several market forces emerged around that time and started to cast doubts on the wisdom of the "complete end-to-end" strategy.  Those were (in no particular order or importance): 

• The release of the iPad, and overall growth of iOS in the enterprise mobile space;
• The subsequent struggles of RIM and Blackberry to maintain their place in a market they had been dominating;
• The fact that there were hundreds of thousands of developers already proficient in languages like C#, Java, and Objective-C;
• The emergence of OData as the primary protocol for data exchange over the web and HTTP;
• The rise of HTML5 as a cross-platform alternative to native mobile application development;
• The introduction of the Google Android platform, and it's ascendence in the mobile marketplace;
• The acquisition of Sybase by SAP, which infused the product with fresh new ideas (and a lot more development resources...)

It became fairly evident that the DAD was very dependent upon market trends and an ever-expanding variety of mobile platforms that were outside SAP's control, and was not the best long-term direction for UI tooling.  As a result, the DAD got sent straight to the bit bucket with the release of SUP 2.0.  The direction then became one of "openness", and embracing alternative development platforms and open industry standards. 

This blog post will cover the four major API's that have been released into SMP since then.  We'll cover how to generate them, what their characteristics are, when to use them (and when not to).  The API's we'll cover here are:

1. The Hybrid App API
2. The Native Object API
3. The OData SDK
4. The HTTP REST API

Note: There is a 4GL programming tool for HTML5 development in SUP/SMP, called the Hybrid App Designer.  I'm not discussing that tool here, because it's integrated with the platform and doesn't require the specific generation of the API libraries.  And developers are hard at work crafting a new HTML5/UI5 programming tool for SMP 3.0 that will deploy hybrid apps into the Kapsel container.  This tool will be called AppBuilder.

Hybrid App API

The Hybrid App API is a set of Javascript libraries that exposes the full functionality of the Hybrid Web Container (HWC).  These can be used to develop HTML5-based apps that run inside the HWC and access the Mobile Business Object (MBO) layer of the SMP server, but with UI tools other than the integrated SMP Hybrid App Designer.  Web apps created with this API will have full access to the SMP messaging stack, including methods such as doOnlineRequest, and classes such as MessageValueCollection.  To deploy these apps as Hybrid Web apps, they must be packaged with the Hybrid App Packaging tool, imported into the SAP Control Center (SCC), and then assigned to registered devices running the container.  These apps use the Message-based Sync (MBS) protocol to communicate with the SMP server.

To generate the Hybrid App API from an MBO diagram, right-click the top level folder in the Workspace Navigator, and select "Generate Hybrid App API...".  Figure 1 below shows where this option is located.

This opens a wizard which has two panels.  The first prompts for the MBOs to include in the generation, and the second allows you to construct the message template for any Server-initiated start point.

Once the process completes, the generated Javascript API libraries and the WorkFlowClient.xml file will be found in the folder location specified.  These can then be included in any standard HTML5/Javascript project.  Hybrid web apps that use the "Online Request" operation to request data will require a persistent data connection.  However, they can also work in a "partial" offline mode, in which outbound workflow transactions can be persisted in the Outbox, just like a sent e-mail, until a connection becomes available. 

Native Object API

The Object API can be thought of as the "native" equivalent to the Hybrid App API, in that it exposes the MBO object model to the client UI developer, but there are two major differences:

1. The Native Object API is generated into the native language of the targeted mobile platform.  This list includes Objective-C and Xcode for the iOS platform, Java for both the Android and Blackberry platforms, and C# for the Windows/Windows Mobile platform.  The app developer is responsible for crafting the user interface and business logic layers in the native IDE for that platform.  If you plan on developing multiple versions of a mobile app, one for each popular mobile platform, then it is required to generate the Object API, and develop a separate UI/logic layer, for each of those targeted platforms.
2. The Native Object API also enables full offline access to the mobile application data, because it uses Replication-based Sync (RBS) when communicating with the SMP server. 

To generate the Object API for a specific language and platform, right-click the Mobile Business Objects folder in the Workspace Explorer, and select "Generate Code...".  This opens a wizard with three panels.  The first prompts for a saved configuration profile (if there is one).  The second prompts for the MBOs to include in the generated code.  The final panel is the important one, and is shown below.

Option	Description
Language	C#, Java, or Objective-C
Platform	iOS, Java for Android, Java ME for Blackberry, .Net Framework for Windows, .Net Compact Framework 3.5 for Windows Mobile
Mobile Server	Select the SMP server where the MBO model has been deployed.
Server Domain	This should correspond to the Application name in the SMP Control Center
Page Size	Controls the size of the data page in the remote database.  Do not select a size that is smaller than is required for a single row.
Destination	Generate into a project folder, or into a specific folder on the file system.
Clean up...	This completely ERASES the contents of the destination folder before code generation, so USE WISELY

The key point to remember when using the Object API is that all operations are performed against the local device database, including MBO object queries.  No data is exchanged between the device and the SMP server (and ultimately the backend EIS or database resource) until the application calls the Synchronize or startSynchronize API method (startSynchronize is the asynchronous, non-blocking version of the method).  The placement of this method call is totally up to the requirements of the application.  To simulate an "online" environment, place the synchronize call immediately after any CUD (Create/Update/Delete) transaction, so that the device immediately sends the transaction to SMP.  To function "offline", just call submitPending to record the transactions locally, and delay the Synchronize call until the user clicks a button, or a live connection is detected.

OData SDK

OData, or the Open Data Protocol, has emerged as the primary protocol for data exchange across the web.  OData operates somewhat like SQL, but instead of querying a relational database, the endpoint is a REST-based web service URL, and the application uses standard HTTP verbs like GET, POST, PUT, and DELETE to interact with the service endpoint.   The protocol defines specific command modifiers, like $select, $filter, $orderby, and $expand to retrieve specific elements from the endpoint URL.  Data returned from the endpoint is formatted in either JSON or XML, using the AtomPub schema.

SAP has identified OData as a strategic direction for the entire portfolio of products, and the OData SDK provides a comprehensive set of API's for securely accessing OData endpoints from native mobile device applications.  The OData SDK is delivered as a set of static runtime libraries on the iOS, Android, and Blackberry platforms.  The MBO model is not used with OData applications, and there is no code generation step required. 

The OData SDK consists of five major components and classes.

OData Parser

Parses and generates valid OData protocol messages to/from native objects. It eliminates the need for mobile developers to work with the low-level details of the OData protocol directly. Functionalities supported by this component include:

• Parsing OData XML structures to native OData objects
• Validating OData XML during parsing by checking the existence of mandatory fields and structures
• Providing easy access to all OData fields and structures via the objects resulting from the parsing
• Building OData XML structures from native OData objects 

Cache Management

The runtime cache is responsible for storing and accessing OData related objects in the memory of the device for quick and easy access. Functionalities supported by this component include:

• Storing/accessing OData objects in the memory (both metadata and application data)
• Searching for OData entries in memory using their searchable fields
• Managing the size of the cache 

Persistence

Implements a convenient and secure storage of data on the device. Mobile applications can access the locally stored data even when network connection is unavailable. Functionalities supported by this component include:

• Storing objects and raw data on the physical storage of the device
• Easy and quick access of the stored objects and raw data
• Data encryption for sensitive data 

Supportability

Implements standard SAP logging, tracing and error handling to enable end-to-end supportability from client to back-end. Functionalities supported by this component include:

• Common exception and error handling
• Event logging
• Tracing (SAP Passport) 

Connectivity

This connectivity layer handles all connectivity related tasks, hides the complexity of the communication at transport level, and provides an easy to use API to the applications. Productive enterprise applications must use SAP Mobile Platform for connectivity for all enterprise use cases. For development and demo purposes, the SDK also provides a possibility to use HTTP or HTTPS. Functionalities supported by this component include:

• Synchronous and asynchronous HTTP request handling
• Supported authentication are:
  • X509 certification
  • SSO token/cookie
  • Basic authentication (user/password)
• Timeout handling
• Compressed payload handling
• Request types as supported by OData Protocol
• Connection pools for optimal performance

The key step in setting up an OData SDK application is to create the Application ID in SAP Control Center, and define it as an "OData" type.  That dialog box is shown below, with sample data.  Note the Application Endpoint setting.  That URL references the root "service document" of the application's OData endpoint.  Making this URL an attribute of the Application adds a layer of security, since only registered Application Connections will be able to access that endpoint through the SMP proxy.  There is no need to expose that OData URL outside the corporate firewall.  The mobile application retrieves the endpoint URL as a property of the Application, once a successful connection is made to the SMP server, and then provides that on all subsequent OData queries and updates.

Refer to the OData SDK Developer Guide for more thorough instructions on the use of the API within your application.

Note:  OData is inherently an HTTP-based protocol, but with SMP 2.x, OData SDK apps communicate with the SMP server using the proprietary "iMO" messaging protocol.  It's essentially "HTTP over iMO".  WIth SMP 3.0, this will be changed to use standard HTTP(s) for communication.

HTTP REST API

The HTTP REST API is the most recent addition to the catalog of programming interfaces.  However, it's a little misleading to call it a traditional "API", since there are no client-side libraries to include with the application code, and no language-specific methods to invoke for implementation.  With the release of SUP 2.2, an HTTP listener was added to the SMP server, and several REST endpoints were exposed on the open port (which is 8000, by default).  These REST services perform basic SMP administration and security functions.  This "decoupling" of client and server platforms allows SMP applications to be written in any language, on any platform, using any IDE.  As long as the mobile application is capable of performing an HTTP call to a REST endpoint, it can be secured and managed by the SMP server.

The REST API provides four basic capabilities to a mobile application.

• Registration:  Creating an Application Connection and registering the device ID and type to SMP;
• Authentication:  The Application is linked to a specific Security Configuration, and any connection must satisfy the authentication requirements.  Anonymous application connections are also supported;
• Native Push Notification: The mobile app can register for push notifications through APNS, GCM, or Blackberry BES
• Configuration:  The mobile app can call SMP to persist specific application settings or preferences;

All the calls to the API are performed by making HTTP calls to a REST endpoint, which is defined on the SMP server.  (If the Relay Server or a 3rd-party reverse proxy server is in place, the URL of the endpoint should reference that URL instead.)   For example, to register an Application Connection, the mobile application simply needs to perform an HTTP POST as shown below.  The body of the post contains the minimum default XML content.

POST http://domain:port/odata/applications/latest/{appid}/Connections

<?xml version="1.0" encoding="UTF-8"?>

<entry xmlns="http://www.w3.org/2005/Atom" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"

xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices">

    <content type="application/xml">

        <m:properties/>

    </content>

</entry>

In the above URL, domain:port would correspond to either the SMP server and port, or the relay server, on their respective HTTP or HTTPS ports.  The appid would be the Application ID as defined in the SAP Control Center.  Once successfully registered and authorized, application data can be retrieved from the OData endpoint with any HTTP request and JSON/XML parsing logic.  You can also create additional OData Proxy connections in SCC, creating a "whitelist" of valid endpoints for the application to use.

The SCC dialog for registering a REST API app is exactly the same as the OData figure shown above (except, of course, that you select "REST API" from the dropdown list...) so I won't duplicate that here.  Suffice it to say that the Application must exist in SCC as a REST API app before any registration and authentication attempts can be made against it. 

As far as online vs. offline goes, I'll call this one "custom", meaning that while a live data connection must be present for any interaction with the SMP server (device registration, authentication, etc.), offline could be supported by any intrepid developer that wants to build and deploy their own SQLite or UltraLite database for the remote device, write the application to persist transactions into that local database, then write the synchronization logic to keep that database in sync with the backend EIS.  Don't forget to manage the entire synchronization session as a restartable, ACID-compliant unit...  (All of that is exactly what the MBO model and the Object API provides for you in a single mouse click.)

One final note on the HTTP REST API:  if you are developing a native app in Objective-C or Java against an OData endpoint, then the Persistence, Caching, and OData Parser libraries from the OData SDK (as mentioned in the section above) may be leveraged in your project.  Just include the corresponding SDK libraries in your project, and those functions will be available to your application.  The Registration and Transport layer libraries would not be applicable in this use case.

Refer to the SMP Developer Guide: REST API Applications for more detailed information on programming to this API.

In Conclusion

Here's a quick wrapup of the four options presented above, so you can choose the most appropriate architecture for your SMP 2.x application.

API	Supported Languages/Platforms	Uses MBO's?	Supports Offline?
Hybrid App API	Javascript	Yes	Partial
Native Object API	iOS: Xcode and Objective-C Android: Java Blackberry: Java ME Windows: .NET Framework 3.5 Windows Mobile: .NET Compact Framework 3.5	Yes	Full
OData SDK	iOS: Xcode and Objective-C Android: Java Blackberry: Java ME	No	No
HTTP REST API	Any	No	Custom