Tracked as SYNCOPE-1617.

General idea

Syncope supports since its beginning the concepts of propagating to, pushing to and pulling from External Resources, as implementations of the general provisioning features; in particular, different pull modes are supported, all of them based on the assumption that provisioning is always triggered by Syncope itself.

What is currently missing is support for livesync, e.g. the ability to pull entities upon receving notification that there is something available to pull.

Implementation

At implementation level, Syncope will allow to define a new Entity named LiveSync with the following characteristics:

1. define some kind of listener to a queue instance, supposed not to be provided by Syncope but available by infrastructure, where:
   1. listener can be implemented by a set of supported technologies to choose from
   2. message payload, published by a set of supported providers, is translated into ConnId's SyncDelta, already used by Pull
2. define mapping information as External Resources do
3. define trace levels and other supporting configuration, again similarly to External Resources

Overall, when a new message is published into a subscribed queue for which a LiveSync instance is defined, Syncope will:

1. translate the message payload into an equivalent SyncDelta instance
2. trigger the execution of SinglePullJobDelegate for the given SyncDelta instance, processed on the basis of the defined mapping

Listeners

A good starting point would be to support at least Apache Kafka.

Providers

• Debezium which supports RDBMS, MongoDB and Cassandra
• OpenLDAP Sync Replication
  In this case we will also need to implement a component which will be part of the syncrepl architecture, publishing messages onto the provided queue instance