Friday Mar 07, 2014

Oracle VM Virtual Appliances Available for E-Business Suite Release 12.2.3

Oracle VM Virtual Appliances for E-Business Suite Release 12.2.3 are now available from the Oracle Software Delivery Cloud at this location:

 These virtual appliances can be imported into Oracle VM Manager to deploy E-Business Suite Linux 64-bit environments on compatible server-class machines running Oracle VM Server.  Alternatively, they can be imported into Oracle VM VirtualBox to create virtual machines on a desktop PC or laptop.

The virtual appliances deliver the full software stack, including the Oracle Linux 6.5 operating system, Oracle E-Business Suite, and additional required technology components.

The available Oracle E-Business Suite Release 12.2.3 virtual appliances are:

  1. Single Node VISION Demo
  2. VISION Demo Database Tier
  3. Production (PROD) Database Tier
  4. Application Tier
  5. Sparse Application Tier

These appliances can be used to support the following scenarios:

  • Single node E-Business Suite 12.2.3 installation: Choose the single node VISION Demo virtual appliance (Option 1 above) to create a unified virtual machine with the EBS 12.2.3 database and application tiers.
  • Multi-node E-Business Suite 12.2.3 installation: Create a multi-node system using the database virtual appliance of choice (either VISION or PROD) and the application tier virtual appliance. That is, Option 2 or 3 above, followed by Option 4.  You can then add secondary application tiers using Option 5.
  • Operating system-only installation (Oracle Linux 6.5): The sparse application tier virtual appliance (Option 5) includes the necessary operating system packages, kernel parameter settings, and users (oracle and applmgr) required to install Oracle E-Business Suite, providing benefit for customers who plan to use Rapid Install for their 12.1.3 or 12.2.3 installation.

Related Articles

Thursday May 09, 2013

Configuring Integrated SOA Gateway in Multinode EBS Environments

The E-Business Suite's three-tier architecture consists of application tier services such as Web Application Services (oacore, oafm, Forms), Web Entry Point Services, Batch Processing Services, Root Services and database tier processes and data. A node represents a physical server with a set of processes. When application and database processes are distributed across multiple servers, it is called a multi-node installation. Generally, a hardware load-balancer is used to distribute EBS traffic between multiple nodes.

Load-balanced multi-node EBS environment

Oracle E-Business Suite Integrated SOA Gateway (ISG) provides a SOA-based infrastructure to provide and consume web service in EBS. The Integrated SOA Gateway can be configured for use in multi-node EBS environments; see:

Configuring Oracle E-Business Suite Integrated SOA Gateway Release 12.1.2 and Release 12.1.3 in a Multinode Environment (Note 1081100.1)

This document's steps for web service generation and deployment in multi-node environments should be followed for each EBS Public API exposed as web service.

How to set up Integrated SOA Gateway in multi-node environment

Service Provider:  ISG generates web service artifacts and stores them in the Instance Home (INST_TOP). Regardless of whether a shared file system is used in EBS multi-node installation, ISG’s Service Provider should be configured to synchronize web service artifacts across all EBS application tier nodes.

Service Invocation Framework:  ISG stores metadata about the web service to be invoked in database tables. However, if the target web service resides outside a corporate firewall, then you need to ensure that the EBS host has access to WSDL and target web service endpoints required for sending SOAP requests. This requires setting up Proxy Host and Port at appropriate EBS application tiers; see the "Setup Tasks" section in Chapter 9 in this guide:

Oracle E-Business Suite Integrated SOA Gateway Implementation Guide [Part E12169-06].

Proxy Host and Port setup should be done for each node in a multi-node environment.


Related Articles

Friday Jul 13, 2012

Five Errors Customers Make When Installing E-Business Suite 12 (Part 1)

One customer recently asked if we could supply documentation and scripts to remove all the E-Business Suite objects from their database leaving them with an empty database. After a few questions, it became apparent they were concerned about performance and a third party consulting organisation had advised the best solution to performance problems was to export and then import the whole database.

Whilst it’s true an export/import might solve performance problems, there are many other things you can do before you conclude the best solution is an export/import; it’s certainly not the default solution. That’s a pretty extreme example but there are quite a few myths and misunderstandings which seem to crop up regularly in Service Requests.

This is the first in a series of short articles that lists a few of the technical myths or misunderstandings about Oracle E-Business Suite. Other articles have covered cloning, patching, migrations, upgrades, and maintenance. This first article discusses installations.

Each article is absolutely not definitive and I’d be particularly interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.

COMMON ERROR #1: In a global implementation, putting your database tier host in your global data centre and putting local application tier hosts in each country.

ORACLE’S RECOMMENDATION: You must put all host nodes of your E-Business Suite environment in one data centre with the fastest possible network connection between nodes. This applies regardless of the location of your users.

COMMON ERROR #2: Placing concurrent processing services and the database tier on the same node to improve performance.

ORACLE’S RECOMMENDATION: There is no significant performance benefit to placing concurrent processing and the database tier on the same node. Your system will be more scalable if your database tier hardware is dedicated solely to serving the needs of the database. Patching, cloning and E-Business Suite administration will also be much easier as you will have at least one less APPL_TOP and application tier technology stack to maintain. Placing concurrent processing on the database tier node to distribute load might suggest that your application tier hardware is already undersized. You should place concurrent processing on the same nodes as your web/forms services or create a dedicated concurrent processing tier in exceptionally busy environments.

COMMON ERROR #3: Installing only the default database character set although you know that you will need a different character set later.

ORACLE’S RECOMMENDATION: Failing to consider national language support (NLS) and database character set requirements when installing a new environment is a critical mistake. You should normally have a very good idea of language requirements before you start your installation. Implement the correct languages and database character set when you perform your installation. Characters sets can be changed later and languages can also be added but if you think you are going to need them then implement them early in your project. Realising that you have forgotten the purchasing team in Denmark the day before you go live will not make you a popular DBA.

You cannot specify a different character set when upgrading to R12. The R12 upgrade process cannot do a character set conversion.

COMMON ERROR #4: Separating Oracle database and application tier ownership by different operating system users/groups.

ORACLE’S RECOMMENDATION: In simple single node installations the whole E-Business Suite file system (including the database) can be owned by a single user/group. This can simplify installation and maintenance. Oracle documentation and Oracle Support engineers sometimes refer to the ‘applmgr’ user and the ‘oracle’ user. These are generic terms used loosely to describe the operating system owner of the application and database tier file systems respectively – they are not mandatory user names. It is also not mandatory to perform E-Business Suite installations as the root user.

COMMON ERROR #5: Before retrying a failed installation, forgetting to remove its entries from the central inventory.

ORACLE’S RECOMMENDATION: When deleting an E-Business Suite environment, in addition to shutting down and deleting files, you must also remove its entries from the central inventory. The central inventory is a file based repository of all Oracle homes installed on a node. This central inventory may exist outside the E-Business Suite file system and is not always removed when you remove the E-Business Suite file system. If the central inventory contains entries for previously deleted E-Business Suite environments then subsequent new installations may fail.


Related Articles



« July 2016