sybase unwired platform version 2.1 - architecture.pdf

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



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



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.



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



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



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.



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



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.



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.



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



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



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.



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.



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


UnwiredWorkspace

Jaas

Enterprise Information Systems

SAP Applications

DatabasesSOAP/REST

Services

M e s s a g

e

S y n c

W e b



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.



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



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.



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.



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


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.



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

sybase unwired platform version 2.1 - architecture.pdf

Documents