Search Server Synchronization

Because the Generic Search Server searches not on the live data itself but on an Index that is built from that data, updates to application data need to be replicated on the Index. In Cúram implementations, it is essential that updates to searchable data be reflected in the relevant Indices in a timely and predictable fashion. With the Generic Search Server, the time lag is short (and configurable).

Figure 1. Data Synchronization

Similar to the initial import of data described above, there are two steps to the synchronization process.

The first step in the process occurs when the application data (which is used in an Index) changes, typically as a result of an insert, update or logical delete. When this occurs, the application must write information about this data change to the Generic Search Server staging tables. All new and updated items are marked with a timestamp.

In the second step (which happens on a periodic basis), the Generic Search Server synchronizes its Indices against the current contents of the staging database. To do this, it reads all newly changed items since the last time it synchronized, and imports these into the Indices; specifically, this is achieved by comparing timestamps associated with each changed item to the latest timestamp used during the last synchronization step.

Note: When writing unit tests that include calls to Generic Search Server searches, it is important to bear in mind the delay in synchronizing data. In addition, as a result of the fact that the Generic Search Server instance will be running in a separate process to the unit tests, it will not be part of the same transaction. Consequently, Generic Search Server synchronizations will not pick up any data that has changed in the test transaction, unless it is explicitly committed.