Oracle E-Business Suite DMZ Setup in R12.2
In Oracle
E-Business Suite (EBS), a DMZ (Demilitarized Zone) setup is used to securely
expose selected application services to external users while keeping core
services protected inside the corporate intranet. This architecture separates Internal
and External application tiers and enforces access control using trust levels.
Normally We are implement DMZ setup for :
- I-Supplier
- I-Receivable setups
- I-procurement
This Post explains:
- Internal vs External application
nodes
- Node Trust Level and
Responsibility Trust Level
- Important profile options
- Role of txkChangeProfH.sql
- Correct AutoConfig sequence
- Step-by-step DMZ setup procedure
Internal
and External Application Nodes
Internal Node
- The Internal Application Tier is
configured within the corporate intranet and is meant only for internal
users.
Key
characteristics:
- Sharing application tier with
external users is not allowed
Services
running on Internal Node:
- Concurrent Manager Services
- Forms and Reports Services
- Oracle HTTP Server (OHS)
- WebLogic Admin Services
External Node (DMZ Node)
The External
Application Tier is deployed in the DMZ and is used by customers or users
accessing EBS from outside the corporate firewall.
Services
running on External Node:
- Oracle HTTP Server (OHS)
- WebLogic Managed Services
No Concurrent Managers or Admin services should run on the DMZ node.
Important Profile Options in DMZ Setup
DMZ security
is enforced using Node Trust Level and Responsibility Trust Level profile
options.
These
profiles restrict user access to predefined responsibilities based on:
- The application tier node
- The responsibility assigned to the user
Node
Trust Level and Responsibility Trust Level
Node Trust Level (NODE_TRUST_LEVEL)
Defines the
trust level of an application tier server.
Trust
Levels:
- Administrative – Used exclusively by system
administrators
- Normal – Used by employees within the
corporate firewall
- External – Used by customers or users outside the firewall
Responsibility Trust Level
Defines
which responsibilities are allowed to be accessed from a given node.
Together,
these profiles ensure that:
- Internal responsibilities cannot
be accessed from the DMZ
- External users can only access
allowed responsibilities
Updating Profile Hierarchy Using
txkChangeProfH.sql
Oracle
provides a script to change the profile option hierarchy type.
Script
Details
- Script Name: txkChangeProfH.sql
- Location: $FND_TOP/patch/115/sql
Execution
Command
sqlplus apps/apps @$FND_TOP/patch/115/sql/txkChangeProfH.sql SERVRESP
What
SERVRESP Means
SERVRESP = Server
+ Responsibility
This
hierarchy ensures profile options are evaluated based on:
- Application tier server
- Responsibility
Profile Options Updated by the Script
The
following profile options (which control EBS URLs) are updated to Server
level:
- APPS_WEB_AGENT
- APPS_SERVLET_AGENT
- APPS_JSP_AGENT
- APPS_FRAMEWORK_AGENT
- ICX_FORMS_LAUNCHER
- ICX_DISCOVERER_LAUNCHER
- ICX_DISCOVERER_VIEWER_LAUNCHER
- HELP_WEB_AGENT
- APPS_PORTAL
- CZ_UIMGR_URL
- QP_PRICING_ENGINE_URL
- TCF:HOST
These values
differ between internal and external nodes.
AutoConfig Order – Very Important
Oracle
strongly recommends the correct AutoConfig execution order to avoid profile
value overwrite issues.
Reason
Running AutoConfig on the External Node updates:
Server-level URL values for external node
Site-level URL values on internal node
If AutoConfig is not run correctly, internal site-level
values may get overwritten
Recommended
Order
1.
Run
AutoConfig on External (DMZ) Node first
2.
Run
AutoConfig last on Internal (Core) Node
This ensures
Primary (MT) site-level profile values remain correct.
DMZ Setup – Step-by-Step Procedure
1. Update
Hierarchy Type on Primary Apps Node
sqlplus apps/apps @$FND_TOP/patch/115/sql/txkChangeProfH.sql SERVRESP
Run
ADPRECLONE on Primary Apps Node
2. Start Admin Server on RUN & PATCH File System
Run File System:
cd /apps/applmgr/r12
. ./EBSapps.env run
cd $ADMIN_SCRIPTS_HOME
./adadminsrvctl.sh start
Patch File system
cd /apps/applmgr/r12
. ./EBSapps.env patch
cd $ADMIN_SCRIPTS_HOME
./adadminsrvctl.sh start forcepatchfs
3. Run
ADPRECLONE on RUN File System
cd $ADMIN_SCRIPTS_HOME
perl adpreclone.pl appsTier
4. Run
ADPRECLONE on PATCH File System
cd $ADMIN_SCRIPTS_HOME
perl adpreclone.pl appsTier
6. Take
Backup of RUN File System
tar -cvzf appsTierBackup.tar.gz EBSapps/
scp appsTierBackup.tar.gz oracle@Dmzserver:/apps/applmgr/r12/fs1
7. On DMZ
Node – Extract Backup
cd /apps/applmgr/r12/fs1
tar -xvf appsTierBackup.tar.gz
8.
Execute ADCFGCLONE (Dual File System)
cd /apps/applmgr/r12/fs1/EBSapps/comn/clone/bin
# Make sure admin server is up and running in both Run and Patch FS of Primary server
perl adcfgclone.pl appsTier dualfs
Do you want to add a node (yes/no) [no] : YES
Enter the APPS password : PROD_Apps_Password
Enter the Weblogic Adminserver password : PROD_WebLogic_Password
Target System Hostname :
Target System Instance Home Directory [/apps/applmgr/r12/] :
Do you want to preserve the Display [:0.0] (y/n) : n
Target System Display :
Target System Root Service [enabled] :
Target System Web Entry Point Services [enabled] :
Target System Web Application Services [enabled] :
Target System Batch Processing Services [enabled] :DISABLED
Target System Other Services [enabled] : DISABLED
Do you want the target system to have the same port values as the source system (y/n) [y] ? : YES
Choose a value which will be set as APPLTMP value on the target node [1] :
9. Stop Patch File System Admin Server on Primary Node
/apps/applmgr/r12/EBSapps.env patch
$INST_TOP/admin/scripts/adadminsrvctl.sh stop
10. Run
AutoConfig on DMZ Node
cd $ADMIN_SCRIPTS_HOME
./adautocfg.sh
Important: Ensure AutoConfig completes successfully.
11. Run
AutoConfig on Core (Internal) Node
cd $ADMIN_SCRIPTS_HOME
./adautocfg.sh
Important: This must be the last AutoConfig
run.
Comments
Post a Comment