WHITE PAPER www.sybase.com Sybase ® Unwired Platform Version 2. 1 Architecture
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 1/20
WHITE PAPER
www.sybase.com
Sybase® Unwired Platform Version 2.1
Architecture
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 2/20
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.
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
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 3/20
1
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 thebusiness 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 U I 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 landscape2. 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.
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 4/20
2
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
Management Console
ControlDevice and server management and security
BlackBerry
iPhone
iPad
Android
Windows
Windows Mobile
ConsumeHeterogeneousmobile devices
ConnectHeterogeneous
data sources
Create
Eclipse
Databases
WebServices
Software
Applications
Mobile
BusinessObjects
Native
Applications
Hybrid Web
Container
Sybase Unwired Platform
ODataInterface
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
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 5/20
3
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
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 MobileModel fromEnterprise
Content
Publish inUnwired Server
GenerateDevice
Artifacts
Sybase Unwired Platform Development Workflow
DevelopDevice
Application
Test onEmulator
and/or Device
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 6/20
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 s erver. 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 protoco
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 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.
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 7/20
5
Relay Server
Afaria Server
Unwired Server
UnwiredWorkSpace
(Eclipse)
SCCAdmin Console
DMZ
External NetworkInternal Network
Internal
Firewall
External
Firewall
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 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
Agent Level
MBean Server
Instrumentation Level
SQL Anywhere SybaseServers
UnwiredServers
Sybase Control Center
SOAP
RPC Client
SOAP-RPC AdapterHTML AdapterRMI Connector
JMXService Beans
Timer, Monitoring,
Etc.
UDP, Jini, LDAP Security, Sessions,
File Transfer,
RemoteShell, Discovery,Messaging, Etc.
UAService Beans
DiscoveryService Beans
Figure 5. Management Infrastructure
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 8/20
66
From an administrative and deployment s tandpoint there are s everal 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
Sybase MobiLink technology to replicate data to the UltraLite® database.
Sybase Mobile SDK Archetypes
CoreApplicationServices
ApplicationSpecialization
SynchronizationServices
HTML5 / JSRuntime
OData Parser
Native ObjectAPI
HTML5 / JSHybrid Apps
OData SDK
BusinessLogic Native Code HTML5 / JS
RuntimeNative Code
Device User
InterfaceNative Code HTML5 / JS
RuntimeNative Code
Security
Supportability and Configuration
Local Persistence and Cache
Connectivity 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.
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 9/20
7
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 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 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.
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 10/20
88
Messaging Service SUP Data Service
Message Processor
Device Messaging
Device Inbox
Application(s)
EIS
ConsolidatedDatabase
Mobile Device
Message Interceptor DCN Servlet
DCN ServletTransformerQueue
Transformer
Response Processor
ResponseQueue
Responder
DB
MMS
J M S
B r i d g e
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 us er’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 s erver. 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 APPLICATIONS
SUP 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
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 11/20
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. SU P 2.1
delivers a native application for iOS, Android, Windows Mobile and BlackBerry platforms. In addition to the s tandard
Web browser capabilities available in s tandard 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 automaticallydeployed 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
MBO
Cache Pull
Push/DCN
Lookup/Search
XML Messages
Container Metadata(HTML5/CSS/JS)
Workflow
Server
Metadata
SAPSystem
MBO
Metadata
Container AppDesigner
MBO Tooling
Figure 8. Hybrid Web Components
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 12/20
1010
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 objec
(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.
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 expression-
centric 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.
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 13/20
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 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.
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 14/20
1212
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 s ame 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
M o b i l e M i d d l e w a r e
S e r v i c e s
D a t a S e r v i c e s
DataChange
Notification
ConnectionPools
ConsolidatedDatabase
UnwiredWorkspace
Jaas
Enterprise Information Systems
SAP Applications
DatabasesSOAP/REST
Services
M e s s a g
e
S y n c
W e b
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 15/20
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 andconsolidate 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.
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 16/20
14
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.
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 bus iness 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 s chema 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 sys tem,
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
Service
ExtractService
AssociationTables
SubscriptionTables
ConsolidatedData Store
Consolidated Data Store Service
NW MobileClient
Channel
SUPTransportChannel
Backend Adapter
DOE FlowManager
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
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 17/20
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 successf ul 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 s end 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 newsmartphone 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 f rom 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 fromreceivers, 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.
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 18/20
16
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 f rom 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
DeviceSyncStack
DeviceWorkflow
Stack
P u s h M e s s a gi n g
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 us ed 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 O DATA AP PLICATIONS
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 s uite. 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.
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 19/20
17
ODataApplication(s)
Mobile Devices
Public Network DMZ Private Network
Relay
Servers
Unwired Server
DataServices
Jaas
Cluster DB
User Agent DB
Monitor DB
SUPData Stores
ConsolidatedDatabase
DataChange
Notification
HTTP CallbackRouter
LDAP Server
Single Sign
on URL
ConnectionPools
SAP Applications
Unified Agent Service
Messaging Channel Container
Services
Domain Logging
L o a d B a l a n c e r
R e l a y S e r v e r
O u t b o u n d E n a b l e r
OData SDK
HTTP MessagingProxy
MessagingChannel
Security/ConfigLogging
Sybase ControlCenter
Outbound Queue
Inbound Queue
Async Channel
Sync Channel
JMSHost
HTTP Proxy
Handler
MobileMiddleware
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.
8/8/2019 Sybase Unwired Platform Version 2.1 - Architecture.pdf
http://slidepdf.com/reader/full/sybase-unwired-platform-version-21-architecturepdf 20/20
Sybase, Inc.
Worldwide Headquarters
One Sybase Drive
Dublin, CA 94568-7902
U.S.A
1 800 8 sybase
Copyright © 2011 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase, theSybase logo, Afaria and MobiLink are trademarks of Sybase, Inc. or its subsidiaries. ® indicates registration in the