11i/R12

Oracle EBS R12.1.1 file location

Autoconfig log file:
Apps:
$INST_TOP/apps/$CONTEXT_NAME/admin/log/$MMDDHHMM/adconfig.log.
Database:
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME//adconfig.log $ORACLE_HOME/appsutil/log/$CONTEXT_NAME//NetServiceHandler.log
Startup/Shutdown Log files:
$INST_TOP/logs/appl/admin/log
Apache, OC4J and OPMN:
$LOG_HOME/ora/10.1.3/Apache $LOG_HOME/ora/10.1.3/j2ee $LOG_HOME/ora/10.1.3/opmn
Patch log:
$APPL_TOP/admin/$SID/log/
Concurrent log:
$INST_TOP/apps/$CONTEXT_NAME/logs/appl/conc/log
Clone log:
Preclone log files in source instance 
Apps:
$INST_TOP/apps/$CONTEXT_NAME/admin/log/ (StageAppsTier_MMDDHHMM.log) 
Database:
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/(StageDBTier_MMDDHHMM.log) 
Clone log files in target instance
Apps :
$INST_TOP/apps/$CONTEXT_NAME/admin/log/ApplyAppsTier_.log 
Database:
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/ApplyDBTier_.log
Alert Log File:
$ORACLE_HOME/admin/$CONTEXT_NAME/bdump/alert_$SID.log

APPL_TOP

[applmgr@gayatri10 ~]$ cd /oracle/PROD/apps/apps_st/appl

INST_TOP

[applmgr@gayatri10 ~]$ cd /oracle/PROD/inst/apps/context_name

COMMAN_TOP

[applmgr@gayatri10 ~]$ cd /oracle/PROD/apps/apps_st/comn

JAVA_TOP  

[applmgr@gayatri10 ~]$ cd /oracle/PROD/apps/apps_st/comn/java
Database_top  

[applmgr@gayatri10 ~]$ cd /oracle/PROD/db/tech_st/10.2.0/appsutil/scripts/PROD_gayatri10/   
Context file:-(.xml)
[applmgr@gayatri10 ~]$ cd /oracle/PROD/inst/apps/PROD_gayatri10/appl/admin
Defaults file location:-(.txt)
[applmgr@gayatri10 ~]$ cd  /oracle/PROD/apps/app_st/appl/admin/PROD/adalldefault.txt
[applmgr@gayatri10 ~]$ cd APPL_TOP/admin/<SID>  
Autoconfig log file:-
[applmgr@gayatri10 ~]$ cd /oracle/PROD/inst/apps/PROD_gayatri10/appl/admin/log

Difference between Application R12 and 11i

Applications Release 12 and 11i , I decided to dedicate this post to outline few major technical difference.
Database:
Database Version in 11i (11.5.9 & 11.5.10) was 9i Rel 2 where as in Release 12 its 10g R2 (10.2.0.2)
Application Tier:
Tech Stack in Application Tier consist of iAS(1.0.2.2.2) & Developer 6i (Forms & Reports 8.0.6) but in Applications R12 it is build on Fusion Middleware (10g Web Server and 10g Forms & Reports)
Sub component in Application Tier
A) HTTP Server or Web Server in R12 is Version 10.1.3 which is built on Apache version 1.3.34. In apps 11i it is Version 1.0.2.2.2 built on Apache Version 1.3.19
B) Jserv in apps 11i is replaced by OC4J (mod_jserv is replaced by mod_oc4j)
C) Forms Version 6i in Apps 11i is replaced by Forms 10.1.2.0.2 in R12
D) Reports Version 6i in Apps 11i is replaced by Reports 10.1.2.0.2 in R12
E) JDBC version is changed from version 9 in apps 11i to version 10.2.0 in Apps R12
F) modplsql or mod_pls is removed from Apps R12 (What will happen to my mod plsql applications- coming soon* )
G) Java processes use JDK/JRE version 1.5.0 in R12 against JDK version 1.3.1 or 1.4.2 in Apps 11i
H) For various environment variable changes check below picture

I) New top INSTANCE_TOP added in Release 12 for configuration and log files.

                      11i/R12 Common Topics

11i/R12 Common Topics
Topic is quite important and I recommend you to go through this thoroughly.
How to find version of Oracle Components
APPS Patching
Change APPS Password
Context/XML or Autoconfig File
Autoconfig
Cloning Internals
Logs in $APPLCSF
Diff APPS 11i/R12
Start/Stop Apps 11i
Advaned Start/Stop Apps 12
Patching Basics
Cloning
Step by Step Apps Cloning
Hot backup Cloning

First Let’s discuss terminology which you will encounter here & in most of Oracle Documentation.
Server – is a process or group of processes and provides a particular functionality/service For example, Database Server listen and process database requests, similarly Web Server listens for and processes HTTP requests.
Tier – is a logical grouping of services, may be on single machine or spread across more than one physical machine. For Example, Middle Tier in Oracle apps consist Form,Web,Report…Services. Forms & Report can be one machine 1 & Web Server can be on machine 2, still they will be part of same tier called as Application Tier or Middle Tier.
Node – is referred as Machine, Each tier may consist of one or more node and each node can potentially have more than one tier.
Desktop Tier – Oracle Applications/E-Business Suite is built on three tier Architecture with first Desktop Tier ic client machines accessing applications via browser(HTML based Self service applications) or Java Applet(Jinitiator) for Form based interface.
Application/Middle Tier – Second is Application Tier also called as middle tier consists of WebServer Forms, Reports, Concurrent processing, Discoverer and Admin Server. I suppose its known as Middle tier because it lies between our desktop & third tier called database tier.
Database Tier – Third is Database Tier contain Orale database server which store all your application data. I am sure if you are DBA you know it.

*******************************************************************************

 compile invalid objects in an R12 APPS Environment

Applying Patches can create invalid objects. To get a quick count of the number of existing invalids (if any), use the following select statement :

SELECT COUNT(*)
FROM DBA_OBJECTS
WHERE STATUS = 'INVALID';

For a more detailed query, use the following script :

SELECT OWNER, OBJECT_TYPE, COUNT(*)
FROM DBA_OBJECTS
WHERE STATUS = 'INVALID'
GROUP BY OWNER, OBJECT_TYPE;

To recompile an individual object, connect to SQL*PLUS as the owner of the object (generally apps) and use one of the following depending on the object type :

alter package <package_name> compile; (package specification)
alter package <package_name> compile body; (package body)
alter view <view_name> compile; (view)

If the object compiles with warnings, use either of the following to see the errors that caused the warnings :



show errors

OR

select * from user_errors where name = '<OBJECT_NAME>';

Another way to correct invalid objects is to run the adadmin utility as follows:

UNIX OPERATING PLATFORM

1. Log in as APPS User : <applmgr username>/<applmgr password>

2. Start the adadmin-Utility from the Unix prompt with this command :

adadmin

The utility will then ask you a series of questions.

3. Under the Maintain Applications Database Objects Menu, select Compile APPS schema(s)

This task spawns parallel workers to compile invalid database objects in your APPS schema(s). It uses the same parallel phases as AutoInstall.

Also try running $ORACLE_HOME/rdbms/admin/utlrp

.sql ( as sysdba ) Within Applications, there is a script to compile INVALID objects - called ADCOMPSC.pls Arguments for ADCOMPSC.pls : 1 - Schema to run in 2 - Password for schema 3 - Check errors for objects starting with #3 NOTE: The order in which to compile Invalid Objects in schemas is SYS, SYSTEM, APPS and then all others. APPS_DDL and APPS_ARRAY_DDL should exist in all schema's. In case of an ORA-1555 error while running adcompsc.pls, restart the script. The script can be run as followed : cd $AD_TOP/sql sqlplus @adcompsc.pls SCHEMA_NAME SCHEMA_PASSWORD % Example : SQL> @adcompsc.pls apps apps % After the script completes, check for invalid objects again. If the number has decreased, but invalid objects still exist, run adcompsc.pls again. Keep running adcompsc.pls until number of invalid objects stops decreasing. If there are any objects still left INVALID, verify them by using the script 'aderrchk.sql' to record the remaining INVALID objects. 'Aderrchk.sql' uses the same syntax as 'adcompsc.pls'. This script is also supplied with the Applications. Send the aderrchk.sql to a file using the spool <file> command in sqlplus. e.g. sqlplus x/y @aderrchk.sql SCHEMA_NAME SCHEMA_PASSWORD % For objects which will not compile, try the following : select text from user_source where name = 'OBJECTNAME' and text like '%Header%'; This script will provide the script that creates the packages/recreates the packages. SQL>@packageheader SQL>@packagebody If recreating the package does not make the package valid, analyze the user_errors table to determine the cause of the invalid package : select text from user_errors where name = '<PACKAGENAME>';

*******************************************************************************

Apps 11i

The three distinct “Tiers” in Oracle apps 11i are:

1. Desktop Tier
2. Application Tier
3. Database Tier

 

The Desktop Tier
The client interface is provided through HTML for the Self-Service interface, and a Java applet for the professional, forms-based interface using a Java-enabled Web browser. The desktop client with Oracle JInitiator downloads the applet on demand
and the applet is cached locally for future use.

Forms Client Applet
The Forms client applet is a general-purpose presentation applet that supports all Oracle Applications Forms-based products, including those with customizations and extensions. The Forms client applet is packaged as Java archive (JAR) files.
The JAR files contain all Java classes required to run the presentation layer of Oracle

Applications forms.
The Forms client applet and commonly used JAR files are downloaded from the Web server at the beginning of the client’s first session. Other less commonly used JAR files are downloaded as needed. The JAR files remain in the disk cache on the
desktop, ready for future sessions, minimizing network traffic.
All updates are installed on the application tier and downloaded to the client automatically through the use of the JInitiator-enabled Web browser.

Oracle JInitiator
The Forms client applet must run within a Java Virtual Machine (JVM) on the desktop. For Oracle Applications, the JVM is supplied by Oracle JInitiator. Oracle JInitiator works in conjunction with theWeb browser. It is implemented on the
desktop client as a plug-in (Netscape Communicator) or ActiveX component (Microsoft Internet Explorer).
When a user enters the desired Oracle Applications signon URL within the Web browser, Oracle JInitiator is executed. If Oracle JInitiator has not been installed, the Web browser prompts the user to download the necessary installation executable to the desktop client. Once installed, Oracle JInitiator runs the Forms client applet and starts an Oracle Applications session.

The Application Tier
The application tier hosts the servers that process the business logic and provides the communication between the desktop tier and the database tier. This tier is also referred to as the middle tier. Oracle 9i Application Server (9iAS) provides the technology stack used on the application tier. Six servers comprise the application
tier for Oracle Applications:
â–  Web server
â–  Forms server
â–  Concurrent Processing server
â–  Reports server
â–  Discoverer server (optional)
â–  Admin server
The Application Tier

Load Balancing
The application tier supports load balancing among many of its servers to provide higher availability, fault tolerance, reliability, and optimal scalability.
Load balancing occurs when there are multiple installations of the following:
â–  Web server
â–  Forms server
â–  Reports server
â–  Concurrent Processing server
â–  Discoverer server

Web Server
The Oracle HTTP server (powered by Apache) is theWeb server. It processes the requests received over the network from the desktop clients. It includes additional components such as:

â–  Web Listener
â–  Java Servlet Engine
â–  Portal
â–  Java Server Pages (JSP)
The Web listener component of the Oracle HTTP server accepts incoming HTTP requests (URLs) from desktop clients (browsers). If possible, the Web server services the requests itself, for example, by returning an HTML 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.

Self-Service Applications Architecture
The Oracle Self-Service Applications:
â–  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
â–  JRAD (Oracle Applications Extensions to JDeveloper) in OA Framework 5.7
â–  Operate by direct connection to theWeb server
OA Framework is the development and deployment platform for self-service applications. It is a 100% Java, middle-tier application framework and services for the rapid development and deployment of HTML-based applications.
OA Framework-based applications logic is controlled by procedures that execute through the Java servlet engine. The Apache JServ module provides the Java servlet
engine. For the Self-Service Applications, the Web server communicates with the
database using JDBC.

The Self-Service 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 (JServ) where it runs a JSP.
4. The JSP obtains the content from the Applications tables and uses information from the metadata dictionary to construct the presentation of the HTML page.
5. The resulting HTML page is passed back to the browser, by way of the Web server.

Oracle Applications Framework Architecture Following is a more detailed description of the processing that occurs in Step 4 of the previous section. Oracle Applications
Framework uses additional components, including:
â–  BC4J (Business Components for Java), 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. It allows
the separation of the application business logic from the UI.
â–  AOL/J provides the Oracle Applications Framework with underlying security and applications Java services. It provides the Oracle Applications Framework with its connection to the database and with application-specific functionality, such as flexfields and attachments.


Oracle Applications Framework Architecture
1. AOL/J validates user access to the page.
2. The page definition is loaded fromtheMetadata Repository on the database tier into the applications tier (Metadata UI Definition).
3. The BC4J objects that contain the applications 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 and creates the corresponding HTML in accordance with UI standards and sends the page to the browser.

The Forms Server
The Forms server hosts the Oracle Applications forms and the forms run time engine that support the professional interface. The Forms server is an Oracle Developer 6i component which mediates the communication between the desktop client and the Oracle data server by displaying client screens and initiating changes
in the database records based on user actions.
The Forms server caches data and provides it to the client as needed, such as when scrolling through multiple order lines that exceed the limitations of a single screen.
The Forms server communicates with the desktop client using these protocols:
â–  Secure HTTPS network connection
â–  Standard HTTP network connection
â–  TCP/IP connection
HTTP and HTTPS support enables operation over a firewall. The Forms server communicates with the Oracle data server using Net8.

Forms Server 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 the 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.

Once a connection has been made, many operations can be performed with little or no 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.

Load Balancing Among Forms Servers
Oracle Applications supports automatic load balancing among multiple Forms servers. In a load-balancing configuration, all Forms server requests have a single point of coordination called the Metrics Server, located on one application server.
Metrics clients located on the other application servers periodically send load information to the Metrics Server so that it can determine which application server has the lightest load.
1. The client requests a Forms session and the request is sent to the Load Balance (Metrics Server) via the Web Listener.
2. The load balancer determines the least-loaded Forms server and returns its name in the form of an HTML page.
3. The client can now access the least-loaded Forms server directly.
4. From this point on, all communication is between the client desktop and the designated Forms server.

Concurrent Processing Server
User interactions with Oracle Applications data are conducted through the Self-Service Applications and the Forms-based Professional interface. However,
there are reporting programs and data updating programs that run periodically on an ad hoc basis. These programs, which operate in the background while users continue to work on other tasks, may contain a very large number of data-intensive
computations. To ensure that they do not interfere with interactive operations, they are run on the Concurrent Processing server.
Processes that run on the Concurrent Processing server are called concurrent requests. When you submit a request, either through Forms or Self-Service
Applications, a row is inserted into a database table specifying the program to be run. Concurrent managers read the applicable requests in the table and start the concurrent programs. The Internal Concurrent Manager service monitors the database table for new requests, controls the other concurrent managers, and determines when a request should be processed and which concurrent manager should carry it out.
Log and output files are generated on the Concurrent Processing server.

Accessing Concurrent Processing Output The Concurrent Processing server communicates with the data server using Net8. The resultant log or output file from a concurrent request is passed back to the Report Review Agent, also known as the Web Review Agent. The Report Review Agent passes a file containing the entire report to the Forms server. The Forms server passes the report back to the user’s browser one page at a time. You can use profile options to control the size of the files and pages passed through the system.

Business Intelligence System (BIS)
The Business Intelligence System is a decision support solution integrated with Oracle Applications. Using the BIS products, a manager can query the Oracle Applications database to monitor recent business performance across multiple
organizations. For example, a manager can set a sales goal and then use BIS to determine how close actual sales amounts are to the goal. A manager can set tolerances and have the system inform people when those tolerances are exceeded.
With the BIS Performance Manager Framework, some corrective actions can be performed automatically. If, for example, sales actual amounts are more than 10% below goals, BIS can send automatic notifications to regional sales managers.
BIS products do not use the Forms server or Forms client. Instead, BIS products use the Oracle Discoverer server and Oracle Reports server on the application tier. A Java applet running on the desktop client communicates with the HTTP server, which connects to the Oracle Discoverer server or Oracle Reports server. The
Discoverer server provides ad hoc analysis; the Reports server uses summary tables such as monthly aggregates of data, and returns them to the browser as HTML.

Reports Server
The Reports server is used primarily to produce reports for BIS products. It is automatically installed on the same node as the Concurrent Processing server and
its reports are contained in the same directory with the concurrent processing reports. However, reports generated by the Reports server are monitored and administered separately from concurrent processing reports. The Reports server dynamically selects language at runtime and users see each report in the preferred language.

Reports Server Architecture
The request for an HTML-based report is similar to the flow of a Self-Service

Applications request:
1. The user clicks the hyperlink of a function from a browser.
2. The browser makes a URL request to the Web listener.
The Application Tier
1-14 Oracle Applications Concepts
3. The Web listener contacts the Reports server through the reports Web CGI. The reports Web CGI allows the desktop client to run reports and see the output through theWeb browser.
4. The Reports server starts the Reports run time engine.
5. The Reports run time engine locates the necessary reports and connects to the database to query the requested information.
6. The queried information is presented to the user in the form of an HTML page.

Clustering and Load Management
When there are a large number of BIS users, it may be beneficial to have multiple
Reports servers.
In this configuration, one of the Reports servers is designated as the master server.
The master Reports server receives the initial request and distributes it to one of the other Reports servers depending on the load each can handle. The master Reports server is capable of determining how many run time engines each of the Reports servers can support.
Release 11i supports multiple languages on a single Reports server.

Discoverer Server
The Discoverer server complements the Reports server as a tool to perform ad hoc queries and analysis of the resultant query output. It also allows users to perform projections as various business and strategic factors are changed.

End User Layer

The End User Layer is the key to providing ease of use. The End User Layer is a layer of metadata that sits in the Oracle Applications database, but on top of the Oracle Applications data.
Oracle Discoverer hides the complexity of the database and converts it to an easy to understand interface for users. It maps the unfamiliar terms in the database, such as tables and columns, to familiar terms for the user. Therefore, analysts or managers with no database syntax familiarity can access key information using terms common to them, such as customer, name, and revenue.
The End User Layer is one of the key components of the Discoverer process. It is in the database, but is separate from the Oracle Applications data.
There are two important software packages that access the End User Layer. They are:

â–  Administrator Edition - allows the creation of the End User Layer and manages the administration of responsibilities and roles.

â–  User Edition - used to create workbooks (saved queries) and view information about the business. Oracle provides predefined workbooks which can be used as bases for ad hoc queries.
In Release 11.0, the User Edition was located on the client. For Release 11i, it is located in the Discoverer server. This allows for central administration of the software.

Admin Server
The Admin server is located on the node where you maintain the data model and data in your Oracle Applications database. You carry out the following operations from this server:

â–  Upgrading Oracle Applications
This process is conducted only when you are upgrading to a new release (from an earlier one, such as 10.7 or 11.0). You use the AutoUpgrade utility (adaimgr) to upgrade Oracle Applications.

â–  Applying database patches to Oracle Applications
Most patches consist of files and scripts that update the file system and/or database objects. You use the AutoPatch utility (adpatch) to perform these updates. AutoPatch may also be used to apply cumulative patches such as minipacks (for example, 11i.GL.D) and maintenance packs (for example, 11.5.9).

â–  Maintaining Oracle Applications data
Some features such as Multiple Reporting Currencies require regular maintenance to ensure updates are propagated to the additional tables and schemas used by this feature. The AD Administration utility (adadmin) allows you to do this as well as other file system and database maintenance tasks.

The Database Tier
The database tier contains the database server, which stores all the data maintained by Oracle Applications. It also contains some processing code that is stored in the database to optimize performance. In Release 11i, the database includes the Oracle Applications online help information as well.
More specifically, the database tier contains the Oracle data server files and Oracle Applications database executable that physically store the tables, indexes, and other database objects for your system.
In general, the database server does not communicate directly with the desktop clients, but rather with the servers on the application tier, which mediate the communications between the database server and the client

 

To switch environments, move to the appropriate home directory and run the environment script.

cd $DB_HOME
. ./PLAY_testapps01.env

Shutdown/Startup 11i

Adjust the following paths and commands by replacing "play" and "PLAY" with the database name you chose during the installation.
To shutdown the system issue the following commands.

cd $COMMON_TOP/admin/scripts/PLAY_testapps01/
./adstpall.sh apps/apps

cd $DB_HOME
. ./PLAY_testapps01.env
cd $ORACLE_HOME/appsutil/scripts/PLAY_testapps01
./addlnctl.sh stop PLAY
./addbctl.sh stop immediate

To start the system issue the following commands.

cd $DB_HOME
. ./PLAY_testapps01.env
cd $ORACLE_HOME/appsutil/scripts/PLAY_testapps01
./addlnctl.sh start PLAY
./addbctl.sh start

cd $COMMON_TOP/admin/scripts/PLAY_testapps01/
./adstrtal.sh apps/apps
./adcmctl.sh start apps/apps

Rapid Installation Wizard Portal

Once the installation is complete, the Rapid Installation Portal can be accessed using the following information.

URL: http://machine-name:8000

Username: SYSADMIN

Password: SYSADMIN

The front screen of the portal is shown below.

To change the SYSADMIN password do the following.

Log in to the eBusiness Suite homepage as SYSADMIN

Click on the "preferences" link (top-right).

Enter the old and new passwords.

***********************************************************

How do you start and stop Concurrent Manager in 11i Apps?

Concurrent Manager

 

adcmctl.sh is one of the scripts in oracle applications 11i for starting and stopping Concurrent Manger service. It requires apps username and password to run this script. Using this predefined script we can start, stop, abort and check the status of Concurrent Manger Service.Starting Service of CM:

Go To

cd $APPLCSF/scripts/<SID>_<localhost_name>

sh adcmctl.sh start apps/appspw

Sample Output:
mydb:applprod$sh adcmctl.sh start apps/apps
You are running adcmctl.sh version 115.31
Starting concurrent manager for PROD_806_BALANCE …
Starting PROD_0725@PROD_806_BALANCE Internal Concurrent Manager
Default printer is noprint
adcmctl.sh: exiting with status 0
mydb:
Stoping Service of CM:

Go To

cd $APPLCSF/scripts/<SID>_<localhost_name>

sh adcmctl.sh stop apps/appspw

Sample Output:
mydb:applprod$sh adcmctl.sh stop apps/apps
You are running adcmctl.sh version 115.31
Shutting down concurrent managers for PROD_806_BALANCE …
Submitted request 15895555 for CONCURRENT FND SHUTDOWN
adcmctl.sh: exiting with status 0
mydb:applprod$
Status of CM:

Go To

cd $APPLCSF/scripts/<SID>_<localhost_name>

sh adcmctl.sh status apps/appspw

Sample Output:

mydb:applprod$sh adcmctl.sh status apps/apps

You are running adcmctl.sh version 115.31
Internal Concurrent Manager is Active.
adcmctl.sh: exiting with status 0
mydb:applprod$

Please check is there any concurrent process is there before starting concurrent processing server. If the concurrent process still exists after shutdown kindly wait for some time for clearing the requests.

The bellow command will tell you how many concurrent processes are running.Here applprod is the user for the application file system.For finding FNDLIBR process:

ps -ef|grep applprod|grep FNDLIBR

For counting FNDLIBR process

ps -ef|grep applprod|grep FNDLIBR|wc –l

For killling FNDLIBR process

kill -9 <PID>

****************************************************************

Bounce Apache Server in Oracle Apps 11i

Please find the two commands that are used for bouncing the Apache below:

$COMMON_TOP/admin/scripts/$TWO_TASK*/adapcctl.sh stop

$COMMON_TOP/admin/scripts/$TWO_TASK*/adapcctl.sh start