Welcome!

Java Authors: Liz McMillan, Tim Hinds, Elizabeth White, Cloud Ventures, Pat Romanski

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

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 asdoOnlineRequest, 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.

Hybrid App.png

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.

Wizard_1.PNG

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.

Object API 2.png

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.