white paper

Sybase Unwired Platform Version 2.1

Architecture

www.sybase.com

table of contents 1 Mobilizing the Enterprise 1 1 1 2 4 Online Mobile Applications Offline Mobile Applications Common Characteristics

Overview of the Sybase Unwired Platform 3 Basic Development and Deployment Process Common Elements of the Architecture 4 Network Topology 5 Administration and Monitoring 6 Device Services 7 Messaging Services 7 Security Services

7 8 10 13 16

Mobile Workflow Enablement 7 Workflow Components Hybrid Web Container Applications 9 Container Messaging Components Mobile Synchronization Applications 10 Cache Synchronization Synchronization with Data Orchestration Engine (DOE) SAP OData Applications

introduction This document is for service providers and enterprises that plan to deploy the Sybase Unwired Platform (SUP) and need a functional understanding of the technology to assist in making informed decisions about choosing the correct mobile technology to use for a particular use case. It includes some level of detail about the internal workings of the platform that may prove useful to administrators. This document serves as a foundation for other more specific explanations of technical aspects of the system, for example, sizing, performance and tuning, architecture approaches, and security. Developers may find it useful to consult other material specifically related to development fundamentals or tutorials.

Mobilizing the enterprise Individuals and businesses develop mobile applications for specific user needs ranging from teams of service workers who use ruggedized devices for industry-specific applications, consultants who track time and expenses on a mobile device, or simple corporate approvals. Sybase Unwired Platform supports these mobile scenarios as well as cross-industry applications, such as customer relationship management, human resources, supply chain management, business intelligence, product life cycle management, and industry-specific applications tailored for the service provider, chemical/pharmaceutical, and utilities industries. All these mobile applications follow two broad patterns; the pattern used depends primarily on who is driving the use case. End-user driven, where an end user looks for the information that he or she wants, for example, an employee lookup IT- or LOB-driven, to improve organizational efficiency and customer engagement, for example, sales process enablement These two patterns inherently represent two broad categories of mobile applications, which can be called online mobile applications and offline mobile applications. These two classes of applications differ significantly in functional and some nonfunctional aspects. However, they share common attributes, such as security. Online Mobile Applications Online mobile applications are completely user-driven, and IT is seldom involved in their operation. Information access is ad hoc in nature, and users typically know what they are looking for in a given situation. Technically, online suggests these attributes: Request/reply interactions directly with the back-end system Lightweight form editing Situation-oriented toward a few screens rather than a complex application Targeted notification from the back end gives alerts to the user Offline Mobile Applications Offline applications are typically driven by IT or Line-of-Business (LOB) to gain organizational efficiency. IT is very much involved in mobile operations for most offline cases, information access is formalized in nature, and the business process dictates the information that each user will act on. In general, offline applications are task oriented, and must provide mission-critical information to end users, regardless of connectivity. Characteristics of offline applications include: Data synchronization to devices is based on enterprise-level process rules Task-oriented covering a complete process, resulting in complex UI navigations Ready for heavy customization, since processes are unique per enterprise Push-enabled for real-time user experience Strong administrative tools for support, monitoring, and data and conflict management Common Characteristics Both online and offline applications require these common IT and application management capabilities: 1. Secure onboard processes to bring user devices into the enterprise landscape 2. Device, data, and transport security 3. Ability to troubleshoot error conditions with supportability toolsets 4. Remote device management These common characteristics introduce a need for a common platform covering both application categories.

overview of the sybase unwired platforM The Unwired Platform primary value proposition is in serving as an information bridge between device users and enterprise data that is secured behind the corporate firewall or hosted in a cloud infrastructure. The platform, as mobile middleware, includes a range of components that are hosted within the enterprise and on the device. These platform technologies are hosted under a common design, runtime, and management infrastructure that provides: Connectivity to multiple client device types and mobile operating systems Support for native client object-based APIs based on the device platform language Support for mobile Web-based clients within a secure enterprise sandbox Eclipse-based visual development tooling for building mobile data services and generating device-side data persistence APIs Enterprise mobilization architecture that uses standard and proprietary interfaces to support a variety of enterprise data resources End-to-end pluggable security that extends from the enterprise to devices Support for mobile users who are either occasionally connected or those that work entirely online Push notifications that alert clients to refresh their mobile view of data Unified platform administration and monitoring

Heterogeneous data sources Databases

Connect

Create
Eclipse

Consume

Heterogeneous mobile devices

Sybase Unwired Platform

BlackBerry iPhone iPad

Web Services Mobile Business Objects OData Interface Hybrid Web Container Native Applications

Software Applications SAP NetWeaver Gateway

Android Windows Windows Mobile

Management Console Device and server management and security

Control

figure 1. Platform Overview

In Unwired Platform, one or more of these technologies come together to provide support for a few major types of mobile applications, including: Hybrid Web container applications: Simple cross-platform request/reply or lookup Mobile workflow enablement Native applications using synchronization: Result-set cache synchronization in an SUP standalone mode Data consolidation and distribution with the Data Orchestration Engine (DOE) Native applications using the SUP OData SDK: Simple device-specific request/reply or lookup with rich UI The purpose and function of the major application pillars is discussed in more detail later in this document, along with the major technology components that support them.

Basic Development and Deployment Process In cases where a model is developed specifically for SUP, the developer starts building an application by using Eclipse-based tooling to discover assets of enterprise datasources and to tailor the mobile interaction pattern (which usually involves selecting data subsets) for mobilization. The most significant model artifacts are mobile business objects (MBOs), which describe the interaction with the back-end data, and the device-side data representation. An MBO is a middleware object that describes mobile data and operations on that data. Operations on an MBO are typically record related, but can also be operations that are directly invoked against the back end. Changes made to MBO data on the device are reflected in the back end. Back-end changes are communicated to the user when the middleware notifies the device of an update and subsequently updates the MBO data on the device.

Enterprise System

customer Attributes (9)

Q Q Q Q Q Q Q Q Q

Device Representation

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

Operations (3)

Subset
figure 2. Mobile Business Object (MBO)

Personalize

Mobilize

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

Sybase Unwired Platform Development Workflow

Develop Mobile Model from Enterprise Content Publish in Unwired Server Generate Device Artifacts Develop Device Application Test on Emulator and/or Device

figure 3. Development Paradigm

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

Once a mobile package is available, the developer can generate device-side artifacts that form the basis of mobile application interactions with SUP services and data. One or more packages can be used within a single application. The same package version information is embedded in the device-side artifacts; this information matches the device application with the correct runtime version on the server. The specific development details of different application types vary; see the developer-specific guides for more information. SUP also supports the Open Data Protocol (OData) as a back-end resource. OData is a resource-based Web protocol for querying and updating data. OData is owned by Microsoft, but has been released under the Open Specification Promise, allowing anyone to freely interoperate with OData implementations. Where an OData source is used as the back end, the application developer does not need to create any model elements (MBOs) in the tooling, but rather inherits a service model from the service document published from the back end (as in SAP NetWeaver Gateway). These OData service documents contain all the information the device developer needs to parse and interact with these data streams.

coMMon eleMents of the architecture Network Topology Most components in the Unwired Platform architecture are installed alongside other corporate assets, while an externally facing mobile data channel, the Relay Server, is installed in the DMZ. The Relay Server runs as a plug-in to either an Apache Web server or a Microsoft Internet Information Server (IIS). The Relay Server is a single point of contact for devices and is a specialized reverse proxy that avoids opening inbound ports in the firewall to the UnwiredServer1. A Relay Server Outbound Enabler (RSOE) opens a bidirectional communication channel from inside the firewall outward to the Relay Server. This communication channel allows devices to communicate with the SUP server over one of several ports, depending on the specific purpose and technology. These connectivity services include facilities for these principle device-to-server transport technologies: Secure mobile messaging channel for reliable data transport and server-side notifications Sybase MobiLink technology for efficient bulk data replication Configure these ports either during installation or from within Sybase Control Center (SCC). As of SUP 2.1. the platform-specific notification facilities provided by the device manufacturers do not conform to the Relay Server semantics (your IT department must allocate an outbound port for APNS, BES, and so on). Sybase Afaria technology deploys device applications and helps configure those applications as well as managing, and helping to secure certain enterprise data on devices. Afaria technology interacts with the device platforms local management facilities on the device to enforce enterprise policies. For some platforms, Afaria also offers an enterprise application store as an alternative to consumer-facing facilities.

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

Internal Network
Internal Firewall External Firewall

External Network

Unwired WorkSpace (Eclipse) Unwired Server

DMZ

SCC Admin Console Afaria Server

figure 4. Network Topology

Relay Server

HTTP/S

HTTP/S

The following sections describe some of the technology-specific SUP usage patterns and provide a general discussion of the architecture involved. Administration and Monitoring The Unified Agent Service acts as a central control and process monitoring facility for all Sybase server technology (not to be confused with application monitoring, which is done in the core server stack). This JMX-based agent has an embedded Web server to which Sybase Control Center communicates, and an associated database for managing its own control and alerting metadata.

Sybase Control Center Distributed Level Agent Level MBean Server JMX Service Beans
Timer, Monitoring, Etc.

SOAP RPC Client SOAP-RPC Adapter

RMI Connector

HTML Adapter

UA Service Beans
Security, Sessions, File Transfer, RemoteShell, Discovery, Messaging, Etc.

Discovery Service Beans

UDP, Jini, LDAP

Instrumentation Level

SQL Anywhere

Sybase Servers

Unwired Servers

figure 5. Management Infrastructure

From an administrative and deployment standpoint there are several hierarchies: A host administrator has global control over the infrastructure. A domain is associated with a configurable security context and can be used to implement multitenancy within a single server runtime. A domain administrator can configure elements only for a domain to which he or she has been granted authorization. An application is associated with a security context and a set of packages. Packages are deployed to the server within an administrative domain as an application. Logging policies can be applied separately at the domain and package level. Monitoring processes within the server record various application behavior, including device requests and application statistics. These records are written asynchronously to the monitoring database. Sybase recommends that you isolate this database on its own hardware if you perform a significant amount of monitoring during production in medium-to-large deployments. Device Services As an information bridge between the enterprise back end and the device, SUP provides several key features that make developing applications much easier and more secure. Moving data securely and efficiently is one of the key value propositions of the platform. SUP uses two proprietary technologies to provide the best quality of service with regard to efficiency and seamless integration with the data store. There are two main types of device applications Hybrid Web container and native applications. The device stack supports a messaging protocol for devices built on the Hybrid Web container, and the SUP Data Orchestration Engine (DOE) supports native device applications with rule distribution. Native applications built without DOE utilize Sybase MobiLink technology to replicate data to the UltraLite database.

Sybase Mobile SDK Archetypes

Device User Interface Business Logic Application Specialization Core Application Services Native Code Native Code Synchronization Services HTML5 / JS Runtime HTML5 / JS Runtime HTML5 / JS Runtime Security Supportability and Configuration Local Persistence and Cache Connectivity and Notifications Native Object API
figure 6. Device Stack

Native Code Native Code OData Parser

HTML5 / JS Hybrid Apps

OData SDK

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

Messaging Services The workflow architecture, Hybrid Web applications, DOE, OData SDK, and notification mechanism leverage a proprietary message transport to move data between device and server. This messaging transport is based on the HTTP protocol. The messaging protocol layered over HTTP provide quality of service for compression, encryption, and asynchronous guaranteed delivery. Messaging may be synchronous or asynchronous; only asynchronous messaging provides guaranteed delivery between the device and the enterprise back end. In-transit asynchronous messages are stored in consolidated database (CDB) queues, and on the server and on the device they reside in the device database until processed by the mobile application infrastructure layers. These messages are encrypted on the device and in transit. To receive messages, devices must be registered with the server via a process called onboarding. A device can be onboarded either manually (administratively whitelisted) or through an automatic process based on a security domain that is associated with the device users login credentials. Within Sybase Control Center, the administrator associates packages with a security domain under the heading of an application during deployment. Security Services Unwired Platform provides pluggable Common Security Infrastructure (CSI) features for authentication, authorization, and auditing. Users can authenticate against an array of authorities including LDAP and Active Directory. Secure connections can also be established with Secure Sockets Layer (SSL) between the device and replication channel. Device databases may also be encrypted with a user-supplied key.

Mobile workflow enableMent Sybase Mobile Workflow technologies enable mobile device users to operate as workflow participants. SUP provides the last-mile connectivity for workflow applications, allowing the mobile user to start and respond to back-end enterprise requests within a generic framework. Mobile Workflow utilizes the concept of a container on the device that is a native application with a Web browser plug-in and built in SDK for connectivity, guaranteed messaging, caching, and security. Mobile Workflow relies on messaging between the server and a container on a device that invokes either online operations to the back end or cached mobile business object (MBO) data in the Unwired Server. Workflow Components In the workflow architecture, changes to back-end workflows, generally sent via data change notifications (DCNs), result in the creation of messages that are sent to the messaging server for dispatch. Spooled messages that meet a specified set of matching criteria are placed in a queue for processing by the messaging transformer component, which augments the message with application-specific (MBO) data or processing instructions.

Messaging Service Mobile Device

Device Inbox Device Messaging DB Application(s) Message Interceptor Transformer Transformer Queue Response Processor Responder Response Queue JMS Bridge Message Processor

SUP Data Service

DCN Servlet EIS

JMS Host

DCN Servlet MMS

DS Consolidated Database

figure 7. Workflow Architecture

Once transformed, the augmented message may be queued for transmission to the mobile device when the device next connects to the SUP server, or the message may be sent directly to the device. These messages are stored in the devices in-box where they await the users actions. When a user loads an in-box message, the appropriate form is loaded by the workflow application, and the user may perform application-provided actions (such as approving an expense request). The device users responses are sent back to the messaging server. Depending on the application, the response action may be queued, or may result in a synchronous action; this behavior is different from outbound message transformations, which are always queued. Regardless of whether the response action is queued or performed immediately, the application communicates with the SUP server to perform the actions unit of work.

hybrid web container applications SUP Hybrid Web Container bridges the deficiencies of todays mobile Web browsers with the power of device OS services like GeoLocation, and so on. This paradigm enables developers to build rich applications using Web technologies and add functionality similar to whats available in todays native applications. SUP 2.1 includes a completely rewritten version of the client-side container technology than was available in earlier versions, which was based on proprietary client-side application definitions via XML and used to render the native application interface within the container. Typical use cases for Hybrid Web container technology include mobile workflows, lightweight applications, and so on, that include these characteristics: Low data volume Simple user experience No long-lasting offline stateful transactions Simple business logic

The Hybrid Web container supports three basic patterns. In many applications, a combination of these patterns are applied to implement specific use cases. Notifications also referred to as server-initiated, these actions are performed in the back end by external applications in the context of a business process result in mobile users being notified with information. Lookup mobile users take action on devices to request information from the back end. Action/Decision Forms users take action on devices to submit a form, make a decision, and so on, which results in some enterprise business process state transition. The Hybrid Web container is the runtime on the device within which these patterns are executed. The applications formed from these patterns are referred to as Mobile Workflows in the context of SUP 2.1, although technically, workflow is a specific use case of the general technology. The Hybrid Web container is a native application with an embedded browser that allows developers to build applications with the simplicity of Web development combined with the power of native device services. SUP 2.1 delivers a native application for iOS, Android, Windows Mobile and BlackBerry platforms. In addition to the standard Web browser capabilities available in standard HTML/CSS/JS code, the Hybrid Web container also provides these additional device and SUP services: Offline cache Reliable messaging Secure store Application provisioning Integration with SUP middleware for MBO data exchange In future versions, other device services such as camera, contacts, and so on are being planned. Container Messaging Components Hybrid Web Container Device Runtime This device-resident native application provides a runtime environment for Hybrid Web applications, and must be deployed once using an application provisioning tool such as Afaria. Thereafter, applications are automatically deployed when the container runs on the device, and the protocol between the container and the server identifies version differences. Container App Designer Container Metadata (HTML5/CSS/JS) Container Client Metadata (HTML/CSS/JS) Browser Container Services (Storage/Messaging/ Security/Provisioning) MBO Cache Pull Workflow Server Metadata MBO Tooling

Unwired Server

MBO Metadata

Lookup/Search

Hybrid Web Container

XML Messages
figure 8. Hybrid Web Components

Push/DCN

SAP System

Mobile Workflow Forms Editor The Mobile Workflow Forms editor is the WYSIWYG tool for building lightweight applications and Mobile Workflows that run in the Hybrid Web Container. The Mobile Workflow Forms editor, which is included with Sybase Unwired Platform, is a tool that helps design the user interface and test the flow of the business process for a Hybrid Web Container application. Using the Mobile Workflow Forms editor allows you to develop mobile workflow screens that can call create, update, and delete operations, as well as object queries, of a mobile business object. Mobile Workflow package files are generated using the Mobile Workflow Package generation wizard in the Mobile Workflow Forms editor. The generated Mobile Workflow package contains files that reference a mobile business object (MBO) package, an MBO in that package, and the operation or object query to call, as well as a mapping of which key values map to parameter values. The generated Mobile Workflow packages output is translated to HTML\CSS\JavaScript. The logic for accessing the data and navigating between screens is exposed as a JavaScript API. Mobile Workflow packages can be deployed to Unwired Server and assigned to users using the Mobile Workflow Forms editor in Eclipse. Middleware The container messaging architecture relies on SUP middleware to integrate and mobilize datasources using the core SUP modeling concept called MBO. Middleware provides connectivity to various back ends through this intermediate MBO runtime construct, thereby providing a single interface for device application developers and abstracting the complexity of the back end. It also securely provisions Hybrid container applications based on the application assignments. The communication between the container and middleware is encrypted to enable confidentiality of message content. Sybase Unwired WorkSpace/MBO Tooling Unwired WorkSpace is a key piece of the architecture that enables modeling mobile business objects (MBOs), which are used for data transfer between the container and the back end through the middleware. This component is an Eclipse plug-in just like the Mobile Workflow Forms editor. Administration Console Hybrid container applications are managed and deployed through the same management/administration console used to manage SUP. This provides the ability to assign applications to devices/users based on regular expressioncentric matching rules. This console also enables platform state monitoring, and provides metrics for tuning.

Mobile synchronization applications Synchronization applications provide transactional consistency between the mobile device, the middleware, and the back-end system. These custom applications are designed and built to suit specific business scenarios, or may start with a bespoke application that is adapted with a large degree of customization. There are several application requirements to consider to determine the best SUP technologies to employ. Application designs that fail to take these criteria into account may have challenges in meeting their key performance indicators (KPIs). Cache Synchronization Cache synchronization maps mobile data and service objects to SAP remote function calls (RFCs) using Java Connector (JCO), and to other non-SAP data sources, such as databases and Web services. When SUP is used in a standalone manner for data synchronization, it utilizes replication-based synchronization (RBS) an efficient bulk transfer and data insertion technology between the middleware cache and the device database. In an SUP standalone deployment, the mobile application is designed such that the developer specifies how to load data from the back end into the cache, and then filters and downloads cache data using device-supplied parameters. The mobile content model and the mapping to the back end are directly integrated.

10

This style of coupling between the device and the back-end queries implies that the back end must be able to respond to requests from the middleware based on user-supplied parameters, and serve up mobile data appropriately. In other words, the back end should be capable of returning what an individual device user may request by supplying an appropriate interface. Normally, some mobile-specific adaptation is required within SAP Business Application Programming Interfaces (BAPI). Because of the direct nature of application parameter mapping and RBS protocol efficiencies, SUP cache synchronization deployment is ideal for: Rapid synchronization of large payloads to devices (may be due to mostly disconnected scenarios) Situations where ad hoc data downloads might be expected SAP or non-SAP back ends Large payloads, for example, can occur in task worker (service) applications that must access large product catalogs, or where service occurs in remote locations and workers might synchronize once a day. While SUP replication-based synchronization does benefit from middleware caching, the direct coupling requires the back end to support an adaptation where mobile user data can be determined. Cache Synchronization Components The goal of synchronization is to keep data views (that is, the state) consistent between the device and back-end tiers. The assumption is that if data changes on one tier (for example, the enterprise system-of-record), all other tiers interested in that data (mobile devices, intermediate staging areas/caches, and so on) are eventually synchronized to have the same data/state. Core Components The SUP server synchronizes data between the device and the back end by maintaining records of device synchronization activity in its consolidated database, along with any cached data that may have been retrieved from the back end or pushed from the device. The SUP server employs several components in the synchronization chain: Mobile channel interfaces provide a conduit for transporting data from and to remote devices. There are two main channel interfaces that provide messaging and replication: Messaging channel serves as the abstraction to all device-side notifications (BES, APNS, and others) so that when changes to back-end data occur, devices can be notified of changes relevant for their application and configuration. This channel is also used to enable data synchronization on iOS.2 Replication channel serves as the conduit over which data is replicated between devices and the mobile middleware. This is an efficient database row replication technology. Mobile Middleware Services (MMS) arbitrates and manages communications between device requests from the mobile channel interfaces in the form that is suitable for transformation to a common MBO service request and a canonical form of EIS data supplied by data services. Data Services (DS) is the conduit to enterprise data and operations within the firewall or hosted in the cloud. DS and MMS together manage the consolidated database (CDB), where data is cached as it is synchronized with client devices. Once a mobile application model is designed, it can be deployed to the SUP server where it operates as part of a specialized container managed package interfacing with MMS and DS components. Cache data and messages are persisted in the databases in the data tier. Changes made on the device are passed asynchronously to the MMS component (with respect to the download) and replayed in their own thread against the data services interfaces with the back end. Data that changes on the back end as a result of device changes, or those originating elsewhere, is replicated to the device database. This download phase occurs either because the device receives a notification causing the device to synchronize (if so configured) or because the user manually invokes synchronization.

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

Public Network

DMZ

Private Network Unwired Server (Clustered)

Data Services

Application(s) MBS Client UltraLite RBS Client UltraLite Relay Servers

Mobile Middleware Services

Mobile Devices

Message

Messaging Channel
Outbound Queue Inbound Queue

JMS Host

Jaas LDAP Server Connection Pools (Active/Passive HA)

Sync

Replication Channel

Web

MobiLink Unified Agent Service Sybase Control Center

Data Change Notification

SUP Data Tier

Consolidated Database Cluster DB

Enterprise Information Systems

Unwired Workspace SAP Applications
figure 9. SUP Cache Synchronization Architecture

User Agent DB Advantage Messaging DB

Databases

SOAP/ REST Services

The Cache Cache-based synchronization uses the cache as a mirror of what users see on the device. While the cache is not the system-of-record, it allows the server to compare the last time cache elements were updated with the time the specific data elements on the device were last successfully synchronized. This mechanism allows the server to download only the elements that have changed since the last device synchronization. The cache is manifested in the consolidated database (CDB), which is a relational database management system. The server, or more specifically the application package hosted in the application server, communicates to the CDB through JDBC connection pools, which can be configured in the administration console. The MBO parameters and the relationship between MBOs define the shape of cache tables. The internal implementation of these tables and the associated queries are not public and may change from release to release. Each package has its own cache, and the life cycle of the cache is the same as the package. If the package is removed from the server, the cache is removed. Cache data can be shared or partitioned based on application parameters defined in the MBO model. If an MBO definition loads data where two application users have overlapping synchronization parameters, the users are sharing the same data. However, if the application model defines the MBO load parameters in way that makes the data unique to a user (for example, an employee ID) then the cache is partitioned and not shared. Shared cache data is typically reference or master data that is not updated by device users. Updating shared data incurs locking costs in the server and should be, if possible, performed infrequently and during periods of low user activity. The validity of cached data, like reference data, can be made invalid by configuring a cache group. By default, all MBOs belong to the same cache group. Available refresh settings for a cache group include: On (device) demand with a specified window of cache coherency Periodically after initial load Once for use where the initial load is done with a load query Always valid because the cache group is updated by DCN
12

Once the device demand or cache schedule triggers a load, all elements in the cache group are refreshed. To the extent possible, the MBO model should be designed to partition user data (via a unique user-specific key) that is meant to be updated from the device. The cache can be updated by either a device user with the proper security role or by a data change notification (DCN). When a device updates the cache, the changes from a result set can be optionally written to the cache along with the update to the back end.3 Alternatively, a portion of the cache can be invalidated, whereupon it is refreshed. However, do not use this method when a DCN is used to populate the cache, since the server needs an operation to update the cache when it is invalidated. The DCN is a HTTP/JSON intranet-facing interface exposed through the built-in Web server for each package and its associated MBOs, with the intent that the back end may proactively send changes to update the cache. Properly authenticated DCNs may send complete payload changes or notifications that something has changed (causing the cache to be invalidated for that record).

synchronization with data orchestration engine (doe) The SUP DOE deployment option provides additional flexibility, allowing the system designer to model and consolidate SAP mobile content in the middle tier and separately layer distribution rules over this content. This approach is especially useful where back ends cannot provide a mobile interface that serves up mobile data, or where additional flexibility is required. This approach allows distribution rules to evolve separately from the content model and for different distribution rule sets to be used with the same content model. Even customers can change the rules without rewriting client or back-end code, after actively deploying applications. The technology to enable this behavior is built directly into the NetWeaver stack and is therefore best suited to SAPonly implementations or where third-party back-end integration is already provided through NetWeaver. This method specifies BAPI CRUD interfaces to adapt back-end suite datasources to the middleware data consolidation area. The SUP DOE option consolidates all mobile data from the back-end SAP system, then uses rules to determine mobile distribution. The rules are fired on these events: New device is registered initial receiver determination Back-end data or client data changes because of user updates or batch updates the staging area is updated Business change resulting in change of user subscriptions, for example, moving from region A to region B device realignment The SUP DOE option is ideal where: The SAP back end cannot directly support mobile queries, or mobile queries place an unacceptable load on the back end The design dictates that the data distribution take place in the middleware Multiple customized SAP back ends must interface to the same mobile application, for example, where a mobile application is developed once and resold to multiple customers who use different distribution rules Customized conflict resolution is required within the mobile middleware (as opposed to the back end)

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

Data Orchestration Engine (DOE) Architecture The SUP DOE architecture differs from cache synchronization in some significant ways. The DOE mobile model design phase does not use Eclipse tooling; the content model description are configured in the DOE in Data Orchestration Workbench.

Data Orchestration Engine

Enterprise Application R CRUD Services

Data Consolidation
Backend Adapter Semantic Data Adaptation (CRUD + Events for BusinessObjects) R

Client Connectivity and Transport

NW Mobile Client Channel SUP Transport Channel

Client Channel Framework R R Generic Synchronization API R R Consolidated Data Store Service Consolidated Data Store R Data Distribution Distribution Engine R Data Distribution Service Distribution Model Rule Evaluation Service Receiver Metamodel Extract Service Association Tables Queues

Application Data Store

DOE Flow Manager Standard Data Object Flow Hierarchy Data Object Flow Receiver Generation Flow Subscription Generation Flow R Key Mapping Service Conflict Detection Service Validation Service Custom Service

Key Lookup Tables R

R Traces and Logs

Monitoring & Central Inbox R

Subscription Tables DOE Receiver Administrator

Data Object Model

Flow Definition

DOE Design Time Modeler

Receiver Inventory

figure 10. DOE Runtime Architecture

Data Consolidation Back-end adapters enable DOE to connect to the source EIS in a loosely coupled way. To be able to communicate with the corresponding DOE back-end adapter, the EIS must expose business data by implementing a set of services. In the case of SAP Business Suite, these services are implemented as ABAP function modules called BAPI wrappers. BAPI wrappers are remote function call (RFC)-enabled and can retrieve or update multiple data sets simultaneously. DOE uses the RFC to retrieve business data from the back end (push and pull) as well as to send data updates performed on the mobile client to the back end. Back-end adapters also provide functionality to map data from source EIS to DOE data representations. Back-end EISs and (device) receivers may use different keys to identify data; therefore, mapping may be required. Custom services, similar in semantics to the BAPI wrappers, must be developed for each other EIS. To enable a fast and scalable synchronization process, DOE consolidates the business data required by the receivers. DOE requests data from the source EIS and stores a replica of that data in its own store, called the consolidated data store (CDS). Within the DOE, data objects represent the structure or schema of the data in the back end. In the backend EIS, business objects or database tables provide the data for the data objects. Examples of business objects are sales orders and customers. Schemas for data exchange or data objects are defined at design time. At runtime, when actual data is exchanged between the EIS and DOE, data from these back-end sources is stored as instances of data objects. The data consolidation component, maintains integrity across the data object instances even if the data for the same data object is coming from different back-end sources. For example, sales order data is received from the SAP CRM system, whereas product master data is received from SAP ERP.
14

The integrity constraints between these different data objects are specified by defining associations and dependencies. Data from the CDS is sent to receivers according to data distribution rules. The receivers may modify the data and send updates to DOE. DOE sends the modified data back to the original source (EIS) of the data object for validation. Only validated data is updated to the CDS, and confirmations of successful validations and modifications are sent back to the receiver that initiated the modification. In case of rejections by the EIS, negative acknowledgements are sent to the receivers. Data Distribution In the CDS, business data is stored in a format that is optimized for data distribution. The data distribution component determines which data to send to each receiver, (receiver determination) and triggers the distribution. The receiver determination is based on rules, which determine the data to be sent to an individual receiver. Subscription is the assignment of a data object instance to a receiver. Data distribution comprises: Receiver management Subscription management Receiver determination The DOE supports automated generation of receivers and their subscriptions based on rules. All receivers in the DOE are stored in the receiver inventory. The attributes of a receiver are defined by the receiver meta model (RMM). Subscriptions can be generated automatically when new receivers are added to the DOE. New receivers can be added based on available back-end EIS information. All data that effects creation of new subscriptions is updated from the EIS into the DOE using data objects. For example, sales order information must be distributed to sales representatives, each of whom carries a smartphone. Each sales rep should receive only sales orders relevant for the region to which he or she is assigned. The IT departments asset inventory stores information about which employee is assigned to which smartphone device. Furthermore, the SAP CRM and SAP ERP systems provide information about the sales region where a specific employee is working. A simple rule stating that data distribution of sales orders to sales representatives based on sales region can be executed automatically, without administrator intervention. DOE automates the process to the extent that whenever a new employee is added in the ERP or CRM back-end system and is assigned to a new smartphone device that is recorded in the asset inventory store, the employee instantly starts receiving daily workrelated data on his or her device, including new software if required. The rules governing the creation of a subscription are stored within a distribution model. Based on these rules, the DOE performs receiver determination to calculate which receiver needs which data. To do so, the receiver determination component first compiles the rules into a form that can be used efficiently, in terms of execution time, at runtime. The relationship between the data object instances from the CDS and the receiver is explicitly precomputed and stored in lookup tables. The compiled form of the rules of the distribution model is also stored in the lookup tables. Whenever a subscription changes due to a change in the governing rules, the data distribution component recalculates the relationship for the corresponding receiver and updates the lookup tables. Existing data may need to be deleted from receivers, or new data may be required to be associated with existing receivers. For example, the distribution of sales orders to the smartphones of sales representatives is based on the sales region. A receiver-determination step is triggered whenever a sales order message with updated region information comes from the back-end system, or whenever a new user is created in the back-end system. To handle thousands of receivers, the algorithm is optimized for handling a mass volume of updates.

15

DOE as a Component in SUP Once the data model and rules are ready to be deployed, a package artifact known as Entity Set Definition for Mobile Applications (ESDMA) communicates the application definition from within the DOE. The ESDMA deployment tool creates the runtime artifacts in the Sybase Unwired server. The runtime artifacts in the Sybase Unwired server are limited to reliable delivery of messages both to and from devices. Data staging is performed in the DOE middleware, while message store and forward is performed in the SUP messaging layers. A message-based server interconnect is used between the Sybase SUP server and its DOE component. Messaging, rather than DB replication, moves data between the back end and devices.

SAP Backend
BAPI Wrapper, Events, Filters

Sybase Unwired Platform with DOE

Data Object, Distribution Model, ESDMA Sybase Mobile App Development Tools Sybase Admin Console

SAP Business Suite

SUP Connector (SOAP XML + ESDMA Bundle)

Sybase DOE Connector

Push Messaging

ERP

CRM

PLM

DOE Consolidation and Rules Distribution

ESDMA Converter

BASIS 7.0

BASIS 7.1

Sybase Unwired Platform

Device Sync Stack

Device Workflow Stack

figure 11. SUP DOE Architecture

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

sap odata applications The SAP NetWeaver Gateway exposes OData with extensions specific to SAP. SUP incorporates facilities for publishing these service documents and allowing users to interact with the Gateway runtime, which then interacts with the SAP application suite. SUP provides administrative facilities for discovering OData service documents and allowing devices to communicate with those enterprise services. The SUP normal device onboarding and security facilities are used when communicating to OData sources. Devices can be administratively whitelisted or automatically registered with the SUP server based on authentication with a security domain.

16

Public Network

DMZ

Private Network Unwired Server

Messaging Channel Container Services
Data Change Notification HTTP Callback Router

Mobile Devices
Relay Server Outbound Enabler OData Application(s) OData SDK HTTP Messaging Proxy Security/Config Logging Messaging Channel Load Balancer

Async Channel
Outbound Queue Inbound Queue

Jaas

LDAP Server Single Sign on URL

Sync Channel

JMS Host

Mobile Middleware Services

HTTP Proxy Handler

Data Services

Connection Pools

Relay Servers

SUP Data Stores

Consolidated Database Cluster DB Monitor DB

Domain Logging Unified Agent Service

Sybase Control Center

figure 12. SUP OData Infrastructure for NetWeaver Gateway

User Agent DB SAP Applications

When device applications communicate with the Gateway, they do so with a synchronous message interface (providing their own retry capability for interrupted communications). The synchronous interface avoids message queues on the device, in the middleware, and associated database disk I/O, and may allow horizontal scaling of the middleware. Using synchronous messaging where a seamless online and offline experience is required places additional burden on the application developer. Device users may publish their logical device address to the Gateway, allowing data change notifications to be forwarded from the Gateway to SUP and onto the device. These notifications are guaranteed to be delivered to the device. Device notifications may be registered over device platform-specific channels like APNS or BES. As with other messaging facilities, monitoring and logging of messages is managed through the Sybase Control Center management console.

17

Sybase, Inc. Worldwide Headquarters One Sybase Drive Dublin, CA 94568-7902 U.S.A 1 800 8 sybase Copyright 2011 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase, the Sybase logo, Afaria and MobiLink are trademarks of Sybase, Inc. or its subsidiaries. indicates registration in the United States of America. SAP, the SAP logo and SAP NetWeaver are the trademarks or registered trademarks of SAP AG in Germany and in several other countries. All other trademarks are the property of their respective owners. 11/11

www.sybase.com