Jaa

ILM "2" also comes as a hybrid...

  • Artikkeli

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"?".

Of course.

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.

Metaverse Provisioning 

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.

Comments

  • Anonymous
    January 01, 2003
    Thanks for clarifying the precedence for hybrid scenarios. The concept I'm struggling with now is understanding how to maintain Sync Rule parameters within the ERE objects. If I specify a bunch of custom data as part of WF activities and I pass that to the SR at the time the ERE is being created it gets stamped, but that data is effectively static within the ERE object. Even if I re-run those WF, am I expected to Remove and re-Add the ERE object in order to update these parameters? What is the expectation for the lifecycle of information stored in the ERE in the form of Synchroniation Rule Parameters?

  • Anonymous
    January 01, 2003
    hi dear bobbygill ! , i need to know something instantly  .   Could u help me please _? i am working for a company and i am supposed to understand some issues . Can you tell me how the concept of ILM works in terms of password , i mean i just enter a password because the password of other applications are reseted ? is it like that ?  and also do i need to write any code in ILM .  Can you explain these in a basic way please ? Thank u for this beneficial web-site . Regards . Serhat

  • Anonymous
    January 01, 2003
    Hey Brad. Yes you are correct. The ERE data is static and if you want to update it, one option is to do a ERE-Remove and ERE-Add in a workflow. A more straightforward approach would be to use a custom activity to muck with existing ERE data -- generally if you want ERE data to be dynamic, you are making the case for using an actual attribute on the schema.

  • Anonymous
    July 30, 2010
    Its good to know about this hybrid model. The most interesting part to me is the working of the join/projection rules in relation to an Inbound Synchronization Rule. I will be trying it out soon. Appreciate you putting this all together. Thanks, Jameel