Avoid Mixing Custom Applications with E-Business Suite Environments

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.

EBS 12.1 technology stack architecture

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:

  • You can't drop a new UIX library into an EBS environment without also delivering the corresponding changes in the OA Framework layer.
  • You can't simply replace the E-Business Suite's Oracle Forms and Reports 10g with, say, Oracle Forms and Reports 11g. 

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:

  • You can optionally integrate Oracle Business Intelligence Enterprise Edition with your EBS environment to offer advanced analytic capabilities.
  • You can optionally use Oracle Access Manager and Oracle Internet Directory if you'd like to integrate the E-Business Suite with a third-party authentication system.
External integrations (e.g. OBIEE, Oracle Access Manager, Discoverer) are loosely-coupled.  For example, applying the Discoverer 11.1.1.6 patchset won't trigger changes to EBS products that deliver Discoverer workbooks. Some small interoperability patches required, but you can generally upgrade externally-integrated Oracle products without significant changes to E-Business Suite technology stack components or product level code. 

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:

  • Makes it difficult to debug or isolate EBS performance or stability issues.
  • Increases your security risk.  If your custom application is compromised, then your EBS environment may also be jeopardized, or vice versa.
  • Makes it difficult to upgrade EBS components if your custom application is dependent on older versions.
  • Makes it difficult to upgrade your custom application if the E-Business Suite is dependent on older component versions than your custom code.
  • Potentially doubles your maintenance outages for your users. Your EBS environment will be taken down every time you need to apply an update to your custom application, and vice versa.

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.

Related Articles

Comments:

I agree completely that deploying custom code into the EBS tech stack is a bad idea. Not something I'd ever consider due to the potential issues you outlined above.

I do, however, think that licensing is an important consideration when choosing between the two options in the "what you should do" section.

Any customised EBS env (and there are, in my experience, very few that aren't customised in any way) will be required to have Application Server licenses. Therefore installing a 2nd AS on the same server as the EBS should NOT require additional licenses to be purchased.

Posted by Des Collins on February 27, 2013 at 09:11 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Search

Categories
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today