Those of You who have attended to Markus Vilcinskas session on last DEC in Chicago should remember this phrase "Don't call me disconnector!". For those who weren't on DEC I will try explain why he didn't wanted to be named as disconnector. Idea for this post came to me after some long and probably fruitless discussion between me and Joe Stepongzi on MMSUG related to disconnectors.
For newbies in ILM (MIIS) world – what is disconnector? Disconnector is an object in connector space (Management Agent view on data source) which isn't connect to any metaverse object. To make it a bit more complicated we have two types of disconnectors:
- normal: disconnector which is possible candidate for connection
- explicit: disconnector which won't be connected anymore.
So … why we don't like disconnectors and why we may want to get rid of them (or at least make them connectors)?
First of all you have to remeber, that normal disconnectors are possible candidates for being connectors, which mean that during synchronization these objects are subject of all activities like filter evaluation, join evaluation etc. This costs You performance as executing these tasks means often executing some code, and even if there is no code attached to these actions this means that such object have to evaluated against all defined rules.
Second aspect is manageability. If CS object is in disconnected state this means that from your synchronization logic point of view this object doesn't exists. You can't apply rules or manage these objects. They are disconnected. So .. if you want to bring them into managed state or for example you want to audit these objects for some reason (orphaned accounts) you want to connect these objects to some metaverse object either through joining them or projecting them into metaverse. This will allow your synchronization logic to evaluate them and maybe do something with them.
Once CS object is connected to metaverse object join rules won't be re-evaluated for it unless it will be disconnected. So what if you want to re-evaluate connections of such object in the feature under some circumstances? You can apply technique described in "Correcting incorrect joins" document to do this. It will require some additional logic to be created in synchronization process, however solution might benefit from it in overall from performance and maybe also other points of views.
So … are disconnectors bad?? As in many other ILM aspects I will say "It depends". It depends what is important for You, how many disconnectors are in CS, are they big burden and are they bringing some impact on environment in case of performance or manageability.
When You will plan your next ILM deployment, except of thinking about attribute flows and provisioning process maybe You should also think about disconnectors. Do You really want them in CS in disconnected state?? Will it hurt performance of solution? Will I need to report them or reflect their existence in some process … for example when looking for unique value??
I think it is good to think about it … so … don't call me disconnector and stay connected to this blog :).