0
Under review

Feature Request: Event Broker plug-in for Identity Broker Changes to defer TRUE result

Bob Bradley 7 months ago updated by Matthew Davis (Engineering Manager) 7 months ago 1

UNIFYNow has been observed to invoke operations as soon as UNIFYBroker changes are detected, rather than waiting until UNIFYBroker has completed generating changes.  In a bulk change scenario, this can result in small batches of changes being imported via a MIM run profile (for example), and in the case of changes that may breach a configured change threshold (e.g. UNIFYNow Safety Catch feature), it is possible that the catch won't be tripped because individual batches themselves fall below the threshold.  For example, when 1000 changes are made in HR, and the import threshold is 500, 4 batches of 250 identity import changes could still get through to MIM.

Instead of change detection returning TRUE as it currently does as SOON as there are changes present in the adapter, is there a way of holding these up (queueing them internally within UNIFYBroker) while reflection is still going on.  This way in the above example, change detection would return TRUE only after the 1000th change had been surfaced to the adapter.

There may be multiple ways of looking at this … for example, a result of BUSY could signal to UNIFYNow that changes have been detected but there could be MORE COMING.  Not sure which option would be best, nor the degree of configuration that may be required to throttle this.  Looking for the most elegant solution to achieve the desired result - and suspect this would be best isolated to within Broker rather than surfacing the decision to UNIFYNow.

+1
Under review

Hey Bob,

This is a tricky one. 

The issue with changes, is that changes generated in the adapter is not a 1:1 ratio with a connector import. You may have fields imported in the connector that don't map to adapter fields, and are simply used for calculated fields. You may also have more changes - one change in the connector might see 3 changes in the adapter (especially when doing joins). 

The other issue is that pending changes in the adapter don't always align with a single connector. If you've got an adapter with a multitude of joins on it, and you have constant changes coming from the joined connectors you're likely to have changes coming through the adapter consistently rather than bulk changes appearing.


The idea of Broker is that pages of changes can be processed and imported, otherwise you'd be potentially waiting all day for a state that there's no changes pending and that doesn't work with the industry we're in.

If you're confident you'll have gaps in Broker where all the changes are processed and nothing is pending, you could currently use a REST API or Powershell operation in UNIFYNow to query the adapter in Broker and only run the operation if no pending changes are there. 

I'm going to leave this ticket open for now, as it could do with some more thought and feedback. But for now there's no real immediate solution.