SAP CRM Mobile Platform

Published on May 2016 | Categories: Documents | Downloads: 59 | Comments: 0 | Views: 478
of 39
Download PDF   Embed   Report

SAP CRM Mobile Platform

Comments

Content

12/26/2014

SAP Mobile Platform 2.3 Architecture

 Home Explore Search You
TIRUPATI KENGUVA
Logout

 slideshare
Upload 
Back

TIRUPATI KENGUVA
My uploads
Account settings
Analytics
Logout
 

Search

Home
Leadership
Technology
Education
Marketing
Design
More Topics

 

 

 

Search

Save

Recommended   More from User
SAP Mobile Platform Architecture and
Strategy
SAP PartnerEdge program for Application
Development
6,330 views

The Canopy Cloud Vision
Thomas Kunz
3,133 views

SMP 3.0 Roadmap
Syambabu Allu
5,272 views

A Blueprint for Future Mobile Success:
SAP Mobile Platform 3.0
SAP Mobile
2,583 views

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

1/39

12/26/2014

SAP Mobile Platform 2.3 Architecture
SAP Mobile Platform
albertspijkers
588 views

SAP Mobile Platform ­ Product and
Roadmap
SAP PartnerEdge program for Application
Development
1,720 views

SAP mobile platform & mobile apps
Capgemini
3,494 views

Syclo Mobile Conference: Mobile Platform
Roadmap
SAP Mobile
4,364 views

SAP Mobile Platform Overview
SAP PartnerEdge program for Application
Development
2,049 views

Developing Synchronized Mobile Apps
with SAP Mobile Platform
SAP Mobile
1,201 views

Afaria Overview­ Architecture, Scaling,
Supported Platforms
SAP PartnerEdge program for Application
Development
7,033 views

Xamarin and SAP Mobile Platform for
Mobile Enterprise Success
Xamarin
885 views

SAP NetWeaver Gateway ­ Introduction
SAP PartnerEdge program for Application
Development
5,345 views

Hana overview
Syambabu Allu
1,142 views

SAP Mobility strategy and Portfolio ­ SAP
SAP Nederland
4,452 views

Introduction about SAP Netweaver
Gateway 2.0
Syambabu Allu
13,302 views

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

2/39

12/26/2014

SAP Mobile Platform 2.3 Architecture
SAP Runs SAP: Mobile Overview
SAP Mobile
2,530 views

SAP Mobile Strategy
SAP D­A­CH
861 views

Sybase Unwired Platform­ A Look at SAP
Mobile Platform Components
SAP PartnerEdge program for Application
Development
517 views

Smp agentry app_development
Ganeshkumar Sanur Gopalakrishnan
3,091 views

Smp agentry sap_framework
Ganeshkumar Sanur Gopalakrishnan
1,275 views

Afaria MDM
SAP PartnerEdge program for Application
Development
1,395 views

Sap fiori net weaver gateway and o­data
basics
Syambabu Allu
2,221 views

SAP Mobile Platform ­ Product and
Roadmap
SAP PartnerEdge program for Application
Development
1,063 views

Roland Haeve (Atos): 'Using the Cloud for
Big Data Analytics'
AlmereDataCapital
2,884 views

SAP Mobile Apps Certification Guidelines
Document
Syambabu Allu
755 views

SAP Mobile Documents Overview
SAP Mobile
463 views

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

3/39

12/26/2014

SAP Mobile Platform 2.3 Architecture
Architecture and Technology in SAP
HANA
SAP Community Network
31,726 views

How to use data change notification for cdb
update
Syambabu Allu
1,859 views

How to build an agentry based mobile app
from scratch connecting to an sap back……
Ganeshkumar Sanur Gopalakrishnan
2,362 views

Introducing SAP Fiori ­ Keeping Simple
Things Simple
SAP Mobile
19,794 views

Evaluation service for SAP
BusinessObjects mobile software
SAP Middle East and North Africa
120 views

Movilidad asug
Ricardo Gómez Vecchio
72 views

Air Products and Chemicals, Inc. ­ SWOT
Analysis
ReportLinker.com
95 views

Sybase Unwired Platform­ Data Change
Notification
SAP PartnerEdge program for Application
Development
1,542 views

Canopy consulting ­ Our core beliefs
Canopy
197 views

Via forensics icloud­
keychain_passwords_13
viaForensics
47 views

Canopy consulting ­ Introduction
Canopy
815 views

SAP MDM ONLINE TRAINING | MDM
Project Support | MDM Certification
Training
balusapbest
68 views

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

4/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

Code Re­signing
CrowdCompass
1,280 views

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

5/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

6/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

7/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

8/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

9/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

10/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

11/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

12/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

13/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

14/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

15/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

16/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

17/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

18/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

19/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

20/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

21/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

22/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

23/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

24/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

25/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

26/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

27/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

Upcoming SlideShare
Loading in...5
×
25 of 27

16,234

SAP Mobile Platform 2.3 Architecture

views

Syambabu Allu (24 SlideShares) , SAP Technical Consultant at Capgemini

+ Follow
6

4

2

1

Uploaded on Jun 06, 2013

Statistics

 

11 Likes

 

0 Comments

 

More in: Technology 

Notes

Full
Name 

Comment goes here.
12 hours ago  Delete •  Reply •  Spam •  Block

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

28/39

12/26/2014

SAP Mobile Platform 2.3 Architecture

  Share your thoughts...

Post

Be the first to comment

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

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

29/39

12/26/2014

SAP Mobile Platform 2.3 Architecture
..............................................................................................................23Back­End System
Support......................................................................................................................................23Multiple
Server Instances
.......................................................................................................................................24
3. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE3Client­Server 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 industry­specific applications,
consultants who track time and expenseson a mobile device, or simple corporate approvals. SAP
Mobile Platform supports these mobile scenarios as wellas cross­industry applications, such as
customer relationship management, human resources, supply chainmanagement, business intelligence,
product life cycle management, and industry­specific 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.  End­user 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 user­driven 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 back­end system  Lightweight form editing  Situation­oriented toward a few screens rather than
a complex application  Targeted notification from the back end gives alerts to the 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 off­line applications are task oriented, and must provideinformation to end users,
regardless of connectivity. Characteristics of offline applications include:  Data synchronization to
devices based on enterprise­level process rules  Task­oriented process, resulting in complex UI
navigations  Ready for heavy customization, since processes are unique per enterprise  Push­enabled
for real­time user experience  Strong administrative tools for support, monitoring, and 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

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

30/39

12/26/2014

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 object­based APIs based on the device platform language
Support for mobile Web­based clients within a secure enterprise sandbox  Eclipse­based visual
development tooling for building mobile data services and generating device­sidedata persistence
APIs  Enterprise mobilization architecture that uses standard and proprietary interfaces to support a
variety ofenterprise data resources  End­to­end pluggable security that extends from the enterprise to
devices  Support for mobile users who are either occasionally connected or those that work entirely
online  Push notifications that alert clients to refresh their mobile view of data  Unified platform
administration and monitoring
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 Cross­platform
request/reply or lookup  Mobile workflow patternsNative applications using synchronization:o
Agentry applications that are synchronized directly against the back endo Mid­tier result­set 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  REST­based 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 mid­tier
cache synchronization instead. DOE is not described in detail in this document; refer to the DOE and
DOE­C 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 mid­tier synchronization model is developed, the developer starts building an application byusing
Eclipse­based 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 mid­tier modelartifacts are mobile business objects (MBOs), which describe the interaction
with the back­end data, and thedevice­side 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. Back­end 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 back­end resource. OData is aresource­based 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 back­end system.Data and information sent to and received from

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

31/39

12/26/2014

SAP Mobile Platform 2.3 Architecture
Clients relate to the day­to­day operations of the softwaresolution. The Agentry Instance receives
production data from the Clients to update to the back­end system, andto retrieve the data from the
back­end 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 consumer­facing
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 well­incorporated 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 technology­specific 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 medium­to­large deployments.The mobile middleware is well
integrated with the SAP Solution Manager for technical monitoring, alerting, root­cause 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 root­cause analysis is incorporated
through end­to­end 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 mid­tier
MBO’s.3Native applications synchronize directly with the SAP Mobile Platform mid­tier 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. REST­based 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

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

32/39

12/26/2014

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 built­in 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. In­transitasynchronous 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 on­line are guaranteed to be delivered. Ifthe device is
off­line 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 “on­boarding.” A device can be on­boarded 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 user­supplied 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 long­lasting 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:

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

33/39

12/26/2014

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 device­resident 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
back­end 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 application­specific (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 in­box
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 expression­centric 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 back­end 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 non­SAP 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 device­supplied parameters. The mobile content model and the mapping to theback end are

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

34/39

12/26/2014

SAP Mobile Platform 2.3 Architecture
directly integrated.This style of coupling between the device and the back­end queries implies that the
back end must be able torespond to requests from the middleware based on user­supplied 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
mobile­specific 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 non­SAP back­ends 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 andback­end tiers. The assumption is that if
data changes on one tier (for example, the enterprise system­of­record),
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 container­managed 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 CacheCache­based synchronization uses the cache as a record
keeper of what enterprise data users have on thedevice. While the cache is not the system­of­record, 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

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

35/39

12/26/2014

SAP Mobile Platform 2.3 Architecture
request to synchronize data to a device, the cache is loaded. This “on­demand” 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 non­zero 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 middle­tier 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 on­line the message is sent viathe asynchronous
messaging middleware. When the device application is off­line 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 off­line applications  Publishes device application specific settings configured by the
administrator  Blacklists specific application instances  Delegates Internet authentication to third
parties and support single sign­on (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: SDK­based messaging and
REST. Both of these protocols run over HTTP(S) although REST is not end­to­endencrypted 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 platform­specificchannels 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 client­side behaviors of an application,
coupled with back­end synchronization logic in thelanguage of the enterprise systems being mobilized.
The Agentry architecture provides forward compatibilityusing a device­agnostic approach. The

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

36/39

12/26/2014

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 on­device data storage
22. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE22  Potential implementation­
specific configurationAgentry also ships and supports several out­of­the­box bundled
applications.These applications typically include the following characteristics:  The ability to process
a moderate­to­high 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 back­end 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 back­endsystem 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.Back­End System SupportAn Agentry Application Instance
can synchronize data between one or more back­end 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 back­end system that supports Java Connector (JCO) technology
24. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE24Each Agentry Application
Instance can also connect to multiple back­end systems, including any one ormore of those listed
above. The ability to connect to multiple back­end 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 back­end connections. For example, you can use the Agentry “steplet” APIs to write
SAPback­end interface code that connects the Agentry application to ABAP. You can make
connections tomultiple back­end 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.Client­Server 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 back­endsystem, and retrieves data from the back­end
system for the clients. The nature of this synchronization isentirely dependent on individual
application implementation.Application Data Synchronization“Application data” as used in Agentry

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

37/39

12/26/2014

SAP Mobile Platform 2.3 Architecture
refers to the data that represents the application itself, that is, thebusiness logic and user interface of
the mobile application. Definitions are created and modified in theAgentry Editor, which then
publishes them to the Agentry Server. The server provides these definitionsto clients during the
standard synchronization process. This behavior allows for the easy deployment ofapplication changes,
customizations, and upgrades.
25. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE25Agentry ClientsThe Agentry
Client can run on a wide array of device platforms, and can take advantage of the features
andbehaviors that are inherent to each client device. Furthermore, the native look and feel of a given
device type ispart of the Agentry Client’s presentation layer. Scanner­enabled devices, devices
equipped with GPS units,tablets, laptops, desktops, and mobile devices are all supported. A single
application deployment can supportany or all of these client device types. The Agentry Clients also
support a wide array of communication types.Standard network connections, wireless LAN, wireless
WAN, and cell data protocols are all supported by theAgentry Clients and Agentry Server for client­
server communications. Default connections are encrypted withSSL/TLS, with support for full server
and client authentication via trusted root certificates and authorized signedcertificates.Agentry Editor
Eclipse Plug­InThe Agentry Editor is a point­and­click, 4th generation development tool for defining
complex mobile applicationsdeployed to the Agentry Clients through the Agentry Server. Install the
Agentry Editor plug­in, which is providedas part of the SAP Mobile Platform SDK, in an Eclipse
implementation. Maintain projects within an Eclipseworkspace, which can also include the
synchronization logic projects for any Java packages. SQL, file systemscripts, and XPath markup for
Web Service system connections are stored as part of the Agentry applicationproject.Create and
modify definitions in the Agentry Editor, then publish them to the Agentry Server. The Server in
turndeploys business logic to the Agentry Clients during normal synchronization. The project
components thatdictate synchronization behavior remain with the Agentry Server and are processed by
it based on client request.Agentry applications do not cache data in the middleware layer. Instead, data
synchronization is defined by thedeveloper to use the Exchange Data Model to perform delta retrieval.
Transaction data that is captured on theclients is transmitted to the Agentry Server and updated
directly to the enterprise system based on thesynchronization logic defined for the transaction.
Transaction data remains on the Agentry Client until theAgentry Server reports successful processing
of the data.Administration ConsoleManage Agentry applications by using SAP Control Center to
configure communication settings between theAgentry Clients and Agentry Server, and between the
Agentry Server and the enterprise system, as well aslogging behaviors and other similar
tasks.MOBILE MIDDLEWARE TOPOLOGYThe mobile middleware may be configured on a single
host or multiple hosts based on the selection of threeindependently installable units:  Application
server node – native and Java processes that constitute the sum of all mobile services. Atleast one of
these processes must exist in the deployment landscape. High availability (HA)considerations must
account for the application server. HA configured application server nodes may be
26. SAP MOBILE PLATFORM VERSION 2.3 ARCHITECTURE26run in an active/active
configuration where both are servicing requests. Alternatively, the HAconfiguration may be
configured in Microsoft Cluster active/passive mode.  Scale­out node – the Java processes that
exclude the native replication and messaging servers. One ormore of these nodes is optional as all of
its services also reside on the application server node. Thescale­out node is not a consideration in HA
but is intended to provide additional processing power forREST or DCN services.  Data tier node –
the embedded database server. HA considerations must account for the data tier in anactive/passive
mode where one node is idle until the other fails.Figure 12. Mobile Middleware TopologyWhen a
combination of application server and scale­out nodes are installed, any synchronization
orasynchronous workflow traffic is routed from scale­out nodes to an application server node that
hosts the nativeprocesses for synchronization and messaging, respectively. In this configuration, the
system uses a clusteredin­memory cache across application server and scale­out nodes to optimize the
availability of deviceconfiguration settings. While session affinity is not necessary for REST or DCN,
session affinity is required fornon­persistent HTTP sessions involving synchronization or messaging.
27. www.sap.com© 2013 SAP AG. All rights reserved.SAP, R/3, SAP NetWeaver, Duet,
PartnerEdge, ByDesign, SAPBusinessObjects Explorer, StreamWork, SAP HANA, and other
SAPproducts and services mentioned herein as well as their respectivelogos are trademarks or
registered trademarks of SAP AG in Germanyand other countries.Business Objects and the Business
Objects logo, BusinessObjects,Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, andother
Business Objects products and services mentioned herein aswell as their respective logos are
trademarks or registered trademarksof Business Objects Software Ltd. Business Objects is an

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

38/39

12/26/2014

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

LinkedIn Corporation © 2014

http://www.slideshare.net/SyambabuAllu/sap­mobile­platform­version­23­architecture?related=1

39/39

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close