Showing posts with label 11i. Show all posts
Showing posts with label 11i. Show all posts

Wednesday, November 18, 2009

How to find a responsibility that can run a particular Conurrent Program

If you would like to know the responsibility that can submit a particular concurrent then use the query mentioned below . It's working for 90% of programs and I'm working on the same to make it 100 % effective ( will update the same when succeed )


Step 1 :

select user_concurrent_program_name from fnd_concurrent_programs_vl where user_concurrent_program_name like '%DIRECT BILLING%'

DIRECT BILLING BO REPORT


Now user the query to find the required responsibilities ...

Query :

select responsibility_name , responsibility_key ,request_group_id , application_id from fnd_responsibility_vl
where request_group_id in (
select request_group_id from FND_REQUEST_GROUP_UNITS where request_unit_id in
( select concurrent_program_id from fnd_concurrent_programs_vl where
user_concurrent_program_name='DIRECT BILLING BO REPORT'))

Saturday, June 13, 2009

Autoconfig Tunning

Tunning Autoconfig Tunning Autoconfig rahulmit_20 Hi Friends , After monitoring a lot . Finally , I got some solution for this . Now autoconfig time has been reduced by 50 minutes on our site . Try this on your site also , if you've been facing the same problem ...

Regds
Rahul
ecengineer84@gmail.com

Tuesday, July 29, 2008

Host Name / I.P Change for the AP node ( Apache / Form Node ) in 11i

Pre-Information

1. ILTEST Architecture (EBS: 11.5.10 ; O.S : AIX 5.3 )




Activity is to change the change the hostname from iltestap (192.168.20.137) to LGEILMESD02N (10.101.0.62).Before the activity stop all the services on Form and Concurrent Node, by running adstpall.sh
on 192.168.20.137 and 192.168.20.133. Also stop the database and listener.

UNIX Team Activity: Change the I.P / hostname of iltestap (192.168.20.137)

When the I.P./Hostname changed. Then up the database and listener only .

Login the Form Node (10.101.0.62) and follow the steps mentioned below.

Step 1 : Add the new host entry in the /etc/hosts file

$ cd /etc
$ vi hosts

Add the entry mentioned below

10.102.0.62 LGEILMESD02N.lgeil.com LGEILMESD02N

Step 2: Now change the host name in the .xml file .

$ cd $APPL_TOP/admin
$ cp ILTEST_iltestap.xml ILTEST_LGEILMESD02N.xml
$ vi ILTEST_LGEILMESD02N.xml

And here change the “iltestap” to “LGEILMESD02N” globally

Step 3: Run the autoconfig.

$ cd $AD_TOP/bin
$ adconfig.sh contextfile=$APPL_TOP/admin/ ILTEST_LGEILMESD02N.xml
Enter the password of apps : apps ( OR apps password of your apps )

Step 4: After the autoconfig completed successfully. Then, make custom.env file

Note: Autoconfig never makes the custom.env file. This file Need to be created manually.

$ cd $APPL_TOP
$ ls –ltr customILTEST_iltestap.env

-rw-r--r-- 1 oracle dba 126369792 Jul 4 17:36 customILTEST_iltestap.env
$ cp customILTEST_iltestap.env customILTEST_LGEILMESD02N.env

Step 5: Edit $APPL_TOP/ILTEST_LGEILMESD02N.env

$ cd $APPL_TOP
$ ls –ltr ILTEST_LGEILMESD02N.env

Vi this file (ILTEST_LGEILMESD02N.env) and edit

Find "FORMS60_PATH" and add lines

FORMS60_PATH=$FORMS60_PATH:$CUSTOM_TOP/resource:$CUSTOM_TOP/forms/US:$EAU_TOP/forms/US
export FORMS60_PATH

Below the following line

FORMS60_PATH="/u02/app/ilprodappl/au/11.5.0/resource:/u01/app/ilprodappl/au/11.5.0/resource/stub"export FORMS60_PATH

Step 6
: Now, up the services on Form Node and Concurrent Node

Run adstrtal.sh on both Form and Concurrent Node and up the services. After try to open the EBS through the new url i.e.; http:.: .

New Setting :

Host File Entry
10.101.0.62 lgeilmesd02n lgeilmesd02n.lgeil.com

Proxy Settings
*lgeilmesd02n*;*lgeilmesd02n.lgeil.com*

Url
http://lgeilmesd02n.lgeil.com:8001
http://lgeilmesd02n.lgeil.com:8001/dev60cgi/f60cgi

Note: If this didn’t wok for you and you EBS shoes some error while opening the form launcher. Then stop the all on AP and DB node by running adstpall.sh (Don’t down the database & listener ) . After this change the iltestap to LGEILMESD02N in the .xml of Concurrent Node and then run the autoconfig firstly on Concurrent Node and after that on Form Node.


Monday, July 21, 2008

Checking mainentance mode in 11i

Maintenance Mode is a new mode of operation introduced with Release 11.5.10, in which the

Oracle Applications system is made accessible only for patching activities not allowing the users

to login to any responsibility. This provides optimal performance for AutoPatch sessions, and

minimizes downtime needed.

1. Scheduling System Downtime

Administrators can schedule 'System Downtime' using Oracle Applications Manager (OAM):

Site Map --> Maintenance --> Manage Downtime Schedules

When the System has been scheduled for 'Downtime', Apache should be re-started on Restricted Mode

by using the Script (adaprstctl.sh). By doing this, users attempting to log on to Oracle Applications will

be automatically redirected to a System Downtime URL showing a message similar to the following one:

Scheduled Downtime Details
Start Time : 17:30:00 12/11/2004
Expected Up Time : 09:00:00 12/12/2004
For Updates : ecengineer84@gmail.com
The system is currently undergoing a scheduled maintenance.

This message can be customized with any text message. If No Downtime has been specified, and the users

try to access the Applications, the following message might also appear:

! Warning
The system has not been taken off maintenance mode completely.
Please contact your System Administrator.

2. Advantages

There are several practical points relating to the use of Maintenance Mode:

  • You can toggle Maintenance Mode between Enabled and Disabled using the new Change Maintenance

Mode menu in AD Administration, or the equivalent function in Oracle Applications Manager.

  • Although you can run AutoPatch with Maintenance Mode disabled, there will be a significant

degradation in performance.

  • There is a separate logon page for Restricted Mode access while the system is in Maintenance Mode.

For more Information on Restricted Mode Access

3. Enabling and Disabling Maintenance Mode

Maintenance mode is Enabled or Disabled from adadmin.

When you Enable or Disable 'Maintenance Mode', adadmin will execute the script:

$AD_TOP/patch/115/sql/adsetmmd.sql sending the parameter 'ENABLE' or 'DISABLE' :

sqlplus /@adsetmmd.sql ENABLE | DISABLE

ENABLE - Enable Maintenance Mode .
DISABLE - Disable Maintenance Mode.

When adsetmmd.sql runs, it sets the Profile Option 'Applications Maintenance Mode'

(APPS_MAINTENANCE_MODE) to 'MAINT' to Enable 'Maintenance Mode' and to 'NORMAL' to Disable it.

4. Determining if Maintenance Mode is Running

A quick way to verify if the Environment is on Maintenance Mode or not, is by checking the value of this

Profile Option as follows:

sqlplus apps/apps

SQL> select fnd_profile.value('APPS_MAINTENANCE_MODE') from dual;

If the query returns 'MAINT', then Maintenance Mode has been Enabled and the Users will not be able to

Login. If the query returns 'NORMAL' then Maintenance Mode has been De-Activated and the Users will be

able to use the application.

Note: Maintenance Mode is only needed for AutoPatch Sessions. Other AD utilities do not require

Maintenance Mode to be enabled. Maintenance Mode must be 'Enabled' before running AutoPatch

and 'Disabled' after the patch application was completed.

When Maintenance Mode is disabled, you can still run Autopatch by using options=hotpatch on the

command line, if necessary. However, doing so can cause a significant degradation of performance.

5. Error Messages

Always remember to Disable Maintenance Mode after any Patch application. If Maintenance Mode is not

Disabled, the Application will not allow the users to use the system. Take note that Apache must be

re-started in normal mode after disabling 'Maintenance Mode' by using the Script adapcctl.sh (or adstrtal.sh)

As explained before, when 'Maintenance Mode' is enabled, a Downtime should be Scheduled from OAM and

Apache should be started on Restricted Mode by using the Script (adaprstctl.sh).

If a 'DownTime' is not Scheduled from OAM and Apache has not been re-started on Restricted Mode,

the Application will allow the users to Login, but it might experience unusual behaviors afterwards

depending on the Patch Level.

Here are some examples of the possible error messages:

  • When clicking on a Responsibility from the PHP

There are no applications available for this responsibility. Please click on a different responsibility

link to display the list of available applications.

or

You are not authorized to access the function Applications Home Page. Please contact your System

Administrator.

  • When trying to access to the Application via CGI directly (not supported):

There are no valid navigations for this responsibility
Cause: The menu compilation has failed.
Cause: There is not valid menu defined for this responsibility.
Cause: There are no navigable forms associated with this responsibility.
Action: Contact your system administrator. Ensure that a valid menu,
containing navigable forms, is defined for the responsibility.
Ensure that the menu is correctly compiled.

Note: In some cases, the behavior is slightly different. Instead of showing the above messages, the

Application might not show any Responsibilities listed for the user at all.

6. Step by Step Process

1. Schedule the 'System Downtime' from OAM

OAM: Site Map --> Maintenance --> Manage Downtime Schedules

At the moment of the downtime, do the following:

2. Shutdown Apache (on Normal Mode):

adapcctl.sh stop
or
adstpall.sh /

3. Enable 'Maintenance Mode' from adadmin

adadmin: Options 5, 1

4. Start Apache (on Restricted Mode)

adaprstctl.sh start

5. Apply the Patch with adpatch
6. Stop Apache (on Restricted Mode)

adaprstctl.sh stop

7. Disable 'Maintenance Mode' from adadmin

adadmin: Options 5, 2

8. Start Apache (on Normal Mode):

adapcctl.sh start
or
adstrtal.sh /

Enabling f60cgi direct login in 11i

Accessing f60cgi is disabled in 11.5.10
----------------------------------------

With increased security in Oracle EBusiness Suite 11.5.10, the ability to
connect directly to forms via f60cgi has been disabled. By default, a user will
see the following error after entering their username and password:

APP-FND-01542: This Applications Server is not authorized to access this database.

This is expected functionality.


Enabling f60cgi direct login
------------------------------

It is possible to login however this method should only be used when
debugging problems.

1. Backup and open $APPL_TOP/admin/_.xml context file

2. Update the context variable:
s_appserverid_authentication

By default in 11.5.10, this is set to SECURE.
In previous 11i versions, this was set to OFF.
For debug purposes, you can use ON or OFF.

Modes:
- ON : Partial
- SECURE : activates full server security (SECURE mode)
- OFF : deactivates server security

3. Run Autoconfig to instantiate the change.

You should now be able to access forms directly again using the f60cgi call.

4. After you have finished your Forms debugging, please reset
s_appserverid_authentication to SECURE and re-run Autoconfig.


Alternative option
---------------------

Running Autoconfig is the preferred method of updating
s_appserverid_authentication.

If you are unable to run Autoconfig during troubleshooting, you can run the
the following commands instead from $FND_TOP/secure directory:

Disable:

java oracle.apps.fnd.security.AdminAppServer apps/apps \
AUTHENTICATION OFF DBC=host_visdemo1.dbc

Enable:

To activate basic server security, from the command line, enter:

jre oracle.apps.fnd.security.AdminAppServer apps/apps \
AUTHENTICATION ON DBC=

To activate full server security (SECURE mode), from the command
line, enter:

jre oracle.apps.fnd.security.AdminAppServer apps/apps \
AUTHENTICATION SECURE DBC=

Check the status:

java oracle.apps.fnd.security.AdminAppServer apps/apps \
STATUS DBC=host_visdemo1.dbc