By Shashidhar Malyala on Feb 04, 2015
When an OIM disconnected system application is provisioned to a user, a manual fulfillment activity is generated and can be viewed in the inbox. This task indicates the person has to complete the provisioning activity manually on the target system and mark the status in OIM. The task to outcomes possible:
When the activity is in pending for completion, the resource/account status is 'Provisioning'. Depending on the outcome from SOA, OIM account status is set.
- If the fulfillment person has completed the task and clicked 'Complete' in OIM, the resource status changes to 'Provisioned' from 'Provisioning'.
- If the fulfillment person decides to reject and clicked 'Reject' in OIM, the resource status remains in 'Provisioning' status. This status at this point is not apt. A meaningful status at this point could be 'Cancelled' , 'Rejected' or 'Revoked'.
While OIM supports custom object status, it is a bit tricky to induce the new status into the object life cycle. Hence, it is simpler to set the object status as 'Revoked' than any other. In the following section lets understand what has to be done to achieve this.
Notice that OIM Provisioning process definition of a disconnected system is auto generated and has the following tasks(Has many other tasks, but list shows what we are interested in):
The ManualProvisioningStart process task is invoked when the resource is provisioned to the user as this is the process task marked as 'Required For Completion'. This will invoke a SOA composite 'DisconnectedProvisioning' and create a human task. The process task is completed successfully and a manual task is pending for approval. This doesn't have any impact on the resource/account status
When an action is taken on the pending human task, the process task ManualProvisiongEnd is triggered. This task is responsible for setting the object status. The OOB setting in the Responses of this process task is shown here:
On the 'Task to Object Status Mapping', the status 'X' is mapped to 'None' OOB. This has to be mapped to 'Revoked' for the object status to be set as 'Rejected' when the fulfillment person Rejects the task. The following screenshot illustrates this configuration change:
This is a very simple change doesn't require any downtime. Even if the manual fulfillment human task has an expiry setting, this approach works !!