5.8 Immediate Synchronization
The previous sections describe how a typical catch-up synchronization pass unfolds. But SData also supports an “immediate” mode for synchronization, in which the changes are pushed in quasi real-time from a source application to one or more targets (see Immediate and Catch-up Synchronization section).
The process is similar to the process used for catch-up when the engine is on the source side (see section on Architecture Variants), but it is a bit simpler. In this case, the source does not query the target digest. Instead, the source sends a synchronization directly to the target.
For example, if the source is sageApp1 and if only one account has been changed in sageApp1, the synchronization feed will look like:
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:sdata="http://schemas.sage.com/sdata/2008/1">
<title>Account immediate synchronization</title>
<id>http://www.example.com/sdata/myApp1/myContract/-/accounts/$syncSource('3EE479B9-05E8-4f35-8115-E205446667B6')</id>
<updated>2008-03-31T13:46:45Z</updated>
<syncMode xmlns="http://schemas.sage.com/sdata/sync/2008/1">immediate</syncMode>
<digest xmlns="http://schemas.sage.com/sdata/sync/2008/1">
<digestEntry>
<endpoint>http://www.example.com/sdata/myApp1/myContract/-/accounts</endpoint>
<tick>7</tick>
<stamp>2008-10-30T19:07:56Z</stamp>
<conflictPriority>1</conflictPriority>
</digestEntry>
<digestEntry>
<endpoint>http://www.example.com/sdata/myApp2/myContract/-/accounts</endpoint>
<tick>10</tick>
<stamp>2008-10-30T12:16:51Z</stamp>
<conflictPriority>2</conflictPriority>
</digestEntry>
<digestEntry>
<endpoint>http://www.example.com/sdata/sageApp3/test/-/accounts</endpoint>
<tick>15</tick>
<stamp>2008-10-30T17:40:11Z</stamp>
<conflictPriority>3</conflictPriority>
</digestEntry>
</digest>
<entry>
<id>http://www.example.com/sdata/myApp1/myContract/-/accounts('23552')</id>
<title>Account Chemical Bros</title>
<updated>2008-05-25T13:27:19.207Z</updated>
<content>Account Chemical Bros</content>
<syncState xmlns="http://schemas.sage.com/sdata/sync/2008/1">
<endpoint>http://www.example.com/sdata/myApp1/myContract/-/accounts</endpoint>
<tick>6</tick>
<stamp>2008-10-30T18:13:39Z</stamp>
</syncState>
<payload sdata:uuid="C4411795-9943-4cf4-8705-51A74C9F0ACC" xmlns="http://schemas.sage.com/sdata/2008/1">
<account xmlns="http://schemas.sage.com/myContract">
<name>Chemical Brothers Inc.</name>
<!-- more account data -->
</account>
</payload>
</entry>
</feed>
The account resource was changed while sageApp1’s tick was 6. This is reflected in its <syncState> element.
The digest is the source digest after the change (endpoint sageApp1, tick 7, other endpoints are included).
The source application propagates this change to one or more endpoints, with POST request(s) like the following:
POST /sdata/myApp2/myContract/-/accounts/$syncTarget?runName=Full%20CRM%20to%20ERP&runStamp=2009-10-14T08:51:02 HTTP/1.1 Content-Type: application/atom+xml; type=feed <!-- Above feed -->
The target endpoint processes the resource changes.
if a large number of resources have been modified together the source can send several pages of changes.
The target endpoint MUST verify that the tick values contained in the entries are contiguous with the tick values of the target digest. If there is a gap between the target tick value and the tick value of a feed entry, the target endpoint MUST refuse the request and send a 400 BadRequest response.
After processing every entry, the target should update its digest by applying the rule described earlier (first table of the Updating Target Digest section).
On the other hand, the target should not perform the additional check described in the Updating Target Digest section, at the end of feed (second table).
In the example above, there is only one entry in the feed and the target digest will be updated as follows:
| Digest | sageApp1 | sageApp2 | sageApp3 |
|---|---|---|---|
| target before | 6 | 11 | 10 |
| feed entry | 6 | ||
| target after | 7 | 11 | 10 |
Before this immediate sync operation, the target was in sync with sageApp1 at tick 6. Now, it is in sync with sageApp1 at tick 7.
In this example, the source has a higher tick than the target for sageApp3 (15 > 10). A likely cause is that the source was recently synchronized with sageApp3 and did not yet propagate the sageApp3 changes to the target. This will not lead to an inconsistency because these changes will be picked up by the next catch up synchronization pass from source to target. But this demonstrates that immediate syncs are just a "best effort" to keep endpoints in sync and that catch up passes may be necessary if the topology is complex or if immedidate sync requests are not guaranteed to reach their targets.
The <syncMode> element is set to immediate to indicate that this feed corresponds to an immediate synchronization.
The target endpoint MUST verify that the tick values contained in the entries are contiguous with the tick values of the target digest. If there is a gap between the target tick value and the tick value of a feed entry, the target endpoint MUST refuse the request and send a 400 BadRequest response.