Unwired_Platform_Architecture_WP_WEB

8/7/2019 Unwired_Platform_Architecture_WP_WEB

1/16

white paper

.ss.c

Sybase Unwired Platform Architecture

Release 1.5.2


2/16

SybaSe Unwired platform 1.5.2

Rlas 1.5.2 is las rsion of Sbas Unwird Plaform, offrin nancd scalabili and prformanc

caracrisics. In addiion, Unwird Plaform 1.5.2 inroducs a nw sncroniaion paradim basd on asncronou

rliabl mssain, supporin a nw class of mobil applicaions for alwas-on dics. Rlas 1.5.2 is also a

cnolo rfrs of prious rsion basd on lpin Sbas cusomrs mobili ir nrpris daa.

Som of componns a bn rdsind or nancd o lp as dplomn, sricabili, and scalabili

of plaform. Nrlss, cnolo is sill drid from sam rliabl foundaion pron and pan-

pndin Sbas mobil cnolois suc as MobiLink, mobil objc clin accss (MOCA), and mobil businss

objcs (MBOs).

table of ContentS

1 Sybase Unwired Platform 1.5.2 New Features

1 Message-Based Synchronization

1 SAP Data Orchestration Engine (DOE) Support1 RESTful Web Services

1 Multitenancy and Domain

1 iPhone Support

2 Mobile Business Object API Extensions

2 Redesigned Data Services

2 Sybase Mobile Workflow

3 Mobile Application Data Mobilization

3 Mobile Data Set Characteristics

4 Data Exchange Pattern

4 Synchronization Paradigm

5 Data Model

5 Partition Cache

6 Cache Loading

7 MBO Modeling

8 Release 1.5.2 Architecture

11 Use Case and Recommended Configuration

11 Field Service Use Case

11 Mobile Data Set Characteristics

11 Data Exchange Pattern

11 Synchronization Paradigm

12 MBO Modeling


3/16

1

SybaSe Unwired platform 1.5.2 new featUreS

Mssa-basd sncroniaion

In earlier versions of Unwired Platform, data synchronization between the device and the enterprise occurs by use

of transactional data replication technology. Mobile users interact with the enterprise via punctuated synchronization

sessions. The data exchange is highly efficiency and reliable. While this paradigm supports use cases that require

occasional bulk synchronization, it may not be efficient to use with frequent exchanges of small amounts of data.

Release 1.5.2 augments replication-based synchronization with a message-based paradigm, to allow for more

connected use cases. As a result, customers can choose between the two s ynchronization paradigms, depending on

the mobile applications mode of interaction with the enterprise.

SAP Data Orchestration Engine (DOE) support

SAP DOE mobilizes data within some SAP applications through the use of a reliable message exchange protocol on

top of HTTP and Web Services Eventing. Release 1.5.2 supports DOE with an additional component, DOE Connector,

within the Unwired Platform. Synchronization with mobile applications for example, mCRM on Apple iPhone

can be accomplished through the use of message-based synchronization.

RESTful Web Services

Release 1.5.2 continues to augment existing back-end connectivity with the support of RESTful Web Services.

This significant addition provides a low overhead/complexity methodology of mobilizing data from additional

back-end systems.

Multitenancy and domain

Release 1.5.2 enables service providers to offer mobile application mobilization by hosting the Unwired Platform,

which uses remote connectivity, to tenants enterprise information systems (EISs). The platform has built-in support

for higher levels of the software as a service maturity model through a domain that offers logical isolation of

packages, EIS connections, security providers, and tenant data. The administration view consists of a platform and

domain perspective. Only Unwired Platform administrators can make platform-wide changes that affect multiple

domains. Domain administrators are restricted to administering only the domains for which they have permission.

There is platform-level and domain-level logging to safeguard tenant-specific information. The platform

administrator can view only platform-level logs and does not automatically have access to domain logs. This means

that the minimal unit of separation is a domain.

In addition to domain-level logging, monitoring is available on a per-domain basis, which addresses service-level

agreements, billing, auditing, and metering requirements. A public administration API can be used to build customer

portals and administration tools for tenants.

iPhone support

Release 1.5.2 adds iPhone to the list of supported devices. However, due to a limitation imposed by the device, only

message-based synchronization is available for applications that leverage mobilized enterprise data. Data exchange

between applications on the device and the platform is through always-on reliable messaging, providing reliability,asynchrony, and transparency.


4/16

Mobile Business Object API extensions

The Object API has been extended to support new features in Sybase Unwired Platform 1.5.2. The following is a

partial list:

Message-based synchronization and asynchronous interaction pattern

Named queries returning MBOs can be created during design time within the MBO data model, thereby

simplifying mobile application development

Query API returns result sets composed by attributes from different MBOs. The primary use of the new query API

is to supply data for highly sophisticated UI screens in advanced mobile devices, such as the iPhone

Local MBOs that are not bound to a data source and run only on the device. These objects are never synchronized

Complex data structure as parameters for create, update, and delete (CUD) operations, personalization keys, and

load parameters

Enhanced personalization support that includes strongly typed data, multiple default values, storage options,

and security

One-to-one, many-to-one, and one-to-many relationships

Composition (containment) relationships

Redesigned data servicesOur experience with earlier versions of the platform highlights the importance of staging enterprise data to

complement the mobile applications mode of interaction and data usage. Failure to configure the staging cache

quickly results in performance degradation and scalability limit. A new Data Services module within the platform

offers more flexibility to match the applications data characteristics, leveraging eventual consistency to achieve

scalability. Customers can override the default settings and revert to more pessimistic settings, but may pay a price in

performance and scalability. In addition to the Data Services module, these features are new to release 1.5.2:

Single EIS operation to populate multiple MBO cache. This feature is primarily designed to work with SAP

exposed operations

Cache group and synchronization group for custom cache filling and synchronization

Sybase Mobile WorkflowMobile Workflow is a lightweight form facility that requires no coding, the form is described by metadata and

displayed by a small run time on the device. Mobile Workflow supports Windows Mobile (5/6/6.1), Symbian (Series 60)

and iPhone (OS 3.0+) devices. On Windows Mobile and Nokia, Sybase Mobile Workflow integrates with the devices

e-mail inbox to allow fast and easy access . Due to restrictions on the iPhone platform, Mobile Workflow is available

only on a custom e-mail client.

Mobile Workflow can be s erver-initiated, for example, upon the receipt of an approval request. Server-initiated

workflow activity is always via an e-mail notification. Device-initiated workflow activity occurs when a user opens the

workflow form on the device to create or modify a MBO.

2


5/16

3

mobile appliCation data mobilization

The manner in which a mobile application uses mobilized data depends on the use case. Sybase recommends that

you use a top-down approach, working with a domain expert so you thoroughly understand the use case, associated

actors, scenarios, and flow before you initiate any work with the development tooling. Usage patterns should be a

deciding factor in how you mobilize enterprise data. Synchronization between devices and the enterprise is costly, and

there are many variables, in addition to monetary, in the cost equation: latency, bandwidth restriction, connectivity

reliability, concurrency, conflict, availability, and security.

Even if we focus on monetary cost, there are many factors that make it difficult to forecast. For example, while

it may seem that the availability of unlimited data plans removes at least one variable from the cost equation,

sophisticated devices such as the iPhone and various Android devices have a much higher than average wireless data

bandwidth consumption, and their rapid growth in popularity is causing significant wireless congestion. Until wireless

data providers can upgrade their infrastructures, there will be a constant struggle between supply and demand.

Developers and analysts must carefully consider, on a case-by-case basis, the composition and characteristics of

the data set that is to be mobilized. There is no one-size-fits-all solution. Furthermore, to gain understanding of the

mobile data set often requires knowledge of the underlying EIS. Device developers may need to work with enterprise

application developers to use or develop new APIs.

The following sections outline the process a mobility analyst/developer should follow when assigned the task of

mobilizing the enterprise. The information and decisions generated through the process can then be applied in the

Sybase Unwired Platform tooling to generate the mobile data model and corresponding deployment configuration.

The results can then be deployed into a cluster or domain within a cluster to support the mobile applications based

on the use case.

Mobil daa s caracrisics

The first step is to identify the enterprise data to be mobilized to support the mobile application and the use

case that it implements. Selecting too much data leads to a high cost, both during initial deployment and ongoing

operations. However, selecting too little data may render the implementation unable to adequately support the use

case. Unwired Platform stages data retrieved from the EIS to s upport device synchronization. The retrieval is referred

to as loading or filling the cache. When the mobile data set is large, you must correctly design the load to avoid

impacting the EIS. In general, the more data you need to mobilize, the higher the cost of caching the EIS data.

Once you have identified the data to be mobilized, next consider its characteristics. The simplest way is to classify

the data as:

Transactional or reference

Private or shared

Updated by one user, or multiple users

Immediate or eventual consistency

Always retrieve or valid until expiration

These classifications can help you determine the data model and the deployment configuration for your use case.


6/16

Daa xcan parn

Once you have identified that data set to be mobilized, consider its synchronization pattern, which is highly

dependent on the use case. For example, a field service mobile application may only require a start- and end-of-

workday synchronization. Work orders are downloaded in the morning, and completed entries are uploaded in the

evening. The data exchanges can be large, due to detailed information that may be associated with a work order. You

want the exchange to be completed as quickly as possible during both synchronization sessions.

However, another use case requires smaller amounts of data to be exchanged (except for initial deployment)

multiple times throughout the workday. For example, a mobile CRM application behaves more like a traditional

e-mail application; new information is pushed to the device on a near real-time basis, continuously and transparently.

Identify synchronization times and data set sizes to determine how to most efficiently perform the data exchange.

The data exchange pattern places certain restrictions on the type of connectivity required to fulfill the use case. Use

the data exchange pattern information to identify the most appropriate synchronization paradigm.

Sncroniaion paradim

Next, determine whether to use replication- or message-based synchronization. To understand which methodology

is most appropriate for your use case, compare their strengths and weaknesses.

Message-based synchronization, which is new in Sybase Unwired Platform1.5.2, uses reliable messaging to

communicate mobile data and operation replays between the device and the enterprise. The device maintains an

always-on connection with Unwired Platform and whenever changes are available for the device, a message is pushed

to it. Since reliable messaging is used, the mobile experiences delays only in getting the latest data or result of any

pending operations. In other words, the mobile application continues to work, regardless of connectivity. Without a

mostly-on connection, users will receive the messages in clusters; reducing data freshness and potentially slowing

down the device due to extending message processing.

CONDItIONS/USAge MODeRePLICAtION-BASeDSyNChRONIzAtION

MeSSAge-BASeDSyNChRONIzAtION

Transfer mode Session based

Pull or poke-pull (with listener)

Transactional

Individual message based

Push

Reliable with duplicate detection

Bulk data transfer Efficient High overhead due to store-and-forward message flow

Low volume data transfer Higher overhead due to sessionoverhead

Efficient

Connectivity requirement Occasionally connected Always or mostly connected

Synchronization and operationreplay result

Mostly synchronous: upload anddownload

Asynchronous via background sync

Always asynchronous

Transparency or users awarenessof synchronization

Moderate High

Device status Not available Available

Freshness of data Reasonably up to date with the useof server-initiated sync, but can beexpensive in high frequency cases

High

4


7/16

This flowchart may help you determine whether to use replication-based synchronization (RBS) or message-based

synchronization (MBS). This is a high-level decision chart; to make the proper choice, also consider enterprise-specific,

detailed information.

Daa modl

Once you have defined the mobile data set and its characteristics, use the Sybase Unwired Platform development

tooling to create the MBO data model. This is a very important step in implementing your mobile use case. If done

incorrectly, the resulting deployment may not meet performance and scalability requirements. The data model

consists of two parts: the cache model and the MBO model. The MBO model is sometimes called the MBO definition.

The cache model includes the cache-related settings and configurations for a particular MBO.

Partition cache

Consider the partition cache when a particular MBO represents transactional data that is private and has a high

freshness/frequent update requirement. Instead of refreshing the entire MBO cache, which contains data for many

mobile users, partition the cache so that each partition can be refreshed individually. This avoids having to compare

large amounts of EIS data against the cache content to determine what has been changed. Each partition

is independent and belongs to only one user.

Again, to make the right decision concerning partitioning, consider the mobile data set and its associated

characteristics, and your use case. Implementing the wrong data model results in degraded performance

and s calability.

5

Data Freshnessnot Required or Synchronization

on Schedule

OccasionallyConnected

SynchronizationParadigm DecisionChart

Connectivity

Consider MBS

No

No

No

No

Consider RBS

High DataVolume

Yes

Yes

Occasional orInfrequent SyncYes

If device platformdoes not support RBSuse MBS instead

If device platformdoes not support MBS

use RBS instead


8/16

6

Cache loading

Loadin cac ia eIS API

It is important to efficiently fill the cache from the EIS, both initially and during a refresh. Determining a

partitioning strategy is a key factor in cache-filling efficiency. It is likely that you will be able to use existing EIS

interfaces to fill the cache. Using the SUP development tooling, developers can interact with the EIS to examine and

configure the load to use standard based APIs. In some cases, developers may need to create a special API just for

this purpose.

Also consider data characteristics (reference or transaction, private or shared, and so on) when deciding how to

fill the cache. For example, you might choose to use a bulk-load API to reference shared data that is refreshed

periodically. Loading is performed once, and all mobile users share the staged data. The EIS is shielded from

synchronization activities. Or perhaps the EIS reference data set is very large and your use case requires only a

portion of the data set. Set up load parameters to retrieve only the required portions that correspond to the value of

the load parameter set. The cache definition refers to the manner in which an MBO cache is loaded.

Release 1.5.2 lets you use one invocation of a single EIS operation that returns a set of tables to fill multiple MBO

caches, thus avoiding the need to iterate or spiderthrough all MBOs, executing their load operations.

Loadin/fillin cac ia DCNsAlternately, the EIS can use data change notification (DCN) to fill the MBO cache. However, you must properly

program the EIS to send DCNs that completely fill the mobile data set. This paradigm decouples the EIS from Sybase

Unwired Platform. With DCN, there is no scheduled refresh and therefore no impact to EIS performance. Filling the

cache using DCN may take quite some time if the data set is large; it also takes more overhead to process DCNs

than API retrievals.

As a compromise, consider using the EIS API to perform the load, then switching to DCN for updating it. This is a

better approach than sending everything via DCN. The only requirement is that the EIS must capture changes to

the mobile data set during the load by DCN phase, and send those requests after the retrieval by API is done.

Cac roup and rfrs sra

By default, all MBOs belong to the same cache group and share the same configuration and refresh settings.

Available refresh strategies include:

On demand with a specified window of coherency a lazy load strategy that is triggered by an initial access,

and remains valid until expiration or invalidation

Scheduled the initial load is triggered on demand, but refreshes periodically, according to a specified schedule

Always valid turns off filling and relies on DCN for initial loading and updating

Scheduled once used in hybrid mode, where the initial load is performed using the EIS API and remains valid

with no additional scheduled refreshes.

If some MBOs have different caching requirements, you can put them into a separate group, and assign the

appropriate refresh strategy. For example, you may want a reference MBO to refresh only once every 24 hours due to a

batch job being executed at midnight by the EIS. Place this particular MBO in its own cache group and set the group

to refresh at a certain time after midnight, allowing enough time for the batch job to complete.


9/16

7

MBO modeling

Rlaionsip

After you determine MBO cache definitions, the next step is to model the relationship between the MBOs.

Release 1.5.2 supports containment or composition so that when you remove a parent MBO, a cascade deletion

occurs; in other words, all child MBOs are also deleted. The MBO model is the data model seen by the mobile

application on the device.

Opraions

After defining relationships, define operations (create, update, delete, and others) for MBOs. In most cases, you

can map operations to EIS API methods that are exposed or developed for various mobile use cases . Release1.5.2

supports structure parameters for operations. Arguments belonging to the EIS API methods that are mapped to

personalization keys, constants, and so on are not exposed to the mobile application developer as parameters.

Every MBO operation invoked on by the application is converted into an operation replay and synchronized either

manually or transparently.

If there is a containment relationship between MBOs (for example, between a sales order and the items on that

sales order), a single operation replay represents changes within the entire instance of the object tree. This allows

you to invoke suitable EIS API methods to perform atomic modifications.

Furthermore, you can designate the effect an operation has on the MBO cache. By default, the operations cache-

affecting policy is apply operation results. The cache write-through or update is performed only after a replay

successfully completes against the EIS. Write-through allows the cache to remain valid. However, cache write-

through cannot guarantee that users always see the latest information with respect to the back-end EIS. For

example, say an operation updates an address to 1 Sybase Dr. When the data is updated at the EIS, the data

cleansing rule decides to change it to 1 Sybase Drive. A discrepancy temporarily exists between the cache and EIS.

Alternatively, you can specify that the cache is to be invalidated when the operation completes. This forces the

cache to refresh immediately by retrieving data from the EIS; users are more likely to get the latest result. This is

called immediate consistency. The cost of refreshing the cache on each operation replay can potentially place a

heavy burden on the EIS.

Namd qur

The Object API provides basic queries, or finders, to retrieve objects from the local database. In addition, developers

can use a dynamic query facility to perform ad hoc retrieval of objects. If queries are identified early in the

development process, they can be specified as named queries within the tooling. Even though the developer

working on the MBO model may not be the same as the developer who is writing the application, this ability can

simplify application development by packaging business-level queries together within the package.

Sncroniaion roup

In some instances, you can synchronize only a subset of the MBOs in a package. For example, the mobile user

needs to upload only operations to the enterprise immediately, and does not need to wait for reference data to

download. Release 1.5.2 lets you create synchronization groups in the development tooling, which lets developers

prioritize MBO synchronization. You can define synchronization groups only if you are using replication-based

synchronization.

Cod nraion and objc API

The MBO modeling process culminates in generating specified object API code in the language used on the

platform of choice. The generated code is the library that provides persistence support for MBOs on the device

as well as the embedded synchronization mechanism that exchanges data with the enterprise through Unwired

Platform. There is a difference in the API between replication- and message-based synchronization. The Object API

for message-based synchronization is asynchronous, as it leverages messaging, and requires the mobile application

to be event driven.


10/16

8

This figure shows the program stack on the device and how the generated code is used within the stack. The API

is the same between the different device platforms that Sybase supports. The syntax can be different due to the

language that is employed by each specific platform.

Mobile Application

Object API

Generated MBO Code in C#, Java, and Objective C

Platform-specific Device Framework

UltraLite API RBS SQLite API MBS

releaSe 1.5.2 arChiteCtUre

Data Center

Structured

Semi-structured

Unstructured

PackagedApplications

Documents/Email

Multi-media

Databases

ServiceDataSources

DataServices

Unified Development Tool

Administration Console

Network

MessagingServicesMobileMiddlewareServices

DeviceServices

Frontline

Release 1.5.2 adheres to the s ame high-level architecture of earlier versions of Unwired Platform. For some modules,

the release is a technology refresh to improve performance and scalability. At the same time, message-based

synchronization has been added to support mobile applications that run over an always-on or mostly-on connectivity.

The Messaging Services module in the above figure includes both replication- and message-based synchronization.

The Data Services module has been redesigned to provide more flexibility in handling mobile data with various

characteristics, and to yield higher performance/scalability.


11/16

9

The figure below shows the deployment architecture for a typical Sybase Unwired Platform installation. Behind

the Relay Server farm are the Device Management module (Afaria) and Messaging Services module (replication- and

message-based synchronization). The Sybase Unwired Platform cluster hosts a number of domains for multi tenancy

purposes, each with its own set of MBO packages. The hosted Sybase Unwired Platform will access the tenants EIS via

appropriate secured protocol. Data change notifications from tenants EIS to update the MBO cache are sent through

the HTTP(S) protocol and distributed to the Sybase Unwired Platform cluster via a s oftware or hardware load balancer.

All modules within Sybase Unwired Platform support high availability (HA), although existing synchronization at

the time of failure will need to be retried. Devices may need to reestablish the always on connection.

Relay ServerIIS or Apache

Relay Server(Optional for HA)

DMZ

DevicesCommunicate

to theRelay Server

HTTP or HTTPS

Devices Connect to theRelay Server Inbound

RelayServerFarm

HTTP(s) Outbound HTTP(s)

OutboundHTTP(s)

FirewallFirewall

Devices Internet Internal

SUPServers

ConnectOutbound

to the RelayServer Farm

SUPDevelopment

(Cluster)

SUP ProductionCluster

HTTP(s)Data

ChangeNotification

HTTP(s)Data

ChangeNotification

MBOsDeployed to

ProductionServer

JDBC/Web Services

/SAP JCo

JDBC/Web Services

/SAP JCo

Domains

HA is Available for the SUP Servers

Field Devices Connectto Domains which

Host MBO Packages

Sybase Control

Center SUPAdminstrationConsole

Sybase ControlCenter SUP

AdminstrationConsole

EIS

The internal architecture of Release 1.5.2 is similar to earlier versions; additional modules have been added to

support message-based synchronization.


12/16

10

Message BasedSynchronization

ReplicationBased

Synchronization

Notifier

Data Sources

StagingDataStore

Data Services Mobile Middleware Services

DOE Connector

Cache Manager

Push NotificationCalculation

DifferentialCalculation

Push NotificationScheduler

Operation Relayand

Download

EnterpriseDataAccess

WebServices

/WSEventing

ESBSAP DOE

Staged w/DCN e.g.Oracle DB +

Replication Server

Staged w/ no DCNe.g. Enterprise

ApplicationScheduler/

Profiler

DATA SERVICES

Interfaces with Enterprise data source

Handles data notification events thatmay or may not include data change

Executes Data Services operationagainst Enterprise data source topropagate changes from client

Handle cache events from MMS

MOBILE MIDDLEWARE SERVICES

Handles replication and message basedsynchronization and operation relay

Handles message based CUD Requests

Invoke Data Service operationsrequired by upload and operation relay

Respond via message with the resultof CUD Request

Notify Data Services of cache events

Release 1.5.2, with the support of the SAP Data Orchestration Engine (DOE), introduces the concept of non-staged

data. With DOE, the mobile data set resides within the engine; it is passed to Sybase Unwired Platform for reliable

delivery to devices. The same happens with messages from the devices. The DOE knows the mobile endpoints

devices that have subscribed to a particular data model. Unwired Platform links the DOE with devices. All messages

between the DOE and devices are temporarily persisted to guarantee delivery. The DOE Connector uses the DOE

protocol to create an end-to-end, reliable communication channel with the devices.

The DOE Connector and associated tooling consume the ESDMA (data model document) from the DOE to generate

necessary metadata, as well as a corresponding MBO package. Based on the MBO package, client-side code is

generated in the appropriate language. Since data is not staged within the platform, no MBO cache is created.

Integration with other enterprise information systems that do utilize the concept of mobile endpoints requires

Unwired Platform to stage the mobile data set within the MBO cache. The MBO cache is organized as cache groups

within a package. The Data Services module obtains data for the MBO cache via one of these methods:

Retrieval using EIS-exposed API methods

DCN receipt

Depending on the configuration of the cache group, Data Services retrieves data either on demand or via a

specified schedule.

With message-based synchronization, the Data Services module periodically generates a list of mobile endpoints

that may have data waiting to be pushed to them. This is called push notification calculation. For each mobile

endpoint, an appropriate query against the cache is executed to determine the push data set. The push data is

converted into a series of messages and passed on to the message-based synchronization component for delivery to

the endpoint.


13/16

11

USe CaSe and reCommended ConfigUration

To help you understand how to leverage Release 1.5.2 to mobilize enterprise data, this section discusses a field

service use case to demonstrate considerations and recommended settings.

Fild sric us casA back-end system creates field orders for engineers throughout the day, allowing flexibility for the dispatcher to

prioritize urgent work orders before periodic maintenance orders. Each work order is assigned to the engineer who

accepts the assignment. Base reference data about equipment and parts that are applicable across work orders are

stored on each device to reduce the amount of data to be sent to each device during synchronization. However, the

reference data is periodically updated. Each work order carries order-specific details to help the engineer complete the

task. During the service call, the engineer updates the work order by either updating existing entities or creating new

ones. Updated information is immediately pushed back to the enterprise as long as connectivity is available thus

increasing visibility of all outstanding work orders to the dispatcher or manager.

Mobile data set characteristics

Use the methodology described earlier to determine the characteristics of mobile data set. There are two types

of data:

DAtA tyPeS ChARACteRIStICS

Equipment andassociated parts

Reference

Shared by all engineers

Single writer updated by EIS every midnight. Changes are limited. No update frommobile application

Data on device is valid for 24 hours

Work order Transactional data can be updated or created

Private no shared work order. Each work order is assigned to one engineer

Multiple writers (2) updated by mobile application as well as the EIS

Eventual consistency engineer does not need to see changes immediately aftersubmission to the enterprise

Always retrieve from the EIS to get the latest assignment

Data exchange pattern

This use case requires reference data to be updated every 24 hours; either in the morning when the device is turned

on, or when connectivity is reestablished. The amount of data to be transferred is not expected to be very large, since

only data changes are sent.

Work-order data updates are a bit different. There may or may not be updates in the morning, but it is very likely

that there will be multiple updates throughout the day, as distributed by the dispatcher. There is no prearranged time

for engineers to check for new assignments, which may come while the engineer is already engaged on a current

assignment. The amount of data associated with a work order is generally small to moderate. However, data freshness

is important, as there is a limit on how long an assignment can be pending for acceptance confirmation. This means

that the acceptance response from the engineer must be delivered to the dispatcher as soon as possible. For workorders, a near real-time data exchange between the enterprise and the engineer is required.

Synchronization paradigm

Following the flowchart on page 9, for this use case, Sybase generally recommends using message-based

synchronization. However, one item for consideration, before making a final decision, is the size of the initial reference

data for equipment and associated parts that is to be downloaded to the device. After the initial deployment of the

mobile application and data to the device, the volume of operational data is manageable, but the initial load for the

reference data can be very large, thus routing us to replication-based synchronization at one of the decision boxes in

the flowchart.


14/16


15/16

13

In addition, back-end business processes may also update these work orders; for example, the dispatcher may

add notes or update other fields in the work order. This means that two writers may potentially be operating

simultaneously on the same work order. Work order changes are eventually returned via DCN, whether the source of

the change is from the device or the back-end business process. Unless data is locked down in a pessimistic fashion,

inconsistencies are exposed to mobile users. To illustrate this, consider the following example:

tIMe eveNt

T0 Back-end business process updates work order w1

T1 Mobile application updates work order w1, message received by platform and changes for w1 areapplied successfully to the EIS. The changes are written to the cache as the apply result to the cacheoption is selected for the update operation

T1 + DCN for the update by the back-end business process @ T0 arrives and is written to the cache,overwriting the change @ T1

T2 Message is created that should contain the operation result @T1 from the cache is sent back to themobile application. However, in reality, changes made by the business process @ T0 are sent, since theoperation result applied to the cache is overwritten @T1 +

T3 Mobile application receives response for update operation but sees the work order status @T1 +

T4 DCN for the update made by the mobile application @T1 arrives and is now written to the cache. The

data within this notification contains both the updates @T0 and T1

T5 Platform detects that a change has occurred for work order w1 and generates a message to informthe device

T6 Mobile application finally sees the most up-to-date result for w1; in other words, the combination ofchanges from back-end business process made @ T0 and the update by mobile application made @ T1

This example is not about the mobile application on the device and the back-end business process making a

conflicting change. In fact, they are making independent changes. Due to the distance between the device and the

enterprise, the mobile application may not immediately s ee the most up-to-date information; however, eventually,

it will. This is called eventual consistency, and represents expected results when using DCN to propagate the latest

information from the EIS. If immediate consistency is required, request an API from the EIS to receive the most

current data. Additionally, select the Invalidate cache option for the update operation to force an immediateretrieval via the EIS API for the latest data. However, this process can be very expensive, especially when the EIS is

required to service two invocations for every modification.

In this use case, the engineer does not require immediate consistency and knows that the information presented by

the mobile application may be temporarily stale. The inconsistency is corrected in a short time by another message

from the enterprise. Eventual consistency is generally considered reasonable in field service use cases. In general,

the engineer is sending back the latest status of the work order to the enterprise. It is not an OLTP-type operation

that demands the latest, consistent result.

Sncroniaion roup

For the reference data that is updated once a day, the query that determines the set of mobile endpoints containing

new data to be sent frequently need not be executed. In fact, setting up the query to be executed once every 24

hours is sufficient. The work order MBOs, however, require the query to be executed on a much more frequent basis,

for example, every 2 minutes, to provide a near real-time experience. To accomplish this, set up two synchronization

groups; the first group contains only the reference MBOs and the second group contains only the work order MBOs.

This lets you avoid unnecessarily executing the change detection query.


16/16

www sybase com

Sybase, Inc.

Worldwide Headquarters

One Sybase Drive

Dublin, CA 94568-7902

U.S.A

1 800 8 sybase Copyright 2010 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. This materialis the confidential and trade secret information of Sybase, Inc. Sybase, the Sybase logo, MobiLink and UltrLite aretrademarks of Sybase, Inc. or its subsidiaries. indicates registration in the United States of America. SAP and the SAPlogo are the trademarks or registered trademarks of SAP AG in Germany and in several other countries. 08/10

Apple and iPhone are registered trademarks of Apple Inc

Unwired_Platform_Architecture_WP_WEB

Documents

Transcript of Unwired_Platform_Architecture_WP_WEB