Welcome!

Java Authors: Pat Romanski, Elizabeth White, Yeshim Deniz, Roger Strukhoff, Sebastian Kruk

Related Topics: Java, Wireless, SOA & WOA, .NET, Web 2.0, SAP

Java: Article

A Comparison of the Programming APIs Available in SAP Mobile Platform 2.3

Native and JavaScript-based programming APIs for SMP

OptionDescription
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 Synchronizeor 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 OData SDK provides basic persistence capabilities, but these are not to

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.

OData 1.PNG

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.  Theappid 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/PlatformsUses 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

More Stories By Paul Horan

Paul Horan is a Senior Solution Advisor and Mobility Architect at SAP, and works with the SAP Mobile Platform and SAP Mobile Secure product lines. Paul joined SAP as part of their acquisition of Sybase in June, 2010. Prior to that, Paul worked for Sybase as a technical pre-sales architect supporting PowerBuilder, PowerDesigner, and SQL Anywhere. Paul works out of SAP's Reston VA office. A 1984 graduate of Indiana University, Paul currently resides in Arlington VA.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.