Simplifying OIM 11g (Chapter Two)

This is the second article in a series of posts with the common goal of providing customers with ideas and techniques that can be used to simplify the use of advanced features of OIM 11g. In Chapter One of this series, we described the components of a framework that would allow users at all levels to configure OIM 11g features like Provisioning and Approval Processes, Approval Routing Functions and Custom User Input Forms. In this second article I will start talking about a reference implementation of the components of the framework described in Chapter One.

The above mentioned components comprise the part of the framework that takes care of Provisioning including the specification of approval flows that will be executed by the custom composite application described in chapter one, which will be the approval process for the Self Assign Roles request template which is out of the box and doesn’t need additional dataset configuration and importing to MDS.

While the goal here is to describe a reference implementation of the framework, it is just that, a high level description of the architecture and the elements that need to be built and the responsibilities of each element/component. The audience can take these descriptions and come up with their own actual implementation. Since this is a framework, once it is built, it can be reused and evolved over time to meet more specialized requirements.

Now I will start discussing the design and specification of the Foundation Components listed in the previous section.

Description: This table stores the definitions of approval flows. Basically the required data for these processes is merely the login IDs of users that should receive requests for approval. The structure of the table supports sequential approvals, parallel approvals and escalations.

Description: This table contains the definitions of custom user input forms that are customizable via XSL style sheets. The contents of this table will be generated through a GUI created for this purpose.

In this section I describe the functionality provided by a couple of web services part of the framework’s implementation. Let me start by explaining the reason why web services are included in the picture. In OIM 11g, all operations associated to Approvals are carried out through Oracle’s SOA Suite. Some of the components that can be most naturally included in SOA Composite applications which represent Approval Processes in OIM 11g are Web Services. So not having Web Services would not make any sense at all. Also, the main purpose of emphasizing this point is to discourage the use of embedded Java in SOA composites specially when the implementation assumes that requests may not be approved for weeks at a time; I have come across some customers that have used OIM APIs in Embedded Java Tasks and have experienced PERM Gen issues on the SOA Server.

This web service will be generated out of entities associated to the above mentioned database tables. JPA entities will be created and a Session Bean will act as the session façade for the entity beans generated out of the database tables. The persistence service will be invoked from the various GUIs used to define Approval Flows, Input Forms and other framework configuration elements.

• Extract the names of the attributes associated to the user in question by querying the OIM_EXT_MV_UPATTR table for the User Login Name of the user in question. The reason why we do this search if because at a given time a user may not have all the attributes populated, so only the attributes that have been populated are processed.
• Extract the key of each custom multi-value attribute from the user profile. The value is used to link the user profile with the OIM_EXT_MV_UPATTR extension table containing the values for each multi-value attribute of each user.
• Extract the values of each multi-value attribute that is populated for the user in question using the key obtained above.
• Populate the corresponding child tables potentially linked to each attribute. The information required to call these API’s is stored in table OIM_EXT_MV_UPATTR for each user.

I intended to present a potential implementation of multi-value attribute support and a mechanism to simplify the request process and potentially provide a more flexible customization mechanism. In the next chapter of the series we will discuss the implementation of the configuration GUI’s and the design of the customization mechanism for the input forms based on XML/XSLT transformations.