Generic Synchronization   |  Wrapper functions

 

What is a Data Container

Introduction

The granularity of data exchange between mobile device and MI server is the so-called data container.

In short, a data container is an MI-specific data format describing a fully parameterized function module call or its response data.

Data containers are created by the mobile device and are then sent to the server at synchronization time. They are either executed there immediately or stored for later processing by a batch job. The response data of the function module call is transported back to the device in another data container.

A data container consists of a header and a body:

Data container transportation cycle

  1. The mobile application fills a data container via the Generic Sync API (com.sap.ip.me.api.sync). It basically needs to furnish an alias for the function module to call, the processing type (synchronous or asynchronous) and the parameterization of the function module in the form of name value pairs. Only applications using Generic Synchronization create data containers by themselves. If applications rely on Smart Synchronization, the data containers are created automatically by the MI framework at synchronization time.
  2. Synchronization can be triggered by the end-user or by an application via com.sap.ip.me.api.sync.SyncManager. At this moment, either all data containers for a specific user or all data containers for all users are put into a file, the file is compressed dynamically and attached to an http(s) request that is sent to the gateway specified in the user settings. Applications can register themselves for notification at synchronization start. At the beginning of the synchronization, Smart Sync determines which changes happened since the last synchronization and creates the corresponding data containers. On receipt of the http request, the MI Sync servlet on the SAP J2EE Engine makes an RFC call (function module WAF_MW_SYNC) to the MI ABAP Server component via SAP JCo.
  3. MI ABAP Server Component checks for each data container, if it is to be processed synchronously or asynchronously. For synchronous data containers, the function module to call is determined (table BWAFMAPP) together with the RFC destination it resides in (table MEMAPPDEST) and then the call is executed. This will start the corresponding wrapper function.
    Asynchronous data containers are stored for later processing by a batch job (report WAF_MW_MAPPING). Data containers created by Smart Sync are automatically processed by the server-side of Smart Synchronization.
  4. The response data for synchronously executed data containers are added to the outbound queue. The outbound queue contains all data that is intended to be synched back to the device for all users.
  5. The part of the outbound queue for the current device is identified and posted back the same way (for example, from MI ABAP Server Component to MI Sync servlet as RFC response and from MI Sync servlet to MI Client Component as http(s) response. )
  6. On receipt of the data containers, the corresponding applications are informed of their receipt and their inbound processing methods are invoked. If an application uses Generic Sync, it needs to process the incoming data itself by a special class that was previously registered with MI. If an application uses Smart Sync, the MI framework automatically takes care of the data.
    At the end of synchronization, another event is triggered to registered applications.

The whole process can be thought of in analogy to a post-box: A mobile application writes a letter (for example, data container) and throws it into the post-box (for example, closes the container and thus adds it to MI's outbound queue on the mobile device). In so doing, responsibility of the letter is now with the Postal Service (for example, MI framework) and the letter (for example, data container) can no longer be changed (without burning the post-box... :-). Some time in the future, the post man arrives (for example, synchronization is started manually by the end-user), takes all the letters currently in the post-box (for example, the entire outbound queue) and the letters are transported. For the letters, their means of transport (like air, ship and so on) is not important. In the same way, MI transports the data containers via any TCP/IP connection (may it be established via GPRS, WLAN, LAN, cradle or other) or even with floppy disk download-upload. Eventually, the letter is delivered to the recipient (for example, MI opens the data container, determines the processing function module and its RFC destination and calls it) and the recipient can now do anything with that letter (for example, processing of the data container is entirely with the server-side of the application). The post man then takes all answer letters (for example, data container outbound queue on the server-side) and transports them back to the original sender, to whom they are delivered one by one (for example, inbound processing of the data container).