Oracle RUEI for Oracle Forms 11g R2 : The good, the not so bad, and less ugly than before

I was VERY happy to get feedback from Jurgen de Leijer product management director, responsible for Oracle Real User experience Insight (RUEI) on my post  “Oracle Forms 11g R 2 RUEI – Real User Experience Insight – The Good The Bad and The Ugly”. He was (not surprisingly) less than happy about my bad and ugly sections and gave some great feedback and information on RUEI. It was so great in fact that I decided to write this follow up, mini retraction and request for further clarification.

Jurgen starts by saying that

“RUEI is not a part of Oracle Forms 11R2 but part of the Application Performance Management features of Enterprise Manager.“

The truth is that when I wrote “ Oracle Real User Experience Insight (RUEI) support is a new feature of Oracle Fusion Middleware 11g R2 “  I copied this from the Oracle Forms 11g Release 2 (11.1.2) New Features  document where it says

“Oracle Real User Experience Interaction (RUEI) is a feature of Oracle Fusion Middleware that provides non-intrusive monitoring, giving insight into how a user is interacting with an application.”

So thanks for the clarification. You may want to have the Oracle Forms team fix that as well. 🙂

Next you mentioned that RUEI is

“Completely passive and does not require any instrumentation! … It is true that early versions did use the EUM instrumentation but this dependency was removed almost 2 years ago… So in summary “the bad and ugly” described in this review really doesn’t apply as we are not using/requiring any instrumentation.”

I was really happy to read the new version of the RUEI user guide document you sent (In my post I referred to features in the documentation of the previous version of RUEI that used EUM for monitoring and not to version 12c as is available now. (Wasn’t version 12c only released at OOW this October ? ) I must say it is GREAT that you no longer relay on EUM for monitoring. I think we both can agree that EUM was not one of the better monitoring utilities to come from Oracle.

Doing passive monitoring is incredible and what all forms adminstrators hope to achieve but only if it generates meaningful data that can provide system and application managers an in-depth understanding of the behaviors and functioning of the system.  I wanted to take this opportunity to try and clarify exactly how this passive monitoring will work for Oracle Forms stand-alone systems.

For EBS systems I understand this passive monitoring is easier.  As Oracle EBS is a packaged app you supply predefined mappings of form names, functional descriptions, application names and you can probably even define processes that are reoccurring across the system. However for Oracle Forms stand alone systems this is much trickier.  Developers worldwide have created very diverse, multi-lingual, multi purpose systems that can be hard to gather this type of data without requiring any instrumentation.  In the document you referred us to Oracle® Real User Experience Insight User’s Guide 12c Release 1 it says:

Working Within a Forms-Only Environment

Customers working within a Forms-only environment should pay particular attention to the issues highlighted in this section.

In order for RUEI to accurately report on EBS-based applications, it needs information about your production environment. In particular, it needs to map functional areas to reported names. … Customers within Forms-only environments are also recommended to run this script and upload the generated .txt files within a .zip file.

Relying on the Default (Template) Mapping

If manually creating the required mappings is not practical, you can simply rely on the default (template) mappings already configured within RUEI. While this approach provides an adequate level of reporting, it is subject to the following restrictions:

• form_name: normally this would be the 8-character technical name translated to a functional description. However, because this is not available, the 8-character technical name is reported instead.
• app: normally this would be derived from the mapping file that connects the form name with the application. However, because this is not available, the first three letters of the form name are reported instead.
• application_name: normally this would be derived from the mapping file. However, because this is not available, the app is reported instead.

Keeping Matching Information up-to-Date

Because Forms-only environments typically change over time, it is strongly recommended that you regularly review your mapping information. Be aware that the above restrictions will also apply to any forms that have been added to your environment since your last ran the create_EBS_info.pl script or manually created the mapping files.

So if I understand correctly, if I did not want to do any manual instrumentation or mapping for a regular Oracle Forms application in RUEI. The graphs and data I would see in the tool is information on form name – SP_0009, from system name – SP_, in application named – APP.  This is not exactly the in-depth passive monitoring data of my system I was hoping for.  J In fact this would only really work if a system used prefixes for form names and named the “technical name” (is this the module name in the fmb file or the fmb name?) something functionally relevant.

Please correct me if I’m wrong (I hope to be wrong 🙂 ), but although the work to map the various elements of a stand-alone forms system does not look very difficult (running scripts) it does require manual intervention. In order to derive the real value that RUEI can thankfully provide there is some mapping work to be done and it needs to be kept current.

Finally you were generous enough to write

“If you have any additional questions, do not hesitate to reach out to me, jurgen.de.leijer@oracle.comI’m happy to guide you through any detail of our Forms coverage and/or answer any questions.”

I would like to take this opportunity to firstly thank you for your comment. It is great to see that Oracle product management really cares to educate the community. I would also like to reach out to you as you offered and ask you to further enlighten the forms community with a guest post on my blog. This would surely fill in the blanks we still have on how to get the most out of end-user experience monitoring of Oracle Forms systems (not EBS). I’m sure this would provide our readers and the forms community with real value and desire to do implementations of this desperately needed solution.

In the meantime I will try and cull as much information on RUEI Oracle Forms 11g R 2 and post the full findings early next week.

If anyone else has any experience on the subject, we’d love to hear from you!