Data Containers | Wrapper functions | Generic Sync Example
The Generic Sync API lets you create and process data containers as well as get information about the synchronization process - that means registering for events during synchronization or read the synchronization log. Synchronization settings are stored in the MI configuration.
In this chapter, we'll cover each of these aspects of the API separately:
For an example of the Generic Sync API, consult the Generic Sync example.
The Generic Sync API reflects very closely the data container processing cycle:
OutboundContainer yourOutboundContainer = OutboundContainerFactory.getInstance().create…There are several create methods to get your OutboundContainer. The method has got different parameters. One of these is a VisibilityType. This parameter is responsible for the visibility of your data container. One value is VisibilityType.SEPARATED. With this parameter the data is completely separated per user and application. The other value is VisibilityType.USER_SHARED. With this parameter the data is separated per application but shared between all users on this device.
SyncManager.getInstance().synchronizeWithBackend(VisibilityType.USER_SHARED);It is also possible to synchronize via disk instead of via http. In that case, the entire sync queue is saved on disk. The disk content can later be uploaded to the WebAS via the Web Console.
java.io.Serializable
.
Example for an InboundProcessor class:public class MyInboundProcessor implements InboundProcessor, Serializable { private String methodName = "MDK_USER_INFO_READ"; public String getMethodName(){ return this.methodName; } public void process(InboundContainer inboundContainer){ // This method implements what to do with incoming container. This method is called by the inbound processor whenever a container // is found that is registered for this inbound processor. } } Hint: "MDK_USER_INFO_READ" is the name of the backend method.
If the framework identifies that a data container is processed by a given InboundProcessor, it calls its process method and passes the InboundContainer to the InboundProcessor. The InboundProcessor can then access all header data (status, method, owner, send date, etc.) or read all InboundContainerElements. For each InboundContainerElement it can request field name and field value. Typically an application would store this information for later via the Persistence API.
During the synchronization process, the framework fires SyncEvents that applications can register for. This gives the applications control over the synchronization process. Typical applications for the SyncEvents are for example, adding outbound data containers before the synchronization starts or do some cleanup work at the end of synchronization. To register for SyncEvents, an application class implementing the SyncEventListener interface needs to call the SyncEventRegistry.
The synchronization process is logged extensively by the framework. This log can be accessed by applications via the class SyncLog.
The Synchronization settings for user, language, web gateway etc. govern the synchronization process. They are maintained manually by the user in the My settings dialog. You can read and write these settings via the corresponding properties in the Configuration API.