EBS 12.2 issues seen in the wild
Recently, I was involved in an EBS upgrade project, and also in operational support of an EBS production environment. Based on this project, here is an unsorted list of issues I've seen in or around the EBS core.
EBS architecture
EBS, or Oracle Applications was designed around Oracle database and is a very old product (it was first released when I was in kindergarten). Due to its age, you would expect that the complexity of the product is high. And it really is. Most of the old functionality is handled by Oracle Forms/Reports, while new functionality is slowly moving to the web and runs on top of an OA framework as a JEE application in Oracle WebLogic. The "old" part was client-server some time ago, but was retrofitted to the web as well and is available now as a Java applet, or a Java Web Start program. Forms/Reports provide desktop-like screens which are stable and work really well (provided there are no major issues on the DB and network side). They look a bit like they are from the 20th century though, which probably explains the desire to move out to an OA framework and pure web. From a Form screen, a user can also start a long-running request in the background which is going to be run by a Concurrent Manager process - a separate Java process running on an application node which is supposed to run long-running tasks in the background. Every concurrent request is tracked and recorded, and you can view quite a bit of data about it in FND_CONCURRENT_REQUESTS table. It's a great source of information about your program's runtime, and you can re-submit one again if needed.Concurrent manager
There are a few inconveniences, though:- One nasty issue I've seen is with queries by internal concurrent managers accessing FND_CONCURRENT_WORKER_REQUESTS & FND_CRM_WORKER_REQUESTS views. Those views have text which is generated on a per client configuration. They can become really big and ugly. So ugly that Oracle's query transformation engine trying to use an OR expansion can lead to a very long hard parse and excessive PGA usage. There's a patch 20355502 which is not enabled by default, and there's a regression/improvement to the fix in bug 27321179. A workaround ia an SQL patch with _no_or_expansion=true.
- There is no SID,SERIAL# in FND_CONCURRENT_REQUESTS. This is something really odd and hard to explain, and it makes it not always easy to map actions of a particular request into Active Session History data when the request is finished. What I'd really like to see is CM push requests' REQUEST_ID into a V$SESSION.ECID field which is then captured by ASH. That would greatly simplify CM request diagnostics. SID,SERIAL# are still required somewhere close to REQUEST_ID, as well.
- Developers (both standard and custom functionality) try to organize programs into small pieces of work, and then combine them into a bigger task by submitting many of them as child requests, sometimes hundreds or thousands of requests. This is troublesome in many ways: slow, row-by-row processing, increased concurrency that is not needed most of the time, and large queues which take time to process. As a result, many programs that are supposed to be batch style and fast act as OLTP requests and take more time than necessary.
- Some programs may require post-processing of their results by a separate process - Output Post Processors. Often post-processing is done with XML Publisher's call to convert results into rich text. If a template is complex and is not supposed to handle large outputs (and "large" here may be just a few thousands of rows), OPP processes may be stuck in either continuous Full GC, or simply fail with java.lang.OutOfMemoryError. A workaround for this issue may be an increase of the heap size for OPP process (luckily they are 64-bit, whereas Forms server is running 32-bit still), or avoiding XML Publisher altogether.
