Friday May 13, 2016

Event Handlers upon Resource Provisioning Activities

After deprecation of entity adapters, everyone know that Oracle has introduced event handlers to perform operations on pre and post of insert, update and delete activities. 

By now, almost all OIM developers might have worked on writing Event Handlers pre and post of creating and updating a user/identity profile. This is a very frequent requirement. 

There is a chance one might want to write event handler that triggers on account provisioning activities. The blog post is intended to provide an example of how to trigger an event handler on successful provisioning of a resource. 

Before getting to the details one must understand there are various operations supported by OIM like Create User, Update User, Provision Account, Disable Account, Create Role, Delete Role, Update Role, Provision Account by Access Policy, Revoke Account etc... and each operation is considered to be a different orchestration.  

1. Entry to EventHandler XML file for AP based provisioning:


 Notice the values for entity-type and operation. The values indicate that the event handler should trigger upon provisioning a resource. The operation value especially indicate that the event handler should trigger only if a resource is provisioned using Access Policy. 

 2. Entry to EventHandlers XML file for direct provisioning:


 In this case the value of operation is 'PROVISION'. One can similarly use REVOKE for triggering event handler upon revoking an account.

OTN documentation provides right value for 'operation' and 'entity-type'  for certain frequently used operations. In order to find all possible values, use the following and perform the operation:


 The handler code can print the values for operation and entity-type:

1. abstractGenericOrchestration.getOperation()

2. abstractGenericOrchestration.getTarget().getType() 

The input parameter to the execute method of event handler differ based on the operations. In case of 'Resource' type use conditional event handler and identify the resource being provisioned in the context. Based on the resource decide whether the actual handler logic is required or not. 

Important Note: Using Any/Any is for the properties is not supported. This is for internal purposes only. Using this may have high impact of product performance.  

Thursday Nov 26, 2015

OIM11gR2: Side-effects of using EntityManager API on update Event Handlers

The main purpose of using EntityManager API to update a user-profile on a post-update event handler is that the event handler shouldn't get into an infinite loop. This is very clear.

Consider a scenario where there is a UDF 'Company Name' which is populated based on user's Organization. Assume, it is just a simple 1-1 mapping between user's Company Name and Organization.  The 'Company Name' attribute is read-only on the user profile and its value needs to be propagated to downstream applications and LDAP Synced. The 'Company Name' attribute is populated using a user-post-update event handler. When user's Organization changes, the event handler is held responsible for updating the 'Company Name value' and it works awesome. 

Sample code on event handler at this point:

HashMap<String, Object> mapAttrs = new HashMap<String, Object>();                   mapAttrs.put(COMPANY_ATTR_NAME, companyCode);  

         //Use profile is updated here with non-null company code.

 EntityManager entMgr = Platform.getService(EntityManager.class);                 entMgr.modifyEntity(targetType,usrKey, mapAttrs);  

 After changing the user's organization from UI, the user profile is updated with new Company Name value, however, either the downstream applications or LDAP Sync directory is not updated with new value. This is because, the EntityManager API does not initiate new orchestration when an update happens. This is as good as database insert/update.

 It is now clear EntityManger API is not suitable in the above mentioned scenarios. Thinking of which API to use? The obvious answer is UserManager API. Yes, use UserManager API.

Instantiate and use this API as shown:

HashMap<String, Object> mapAttrs = new HashMap<String, Object>();              mapAttrs.put(COMPANY_ATTR_NAME, companyCode); 

UserManager usrManagerAPI = Platform.getServiceForEventHandlers(UserManager.class, null, null, null, null);

User userToModify = new User(usrKey,mapAttrs);             


 This way a new orchestration is started and rest of the operations like LDAP Sync, User process triggers etc..are placed accordingly. 

Wednesday Feb 04, 2015

OIM11gR2PS2: Disconnected System Resource status based on manual fulfillment outcome

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:

  1. Complete
  2. Reject  

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.

  1. If the fulfillment person has completed the task and clicked 'Complete' in OIM, the resource status changes to 'Provisioned' from 'Provisioning'. 
  2. 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'.
[Note:For a full view, open the image in a new tab]

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):

  1.  ManualProvisioningStart
  2. ManualProvisiongEnd 

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 !!

Monday Jun 23, 2014

OIM11gR2: SOA composite for Request Approval Process

The Oracle Identity Manager version consider is OIM11g R2 Base.[Read More]

Monday Apr 28, 2014

OIM11gR2: How to handle child data in a custom ICF connector

This blog entry explains how to perform child table operations in custom ICF connector code.This blog does not explains in detail about how to write ICF connectors. This is just to help set up and perform child table operations through ICF.  

We will only discuss here what APIs to use to perform child table operations in your custom ICF code. Second section of this blog entry will discuss a typical requirement of setting up reconciliation for a resource with multi-column child table through custom ICF. 

SECTION 1 - Child table operation APIs in custom ICF connector

We may want to perform different provisioning operations such as add, remove, update on a child table through our custom ICF code.  

Operation Add/ Remove operations on child table:

To perform child table operations in custom ICF connector, you need to implement UpdateAttributeValuesOp interface in your connector code. The methods addAttributeValues & removeAttributeValues deal with adding and removing child table data.

addAttributeValues(objectClass, uid, attributes, operationOptions);

removeAttributeValues(objectClass, uid, attributes, operationOptions);

Here one should note that, UpdateOp is used for updating only Parent form attributes. To handle parent form updates & child form creation/updation/deletion we have to implement both the interfaces i.e., UpdateOp and UpdateAttributeValuesOp.

UpdateOp interface:

UpdateAttributeValuesOp interface:

Update operations on child table:

1)     You may have a question as to "How is update to childtable data handled in ICF"? This is how it works :-

        When child table row is updated, OIM triggers removeAttributeValues(oldValue) followed by addAttributeValues(newValue) in the connector.

  Now how do we pass values to following methods:

public String addChildTableValue(String objectType, String childTableName, long childPrimaryKey)

public String removeChildTableValue(String objectType, String childTableName, Integer taskInstanceKey)

 Here, objectType will be User, ChildTableName should be the name of child table process form of your implementation and refer below images for mapping childPrimaryKey and taskInstanceKey:

 childPrimaryKey Mapping

taskInstanceKey Mapping

Using above information you can perform different provisioning operations on child table through custom ICF connector code.

SECTION 2:  Setting up reconciliation for Multi-column child table in custom ICF connector

We often see requirements where multi-column child data has to be processed using custom ICF. We had a requirement where we were required to reconcile a resource with more than one column in its child form.

 We could not find enough information about how to achieve this in any of the blogs/ product documentation or even training docs. Training guide, though talks about Flat file custom ICF with child table, but that only is for child tables which have single column. 

 Handling multi-column child table in custom ICF is different from how you would see for single-column in lab guides or product documentation ( Developer guide: 

Below is what was done in our case:

Requirement: To Provision and Reconcile multi column child table data using custom ICF

Below is how the parent and child form data looked in our case:

Child table Data Reconciliation Implementation:

 The recon lookup for our implementation was set up as below:

  1. Recon Lookup :

 2.  Apart from implementing  addAttributeValues & removeAttributeValues methods in your code, you also need to have executeQuery(), schema(), getEmbeddedObjAttributeInfo() and addAttrInObjClass() methods in your custom ICF code.

Below is the code snippet of different methods that we implemented for child table:

Here,  APPS = ‘apps’ and APPLICATIONS = ‘Applications’  (from lookup entry above) in the code below.

‘Applications’ and ‘UserName’ in getEmbeddedObjAttributeInfo method are the child table columns

   3.  Below is the snippet from executeQuery method for child table data wrapping

Here too,  APPS = ‘apps’ and APPLICATIONS = ‘Applications’  (from lookup entry above) in the code below.

4.  Below is how we had set up Reconciliation Field Mapping in Process Definition:

Friday Apr 25, 2014

OIM11gR2PS2 New Features

  • Access Policy Harvesting for Reconciled Accounts

  • Dynamic Organization Membership

  • Hierarchical Entitlements

  • Catalog Auditing

  • Archiving/Purge Support for Entities

  • Draft Request Support

  • Additional Information in Requests

  • Account and Entitlement Dependency Handling

  • Entitlement Form Support

  • Sunrise/Sunset of Accounts and Entitlements

  • Flexible Certification

  • Improved Diagnostic Console via Oracle Enterprise Manager

  • Enable Taskflows for Customization

  • FVC Utility Enhancements

  • BI Publisher Certification for IBM WebSphere Application Server

Wednesday Mar 26, 2014

OIM11gR2PS2 OPSS Upgrade: Internal Exception: java.sql.SQLException: ORA-12801: error signaled in parallel query server

[Read More]

OIM11gR2: Uninstall connector utility

Unlike earlier version of OIM, you can now uninstall a connecter that is installed using a connector bundle or created on an environment directly.

Note: Before deleting a connector, navigate to Resource Object and click Create Reconciliation profile before deleting connector. Otherwise you see the connector delete is unsuccessful.

The following are the steps involved in uninstalling a connector:

 1. Set up the properties file with appropriate information. Location: $OIM_HOME/bin/

2. Execute the uninstall script. Location: $OIM_HOME/bin/uninstallConnector.bat or

Almost all the properties on the file are explained in the OOB file. The focus here would be on ObjectType and ObjectValues properties.

If the connector is installed using a connector bundle and you wanted to uninstall it, ignore these properties.  If a connector is installed using Deployment Manager --> Import then these properties are helpful.

By providing ObjectType=Resource and ObjectValue=<Name of RO>, a few of the important connector components can be deleted.

If a connector is uninstalled using the Resource Object Name and it is value, the objects like Process Definition, Process Form, IT Resource, Application Instance are deleted. Note that the request dataset is not deleted.

OIM11gR2 : Fetch Human Task comments using SOA API

From OIM11gR2, in order to get the human task comments one should use SOA API instead of OIM Request API.

The Task Id or Task Number can be obtained from OIM request tables which can be used to uniquely identify the human task.

Refer the link to know human task operations using SOA API:

Tuesday Jun 11, 2013

OIM11gR2: ADF: Frequently used EL expressions



EL [Expression Language]


Get the current user’s attribute value by passing the attribute name



Similarly get the value for a UDF



Gets the roles assigned to current user. Returns list of RoleEntity objects. It is a Java Bean having name, description, key, and displayName properties



Return true if user is a system administrator

#{oimcontext.currentUser.roles['SYSTEM ADMINISTRATORS'] ne null}

Returns true if user is assigned with admin role


#{oimcontext.currentUser.adminRoles['OrclOIMSystemAdministrator'] ne null}

Returns user key


Returns user key


Returns user login

#{oimcontext.currentUser['User Login']}

Returns current operation. Possible values: CREATE/MODIFY


Returns true if the current operation is Modify

#{pageFlowScope.requestFormContext.operation eq 'MODIFY'}

Return the current action type. Possible values: APPROVAL/ FULFILL/ REQUEST/ VIEW/ SUMMARY.

On all approval pages/ approver view the value is APPROVAL

For Manual fulfillment page the value is FULFILL


Returns true if the action type is Request i.e. the user is about to submit the request

#{pageFlowScope.requestFormContext.actionType eq 'REQUEST'}

Returns true if the request is bulk


Returns beneficiaries user ids[user login values]


Returns keys for cart items


Returns the type of item added to request. Possible values: ROLE/ ENTITLEMENT/ APP_INSTANCE/ USER.


Returns true if added item is Application Instance

#{pageFlowScope.requestFormContext.requestEntityType eq 'APP_INSTANCE'}

Returns application instance key for the item added


Returns provisioned instance key for a modify type request


Invoke a method present on backing bean

#{backingBean.<Bean Name>.<bean method>}

To show a field disabled on all FULFILL and APPROVAL pages

disabled="#{pageFlowScope.requestFormContext.actionType ne 'REQUEST'}"

OIM11gR2 Blog by NA-TAG Offshore IDAM team


« July 2016