white paper

Sybase Unwired Platform Version 2.1

Architecture

www.sybase.com

Table of Contents
1 Mobilizing the Enterprise
1 Online Mobile Applications
1 Offline Mobile Applications
1 Common Characteristics
2 Overview of the Sybase Unwired Platform
3 Basic Development and Deployment Process
4 Common Elements of the Architecture
4 Network Topology
5 Administration and Monitoring
6 Device Services
7 Messaging Services
7 Security Services
7 Mobile Workflow Enablement
7 Workflow Components
8 Hybrid Web Container Applications
9 Container Messaging Components
10 Mobile Synchronization Applications
10 Cache Synchronization
13 Synchronization with Data Orchestration Engine (DOE)
16 SAP OData Applications

Introduction
This 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.

Mobilizing the Enterprise

Individuals 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 Applications
Online 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 Applications
Offline 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 Characteristics
Both online and offline applications require these common IT and application management capabilities:
1. Secure onboard processes to bring user devices into the enterprise landscape
2. Device, data, and transport security
3. Ability to troubleshoot error conditions with supportability toolsets
4. Remote device management
These common characteristics introduce a need for a common platform covering both application categories.

Overview of the Sybase Unwired Platform

The 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

Connect

Databases

Consume

Create

Heterogeneous
data sources

Heterogeneous
mobile devices

Eclipse

BlackBerry

Sybase Unwired Platform

iPhone

Web
Services

Software
Applications
SAP
NetWeaver
Gateway

iPad
Mobile
Business
Objects

Hybrid Web
Container

OData
Interface

Native
Applications

Android
Windows
Windows Mobile

Management Console

Control

Device and server management and security

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.

Basic Development and Deployment Process

In 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

customer
Attributes (9)
Q
Q
Q
Q
Q
Q
Q
Q
Q

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

Operations (3)
update()
delete()
create()

Subset

Personalize

Mobilize

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.

Sybase Unwired Platform Development Workflow

Develop Mobile
Model from
Enterprise
Content

Publish in
Unwired Server

Generate
Device
Artifacts

Develop
Device
Application

Test on
Emulator
and/or Device

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.

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 Topology
Most 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 platforms 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.

Internal Network

External Network
Internal
Firewall

Unwired
WorkSpace
(Eclipse)

External
Firewall

DMZ

Unwired Server

SCC
Admin Console

Relay Server
Afaria Server

Figure 4. Network Topology

HTTP/S

HTTP/S

The following sections describe some of the technology-specific SUP usage patterns and provide a general
discussion of the architecture involved.
Administration and Monitoring
The 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

Sybase Control Center

SOAP
RPC Client

RMI Connector

HTML Adapter

SOAP-RPC Adapter

JMX
Service Beans

UA
Service Beans

Discovery
Service Beans

Timer, Monitoring,
Etc.

Security, Sessions,
File Transfer,
RemoteShell, Discovery,
Messaging, Etc.

Agent Level
MBean Server

UDP, Jini, LDAP

Instrumentation Level

SQL Anywhere

Sybase
Servers

Unwired
Servers

Figure 5. Management Infrastructure

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 Services
As 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
SybaseMobiLink technology to replicate data to the UltraLite database.

Sybase Mobile SDK Archetypes

Device User
Interface

Native Code

HTML5 / JS
Runtime

Native Code

Business
Logic

Native Code

HTML5 / JS
Runtime

Native Code

Synchronization
Services

HTML5 / JS
Runtime

OData Parser

Application
Specialization

Security

Core
Application
Services

Supportability and Configuration

Local Persistence and Cache
Connectivity and Notifications
Native Object
API

HTML5 / JS
Hybrid Apps

OData SDK

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.

Messaging Services
The 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 users login credentials. Within Sybase Control Center, the administrator associates
packages with a security domain under the heading of an application during deployment.
Security Services
Unwired 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 Enablement

Sybase 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 Components
In 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.

Message Processor

Mobile Device

Message Interceptor

Device Inbox

Transformer
Transformer
Queue

Device Messaging
DB

SUP Data Service

JMS Bridge

Messaging Service

DCN Servlet

JMS
Host

EIS

DCN Servlet
MMS

Response Processor

Application(s)

Responder
Response
Queue

DS
Consolidated
Database

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
devices in-box where they await the users 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 users 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 actions unit of work.

Hybrid Web Container Applications

SUP Hybrid Web Container bridges the deficiencies of todays 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 whats available in todays 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

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 Runtime
This 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 App
Designer

MBO Tooling

Container Metadata
(HTML5/CSS/JS)
Container Client
Metadata
(HTML/CSS/JS)

Workflow
Server
Metadata

Unwired Server

Lookup/Search

Browser
Container Services
(Storage/Messaging/
Security/Provisioning)

Hybrid Web Container

MBO
Metadata

MBO
Cache

Pull

Push/DCN

SAP
System

XML Messages
Figure 8. Hybrid Web Components
9

Mobile Workflow Forms Editor

The 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 packages 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.
Middleware
The 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 Tooling
Unwired 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 Console
Hybrid 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 expressioncentric matching rules. This console also enables platform state monitoring, and provides metrics for tuning.

Mobile Synchronization Applications

Synchronization 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 Synchronization
Cache 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.

10

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 Components
The 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 Components
The 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.
11

Public Network

DMZ

Private Network

Application(s)

Inbound Queue

UltraLite
Relay
Servers

UltraLite

Web

Sync

MBS Client

RBS Client

JMS
Host

Outbound Queue

Replication Channel

Jaas
Data Services

Mobile Devices

Messaging Channel
Mobile Middleware
Services

Message

Unwired Server (Clustered)

LDAP Server
Connection
Pools

SUP Data Tier

MobiLink

(Active/Passive HA)

Unified Agent Service

Sybase
Control Center

Data
Change
Notification

Consolidated
Database
Cluster DB

Enterprise Information Systems

Unwired
Workspace

Databases
SAP Applications

SOAP/
REST
Services

User Agent DB
Advantage
Messaging DB

Figure 9. SUP Cache Synchronization Architecture

The Cache
Cache-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
12

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 SAPonly 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.

13

Data Orchestration Engine (DOE) Architecture

The 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.

Data Orchestration Engine

Data Consolidation

Enterprise
Application
R
CRUD
Services

Client Connectivity and Transport

Backend Adapter

NW Mobile
Client
Channel

Semantic Data Adaptation

(CRUD + Events for BusinessObjects)

Client Channel Framework

R
Application
Data Store

Standard Data
Object Flow

Key
Mapping
Service

Conflict
Detection
Service

Receiver
Generation
Flow

Validation
Service

Subscription
Generation
Flow

Hierarchy Data
Object Flow

Generic
Synchronization API

DOE Flow
Manager

Data Object
Model

SUP
Transport
Channel

Custom
Service

Flow
Definition

Key
Lookup
Tables

Queues

R
Consolidated Data Store Service

Traces and Logs

Consolidated
Data Store

R
Monitoring & Central Inbox
R

R
Data Distribution

Distribution Engine
R

DOE Design
Time Modeler

Data
Distribution
Service
Distribution
Model

Rule
Evaluation
Service
Receiver
Metamodel

Extract
Service

Receiver
Inventory

Association
Tables

Subscription
Tables
DOE
Receiver
Administrator

Figure 10. DOE Runtime Architecture

Data Consolidation
Back-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 backend 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.
14

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 Distribution
In 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 departments 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 workrelated 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.

15

DOE as a Component in SUP

Once 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.

SAP Backend

Sybase Unwired Platform with DOE

Data Object, Distribution
Model, ESDMA

SAP Business Suite

SUP Connector
(SOAP XML +
ESDMA Bundle)

Sybase DOE
Connector

DOE Consolidation
and Rules
Distribution

ESDMA
Converter

ERP

CRM

PLM

BASIS 7.0

BASIS 7.1

Sybase Mobile App

Development Tools

Sybase Unwired
Platform

Sybase Admin Console

Push Messaging

BAPI Wrapper, Events,

Filters

Device
Sync
Stack

Device
Workflow
Stack

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 Applications

The 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.

16

Public Network

DMZ

Private Network
Unwired Server
Container
Services

Messaging Channel

OData
Application(s)

Outbound Queue

OData SDK
HTTP Messaging
Proxy
Security/Config
Logging

Relay
Servers

Relay Server
Outbound Enabler

Async Channel

Load Balancer

Mobile Devices

Inbound Queue

Sync Channel

Data
Change
Notification

JMS
Host

Mobile
Middleware
Services

HTTP
Callback
Router

Data
Services

HTTP
Proxy
Handler

Messaging
Channel

Domain Logging
Unified Agent Service

Jaas

LDAP Server
Single Sign
on URL

Connection
Pools

SUP
Data Stores
Consolidated
Database
Cluster DB
Monitor DB

Sybase Control
Center

User Agent DB
SAP Applications

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.

17

Sybase, Inc.
Worldwide Headquarters
One Sybase Drive
Dublin, CA 94568-7902
U.S.A
1 800 8 sybase

www.sybase.com

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