unwired_platform_architecture_wp_web
TRANSCRIPT
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
1/16
white paper
.ss.c
Sybase Unwired Platform Architecture
Release 1.5.2
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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.
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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.
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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/7/2019 Unwired_Platform_Architecture_WP_WEB
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.
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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.
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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.
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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.
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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.
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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.
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
14/16
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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.
-
8/7/2019 Unwired_Platform_Architecture_WP_WEB
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