Generic Synchronization | Smart Synchronization
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.
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.
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.
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.
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.