Synchronization Server Overview

The Synchronization Server implements the publishing of event messages for LN. This is done by creating a synchronization object for a business object. A synchronization object is the selection of a business object, extended with selection of components and attributes and (optionally) a filter. The synchronization object enables the synchronization at runtime for the selected business object.

Synchronization Server Functions

If LN must be synchronized with another application, the data source at the LN side is actually a set of table fields. However the LN tables are not directly accessible. LN tables can be accessed through business objects. To read the fields in a table, you must call a method of a business object. This method handles the attributes of the business objects. The attributes of the business object are mapped to table fields, but formatting or calculation may be involved.

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.

Relationship between Publishing Methods and Synchronization Server

Technically, a PublishChanges request is translated into a synchronization object in the Synchronization Server. This means that usually, you do not have to set up a synchronization object manually. However, you can use the Synchronization Server user interface to fine-tune the settings for a synchronization object.

If a PublishChanges request arrives for an already existing synchronization object, the existing settings (selection and filter) are updated.

If an UnpublishChanges request arrives, the corresponding synchronization object is deleted.

More information

For more information, see:

  • Synchronization Server - User Interface Overview
  • Synchronization Server - User Tasks
  • Event Publishing Overview
  • Synchronization and Event Publishing Deployment Guide This deployment guide describes among other things:
    • The specifications for the PublishList, PublishChanges and UnpublishChanges methods.
    • How to use these methods.
    • How to use the Synchronization Server to set up, optimize and manage the event publishing.
    • Important things to take into account when setting up the synchronization or event handling.
    • What to do in case of problems.