Synchronization Framework Overview

The Synchronization Framework defines the components that allow Kuwaiba to fetch data from the real network to keep itself up-to-date. The framework was designed so you can extend it to meet your needs. The following figure illustrates its general architecture:



Figure 1. Synchronization Framework architecture, using a supervised Synchronization Provider
  • Synchronization Provider: This component contains the logic that reads data from a device or third-party application, compares it with the information stored in Kuwaiba, finds the differences (a.k.a Findings) and executes a set of actions to update the inventory system, either automatically or supervised by a human. The Sync Provider implements low level protocols (like SNMP, WMI or SOAP) or reuse libraries to communicate with those devices/applications.
  • Synchronization Data Source: Any device or application a provider will retrieve data from, so the inventory information can be updated.
  • Synchronization Data Source Configuration: A Data Source Configuration is a set of parameters (IP addresses, user names, ports, passwords, column names, etc) that help the Synchronization Provider to reach the data source and read data from it. The parameters and their formats are defined and validated by the Sync Provider.
  • Synchronization Group: Contains a set of Data Source Configurations. The group has a unique sync provider associated to it, and all the configurations within it are going to be used as input to start a synchronization process.

The general workflow is as described in the Figure 1: The user (or an automated task) starts the synchronization process for a particular sync group. The sync provider associated to the group sequentially attempts to reach the devices/applications defined in the data source configurations within the group, fetches the relevant data and compares it with the current information in Kuwaiba. If the sync provider is supervised (that is, it waits for the user confirmation to take any action), the deltas are reported to the user as findings. An example of finding is: "I have found a new board in the device, should I create it in Kuwaiba, along with its ports?". The user may choose to perform the suggested action or skip it. The actions to be performed are compiled and sent back to the sync provider to be executed, and after their execution a list of results is sent to the user. If the sync provider is not supervised, the actions are executed and the result is logged or returned to whoever started the process without human intervention.

Findings and Results

  • Figure 2 shows a couple examples of how a finding would look like when displayed using the Kuwaiba client. On the left, a few changes were detected in the attributes of a Router object. On the right, a new phsyical interface was found:

    Figure 2. Examples of findings and actions in a supervised sync provider



  • Figure 3 shows an example of how a results report would look like:

    Figure 3. Example of a results report in a supervised sync provider

Further Steps

Feel free to use the project's mailing lists or forums to ask your questions! Also, if you're interested in developing your own Synchronization Providers, check the relevant javadoc sections (see com.neotropic.kuwaiba.sync package for details and examples).

ENTERPRISE SUPPORT

SALES

Send us email to contact@neotropic.co and we will gladly answer your questions or arrange a conference call or a business presentation to discuss further details about our commercial offer.

HEADQUARTERS

COLOMBIA

Popayán Cll 8 N°11-56