A few weeks ago Steven Chan posted an open question on his blog asking how support for the E-Business Suite techstack could be improved. Specifically, he wanted to know how interaction with Oracle Support could improve. I sent a suggestion, but it didn’t make the cut; he didn’t post it. 🙁
Since I spent a bit of time writing and editing, it seems a shame to let my suggestion sit lonely on my JungleDisk, so I thought I’d post it here. In a nutshell, I don’t really like the way Oracle has coupled E-Business Suite diagnostics with the application itself. Seems like some sort of physician-heal-thyself approach that makes the diagnostic process contingent on the health of the patient.
Anyway, this was my suggestion:
I would like to see diagnostic utilities as de-coupled from the application as possible, and delivered in a unified format. Diagnostic information should be available quickly, with as little fuss as possible, and should always be current (i.e. keeping diagnostics current should be simple and practical). There should be a unified way to gather diagnostic information unless prohibited by the practical limitations of the technology involved. Co-mingling diagnostic utilities with the applications they are supposed to analyze leads to unnecessary delays in diagnosing and solving problems, and may unnecessarily extend downtime.
Nothing is faster than running a script, and I’m certainly aware that many of the IZU diagnostic tests available in OAM may be run as a shell script out of $IZU_TOP (or even from a downloaded, unpacked IZU patch), but this is rarely the advice from support. Typically, if support wants diagnostic output, they provide instructions for running a test via OAM. As long as OAM is up and running, this is OK; however, there are many cases where the application framework itself is the trouble, and support’s instructions cannot be followed. When asked for alternate instructions, I have run many times into the experience-level issue you describe: Not all support reps know how to run the diagnostics from the command-line and not all of them know which equivalent script to run. This confusion results in delays, especially if the time to sort everything out spans a support shift change.
I try to keep diagnostics up-to-date more aggressively than any other apps component, but because they are delivered as a patch, the process of staying current seems unnecessarily cumbersome. The patchsets.sh script is a great example of a better update method: Patchsets.sh can be scripted in cron to update itself every day with no user interference. I have wrapped patchsets.sh in another script that runs a weekly update and execution against production. This is very nice, because I have an up-to-date report every week that I can quickly reference and include in any TARs as needed without having to do anything special. Most importantly, I know that I have run the latest version of patchsets.sh available. With IZU, the process is not as simple. A great deal of user interaction is required, and because IZU is an application component instead of something much simpler, we can run into bugs like the recent TXK.S problem described in note 604263.1. Such problems seem to be so unnecessary; why should diagnostic utilities ever meddle with the application they are supposed to examine?
As a side note, the RDA is almost as simple to automate as patchsets.sh. The download is not as easy to automate (it should be) but the RDA can be scripted to run weekly or daily so that the output is readily available when logging a TAR.
I would love to see:
- A comprehensive diagnostic suite (including RDA, IZU, and patchsets.sh) that ran exclusively from the command-line in perl, shell, or whatever was appropriate for the OS. Bottom line, it would not be part of the application so that application problems would not interfere with diagnostic execution and there would be no potential confusion from support.
- Updates to the diagnostic suite that could be easily scripted via ftp, wget, etc., so as to allow automation. I think this would lead to better information for support and everyone involved in a TAR.
- A way to upload to a TAR directly from the command-line; it would be great to have a simple method for uploading diagnostics to a TAR without having to move zip files around to a place where my browser can access them locally. Again, I know such functionality is available to a degree in OAM, but it seems counterintuitive that application downtime should render such a tool unavailable.
Bottom line, I would love to see improvements with speed, automation, and simplicity when gathering diagnostic information.
EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.
Imagine there are over one hundred logins in the source server and you need to migrate them all over to the destination server. Wouldn’t it be awesome if we could automate the process by generating the scripts for the required tasks?