So, while working with one of our TAP customers this past week I got the chance to do a really deep dive on Codeless Provisioning. The past weeks worth of posts here are the partial result of that endeavor and out of that came a deck with a few interesting slides that I thought would make good blog fodder. So here it is, in all of its glory, the "Codeless Provisioning Detour".
With MIIS/ILM we've enjoyed (some would say suffered) a somewhat inflexible system for provisioning new objects into other connector spaces - the Provisioning Rules extension. "Why do I need to write code to provision new accounts?" has been the frequent cry heard by the product group certainly since the product shipped back in 2003. We've all gotten used to handling our own "manual workflow" through this method despite its limitations and yet it has a peculiar bit of efficiency about it that you'll no doubt come to realize once you understand how Codeless Provisioning works. Let's look at how things work today:
This creates a pretty efficient pipeline when you can take information from an authoritative source, make a decision about it and then immediately take action. With Codeless Provisioning we have to take a "detour" through the ILM MA and the portal application so the workflows, processes, and policies can work their magic.
With ILM 2, in order for WF to take effect you have to first get the object into the portal to begin with. Getting the object into the portal allows your Management Policy Rule to fire and create the ExpectedRuleEntry object for every object that falls under the scope of your Synchronization Rule.
When you check the little box on an Inbound Sync Rule to "Create object in ILM" it's provisioning the object into the ILM MA datastore so it can be evaluated for Outbound Sync Rules.
It doesn't really matter yet that you have Outbound Sync Rules already in place - until you take the detour through the ILM MA your new objects can't be added to the scope of those rules yet; more on this later.