Transcript
1. SAP® Mobile Platform Version 2.3Architecture
2. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE2TABLE OF
CONTENTSINTRODUCTION
...............................................................................................................................................
4MOBILIZING THE ENTERPRISE
..................................................................................................................... 4Online Mobile
Applications....................................................................................................................................4Offline
Mobile Applications
...................................................................................................................................4Common
Characteristics
.......................................................................................................................................5OVERVIEW
OF THE SAP MOBILE PLATFORM
............................................................................................ 5Basic Development and
Deployment Process
....................................................................................................7COMMON ELEMENTS OF
THE ARCHITECTURE ......................................................................................... 8Network
Topology
..................................................................................................................................................8Administration
and Monitoring
.............................................................................................................................9Device
Services
....................................................................................................................................................11Messaging
Services
.............................................................................................................................................12Security
Services..................................................................................................................................................12HYBRID
WEB CONTAINER APPLICATIONS
............................................................................................... 13Hybrid Web Messaging
Components.................................................................................................................14Hybrid
Web Container Device
Runtime..................................................................................................................14Hybrid
App
Designer...............................................................................................................................................14Middleware
Messaging for the
Container...............................................................................................................15Administration
Console...........................................................................................................................................16MOBILE
SYNCHRONIZATION
APPLICATIONS........................................................................................... 16Cache
Synchronization........................................................................................................................................16Cache
Synchronization Components
.....................................................................................................................16Core
Components...................................................................................................................................................17The
Cache
..............................................................................................................................................................18SAP
ODATA
APPLICATIONS........................................................................................................................
20AGENTRY APPLICATIONS
........................................................................................................................... 21Agentry
Runtime Application Instance
SAP Mobile Platform 2.3 Architecture
..............................................................................................................23BackEnd System
Support......................................................................................................................................23Multiple
Server Instances
.......................................................................................................................................24
3. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE3ClientServer Encrypted
Communications..............................................................................................................24Production
Data Synchronization
...........................................................................................................................24Application
Data
Synchronization...........................................................................................................................24Agentry
Clients
.....................................................................................................................................................25Agentry
Editor Eclipse Plug
In............................................................................................................................25Administration
Console
.......................................................................................................................................25MOBILE
MIDDLEWARE TOPOLOGY
........................................................................................................... 25
4. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE4INTRODUCTIONThis document
is for service providers and enterprises that plan to deploy the SAP® Mobile Platform (SMP) andneed
a functional understanding of the technology to assist in making informed decisions about choosing
thecorrect mobile technology to use for a particular use case. It includes some level of detail about the
internalworkings of the platform that may prove useful to administrators.This document serves as a
foundation for other more specific explanations of technical aspects of the system,for example, sizing,
performance and tuning, architecture approaches, and security. Developers may find ituseful to consult
other material specifically related to development fundamentals or tutorials.MOBILIZING THE
ENTERPRISEIndividuals and businesses develop mobile applications for specific user needs ranging
from teams of serviceworkers who use ruggedized devices for industryspecific applications,
consultants who track time and expenseson a mobile device, or simple corporate approvals. SAP
Mobile Platform supports these mobile scenarios as wellas crossindustry applications, such as
customer relationship management, human resources, supply chainmanagement, business intelligence,
product life cycle management, and industryspecific applications tailoredfor the service provider,
chemical/pharmaceutical, and utilities industries. All these mobile applications follow twobroad
patterns; the pattern used depends primarily on who is driving the use case. Enduser driven, where
an end user looks for the information that he or she wants, for example, anemployee lookup IT or
Line of Business (LOB) driven, to improve organizational efficiency and customer engagement,
forexample, sales process enablementThese two patterns inherently represent two broad categories of
mobile applications, which may supportoperations that are only allowed while connected to the
network or that have features to support operation whiledisconnected. These two classes of
applications differ significantly in functional and some nonfunctional aspects.However, they share
common attributes, such as security.Online Mobile ApplicationsOnline mobile applications are
completely userdriven and the LOB is seldom involved in support of their dailyoperation.
Information access is ad hoc in nature, and users typically know what they are looking for in a
givensituation. Technically, online suggests these attributes: Request/reply interactions directly with
the backend system Lightweight form editing Situationoriented toward a few screens rather than
a complex application Targeted notification from the back end gives alerts to the userOffline Mobile
ApplicationsOffline mission critical applications are typically supported by IT specialist on behalf of a
LOB to gainorganizational efficiency. Supporters of the LOB infrastructure are heavily involved in
mobile operations for mostoffline cases, information access is formalized in nature, and the business
process dictates the information that
5. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE5each user will act on. In general,
mission critical offline applications are task oriented, and must provideinformation to end users,
regardless of connectivity. Characteristics of offline applications include: Data synchronization to
devices based on enterpriselevel process rules Taskoriented process, resulting in complex UI
navigations Ready for heavy customization, since processes are unique per enterprise Pushenabled
for realtime user experience Strong administrative tools for support, monitoring, and back end data
conflict managementCommon CharacteristicsBoth online and offline applications require these
common IT and application management capabilities:1. Secure onboard processes to bring user
SAP Mobile Platform 2.3 Architecture
devices into the enterprise landscape2. Device, data, and transport security3. Ability to troubleshoot
error conditions with supportability toolsets4. Remote device managementThese common
characteristics introduce a need for a common platform covering both application
categories.OVERVIEW OF THE SAP MOBILE PLATFORMThe SAP Mobile Platform primary
value proposition is in serving as an information bridge between device usersand enterprise data that is
secured behind the corporate firewall or hosted in a cloud infrastructure. The platform,as mobile
middleware, includes a range of components that are hosted within the enterprise and on the
device.These platform technologies are hosted under a common design, runtime, and management
infrastructure thatprovides: Connectivity to multiple client device types and mobile operating
systems Support for native client objectbased APIs based on the device platform language
Support for mobile Webbased clients within a secure enterprise sandbox Eclipsebased visual
development tooling for building mobile data services and generating devicesidedata persistence
APIs Enterprise mobilization architecture that uses standard and proprietary interfaces to support a
variety ofenterprise data resources Endtoend pluggable security that extends from the enterprise to
devices Support for mobile users who are either occasionally connected or those that work entirely
online Push notifications that alert clients to refresh their mobile view of data Unified platform
administration and monitoring
6. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE6Figure 1. Platform OverviewIn
SAP Mobile Platform, one or more of these technologies come together to provide support for a few
majortypes of mobile applications, including: Hybrid Web Container applications:o Crossplatform
request/reply or lookup Mobile workflow patternsNative applications using synchronization:o
Agentry applications that are synchronized directly against the back endo Midtier resultset cache
synchronizationo Support of data consolidation and distribution with the Data Orchestration Engine
(DOE)1 Native applications using the OData SDK:o Request/reply or lookup and guaranteed
notifications RESTbased OData applications built with any SDKo Request/reply or lookup with
device specific native notifications1DOE is not recommended for new mobility solutions; it is
supported for backward compatibility with existing applications. For new applications use midtier
cache synchronization instead. DOE is not described in detail in this document; refer to the DOE and
DOEC documentation for specifics related to thistechnology.
7. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE7The purpose and function of the
major application pillars is discussed in more detail later in this document, alongwith the major
technology components that support them.Basic Development and Deployment ProcessIn cases where
a midtier synchronization model is developed, the developer starts building an application byusing
Eclipsebased tooling to discover assets of enterprise data sources and to tailor the mobile
interactionpattern (which usually involves selecting data subsets) for mobilization. The most
significant midtier modelartifacts are mobile business objects (MBOs), which describe the interaction
with the backend data, and thedeviceside data representation.An MBO is a middleware object that
describes mobile data and operations on that data. Operations on an MBOare typically record related,
but can also be operations that are directly invoked against the back end. Changesmade to MBO data
on the device are reflected in the back end. Backend changes are communicated to the userwhen the
middleware notifies the device application of an update and the application subsequently
synchronizesthe MBO data on the device.Figure 2. Mobile Business Object (MBO)Using Eclipse
tooling and the MBO model, a developer creates a package containing one or more MBOs thatcan be
deployed into the server runtime environment. Each package is assigned a version that is
associatedwith the specific runtime artifacts generated by the deployment architecture.Figure 3.
Development Paradigm
8. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE8SAP Mobile Platform also
supports the “Open Data Protocol” (OData) as a backend resource. OData is aresourcebased Web
protocol for querying and updating data. The OData specification is owned by Microsoft,but has been
released under the Open Specification Promise, allowing anyone to freely develop
ODataimplementations. SAP contributes to the OData specification and supports this protocol in many
of its products.The primary OData access layer for SAP Business Suite is the SAP NetWeaver
Gateway.Where an OData source is used as the back end, the application developer does not need to
create any modelelements (MBOs) in SAP Mobile WorkSpace, but rather inherits a service model
from the service documentpublished from the back end, for example SAP NetWeaver® Gateway.
These OData service documents containall the information the device developer needs to parse and
interact with these data streams.Agentry applications within SAP Mobile Platform perform data
synchronization directly with the backend system.Data and information sent to and received from
SAP Mobile Platform 2.3 Architecture
Clients relate to the daytoday operations of the softwaresolution. The Agentry Instance receives
production data from the Clients to update to the backend system, andto retrieve the data from the
backend system for the Clients. The nature of this synchronization is entirelydependent on the
implementation of the application.COMMON ELEMENTS OF THE ARCHITECTURENetwork
TopologyThe replication and messaging components in the SAP Mobile Platform architecture are
typically installedalongside other corporate Web server assets. A load balancer and one or more
reverse proxy servers areinstalled in the DMZ to insulate the Web server and mobile middleware from
direct internet traffic2. When amobile middleware cluster is used the data tier of the SAP Mobile
Platform may be positioned in a zonealongside other enterprise database servers. A load balancer may
also be positioned between backend serversand the SAP Mobile Platform Web server nodes when data
change notifications need to be sent to both nodes inthe SAP Mobile Platform cluster.SAP Afaria®
technology deploys device applications and helps configure those applications as well asmanaging, and
helping to secure certain enterprise data on devices. Afaria technology interacts with the
deviceplatform’s local management facilities on the device to enforce enterprise policies. For some
platforms, Afariaalso offers an enterprise application store as an alternative to consumerfacing
provisioning facilities.2The SAP Relay Sever is an optional component that should only be used
where standard proxy technologies are not practical and low traffic demand isexpected. For the best
security and performance a standard reverse proxy that is wellincorporated into the existing Internet
landscape should be used.
9. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE9Figure 4. Network TopologyThe
following sections describe some of the technologyspecific SAP Mobile Platform usage patterns
andprovide a general discussion of the architecture involved.Administration and MonitoringThe SAP
Control Center service acts as a control facility for SAP Mobile Server technology. This JMX
basedagent has an embedded Web server to which SAP Control Center communicates, and an
associated databasefor managing its own control and alerting metadata.
10. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE10Figure 5. Management
InfrastructureFrom an administrative and deployment standpoint there are several hierarchies: A host
administrator has global control over the mobile runtime infrastructure. A domain is associated with
a configurable security context and can be used to isolate LOB applicationswithin a single server
runtime. A domain administrator can configure elements only for a domain towhich he or she has
been granted authorization. An application is associated with a security context and a set of
packages. Packages are deployed to the server within an administrative domain as an application.
Logging policies can be applied separately at the domain and package level.Monitoring processes
within the server record various application behaviors, including device requests andapplication
statistics. These records are written asynchronously to the monitoring database. SAP recommendsthat
you isolate the monitoring database on its own hardware if you perform a significant amount of
monitoringduring production in mediumtolarge deployments.The mobile middleware is well
integrated with the SAP Solution Manager for technical monitoring, alerting, rootcause analysis,
change diagnostics, and workload analysis. The complete mobile middleware landscape isdiscoverable
and all error logs are scanned by locally installed Solution Manager Agents. Workload analysismay be
accomplished by utilizing Wily IntroScope instrumentation that provides key performance indicators
formajor mobile middleware components.SAP Solution Manager rootcause analysis is incorporated
through endtoend tracing. Tracing is enabledthrough an administrative action that allows a device
application to initiate a business transaction level trace that
11. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE11incorporates several independent
operations. This trace is captured in the middleware components, logged, andpassed to the SAP
backend. After tracing is complete the traces are uploaded by local agents to the SolutionManager for
analysis in the context of the entire landscape.Device ServicesThere are two main types of device
application approaches — Hybrid Web Container and native applications.Each of these application
types utilize various SDK services, some that are specialized to the application usecase and many
which are common across application types. Various protocols support the application types.The
Hybrid Web Container device stack utilizes a reliable messaging protocol that interacts with midtier
MBO’s.3Native applications synchronize directly with the SAP Mobile Platform midtier cache
utilizing an efficientreplication technology to move data between the server cache and the device
UltraLite® database. NativeOData applications use synchronous messaging calls to interact with the
SAP Online Data Proxy and the SAPNetWeaver Gateway. RESTbased OData services use common
HTTP verbs (GET, PUT, POST, and MERGE)of CRUD operations between the device, the mobile
middleware proxy, and the SAP NetWeaver Gateway.Figure 6. Device Stack3This same asynchronous
SAP Mobile Platform 2.3 Architecture
messaging subsystem is used to communicate with the legacy SAP Mobile Platform Data
Orchestration Engine (DOE).
12. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE12Security features are embedded
into the SDK to support secure certificate storage, use of these artifacts inauthentication such as SSO
(X.509 and SSO2 logon ticket), and other features related to database encryption.There are APIs for
the certificate store, logon certificates, and the data vault used to store these securityartifacts. Each
device application type makes use of the same set of security features.The Agentry archetype supports
security features, including Anonymous and Authenticated SSL and userauthentication. These are a
part of the builtin functionality, requiring the configuration of properly signedcertificates and trusted
root certificates in the appropriate areas.Messaging ServicesThe workflow architecture, Hybrid Apps,
DOE, and device notification mechanism leverage a proprietaryasynchronous message service to move
data between device and server. This messaging service is based onthe HTTP protocol but uses a
proprietary binary payload that is compressed and encrypted. Intransitasynchronous messages are
stored in the server’s cache database messaging queues until a notification is sentto the device
instructing the device messaging layers to pull the payload from the messaging service on theserver.
Once consumed by the SDK client layer the messages reside in the device database until processed
bythe device application layer. Messages are encrypted on the device.OData SDK applications use the
same messaging infrastructure but use synchronous messaging mode forrequest/reply traffic. OData
SDK applications must ensure completion of a request by testing for errorconditions. Proprietary
notifications sent to the OData SDK while it is online are guaranteed to be delivered. Ifthe device is
offline and the application is not able to maintain a connection with the server, the server will senda
device platform specific notification (APNS, BES, etc.) informing the application that it has data
waiting on theserver.To receive application settings notifications, and messages, devices must be
registered with the server via aprocess called “onboarding.” A device can be onboarded either
manually (administratively whitelisted) orthrough an automatic process based on a security domain
that is associated with the device user’s logincredentials. Within SAP Control Center, the
administrator associates packages with a security domain under theheading of an “application”.Agentry
applications use TCP/IP with SSL along with the Agentry Next Generation Encryption Layer
(ANGEL)connection type. Both synchronous and asynchronous communications are supported.
Agentry Clients canoperate in both online and offline mode, with all data stored locally on the client,
and support for delta (exchangedata model) synchronization. The mode is driven by the definition of
the application’s business logic.Security ServicesSAP Mobile Platform provides pluggable Common
Security Infrastructure (CSI) features for authentication,authorization, and auditing. Users can
authenticate against an array of authorities including LDAP and ActiveDirectory. Secure connections
can also be established with Secure Sockets Layer (SSL) between the device andreplication channel.
Device databases may also be encrypted with a usersupplied key.
13. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE13HYBRID WEB CONTAINER
APPLICATIONSHybrid Web Container bridges the deficiencies of today’s mobile Web browsers
with the power of device OSservices like GeoLocation. This paradigm enables developers to build rich
applications using Web technologiesand add functionality similar to what’s available in today’s native
applications. Integration with Apache Cordova(formerly Adobe PhoneGap) allows you to link your
own custom native code to the Hybrid Web Container andcall this native code from JavaScript, as well
as access native device functionality using the Cordova framework.Typical use cases for Hybrid Web
Container technology include mobile workflows, lightweight applications, andso on, that include these
characteristics: Low data volume Simple user experience No longlasting offline stateful
transactions Simple business logicThe Hybrid Web Container supports three basic patterns. In many
applications, a combination of these patternsis applied to implement specific use cases. Simple
request/response or lookup applications using either the SDK messaging API’s or REST
basedinvocations. Hybrid Web Container notifications that are the result of an MBO data change
operation sent from theback end via the middleware in the context of a business process resulting in
mobile users receivinginformation that they can act on. Action/Decision Forms that incorporate
SDK request, responses, and notifications — users take actionon devices to submit a form, make a
decision, and so on, which results in some enterprise businessprocess state transition.The Hybrid Web
Container is the device runtime within which these services are executed. The Hybrid WebContainer is
a native application with an embedded browser that allows developers to build applications with
thesimplicity of Web development combined with the power of native device services. SAP Mobile
Platform deliversa native application for iOS, Android, Windows Mobile and BlackBerry platforms.
In addition to the standard Webbrowser capabilities available in standard HTML/CSS/JS code, the
Hybrid Web Container also provides theseadditional device and SAP Mobile Platform services:
SAP Mobile Platform 2.3 Architecture
Offline cache Reliable messaging (not for OData) Secure store for security artifacts (certificates,
etc.) Application provisioning of an HTML instance Integration with SAP Mobile Platform
middleware for MBO data exchange
14. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE14Hybrid Web Messaging
ComponentsHybrid Web Container Device RuntimeThis deviceresident native application provides a
runtime environment for Hybrid Apps, and must be deployedonce using an application provisioning
tool such as Afaria. Thereafter, applications are automatically deployedwhen the container runs on the
device, and the protocol between the container and the server identifies versiondifferences.Figure 7.
Hybrid Web ComponentsHybrid App DesignerThe Hybrid App Designer is the WYSIWYG tool for
building lightweight applications that run in the Hybrid WebContainer. The Designer, which is
included with SAP Mobile Platform, is a tool that helps design the userinterface and test the flow of
the business process for a Hybrid Web Container application. Using the Hybrid AppDesigner allows
you to develop Hybrid App screens that can call create, update, and delete operations, as wellas object
queries, of a mobile business object.Package files are generated using the Hybrid App Package
generation wizard in the Hybrid App Designer. Thegenerated Hybrid App package contains files that
reference a mobile business object (MBO) package, an MBOin that package, and the operation or
object query to call, as well as a mapping of which key values map toparameter values.
15. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE15The generated Hybrid App
package’s output is translated to HTML/CSS/JavaScript. The logic for accessing thedata and
navigating between screens is exposed as a JavaScript API. Packages can be deployed to SAP
MobileServer and assigned to users using the editor in Eclipse.Middleware Messaging for the
ContainerThe container messaging architecture relies on SAP Mobile Platform middleware to
integrate and mobilize datasources using the core SAP Mobile Platform modeling concept called
MBO. Middleware provides connectivity tovarious back ends through this intermediate MBO runtime
construct, thereby providing a single interface fordevice application developers and abstracting the
complexity of the back end. It also securely provisions HybridWeb Container applications based on
the application assignments. The communication between the containerand middleware is encrypted to
enable confidentiality of message content.Hybrid Apps may invoke online operations to the back end
or to cached mobile business object (MBO) data inthe SAP Mobile Server. Additionally, changes to
backend processes, generally sent via data changenotifications (DCNs) result in the creation of
messages that are sent to the messaging server for dispatch.Spooled messages are processed against a
set of matching criteria and are placed in a queue for processing bythe messaging transformer
component, which augments the message with applicationspecific (MBO) data orprocessing
instructions.Figure 8. Hybrid Web Messaging ArchitectureOnce transformed, the augmented message
may be queued for transmission to the mobile device when thedevice next connects to the SAP Mobile
Server. A notification is sent to the device container where theapplication can choose what action to
take, such as connecting to the server. Once the device connects, datamessages are pulled from the
server and stored in the device’s queue where they await the user’s actions.
16. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE16When a user loads an inbox
message, the appropriate form is loaded by the application, and the user mayperform application
provided actions (such as approving an expense request).Administration ConsoleHybrid Apps are
managed and deployed through the same management/administration console used to manageSAP
Mobile Platform. This console provides the ability to assign applications to devices users and groups
basedon regular expressioncentric matching rules. This console also enables platform state
monitoring, and providesmetrics for tuning.MOBILE SYNCHRONIZATION
APPLICATIONSSynchronization applications provide transactional consistency between the mobile
device, the middleware, andthe backend system. These custom applications are designed and built to
suit specific business scenarios, ormay start with a bespoke application that is adapted with a large
degree of customization. There are severalapplication requirements to consider in determining the best
SAP Mobile Platform technologies to employ.Application designs that fail to take these criteria into
account may have challenges in meeting their keyperformance indicators (KPIs).Cache
SynchronizationCache synchronization allows mapping of mobile data and service objects to SAP
remote function calls (RFCs)using Java Connector (JCO), and to other nonSAP data sources, such as
databases and Web services. WhenSAP Mobile Platform is used in a standalone manner for data
synchronization, it utilizes an efficient bulk transferand data insertion technology between the
middleware cache and the device database. The mobile applicationis designed such that the developer
specifies how to load data from the back end into the cache, and then filtersand downloads cache data
using devicesupplied parameters. The mobile content model and the mapping to theback end are
SAP Mobile Platform 2.3 Architecture
directly integrated.This style of coupling between the device and the backend queries implies that the
back end must be able torespond to requests from the middleware based on usersupplied parameters,
and serve up mobile dataappropriately. In other words, the back end should be capable of returning
what an individual device user mayrequest by supplying an appropriate interface. Normally, some
mobilespecific adaptation is required within SAPBusiness Application Programming Interfaces
(BAPI). Because of the direct nature of application parametermapping and replication protocol
efficiencies, SAP Mobile Platform cache synchronization deployment is idealfor: with repeated large
payload delivery to devices where time is critical where ad hoc use of devices might be expected
causing a large transfer or initial data for SAP or nonSAP backends with Web service or JDBC
interfacesCache Synchronization ComponentsThe goal of synchronization is to keep data and
operations (that is, the state) consistent between the device andbackend tiers. The assumption is that if
data changes on one tier (for example, the enterprise systemofrecord),
17. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE17all other tiers interested in that
data (mobile devices, intermediate staging areas/caches, and so on) areeventually synchronized to have
the same data/state.Core ComponentsThe SAP Mobile Server synchronizes data between the device
and the back end by maintaining records ofdevice synchronization activity in its consolidated database,
along with any cached data that may have beenretrieved from the back end or pushed from the device.
The SAP Mobile Server employs several components inthe synchronization chain: Mobile channel
interfaces — provides a conduit for transporting data from and to remote devices overwhich data is
replicated between devices and the mobile middleware. Mobile Middleware Services (MMS) —
arbitrates and manages communications between devicerequests from the mobile channel interfaces to
a form that is suitable for transformation to a commonMBO service request to the data services
components. Data Services (DS) — is the interface to enterprise data, operations, and the
middleware cache Notification channel – is the mechanism that responds to events from the
middleware and sendsmessages to the device based on changes to the middleware cache or events from
the backend such asOData subscriptions notifications or workflow data change eventsOnce a mobile
application model is designed, it can be packaged and deployed to the SAP Mobile Server whereit
operates as part of a specialized middleware containermanaged application package interfacing with
MMSand DS components. When a package is deployed, its associated database cache tables are created
along withdatabase operations that manage that package’s cache data. The middleware cache helps
alleviate load fromthe backend system, especially when many devices are downloading data at once,
but the backend remains thesystem of record.
18. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE18Figure 9. SAP Mobile Platform
Cache Synchronization ArchitectureThe CacheCachebased synchronization uses the cache as a record
keeper of what enterprise data users have on thedevice. While the cache is not the systemofrecord, it
allows the server to compare the last time cache elementswere updated with the time the specific data
elements on the device were last successfully synchronized. Thismechanism allows the server to
download only the elements that have changed since the last devicesynchronization.The cache is
manifested in an embedded relational database management system. The server, specifically
theapplication package hosted in the application server, communicates to the cache database through
JDBCconnection pools, which can be configured in the administration console. The MBO parameters
and therelationship between MBOs define the shape of cache tables. The internal implementation of
these tables andthe associated queries are not public and may change from release to release.Each
package has its own cache, and the life cycle of the cache is the same as the package. If the package
isremoved from the server, the cache is removed. Cache data can be shared or partitioned based on
applicationparameters defined in the MBO model. If an MBO definition loads data where two
application users haveoverlapping synchronization parameters, the users are sharing the same data.
However, if the application modeldefines the MBO load parameters in way that makes the data unique
to a user, for example, an employee ID,then the cache is partitioned and not shared.
19. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE19Shared cache data is typically
reference or master data that is not updated by device users. Updating shareddata incurs locking costs
in the server and should be, if possible, performed infrequently and during periods oflow user activity.
To the extent possible, the MBO model should be designed to partition user data (via a uniqueuser
specific key) in order to avoid course level cache locking.The load rules and validity of several
MBO’s can be configured together within a cache group. Each cachegroup has its own load and
coherency (validity) settings. By default, all MBOs belong to the same cache group.A composite
object made up of several MBO’s must be contained within a single cache group. The
middlewarecache, or cache group, can be configured to load in one of three ways: Upon a user
SAP Mobile Platform 2.3 Architecture
request to synchronize data to a device, the cache is loaded. This “ondemand” method isthe least
desirable method as the device must wait for the specified cache data to load from thebackend. The
cache can have a “coherence” window based on the last time the cache was loaded. Ifthe coherence
window is zero every user request will cause the associated segment or partition of thecache to be
loaded on every request. If the request is nonzero and the request is within the coherencewindow the
request is serviced from the cache. Scheduled cache refreshes pull data from the backend. This
method is typically only desirable forreference data since the parameters to load the cache must be
configured outside the context of anyuser parameters. This option is best used during dormant hours
and only if a DCN is not available. Data Change Notifications (DCN) pushes data to the middle tier
via HTTP/JSON. This is by far the mostdesirable method of loading the cache for either initial loads
or subsequent changes. Initial loads usingDCN can be spread across multiple members of the cluster
and subsequent changes are surgical andproactive. Use this method to load the cache whenever
possible.Cache data is persisted in the middletier database hosted by the data node until expiration and
cleanup.When a device connects to synchronize, downloads (to the device) are retrieved from the
middleware databaseover the replication channel. Uploads (from the device), consisting of device
initiated data changes andoperations, are passed asynchronously to the MMS component (with respect
to the download) into JMSMessaging Channel queues and replayed in their own thread against the data
services interfaces to the backend and the cache. By default, the upload of changes is independent of
the download although the user mayconfigure the application to always download changes right away.
This decoupling of upload and download isreferred to as asynchronous operation replay which is the
default behavior4.Once the upload changes are applied to the backend any resultant changes, along
with changes caused byother systems, are ready for download. The download phase occurs as a result
of device applicationsynchronization. The device application may be user initiated (users manually
triggers a synchronization) orbecause the application is programmed to respond to a middleware
notification to synchronize. The device will4Applications built prior to Sybase Unwired Platform 2.1
ESD 2 couple upload and download transmissions.
20. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE20receive a notification when the
middleware detects a cache change that affects a cache partition that iscorrelated to a device user’s
application data. When a synchronization device is online the message is sent viathe asynchronous
messaging middleware. When the device application is offline a platform specific devicenotification
(APNS, BES, etc.) is sent to the device application.SAP ODATA APPLICATIONSThe SAP
NetWeaver Gateway exposes OData with extensions specific to SAP. SAP Mobile Platform serves
asthe IT infrastructure in a production environment by providing the following services: Establishes
formal registration of device application instances before accessing enterprise resources forboth on
line and offline applications Publishes device application specific settings configured by the
administrator Blacklists specific application instances Delegates Internet authentication to third
parties and support single signon (SSO) Configures and exposes specific white listed services from
the NetWeaver Gateway (with URL rewriting) Provides a central device application reporting source
based on the exposed public “application” Provides a device application notification hub (proprietary
messaging and device specific)When device applications communicate with the Gateway, they do so
with a synchronous message interface(providing their own retry capability for interrupted
communications). The synchronous interface avoids messagequeues on the device, in the middleware,
and associated database disk I/O, and may allow horizontal scaling ofthe middleware. The middleware
provides two forms of communication with enterprise OData resources: SDKbased messaging and
REST. Both of these protocols run over HTTP(S) although REST is not endtoendencrypted and
therefore may be more amenable to firewall intrusion detection systems (IDS). A REST ODataservice
can also be called directly from within a Hybrid Web Container or synchronization application.
21. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE21Figure 10. SAP Mobile
Platform OData Infrastructure for NetWeaver GatewayDevice users may publish their logical device
address to the Gateway, allowing data change notifications to beforwarded from the Gateway to SAP
Mobile Platform middleware and onto the device. These notifications areguaranteed to be delivered to
the device. Device notifications may be registered over device platformspecificchannels like APNS or
BES.As with other messaging facilities, monitoring, and logging of middleware messages and
interactions is managedthrough the SAP Control Center management console.AGENTRY
APPLICATIONSAgentry applications provide support for multiple client devices and multiple
enterprise system connectionswithin a single set of business logic, or “definitions.” The Agentry
architecture provides 4thgeneration languagedevelopment of clientside behaviors of an application,
coupled with backend synchronization logic in thelanguage of the enterprise systems being mobilized.
The Agentry architecture provides forward compatibilityusing a deviceagnostic approach. The
SAP Mobile Platform 2.3 Architecture
Agentry Client component is provided in multiple builds, each of whichsupports the same
functionality set, which in turn allows for a single application project containing all businesslogic to
be deployed to a variety of device types.Typical use cases for an Agentry application include:
Mobile workflows with simple or complex business requirements and rules An intelligent client with
native ondevice data storage
22. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE22 Potential implementation
specific configurationAgentry also ships and supports several outofthebox bundled
applications.These applications typically include the following characteristics: The ability to process
a moderatetohigh volume of data Simple or complex user interface Online and offline support of
application functionality and data access Potential for multiple system connections between the
Agentry Server and enterprise systems, possiblywith different synchronization paradigms (for
example, SQL, Java, and so on)Agentry applications support fully configurable security and
authentication requirements, including enterprisesystem, LDAP, active directory, and
others.Applications are supported on Windows Mobile, Android, and iOS platforms, as well as
Windows PCs.The Agentry software components of the SAP Mobile Platform include the Agentry
Runtime Instance, whichserves as a proxy to backend synchronization or requests, Agentry Editor,
and the Agentry Clients. Eachcomponent serves a specific purpose, and all work together to provide
the overall software solution.
23. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE23Figure 11. Agentry environment
within SAP Mobile PlatformAgentry Runtime Application InstanceThe Agentry Application Instance
invokes synchronization logic for all production data between the backendsystem and the Agentry
Clients. The application instance in the middle tier does not cache any production data.The application
instance also distributes the application metadata “definitions” published from the Agentry Editorthat
are executed by the device client through the application instance. The server is the hub of both
productionand development environments. The behavior of the Agentry Application Instance is
affected by its configuration,the definition of the application it deploys, and whether the server is
configured for development or production.BackEnd System SupportAn Agentry Application Instance
can synchronize data between one or more backend systems for asingle application. With respect to
enterprise system integration, an application can synchronizeproduction data with a single system, or
with multiple back end systems of varying types. A singleapplication can synchronize data with: A
database system using SQL A Web Server, by making CGI requests and receiving structured XML
data in return The Windows host system upon which the Agentry Server is running A Java API
using the JVM An SAP backend system that supports Java Connector (JCO) technology
24. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE24Each Agentry Application
Instance can also connect to multiple backend systems, including any one ormore of those listed
above. The ability to connect to multiple backend systems and system types allowsfor data
synchronization from disparate systems in a seamless manner for mobile application end users.You can
use Connector Studio, which is part of the Agentry Editor, to configure connectivity to WSDL orSQL
systems. You can use the Agentry SDKs to develop custom code that provides connectivity logicfor
setting up backend connections. For example, you can use the Agentry “steplet” APIs to write
SAPbackend interface code that connects the Agentry application to ABAP. You can make
connections tomultiple backend systems using both custom code and Connector Studio configuration
for access via asingle application.Multiple Server InstancesSAP Mobile Platform 2.3 supports
clustered environments. You can deploy multiple instances of anAgentry application across a cluster to
provide load balancing and failover. In addition to the clusteredmobile server environment, you must
also use a hardware load balancer to distribute traffic across theinstances of the Agentry application. A
clustered environment lets you simultaneously configure multipleapplication instances, and propagate
configuration settings to all instances in the cluster. Whenapplication updates are published, each
application instance in the cluster withholds the latest version ofthe application from deployment to
the Agentry Clients until all servers in the cluster receive the updatedversion. This ensures consistent
version deployment across all mobile users.ClientServer Encrypted CommunicationsThe Agentry
Application Instance supports encrypted communication with the Agentry Clients. Thisincludes
SSL/TLS support and can use authentication certificates for the purposes of both server andclient
authentication.Production Data Synchronization“Production data” as used in Agentry refers to the data
and information that is sent to and received fromclients. The Agentry Application Instance receives
production data from clients to update the backendsystem, and retrieves data from the backend
system for the clients. The nature of this synchronization isentirely dependent on individual
application implementation.Application Data Synchronization“Application data” as used in Agentry
SAP Mobile Platform 2.3 Architecture
SAPcompany.Sybase and Adaptive Server, iAnywhere, Sybase 365, SQLAnywhere, and other Sybase
products and services mentioned hereinas well as their respective logos are trademarks or
registeredtrademarks of Sybase Inc. Sybase is an SAP company.Crossgate, m@gic EDDY, B2B 360°,
and B2B 360° Services areregistered trademarks of Crossgate AG in Germany and othercountries.
Crossgate is an SAP company.All other product and service names mentioned are the trademarks
oftheir respective companies. Data contained in this document servesinformational purposes only.
National product specifications may vary.These materials are subject to change without notice. These
materialsare provided by SAP AG and its affiliated companies ("SAP Group")for informational
purposes only, without representation or warranty ofany kind, and SAP Group shall not be liable for
errors or omissionswith respect to the materials. The only warranties for SAP Groupproducts and
services are those that are set forth in the expresswarranty statements accompanying such products and
services, ifany. Nothing herein should be construed as constituting an additionalwarranty..
ENGLISH
English
Français
Español
Português (Brasil)
Deutsch
English
Espanol
Portugues
Français
Deutsche
About
Careers
Dev & API
Press
Blog
Terms
Privacy
Copyright
Support