Generic Synchronization   |  Smart Synchronization

 

MI Synchronization - Overview

The goal of mobile applications is of course to update the backend with the data collected in the field. The key services offered by MI's synchronization mechanism are

This chapter looks at these functionalities on a very technical level and hence extends the general overview given in the introduction. The chapters Generic Synchronization and Smart Synchronization explain in detail the technology and API offered by the MI sync services.

Ensured, Encrypted, Compressed Data Transfer

Due to a sophisticated acknowledgement mechanism between MI Client Component and MI ABAP Server Component, MI can ensure that every data container is successfully delivered (irrespective of possibly line cuts during past synchronizations) and is executed exactly once.
The acknowledgement mechanism is based on individual acknowledgement information for data containers both on the server- and on the client-side. This means that both sides identify which data containers have already been sent over and for which of them the corresponding acknowledgement information (indicating successful delivery and processing) has been received yet. If no acknowledgement information was received, the data container is sent again. If the receiver already processed the container, but sending of the acknowledgement failed, the processing is not executed and the acknowledgement information is sent instead.

For data transfer between MI Client Component and MI J2EE Server Component an http or https request is used, where https is recommended for security reasons. The MI Client simply creates the http request object, adds all the data containers as its form parameters and sends the request to the MI Sync servlet residing on the SAP J2EE Engine. For https support, SSL needs to be activated on the SAP J2EE Engine.
MI uses the Sun Microsystems reference implementation for Java Secure Sockets Extension to support https. This is also the reason why MI Client Component does not support JDK 1.4.*, as the reference implementation does not run with this JDK.
Server certificates issued by SAP Trust Center are supported directly. For other certification authorities, a minor administration task needs to be done on the client device.

The data file containing all the data containers in ASCII format is compressed dynamically before being sent - both when sent from client to server and when sent from server to client. For compression, gzip is used with level 5.

Support of any connection type

At synchronization, MI creates an http request and sends it to the MI Sync servlet. The required TCP/IP connection is assumed to exist. If not, the synchronization fails and the user sees a corresponding synchronization error log. The TCP/IP needs to be created by the device (or its user) beforehand via any of the standard connection types like Wireless LAN, LAN, GSM , GPRS etc. With PocketPC2002, a device that resides in the cradle can also create a TCP/IP connection to the MI sync servlet, for example, use the PC's network connection to reach the remote server.
MI is not yet capable of automatically creating a network connection at sync time, if none exists.

Two synchronization modes

MI offers two synchronization methods to best fit the needs of both light-weight and complex mobile business applications:

Generic Synchronization allows to call any SAP function module residing in any SAP backend (and even non-SAP backend, if the SAP Business Connector is used). MI offers a client-side API that allows to parameterize the module and then release this request for synchronization, where it is is processed in the corresponding application backend. The response data of the module will be returned to the device and can then be processed by the mobile application.
Generic Sync allows to easily tie a mobile application to a backend and reuse the business process logic prevalent in the backend. It is therefor ideal for simple data collection scenarios (for example, warehouse inventory). On the other hand, the central limitation of the approach is that only the response data of the called module are transported back to the device. This implies that a) the device needs to actively pull the data from the backend and b) the function module needs to bring back the right data for the current user and state of the device. The responsibility for this lies with the function module and hence with the backend application developer. For data replication scenarios, where complex data handling is required, MI recommends to use Smart Synchronization.

Smart Synchronization is a full-blown data replication middle ware based on extracts of Business Objects (so called SyncBOs). These extracts can be assigned to users and user groups and Smart Sync takes care of transporting the corresponding data to the devices and offering them there to applications via an API. To optimize data replication, Smart Sync keeps track of the current state of each device in the field and guarantees that only the changes since the last synchronization are sent from server to client and vice-versa. This feature is also known as delta-determination. Smart Sync also cares for conflict situations between client and server, for example when the same object was edited on the server and on the client and then the client tries to send its data to the server. Smart Sync detects such conflicts and either resolves them automatically (by sending a corresponding error message and updated object information to the client) or offers applications to handle the conflict by themselves. Additionally, Smart Sync offers a workbench for designing SyncBOs and assigning them to users as well as monitoring tools to control the data flow between client and MI server as well as between MI server and application backend.
Smart Sync is completely independent of the CRM middle ware.

Multiple backend support

The MI server is itself based on SAP WebAS and plays a dispatching role in the landscape. It identifies which request is processed by which backend system and then calls the system via RFC. If several applications are running on the same device, they can therefore have different application backends and even the server-side of a single application can span over several backend systems. This concept is elicited in the MI architecture overview.

Generic Synchronization can call SAP systems of mySAP Technology release 4.5 or higher. For releases 4.5-4.6C the R/3 plug-in needs to be installed (PI 2001.1 or later release).
Smart Synchronization can replicated data from SAP systems of mySAP Technology release 3.1I or higher. No additional installations on the backends are necessary.
non-SAP systems can be integrated via the SAP Business Connector, which is basically just another RFC-destination that can be called by Generic Sync or Smart Sync. The MDK does not explain the necessary integration steps for this scenario. In the future, with the integration of SAP Exchange Infrastructure, non-SAP systems can also be addressed via SOAP.