Monitoring OIM R2 PS2 Orchestration

The OIM R2 PS2 ( release provides a great new feature: monitoring of OIM orchestration processes through Enterprise Manager console.

Such feature provides the capability of querying orchestration data to check orchestration processes details. For example, you can check what happened during a user modification operation, or you can get details of failed orchestration processes, such details can help you to fix issues in your environment. It is also possible to check configuration information, like which event handlers are defined for a specific orchestration process.

To access the new feature you have to:

  • Point your browser to http://admin_server:port/em
  • Log in with domain administrator credentials
  • On the left menu, open the ‘Identity and Access’ menu item
  • Right click on ‘OIM’ menu item
  • In the opened context menu, click on ‘Administration’

After the steps above, the following page will show:


The Dashboard page shows the most recent orchestration operation instances that happened in OIM. It contains a table with all the orchestration operation instances and a specific table for the failed orchestration operation instances.

If you click on the Operations tab, you can check the configuration of the different orchestration operations, including the event handlers configured for each of the them. You can verify the order of the out-of-the-box event handlers so you can configure custom ones with the right order. You can also verify the custom event handlers deployed to your environment. The image below depicts this tab and highlights a custom event handler definition:


The third tab provides you with a search form that you can use to search for specific orchestration operations instances. You can filter your search by a particular operation, by beneficiary, by operation id and some other fields. The screenshot below depicts a search filtered by beneficiary. Note the different orchestration operations on the left table column:


But the most interesting and useful feature of this new monitoring tool is the ability to investigate the failed orchestration operations and find the failure causes. There are a couple of different ways of doing that, so let’s first go back to the Dashboard tab: in this tab, there are two links available in the each row of the Failed Operations table. The first link is on the Operation Id column, the second one is on the ECID column, the screenshot below depicts that. The failed orchestration operation was an attempt to update some user’s attributes, in other words, it was a Modify User operation. Let’s follow the links on the failed operation instance below and try to figure the issue out:


Clicking on the Operation ID column link will take you to a new tab showing the orchestration operation instance details, including the sequence of the executed event handlers. Depending upon the failure cause, a link on the ‘Error Message’ column might be available, so you can click on it to get more details. The two screenshots below depict that:



Although the full stack trace is available, it is not possible to conclude what has caused the orchestration operation to fail. So the other route to take is to go back to the Dashboard page and click on the link in the ECID column.This link is very interesting and it will take you to a different page; a page that is actually another feature provided by Enterprise Manager console: diagnostic log files analyses. And, to make things even better, /em console will filter the diagnostic contents based on the ECID value that you clicked on, the screenshot below depicts that:


So, according to the log statements in the screenshot above, OIM was not able to get a connection to the LDAP server in order to execute the user modification (the OIM environment used to build this post is configured with LDAP Synch), therefore the User Modification orchestration operation failed.

It is important to mention that the information shown by the monitoring tool is based on the data from the orchestration tables. Such data gets cleaned up according to the configuration of the OIM Data Purge scheduled job. It is always a good practice to configure this job according to your needs so you have control over the data growth in some of the OIM operational tables.

Have fun!


  1. Kevin Pinsky says:

    Excellent article Daniel. It’s great that there is a search field for both Request ID and Reconciliation ID. Is this added functionality in the documentation yet? Is there any notification process available in these tabs to notify when an event is found to be in an incomplete state?


  2. Philipp Grigoryev says:

    Perfect article, thank you!

Add Your Comment