As part of SAP’s strategic decision to adopt the Sybase Unwired Platform (SUP) as its mobile platform, companies today have several development paradigms from which they can choose when building their mobile solution architecture on the SUP. The following is a list of standard mobility development architecture examples supported by SAP at the time that this article was published:

• Native Application Development using Mobile Business Object (MBO)-based Native Object APIs
• Hybrid Web development using Sybase Unwired WorkSpace
• Native Application Development using the SUP Open Data Protocol (OData) Software Development Kit (SDK)
• Native Application Development using the SUP Data Orchestration Engine (DOE)

My overview of the options supported by SUP can serve as a guide for deciding which is best suited for different types of business scenarios. The strategic approach I propose will assist you in selecting a solution that will provide long-term scalability, sustainability, security, and the potential for integration with innovative open standard technologies.

The Scope of SUP Functionality

Before deciding on a system architecture, it is important that you understand the scope of what SUP provides in the context of mobile application development, and how it’s different from building mobile point solutions without any mobile middleware platform in place. SUP promotes an open standard toolset that enables development capabilities to quickly build mobile apps. It also provides a set of IT management and control tools that allow administrators to efficiently monitor and control devices, and to be able to create and maintain policies around them. In doing so, SUP provides an enterprise-grade mobile platform that allows you to take content from multiple back-end systems and then to build mobile applications for multiple device types. With point solutions, your mobile application development is targeted toward specific device types without the presence of a mobile middleware layer. SUP aims to provide a mobile middleware technology that can scale across multiple different back-end information systems, support multiple device platforms, and address all mobile use cases.

Key Considerations when Designing a Mobile Application

To make the discussion of different mobile architecture models more meaningful, I’ll first review various factors to consider when designing a mobile application:

• Online versus offline: What are the application’s bandwidth requirements? What connectivity modes does it require? Does it need access to offline data? Does it need to interact with the system in real time? Does it need alerts pushed to the mobile device?
• Data volume: How much data volume are your apps expected to use?
• User interface (UI) complexity: How complex does your UI need to be?
• Device strategy: Will you have a device-agnostic strategy or will you only develop for certain devices?
• Integration with native services: Will you use the device’s GPS, camera, gyroscope, or accelerometer?
• Developer profile: Are developers with the right skill sets available?

Online Data Versus Offline Data

Your development paradigm and technology selection may vary significantly based on whether your mobile application is designed to handle online or offline data. For example, online apps do not usually require any data to be stored locally on the mobile device. Instead, they depend entirely on being able to communicate directly with back-end systems for requesting and updating information. Online apps typically involve simple form interactions as opposed to the complex UI interactions that are characteristic of offline applications. Therefore, the biggest disadvantage for online apps is that they require continuous network connectivity to back-end data sources in order to be operational. On the flip side, online mobile applications have the following advantages:

• Real-time data updates and refreshes
• Always in sync with the back-end information source
• No actual business data ever has to be stored on the device

These design considerations are different from an offline mobile application. The first major distinction between the two is that offline apps usually have a data persistence layer that is stored on the mobile device itself. This allows the user to use the mobile application in a fully disconnected operating environment. Changes or updates to the data have to be cached locally on the device and then synced with the server upon restoration of network connectivity. Design considerations need to account for performance issues that could arise from the synchronization of large data volumes based on business process rule definitions. A rich tool set is helpful for such scenarios to allow administrative features for filtering, data conflict management, support, and monitoring. From the developer’s standpoint, it is important to realize that although data synchronization can address part of the design consideration, the other part of the application design relies heavily on how the application itself is used. Here it is critical to to ensure that the application design includes core operations that can be performed in an offline mode.

Native Device Development Versus Hybrid Development

There are essentially two major approaches that can be used in mobile device development: native device development or hybrid mobile Web development. Each approach has its advantages and disadvantages and can be adopted based on the organization’s enterprise mobility strategy. Companies that want to standardize around a specific mobile OS or mobile device can opt for native device development. Additionally, if it is important to the business to use specific hardware functionality on a device (such as a GPS, camera, gyroscope, accelerometer, or near field communication), or if optimal application performance and integration with the native OS is required, then native device development may be the best way to go. Other reasons for adopting a native mobile development strategy could include:

• Security
• UI intuitiveness and optimal user experience specific to a device
• Ability to run apps in an offline state and synchronize

Under the native device development approach, a mobile application is developed targeting a specific mobile OS platform. This application is then installed to run locally on the mobile device. Native applications use development tools specific to the mobile platform and use APIs provided by the mobile OS manufacturer (iOS uses Objective C and Android uses Java, for instance). On a negative note, this approach offers limited portability to other mobile OS platforms, resulting in higher total cost of ownership (TCO). Organizations using native device development should be prepared to employ skilled developers in-house with deep knowledge of each mobile OS platform. On the contrary, if a device agnostic strategy is chosen, allowing multiple OS platforms to be supported, then the most sustainable option is to adopt a hybrid Web development approach. The hybrid Web development approach brings together mobile Web development with native development and enables the use of HTML, Cascading Style Sheets (CSS), and JavaScript into a hybrid mobile application by extending native device capability through the mobile Web browser. This concept is realized by wrapping a browser engine into a native mobile application container. The key differentiator between this approach and native application development is that the hybrid approach requires the application to run on the browser of the mobile device. Due to advancements in mobile hardware technology (i.e., faster processors and faster GPUs), it is now possible for mobile Web apps to reside on the device in a hybrid (part Web and part native mobile) format. Also, it is now becoming more and more possible to access hardware features using hybrid Web development on SUP, as well as through third-party tools such as PhoneGap and through native API sets. For many use cases, the hybrid development approach is the preferred way to go because it offers:

• Ease of portability across multiple platforms due to use of open standard technologies (HTML, CSS, JavaScript)
• Many of the native device functionalities
• Device integration support
• Support for receiving push notifications
• No need to maintain in-house platform-specific expertise
• Web developer skill sets that are more readily available
• Reduced TCO

Another consideration when planning whether to go with a native device or hybrid support strategy is whether the organization plans to maintain the required developer profiles for those specific skills that would be required for a given platform (i.e., Objective C, Java, or .NET). From a TCO perspective, it’s always more cost effective to avoid strategies that require you to develop and support separate code sets for every platform. A hybrid approach that facilitates application business logic reuse is more cost advantageous.

Architecture and Design Options

Now that I have discussed many of the decision points, design considerations, and complexities behind mobile application solution development, I review SAP’s mobility platform offering in this context. There are several architectural and design options available for SUP. It’s important to carefully make the right technology selection for your use case. The scope of this review is limited only to SAP’s standard mobility technology offering and does not cover other partner technology solutions.

Native Application Development Using an MBO-Based Native Object API

This solution uses the standard core offering of the SUP based on the Mobile Business Object (MBO) architecture. MBOs serve to describe the interaction with both the back-end data as well as the device-side data. Hence, MBOs are used to model enterprise data in a format in which its respective data entities can be abstracted from their original data source. This representation enables developers to construct the mobile data models required by their applications in a way that is compatible with their respective back-end enterprise information systems. MBOs are also used to provide vital configuration for various aspects of interaction between the data source and the device’s client database, and include various types of properties such as data source, connection settings, details on data binding and operation types, relationship mappings, object queries indicating the query methods generated in the object class, and synchronization settings with rules and partition information. Figure 1 shows how MBOs fit into the general architecture of an SAP mobility solution. MBOs can provide the data interface to two different types of APIs:

• The Native Object API
• The HTML5/JavaScript Container API

In the context of this solution, I focus on the native object API. One of the major features of this API is to provide query methods to the MBO. Additionally, the native object API uses the SUP synchronization architecture, which is typically used when developing native device applications. This synchronization architecture is based on the concept of a cache database. The purpose of this cache DB (which is a component of SUP) is to replicate and send message updates to the device’s client DB.

MBO-Based Native Object API: Advantages and Drawbacks

Advantages of using the MBO-based native object API include:

• Reusability of MBO data models.
• This approach results in mobile applications with rich user experience and optimal performance for each target mobile platform, resulting in better usability and providing the look and feel native to the target device (as you can use the standard device UI). Native applications are generally optimized for a specific device screen size. For example, you can build different apps for the iPhone and the iPad to use the screen space optimally giving best usability.
• Support for synchronization and full offline scenarios through MBOs
• Full integration into the mobile platform without any other limitations. Full hardware access to all native hardware features (such as the GPS, camera, or accelerometer).
• SUP support for the native object API for major mobile platforms (Android, Blackberry, iOS, Windows Mobile, and Windows-based laptops).

Disadvantages of using this approach:

• This approach requires native development, which entails a longer development cycle and requires in-house skills for each target mobile platform. This could result in higher TCO if multiple platforms are to be supported.
• Lack of extensibility or portability, requiring recoding per target platform.

Implementation

The steps for this development model are as follows: Sybase Unwired WorkSpace:

1. Develop MBOs
2. Deploy MBOs to SUP
3. Generate native object code (this code has to be copied into the mobile application project’s native development environment)

Native development tools:

4. Develop a native device-specific application
5. Deploy and test

The first step in developing mobile applications is to define the MBO using the Sybase Unwired WorkSpace, an Eclipse-based tooling environment with a set of connector wizards for connection to standard data sources. As part of the MBO development process, it must be bound to a back-end data source. Next, the MBO is deployed to the SUP server using Eclipse tooling, and the object code is generated.  Developers can then begin to develop their native mobile application and access the MBOs using the native object API provided by SUP. Finally, once fully tested, the mobile application can be deployed to the device. The table below highlights a list of all native mobile platforms and their associated programming languages and integrated developing environments currently supported as of SUP 2.1.3. When working with MBOs in the context of native development, always:

• Access MBOs via their synchronization parameter whenever it is available and relevant to the business case
• Minimize memory instantiation of objects to only that which is absolutely required on the mobile device in order to improve performance
• Create and map only the minimal attributes of the MBO that are absolutely necessary for the mobile application (irrespective of what the back-end provider contains)

Some potential use cases that benefit from this development model are:

• Apps that support critical, offline, and complex scenarios with medium-to-low data access requirements.
• Apps that require full support for offline data access and synchronization. These scenarios allow users to continue to work on mobilized data while fully offline. The MBO architecture supports synchronization updates to the SUP server.
• Device-specific usability (such as specific hardware features) or performance standards that are critical requirements.
• Heavy UI complexity with special attention to pixel-level detail.

Hybrid Web Development using Sybase Unwired WorkSpace

A potentially more rapid approach to building mobile applications on SUP that does not require any kind of platform-specific coding knowledge is building HWC applications that are based on HTML5, JavaScript, and CSS. An HWC is essentially a native application with an embedded browser built for iOS, Android, Blackberry, and Windows Mobile. HWC technology enables cross-platform development capabilities by taking browser technology and wrapping it around a native shell to give users the experience of a native application while expressing the presentation and business logic in HTML and JavaScript. Using this development approach, you would still need to do all your data modeling by creating MBOs on SUP. You begin by modeling your back-end data, and create your MBOs that then are deployed to the SUP server. Using the HWC Application Form Designer, you create mobile apps by dragging and dropping screens on a canvas and adding controls onto the screens. These screens are eventually used to generate the HTML and the corresponding JavaScript and CSS files. Once you have created your mobile application, you deploy it onto the intended mobile devices, after which the user enters his connection information to connect back to the SUP server. Once that is done, every Web app that you create afterwards can be automatically provisioned and deployed to the application on the device. The container takes care of installing the application securely and communicating with the SUP server. SUP also supports manual customization changes to the HWC application through standard Web technologies (i.e. HTML5, JavaScript, and CSS).

Architecture

HWC architecture provides a native application running on each platform that embeds a browser control that is supplied by the OS. Therefore, depending on which mobile platform you are on, that browser control might have rich or limited functionality. The container application communicates internally with the SUP by transporting encrypted compressed XML messages to and from the server. There is a data structure that you can manipulate in JavaScript that represents these XML messages. Because the container application on the device is a native application, it is able to expose native services. These native services provided by the container may include security, storage, making native menu items, and other functions that a typical Web application can’t do. Because this is a native application, it is able to expose this functionality through JavaScript and HTML and make it accessible. Figure 2 shows the system architecture underlying an HWC-based app. The most important principle behind HWC architecture is the bridge piece, which allows the JavaScript to interact with the container so that it can do things that a typical Web application cannot do (such as creating native menu items). This development option has limited offline capabilities. There is an option to custom develop a data cache in the HWC application. Moreover, the messages to and from the HWC container are queued. Approvals then can be done offline and submitted once the HWC app comes online.

Hybrid Web Development: Advantages and Drawbacks

Using an HWC to create a mobile app offers the following advantages:

• Fully device-agnostic approach that can greatly reduce conventional development cycles (which are typically seen with native mobile device specific applications) resulting in significantly reduced efforts. Eliminates the need to maintain device-specific expertise.
• High portability and extensibility as the same UI can be re-used across multiple different platforms. This provides the ability to reuse Web UIs that are already available and to adapt them to mobile apps.
• HWC technology is enabled by an open standards based platform that promotes easier customization of modeled applications and takes away the responsibility to do rendering on the device.
• Uses existing Web development skills with a minimal learning curve. As a result, you can now target a much larger audience (Web developers can now be mobile developers).
• This helps to reduce the cost of building cross platform applications involved in doing native development for each device type, eliminating the need for developers to have native coding skills.
• Easy to customize.
• SUP support for HTML5 and JavaScript API for all major mobile platforms.
• Its Web browser capability allows the HWC to exploit the power of Web standards such as HTML, CSS, and JavaScript to enable Web developers to apply skills they already have to build mobile apps. This allows the potential to reach a larger Web developer base.
• Supports single sign-on.

Hybrid Web development also has the following drawbacks:

• The apps may not be able to use advanced, device-specific hardware feature sets, with limited access to on-device capabilities.
• The UI complexity is lower compared to native development.
• Slower UI performance than a native app.
• Although HWCs use MBO data binding, they do not use the MBO synchronization architecture. This results in limited offline capability, which may not be suitable for synchronization scenarios.
• A substantial amount of development effort is required in HWC enhancements to achieve a native application-like user experience and performance.

Implementation

The steps for this development model are as follows:

1. Develop MBOs
2. Deploy MBOs to SUP
3. Create a mobile application using the HWC Application Form Designer and design binding between the HWC application and MBO
4. Deploy the HWC application to the mobile device, and configure SUP connection details (this step is done initially, only once)
5. Test

Some potential use cases for which the HWC approach is most useful include:

• Mobile workflow: Scenarios that require the user to act on information (e.g., review, approve, reject) by making a decision on a transaction in a business process chain.
• Data lookups and replies: Provides mobile users the ability to request and receive data from the back-end system by invoking simple requests and replies.
• Back-end-system-generated notifications: These scenarios involve some event taking place in the back-end system, which then triggers informational notifications being directly sent to the mobile user’s device.

Native Application Development Using the SUP OData SDK

Yet another approach for building mobile applications that operate in an online environment is the native application development approach using SUP’s OData SDK. From version 2.1 onwards, SUP has inbuilt platform support for building native mobile applications using the OData SDK. The OData SDK comes with a collection of runtime libraries and classes that support native device platform development for Android, BlackBerry, and iOS platforms. The OData is an extensible open standard Web protocol based on HTTP and ATOM that uses the REST architecture. OData has been defined by Microsoft, and provides an easy-to-use protocol for metadata and business data exchange between supported back ends (i.e., SAP ERP Central Component 6.0 via SAP NetWeaver Gateway) and client devices. The REST-based architecture provides its consumers with an interface that supports querying and updating data. SAP supports OData through its SAP NetWeaver Gateway technology, which enables the exposure of the Business Suite as RESTFUL services for consumption. Under this architecture, the actual data is transferred over HTTP in XML format. This development approach offers an effective approach for developers to build native applications on a mobile device using open standards to consume OData services.

System Architecture

Business data is transferred by request of the client (mobile device). In Figure 3, the SUP server is only used as a proxy (in OData native applications) and can be bypassed if required - it’s not mandatory for OData SDK-based applications to connect to a back end.  In other words, it is possible for OData protocol services to be consumed directly (without SUP) from other application types as well, such as portal pages, desktops, and other back-end consumer application types. Therefore, the decision to architect OData-based applications should consider what sorts of devices are consuming the data. Native application development using the SUP OData SDK can be used for online-specific scenarios such as:

• Mobile workflow: Scenarios that require the user to act on information by making a decision (e.g., review, approve, reject) on a transaction in a business process chain.
• Data lookups and replies: Provides mobile users the ability to request and receive data from the back-end system by invoking simple requests and replies.
• Back-end-system-generated notifications: These scenarios involve some event taking place in the back-end system, which then triggers informational notifications that are sent directly to the mobile user’s device.
• Optimal use case scenarios for using this approach are when device-specific usability (hardware-specific features such as GPS or camera) and performance are critical requirements in an online-only access mode
• Applications with heavy UI complexity and special attention paid to pixel-level detail in an online-only access mode

SUP OData SDK: Advantages and Drawbacks

Advantages of using this approach:

• All the same advantages I explained earlier with native mobile application development approaches.
• Does not require data modeling by creating MBOs. Instead developers can directly consume OData services that have been exposed by the back end.
• Developers require no prior SAP knowledge.
• Provides simplified SAP service consumption.

Disadvantages of using this approach:

• Will only work with back-end systems that are able to expose their services as OData.
• Does not support offline scenarios.
• OData does not currently support passing structures or tables as input.

Implementation

If you use SUP as a proxy server as shown in Figure 3, follow these steps:

• Copy the OData and SUP 2.1+ SDK Java libraries to your desktop
• SAP NetWeaver Gateway Service Consumption: Create a service request application (add the code in your native mobile platform) to connect to SUP and register application users
• Define connectivity to SUP
• Register a first-time user
• Gateway service consumption: Call the service
• Gateway service consumption: Parse the service request
• Set up a communication channel through SUP: Define a user on SUP
• Deploy and test

Native Application Development Using SUP DOE

As of today, native application development using SUP DOE is supported. However, SAP is now working on bringing better options for heavy mobile offline scenarios, and Syclo may soon be positioned as bringing similar functionality as SUP DOE. With the exception of native application development using the MBO-based Native Object API reviewed earlier, all the other solution technologies explored thus far have involved online scenarios only. However, for scenarios with heavy data requirements for offline synchronization (such as a large number of devices that require heavy data sets loaded onto the device with a heavy volume of daily delta updates), the SUP DOE is the best solution. It provides a breadth of features for effectively dealing with such heavy data distribution to specific device types based on selective data criteria. The architecture for using SUP DOE is shown in Figure 4. The concept behind this technology is that each mobile device has a persistent local database for offline use in which the synchronized data is stored. The local database can be accessed through the represented MBOs discussed earlier. SAP provides a number of services through a set of SDKs that make it easy for developers to use the generated MBO classes and their methods for accessing this mobilized data on the device, thereby facilitating development. These SDKs provide an easy mechanism for querying the underlying data represented by the MBOs and also simplify online searching against the back-end system. Additional SDK features include mobile application initialization, support for callbacks (from push notifications), and client logging. Before walking through the high-level development process involving DOE, I first characterize the design considerations for building offline data-intensive scenarios and the features available as part of SAP’s DOE technology offering. DOE-based scenarios should be built with the following design considerations in order to use this technology in the most effective manner:

• Make sure that you are only giving your mobile users the data that they really require, and no more
• Ensure appropriate data consolidation to limit distribution of redundant data
• Ensure the most efficient and optimized synchronization takes place in a timely manner over constrained bandwidths as required
• Ensure that your data model supports distribution according to distribution rules
• Ensure support of bulk assignment with content-based routing
• Ensure support for object dependencies
• Ensure that your solution architecture supports high scalability for extra-large applications across a large user base, as your requirements may evolve over time

To effectively address the above considerations, a highly scalable mobile platform capable of the following features is required:

• Support for push notifications directly to the device
• Support for frequent and ongoing change and maintenance of mobile data distribution rules
• Provisions for data realignment on large scale
• Ability to support automated and manual data synchronization parameters for optimal performance
• Ability to manage support for data reconciliations involving conflicts

The SUP DOE offers the following key features that support the above provisions:

• Allows rules-based distribution modeling and consolidation through the Data Orchestration Workbench. The distribution modeling involves:
  • Creation of a distribution model.
  • Creation of distribution rules and their associated object dependencies. The distribution rules allow you to map the business data against specific mobile users in order to optimize performance. Data is then distributed based on defined rules.
• Invokes calls to back-end BAPI wrappers to extract data from the SAP systems
• Replicates the data into the consolidated data store.
• Efficient handling of delta data updates.
• Detects and resolves data conflicts that can occur if a data object is changed on the client and in the back-end system at the same time.
• Efficient data major and data minor realignment that provides redistribution of data due to changes (such as changes in object receivers, instance association, or distribution of metadata)
• Receives messages from the mobile device via SUP.
• Support for both individual distribution and mass distribution based on bulk assignments.
• Effective bandwidth utilization.

Development Steps Explained

The DOE stores the business data in the form of data objects. However, to load this data from the SAP back end, the DOE invokes BAPI wrappers (which point to Remote Function Call (RFC)-enabled function modules based on CRUD services [GetList, GetDetail, Create, Update, Delete] that deliver the required data from the SAP back end). As part of this process (but before starting any development), it is essential to first define all business processes to be mobilized and map out these processes against their respective business data that needs to be distributed to the mobile device. This makes it easier to identify the required BAPI wrappers for implementation with the DOE. Once the BAPI wrappers have been created in the back-end SAP system, it is then necessary to define the associated data model in the DOE that represents the data to be exchanged with the mobile devices. To start this process, developers use the Data Orchestration Workbench in the DOE to first create a software component version (SWCV). The SWCV holds the application details, including version info. The Data Orchestration Workbench also helps to define the data model associations with its respective data objects. Next, the distribution model must be created to provide the distribution rules that determine which data is to be sent to which mobile user. This is critical when synchronization of heavy transactional data is involved in order to prevent adverse performance issues. The best practice here is to send only the minimum relevant data that has to be distributed to a particular device user based on the mobile user’s role and profile by setting up distribution rules to filter the data as much as possible. The next step is to create and generate the entity set definition for mobile applications (ESDMA). The purpose of this process is to capture the specific configuration of your back-end SAP system (that is being mobilized) in order to create the respective structures on the SUP. The ESDMA bundle generation process (which is exported from the DOE) results in creating a ZIP file that contains Web Service Definition Languages (WSDLs) and other XML documents that are used to define the necessary metadata for the Sybase DOE Connector. Once the ESDMA has been deployed, the SUP is then able to generate subscriptions and send data to—and receive data from—the DOE. Once the package has been deployed on the SUP server, the target MBO code for the desired device must then be generated. Finally, the native mobile client application is then developed. In a high level summary, the development steps (involving back end, DOE, SUP and IDE) for applications that are based on the DOE scenario are as follows:

• Back end
  • Create BAPI wrappers (based on CRUD services)
  • Create events for push notifications
  • Create data load filters
• DOE
  • Define and create data objects
  • Define and create distribution rules
  • Create ESDMA
• SUP
  • Generate MBOs and client code
• Client development IDE
  • Develop client application

This approach is best suited to applications with heavy transactional data collection and processing on mobile handhelds, such as:

• Create, update, display, delete, and approve work orders, purchase orders, PRs
• SAP CRM Sales
• SAP Field Service
• SAP EAM Work Orders
• SAP Retail Execution

SUP DOE: Advantages and Drawbacks

Advantages of using the SUP DOE approach are:

• Provides full offline support and synchronization for heavy data scenarios
• Provides a rich set of data orchestration features that supports data filtering based on distribution rules
• The replication of data into the consolidated data store ensures that the business data is fetched from the SAP back-end system only once and not during the synchronization of each mobile device
• Provides flexibility for easy design and modification of data distribution logic without coding

Disadvantages of using this approach:

• Adds additional complexity for configuration, setup, and administration of DOE
• Lacks a single point of administration and control, and requires monitoring and control in multiple (DOE, SUP) admin consoles.