The E-Business Suite technology stack is extensive. Many components are distributed across the EBS database and application tiers. These include the Oracle Database, Oracle HTTP Server, Oracle Forms and Reports 10g, Oracle Containers for Java, and many others.
Internal EBS components are tightly-coupled
Most of these components are not "user-serviceable" in the conventional manner. They're tightly integrated with the E-Business Suite, with deep dependencies, custom configuration files, and dedicated configuration management utilities that are designed specifically for the E-Business Suite.
The internal E-Business Suite technology stack is relatively tightly-coupled: you generally cannot change one thing without understanding how those changes will affect other components.
Examples of what this means:
External integrations are loosely-coupled
It is also possible to integrate the E-Business Suite with other
Oracle products. These integrations are optional, in the sense that you
don't need them to use the core E-Business Suite functionality. These are sometimes called external integrations since they're outside of the core EBS technology stack.
Examples of external integrations:
Before you upgrade internal and external components
You should always check that newer versions of internal and external components are certified before upgrading them. We release around 80 new certified component updates a year, comprising over 150 configurations. Monitoring or subscribing to this blog is the best way of keeping up.
The official Certification database on My Oracle Support is the definitive source of all EBS certifications. I've also published a one-page summary of all of the latest E-Business Suite techstack certifications on this blog.
What does this mean for custom applications?
You might be tempted to deploy a custom application in the E-Business Suite technology stack. After all, you think to yourself, that's easier than installing a separate server for, say, OC4J.
Don't do it.
The E-Business Suite internal technology stack should be reserved strictly for the E-Business Suite. Mingling your own custom applications into the E-Business Suite technology stack:
What you should do
Option 1: Deploy on a separate server
Ideally, you should install your custom application and its required technology stack prerequisites on a different physical server. This will ensure that the E-Business Suite remains completely isolated from your custom application, its technical requirements, and its load requirements. This is the recommended approach.
Option 2: Deploy in a separate ORACLE_HOME on an EBS server
Less ideally, you can install your custom application in a different ORACLE_HOME on an existing E-Business Suite server.
This is not recommended. There are a number of downsides to this approach:
- If your custom application's security is compromised, this might put your E-Business Suite environment at risk.
- Deploying your custom application and its components on your EBS server will make performance tuning difficult. If your server's resources are maxed out, how do you determine whether the problem lies with EBS or your custom application?
- A single point of failure: server maintenance or outages take down all applications that share that server. Physical consolidation saves money but increases risk.
Implications for support
Here's the biggest reason not to mix EBS environments with custom applications: it makes support very difficult, if not impossible.
Oracle can best assist with issues that we can reproduce. We can issue EBS patches only for issues that can be reproduced on standard EBS environments.
If a problem occurs in an E-Business Suite environment that includes other uncertified components or code, then our default recommendation will be to disable those before investigating further.