Provisioning process in OIM 10g can get very complicated, and understanding the flow with many different tasks is sometimes very time consuming.
One typical case is when a connector is deployed for manual provisioning in one at first, and is later modified for automated provisioning. Process tasks, as almost everything else in OIM, can not be deleted. Your process will then end up with tasks from the original provisioning process and also from the second, all mixed together.
One solution is to use Process Determination Rules. Those rules allow multiple provisioning processes to co-exist, with one being the default provisioning process. The other(s) are chosen when the appropriate rules evaluate to true. In our scenario, the manual provisioning process can remain unmodified, and the new, automated provisioning process can be created on a clean, new, one.
Let’s look at one example.
In this example I created two provisioning processes. “Generic Connector” is the default process.
“Generic Connector Other” is the second process defined for the same resource.
The rule that is going to be used for the runtime selection of the appropriate process is shown below. It has only one element that uses the “Action” attributes in the object form and compare it to the literal “OTHER”. When they match, the rule will return true.
The final step in setting the rule is adding it to the appropriate resource, in the “Provisioning Processes” section of the “Process Determination Rules” tab.
We are going to test the new rule with two requests. One will have the “Action” attribute set to “Other”, while the second one will have it set to “AS400″.
As we can see, before the request, user itnaf1 has no resources.
Before we can go further, I had problems creating a request for the resource because there was a conflict when both provisioning processes had the same form. After restoring the database, I created a similar but different form for both, and everything started working.
Now, itnaf1 has two instances of the “Generic Connector” type.
The first one has the provisioning task “Create User”, defined in the “Generic Connector Other” provisioning process.
The second one has the provisioning task “Run Connector”, defined in the “Generic Connector” provisioning process.
Another important thing is that all other tasks invoked on this resource will still use the same provisioning process selected when the rule was first applied. This includes the undo tasks.
If we revoke the first resource, for example:
The appropriate undo task will be invoked in the resource, the one from “Generic Connector Other”.