ILM2 RC0 – Updating Portal objects the no-code way

I am working on a demo scenario :  Certain information about users (name, department, job title, start date) should come direct from HR or from a simplified User Create form; other account-specific stuff (account name, mail nickname, mail database) should be automatically populated; and the account should be provisioned to AD/Exchange when all information is present and correct.

Unfortuantely this has been proving trickier than I would have liked, and the main culprit is the Function Evaluator. This little workflow action is supposed to be able to assign values to attributes in the portal but, as it turns out, is completely broken in RC0.

I struggled for some time with the Ensynch guys’ posts on how to build your own replacement for the Function Evaluator (see here and here) – but, not being much of a programmer, this proved too much for me. I have now found myself a satisfactory workaround using a good old fashioned MIIS approach (and some codeless provisioning rules).

Overview

The approach is simply to add an extra SQL table and MA. Using export flow rules I generate the values I want into the table and then import them back in. I can now flow these values back into the portal through the ILM MA.

So an account creation started from the HR database would go like this:

HR -> ILM -> GenerateAttribtes -> ILM -> AD

The rest of this post is really just an example of how to codelessly provision to the GenerateAttributes SQL MA.

Configuration of the ILM MA

The ILM MA only allows direct classic flow rules, so that’s pretty straight forward.You should create both Import and Export flow rules for all the attributes you’re using.

If you need some extra attributes in the ILM schema then see the Schema UI document.

The GenerateAttributes MA

The table I’m using is a very simple one (my favourite sort) with an ID field to hold the employeeID, and the various other values I want to generate.

This table is linked into ILM using a bog standard SQL MA. I’ve been finding it works better to use classic Import attribute flows, mostly because the precedence works.

And I set that precendence so that the GenerateAttributes values can replace the ILM values.

The HR MA

Continuing as above, I created classic import attribute flows for the HR MA.

I did make one exception and used a sync rule for flowing the StaffID (number) into the employeeID (string). Using a classic Advanced IAF I would have had to write some code , but with the sync rule it is a simple matter of concatenating the number with a blank string. As I’m not provisioning there is nothing else to do here, apart from importing the sync rule object in the MIIS metaverse.

The Provisioning Sync Rule for GenerateAttributes

I then created a sync rule called GenerateAttributes-export-person for provisioning and EAF for the GenerateAttributes MA. I’m please to report this worked first go – I must be getting the hang of it!

I defined a Set which I called “_All Users” and which finds all the people who should have user accounts. It’s pretty much the same as the one in this post.

Next I created a Workflow called “_GenerateAttribute Export SyncRule” which runs the Sync Rule.

And finally I created a Management Policy called “_Provision GenerateAttributes” configured as follows:

  • Requesters: “All People”
  • Operation: Create resource, Add/Remove/Modify resource attributes
  • Target Resource Before/After request: “_All Users”
  • Action: “_GenerateAttributes Export Sync Rule”

Generating the Attributes

Now, as soon as a person is created or changed, and as long as they appear in the Set you defined above, you should see this new sync rule added to their Provisioning ERL.

When you run an Import Sync of the ILM MA a new object will be created in the GenerateAttributes MA, complete with the new values.

Export and re-import the values, then export out to ILM, and you now have your generated values.

Finally, Provisioning to AD

I have already blogged about how to codelessly provision AD/Exchange 2007 users here, so I shall refer you to that post.

I will just add that my Workflow for AD provisioning is applied “Based on attribute value”, and the attribute is “Account Status”. I flow a constant value of “Approved” from the HR MA, then I replace that with “Active” from the GenerateAttributes MA. Only when the person is updated with the “Active” value in ILM does the AD provisioning rule get applied.

About: Carol

I've been doing IT for 30 years, and IdM for 15. I live in Australia and build IdM solutions based on Microsoft Identity Manager. I also play the violin, but that doesn't help much with the IdM solutions.