Syncs are configured and scheduled using a Wizard interface which offers immediate access to three common directory to directory sync profiles, four common LDIF transformations as well as access to an Advanced Wizard view giving fine-grain control of the synchronization process.


New syncs are configured via a wizard which offers immediate access to a number of synchronization options:

  • 3 common directory to directory syncs.
  • 4 common LDIF transformations.
  • Go straight to Advanced view
  • Group syncs into a directory replication workflow.

Some of these sync options will lead to a Simplified view of the Sync Wizard, consisting of Source & Target and Scheduling tabs. Others will go directly to an Advanced view which has additional tabs, as shown in the following screenshot.

The front profile screen gives a workflow diagram of the core functions, the diagram will adapt as different options are chosen in the tabs which define options, including those described below.


A sync can be configured to operate in a number of different modes:

  • Source Only: This sync operates without a target, the primary use of this mode if for checking data.
  • Complete Scan: The standard mode of operation used for directory to directory syncs. Source and target (which can be independently configured as directory, LDIF, CSV or SQL) are compared and changes applied to the target.
  • Cached Scan: This varient uses a cached copy of the target directory, which the sync will update. This has the advantage of removing the need to read data from the target, which reduces network overhead. This mode is essential for sync over email and related modes where it is not possible to read data from the target directory.
  • Recreate: Where a standard sync will calculate changes and apply only necessary changes to the target, this mode will delete the target and fully load each time.
  • LDIF: This mode takes a change LDIF (an LDIF representing a set of changes to be applied to a directory) as input.
  • Queues: This mode takes as input a sequence of LDIF file and is designed to support sync by email and related modes

Source and Target

Source and target tabs control where data is coming from and where it is going to. Where to source or target is a directory server, the server is referenced by a bind profile that is configured to connect to that directory at the point of the DIT (directory information tree) used. For the source, options exist to handle aliases either as a mechanical copy or be de-reference (so that the target gets the data from the entry that is pointed to by the alias).


A number of checks can be configured including a referential integrity check, constraint on update size and a check that a given attribute is unique. Attribute syntax checks can also be configured by defining custom XML.


The Output tab gives a number of options for the final step of the sync:

  • Discard changes
  • Apply changes to the target (this is the standard approach).
  • Apply changes to another directory.
  • Generate a change LDIF file.
  • Generate a change LDIF file for a queue, this is in support of synchronizations by email.
  • For a source-only scan, the set of output options is LDIF, CSV and writing to a different area of the source directory.


The final tab, Trace, gives a number of trace, logging and debug options.

Sync Scheduling

Sodium Sync enables independent scheduling of multiple syncs. Regular syncs can be scheduled daily, hourly or on specified days of the week or month. Syncs can also be specified with an interval so that a sync will start a configurable time after the previous sync has finished.

When unscheduled tasks are run from the Sodium GUI, status and errors are shown interactively. Sodium Sync Manager (below) can be run at any time to check on the status of synchronizations.

When there are problems this screen can be used as an entry point for diagnosing problems and accessing error logs. Any errors are also logged as Isode events. These events can be monitored using any of the approaches available as part of the Isode event system.


Simple syncs occur as independent events but more complex scenarios exist where it makes sense for syncs to have relationships to each other and to external events, for example:

  1. To sync data inwards from an external source before sending a sync outwards to multiple targets.
  2. Running a database report generation program to generate a file, prior to loading via a sync.
  3. Load in data, check its validity, and publish automatically via another sync if the checks succeed. It the checks fail, publication will not happen. This will ensure operator checking, and that the published data has always been checked.

Grouped Syncs

This type of capability is referred to as 'Directory Replication Workflow'. The first feature to support this is Group Syncs. A sequence of syncs and checks can be grouped together, so that they are run in order and subsequent syncs will only run if the previous ones succeed.  This can help with situations where data is brought in from multiple sources and then sent onwards. It can also bring in remote data, perform processes, and then only transmit onwards if a series of checks succeed.

This enables the definition of a new group and defines error handling proceedures. Groups are shown on the management screen and syncs in a group can be run independently or as a group. Commands can be specified to run before and after a sync, allowing external processes to be integrated with the directory replication workflow.