Select language:

Function documentation Smart Synchronization Mechanism 


The synchronization process for all applications based on Smart Synchronization has the following characteristics:

  Many of the elements in the synchronization components of Smart Synchronization are designed in such a way that they guarantee in-order message processing and one-time message delivery at all times. The message delivery guarantee is the responsibility of the synchronization layer.

  Every message from a device is controlled in Smart Synchronization with a status. The administrator can view each of the messages in different states.

  Smart Synchronization is a framework that is especially designed to provide the development tools and synchronization features required for offline applications. Smart Synchronization processes are, therefore, usually executed in asynchronous mode in the SAP MI Server Component.


Synchronous mode for synchronization is also available. The basic synchronization mechanisms are identical for both synchronous and asynchronous mode.

Technically, the same messaging protocol is used for both modes. The difference lies in the timing for expecting response from the server.

  In the SAP MI Client Component, there is no application-specific coding that directly interacts with the synchronization process. Application-specific coding is only necessary when dealing with local data using the MI Client APIs. For application data that is stored locally in the persistence layer, the underlying components of the MI Client APIs keep the device data synchronized with the back-end.

Error and conflict handling are exceptions. To handle synchronization errors using application-specific logics, Smart Synchronization offers features to access details error and conflict information.


Steps in Smart Synchronization

Smart Synchronization is designed to enable offline application programming and provide a generic synchronization infrastructure for such an application. This framework is built under the assumption that a stable and inexpensive connection between the client and the server may not be available in the productive environment. It allows the applications to synchronize data between the back-end system and the mobile devices in either synchronous mode or asynchronous mode.

To enable both synchronization modes, the synchronization mechanism is technically divided into two separate blocks. In synchronous mode, both processing blocks are executed within one connection from the mobile device. In asynchronous mode, only the first processing block is executed while the connection from the device is retained.


In asynchronous mode, response messages for synchronization requests from the mobile device return to the device only when the device connects again after asynchronous execution on the SAP MI Server Component has finished.

In synchronous mode, however, synchronization requests are executed while the device is waiting online and the response is immediately returned to the client device.

With synchronous mode, the system behavior is generally easier for device users to understand. However, the connection time can become critical for financial as well as system connection stability reasons if message execution takes too long.


  Transfer of data packages between the mobile device and the SAP MI Server Component (device synchronization)

In this processing block, the request messages are first transferred from the mobile device to the SAP MI Server Component before being stored in the Smart Synchronization inbox. In the same step, data packages that collected for requests from the same mobile device are retrieved from the MI outbox to be sent to the device.


The request messages from a mobile device in one synchronization cycle include:

  Upload messages for all the objects created, modified, or deleted on the device since the last synchronization.

  Download request messages for all the SyncBOs included in the mobile application on the device.

On the client, you can deactivate the sending of download requests if it is inappropriate to send them in every synchronization cycle. For applications, this option is available through the API. Alternatively, the user can suppress the download by making the appropriate setting in the user interface of the SAP MI Client component.

The download messages to the mobile device in one synchronization cycle include:

·  Response messages for upload messages from the same client (processing results and data).

·  Response messages for download request messages from the same device (processing results and delta data).


Alternatively, requests can be triggered by the Client Data Distributor (report MEREP_DISTRIBUTOR). The report creates requests for defined devices, groups, or users without a trigger from the client. The delta determination algorithms are the same as those for synchronization triggered from the client.

  Execution of device request messages in the Smart Sync inbox (server-side synchronization)

In this processing block the following steps are executed for each device message:

  Detect delta data and store it for downloading to the device (downloader)

  Perform a data update to the back-end system. Data is uploaded from the device (uploader).

The synchronization type and message contents determine which of the above two are executed and how they are executed.

The delta data detection process detects the differences between the local database on the device and the respective data in the back-end system.

The following records are considered to be delta data on the server side, and are detected as the target records to be sent to a mobile device:

  A data record that already exists on a device and was modified/deleted in the back-end system.

  A data record that does not yet exist on a device and was created in the back-end system.

In both cases, only the data that is relevant for the requesting mobile device is taken into account. This means that even if the data records in the back-end system are modified, the changes are not detected as delta data if the filter settings specify that the data is not relevant for the specific device.


The changes in the back-end system include those changes that were made by the other mobile devices.


A SyncBO data model is normally a subset of business data in the back-end system. For delta determination, only data fields mapped in the SyncBO are taken into account.

Executed Processes by Synchronization Type

Synchronization Type



Replication from Back-End

Upload (U01)

Not executed


Not executed

Timed 2-Way (T01)

Executed. Base data for delta detection is replication database.

Executed if message contains upload data

Triggered by scheduled job

Backend-Driven (T51)

Executed. Base data for delta detection is replication database.

Executed if message contains upload data

Triggered by the back-end system

2-Way (S01)

Executed. Base data for delta detection is the back-end system.

Executed if message contains upload data

Triggered by the device


To create a SyncBO that only downloads data, use one of the types Timed 2-Way (T01), Backend-Driven (T51) or 2-Way (S01), and only specify the GetList BAPI wrapper and (optionally) the GetDetail BAPI wrapper.

Data replication from the back-end system to the SAP MI Server Component (replication database)

Depending on the SyncBO type, delta data is detected differently.

For SyncBOs of the types Timed 2-Way and Back-End-Driven, the system compares the replication database with the local data on the mobile device. This implies that the replication database must be updated at regular intervals in a separate process to synchronize the devices with high accuracy.

  For Timed 2-Way SyncBOs, the replicator is executed to synchronize between the back-end system and the replication database, normally with a scheduled background job.

  For Back-End-Driven SyncBOs, the back-end system sends every delta data record directly to the replication database whenever the application data changes in the back-end system. This minimizes data traffic between back-end system and SAP MI Server Component, and the overall replication process.


For SyncBOs of type 2-Way, the back-end system is referenced.


The synchronization modes are independent of the synchronization type. Also 2-Way SyncBOs can be processed in synchronous mode. The synchronization mode is normally determined by the client application.

This graphic is explained in the accompanying text

Support for multiple languages

It is possible to provide data in multiple languages, so the user s can work with data in their language:

  For SyncBOs of type 2-Way multiple language data can be handled without further settings, as the data is obtained directly from the back end. The replication database only holds the relevant data for device and user in the chosen language.

  For SyncBOs of type Timed 2-Way and Back-End Driven configured accordingly, the replication database holds data in multiple languages. Before the data is transferred to the device, the data is converted and only data in the language of the mobile device will be transferred to the device. In no language is defines, the default language will be used without converting the data.


Basic rules for messaging and synchronization, with their responsible components

  Delivery guarantee

It is guaranteed that all the messages transmitted between the SAP MI Server Component and the SAP MI Client Component are delivered to the target. The protocol between the SAP MI Client Component and the SAP MI Server Component assures that all messages without exception are re-sent until the complete arrival on the other side is confirmed.

  In-order processing

The handler ensures that all the messages sent from the SAP MI Client Component to the SAP MI Server Component are processed in the correct sequence. The correct sequence is the sequence in which the messages were sent from the mobile device. The SAP MI Client Component determines the message sequence, strictly following the order of user actions on the local data.

  One-time execution

In an offline messaging environment, especially for business transactions, it is important that a transmitted message is processed only once at the other end. For example, a device transmits a message to the SAP MI Server Component to create a sales order. If the SAP MI Server Component executes this message more than once, multiple entries are created in the back-end system.

If processing a message results, for example, in an application error, the message can be processed again, but this second execution is to be triggered by a responsible person, normally the administrator, using the Monitor tool.

  All-or-nothing concept in object updates (BAPI / BAPI Wrapper)

All BAPIs follow a basic rule called the All-or-nothing concept. The methods for updating a business object execute the update either completely or not at all. For example, a method is called to update a sales order with two order items. Unless the header and both of the items can be updated without an error, nothing is updated. If an error occurs, a message with an error type is returned to the caller, which in Smart Synchronization is the synchronizer.


SAP standard BAPIs never include the Commit Work or Rollback Work statements. This enables external calling programs to explicitly issue Commit Work or Rollback Work statements, depending on the results from the BAPI method calls. However, Smart Synchronization expects the BAPI wrappers to include the Commit Work or Rollback Work statements.

Message status flow

In Smart Synchronization processes, messages from and to a mobile device have various statuses. For example, a message received by the server first has the status Waiting, and eventually has the status Finished after processing. The following table shows the different statuses and respective descriptions, as well as some remarks.


Technically, these statuses are kept in the Smart Synchronization worklist items, which are equivalent to a message header for each message from and to a mobile device.

Description of Status



I-Waiting (W)

Synchronization messages are received and stored in the Smart Synchronization inbox; a worklist item is created for each synchronization message, and a handler is triggered for the respective device.

I-Partially Processed (P)

Worklist item is being processed by the synchronizer.

I-Finished (F)

Inbound processing is completed.

This graphic is explained in the accompanying text

The I-Finished status includes those upload messages that resulted in a Conflict status.

Whether a message has resulted in conflict or not can be identified by referring to the subordinate Synchronizer worklist of the Handler worklist.

I-Error (E)

Error encountered during inbound processing. It can be an application error or synchronization error.

I-Ignore (I)

Worklist item is marked as complete and ignored.

This graphic is explained in the accompanying text

Worklist items whose status is I-Error or I-Waiting can be manually changed to I-Ignore status.


Synchronization messages are created as result of the report MEREP_DISTRIBUTOR.


Synchronization messages created by MEREP_DISTRIBUTOR are being processed.


Processing is completed. The synchronization messages are ready to be transferred to the client upon the next synchronization.


Error encountered during processing. It can be an application error or synchronization error.


The synchronization message created by MEREP_DISTRIBUTOR is marked as complete and ignored.

O-Waiting (W)

Synchronization messages are created in response to inbound messages (worklist item(s)) and stored in the Smart Synchronization outbox.

O-Sent (S)

Synchronization messages are converted into MI containers for each request from the device.

This graphic is explained in the accompanying text

When the status of an outbound message is O-Sent, the data has been downloaded successfully. Updates on the client may have failed for technical or application reasons, but the system has confirmed the message has arrived on the client device.

O-Error (E)

Error encountered during outbound processing.


Message Transformation

Messages are transformed between the mobile devices and the SAP MI Server Component during synchronization.

Different Message Formats in the Respective Stages




Device local store

Raw data (serialized file, local database, and so on)


Smart Sync message


Client uses XML data both when sending data to the SAP MI Server Component and receiving data from the server.

MI container

<Field> <Field Value> pair

The Smart Synchronization message is packed into the MI container when it is transmitted over the network between the SAP MI Client Component and the SAP MI Server Component.

Smart Synchronization inbox

XML + worklist item

When a Smart Sync message is received from a device, the XML data is read from the ME container as a string and stored in the Smart Synchronization inbox.

At the same time, a worklist item that is equivalent to a message header is generated and stored in the SAP MI Server Component.

Smart Synchronization outbox

XML + worklist item

Messages from Smart Synchronization are stored in the Smart Synchronization outbox in XML format. The XML data is stored with the metadata with a SyncBO.


Was this page helpful to you?