Synchronization Server Overview

The Synchronization Server takes care of:

• Event detection
  Changes in the underlying back-end components of the business objects are detected. If a change is applied to a certain column in a table and that column is mapped to an attribute of a business object, from which a client wishes to see changes pushed, the Synchronization Server detects that the change has happened. In LN the changes are detected through audit functionality.
• Event filtering
  Create, change or delete events are filtered based on values of attributes, such as is possible in the List and Show. Create and delete events are either passed on or skipped. But in case of change events it is additionally possible that the event is passed on but altered. If the original values of the attributes (before the change) meet the filter, but the current values (after the change) do not, the event is passed on as a delete event instead of a change event. Similarly, if the original values of the attributes (before the change) do not meet the filter, but the current values (after the change) do, the event is passed on as a create event.
• Event aggregation
  A change event at database level (table column) is converted into a change event for a business object (component attribute). By default changes in attributes will be aggregated towards pushing out all relevant surrounded component data. So even if one attribute is changed it will push out the contents of the other attributes inside the same component as well. In addition to adding attributes for the changed component(s), the aggregation process also adds parent components with at its attributes. This default behavior can be changed, by specifying at configuration time that only certain attributes need to be pushed instead of all data of the entire component involved, or by specifying that also data from other unchanged child components must be included. For example: A change of a quantity in a sales order lines table, will be transformed into an XML document containing the sales order object consisting of the (unchanged) header and the changed order line.
• Event publishing
  The XML document that describes the change event is pushed out to an external component that is responsible for handling the event in a correct way. This component is responsible for feeding the data further into a broker product, or saving it in a file on the file system, or simply feeding it into a message queue, for example. The destination is specified via a so-called bus component, which actually refers to the listening party that must receive the event messages.