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.
Customer support service by UserEcho