SAP Mobile Platform Version 2.3. Architecture

Transcription

1 SAP Mobile Platform Version 2.3 Architecture

2 TABLE OF CONTENTS INTRODUCTION... 4 MOBILIZING THE ENTERPRISE... 4 Online Mobile Applications... 4 Offline Mobile Applications... 4 Common Characteristics... 5 OVERVIEW OF THE SAP MOBILE PLATFORM... 5 Basic Development and Deployment Process... 7 COMMON ELEMENTS OF THE ARCHITECTURE... 8 Network Topology... 8 Administration and Monitoring... 9 Device Services...11 Messaging Services...12 Security Services...12 HYBRID WEB CONTAINER APPLICATIONS Hybrid Web Messaging Components...14 Hybrid Web Container Device Runtime...14 Hybrid App Designer...14 Middleware Messaging for the Container...15 Administration Console...16 MOBILE SYNCHRONIZATION APPLICATIONS Cache Synchronization...16 Cache Synchronization Components...16 Core Components...17 The Cache...18 SAP ODATA APPLICATIONS AGENTRY APPLICATIONS Agentry Runtime Application Instance...23 Back-End System Support...23 Multiple Server Instances

3 Client-Server Encrypted Communications...24 Production Data Synchronization...24 Application Data Synchronization...24 Agentry Clients...25 Agentry Editor Eclipse Plug-In...25 Administration Console...25 MOBILE MIDDLEWARE TOPOLOGY

4 INTRODUCTION This document is for service providers and enterprises that plan to deploy the SAP Mobile Platform (SMP) and need a functional understanding of the technology to assist in making informed decisions about choosing the correct mobile technology to use for a particular use case. It includes some level of detail about the internal workings 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 it useful to consult other material specifically related to development fundamentals or tutorials. MOBILIZING THE ENTERPRISE Individuals and businesses develop mobile applications for specific user needs ranging from teams of service workers who use ruggedized devices for industry-specific applications, consultants who track time and expenses on a mobile device, or simple corporate approvals. SAP Mobile Platform supports these mobile scenarios as well as cross-industry applications, such as customer relationship management, human resources, supply chain management, business intelligence, product life cycle management, and industry-specific applications tailored for the service provider, chemical/pharmaceutical, and utilities industries. All these mobile applications follow two broad 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, an employee lookup IT- or Line of Business (LOB) driven, to improve organizational efficiency and customer engagement, for example, sales process enablement These two patterns inherently represent two broad categories of mobile applications, which may support operations that are only allowed while connected to the network or that have features to support operation while disconnected. These two classes of applications differ significantly in functional and some nonfunctional aspects. However, they share common attributes, such as security. Online Mobile Applications Online mobile applications are completely user-driven and the LOB is seldom involved in support of their daily operation. Information access is ad hoc in nature, and users typically know what they are looking for in a given situation. 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 user Offline Mobile Applications Offline mission critical applications are typically supported by IT specialist on behalf of a LOB to gain organizational efficiency. Supporters of the LOB infrastructure are heavily involved in mobile operations for most offline cases, information access is formalized in nature, and the business process dictates the information that 4

5 each user will act on. In general, mission critical off-line applications are task oriented, and must provide information 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 management Common Characteristics Both online and offline applications require these common IT and application management capabilities: 1. Secure onboard processes to bring user devices into the enterprise landscape 2. Device, data, and transport security 3. Ability to troubleshoot error conditions with supportability toolsets 4. Remote device management These common characteristics introduce a need for a common platform covering both application categories. OVERVIEW OF THE SAP MOBILE PLATFORM The SAP Mobile Platform primary value proposition is in serving as an information bridge between device users and 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 that provides: 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-side data persistence APIs Enterprise mobilization architecture that uses standard and proprietary interfaces to support a variety of enterprise 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 5

6 Figure 1. Platform Overview In SAP Mobile Platform, one or more of these technologies come together to provide support for a few major types 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 end o Mid-tier result-set cache synchronization o 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 SDK o Request/reply or lookup with device specific native notifications 1 DOE is not recommended for new mobility solutions; it is supported for backward compatibility with existing applications. For new applications use midtier cache synchronization instead. DOE is not described in detail in this document; refer to the DOE and DOE-C documentation for specifics related to this technology. 6

7 The purpose and function of the major application pillars is discussed in more detail later in this document, along with the major technology components that support them. Basic Development and Deployment Process In cases where a mid-tier synchronization model is developed, the developer starts building an application by using Eclipse-based tooling to discover assets of enterprise data sources and to tailor the mobile interaction pattern (which usually involves selecting data subsets) for mobilization. The most significant mid-tier model artifacts are mobile business objects (MBOs), which describe the interaction with the back-end data, and the device-side data representation. An MBO is a middleware object that describes mobile data and operations on that data. Operations on an MBO are typically record related, but can also be operations that are directly invoked against the back end. Changes made to MBO data on the device are reflected in the back end. Back-end changes are communicated to the user when the middleware notifies the device application of an update and the application subsequently synchronizes the 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 that can be deployed into the server runtime environment. Each package is assigned a version that is associated with the specific runtime artifacts generated by the deployment architecture. Figure 3. Development Paradigm 7

8 SAP Mobile Platform also supports the Open Data Protocol (OData) as a back-end resource. OData is a resource-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 OData implementations. 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 model elements (MBOs) in SAP Mobile WorkSpace, but rather inherits a service model from the service document published from the back end, for example SAP NetWeaver Gateway. These OData service documents contain all 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 software solution. The Agentry Instance receives production data from the Clients to update to the back-end system, and to retrieve the data from the back-end system for the Clients. The nature of this synchronization is entirely dependent on the implementation of the application. COMMON ELEMENTS OF THE ARCHITECTURE Network Topology The replication and messaging components in the SAP Mobile Platform architecture are typically installed alongside other corporate Web server assets. A load balancer and one or more reverse proxy servers are installed in the DMZ to insulate the Web server and mobile middleware from direct internet traffic 2. When a mobile middleware cluster is used the data tier of the SAP Mobile Platform may be positioned in a zone alongside other enterprise database servers. A load balancer may also be positioned between backend servers and the SAP Mobile Platform Web server nodes when data change notifications need to be sent to both nodes in the SAP Mobile Platform cluster. SAP Afaria technology deploys device applications and helps configure those applications as well as managing, and helping to secure certain enterprise data on devices. Afaria technology interacts with the device platform s local management facilities on the device to enforce enterprise policies. For some platforms, Afaria also offers an enterprise application store as an alternative to consumer-facing provisioning facilities. 2 The SAP Relay Sever is an optional component that should only be used where standard proxy technologies are not practical and low traffic demand is expected. For the best security and performance a standard reverse proxy that is well-incorporated into the existing Internet landscape should be used. 8

9 Figure 4. Network Topology The following sections describe some of the technology-specific SAP Mobile Platform usage patterns and provide a general discussion of the architecture involved. Administration and Monitoring The SAP Control Center service acts as a control facility for SAP Mobile Server technology. This JMX-based agent has an embedded Web server to which SAP Control Center communicates, and an associated database for managing its own control and alerting metadata. 9

10 Figure 5. Management Infrastru cture From 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 applications within a single server runtime. A domain administrator can configure elements only for a domain to which 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 and application statistics. These records are written asynchronously to the monitoring database. SAP recommends that you isolate the monitoring database on its own hardware if you perform a significant amount of monitoring during production in medium-to-large deployments. The mobile middleware is well integrated with the SAP Solution Manager for technical monitoring, alerting, rootcause analysis, change diagnostics, and workload analysis. The complete mobile middleware landscape is discoverable and all error logs are scanned by locally installed Solution Manager Agents. Workload analysis may be accomplished by utilizing Wily IntroScope instrumentation that provides key performance indicators for major mobile middleware components. SAP Solution Manager root-cause analysis is incorporated through end-to-end tracing. Tracing is enabled through an administrative action that allows a device application to initiate a business transaction level trace that 10

11 incorporates several independent operations. This trace is captured in the middleware components, logged, and passed to the SAP backend. After tracing is complete the traces are uploaded by local agents to the Solution Manager for analysis in the context of the entire landscape. Device Services There 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 use case 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. 3 Native applications synchronize directly with the SAP Mobile Platform mid-tier cache utilizing an efficient replication technology to move data between the server cache and the device UltraLite database. Native OData applications use synchronous messaging calls to interact with the SAP Online Data Proxy and the SAP NetWeaver 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 Stack 3 This same asynchronous messaging subsystem is used to communicate with the legacy SAP Mobile Platform Data Orchestration Engine (DOE). 11

12 Security features are embedded into the SDK to support secure certificate storage, use of these artifacts in authentication 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 security artifacts. 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 user authentication. These are a part of the built-in functionality, requiring the configuration of properly signed certificates and trusted root certificates in the appropriate areas. Messaging Services The workflow architecture, Hybrid Apps, DOE, and device notification mechanism leverage a proprietary asynchronous message service to move data between device and server. This messaging service is based on the HTTP protocol but uses a proprietary binary payload that is compressed and encrypted. In-transit asynchronous messages are stored in the server s cache database messaging queues until a notification is sent to the device instructing the device messaging layers to pull the payload from the messaging service on the server. Once consumed by the SDK client layer the messages reside in the device database until processed by the device application layer. Messages are encrypted on the device. OData SDK applications use the same messaging infrastructure but use synchronous messaging mode for request/reply traffic. OData SDK applications must ensure completion of a request by testing for error conditions. Proprietary notifications sent to the OData SDK while it is on-line are guaranteed to be delivered. If the device is off-line and the application is not able to maintain a connection with the server, the server will send a device platform specific notification (APNS, BES, etc.) informing the application that it has data waiting on the server. To receive application settings notifications, and messages, devices must be registered with the server via a process called on-boarding. A device can be on-boarded either manually (administratively whitelisted) or through an automatic process based on a security domain that is associated with the device user s login credentials. Within SAP Control Center, the administrator associates packages with a security domain under the heading 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 can operate in both online and offline mode, with all data stored locally on the client, and support for delta (exchange data model) synchronization. The mode is driven by the definition of the application s business logic. Security Services SAP 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 Active Directory. Secure connections can also be established with Secure Sockets Layer (SSL) between the device and replication channel. Device databases may also be encrypted with a user-supplied key. 12

13 HYBRID WEB CONTAINER APPLICATIONS Hybrid Web Container bridges the deficiencies of today s mobile Web browsers with the power of device OS services like GeoLocation. This paradigm enables developers to build rich applications using Web technologies and 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 and call 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, and so on, that include these characteristics: Low data volume Simple user experience No long-lasting offline stateful transactions Simple business logic The Hybrid Web Container supports three basic patterns. In many applications, a combination of these patterns is applied to implement specific use cases. Simple request/response or lookup applications using either the SDK messaging API s or REST-based invocations. Hybrid Web Container notifications that are the result of an MBO data change operation sent from the back end via the middleware in the context of a business process resulting in mobile users receiving information that they can act on. Action/Decision Forms that incorporate SDK request, responses, and notifications users take action on devices to submit a form, make a decision, and so on, which results in some enterprise business process state transition. The Hybrid Web Container is the device runtime within which these services are executed. The Hybrid Web Container is a native application with an embedded browser that allows developers to build applications with the simplicity of Web development combined with the power of native device services. SAP Mobile Platform delivers a native application for ios, Android, Windows Mobile and BlackBerry platforms. In addition to the standard Web browser capabilities available in standard HTML/CSS/JS code, the Hybrid Web Container also provides these additional 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 13

14 Hybrid Web Messaging Components Hybrid Web Container Device Runtime This device-resident native application provides a runtime environment for Hybrid Apps, and must be deployed once using an application provisioning tool such as Afaria. Thereafter, applications are automatically deployed when the container runs on the device, and the protocol between the container and the server identifies version differences. Figure 7. Hybrid Web Components Hybrid App Designer The Hybrid App Designer is the WYSIWYG tool for building lightweight applications that run in the Hybrid Web Container. The Designer, which is included with SAP Mobile Platform, is a tool that helps design the user interface and test the flow of the business process for a Hybrid Web Container application. Using the Hybrid App Designer allows you to develop Hybrid App screens that can call create, update, and delete operations, as well as object queries, of a mobile business object. Package files are generated using the Hybrid App Package generation wizard in the Hybrid App Designer. The generated Hybrid App package contains files that reference a mobile business object (MBO) package, an MBO in that package, and the operation or object query to call, as well as a mapping of which key values map to parameter values. 14

15 The generated Hybrid App package s output is translated to HTML/CSS/JavaScript. The logic for accessing the data and navigating between screens is exposed as a JavaScript API. Packages can be deployed to SAP Mobile Server and assigned to users using the editor in Eclipse. Middleware Messaging for the Container The container messaging architecture relies on SAP Mobile Platform middleware to integrate and mobilize data sources using the core SAP Mobile Platform modeling concept called MBO. Middleware provides connectivity to various back ends through this intermediate MBO runtime construct, thereby providing a single interface for device application developers and abstracting the complexity of the back end. It also securely provisions Hybrid Web Container applications based on the application assignments. The communication between the container and 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 in the SAP Mobile Server. Additionally, changes to back-end processes, generally sent via data change notifications (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 by the messaging transformer component, which augments the message with application-specific (MBO) data or processing instructions. Figure 8. Hybrid Web Messaging Architecture Once transformed, the augmented message may be queued for transmission to the mobile device when the device next connects to the SAP Mobile Server. A notification is sent to the device container where the application can choose what action to take, such as connecting to the server. Once the device connects, data messages are pulled from the server and stored in the device s queue where they await the user s actions. 15

16 When a user loads an in-box message, the appropriate form is loaded by the application, and the user may perform application-provided actions (such as approving an expense request). Administration Console Hybrid Apps are managed and deployed through the same management/administration console used to manage SAP Mobile Platform. This console provides the ability to assign applications to devices users and groups based on regular expression-centric matching rules. This console also enables platform state monitoring, and provides metrics for tuning. MOBILE SYNCHRONIZATION APPLICATIONS Synchronization applications provide transactional consistency between the mobile device, the middleware, and the back-end system. These custom applications are designed and built to suit specific business scenarios, or may start with a bespoke application that is adapted with a large degree of customization. There are several application 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 key performance indicators (KPIs). Cache Synchronization Cache 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. When SAP Mobile Platform is used in a standalone manner for data synchronization, it utilizes an efficient bulk transfer and data insertion technology between the middleware cache and the device database. The mobile application is designed such that the developer specifies how to load data from the back end into the cache, and then filters and downloads cache data using device-supplied parameters. The mobile content model and the mapping to the back end are directly integrated. This style of coupling between the device and the back-end queries implies that the back end must be able to respond to requests from the middleware based on user-supplied parameters, and serve up mobile data appropriately. In other words, the back end should be capable of returning what an individual device user may request by supplying an appropriate interface. Normally, some mobile-specific adaptation is required within SAP Business Application Programming Interfaces (BAPI). Because of the direct nature of application parameter mapping and replication protocol efficiencies, SAP Mobile Platform cache synchronization deployment is ideal for: 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 interfaces Cache Synchronization Components The goal of synchronization is to keep data and operations (that is, the state) consistent between the device and back-end tiers. The assumption is that if data changes on one tier (for example, the enterprise system-of-record), 16

17 all other tiers interested in that data (mobile devices, intermediate staging areas/caches, and so on) are eventually synchronized to have the same data/state. Core Components The SAP Mobile Server synchronizes data between the device and the back end by maintaining records of device synchronization activity in its consolidated database, along with any cached data that may have been retrieved from the back end or pushed from the device. The SAP Mobile Server employs several components in the synchronization chain: Mobile channel interfaces provides a conduit for transporting data from and to remote devices over which data is replicated between devices and the mobile middleware. Mobile Middleware Services (MMS) arbitrates and manages communications between device requests from the mobile channel interfaces to a form that is suitable for transformation to a common MBO 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 sends messages to the device based on changes to the middleware cache or events from the backend such as OData subscriptions notifications or workflow data change events Once a mobile application model is designed, it can be packaged and deployed to the SAP Mobile Server where it operates as part of a specialized middleware container-managed application package interfacing with MMS and DS components. When a package is deployed, its associated database cache tables are created along with database operations that manage that package s cache data. The middleware cache helps alleviate load from the backend system, especially when many devices are downloading data at once, but the backend remains the system of record. 17

18 Figure 9. SAP Mobile Platform Cache Synchronization Architecture The Cache Cache-based synchronization uses the cache as a record keeper of what enterprise data users have on the device. While the cache is not the system-of-record, it allows the server to compare the last time cache elements were updated with the time the specific data elements on the device were last successfully synchronized. This mechanism allows the server to download only the elements that have changed since the last device synchronization. The cache is manifested in an embedded relational database management system. The server, specifically the application package hosted in the application server, communicates to the cache database through JDBC connection pools, which can be configured in the administration console. The MBO parameters and the relationship between MBOs define the shape of cache tables. The internal implementation of these tables and the 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 is removed from the server, the cache is removed. Cache data can be shared or partitioned based on application parameters defined in the MBO model. If an MBO definition loads data where two application users have overlapping synchronization parameters, the users are sharing the same data. However, if the application model defines 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. 18

19 Shared cache data is typically reference or master data that is not updated by device users. Updating shared data incurs locking costs in the server and should be, if possible, performed infrequently and during periods of low user activity. To the extent possible, the MBO model should be designed to partition user data (via a unique user-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 cache group 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 middleware cache, 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 is the least desirable method as the device must wait for the specified cache data to load from the backend. The cache can have a coherence window based on the last time the cache was loaded. If the coherence window is zero every user request will cause the associated segment or partition of the cache to be loaded on every request. If the request is non-zero and the request is within the coherence window the request is serviced from the cache. Scheduled cache refreshes pull data from the backend. This method is typically only desirable for reference data since the parameters to load the cache must be configured outside the context of any user 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 most desirable method of loading the cache for either initial loads or subsequent changes. Initial loads using DCN can be spread across multiple members of the cluster and subsequent changes are surgical and proactive. 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 database over the replication channel. Uploads (from the device), consisting of device initiated data changes and operations, are passed asynchronously to the MMS component (with respect to the download) into JMS Messaging Channel queues and replayed in their own thread against the data services interfaces to the back end and the cache. By default, the upload of changes is independent of the download although the user may configure the application to always download changes right away. This decoupling of upload and download is referred to as asynchronous operation replay which is the default behavior 4. Once the upload changes are applied to the backend any resultant changes, along with changes caused by other systems, are ready for download. The download phase occurs as a result of device application synchronization. The device application may be user initiated (users manually triggers a synchronization) or because the application is programmed to respond to a middleware notification to synchronize. The device will 4 Applications built prior to Sybase Unwired Platform 2.1 ESD 2 couple upload and download transmissions. 19

20 receive a notification when the middleware detects a cache change that affects a cache partition that is correlated to a device user s application data. When a synchronization device is on-line the message is sent via the asynchronous messaging middleware. When the device application is off-line a platform specific device notification (APNS, BES, etc.) is sent to the device application. SAP ODATA APPLICATIONS The SAP NetWeaver Gateway exposes OData with extensions specific to SAP. SAP Mobile Platform serves as the IT infrastructure in a production environment by providing the following services: Establishes formal registration of device application instances before accessing enterprise resources for both 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 message queues on the device, in the middleware, and associated database disk I/O, and may allow horizontal scaling of the middleware. The middleware provides two forms of communication with enterprise OData resources: SDKbased messaging and REST. Both of these protocols run over HTTP(S) although REST is not end-to-end encrypted and therefore may be more amenable to firewall intrusion detection systems (IDS). A REST OData service can also be called directly from within a Hybrid Web Container or synchronization application. 20

21 Figure 10. SAP Mobile Platform OData Infrastructure for NetWeaver Gateway Device users may publish their logical device address to the Gateway, allowing data change notifications to be forwarded from the Gateway to SAP Mobile Platform middleware and onto the device. These notifications are guaranteed to be delivered to the device. Device notifications may be registered over device platform-specific channels like APNS or BES. As with other messaging facilities, monitoring, and logging of middleware messages and interactions is managed through the SAP Control Center management console. AGENTRY APPLICATIONS Agentry applications provide support for multiple client devices and multiple enterprise system connections within a single set of business logic, or definitions. The Agentry architecture provides 4 th generation language development of client-side behaviors of an application, coupled with back-end synchronization logic in the language of the enterprise systems being mobilized. The Agentry architecture provides forward compatibility using a device-agnostic approach. The Agentry Client component is provided in multiple builds, each of which supports the same functionality set, which in turn allows for a single application project containing all business logic 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 21

22 Potential implementation-specific configuration Agentry 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, possibly with different synchronization paradigms (for example, SQL, Java, and so on) Agentry applications support fully configurable security and authentication requirements, including enterprise system, 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, which serves as a proxy to back-end synchronization or requests, Agentry Editor, and the Agentry Clients. Each component serves a specific purpose, and all work together to provide the overall software solution. 22

23 Figure 11. Agentry environment within SAP Mobile Platform Agentry Runtime Application Instance The Agentry Application Instance invokes synchronization logic for all production data between the back-end system 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 Editor that are executed by the device client through the application instance. The server is the hub of both production and 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 Support An Agentry Application Instance can synchronize data between one or more back-end systems for a single application. With respect to enterprise system integration, an application can synchronize production data with a single system, or with multiple back- end systems of varying types. A single application 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 23

24 Each Agentry Application Instance can also connect to multiple back-end systems, including any one or more of those listed above. The ability to connect to multiple back-end systems and system types allows for 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 or SQL systems. You can use the Agentry SDKs to develop custom code that provides connectivity logic for setting up back-end connections. For example, you can use the Agentry steplet APIs to write SAP back-end interface code that connects the Agentry application to ABAP. You can make connections to multiple back-end systems using both custom code and Connector Studio configuration for access via a single application. Multiple Server Instances SAP Mobile Platform 2.3 supports clustered environments. You can deploy multiple instances of an Agentry application across a cluster to provide load balancing and failover. In addition to the clustered mobile server environment, you must also use a hardware load balancer to distribute traffic across the instances of the Agentry application. A clustered environment lets you simultaneously configure multiple application instances, and propagate configuration settings to all instances in the cluster. When application updates are published, each application instance in the cluster withholds the latest version of the application from deployment to the Agentry Clients until all servers in the cluster receive the updated version. This ensures consistent version deployment across all mobile users. Client-Server Encrypted Communications The Agentry Application Instance supports encrypted communication with the Agentry Clients. This includes SSL/TLS support and can use authentication certificates for the purposes of both server and client authentication. Production Data Synchronization Production data as used in Agentry refers to the data and information that is sent to and received from clients. The Agentry Application Instance receives production data from clients to update the back-end system, and retrieves data from the back-end system for the clients. The nature of this synchronization is entirely 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, the business logic and user interface of the mobile application. Definitions are created and modified in the Agentry Editor, which then publishes them to the Agentry Server. The server provides these definitions to clients during the standard synchronization process. This behavior allows for the easy deployment of application changes, customizations, and upgrades. 24

25 Agentry Clients The Agentry Client can run on a wide array of device platforms, and can take advantage of the features and behaviors that are inherent to each client device. Furthermore, the native look and feel of a given device type is part 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 support any 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 the Agentry Clients and Agentry Server for client-server communications. Default connections are encrypted with SSL/TLS, with support for full server and client authentication via trusted root certificates and authorized signed certificates. Agentry Editor Eclipse Plug-In The Agentry Editor is a point-and-click, 4th generation development tool for defining complex mobile applications deployed to the Agentry Clients through the Agentry Server. Install the Agentry Editor plug-in, which is provided as part of the SAP Mobile Platform SDK, in an Eclipse implementation. Maintain projects within an Eclipse workspace, which can also include the synchronization logic projects for any Java packages. SQL, file system scripts, and XPath markup for Web Service system connections are stored as part of the Agentry application project. Create and modify definitions in the Agentry Editor, then publish them to the Agentry Server. The Server in turn deploys business logic to the Agentry Clients during normal synchronization. The project components that dictate 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 the developer to use the Exchange Data Model to perform delta retrieval. Transaction data that is captured on the clients is transmitted to the Agentry Server and updated directly to the enterprise system based on the synchronization logic defined for the transaction. Transaction data remains on the Agentry Client until the Agentry Server reports successful processing of the data. Administration Console Manage Agentry applications by using SAP Control Center to configure communication settings between the Agentry Clients and Agentry Server, and between the Agentry Server and the enterprise system, as well as logging behaviors and other similar tasks. MOBILE MIDDLEWARE TOPOLOGY The mobile middleware may be configured on a single host or multiple hosts based on the selection of three independently installable units: Application server node native and Java processes that constitute the sum of all mobile services. At least 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 25

26 run in an active/active configuration where both are servicing requests. Alternatively, the HA configuration may be configured in Microsoft Cluster active/passive mode. Scale-out node the Java processes that exclude the native replication and messaging servers. One or more of these nodes is optional as all of its services also reside on the application server node. The scale-out node is not a consideration in HA but is intended to provide additional processing power for REST or DCN services. Data tier node the embedded database server. HA considerations must account for the data tier in an active/passive mode where one node is idle until the other fails. Figure 12. Mobile Middleware Topology When a combination of application server and scale-out nodes are installed, any synchronization or asynchronous workflow traffic is routed from scale-out nodes to an application server node that hosts the native processes for synchronization and messaging, respectively. In this configuration, the system uses a clustered in-memory cache across application server and scale-out nodes to optimize the availability of device configuration settings. While session affinity is not necessary for REST or DCN, session affinity is required for non-persistent HTTP sessions involving synchronization or messaging. 26

27 SAP AG. All rights reserved. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. Business Objects is an SAP company. Sybase and Adaptive Server, ianywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Sybase Inc. Sybase is an SAP company. Crossgate, EDDY, B2B 360, and B2B 360 Services are registered trademarks of Crossgate AG in Germany and other countries. Crossgate is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty..