Performance Tuning Tips for OIM

Escalations in OIM are typically related to performance issues; however, performance problems can be prevented by following some common recommended practices on how to configure OIM’s components and connectors.

This article will discuss several kinds of issues/recommendations that can cause/avoid performance problems. These are grouped in the following categories:

• Memory Related
• Connector Related
• Customization Related

MEMORY RELATED ISSUES

Heap Size for the VM running OIM’s process: This is a very common question for which there is not a definitive answer for all cases. Unfortunately, this is highly dependent on how OIM is going to be used. Some companies are highly dependent on automatic provisioning and very rarely use UI driven processes. For these cases, it is important to ensure that the VM has enough memory available to process big loads of data at any given time. Most of the time we have seen 2-4 GB assigned to JVM heap as a maximum which works well for the higher automatic provisioning processes. For those companies that allow their employees to request their own resources, the value of Heap memory should be able to accommodate enough resources according to the following criteria:

• Concurrency: The higher this gets the more memory will be required. Unfortunately it is very hard to determine an actual number but 4 GB seems reasonable for high concurrency implementations.
• Complexity of the Data Schema for the resources: If the provisioned resources available in the implementation have a lot of data dependencies on third party systems or the Process Forms are very intricate or have a lot of Child Tables associated. This will require more memory to represent requests for these resources. The recommendation is to always try to simplify as much as possible the design of your process forms and resource objects schemas.
• Complexity of the Approval processes if any: The need to open connections to third party systems to search for approvers for instance or determine the destination of an approval request affects the memory requirements as well, especially in high concurrency systems. In 11g this is not a factor because these requirements are implemented in SOA Composites handled by a SOA Server.
• Size of Metadata and Configuration Data (Lookups): Be very mindful of how much information is represented as lookups or configuration data. Some customers decided to store corporate groups as Lookup Fields which is causing hundreds of thousands of entries being pulled out by lookup fields. This is a potential performance problem since OIM’s implementation of Lookup Fields executes Lookup queries to pre-populate the list of values displayed to users for selection. There is no database driven pagination, pagination actually happens in the UI. This affects in a significant way, the amount of memory required and customers should be very careful as to how they represent data associated with the provisioned resources and how this data is retrieved and presented to users in the UI.

CONNECTOR RELATED

Provisioning is a very complex problem to solve in companies. OIM inherits a little bit of that complexity in order to simplify in some degree the mechanisms that tackle this complex problem. Connectors are right in the middle of the storm when it comes to addressing this complexity because they are the cornerstone for account provisioning to target systems, which are as numerous and diverse as the needs of all lines of business in which OIM operates. Customer environments are almost always comprised of a mixture of commercial software systems and in-house built applications which most often than not have very specific requirements. Some things to keep in mind when working with connectors and customizing them are the following:

• Understand the life cycle of adapters and connectors: This is very important, because many times customers and integrators forget about this and implement customizations in a way that is not suitable to the dynamics of OIM’s component life cycles. Implementing resource pools inside adapters is not a good practice, and it is futile because adapters are instantiated per request and are totally stateless. If adapters need to make use of centralized resources, consider leveraging application server resources like JDBC data sources for instance. This will keep adapters separate from the management of such shared resources and will be able to make use of those resources even across multiple adapter instantiations.
• When it comes to reconciliation implemented by connectors. Reconciliation uses JMS resources to process messages. To enhance performance customers usually configure distributed JMS destinations when supported by the hosting application server. Some servers have a feature called Server Affinity, which when enabled, prevent the load balancing of messages across multiple physical servers having destinations as part of the distributed JMS destination. In WebLogic this can be turned off, allowing multiple JMS producers to distribute messages to physical destinations present on different servers from the one the producer is sitting on. This truly allows big clusters to be leveraged for large reconciliations. This in conjunction with increasing the number of MDB threads processing reconciliation event messages can enhance the performance of large scale systems. For details check the following link: http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jms_admin/advance_config.html#wp1076348

CUSTOMIZATION RELATED

OIM provides multiple mechanisms to integrate customer’s business logic into their OIM implementation. Some of these mechanisms come in the form of Adapters. Adapters can be used for pre-population of process data forms and request fields, and to perform operations on the user’s data before during or after the user is inserted in the database (Entity Adapters). OIM also provided a rich set of API’s so customers can create their own UI’s to access OIM’s functionality.
Traditionally, OIM 10g customers customized the Struts Actions implementation classes whose source code was actually exposed. Even though this was very powerful, many customers ended up with poor performing UI’s. In OIM 11g, customizing the Out of the Box Web Console beyond adding cosmetic changes like adding logos or changing labels and such is no longer a possibility. If customers require special handling of data that is not supported by the out of the box Web Console in OIM 11g, then using OIM’s APIs from a custom UI is the only approach. Some recommendations that apply to customizations are the following:

• Pre-Load OIM’s APIs and reuse the references as much as possible: Avoid looking up for OIM’s APIs interfaces every time an adapter needs them. This is a perfect opportunity to implement a wrapper that follows the recommendation above. Make sure you synchronize access to those references to make your code more robust and reliable.
• Know the size of your data: It is very important to know how much data will be handled by either a customized version of the Out of the Box Web Console or your own UI. Performance may be highly impacted by it and also will affect the memory requirements. See Memory Related Issues for more about this.