Before I go on to discuss Incoming Change Detection, one of the lesser understood features I’ve been using recently is the ability to jump to a label in an OpList on evaluation of a condition.  Such an OpList might look something like this:

 

In the above example, whenever a pending export is detected for my "Northwind MOSS UPMA", in addition to running the standard Export operation, I’m conditionally running a full import/delta sync on the same MA.  The condition I am testing for is the presence of unconfirmed deletes in the ILM connector space (CS) of my MA, whereby the "SQL Changes Plugin" returns true if a result set is returned from my SQL query on the ILM database.  If the result is true, I proceed to execute the additional run profile operation, otherwise I bypass it with a "GOTO" label.  Sure it’s a bit passe to see the good old VB "on condition goto label" style construct again, but as far as the (necessarily) linear OpList model is concerned it actually makes perfect sense in this context.

 

Another example of where I have used this mechanism (only today actually) is to handle a special situation where I want to disconnect and reconnect a CS object.  In my case the disconnect needs to happen on a delta import/delta sync (incoming) when a certain attribute change has been made.  At this point I use a similar construct to detect the presence of the new disconnector after the first operation has completed, and run a delta sync if my (SQL) test returns true.

 

So here we have some basic flow control logic that can be implemented in any Event Broker OpList, so remember this feature the next time you want a variaton in behaviour based on a simple condition test – and any of the "Change Detection" plugins can be used here for this purpose.