Generic Synchronization | Wrapper functions
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:
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. 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.BWAFMAPP
) together
with the RFC destination it resides in (table MEMAPPDEST
) and
then the call is executed. This will start the corresponding wrapper
function. WAF_MW_MAPPING
). Data containers created by Smart Sync
are automatically processed by the server-side of Smart Synchronization.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).