Oracle R12 E-Business Suite Architecture
Business Architecture: The R12 EBS has 5 principles that drives its business architecture:
-Modern Foundation
-Complete
-End to end Intergration
-Global
-Rapid Implementation.
1. Oracle has embedded all of its new R12 development into open, scalable standards. These standards include using Java/J2EE, HTML, JavaScript (JSP), Internet-accessibility, and centralized management.
2. R12 E-Business Suite is accessible via global networks. It accommodates multiple languages and currencies; supports international features, such as flexible date formats and multiple radix support; supports data in the Unicode Character Set (UTF-8) and has accounting and business localizations built into it.
The Oracle E-Business Suite Architecture is a framework for multi-tiered, distributed computing that supports Oracle E-Business Suite products. In this model, various servers or services are distributed among three levels, or tiers.
A server (or services) is a process or group of processes that runs on a single machine and provides a particular functionality. For example, Web services process HTTP requests, and Forms services process requests for activities related to Oracle Forms. The Concurrent Processing server supports data-intensive programs that run in the background.
Important: The term server, in the sense of a single process, is less appropriate in the Release 12 architecture. Where applicable, replacement terms such as services are used.
A tier is a logical grouping of services, potentially spread across more than one physical machine. The three-tier architecture that comprises an Oracle E-Business Suite installation is made up of the database tier, which supports and manages the Oracle database; the application tier, which supports and manages the various Oracle E-Business Suite components, and is sometimes known as the middle tier; and the desktop tier, which provides the user interface via an add-on component to a standard web browser.
A machine may be referred to as a node, particularly in the context of a group of computers that work closely together in a cluster. Each tier may consist of one or more nodes, and each node can potentially accommodate more than one tier. For example, the database can reside on the same node as one or more application tier components. Note, however, that a node is also a software concept, referring to a logical grouping of servers.
Centralizing the Oracle E-Business Suite software on the application tier eliminates the need to install and maintain application software on each desktop client PC, and also enables Oracle E-Business Suite to scale well with an increasing load. Extending this concept further, one of the key benefits of using the Shared Application Tier File System model (originally Shared APPL_TOP) is the need to maintain only a single copy of the relevant Oracle E-Business Suite code, instead of a copy for every application tier machine.
On the database tier, there is increasing use of Oracle Real Application Clusters (Oracle RAC) , where multiple nodes support a single database instance to give greater availability and scalability.
Figure 1-1 Oracle E-Business Suite Architecture
The connection between the application tier and the desktop tier can operate successfully over a Wide Area Network (WAN). This is because the desktop and application tiers exchange a minimum amount of information, for example only field values that have changed. In a global operation with users at diverse locations, requiring less network traffic reduces telecommunications costs and improves response times.
The Desktop Tier
The client interface is provided through HTML for HTML-based applications, and via a Java applet in a Web browser for the traditional Forms-based applications.
Figure 1-2 Forms-based Desktop Tier Architecture
You log in via the Oracle E-Business Suite Home Page on a desktop client web browser. The Home Page provides a single point of access to HTML-based applications, Forms-based applications, and Business Intelligence applications.
Once successfully logged in via the E-Business Suite Home Page, you are not prompted for your user name and password again, even if you navigate to other tools and products. Oracle E-Business Suite also retains preferences as you navigate through the system. For example, if you registered in the Home Page that German is your preferred language, this preference carries over whether you access Forms-based or HTML-based applications.
Forms
Client Applet
The Forms client applet is a general-purpose presentation applet that supports all Oracle E-Business Suite Forms-based products, including those with customizations and extensions. The Forms client applet is packaged as a collection of Java Archive (JAR) files. The JAR files contain all Java classes required to run the presentation layer of Oracle E-Business Suite forms.
Desktop Java Client
The Forms client applet must run within a Java Virtual Machine (JVM) on the desktop client. The Sun JRE Plug-in component allows use of the Oracle JVM on web clients, instead of the browser's own JVM. This component is implemented as a standard browser plug-in.
In the traditional, Forms-based Oracle E-Business Suite environment, the JVM was run as part of the standard Oracle E-Business Suite sign-on process. Now, the JVM (JRE Plug-in in Release 12) is only invoked when a user chooses to access functions that require it, such as running a form. If the JRE Plug-in has not been installed, the browser prompts the user to download the required installation executable.
After you download and install the plug-in, you will be able to run Forms-based applications, for example as shown in Figure 1-4.
Figure 1-4 Forms-based Oracle E-Business Suite interface
The Forms client applet and commonly used JAR files are downloaded from the Web server at the beginning of the client's first session. Less commonly used JAR files are downloaded as needed. All downloaded JAR files are cached locally on the client, ready for future sessions. This eliminates the network traffic that would be involved in downloading them whenever they were required.
In Release 12, the cache directory path is of the form:
<HOMEDRIVE>\Documents and Settings\<Windows User Name>\Application Data\Sun\Java\Deployment\cache
For example:
C:\Documents and Settings\jalee\Application Data\Sun\Java\Deployment\cache
Selecting "Show console" on the "Advanced" tab of the JRE Plug-in control panel will allow you to observe downloading of JAR files, to confirm they are being downloaded when they should be. The Java console is shown in Figure 1-5.
Figure 1-5 Java Console
All updates to JAR files are installed on the application tier and downloaded to the client automatically, via the caching mechanism outlined above.
Note: For further details of using the Sun JRE Native Client with Oracle E-Business Suite, see My Oracle Support Knowledge Document 393931.1, Upgrading JRE Plugin with Oracle Applications R12.
The Application Tier
The application tier has a dual role: hosting the various servers and service groups that process the business logic, and managing communication between the desktop tier and the database tier. This tier is sometimes referred to as the middle tier.
Three servers or service groups comprise the basic application tier for Oracle E-Business Suite:
In Release 12, Web and Forms services are provided by Oracle Application Server (OracleAS) 10g. They are no longer servers in the sense of being a single process, as was the case in previous Applications releases.
Note: There is no concept of an Administration server in Release 12. By default, patching can be undertaken from any application tier node.
It is advisable to avoid using a mixture of different platforms on your application tier. This makes maintenance easier, since only one set of patches needs to be downloaded.
Load Balancing
The application tier supports load balancing among many of its servers and services to help provide higher availability, fault tolerance, reliability, and optimal scalability. If you have more than one of any of the following types of server, load balancing can be employed:
Chapter 10 discusses the various types of load balancing in more detail.
Use of
Two Oracle Application Server ORACLE_HOMEs in Release 12
Two different Oracle Application Server (OracleAS) 10g releases, in separate ORACLE_HOMEs, are used in Oracle E-Business Suite Release 12. This enables Oracle E-Business Suite to take advantage of the latest Oracle technologies.
Figure 1-6 illustrates the functional usage of the two Oracle Application Server ORACLE_HOMEs.
Figure 1-6 Relationship between the two Application Server ORACLE_HOMEs
Notable features of this architecture include:
Figure 1-7 illustrates the relationship of the two Application Server ORACLE_HOMEs and the database ORACLE_HOME.
Figure 1-7 Database and Oracle Application Server ORACLE_HOMEs
Notable features of this high-level architecture include:
Web Services
The Web services component of Oracle Application Server processes requests received over the network from the desktop clients, and includes the following components:
The Web listener component of the Oracle HTTP server accepts incoming HTTP requests (for particular URLs) from client browsers, and routes the requests to the appropriate OC4J container.
If possible, the Web server services the requests itself, for example by returning the HTML to construct a simple Web page. If the page referenced by the URL needs advanced processing, the listener passes the request on to the servlet engine, which contacts the database server as needed.
HTML-Based
Applications and the Oracle Application Framework
The Oracle HTML-based applications (originally known as Self-Service applications) have the following characteristics:
The Oracle Application Framework is the development platform for HTML-based applications. It consists of a Java-based application tier framework and associated services, designed to facilitate the rapid deployment of HTML-based applications.
Notable Oracle Application Framework components include:
The Framework-based applications logic is controlled by procedures that execute through the Java servlet engine, which is provided by the Apache JServ module. The servlet engine uses the metadata dictionary in constructing the Framework UI.
Figure 1-8 HTML-Based Applications Architecture
Java Servlet Access with HTML-Based Applications
An HTML-based Applications module uses the following access path:
Figure 1-9 Oracle Application Framework Architecture
Oracle
Application Framework Processing Details
The following is a more detailed explanation of how the JSP obtains the content from the Oracle E-Business Suite tables and uses information from the metadata dictionary to construct the HTML page.
Forms Services
By default, Forms services in Oracle E-Business Suite Release 12 are provided by the Forms listener servlet, which, as described further below, facilitates the use of firewalls, load balancing, proxies, and other networking options.
Benefits of using the Forms listener servlet include:
Forms
Listener Servlet Architecture
The Forms listener servlet is a Java servlet that delivers the ability to run Oracle Forms applications over HTTP or HTTPS connections. It hosts the Oracle E-Business Suite forms and associated runtime engine, mediating the communication between the desktop client and the Oracle database server, displaying client screens, and initiating changes in the database according to user actions.
The Forms listener servlet caches data and provides it to the client as needed, for example when scrolling through multiple order lines that exceed the limitations of a single screen.
The Forms listener servlet can communicate with the desktop client using either a standard HTTP network connection or secure HTTPS network connection. In contrast, Forms services (formerly known as Forms server) communicates with the desktop client using the TCP/IP network protocol, on top of which it layers its own protocol.
The Forms listener servlet communicates with the Oracle database server using the Oracle Net networking infrastructure.
The Forms listener servlet manages the creation of a Forms runtime process for each client, as well as network communications between the client and its associated Forms runtime process. The client sends HTTP requests and receives HTTP responses from the Web services, which acts as the network endpoint for the client.
Note: Although the OC4J-Forms instance runs out of the OracleAS 10.1.3 ORACLE_HOME, the frmweb executable is invoked out of the OracleAS 10.1.2 ORACLE_HOME.
Forms
Socket Mode Architecture
In the traditional Forms server socket mode architecture, when a user initiates an action in the Forms client applet (such as entering data into a field or clicking a button), data is passed to a Forms server on the application tier. The user interface logic runs in the Forms server, and determines the appropriate user interface effect based on the user's action. For example, a window may open, or another field value may be populated. If necessary, the database tier is contacted for any data not already cached on the application tier, or for data-intensive processing.
Figure 1-10 Forms Socket Mode
Once a connection has been made, many operations can be performed with little or no further interaction with the Forms server. For example, when a few field values change in response to a user action, there is no need to update the entire screen. In this scenario, only the changed fields are updated with the new values.
Choice of
Mode
As stated, by default Oracle E-Business Suite Release 12 utilizes Forms listener servlet mode. However, socket mode is still supported, and may be useful in high-latency, bandwidth-constrained WAN environments.
Note: For more details of utilizing Forms Socket Mode, see My Oracle Support Knowledge Document 384241.1, Using Forms Socket Mode with Oracle E-Business Suite Release 12.
Java APIs
for Forms
Building on top of Oracle Fusion Middleware and service-oriented architecture (SOA) technology, Oracle E-Business Suite Integrated SOA Gateway (ISG ) provides a robust communication and integration infrastructure between independently managed components and loosely coupled applications. This promotes more effective integration between heterogeneous applications, and facilitates the development and execution of complex business processes into flexible and reusable Web services. With this standardized Web service platform, Oracle E-Business Suite Integrated SOA Gateway provides a framework that efficiently supports service integration between Web applications.
Within this integration environment, Java APIs for Forms are XML document-based integration points wrapped in Java classes, and used to execute business logic in Oracle Forms. These specialized Java classes are categorized as a subtype of Java interface, and can be service-enabled through SOA Provider.
Note: For further details of Java APIs and Web services, see Oracle E-Business Suite Integrated SOA Gateway User's Guide, Development Guide, and Implementation Guide in the Oracle E-Business Suite Documentation Library.
A new OC4J container, forms-c4ws, enables business logic contained within Oracle Forms to be exposed as Web services. As this container handles registration, generation, deployment, security and execution of Forms services, clients see the end-point alone, without even having to be aware that Forms is the source.
Note: For further details of deploying the forms-c4ws container, see section Configuring Oracle E-Business Suite Integrated SOA Gateway Release 12.1.2 of My Oracle Support Knowledge Document 556540.1, Installing Oracle E-Business Suite Integrated SOA Gateway, Release 12.
Concurrent Processing Server
As described previously, user interactions with Oracle E-Business Suite data can be conducted via HTML-based applications or the more traditional Forms-based applications. However, there are also reporting programs and data updating programs that need to run either periodically, or on an ad hoc basis. These programs, which run in the background while users continue to work on other tasks, may require a large number of data-intensive computations, and are run using the Concurrent Processing architecture. Concurrent Processing is an Oracle E-Business Suite feature that allows these non–interactive and potentially long-running functions to be executed efficiently alongside interactive operations. It uses operating system facilities to enable background scheduling of data- or resource-intensive jobs, via a set of programs and forms.To ensure that resource-intensive concurrent processing operations do not interfere with interactive operations, they are run on a specialized server, the Concurrent Processing server.
Processes that run on the Concurrent Processing server are called concurrent requests. When you submit such a request, either through HTML-based or Forms-based applications, a row is inserted into a database table specifying the program to be run. A concurrent manager then reads the applicable requests in the table, and starts the associated concurrent program.
Concurrent Manager Characteristics
Concurrent managers are fundamental to concurrent processing. Acting as a job scheduling and execution system, a concurrent manager:
Specialist Concurrent Managers As well as the general-purpose concurrent managers described in the previous section, there are a number of specialized concurrent managers.
The Internal Concurrent Manager (ICM) controls all other concurrent managers. It administers the startup and shutdown of managers as defined by their work shift, monitors for process failure, and cleans up if a failure occurs. The ICM does not process concurrent requests itself (except for queue control requests, such as ACTIVATE, DEACTIVATE, or ABORT).
While the basic ICM definition should not be changed, you can if required modify the sleep time (number of seconds the ICM waits between checking for new concurrent requests), PMON (process monitor) cycle time (number of sleep cycles the ICM waits between checking for failed workers), and queue size (duration between checks for number of active workers, measured in PMON cycles). If Parallel Concurrent Processing (described below) is being used, you can also set some options for this.
The Conflict Resolution Manager (CRM) enforces rules designed to ensure that incompatible concurrent requests do not run in the same conflict domain (an abstract representation of the groupings used to partition data). As with the Internal Concurrent Manager, the basic CRM definition should not be changed, but you can modify the sleep time for each work shift, as well as some Parallel Concurrent Processing options.
The Standard Manager as shipped with Oracle E-Business Suite will accept and run any concurrent requests, as it has no specialization rules that would restrict its activities. Consequently, the definition of the Standard Manager should not be altered without careful planning, otherwise some programs might not be able to run at all. Jobs should only be excluded from the Standard Manager after ensuring they can be run by an alternative manager, such as a product-specific manager or user-defined manager.
Transaction Managers support synchronous request processing, whereby a pool of server processes responds to requests from client programs. Instead of polling the concurrent requests table to obtain instructions, a transaction manager waits to be signaled by a client. An example is approval of an order, where execution of the request must take place quickly.
The relevant transaction manager program runs on the server, transparently to the client. All transaction programs for a given manager process run in the same database session. Communication between the client and the server is conducted synchronously via Advanced Queueing. At the end of program execution, the client program receives a completion message and a return value, for example denoting approval of the order. This strategy of using non-persistent connections between the client and Transaction Manager processes enables a small pool of server processes to service a large number of clients with near real-time response.
Setting Up Concurrent Managers
The Oracle E-Business Suite System Administrator’s Guide gives full details of the steps and options involved in setting up and monitoring concurrent managers. Some of the key steps include:
Tip: It is easier to identify the optimum number of workers by being conservative initially, and defining additional workers later if needed (subject to availability of system resources).
Multiple managers can be run on multiple nodes using Parallel Concurrent Processing, as described below.
Concurrent Processing Architecture
In Concurrent Processing, programs are run as operating system background processes. These programs may be written using a variety of Oracle tools, programming languages for executables, or the host operating system scripting language.
As noted above, a concurrent program that runs in the concurrent manager's own operating system process is known as an immediate program. Immediate programs run as a function within the concurrent manager’s program library. Examples include PL/SQL programs. In contrast, a concurrent program that runs in a child process of the concurrent manager process is known as a spawned program. Examples include SQL programs, SQL Loader programs, Oracle Reports programs, spawned C programs, and host language programs such as UNIX shell scripts or Windows command files.
All reports are run through the Concurrent Processing server manager via the rwrun executable, which spawns an in-process server. This is in contrast to earlier releases of Oracle E-Business Suite, which used the now-obsolete Reports server.
While C programs can be run as immediate programs, it is advisable to run them as spawned programs. This simplifies maintenance, without introducing any disadvantages.
A concurrent request has a life cycle, which consists of three or possibly four phases:
A concurrent program library contains concurrent programs that can be called by a concurrent manager. An important example is the Oracle Application Object Library program library (FNDLIBR), which contains Oracle E-Business Suite immediate concurrent programs, and is assigned to the standard concurrent manager. Although each concurrent manager can only run immediate concurrent programs from its own concurrent program library, it can also run spawned or Oracle tool concurrent programs.
Various database tables are employed by the concurrent processing architecture:
Caution: Do not update these tables manually. You can (subject to your organization's archiving requirements) periodically run the "Purge Concurrent Requests and/or manager data" program to prevent these tables growing too large. See the Oracle E-Business Suite System Administrator's Guide for details.
Concurrent Processing Operations
Because the Internal Concurrent Manager controls all the other managers, it must be running before any other manager can be activated. Once the ICM has been activated, it starts a Service Manager on each node that is enabled for concurrent processing. Acting as an agent of the ICM, the Service Manager starts the concurrent managers on its node, excluding any managers that have been deactivated, or that have no current work shift. The ICM can be activated and deactivated from the operating system prompt, or Oracle Applications Manager. It can also be deactivated (but not activated) from the Administer Concurrent Managers form.
When the ICM is initiated on UNIX, the $FND_TOP/bin/startmgr program is invoked. This calls $FND_TOP/bin/batchmgr, which then:
Normally, startmgr is run by the user account that owns the application software (for example, applmgr). This account must have write privileges to the log and out directories where the log and output files respectively are written.
The ICM starts up a Service Manager on each node that is enabled for concurrent processing, by instructing the node's Applications Listener (which is dedicated to Concurrent Processing) to spawn a process running the Service Manager executable (FNDSM). The Applications Listener must be configured to source the Oracle E-Business Suite environment file before FNDSM is spawned. Following startup, the Service Manager acts as an agent of the ICM to start and stop concurrent managers on that node, according to their defined work shifts.
Note: The Service Manager is a component of the Generic Service Management (GSM) architecture rather than Concurrent Processing, although GSM and Concurrent Processing are closely integrated.
Concurrent manager processes on a specific node can be seen by running the UNIX commands:
ps –ef | grep FNDLIBR
ps –ef | grep FNDSM
The Service Manager PID seen in the output of the second command can then, if desired, be used to locate all concurrent manager and service processes on the node, since the Service Manager is the parent process for them:
ps –ef | grep <sm_pid>
On Windows, the Task Manager can be used to locate concurrent manager processes. An FNDLIBR process runs for the Internal Concurrent Manager and each standard manager. The ICM can be distinguished by additional details being displayed, including some of the parameters it was started with.
For every process that was successfully started at operating system level, the ICM inserts a row into FND_CONCURRENT_PROCESSES. It then updates the RUNNING_PROCESSES column to reflect the actual running processes as shown in FND_CONCURRENT_QUEUES.
Viewing Concurrent Processing Output
The output from a concurrent processing job goes through several stages before being displayed to the user.
Figure 1-11 Viewing Concurrent Processing Output
You can cater for your network capacity and report volume by using profile options to specify the maximum size of the files and pages that can be passed through the system.
Parallel Concurrent Processing
Parallel Concurrent Processing (PCP) allows concurrent processing activities to be distributed across multiple nodes in an Oracle Real Application Clusters (Oracle RAC) environment or similar cluster system. By distributing concurrent processing in this way, hardware resources can be fully utilized, maximizing throughput and providing resilience to node failure, while retaining a central point of control.
Parallel Concurrent Processing enables you to:
One or more concurrent managers can be specified to run on one or more nodes, to best suit your processing needs and fully utilize available hardware resources.
Parallel Concurrent Processing is enabled by default, so PCP is always available for use in environments where one or more concurrent processing nodes exist.
Note: PCP does not require an Oracle RAC environment. Conversely, you do not have to use PCP in an Oracle RAC environment, although it typically makes sense to do so.
Managing Concurrent Processing
From the command line, two commands can be entered to control the Internal Concurrent Manager: startmgr, which starts the ICM; and concsub, which is used to stop or abort the ICM, or request the ICM to check on the operating system process for each manager. In addition, an AutoConfig-enabled environment provides a number of scripts for starting and stopping application tier services from the command line. The script for concurrent processing startup and shutdown is INST_TOP/admin/scripts/adcmctl.sh.
The various components of the concurrent processing system can be managed from various forms, such as Concurrent Manager: Administer, or from Concurrent Managers or Concurrent Requests under Oracle Applications Manager (OAM).
Note: For details of setting up and managing concurrent processing, see Oracle System Administrator's Guide - Configuration, Chapter 7.
Application Tier Administration
In Oracle E-Business Suite Release 12, any application tier node can be used to carry out the following operations:
The concept of an Administration server is a historical one, and does not exist in Oracle E-Business Suite Release 12.
The Database Tier
The database tier contains the Oracle database server that stores and manages all the data maintained by Oracle E-Business Suite. This includes the various types of file in which the tables, indexes, and other database objects for your system physically reside, as well as the database executables. The database also stores the Oracle E-Business Suite online help information.
The database server communicates with the services and servers on the application tier, which mediate the communications between the database and the clients: there is no direct communication between the database and clients.
Using a
Mixed Platform Architecture
The Oracle database server is sometimes available on platforms where Oracle E-Business Suite is not currently certified. In such a case, it may be possible to utilize a mixed platform architecture, where the database is installed on one platform and the application tier on another. (In Release 11i, this was referred to as a split configuration.)
This type of deployment can enable the database to utilize the specific features offered by a particular platform (such as a 64-bit architecture). It can also allow the application tier to be managed in a more cost-effective way.
Note: For up-to-date details of Release 12 support with mixed platform architectures, see Certify on My Oracle Support.
The Oracle E-Business Suite Technology
Layer
The Oracle E-Business Suite technology layer lies between the Oracle E-Business Suite technology stack and the Oracle E-Business Suite product-specific modules. It provides features common to all Oracle E-Business Suite products.
Products in the Oracle E-Business Suite technology layer include:
Business Architecture: The R12 EBS has 5 principles that drives its business architecture:
-Modern Foundation
-Complete
-End to end Intergration
-Global
-Rapid Implementation.
1. Oracle has embedded all of its new R12 development into open, scalable standards. These standards include using Java/J2EE, HTML, JavaScript (JSP), Internet-accessibility, and centralized management.
2. R12 E-Business Suite is accessible via global networks. It accommodates multiple languages and currencies; supports international features, such as flexible date formats and multiple radix support; supports data in the Unicode Character Set (UTF-8) and has accounting and business localizations built into it.
·
The
Desktop Tier
·
The
Application Tier
·
The
Database Tier
·
The
Oracle E-Business Suite Technology Layer
·
Oracle
Configuration Manager
·
Oracle
E-Business Suite Patch Nomenclature
The Oracle E-Business Suite Architecture is a framework for multi-tiered, distributed computing that supports Oracle E-Business Suite products. In this model, various servers or services are distributed among three levels, or tiers.
A server (or services) is a process or group of processes that runs on a single machine and provides a particular functionality. For example, Web services process HTTP requests, and Forms services process requests for activities related to Oracle Forms. The Concurrent Processing server supports data-intensive programs that run in the background.
Important: The term server, in the sense of a single process, is less appropriate in the Release 12 architecture. Where applicable, replacement terms such as services are used.
A tier is a logical grouping of services, potentially spread across more than one physical machine. The three-tier architecture that comprises an Oracle E-Business Suite installation is made up of the database tier, which supports and manages the Oracle database; the application tier, which supports and manages the various Oracle E-Business Suite components, and is sometimes known as the middle tier; and the desktop tier, which provides the user interface via an add-on component to a standard web browser.
A machine may be referred to as a node, particularly in the context of a group of computers that work closely together in a cluster. Each tier may consist of one or more nodes, and each node can potentially accommodate more than one tier. For example, the database can reside on the same node as one or more application tier components. Note, however, that a node is also a software concept, referring to a logical grouping of servers.
Centralizing the Oracle E-Business Suite software on the application tier eliminates the need to install and maintain application software on each desktop client PC, and also enables Oracle E-Business Suite to scale well with an increasing load. Extending this concept further, one of the key benefits of using the Shared Application Tier File System model (originally Shared APPL_TOP) is the need to maintain only a single copy of the relevant Oracle E-Business Suite code, instead of a copy for every application tier machine.
On the database tier, there is increasing use of Oracle Real Application Clusters (Oracle RAC) , where multiple nodes support a single database instance to give greater availability and scalability.
Figure 1-1 Oracle E-Business Suite Architecture
The connection between the application tier and the desktop tier can operate successfully over a Wide Area Network (WAN). This is because the desktop and application tiers exchange a minimum amount of information, for example only field values that have changed. In a global operation with users at diverse locations, requiring less network traffic reduces telecommunications costs and improves response times.
The Desktop Tier
The client interface is provided through HTML for HTML-based applications, and via a Java applet in a Web browser for the traditional Forms-based applications.
Figure 1-2 Forms-based Desktop Tier Architecture
You log in via the Oracle E-Business Suite Home Page on a desktop client web browser. The Home Page provides a single point of access to HTML-based applications, Forms-based applications, and Business Intelligence applications.
Once successfully logged in via the E-Business Suite Home Page, you are not prompted for your user name and password again, even if you navigate to other tools and products. Oracle E-Business Suite also retains preferences as you navigate through the system. For example, if you registered in the Home Page that German is your preferred language, this preference carries over whether you access Forms-based or HTML-based applications.
Forms
Client Applet
The Forms client applet is a general-purpose presentation applet that supports all Oracle E-Business Suite Forms-based products, including those with customizations and extensions. The Forms client applet is packaged as a collection of Java Archive (JAR) files. The JAR files contain all Java classes required to run the presentation layer of Oracle E-Business Suite forms.
Desktop Java Client
The Forms client applet must run within a Java Virtual Machine (JVM) on the desktop client. The Sun JRE Plug-in component allows use of the Oracle JVM on web clients, instead of the browser's own JVM. This component is implemented as a standard browser plug-in.
In the traditional, Forms-based Oracle E-Business Suite environment, the JVM was run as part of the standard Oracle E-Business Suite sign-on process. Now, the JVM (JRE Plug-in in Release 12) is only invoked when a user chooses to access functions that require it, such as running a form. If the JRE Plug-in has not been installed, the browser prompts the user to download the required installation executable.
After you download and install the plug-in, you will be able to run Forms-based applications, for example as shown in Figure 1-4.
Figure 1-4 Forms-based Oracle E-Business Suite interface
The Forms client applet and commonly used JAR files are downloaded from the Web server at the beginning of the client's first session. Less commonly used JAR files are downloaded as needed. All downloaded JAR files are cached locally on the client, ready for future sessions. This eliminates the network traffic that would be involved in downloading them whenever they were required.
In Release 12, the cache directory path is of the form:
<HOMEDRIVE>\Documents and Settings\<Windows User Name>\Application Data\Sun\Java\Deployment\cache
For example:
C:\Documents and Settings\jalee\Application Data\Sun\Java\Deployment\cache
Selecting "Show console" on the "Advanced" tab of the JRE Plug-in control panel will allow you to observe downloading of JAR files, to confirm they are being downloaded when they should be. The Java console is shown in Figure 1-5.
Figure 1-5 Java Console
All updates to JAR files are installed on the application tier and downloaded to the client automatically, via the caching mechanism outlined above.
Note: For further details of using the Sun JRE Native Client with Oracle E-Business Suite, see My Oracle Support Knowledge Document 393931.1, Upgrading JRE Plugin with Oracle Applications R12.
The Application Tier
The application tier has a dual role: hosting the various servers and service groups that process the business logic, and managing communication between the desktop tier and the database tier. This tier is sometimes referred to as the middle tier.
Three servers or service groups comprise the basic application tier for Oracle E-Business Suite:
·
Web
services
·
Forms
services
·
Concurrent
Processing server
In Release 12, Web and Forms services are provided by Oracle Application Server (OracleAS) 10g. They are no longer servers in the sense of being a single process, as was the case in previous Applications releases.
Note: There is no concept of an Administration server in Release 12. By default, patching can be undertaken from any application tier node.
It is advisable to avoid using a mixture of different platforms on your application tier. This makes maintenance easier, since only one set of patches needs to be downloaded.
Load Balancing
The application tier supports load balancing among many of its servers and services to help provide higher availability, fault tolerance, reliability, and optimal scalability. If you have more than one of any of the following types of server, load balancing can be employed:
·
Web
services
·
Forms
services
·
Concurrent
Processing server
Chapter 10 discusses the various types of load balancing in more detail.
Use of
Two Oracle Application Server ORACLE_HOMEs in Release 12
Two different Oracle Application Server (OracleAS) 10g releases, in separate ORACLE_HOMEs, are used in Oracle E-Business Suite Release 12. This enables Oracle E-Business Suite to take advantage of the latest Oracle technologies.
Figure 1-6 illustrates the functional usage of the two Oracle Application Server ORACLE_HOMEs.
Figure 1-6 Relationship between the two Application Server ORACLE_HOMEs
Notable features of this architecture include:
·
The
latest version of Oracle Containers for Java (OC4J), the successor to
JServ, is included in Oracle Application Server 10.1.3.
·
All
major services are started out of the OracleAS 10.1.3 ORACLE_HOME.
·
The
Oracle E-Business Suite modules (packaged in the file formsapp.ear) are deployed
into the OC4J-Forms instance running out of the OracleAS 10.1.3
ORACLE_HOME, while the frmweb executable is invoked out of
the Oracle AS 10.1.2 ORACLE_HOME.
Figure 1-7 illustrates the relationship of the two Application Server ORACLE_HOMEs and the database ORACLE_HOME.
Figure 1-7 Database and Oracle Application Server ORACLE_HOMEs
Notable features of this high-level architecture include:
·
The
Oracle Application Server 10.1.2 ORACLE_HOME (sometimes referred to as
the Tools, C, or Developer ORACLE_HOME) replaces the 8.0.6 ORACLE_HOME
provided by Oracle9i Application Server 1.0.2.2.2 in Release 11i.
·
The
Oracle Application Server 10.1.3 ORACLE_HOME (sometimes referred to as
the Web or Java ORACLE_HOME) replaces the 8.1.7-based ORACLE_HOME
provided by Oracle9i Application Server 1.0.2.2.2 in Release 11i.
Web Services
The Web services component of Oracle Application Server processes requests received over the network from the desktop clients, and includes the following components:
·
Web
Listener (Oracle HTTP Server powered by Apache)
·
Java
Servlet Engine (OC4J)
The Web listener component of the Oracle HTTP server accepts incoming HTTP requests (for particular URLs) from client browsers, and routes the requests to the appropriate OC4J container.
If possible, the Web server services the requests itself, for example by returning the HTML to construct a simple Web page. If the page referenced by the URL needs advanced processing, the listener passes the request on to the servlet engine, which contacts the database server as needed.
HTML-Based
Applications and the Oracle Application Framework
The Oracle HTML-based applications (originally known as Self-Service applications) have the following characteristics:
·
Do
not use Oracle Forms for the interface
·
Are
designed in pure HTML and JavaScript
·
Dynamically
generate HTML pages by executing Java code
·
Use
a metadata dictionary for flexible layout
·
Operate
by direct connection to the Web server
The Oracle Application Framework is the development platform for HTML-based applications. It consists of a Java-based application tier framework and associated services, designed to facilitate the rapid deployment of HTML-based applications.
Notable Oracle Application Framework components include:
·
Business Components for Java (BC4J), included in Oracle JDeveloper, is used to create Java business
components for representing business logic. It also provides a mechanism for mapping
relational tables to Java objects, and allows the separation of the
application business logic from the user interface.
·
AOL/J supplies the Oracle
Application Framework with underlying security and applications Java services. It
provides the Oracle Application Framework with its connection to the database,
and with application-specific functionality such as flexfields.
Note: An optional and recommended alternative to AOL/J is the
Oracle Universal Connection Pool (UCP) . For further details, see My Oracle Support Knowledge Document
1077727.1, Using Universal Connection Pool (UCP) in Oracle E-Business Suite
Release 12.1.3.
The Framework-based applications logic is controlled by procedures that execute through the Java servlet engine, which is provided by the Apache JServ module. The servlet engine uses the metadata dictionary in constructing the Framework UI.
Figure 1-8 HTML-Based Applications Architecture
Java Servlet Access with HTML-Based Applications
An HTML-based Applications module uses the following access path:
1.
The
user clicks the hyperlink of a function from a browser.
2.
The
browser makes a URL request to the Web listener.
3.
The
Web listener contacts the Servlet engine (OC4J), where it runs a JSP.
4.
The
JSP obtains the content from the Oracle E-Business Suite tables and uses
information from the metadata dictionary to construct the HTML page.
5.
The
resulting HTML page is passed back to the browser, via the Web server.
Figure 1-9 Oracle Application Framework Architecture
Oracle
Application Framework Processing Details
The following is a more detailed explanation of how the JSP obtains the content from the Oracle E-Business Suite tables and uses information from the metadata dictionary to construct the HTML page.
1.
AOL/J
validates user access to the page.
2.
The
page definition (metadata UI definition) is loaded from the metadata
repository on the database tier into the application tier.
3.
The
BC4J objects that contain the application logic and access the database
are instantiated.
4.
The
Java Controller programmatically manipulates the page definition as
necessary, based on dynamic UI rules.
5.
UIX
(HTML UI Generator) interprets the page definition, creates the
corresponding HTML in accordance with UI standards, and sends the page to the
browser.
Forms Services
By default, Forms services in Oracle E-Business Suite Release 12 are provided by the Forms listener servlet, which, as described further below, facilitates the use of firewalls, load balancing, proxies, and other networking options.
Benefits of using the Forms listener servlet include:
·
Ability
to re-establish dropped network connections
·
Fewer machines and ports need to be exposed at the
firewall
·
Easier firewall/proxy server configuration
·
More
robust and secure deployment over the Internet
Forms
Listener Servlet Architecture
The Forms listener servlet is a Java servlet that delivers the ability to run Oracle Forms applications over HTTP or HTTPS connections. It hosts the Oracle E-Business Suite forms and associated runtime engine, mediating the communication between the desktop client and the Oracle database server, displaying client screens, and initiating changes in the database according to user actions.
The Forms listener servlet caches data and provides it to the client as needed, for example when scrolling through multiple order lines that exceed the limitations of a single screen.
The Forms listener servlet can communicate with the desktop client using either a standard HTTP network connection or secure HTTPS network connection. In contrast, Forms services (formerly known as Forms server) communicates with the desktop client using the TCP/IP network protocol, on top of which it layers its own protocol.
The Forms listener servlet communicates with the Oracle database server using the Oracle Net networking infrastructure.
The Forms listener servlet manages the creation of a Forms runtime process for each client, as well as network communications between the client and its associated Forms runtime process. The client sends HTTP requests and receives HTTP responses from the Web services, which acts as the network endpoint for the client.
Note: Although the OC4J-Forms instance runs out of the OracleAS 10.1.3 ORACLE_HOME, the frmweb executable is invoked out of the OracleAS 10.1.2 ORACLE_HOME.
Forms
Socket Mode Architecture
In the traditional Forms server socket mode architecture, when a user initiates an action in the Forms client applet (such as entering data into a field or clicking a button), data is passed to a Forms server on the application tier. The user interface logic runs in the Forms server, and determines the appropriate user interface effect based on the user's action. For example, a window may open, or another field value may be populated. If necessary, the database tier is contacted for any data not already cached on the application tier, or for data-intensive processing.
Figure 1-10 Forms Socket Mode
Once a connection has been made, many operations can be performed with little or no further interaction with the Forms server. For example, when a few field values change in response to a user action, there is no need to update the entire screen. In this scenario, only the changed fields are updated with the new values.
Choice of
Mode
As stated, by default Oracle E-Business Suite Release 12 utilizes Forms listener servlet mode. However, socket mode is still supported, and may be useful in high-latency, bandwidth-constrained WAN environments.
Note: For more details of utilizing Forms Socket Mode, see My Oracle Support Knowledge Document 384241.1, Using Forms Socket Mode with Oracle E-Business Suite Release 12.
Java APIs
for Forms
Building on top of Oracle Fusion Middleware and service-oriented architecture (SOA) technology, Oracle E-Business Suite Integrated SOA Gateway (ISG ) provides a robust communication and integration infrastructure between independently managed components and loosely coupled applications. This promotes more effective integration between heterogeneous applications, and facilitates the development and execution of complex business processes into flexible and reusable Web services. With this standardized Web service platform, Oracle E-Business Suite Integrated SOA Gateway provides a framework that efficiently supports service integration between Web applications.
Within this integration environment, Java APIs for Forms are XML document-based integration points wrapped in Java classes, and used to execute business logic in Oracle Forms. These specialized Java classes are categorized as a subtype of Java interface, and can be service-enabled through SOA Provider.
Note: For further details of Java APIs and Web services, see Oracle E-Business Suite Integrated SOA Gateway User's Guide, Development Guide, and Implementation Guide in the Oracle E-Business Suite Documentation Library.
A new OC4J container, forms-c4ws, enables business logic contained within Oracle Forms to be exposed as Web services. As this container handles registration, generation, deployment, security and execution of Forms services, clients see the end-point alone, without even having to be aware that Forms is the source.
Note: For further details of deploying the forms-c4ws container, see section Configuring Oracle E-Business Suite Integrated SOA Gateway Release 12.1.2 of My Oracle Support Knowledge Document 556540.1, Installing Oracle E-Business Suite Integrated SOA Gateway, Release 12.
Concurrent Processing Server
As described previously, user interactions with Oracle E-Business Suite data can be conducted via HTML-based applications or the more traditional Forms-based applications. However, there are also reporting programs and data updating programs that need to run either periodically, or on an ad hoc basis. These programs, which run in the background while users continue to work on other tasks, may require a large number of data-intensive computations, and are run using the Concurrent Processing architecture. Concurrent Processing is an Oracle E-Business Suite feature that allows these non–interactive and potentially long-running functions to be executed efficiently alongside interactive operations. It uses operating system facilities to enable background scheduling of data- or resource-intensive jobs, via a set of programs and forms.To ensure that resource-intensive concurrent processing operations do not interfere with interactive operations, they are run on a specialized server, the Concurrent Processing server.
Processes that run on the Concurrent Processing server are called concurrent requests. When you submit such a request, either through HTML-based or Forms-based applications, a row is inserted into a database table specifying the program to be run. A concurrent manager then reads the applicable requests in the table, and starts the associated concurrent program.
Concurrent Manager Characteristics
Concurrent managers are fundamental to concurrent processing. Acting as a job scheduling and execution system, a concurrent manager:
·
Is
an executable that is registered as a program library within Oracle E-Business
Suite, and which runs in its own operating system process
·
Runs operating system processes called target
processes (often referred to as workers), each of which can start one concurrent program at a time
·
Can
optionally run an immediate program that runs as
part of the concurrent manager’s own operating system process
·
Can
be allowed to run any concurrent program, or be specialized to run certain
programs
Specialist Concurrent Managers As well as the general-purpose concurrent managers described in the previous section, there are a number of specialized concurrent managers.
The Internal Concurrent Manager (ICM) controls all other concurrent managers. It administers the startup and shutdown of managers as defined by their work shift, monitors for process failure, and cleans up if a failure occurs. The ICM does not process concurrent requests itself (except for queue control requests, such as ACTIVATE, DEACTIVATE, or ABORT).
While the basic ICM definition should not be changed, you can if required modify the sleep time (number of seconds the ICM waits between checking for new concurrent requests), PMON (process monitor) cycle time (number of sleep cycles the ICM waits between checking for failed workers), and queue size (duration between checks for number of active workers, measured in PMON cycles). If Parallel Concurrent Processing (described below) is being used, you can also set some options for this.
The Conflict Resolution Manager (CRM) enforces rules designed to ensure that incompatible concurrent requests do not run in the same conflict domain (an abstract representation of the groupings used to partition data). As with the Internal Concurrent Manager, the basic CRM definition should not be changed, but you can modify the sleep time for each work shift, as well as some Parallel Concurrent Processing options.
The Standard Manager as shipped with Oracle E-Business Suite will accept and run any concurrent requests, as it has no specialization rules that would restrict its activities. Consequently, the definition of the Standard Manager should not be altered without careful planning, otherwise some programs might not be able to run at all. Jobs should only be excluded from the Standard Manager after ensuring they can be run by an alternative manager, such as a product-specific manager or user-defined manager.
Transaction Managers support synchronous request processing, whereby a pool of server processes responds to requests from client programs. Instead of polling the concurrent requests table to obtain instructions, a transaction manager waits to be signaled by a client. An example is approval of an order, where execution of the request must take place quickly.
The relevant transaction manager program runs on the server, transparently to the client. All transaction programs for a given manager process run in the same database session. Communication between the client and the server is conducted synchronously via Advanced Queueing. At the end of program execution, the client program receives a completion message and a return value, for example denoting approval of the order. This strategy of using non-persistent connections between the client and Transaction Manager processes enables a small pool of server processes to service a large number of clients with near real-time response.
Setting Up Concurrent Managers
The Oracle E-Business Suite System Administrator’s Guide gives full details of the steps and options involved in setting up and monitoring concurrent managers. Some of the key steps include:
·
Name
and description of the manager
·
Assignment
of a concurrent program library
·
Assignment
of work shifts to the manager
·
Definition
of the maximum number of workers (target processes) the manager can run
concurrently
·
Optionally
specializing the manager to run certain types of requests
Tip: It is easier to identify the optimum number of workers by being conservative initially, and defining additional workers later if needed (subject to availability of system resources).
Multiple managers can be run on multiple nodes using Parallel Concurrent Processing, as described below.
Concurrent Processing Architecture
In Concurrent Processing, programs are run as operating system background processes. These programs may be written using a variety of Oracle tools, programming languages for executables, or the host operating system scripting language.
As noted above, a concurrent program that runs in the concurrent manager's own operating system process is known as an immediate program. Immediate programs run as a function within the concurrent manager’s program library. Examples include PL/SQL programs. In contrast, a concurrent program that runs in a child process of the concurrent manager process is known as a spawned program. Examples include SQL programs, SQL Loader programs, Oracle Reports programs, spawned C programs, and host language programs such as UNIX shell scripts or Windows command files.
All reports are run through the Concurrent Processing server manager via the rwrun executable, which spawns an in-process server. This is in contrast to earlier releases of Oracle E-Business Suite, which used the now-obsolete Reports server.
While C programs can be run as immediate programs, it is advisable to run them as spawned programs. This simplifies maintenance, without introducing any disadvantages.
A concurrent request has a life cycle, which consists of three or possibly four phases:
Table 1-1
Concurrent Request Life Cycle
|
|
Phase
|
Activity
|
Pending
|
The request is waiting to be run
|
Running
|
The request is running
|
Completed
|
The request has finished
|
Inactive
|
The request cannot be run
|
A concurrent program library contains concurrent programs that can be called by a concurrent manager. An important example is the Oracle Application Object Library program library (FNDLIBR), which contains Oracle E-Business Suite immediate concurrent programs, and is assigned to the standard concurrent manager. Although each concurrent manager can only run immediate concurrent programs from its own concurrent program library, it can also run spawned or Oracle tool concurrent programs.
Various database tables are employed by the concurrent processing architecture:
Table 1-2
Concurrent Processing Database Tables
|
|
Table
|
Content
|
FND_CONCURRENT_REQUESTS
|
Details of user requests, including status, start date,
and completion date
|
FND_CONCURRENT_PROGRAMS
|
Details of concurrent programs, including execution
method, whether the program is constrained, and whether it must be run alone.
|
FND_CONCURRENT_PROCESSES
|
Cross-references between concurrent requests and queues,
and a history of concurrent manager processes
|
FND_CONCURRENT_QUEUES
|
Information about each of the concurrent manager queues
|
Caution: Do not update these tables manually. You can (subject to your organization's archiving requirements) periodically run the "Purge Concurrent Requests and/or manager data" program to prevent these tables growing too large. See the Oracle E-Business Suite System Administrator's Guide for details.
Concurrent Processing Operations
Because the Internal Concurrent Manager controls all the other managers, it must be running before any other manager can be activated. Once the ICM has been activated, it starts a Service Manager on each node that is enabled for concurrent processing. Acting as an agent of the ICM, the Service Manager starts the concurrent managers on its node, excluding any managers that have been deactivated, or that have no current work shift. The ICM can be activated and deactivated from the operating system prompt, or Oracle Applications Manager. It can also be deactivated (but not activated) from the Administer Concurrent Managers form.
When the ICM is initiated on UNIX, the $FND_TOP/bin/startmgr program is invoked. This calls $FND_TOP/bin/batchmgr, which then:
1.
Starts
a shell process
2.
Starts
the ICM process using the command FNDLIBR, with startup parameters FND, CPMGR,
and FNDCPMBR
3.
Creates
log files (std.mgr and wnnn.mgr) in $APPLCSF/$APPLLOG
Normally, startmgr is run by the user account that owns the application software (for example, applmgr). This account must have write privileges to the log and out directories where the log and output files respectively are written.
The ICM starts up a Service Manager on each node that is enabled for concurrent processing, by instructing the node's Applications Listener (which is dedicated to Concurrent Processing) to spawn a process running the Service Manager executable (FNDSM). The Applications Listener must be configured to source the Oracle E-Business Suite environment file before FNDSM is spawned. Following startup, the Service Manager acts as an agent of the ICM to start and stop concurrent managers on that node, according to their defined work shifts.
Note: The Service Manager is a component of the Generic Service Management (GSM) architecture rather than Concurrent Processing, although GSM and Concurrent Processing are closely integrated.
Concurrent manager processes on a specific node can be seen by running the UNIX commands:
ps –ef | grep FNDLIBR
ps –ef | grep FNDSM
The Service Manager PID seen in the output of the second command can then, if desired, be used to locate all concurrent manager and service processes on the node, since the Service Manager is the parent process for them:
ps –ef | grep <sm_pid>
On Windows, the Task Manager can be used to locate concurrent manager processes. An FNDLIBR process runs for the Internal Concurrent Manager and each standard manager. The ICM can be distinguished by additional details being displayed, including some of the parameters it was started with.
For every process that was successfully started at operating system level, the ICM inserts a row into FND_CONCURRENT_PROCESSES. It then updates the RUNNING_PROCESSES column to reflect the actual running processes as shown in FND_CONCURRENT_QUEUES.
Viewing Concurrent Processing Output
The output from a concurrent processing job goes through several stages before being displayed to the user.
1.
The
Concurrent Processing server communicates with the database server via Oracle
Net.
2.
The
log or output file associated with a concurrent request is passed back to the Report Review Agent, also known as the Web
Review Agent.
3.
The
Report Review Agent passes a file containing the entire report to the Forms
services.
4.
The
Forms services pass the report back to the user's browser one page at a time.
Figure 1-11 Viewing Concurrent Processing Output
You can cater for your network capacity and report volume by using profile options to specify the maximum size of the files and pages that can be passed through the system.
Parallel Concurrent Processing
Parallel Concurrent Processing (PCP) allows concurrent processing activities to be distributed across multiple nodes in an Oracle Real Application Clusters (Oracle RAC) environment or similar cluster system. By distributing concurrent processing in this way, hardware resources can be fully utilized, maximizing throughput and providing resilience to node failure, while retaining a central point of control.
Parallel Concurrent Processing enables you to:
·
Run
concurrent processes on multiple nodes to improve concurrent processing
throughput
·
Continue
running concurrent processes on the remaining nodes when one or more nodes fail
·
Administer
concurrent managers running on multiple nodes from any node in the cluster
One or more concurrent managers can be specified to run on one or more nodes, to best suit your processing needs and fully utilize available hardware resources.
Parallel Concurrent Processing is enabled by default, so PCP is always available for use in environments where one or more concurrent processing nodes exist.
Note: PCP does not require an Oracle RAC environment. Conversely, you do not have to use PCP in an Oracle RAC environment, although it typically makes sense to do so.
Managing Concurrent Processing
From the command line, two commands can be entered to control the Internal Concurrent Manager: startmgr, which starts the ICM; and concsub, which is used to stop or abort the ICM, or request the ICM to check on the operating system process for each manager. In addition, an AutoConfig-enabled environment provides a number of scripts for starting and stopping application tier services from the command line. The script for concurrent processing startup and shutdown is INST_TOP/admin/scripts/adcmctl.sh.
The various components of the concurrent processing system can be managed from various forms, such as Concurrent Manager: Administer, or from Concurrent Managers or Concurrent Requests under Oracle Applications Manager (OAM).
Note: For details of setting up and managing concurrent processing, see Oracle System Administrator's Guide - Configuration, Chapter 7.
Application Tier Administration
In Oracle E-Business Suite Release 12, any application tier node can be used to carry out the following operations:
·
Applying database patches to Oracle E-Business Suite
In
general, Oracle E-Business Suite patches consist of
files and scripts that update the file system and database objects. In Release
12, a single unified (u) driver file combines the
features of the older copy (c), database (d), and generate
(g) driver files.
You
use the AutoPatch utility (adpatch)
to perform these updates. AutoPatch may also be used to apply cumulative
patches such as mini-packs and maintenance packs.
·
Maintaining Oracle E-Business Suite data
Some
features require updates to the tables and schemas they use. The AD
Administration utility (adadmin)
enables you to carry out this and various other file system and database
maintenance tasks.
The concept of an Administration server is a historical one, and does not exist in Oracle E-Business Suite Release 12.
The Database Tier
The database tier contains the Oracle database server that stores and manages all the data maintained by Oracle E-Business Suite. This includes the various types of file in which the tables, indexes, and other database objects for your system physically reside, as well as the database executables. The database also stores the Oracle E-Business Suite online help information.
The database server communicates with the services and servers on the application tier, which mediate the communications between the database and the clients: there is no direct communication between the database and clients.
Using a
Mixed Platform Architecture
The Oracle database server is sometimes available on platforms where Oracle E-Business Suite is not currently certified. In such a case, it may be possible to utilize a mixed platform architecture, where the database is installed on one platform and the application tier on another. (In Release 11i, this was referred to as a split configuration.)
This type of deployment can enable the database to utilize the specific features offered by a particular platform (such as a 64-bit architecture). It can also allow the application tier to be managed in a more cost-effective way.
Note: For up-to-date details of Release 12 support with mixed platform architectures, see Certify on My Oracle Support.
The Oracle E-Business Suite Technology
Layer
The Oracle E-Business Suite technology layer lies between the Oracle E-Business Suite technology stack and the Oracle E-Business Suite product-specific modules. It provides features common to all Oracle E-Business Suite products.
Products in the Oracle E-Business Suite technology layer include:
·
Oracle
Applications DBA (AD)
·
Oracle
Application Object Library (FND)
·
Oracle
Applications Utilities (AU)
·
Oracle
Common Modules (AK)
·
Oracle
Workflow (WF)
·
Oracle
Alert (ALR)
·
Oracle
Application Framework (FWK)
·
Oracle
XML Publisher (XDO)
