white paper

Sybase® Unwired Platform Architecture

Release 1.5.2

www.sybase.com
Table of Contents
1 Sybase Unwired Platform 1.5.2 New Features
1 Message-Based Synchronization
1 SAP Data Orchestration Engine (DOE) Support
1 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

Sybase Unwired Platform 1.5.2

Release 1.5.2 is the latest version of the Sybase Unwired Platform, offering enhanced scalability and performance
characteristics. In addition, Unwired Platform 1.5.2 introduces a new synchronization paradigm based on asynchronous
reliable messaging, supporting a new class of mobile applications for “always-on” devices. Release 1.5.2 is also a
technology refresh of the previous version based on helping Sybase customers mobilize their enterprise data.
Some of the components have been redesigned or enhanced to help ease deployment, serviceability, and scalability
of the platform. Nevertheless, the technology is still derived from same reliable foundation — proven and patent-
pending Sybase mobile technologies such as MobiLink,™ mobile object client access (MOCA), and mobile business
objects (MBOs).
Sybase Unwired Platform 1.5.2 New Features

Message-based synchronization
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 synchronization paradigms, depending on
the mobile application’s 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.

1
 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 services

Our 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 application’s 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 Workflow

Mobile 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 device’s
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 server-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
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.

Mobile data set characteristics

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

3
 Data exchange pattern
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.

Synchronization paradigm
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 Platform 1.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.

Replication-Based Message-Based
Conditions/Usage Mode Synchronization Synchronization
Transfer mode Session based Individual message based
Pull or poke-pull (with listener) Push
Transactional 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 session Efficient
overhead
Connectivity requirement Occasionally connected Always or mostly connected
Synchronization and operation Mostly synchronous: upload and Always asynchronous
replay result download
Asynchronous via background sync
Transparency or user’s awareness Moderate High
of synchronization
Device status Not available Available
Freshness of data Reasonably up to date with the use High
of server-initiated sync, but can be
expensive in high frequency cases

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

Synchronization
Paradigm Decision
Chart

If device platform
Occasional or
does not support RBS Consider RBS Yes Infrequent Sync
use MBS instead

No

High Data
Yes
Volume

No

Occasionally
Connectivity
Connected

No

Data Freshness
Yes not Required or Synchronization
on Schedule

No

If device platform
Consider MBS does not support MBS
use RBS instead

Data model
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 scalability.

5
 Cache loading
Loading the cache via the 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 spider through all MBOs, executing their load operations.

Loading/filling the cache via DCNs

Alternately, 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.

Cache group and refresh strategy

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.

6
MBO modeling
Relationship
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.

Operations
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. Release 1.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 operation’s 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.

Named query
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.

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

Code generation and object 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.

7
 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 Network Frontline

Databases
Structured

Packaged
Applications
Device
Services
Service Data Mobile Messaging
Semi-structured Data Services Middleware Services
Sources Services

Documents/
Email
Unified Development Tool
Unstructured Multi-media
Administration Console

Release 1.5.2 adheres to the same 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.

8
 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 software 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.

Field Devices Connect

Domains SUP Production
to Domains which
Host MBO Packages Cluster

HA is Available for the SUP Servers

Sybase Control
Center SUP HTTP(s)
Relay Server Data
Adminstration
(Optional for HA) Change
Console
Notification
MBOs JDBC/
Deployed to Web Services
Production /SAP JCo
Outbound Server
Devices Connect to the Relay HTTP(s) EIS
Relay Server Inbound Server JDBC/
Farm Web Services
/SAP JCo

HTTP(s)
Data
SUP
Change
Development
Notification
(Cluster)
HTTP(s) Outbound HTTP(s)
SUP
Servers
Relay Server Connect
Devices IIS or Apache Outbound
Communicate Sybase Control
to the Relay
to the Center SUP
Firewall Firewall Server Farm
Relay Server Adminstration
HTTP or HTTPS Console

Devices Internet DMZ Internal

The internal architecture of Release 1.5.2 is similar to earlier versions; additional modules have been added to
support message-based synchronization.

9
 Data Sources Data Services Mobile Middleware Services

Web Services/WS Eventing

SAP DOE

ESB
DOE Connector

Message Based
Synchronization

Staged w/DCN e.g.

Oracle DB + Push Notification

Enterprise Data Access

Staging Notifier
Replication Server Scheduler
DataStore
Cache Manager
Staged w/ no DCN Operation Relay Replication
Push Notification and Based
e.g. Enterprise Calculation
Application Download Synchronization
Scheduler/ Differential
Profiler Calculation

DATA SERVICES MOBILE MIDDLEWARE SERVICES

• Interfaces with Enterprise data source
• Handles data notification events that
may or may not include data change
• Executes Data Services operation
against Enterprise data source to
propagate changes from client
• Handle cache events from MMS
• Handles replication and message based
synchronization and operation relay
• Handles message based CUD Requests
• Invoke Data Service operations
required by upload and operation relay
• Respond via message with the result
of 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.

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

Field service use case

A 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 and • Reference
associated parts • Shared by all engineers
• Single writer — updated by EIS every midnight. Changes are limited. No update from
mobile 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 after
submission 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 work
orders, 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.

11
 There are ways to resolve this problem and still use message-based synchronization. First, determine whether the
initial deployment must be done while the device is cradled, or if it can be done over WiFi. Next, determine how many
devices are to be provisioned simultaneously. Typically, only a fixed number of devices are provisioned over a period
of one day; it may be acceptable to bulk-load the reference data over several days. For this example, assume that the
devices can be provisioned over WiFi, and that the engineer is not waiting for the application to be deployed before
starting work. These assumptions weight the decision toward message-based synchronization for this use case, under
the specified circumstances.

MBO modeling
Cache modeling
Assume that for the reference data, the EIS exposes an API method that can be used to retrieve the entire data
set, and that the EIS cannot send DCNs when there are updates. The mobile data set must be pulled each night
at midnight, to determine whether there are data changes. For the work order, the EIS is configured to send out
existing assigned work orders, and new ones later, by way of DCN.

For this use case, the recommendation is to bulk-load the reference MBOs, and use the API method to retrieve
their contents for change detection. The work orders MBOs are well-suited to using a partitioned cache. However,
because DCN is used to load the MBOs, data is never retrieved from the EIS, and using partitioning or not is
irrelevant. The work order MBOs do not have actual load operations.

Cache groups and refresh strategy

The MBO cache for reference data will be set to refresh daily at midnight. However, for the work order MBO cache,
the refresh policy is scheduled (first refresh can be immediate), but the period is infinite. This means that after
deployment, the MBO cache executes the refresh once and it is marked as valid. DCNs can be sent to load the MBO
cache with existing work orders. This means there will be two cache groups in the package — the reference MBOS
in one group, and the work order MBOs in the other.

Operations
There is no operation for reference data, as it is never updated by the mobile application. It is updated only by
single-writer back-end business processes. Work order MBOs must have appropriate update and create operations.
For changes made by the mobile application to be visible in the MBO cache, the “Apply operation result” option is
required. This means that the changes are written to the cache as soon as there is a successful reply from the EIS,
and prevents the mobile application seeing the changed data reverted back to previous state, as the changes have
not yet propagated to the cache via DCN.

12
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 are
applied successfully to the EIS. The changes are written to the cache as the “apply result to the cache”
option 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 the
mobile application. However, in reality, changes made by the business process @ T0 are sent, since the
operation 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 inform
the device
T6 Mobile application finally sees the most up-to-date result for w1; in other words, the combination of
changes 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 see 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 immediate
retrieval 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.

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

13
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 material
is the confidential and trade secret information of Sybase, Inc. Sybase, the Sybase logo, MobiLink and UltrLite are
trademarks of Sybase, Inc. or its subsidiaries. ® indicates registration in the United States of America. SAP and the SAP
logo are the trademarks or registered trademarks of SAP AG in Germany and in several other countries. 08/10

www.sybase.com Apple and iPhone are registered trademarks of Apple Inc.