« May 2007 | Main | July 2007 »

June 20, 2007

DMZ Configuration with 11i

DMZ Configuration with 11i

A DMZ configuration refers to a Demilitarized Zone implementation of Oracle Applications. This kind of architecture is typically usefully when you wish to open up your applications outside your corporate network or your militarized zone.

The ebusiness suite 11.5.10.2 allows you to have various options ranging from the simple one to the more complex and tightly  secure architectures in a relatively simple out of the box solutions.

Typically Ebusiness Suite supports the following topologies in a DMZ architecture

  • Using Reverse Proxies in DMZ
  • Using Separate Oracle E-Business Suite 11i Web Tier in DMZ
  • Using HTTP Hardware Load Balancers in DMZ
  • Using Reverse Proxies only in DMZ


You can find more details on the supported methodologies with the DMZ architecture in the following metalink note
DMZ Configuration with Oracle E-Business Suite 11i

In the current post i will discuss on a less complex case where we are using an ebusiness suite application tier as the external tier for our DMZ architecture. The below diagram depicts this architecture in simplistic form.



As discussed earlier we will build a second application server for Oracle Applications using adclone which will be used as the external application for the instance.

Current Configuration
Oracle Applications 11.5.10.2
Dual Node
Operating System Sun Solaris

DMZ Patches
Ensure the following patches have been applied on the instance before proceeding ahead.
3942483 An autoconfig patch to suport your reverse proxy and DMZ configuration
5478710 An autoconfig template roll up.

Pre Clone
Shutdown the application tier services and run adpreclone.pl on the application tier of your instance.
#su - applsam
$cd samappl
$. ./APPSORA.env
$cd $COMMON_TOP/admin/scripts/SAM_SAMLXA
$perl adpreclone.pl appsTier

Filesystem Copy
After that copy across the application tier filesystem to the machine
tar -cf - applsam | ssh Node_B tar -xf - -C /u02/sam/

Post Clone on the External Tier
Now you must run your post clone (adcfgclone.pl) on the external tier  and specify that it is your Web Server node only
# su - applsam
$ cd samcomn/clone/bin
$ perl adcfgclone.pl appsTier

Run the txkChangeProfH.sql
Run the txkChangeProfH.sql script to update your profile options default hirerchy to server
$ cd $FND_TOP/patch/115/sql/
$ sqlplus apps/xxxxxxxx  @txkChangeProfH.sql SERVRESP

Startup Services
Startup the application services both on the internal and external tier and test the connectivity.

Verify the Nodes
Verify that the nodes have been registered as expected in the instance.
Navigate to
System Administrator->Install->Nodes



Update Node Trust Level
Update the node trust level by identifying the node which you want to be as your external node.
Navigate to
System Administrator->Profile->System and query for 'Node Trust Level'
Set it as external for the external node at the server level only.



Update Responsibilities
After updating the node trust level the user who come in from the external application server will be able to see only those responsibilities that have been marked as external.
Navigate to
System Administrator->Profile->System and query for 'Responsibility Trust Level'
Choose the responsibility that you want to be as external, in my case it was Isupplier Registration.



Update Home Page Mode
Lastly update the home page mode to framework only.
Navigate to
System Administrator->Profile->System and query for 'Self-Service Personal Home Page Mode' and set it to framework only.



Autoconfig
Run autoconfig on both the nodes and restart the application tier services.

June 08, 2007

Concurrent Manager Troubleshooting Flowchart

Concurrent Manager Troubleshooting Flowchart

There have been some really good notes on concurrent managers. And also a couple on troubleshooting concurrent Managers.

When it comes to troubleshooting concurrent managers in my case i used a flowchart based approach which always worked in most cases.
I made this one based on a similar one for workflow which i had seen sometime back.I believe that most you guys would already be following a similar approach. I just found it easier to put it up in a flow chart format to help me out.





In case you found that confusing or messy here is an explanation of the approach.

  • Submit a Standard Concurrent Report and check if it completes successfully.
  • Check if you are able to view the log/output file if not check if your APPS listener is running.
  • If your concurrent report fails check the log report or request log file.
  • Check if your standard manager is running from the front end.
  • Check if the internal concurrent manager is up and running.
  • Check the UNIX background process of your concurrent manager
    ps -ef|grep FNDLIBR.
  • Check your Concurrent Manager log files at $APPLCSF/$APPLLOG.
  • If the managers are failing due a problematic request try running cmclean.sql or use the recover concurrent manager option from Oracle Applications Manager.
  • In case your concurrent managers are not able to start due to failing to accuire locks, try clearing up the locks from the database.
  • If you are still having trouble with your concurrent managers you can try re creating the concurrent manager views using
    FNDLIBR  FND  FNDCPBWV  apps/<passwd>  SYSADMIN  'System Administrator'  SYSADMIN