Today the subject came up as to what is generally required of an API that is being developed to support an ILM ECMA with delta import requirements to also support the creation of a corresponding Event Broker "changes" plug-in (using the Event Broker SDK).  This is a requirement which I have already had to meet with many times myself with my own ECMAs (or xMAs), and it turns out to be quite simple.

 

The SDK provides an Event Broker developer with the interface definition required to build a new changes plugin for any given MA source.  In the case where an API is being created specifically to support the writing of an ECMA (using the ILM SDK), it makes sense to take the extra step to ensure that the API also supports the Event Broker SDK.  Generally this comes down to a requirement for a single API method, namely "Get Latest Change Token".  If the API supports delta imports, generally this means that it does so because the concept of a change token has been employed in some way (e.g. datetime, timestamp or unique counter).  In fact the ILM ECMA developer has the harder task – the generation of a delta image for ILM – wheras the Event Broker developer just needs to know if there is a delta image at all.

 

This obviously presumes such a concept exists in the source – where it doesn’t you can’t generally use Event Broker to enable event-driven delta imports without another piece of UNIFY technology, namely Identity Broker.  But that’s another story …