white paper

www.sybase.com

Sybase® Unwired Platform Version 2.1Architecture

introductionThis document is for service providers and enterprises that plan to deploy the Sybase® Unwired Platform (SUP) and

need a functional understanding of the technology to assist in making informed decisions about choosing the correct mobile technology to use for a particular use case. It includes some level of detail about the internal workings of the platform that may prove useful to administrators.

This document serves as a foundation for other more specific explanations of technical aspects of the system, for example, sizing, performance and tuning, architecture approaches, and security. Developers may find it useful to consult other material specifically related to development fundamentals or tutorials.

table of contents 1 Mobilizing the Enterprise

1 Online Mobile Applications1 Offline Mobile Applications1 Common Characteristics

2 Overview of the Sybase Unwired Platform3 Basic Development and Deployment Process

4 Common Elements of the Architecture4 Network Topology5 Administration and Monitoring6 Device Services7 Messaging Services7 Security Services

7 Mobile Workflow Enablement7 Workflow Components

8 Hybrid Web Container Applications9 Container Messaging Components

10 Mobile Synchronization Applications10 Cache Synchronization

13 Synchronization with Data Orchestration Engine (DOE) 16 SAP OData Applications

1

Mobilizing the enterpriseIndividuals and businesses develop mobile applications for specific user needs ranging from teams of service

workers who use ruggedized devices for industry-specific applications, consultants who track time and expenses on a mobile device, or simple corporate approvals. Sybase Unwired Platform supports these mobile scenarios as well as cross-industry applications, such as customer relationship management, human resources, supply chain management, business intelligence, product life cycle management, and industry-specific applications tailored for the service provider, chemical/pharmaceutical, and utilities industries. All these mobile applications follow two broad patterns; the pattern used depends primarily on who is driving the use case.

•End-user driven, where an end user looks for the information that he or she wants, for example, an employee lookup

• IT- or LOB-driven, to improve organizational efficiency and customer engagement, for example, sales process enablement

These two patterns inherently represent two broad categories of mobile applications, which can be called online mobile applications and offline mobile applications. These two classes of applications differ significantly in functional and some nonfunctional aspects. However, they share common attributes, such as security.

Online Mobile ApplicationsOnline mobile applications are completely user-driven, and IT is seldom involved in their operation. Information

access is ad hoc in nature, and users typically know what they are looking for in a given situation. Technically, online suggests these attributes:

•Request/reply interactions directly with the back-end system•Lightweight form editing•Situation-oriented toward a few screens rather than a complex application•Targeted notification from the back end gives alerts to the user

Offline Mobile ApplicationsOffline applications are typically driven by IT or Line-of-Business (LOB) to gain organizational efficiency. IT is very

much involved in mobile operations for most offline cases, information access is formalized in nature, and the business process dictates the information that each user will act on. In general, offline applications are task oriented, and must provide mission-critical information to end users, regardless of connectivity. Characteristics of offline applications include:

•Data synchronization to devices is based on enterprise-level process rules•Task-oriented covering a complete process, resulting in complex UI navigations•Ready for heavy customization, since processes are unique per enterprise•Push-enabled for real-time user experience•Strong administrative tools for support, monitoring, and data and conflict management

Common CharacteristicsBoth online and offline applications require these common IT and application management capabilities:1. Secure onboard processes to bring user devices into the enterprise landscape2. Device, data, and transport security3. Ability to troubleshoot error conditions with supportability toolsets4. Remote device management

These common characteristics introduce a need for a common platform covering both application categories.

2

overview of the sybase unwired platforMThe Unwired Platform primary value proposition is in serving as an information bridge between device users and

enterprise data that is secured behind the corporate firewall or hosted in a cloud infrastructure. The platform, as mobile middleware, includes a range of components that are hosted within the enterprise and on the device. These platform technologies are hosted under a common design, runtime, and management infrastructure that provides:

•Connectivity to multiple client device types and mobile operating systems•Support for native client object-based APIs based on the device platform language•Support for mobile Web-based clients within a secure enterprise sandbox•Eclipse-based visual development tooling for building mobile data services and generating device-side data

persistence APIs•Enterprise mobilization architecture that uses standard and proprietary interfaces to support a variety of

enterprise data resources•End-to-end pluggable security that extends from the enterprise to devices•Support for mobile users who are either occasionally connected or those that work entirely online•Push notifications that alert clients to refresh their mobile view of data•Unified platform administration and monitoring

Management Console

ControlDevice and server management and security

BlackBerry

iPhone

iPad

Android

Windows

Windows Mobile

ConsumeHeterogeneous mobile devices

ConnectHeterogeneous

data sources

Create

Eclipse

Databases

WebServices

SoftwareApplications

MobileBusiness Objects

NativeApplications

Hybrid WebContainer

Sybase Unwired Platform

OData Interface

SAPNetWeaver

Gateway

figure 1. Platform Overview

In Unwired Platform, one or more of these technologies come together to provide support for a few major types of mobile applications, including:

•Hybrid Web container applications: – Simple cross-platform request/reply or lookup – Mobile workflow enablement

•Native applications using synchronization: – Result-set cache synchronization in an SUP standalone mode – Data consolidation and distribution with the Data Orchestration Engine (DOE)

•Native applications using the SUP OData SDK: – Simple device-specific request/reply or lookup with rich UI

The purpose and function of the major application pillars is discussed in more detail later in this document, along with the major technology components that support them.

2

3

Basic Development and Deployment ProcessIn cases where a model is developed specifically for SUP, the developer starts building an application by using

Eclipse-based tooling to discover assets of enterprise datasources and to tailor the mobile interaction pattern (which usually involves selecting data subsets) for mobilization. The most significant model artifacts are mobile business objects (MBOs), which describe the interaction with the back-end data, and the device-side data representation.

An MBO is a middleware object that describes mobile data and operations on that data. Operations on an MBO are typically record related, but can also be operations that are directly invoked against the back end. Changes made to MBO data on the device are reflected in the back end. Back-end changes are communicated to the user when the middleware notifies the device of an update and subsequently updates the MBO data on the device.

Enterprise System

Subset Personalize Mobilize

Device Representation

fname : STRING(15)lname : STRING(20)address : STRING(35)city : STRING(20)state : STRING(2)zip : STRING(10)phone : STRING(12)company_name : STRING(35)+ id : INT

update()delete()create()

Q

Q

Q

Q

Q

Q

Q

Q

Q

Attributes (9)

Operations (3)

customer

figure 2. Mobile Business Object (MBO)

Using Eclipse tooling and the MBO model, a developer creates a package containing one or more MBOs that can be deployed into the server runtime environment. Each package is assigned a version that is associated with the specific runtime artifacts generated by the deployment architecture.

figure 3. Development Paradigm

When using the Data Orchestration Engine (DOE) for communication with the back end, the developer starts by describing back-end interaction and the application content model within the DOE tooling. The application content model includes mobile entities, called data objects, that are reusable across applications, and distribution models that are application- or deployment-specific. The product of this design activity is a package that can be deployed, via tools, into the Unwired Server, where artifacts are generated for storing and forwarding messages between server and device. In effect, the deployment tooling autogenerates MBO constructs for DOE communication.

Develop Mobile Model from Enterprise

Content

Publish in Unwired Server

GenerateDevice

Artifacts

Sybase Unwired Platform Development Workflow

DevelopDevice

Application

Test on Emulator

and/or Device

44

Once a mobile package is available, the developer can generate device-side artifacts that form the basis of mobile application interactions with SUP services and data. One or more packages can be used within a single application. The same package version information is embedded in the device-side artifacts; this information matches the device application with the correct runtime version on the server. The specific development details of different application types vary; see the developer-specific guides for more information.

SUP also supports the “Open Data Protocol” (OData) as a back-end resource. OData is a resource-based Web protocol for querying and updating data. OData is owned by Microsoft, but has been released under the Open Specification Promise, allowing anyone to freely interoperate with OData implementations.

Where an OData source is used as the back end, the application developer does not need to create any model elements (MBOs) in the tooling, but rather inherits a service model from the service document published from the back end (as in SAP® NetWeaver® Gateway). These OData service documents contain all the information the device developer needs to parse and interact with these data streams.

coMMon eleMents of the architecture

Network TopologyMost components in the Unwired Platform architecture are installed alongside other corporate assets, while an

externally facing mobile data channel, the Relay Server, is installed in the DMZ. The Relay Server runs as a plug-in to either an Apache Web server or a Microsoft Internet Information Server (IIS). The Relay Server is a single point of contact for devices and is a specialized reverse proxy that avoids opening inbound ports in the firewall to the UnwiredServer1.

A Relay Server Outbound Enabler (RSOE) opens a bidirectional communication channel from inside the firewall outward to the Relay Server. This communication channel allows devices to communicate with the SUP server over one of several ports, depending on the specific purpose and technology. These connectivity services include facilities for these principle device-to-server transport technologies:

•Secure mobile messaging channel for reliable data transport and server-side notifications•Sybase MobiLink™ technology for efficient bulk data replication

Configure these ports either during installation or from within Sybase Control Center (SCC). As of SUP 2.1. the platform-specific notification facilities provided by the device manufacturers do not conform to the Relay Server semantics (your IT department must allocate an outbound port for APNS, BES, and so on).

Sybase Afaria® technology deploys device applications and helps configure those applications as well as managing, and helping to secure certain enterprise data on devices. Afaria technology interacts with the device platform’s local management facilities on the device to enforce enterprise policies. For some platforms, Afaria also offers an enterprise application store as an alternative to consumer-facing facilities.

1 Relay Sever is an optional component that may be replaced by other third-party proxy technologies or firewall management techniques.

5

HTTP/SHTTP/S

Relay Server

Afaria Server

Unwired Server

Unwired WorkSpace

(Eclipse)

SCCAdmin Console

DMZ

External NetworkInternal Network

InternalFirewall

ExternalFirewall

figure 4. Network Topology

The following sections describe some of the technology-specific SUP usage patterns and provide a general discussion of the architecture involved.

Administration and MonitoringThe Unified Agent Service acts as a central control and process monitoring facility for all Sybase server technology

(not to be confused with application monitoring, which is done in the core server stack). This JMX-based agent has an embedded Web server to which Sybase Control Center communicates, and an associated database for managing its own control and alerting metadata.

Distributed Level

Agent Level

MBean Server

Instrumentation Level

SQL Anywhere Sybase Servers

Unwired Servers

Sybase Control CenterSOAP

RPC Client

SOAP-RPC AdapterHTML AdapterRMI Connector

JMX Service Beans

Timer, Monitoring,Etc.

UDP, Jini, LDAPSecurity, Sessions,

File Transfer, RemoteShell, Discovery,

Messaging, Etc.

UAService Beans

Discovery Service Beans

figure 5. Management Infrastructure

66

From an administrative and deployment standpoint there are several hierarchies:•A host administrator has global control over the infrastructure.•A domain is associated with a configurable security context and can be used to implement multitenancy within

a single server runtime. A domain administrator can configure elements only for a domain to which he or she has been granted authorization.

•An application is associated with a security context and a set of packages.•Packages are deployed to the server within an administrative domain as an application.•Logging policies can be applied separately at the domain and package level.

Monitoring processes within the server record various application behavior, including device requests and application statistics. These records are written asynchronously to the monitoring database. Sybase recommends that you isolate this database on its own hardware if you perform a significant amount of monitoring during production in medium-to-large deployments.

Device ServicesAs an information bridge between the enterprise back end and the device, SUP provides several key features that

make developing applications much easier and more secure. Moving data securely and efficiently is one of the key value propositions of the platform. SUP uses two proprietary technologies to provide the best quality of service with regard to efficiency and seamless integration with the data store.

There are two main types of device applications — Hybrid Web container and native applications. The device stack supports a messaging protocol for devices built on the Hybrid Web container, and the SUP Data Orchestration Engine (DOE) supports native device applications with rule distribution. Native applications built without DOE utilize Sybase MobiLink technology to replicate data to the UltraLite® database.

Sybase Mobile SDK Archetypes

Core ApplicationServices

ApplicationSpecialization

SynchronizationServices

HTML5 / JSRuntime OData Parser

Native ObjectAPI

HTML5 / JSHybrid Apps

OData SDK

BusinessLogic Native Code HTML5 / JS

Runtime Native Code

Device User Interface Native Code HTML5 / JS

Runtime Native Code

SecuritySupportability and Configuration

Local Persistence and CacheConnectivity and Notifications

figure 6. Device Stack

Security features are embedded into the SDK to support secure certificate storage, use of these artifacts in authentication such as SSO (X.509 and SSO2 logon ticket), and other features related to database encryption. There are APIs for the certificate store, logon certificates, and the data vault. Each device application type makes use of the same set of security features.

7

Messaging ServicesThe workflow architecture, Hybrid Web applications, DOE, OData SDK, and notification mechanism leverage a

proprietary message transport to move data between device and server. This messaging transport is based on the HTTP protocol. The messaging protocol layered over HTTP provide quality of service for compression, encryption, and asynchronous guaranteed delivery.

Messaging may be synchronous or asynchronous; only asynchronous messaging provides guaranteed delivery between the device and the enterprise back end. In-transit asynchronous messages are stored in consolidated database (CDB) queues, and on the server and on the device they reside in the device database until processed by the mobile application infrastructure layers. These messages are encrypted on the device and in transit.

To receive messages, devices must be registered with the server via a process called “onboarding.” A device can be onboarded either manually (administratively whitelisted) or through an automatic process based on a security domain that is associated with the device user’s login credentials. Within Sybase Control Center, the administrator associates packages with a security domain under the heading of an “application” during deployment.

Security ServicesUnwired Platform provides pluggable Common Security Infrastructure (CSI) features for authentication,

authorization, and auditing. Users can authenticate against an array of authorities including LDAP and Active Directory. Secure connections can also be established with Secure Sockets Layer (SSL) between the device and replication channel. Device databases may also be encrypted with a user-supplied key.

Mobile workflow enableMentSybase Mobile Workflow technologies enable mobile device users to operate as workflow participants. SUP provides

the last-mile connectivity for workflow applications, allowing the mobile user to start and respond to back-end enterprise requests within a generic framework. Mobile Workflow utilizes the concept of a container on the device that is a native application with a Web browser plug-in and built in SDK for connectivity, guaranteed messaging, caching, and security. Mobile Workflow relies on messaging between the server and a container on a device that invokes either online operations to the back end or cached mobile business object (MBO) data in the Unwired Server.

Workflow ComponentsIn the workflow architecture, changes to back-end workflows, generally sent via data change notifications (DCNs),

result in the creation of messages that are sent to the messaging server for dispatch. Spooled messages that meet a specified set of matching criteria are placed in a queue for processing by the messaging transformer component, which augments the message with application-specific (MBO) data or processing instructions.

88

Messaging Service SUP Data Service

Message Processor

Device Messaging

Device Inbox

Application(s)

EIS

ConsolidatedDatabase

Mobile Device Message Interceptor DCN Servlet

DCN ServletTransformer Queue

Transformer

Response Processor

ResponseQueue

Responder

DB

MMS

JMS

Brid

ge

DS

JMSHost

figure 7. Workflow Architecture

Once transformed, the augmented message may be queued for transmission to the mobile device when the device next connects to the SUP server, or the message may be sent directly to the device. These messages are stored in the device’s in-box where they await the user’s actions. When a user loads an in-box message, the appropriate form is loaded by the workflow application, and the user may perform application-provided actions (such as approving an expense request).

The device user’s responses are sent back to the messaging server. Depending on the application, the response action may be queued, or may result in a synchronous action; this behavior is different from outbound message transformations, which are always queued. Regardless of whether the response action is queued or performed immediately, the application communicates with the SUP server to perform the action’s unit of work.

hybrid web container applicationsSUP Hybrid Web Container bridges the deficiencies of today’s mobile Web browsers with the power of device

OS services like GeoLocation, and so on. This paradigm enables developers to build rich applications using Web technologies and add functionality similar to what’s available in today’s native applications. SUP 2.1 includes a completely rewritten version of the client-side container technology than was available in earlier versions, which was based on proprietary client-side application definitions via XML and used to render the native application interface within the container.

Typical use cases for Hybrid Web container technology include mobile workflows, lightweight applications, and so on, that include these characteristics:

•Low data volume•Simple user experience•No long-lasting offline stateful transactions •Simple business logic

9

The Hybrid Web container supports three basic patterns. In many applications, a combination of these patterns are applied to implement specific use cases.

•Notifications — also referred to as server-initiated, these actions are performed in the back end by external applications in the context of a business process result in mobile users being notified with information.

•Lookup — mobile users take action on devices to request information from the back end.•Action/Decision Forms — users take action on devices to submit a form, make a decision, and so on, which results

in some enterprise business process state transition.

The Hybrid Web container is the runtime on the device within which these patterns are executed. The applications formed from these patterns are referred to as “Mobile Workflows” in the context of SUP 2.1, although technically, “workflow” is a specific use case of the general technology.

The Hybrid Web container is a native application with an embedded browser that allows developers to build applications with the simplicity of Web development combined with the power of native device services. SUP 2.1 delivers a native application for iOS, Android, Windows Mobile and BlackBerry platforms. In addition to the standard Web browser capabilities available in standard HTML/CSS/JS code, the Hybrid Web container also provides these additional device and SUP services:

•Offline cache•Reliable messaging•Secure store•Application provisioning• Integration with SUP middleware for MBO data exchange

In future versions, other device services such as camera, contacts, and so on are being planned.

Container Messaging Components

Hybrid Web Container Device RuntimeThis device-resident native application provides a runtime environment for Hybrid Web applications, and must

be deployed once using an application provisioning tool such as Afaria. Thereafter, applications are automatically deployed when the container runs on the device, and the protocol between the container and the server identifies version differences.

Container Services(Storage/Messaging/Security/Provisioning)

Container ClientMetadata

(HTML/CSS/JS)

Browser

Hybrid Web Container

Unwired Server

MBOCache Pull

Push/DCN

Lookup/Search

XML Messages

Container Metadata(HTML5/CSS/JS)

WorkflowServer

Metadata

SAP System

MBOMetadata

Container AppDesigner MBO Tooling

figure 8. Hybrid Web Components

1010

Mobile Workflow Forms EditorThe Mobile Workflow Forms editor is the WYSIWYG tool for building lightweight applications and Mobile Workflows

that run in the Hybrid Web Container. The Mobile Workflow Forms editor, which is included with Sybase Unwired Platform, is a tool that helps design the user interface and test the flow of the business process for a Hybrid Web Container application. Using the Mobile Workflow Forms editor allows you to develop mobile workflow screens that can call create, update, and delete operations, as well as object queries, of a mobile business object.

Mobile Workflow package files are generated using the Mobile Workflow Package generation wizard in the Mobile Workflow Forms editor. The generated Mobile Workflow package contains files that reference a mobile business object (MBO) package, an MBO in that package, and the operation or object query to call, as well as a mapping of which key values map to parameter values.

The generated Mobile Workflow package’s output is translated to HTML\CSS\JavaScript. The logic for accessing the data and navigating between screens is exposed as a JavaScript API. Mobile Workflow packages can be deployed to Unwired Server and assigned to users using the Mobile Workflow Forms editor in Eclipse.

MiddlewareThe container messaging architecture relies on SUP middleware to integrate and mobilize datasources using

the core SUP modeling concept called MBO. Middleware provides connectivity to various back ends through this intermediate MBO runtime construct, thereby providing a single interface for device application developers and abstracting the complexity of the back end. It also securely provisions Hybrid container applications based on the application assignments. The communication between the container and middleware is encrypted to enable confidentiality of message content.

Sybase Unwired WorkSpace/MBO ToolingUnwired WorkSpace is a key piece of the architecture that enables modeling mobile business objects (MBOs), which

are used for data transfer between the container and the back end through the middleware. This component is an Eclipse plug-in just like the Mobile Workflow Forms editor.

Administration ConsoleHybrid container applications are managed and deployed through the same management/administration console

used to manage SUP. This provides the ability to assign applications to devices/users based on regular expression-centric matching rules. This console also enables platform state monitoring, and provides metrics for tuning.

Mobile synchronization applicationsSynchronization applications provide transactional consistency between the mobile device, the middleware, and

the back-end system. These custom applications are designed and built to suit specific business scenarios, or may start with a bespoke application that is adapted with a large degree of customization. There are several application requirements to consider to determine the best SUP technologies to employ. Application designs that fail to take these criteria into account may have challenges in meeting their key performance indicators (KPIs).

Cache SynchronizationCache synchronization maps mobile data and service objects to SAP remote function calls (RFCs) using Java

Connector (JCO), and to other non-SAP data sources, such as databases and Web services. When SUP is used in a standalone manner for data synchronization, it utilizes replication-based synchronization (RBS) — an efficient bulk transfer and data insertion technology between the middleware cache and the device database.

In an SUP standalone deployment, the mobile application is designed such that the developer specifies how to load data from the back end into the cache, and then filters and downloads cache data using device-supplied parameters. The mobile content model and the mapping to the back end are directly integrated.

11

This style of coupling between the device and the back-end queries implies that the back end must be able to respond to requests from the middleware based on user-supplied parameters, and serve up mobile data appropriately. In other words, the back end should be capable of returning what an individual device user may request by supplying an appropriate interface. Normally, some mobile-specific adaptation is required within SAP Business Application Programming Interfaces (BAPI). Because of the direct nature of application parameter mapping and RBS protocol efficiencies, SUP cache synchronization deployment is ideal for:

•Rapid synchronization of large payloads to devices (may be due to mostly disconnected scenarios)•Situations where ad hoc data downloads might be expected•SAP or non-SAP back ends

Large payloads, for example, can occur in task worker (service) applications that must access large product catalogs, or where service occurs in remote locations and workers might synchronize once a day. While SUP replication-based synchronization does benefit from middleware caching, the direct coupling requires the back end to support an adaptation where mobile user data can be determined.

Cache Synchronization ComponentsThe goal of synchronization is to keep data views (that is, the state) consistent between the device and back-end

tiers. The assumption is that if data changes on one tier (for example, the enterprise system-of-record), all other tiers interested in that data (mobile devices, intermediate staging areas/caches, and so on) are eventually synchronized to have the same data/state.

Core ComponentsThe SUP server synchronizes data between the device and the back end by maintaining records of device

synchronization activity in its consolidated database, along with any cached data that may have been retrieved from the back end or pushed from the device. The SUP server employs several components in the synchronization chain:

•Mobile channel interfaces — provide a conduit for transporting data from and to remote devices. There are two main channel interfaces that provide messaging and replication:

– Messaging channel — serves as the abstraction to all device-side notifications (BES, APNS, and others) so that when changes to back-end data occur, devices can be notified of changes relevant for their application and configuration. This channel is also used to enable data synchronization on iOS.2

– Replication channel — serves as the conduit over which data is replicated between devices and the mobile middleware. This is an efficient database row replication technology.

•Mobile Middleware Services (MMS) — arbitrates and manages communications between device requests from the mobile channel interfaces in the form that is suitable for transformation to a common MBO service request and a canonical form of EIS data supplied by data services.

•Data Services (DS) — is the conduit to enterprise data and operations within the firewall or hosted in the cloud. DS and MMS together manage the consolidated database (CDB), where data is cached as it is synchronized with client devices.

Once a mobile application model is designed, it can be deployed to the SUP server where it operates as part of a specialized container managed package interfacing with MMS and DS components. Cache data and messages are persisted in the databases in the data tier.

Changes made on the device are passed asynchronously to the MMS component (with respect to the download) and replayed in their own thread against the data services interfaces with the back end. Data that changes on the back end as a result of device changes, or those originating elsewhere, is replicated to the device database. This download phase occurs either because the device receives a notification causing the device to synchronize (if so configured) or because the user manually invokes synchronization.

2 In a future release, cache synchronization will use the replication channel for iOS as is currently done with all other devices.

1212

figure 9. SUP Cache Synchronization Architecture

The CacheCache-based synchronization uses the cache as a mirror of what users see on the device. While the cache is not

the system-of-record, it allows the server to compare the last time cache elements were updated with the time the specific data elements on the device were last successfully synchronized. This mechanism allows the server to download only the elements that have changed since the last device synchronization.

The cache is manifested in the consolidated database (CDB), which is a relational database management system. The server, or more specifically the application package hosted in the application server, communicates to the CDB through JDBC connection pools, which can be configured in the administration console. The MBO parameters and the relationship between MBOs define the shape of cache tables. The internal implementation of these tables and the associated queries are not public and may change from release to release.

Each package has its own cache, and the life cycle of the cache is the same as the package. If the package is removed from the server, the cache is removed. Cache data can be shared or partitioned based on application parameters defined in the MBO model. If an MBO definition loads data where two application users have overlapping synchronization parameters, the users are sharing the same data. However, if the application model defines the MBO load parameters in way that makes the data unique to a user (for example, an employee ID) then the cache is partitioned and not shared.

Shared cache data is typically reference or master data that is not updated by device users. Updating shared data incurs locking costs in the server and should be, if possible, performed infrequently and during periods of low user activity. The validity of cached data, like reference data, can be made invalid by configuring a cache group. By default, all MBOs belong to the same cache group. Available refresh settings for a cache group include:

•On (device) demand with a specified window of cache coherency•Periodically after initial load•Once for use where the initial load is done with a load query•Always valid because the cache group is updated by DCN

Cluster DB

User Agent DB

AdvantageMessaging DB

MBS Client

Application(s)

Mobile Devices

SUP Data Tier(Active/Passive HA)

Public Network DMZ Private Network

UltraLite

RBS Client

UltraLite

Relay Servers

LDAP Server

Unwired Server (Clustered)

Outbound Queue

Inbound Queue

Messaging Channel

Replication Channel

Unified Agent Service

MobiLink

SybaseControl Center

JMSHost

Mob

ile M

iddl

ewar

eSe

rvic

es

Dat

a Se

rvic

es

Data Change

Notification

ConnectionPools

ConsolidatedDatabase

UnwiredWorkspace

Jaas

Enterprise Information Systems

SAP Applications

DatabasesSOAP/REST

Services

Mes

sage

Sync

Web

13

Once the device demand or cache schedule triggers a load, all elements in the cache group are refreshed. To the extent possible, the MBO model should be designed to partition user data (via a unique user-specific key) that is meant to be updated from the device.

The cache can be updated by either a device user with the proper security role or by a data change notification (DCN). When a device updates the cache, the changes from a result set can be optionally written to the cache along with the update to the back end.3 Alternatively, a portion of the cache can be invalidated, whereupon it is refreshed. However, do not use this method when a DCN is used to populate the cache, since the server needs an operation to update the cache when it is invalidated.

The DCN is a HTTP/JSON intranet-facing interface exposed through the built-in Web server for each package and its associated MBOs, with the intent that the back end may proactively send changes to update the cache. Properly authenticated DCNs may send complete payload changes or notifications that something has changed (causing the cache to be invalidated for that record).

synchronization with data orchestration engine (doe)The SUP DOE deployment option provides additional flexibility, allowing the system designer to model and

consolidate SAP mobile content in the middle tier and separately layer distribution rules over this content. This approach is especially useful where back ends cannot provide a mobile interface that serves up mobile data, or where additional flexibility is required. This approach allows distribution rules to evolve separately from the content model and for different distribution rule sets to be used with the same content model. Even customers can change the rules without rewriting client or back-end code, after actively deploying applications.

The technology to enable this behavior is built directly into the NetWeaver stack and is therefore best suited to SAP-only implementations or where third-party back-end integration is already provided through NetWeaver. This method specifies BAPI CRUD interfaces to adapt back-end suite datasources to the middleware data consolidation area.

The SUP DOE option consolidates all mobile data from the back-end SAP system, then uses rules to determine mobile distribution. The rules are fired on these events:

•New device is registered — initial receiver determination•Back-end data or client data changes because of user updates or batch updates — the staging area is updated•Business change resulting in change of user subscriptions, for example, moving from region A to region B —

device realignment

The SUP DOE option is ideal where:•The SAP back end cannot directly support mobile queries, or mobile queries place an unacceptable load on the

back end•The design dictates that the data distribution take place in the middleware•Multiple customized SAP back ends must interface to the same mobile application, for example, where a mobile

application is developed once and resold to multiple customers who use different distribution rules •Customized conflict resolution is required within the mobile middleware (as opposed to the back end)

3 Restrictions apply to the mapping of back-end operations that are intended to update the cache so that the MBO attributes in the cache are properly maintained. During an update with this policy the back-end data may not be properly reflected in the cache if the back end further updates fields that have been applied during the cache write-through. This issue will be addressed in a future version of the server.

14

Data Orchestration Engine (DOE) ArchitectureThe SUP DOE architecture differs from cache synchronization in some significant ways. The DOE mobile model

design phase does not use Eclipse tooling; the content model description are configured in the DOE in Data Orchestration Workbench.

figure 10. DOE Runtime Architecture

Data ConsolidationBack-end adapters enable DOE to connect to the source EIS in a loosely coupled way. To be able to communicate

with the corresponding DOE back-end adapter, the EIS must expose business data by implementing a set of services. In the case of SAP Business Suite, these services are implemented as ABAP function modules called BAPI wrappers. BAPI wrappers are remote function call (RFC)-enabled and can retrieve or update multiple data sets simultaneously. DOE uses the RFC to retrieve business data from the back end (push and pull) as well as to send data updates performed on the mobile client to the back end.

Back-end adapters also provide functionality to map data from source EIS to DOE data representations. Back-end EISs and (device) receivers may use different keys to identify data; therefore, mapping may be required. Custom services, similar in semantics to the BAPI wrappers, must be developed for each other EIS.

To enable a fast and scalable synchronization process, DOE consolidates the business data required by the receivers. DOE requests data from the source EIS and stores a replica of that data in its own store, called the consolidated data store (CDS). Within the DOE, data objects represent the structure or schema of the data in the back end. In the back-end EIS, business objects or database tables provide the data for the data objects. Examples of business objects are sales orders and customers.

Schemas for data exchange or data objects are defined at design time. At runtime, when actual data is exchanged between the EIS and DOE, data from these back-end sources is stored as instances of data objects. The data consolidation component, maintains integrity across the data object instances even if the data for the same data object is coming from different back-end sources. For example, sales order data is received from the SAP CRM system, whereas product master data is received from SAP ERP.

R

R

R

R

R

R

Data Orchestration Engine

R

R R

RR

R

R

R

Data Consolidation Client Connectivity and Transport

Client Channel Framework

GenericSynchronization API Queues

Traces and Logs

Monitoring & Central Inbox

Data Distribution

Distribution Engine

DistributionModel

ReceiverMetamodel

ReceiverInventory

DOEReceiver

Administrator

DataDistribution

Service

RuleEvaluation

ServiceExtractService

AssociationTables

SubscriptionTables

Consolidated Data Store

Consolidated Data Store Service

NW MobileClient

Channel

SUPTransportChannel

Backend Adapter

DOE Flow Manager

Standard DataObject Flow

KeyMappingService

KeyLookupTables

ConflictDetection

Service

CustomService

ValidationService

Hierarchy DataObject Flow

ReceiverGeneration

Flow

SubscriptionGeneration

Flow

Data ObjectModel

FlowDefinition

DOE DesignTime Modeler

Semantic Data Adaptation(CRUD + Events for BusinessObjects)

EnterpriseApplication

CRUDServices

ApplicationData Store

R

15

The integrity constraints between these different data objects are specified by defining associations and dependencies. Data from the CDS is sent to receivers according to data distribution rules. The receivers may modify the data and send updates to DOE. DOE sends the modified data back to the original source (EIS) of the data object for validation. Only validated data is updated to the CDS, and confirmations of successful validations and modifications are sent back to the receiver that initiated the modification. In case of rejections by the EIS, negative acknowledgements are sent to the receivers.

Data DistributionIn the CDS, business data is stored in a format that is optimized for data distribution. The data distribution

component determines which data to send to each receiver, (receiver determination) and triggers the distribution. The receiver determination is based on rules, which determine the data to be sent to an individual receiver. Subscription is the assignment of a data object instance to a receiver. Data distribution comprises:

•Receiver management•Subscription management•Receiver determination

The DOE supports automated generation of receivers and their subscriptions based on rules. All receivers in the DOE are stored in the receiver inventory. The attributes of a receiver are defined by the receiver meta model (RMM).

Subscriptions can be generated automatically when new receivers are added to the DOE. New receivers can be added based on available back-end EIS information. All data that effects creation of new subscriptions is updated from the EIS into the DOE using data objects. For example, sales order information must be distributed to sales representatives, each of whom carries a smartphone. Each sales rep should receive only sales orders relevant for the region to which he or she is assigned. The IT department’s asset inventory stores information about which employee is assigned to which smartphone device.

Furthermore, the SAP CRM and SAP ERP systems provide information about the sales region where a specific employee is working. A simple rule stating that data distribution of sales orders to sales representatives based on sales region can be executed automatically, without administrator intervention. DOE automates the process to the extent that whenever a new employee is added in the ERP or CRM back-end system and is assigned to a new smartphone device that is recorded in the asset inventory store, the employee instantly starts receiving daily work-related data on his or her device, including new software if required.

The rules governing the creation of a subscription are stored within a distribution model. Based on these rules, the DOE performs receiver determination to calculate which receiver needs which data. To do so, the receiver determination component first compiles the rules into a form that can be used efficiently, in terms of execution time, at runtime. The relationship between the data object instances from the CDS and the receiver is explicitly precomputed and stored in lookup tables.

The compiled form of the rules of the distribution model is also stored in the lookup tables. Whenever a subscription changes due to a change in the governing rules, the data distribution component recalculates the relationship for the corresponding receiver and updates the lookup tables. Existing data may need to be deleted from receivers, or new data may be required to be associated with existing receivers.

For example, the distribution of sales orders to the smartphones of sales representatives is based on the sales region. A receiver-determination step is triggered whenever a sales order message with updated region information comes from the back-end system, or whenever a new user is created in the back-end system. To handle thousands of receivers, the algorithm is optimized for handling a mass volume of updates.

16

DOE as a Component in SUPOnce the data model and rules are ready to be deployed, a package artifact known as Entity Set Definition for

Mobile Applications (ESDMA) communicates the application definition from within the DOE. The ESDMA deployment tool creates the runtime artifacts in the Sybase Unwired server.

The runtime artifacts in the Sybase Unwired server are limited to reliable delivery of messages both to and from devices. Data staging is performed in the DOE middleware, while message store and forward is performed in the SUP messaging layers. A message-based server interconnect is used between the Sybase SUP server and its DOE component. Messaging, rather than DB replication, moves data between the back end and devices.

Sybase Unwired Platform with DOE

SUP Connector(SOAP XML +

ESDMA Bundle)

SAP Backend

BAPI Wrapper, Events,Filters

SAP Business Suite

BASIS 7.0

ERP PLM…CRMDOE Consolidation

and RulesDistribution

BASIS 7.1

Sybase DOEConnector

ESDMAConverter

Sybase UnwiredPlatform

Device Sync Stack

Device Workflow

Stack

Push Messaging

Data Object, DistributionModel, ESDMA

Sybase Mobile AppDevelopment Tools

Sybase Admin Console

figure 11. SUP DOE Architecture

The DOE Connector (DOE-C) is the reliable bidirectional interconnect component between SUP and DOE. This interconnect transports the XML payload, and the SUP messaging layers transform this payload to a form suitable for transmission to the devices. A reliable, encrypted, compression-capable, messaging infrastructure is used between the SUP server and the device. Once on the device, client-side messages are stored within the message-based synchronization (MBS) SDK persistence framework.

Monitoring of SUP messages in the store and forward infrastructure takes place in Sybase Control Center.

sap odata applicationsThe SAP NetWeaver Gateway exposes OData with extensions specific to SAP. SUP incorporates facilities for

publishing these service documents and allowing users to interact with the Gateway runtime, which then interacts with the SAP application suite. SUP provides administrative facilities for discovering OData service documents and allowing devices to communicate with those enterprise services.

The SUP normal device onboarding and security facilities are used when communicating to OData sources. Devices can be administratively whitelisted or automatically registered with the SUP server based on authentication with a security domain.

17

ODataApplication(s)

Mobile Devices

Public Network DMZ Private Network

Relay Servers

Unwired Server

Data Services

Jaas

Cluster DB

User Agent DB

Monitor DB

SUP Data Stores

ConsolidatedDatabase

Data Change

Notification

HTTPCallbackRouter

LDAP Server

Single Signon URL

ConnectionPools

SAP Applications

Unified Agent Service

Messaging Channel ContainerServices

Domain Logging

Load

Bal

ance

r

Rela

y Se

rver

Out

boun

d En

able

rOData SDK

HTTP Messaging Proxy

MessagingChannel

Security/ConfigLogging

Sybase ControlCenter

Outbound Queue

Inbound Queue

Async Channel

Sync Channel

JMSHost

HTTPProxy

Handler

Mobile Middleware

Services

figure 12. SUP OData Infrastructure for NetWeaver Gateway

When device applications communicate with the Gateway, they do so with a synchronous message interface (providing their own retry capability for interrupted communications). The synchronous interface avoids message queues on the device, in the middleware, and associated database disk I/O, and may allow horizontal scaling of the middleware. Using synchronous messaging where a seamless online and offline experience is required places additional burden on the application developer.

Device users may publish their logical device address to the Gateway, allowing data change notifications to be forwarded from the Gateway to SUP and onto the device. These notifications are guaranteed to be delivered to the device. Device notifications may be registered over device platform-specific channels like APNS or BES.

As with other messaging facilities, monitoring and logging of messages is managed through the Sybase Control Center management console.

www.sybase.com

Sybase, Inc. Worldwide HeadquartersOne Sybase DriveDublin, CA 94568-7902U.S.A1 800 8 sybase

Copyright © 2011 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase, the Sybase logo, Afaria and MobiLink are trademarks of Sybase, Inc. or its subsidiaries. ® indicates registration in the United States of America. SAP, the SAP logo and SAP NetWeaver are the trademarks or registered trademarks of SAP AG in Germany and in several other countries. All other trademarks are the property of their respective owners. 11/11