There are basically two key concepts which make Event Broker the ideal "orchestrator" for any ILM/MIIS solution – its ability to invoke "inbound" flows (import/sync – ideally deltas) on detecting changes in a connected directory (CD), and to invoke "outgoing" or "outbound" flows (export) on detection of changes (pending exports) within an ILM management agent (MA).  I’ll talk about the most obvious of the two (to me at least) to start with – Outgoing.

 

One of the features that was shelved for ILM2 was the concept of automatically triggering export run profiles whenever pending exports were present.  The reason that I was given as to why this didn’t make it into ILM2 was that this wasn’t as high a priority as the other features new to ILM, and was more of a "nice to have".

 

I’ve had always thought that this would have been almost a "no brainer" – but thinking about it some more, ILM would probably need to have an additional service in the mix to fire the exports, and if it’s going to have that, it might as well have the ability to handle pre and post processing (as per the concept used within the MIIS toolkit "sequencer" component).  Then there might be a need to handle conditional flows – e.g. if this condition, do something, else do something else.

 

Well while we wait for ILM3 to come along, rest assured that in the meantime you can do all of the above with Event Broker right now.

 

 

The simplest case is to set up an automatically fired export run profile for say an Active Directory MA – in my case my MA is called "Northwind AD MA" – as follows:

 

 

With all Event Broker operation configurations, the model is always to work with a list of operations (or an "Oplist").  In the above case the MA has an "Outgoing" Oplist with the "Autorun on Outgoing Provisioning Pending" checkbox is ON (the default for Outgoing).  When the Oplist was first created it was empty, and the only action required to achieve the desired outcome was to add a run profile operation via a dialog box as follows:

Clicking "Run Profile" raises a second dialog box which allows you to select any of the configured run profiles for the MA in context (in this case Northwind AD MA).

Note that there is nothing to prevent you from selecting from any MA, and any of its run profiles – however, the desired configuration requires only the selection of "Export" from the above list.

 

 

It is possible to build on the above example by adding additional steps to the Oplist.  One such example is to set up what we ILM folk know as a "confirming (delta) import".  Now it’s true that if you have an Incoming Oplist configured for all delta imports that such a configuration is most likely doubling up.  However there are some examples where it is best to fire the confirming delta import/sync run profile immediately after the export.  In the case below, there is a need to handle an exported DELETE as a special case …

 

 

In the above I have followed on from a (successful) Export step with the execution of a special "SQL Changes Plugin", whereby the selected operation was not "Run Profile" as before, but "Plugin" – from which the SQL plugin was selected from a list of available plugins which will be discussed at a later stage.  Each operation in an Oplist has a common set of "General Properties", including an action to take based on the result of the operation (in this case the returned boolean value from the plugin).  The SQL plugin has been used to chack the ILM MA connector space for the presence of unconfirmed exported deletions, returning TRUE if these are found, otherwise FALSE.  In this case the requirement is to run a Full Import / Delta Sync run profile after every delete, otherwise do nothing (and wait for the Incoming Oplist to fire the delta import/delta sync).  This is achieved by setting up a "Label" (the third and final category of operation selected from the dialog), and using the following General Properties settings to ensure that processing bypasses the Full Import / Delta Sync if there are no deletions detected:

 

 

That’s enough on Outgoing for now … there’s a lot to cover, but this will be fleshed out in due course.  The next installment will be on "Incoming" change detection.