Ask Identigral is our answer to Dear Abby. According to Wikipedia, "Dear Abby ... is known for its uncommon common sense and youthful perspective", two qualities we're striving for in our blog. Since Abby isn't very good when it comes to identity and access management products' arcana, I together with the rest of Identigral staff have decided to step in and close the gap. Email us your questions about any Oracle identity or access management product(s) and once a week we will post the answers here.

What is the best way to customize Oracle Identity Manager user interface?

When customizing any enterprise-grade product, the first question you (and your clients) should ask is what happens when the product is upgraded. Will you have to provide your own framework and process for maintaining your changes as the product is patched and upgraded? That is the question, as they used to say in ye olde England. Oracle Identity Manager is no exception to the rule. The approach you take for customization can have a signficant impact on the amount of time it takes to patch and upgrade your identity management infrastructure.

First, the basics. Oracle has a document that goes over simple customizations to the Oracle Identity Manager user interface, the document being Administrative and User Console Customization Guide.While there are numerous other ways to accomplish the same goals as those in the guide, following Oracle's suggestions will help you stay out of major trouble.

If you have a requirement where you deduced that a customization is necessary and the customization doesn't fit the norm, it is not addressed in the aforementioned Oracle Identity Manager documentation, then there are four generic approaches available to you:

1) Modify the JSPs to get the behavior you want2) Write new JSPs (and/or action classes and/or other supporting code) to do exactly what you want. Have your new pages be called from somewhere in OIM web UI, e.g. a new menu item that you might have added3) Extend the action classes to either override out-of-the-box OIM functionality or add additional functionality4) Forgo the OIM web UI altogether and roll your own

To choose from these approaches,we have to agree on what's important to us. If we define our goal and key evaluation criterion as being able to draw a line in the sand between our changes and vanilla OIM so that we won't get hurt by patches or upgrades, then none of these are perfect. Our own user interface (approach #4) comes closest but even then there's a large underlying assumption that all interaction between the custom UI front-end and OIM would proceed via official, publicly documented APIs. This may or may not be true, it depends on the requirements.

Whenever you modify a JSP, you will have to merge those changes back into the post-patch or post-upgrade OIM codebase. Having a robust source control system with good merge tools will help speed this up and not make it too onerous but there's a catch. A merge might be easy to accomplish in terms of joining two text files and figuring out what line goes where, creating one physical whole with correct structure but that does nothing for the meaning of that new whole. The new code may end up behaving in a completely different way. Logically, the merge is not complete without regression tests that prove your new page works under the same set of inputs as prior to the merge. The only benefit of directly editing a JSP is that you may not need a server restart to see the changes although that also depends on your app server settings and your strategy for deploying the modified JSP.

Adding your own pages, or extending the classes, typically requires one or more changes to be done to xlWebAdmin.properties, struts-config.xml, tiles-def.xml (there are a couple other files). Modifying these files may require a restart depending on your application server and how it was configured. The advantage of this approach is that there's no code merge, only XML and properties so there's no need for regression tests on existing pages although running them never hurts. With this approach Oracle can add or change features on the web client and usually (but not always) those changes will not have any impact on your custom code.

Thus, our advice is to evaluate the requirement driving the change. I've seen great many cases where the UI customization was not necessary, another solution that did not require that was possible. If there's no way around the customization, think about the type of change you're going to be making. Consider the frequency of future changes to the same component, the size of the change and whether there are any major updates or revisions to the general area of the user interface planned by Oracle and placed on the roadmap. Come up with a policy and a process to deal with all types of customizations so your team follows the same approach for each class of changes. Last but not least, ensure you've got a build & release process to deal with merges and regressions.

Have a Question?

Send your questions to ask@identigral.com and we'll do our best to answer. Please use your work email address - no GMail, Hotmail, Yahoo, etc