Data Change Notification Data Flow

Replication-based synchronization (RBS) data flow for regular DCN differs slightly from message-based synchronization (MBS).

RBS DCN data flow:

Data change notification dataflow

Steps one through four describe DCN, while steps five through eight provide an example of how the change itself is synchronized with the client using targeted change notification (TCN), previously called server-initiated synchronization (SIS), with an RBS client using synchronization parameters.

  1. EIS update – a program or some other process updates data in the EIS which is associated with a DCN.
  2. HTTP(S) push – the EIS pushes a DCN message with new or changed MBO data contained in the message on the configured HTTP(S) port.
  3. DCN operation – the DCN service receives the message and performs the upsert/update to the CDB tables of the corresponding MBOs. DCN upsert/delete operations also set the changed flag of an MBO package to true.
  4. Unwired Server response – Unwired Server sends a response message back to the EIS that contains the status of each DCN in the submitted message.
  5. Change detection – for a particular device that needs the new data, Unwired Server generates a message for the client indicating that it should synchronize.
  6. Change notification – the message is pushed from Unwired Server to the device.
    The flow assumes that the device is registered for notifications and comes online to receive the notification:
    • If the device is online (as viewed in Sybase Control Center, Application Connections), then the notification message is immediately delivered to the device through the MBS channel and the application handles the notification accordingly (the developer must code for this scenario).
    • If the device is offline, then the notification is queued and the "Pending Count" for that application connection increases and can be observed to be non-zero in the same Sybase Control Center screen (Application Connections). Optionally, for iOS, APNS can be configured to provide notification to the device/application which ultimately results in the user launching the application, causing it to reconnect to Unwired Server to retrieve the notification.
    See Subscribing Applications to Push Synchronization Notifications in Mobile Application Life Cycle and Push Synchronization Applications in Developer Guide: <Device Platform> Object API Applications for additional information about notifications.
  7. RBS synchronization – the client receives the message and issues a synchronization request to Unwired Server.
  8. Synchronization – Unwired Server retrieves the new/updated data based on the client synchronization parameter and returns it to the client.

MBS DCN data flow:

Data change notification dataflow
  1. EIS update – a program or some other process updates data in the EIS which is associated with a DCN.
  2. HTTP(S) push – the EIS pushes a DCN message with new or changed MBO data contained in the message on the configured HTTP(S) port.
  3. DCN operation – (with payload) the DCN service receives the message and performs the upsert/update operation to the CDB tables of the corresponding MBOs. DCN upsert/delete operations also set the changed flag of an MBO package to true.
  4. Unwired Server response – Unwired Server sends a response message back to the EIS that contains the status of each DCN in the submitted message.
  5. Change detection/synchronization triggered – for a particular device that needs the new data, Unwired Server generates a message for the client indicating that it should synchronize. This is essentially the same as step 6 above in terms of online versus offline, with the difference being the data is also pushed on the same channel and not synchronized on the separate RBS channel.
  6. MBS push – the MBS message is pushed from Unwired Server to the device.

    When the client receives this message, it performs the corresponding create, update, or delete operation on the device's mobile database.

Parent topic: Data Change Notification