SAP Mobile Platform 2.3 Architecture

  • 16,250 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
16,250
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
11

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

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 ..............................................................................................................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 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 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 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: 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 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 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 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 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 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..