For those of you who are MIIS / ILM 2007 pros, when seeing the Codeless Provisioning functionality one of the first questions that comes to mind is “can I use my existing rules extension in ILM “2”?”.
At a basic level, with ILM “2” RC, you can take an existing ILM 2007 deployment and migrate it’s synchronization engine component straight into ILM “2” RC. You can do this by copying the IdentityIntegrationServer DB to a ILM “2” server, and upon installing ILM “2” point to this database instance during the setup of the synchronization component. The installer will then migrate that data forward such that all existing MA and MV configurations are ready to use right away, including rules extensions.
But if you want to go beyond this, its important to note how Codeless Provisioning works side-by-side with existing ILM synchronizaiton concepts. That is, while Codeless Provisioning bubbles up a business process driven approach to synchronization it is inherently underpinned by the same basic mechanics which power the ILM synchronization engine. As such, the adding of this functionality should not in any way change the behaviour of how MA’s work, how rules extensions are called or how traditional metaverse provisioning is done.
This side-by-side coexistence is collectively referred to as a hybrid deployment.
In fact, it is supported to run Codeless Provisioning based provisioning logic side by side with traditional metaverse extensions. Codeless Provisioning is driven through the processing of Expected Rule Entry (ERE) objects, these determine which MV objects are provisioned a connector and how flows are applied on top. For a MV object being sync’ed, this processing is done prior to the calling of the Metaverse rules extension. Hence if for any reason the ERE’s attached to a MV object do not achieve a desired outcome in a CS, you can use a Metaverse extension to provision additional connectors, apply initial flows and deprovision existing connectors just you would have done with ILM 2007.
Custom Functions = Rules Extensions
Metaverse extensions are just one aspect of a hybrid scenario. A more common use case is for scripted flow. ILM “2” RC contains around 20 built in functions, which for the most part should satisfy most basic needs. However if this is not true, then you can always use an traditional Rules Extension to apply a transformation on a outbound flow. Using an MA, you can defined an advanced flow like before. This flow will be applied after any Sync Rule flows have been pushed onto an object, thus allowing you to append or overwrite attribute flow data that was provided by a Sync Rule.
Join / Projection Rules
On the inbound side, the traditional Join/Projection concepts live on as you remember them in ILM 2007. Just like the extension points, you can use traditional declared/advanced join projection rules along side Synchronization Rule concepts. In this case, if you have defined a Inbound Synchronization Rule on an MA that also has traditional join/projection rules defined the Synchronization Rule will be evaluated first. So if a disconnector exists within this MA such that it matches a Synchronization Rule’s connected scoping filter, than this disconnector will be attempted to be joined/projected to the MV based on that Synchronization Rule definition. If the evaluation of that disconnector against the Synchronization Rule results in the CS object remaining a disconnector, then the existing declared join/projection rules will be executed against it.