OIM11gR2: Issue with (request form prepop Vs process form prepop)
By Shashidhar Malyala on May 20, 2013
Pre-Populating known information on a request form during a provisioning operation is a very common need. OIM11g R2 supports request form pre-population using plug-in concept. The plug-in point is "oracle.iam.request.plugins.PrePopulationAdapter". A sample entry in plug-in.xml is shown here:
| <plugin pluginclass="PrePopulateUserLogin" version="1.0" name="PrePopulateUserLogin">
<value>PrepopTestApp::User Login|FileTransfer::Account Login</value>
The class PrePopulateUserLogin is used maintain the logic to fetch and return the value of User Login.
The returned value is populated on the attributes mentioned in the <value> element of the above seen snippet. They are 'user Login' field on the 'PrepopTestApp' application and 'Account Login' on 'FileTransfer' application.
In case the plugin class couldn't fetch a value for User Login and it is programmed in such a way that a blank/empty string is returned. In this scenario doing this may look smooth and robust enough. However, this is an issue if you also have a logic to pre-populate the same attribute using a pre-populate adapter attached on the process form.
The User Login is returned blank by the request form pre-populate code. The request is submitted with a blank User Login value. Say the request had gone through required approvals.
The process form pre-populate adapter gets triggered because the 'User Name' attribute is blank. Any OIM developer can state that, once the pre-populate adapter is triggered and returns a value, the value is populated on the process form. Surprisingly, this doesn't happen in this case.
The adapter is triggered and a value is returned, but the form is not populated. In case your User Name attribute is mandatory on the process form, you account stands in provisioning state and you can see from the Resource History that 'System Validation' is pending. Try this out!!!
At least I felt that it is a good discovery. The solution is simple.
In your request form pre-population logic if you don't find a value to return, return null instead of blank string
Case1: If we do this, the process form pre-pop triggers but will not a set a value . The weird thing is since it is triggered, it should set the value fetched, but it doesn’t.
Case2: The process form pre-populate gets triggered and sets a value
This means, for request form pre-populate we should return null, if the
source attribute value is either blank/null.