I'm sure I've detailed this requirement in the former Project Management tool, but it is presently offline so I can't tell. I do recall spending quite some time writing this (and other issues) up in that tool - but I can't find them here. I feel strongly enough about this issue to write this up while on leave ...
A key requirement @ Centrelink (as with ANY FIM Portal implementation) is the ability for Event Broker to differentiate between data vs. rule changes that have occurred in the FIM portal, and thereby ensure that the correct operation list is run as a result. Both rule and data changes are imported together into the same FIM MA connector space (there can only ever be one FIM MA), and different sync cycles are required depending on whether or not the imported changes included rule changes (essentially sync rules).
The easiest way to explain this is in terms of a FIM administrator attempting to manually execute run profiles involving multiple MAs, including the FIM MA. If running a delta import/delta sync on the FIM MA immediately after a rule has changed in the portal, the FIM administrator should not be surprised to see the sync service raise a warning when he attempts to run a subsequent delta import/delta sync on another MA, with words to the effect that rules have been changed since the last full sync cycle, and that a new full sync is required. When the Event Broker (or any other non-interactive process) executes run profiles under this scenario a warning is written to the Application Event Log but this does not prevent the run profile from subsequently being executed.
A variation on this scenario has always been around since MIIS/ILM days, but what is new here is that the FIM portal now introduces an additional (less obvious) way that the sync engine configuration can be changed by a FIM administrator type. It is anticipated that there will be certain types of changes that could occur in day-to-day FIM operations whereby a FIM sync server under the "governance" of Event Broker would be expected to handle this scenario without having to first shut down the Event Broker service and manually perform "re-baselining".
I won't go into any further detail on this now, but suffice to say it was an issue for us @ Centrelink, and Jeff Nelson (MCS) sees this as a key business driver in the ultimate purchase of Event Broker by Centrelink.
The way change detection has been implemented for the FIM Portal @ Centrelink is using the file changes plug-in with log files written by a FIM custom activity (as I demonstrated in a live meeting on the NAB site before christmas) and the way that "data changes" are differentiated from "rule changes" are that the custom activity is used to write to either a "data" or a "rule" file depending on the nature of the change that has been logged. The challenge then is for Event Broker to correctly interpret changes to either file ...
The present Event Broker design does not allow multiple incoming operation lists to be configured for the same MA, but this would have allowed me to meet the requirement together with the mutex capability recently added to the product.
As a work-around I was able to configure the INCOMING operation list for the FIM MA using the standard File Changes plug-in for the DATA log file, and this did little more than a delta import/delta sync on the FIM MA (followed by a commit file changes plugin call). I coupled this with a GLOBAL operation list on a similar schedule to the above delta (10 secs which is the default) which ran the File Changes plug-in on the RULE log file as the first step in the run profile. If this plug-in returned false it "jumps to a label" operation at the end of the operation list, but proceeds to run a full sync on each MA (with each operation on the same MUTEX thread name as those of the regular delta operation list) if it returns true.
The implications now on the equal precedence issue (written up by Nigel this week) now throw up concern that running a series of full syncs to re-baseline the FIM sync service in ANY WAY could lead to loss of MV data for attributes marked as equal precedence applicable. However, this does not take away from the fact that data and rule changes detected in the FIM portal need to be handled differently.
Customer support service by UserEcho