Parameters for FND_REQUEST.submit_request
--- Mike Leonard mklnrd@hotmail.com wrote:
Hi everyone,
Is there a generic method by which i can find out
exactly what and how
many parameters do I need to pass to a concurrent
program, and in
which order,when I use the
FND_REQUEST.submit_request procedure to
submit requests? Or is it purely trial and error?
We are working on writing custom code to call
several such
programs and need to be able to call them using the
FND_REQUEST.submit_request procedure.
Does anybody know how to do this?
Thanks in advance.
Mike
Date: Wed, 21 Apr 1999 10:10:48 -0700 (PDT)
From: Andy Schindler aschindl@yahoo.com
Subject: Re: Parameters for FND_REQUEST.submit_request
Things I do to prepare for an automated submission:
1) Run it normally.
2) From sysadmin, review the way the parameters look
in the review request form.
(Navigate-Concurrent-Requests)
Highlight the request of interest and press Open.
3) Review the log file.
Note the module short name.
4) Review the parameters and order in the define
concurrent program window.
Andy Schindler
NRC, Inc.
Date: Wed, 21 Apr 1999 11:04:39 PDT
From: "Mike Leonard" mklnrd@hotmail.com
Subject: Re: Parameters for FND_REQUEST.submit_request
I tried that for running OrderImport in OE once. It just doesnt work.
The records didnt get processed. Then I tried running OrderImport
online and all the records got processed immediately. Which means
there was definitely something wrong with my parameters. And I finally
figured out the right combination for that. But my basic problem still
remains.
Mike.
Date: Wed, 21 Apr 1999 12:51:19 -0700 (PDT)
From: Andy Schindler aschindl@yahoo.com
Subject: Re: Parameters for FND_REQUEST.submit_request
I am sorry. I misunderstood your basic request. Let
me try again.
At this time, what you are asking for (a comprehensive
documentation of how to automate Oracle's internal
processing programs) DOES NOT exist. The Technical
Reference Manuals (TRM's) are a good starting place.
The Application Object Library Reference Manuals and
Open Interface Manuals are also required reading. But
bottom line, it takes trial, error, raw experience,
and a lot of testing to automate most of the import
programs.
In launching processes from FND_REQUEST, it takes more
than just getting the parameters in the correct order.
You also need to ensure that your profile options are
set appropriately as well.
In Oracle's support, the background processes in apps
are designed to be launched from within the
application where Oracle can manage all of the
details.
I share your pain and frustration.
Good luck.
Andy Schindler
NRC, Inc
Date: Wed, 21 Apr 1999 16:28:47 -0400
From: Sateesh Reddy sreddy@camail2.harvard.edu
Subject: Re: Parameters for FND_REQUEST.submit_request
Hi
In "Oracle applications Coding standards" book
you can get the information about FND_REQUEST Package and other related
functions.\
you may find it usefull.
Sateesh Reddy
x-------------x
Date: Tue, 4 May 1999 10:17:50 -0400Registering Shell Script
From: "MCQUILLAND.ACIO.TSAINC.COM" MCQUILLAND@tsainc.com
Subject: Registering Shell Script
Date: Mon, 26 Apr 1999 14:01:43 -0400 (EDT)
Hello,
In what directory do you place a shell script if you are
trying to
register it in an application. For example sql*plus files that are
registered
go in the SQL directory of the top for that particular module. Any
help
appreciated.
Thanks DAN MCQUILLAN
From: Manoj J [mailto:msolanki@hotmail.com]
Sent: Monday, April 26, 1999 2:28 PM
Subject: Re: Registering Shell Script
Hi,
I can tell you how we have done it. Normally, one would have XXX_TOP
defined (for example XXX represents the company you are working for)
in the sys admin register applications screen. we stored the shell
scripts in that xxx_top directory. I also believe that if you have
written a script for AP then you can store it in AP_TOP (Correct me if
I am wrong)
Date: Mon, 26 Apr 1999 15:47:16 -0400
From: "Cotten, Jim" Jim.Cotten@respironics.com
Subject: RE: Registering Shell Script
It doesn't matter what module the script was written for, I say you
always put it in the custom directory. The only things in the module
top should be that which Oracle has seen fit to bestow. If you do this,
you will never clobber you files during an upgrade or patch application.
Most of the time I feel that using guidelines religiously is
debilitating, but in this case I believe that it is warranted.
Date: Mon, 26 Apr 1999 16:47:39 -0400
From: "Camara, Juan (CAP, GEFA)" Juan.Camara@gecapital.com
Subject: RE: Registering Shell Script
To answer your original question -
Plase the shell script on the bin directory - such as XXX_TOP/bin
Just like you would place the SQL script on the XXX_TOP/sql directory
- jc
Date: Tue, 27 Apr 1999 04:56:24 -0500
From: John Stouffer jstouffe@csac.com
Subject: DBA: Shell Scripts
Dan,
put them in a custom directory that has been defined
in your APPLSYS.env file under the bin sub-directory.
don't use .sh extenstions and don't use names longer
that 8 characters to avoid issue with the concurrent managers.
good luck.
thx,
John
Securing Attributes
Subject: SYSADMIN
Author: "Mohit Takyar" mtakyar@qir.com at smtplink-micros
Date: 4/27/99 12:04 PM
I would appreciate if someone could explain to me the importance of
"Securing Attributes" in the alternate region of Define User Form.
Thanks in Advance,
Mohit
Date: Tue, 27 Apr 1999 13:32:02 -0400
From: NSmith@micros.com
Subject: Re: SYSADMIN
Mohit,
They can be used when implementing the Oracle Self Serve Web
Applications (OSSWA). For instance, by setting the
ICX_CUSTOMER_ORG_ID to a particular customer's internal record ID, you
can limit that user's ability to view only their customer data (i.e.
sales orders, invoices, and payments).
This is the only reason we've had to make settings in the "Securing
Attributes" section. There may be others as well.
The securing attributes in 10.7 were only visible from within the
OSSWA and it was only in 11.0 that they appeared in the Define User
Form. In 10.7 OSSWA's had a different system administration
interface, only accessible from a browser.
Hope this helps.
Best Regards,
Neil
Change of Architecture
From: Manish Deora [mailto:manish_deora@hotmail.com]
Sent: Friday, April 30, 1999 12:25 PM
Subject: 11.0.2 change of architecture
Hi,
we currently have following architecture.
server1:
Database server
administration server
concurrent processing server
server2:
web server
forms server
We want to change this architecture to logical tire
i.e we want to have all this on single server.
how to do this, can anyone guide us?
Looking forward for your valuable suggestion.
Thans in Advance.
MAnish Deora
Date: Fri, 30 Apr 1999 13:59:51 -0400
From: "Ellis, Rob" Rob.Ellis@Cognos.COM
Subject: RE: 11.0.2 change of architecture
We operate 10.7 NCA all on one Solaris box. It is necessary to have two
oracle homes. One for the database and one for the forms/web servers.
Rob Ellis
Date: Fri, 30 Apr 1999 13:30:09 -0500
From: "Logan, Ernie" Ernie_Logan@bmc.com
Subject: RE: 11.0.2 change of architecture
Interesting. That is not true on HP-UX 11.0. Wonder why the requirement on
Sun? We do have separate ORACLE_HOME per instance on the same box.
Ernie Logan, Jr. | She put me on Earth to accomplish
Ernie_Logan@bmc.com | a certain number of things. Right
(713) 918-3649 | now, I'm so far behind, I will never
918-1313 (FAX) | die.
Date: Fri, 30 Apr 1999 14:35:14 -0400
From: "Mark Conger" mconger@invacare.com
Subject: RE: 11.0.2 change of architecture
R11 is a bit different from 10.7 from what I understand. We run 10.7 NCA
here, but have our DB tier and Middle-tier on separate boxes. The reasoning
is the versions of the backend D2K runtimes has to be different under 10.7
than the middle-tiers. Under R11 I think everything runs off the Dev2K
1.6.1. We also have to maintain separate APPL_TOPs for DB and Middle
tier's, etc. R11 integrates all that stuff together... :)
Mark Conger
Date: Fri, 30 Apr 1999 14:46:00 -0400
From: "Ellis, Rob" Rob.Ellis@Cognos.COM
Subject: RE: 11.0.2 change of architecture
That's right. In 10.7 Oracle reports run by the concurrent manager must use
report 2.5 from D2K 1.3 while the forms server required in the mid-tier
comes from D2K 1.6.1. D2K 1.3 and D2K 1.6.1 cannot live in the same Oracle
home thus you MUST have two Oracle homes to install them on the same box.
Yes I here thinks are different in 11. :)
Rob Ellis
Date: Fri, 30 Apr 1999 14:16:51 -0500
From: "Uptmore, Chris" uptmorec@kci1.com
Subject: RE: 11.0.2 change of architecture
For 10.7 NCA:
one ORACLE_HOME is for the Character Forms2.3 (and dbs);
the other ORACLE_HOME is for the GUI Forms 4.5
Report Listner AND Help files
Subject: Report Listener in Rel.11
Author: Mohammad Faisal Yasin fyasin@ora-tech.com at smtplink-micros
Date: 5/5/99 5:54 AM
Hi, All
Please tell me how to configure. Report Listener in
Rel. 11 concurrent processing tier.
Im facing troubles viewing my rewuests.
aand another thing
how do i set up help files , i've installed them in OA_DOC but
when ever i press help button it opens another browser window
and search for some other URL. which is not belongs to our
network.
Thanks
Date: Wed, 5 May 1999 09:15:21 -0400
From: NSmith@micros.com
Subject: Re: Report Listener in Rel.11
Mohammad,
Regarding the Report Listener, you need to make an entry for it in
the "listener.ora" and "tnsnames.ora" files. See Oracle Installation
documentation Something like:
listener.ora extract:
...
(SID_LIST =
(SID_DESC =
(PROGRAM=/u10/applmgr/11.0/fnd/11.0.28/bin/FNDFS)
(GLOBAL_DBNAME = FNDFS_hpk570)
(SID_NAME = FNDFS)
(ORACLE_HOME = /u10/applmgr/11.0/fnd/11.0.28)
(PRESPAWN_MAX = 10)
)
...
tnsnames.ora extract:
...
FNDFS_hpk570=
(DESCRIPTION=
(PROGRAM=FNDFS)
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=HPK570)
(PORT=1526)
)
)
(CONNECT_DATA =
(SID=FNDFS)
(GLOBAL_NAME=FNDFS_hpk570)
)
)
...
Also, to view the reports from a browser, set the SYSTEM PROFILES
listed below to 'Browser':
Viewer: HTML
Viewer: PDF
Viewer: PostScript
Viewer: Text
Regarding the help, you need to set the SYSTEM PROFILE:
'Help System Base URL'
to the location of your help files. As an example, ours is set to:
'http://hpk570:8788/OA_HELP/help/'
Best Regards,
Neil
APPLSYS.FND_CONC_PP_ACTIONS TABLE
From: Bharat Patel[SMTP:bpatel@DOMINOAMJET.com]
Sent: Wednesday, May 05, 1999 12:37 PM
Subject: APPLSYS.FND_CONC_PP_ACTIONS TABLE
Hi, Guys My above mentioned table is reached it's maxextents and I am
trying
to find out from the technical reference manual that's I have ( for
release
10 and update to 10.7) but it doesn't mention this table at all.
we are on release 11.0.
Any body I do delete/truncate this table will impact to others programs?
thanks in advance.
Bharat Patel
D.B.A.
bpatel@dominoamjet.com
847-244-2501 ex 1249
Date: Wed, 5 May 1999 15:54:34 -0400
From: Margaret Murray mmurray@delorme.com
Subject: RE: APPLSYS.FND_CONC_PP_ACTIONS TABLE
Bharat,
When we upgraded to applications, these table became huge due to a bug.
You'll notice (if you look) that jobs that are re-submitted will have a
printer added on for ever resubmission. Check it out under Requests, view
Details, Print To: (or click on completion options). Print To will show a
number of printers.
Here's a cut from an e-mail I sent to someone else having the same problem:
It took us MONTHS to get support to see this as a problem - we ended up with
1.6 million rows in FND_CONC_PP_ACTIONS before they got us a patch to fix
it. We're on Solaris (you didn't mention your platform) and the bug/patch
was 764355. FND_CONC_PP_ACTIONS will get purged by the Purge Concurrent
Manager and/or Manager Data routine, but you may need to rebuild it if your
has grown as large as ours did - the usual number of rows it contains is
about 50,000 rows - lots less than the 1.6 million it grew to!
In case they never find the patch there are two work arounds. You can set
the number of copies on the report to zero. You must remove the printer from
the Completion Options section of submit Request; from the Printer field
chose edit from the menu bar, then clear record. The second work around is
to have the job not print by unchecking the print box - got to programs,
define; query the program and uncheck the box and save. This makes it so
the program will never print. OK for batch jobs that do processing, not OK
for reports.
Margaret Murray, DBA
DeLorme Mapping
Capturing User ID
From: server@ibm6000.cpa.qc.ca [mailto:server@ibm6000.cpa.qc.ca]On
Behalf Of Mohan_Rajaganapathy@notes.seagate.com
Sent: Wednesday, May 05, 1999 9:27 PM
Subject: Capturing User Id
Hello Friends,
I have a small question to all of you here. How do
i
capture the user id when the user logs on
in oracle apps.If anybody has done this before pls help me out
Thanks in Advance
Mohan
From: CFowler@littonapd.com [SMTP:CFowler@littonapd.com]
Sent: Thursday, May 06, 1999 10:55 AM
Subject: RE: Capturing User Id
I have a related question. Does anyone know how to find out which
user
has
a lock on a record?? This would be very handy when a user gets the
message
"Can't reserve record x times. Keep retrying? Yes or No" and asks you
who
has the record tied up.
From: Palad, Ed (FUSA) [SMTP:EdPalad@firstusa.com]
Sent: Thursday, May 06, 1999 11:07 AM
Subject: RE: Capturing User Id
Candace,
Try this sql statement. from Oracle Perf. Tuning by O' Reilly.
WHAT.SQL
ed
Here, just substitute CONPEQ with the user id
log on in apps,
if you want too see every user then just take the first line.
SELECT /*+ ORDERED */
s.sid, s.username, s.osuser,
nvl(s.machine, '?') machine,
nvl(s.program, '?') program,
s.process F_Ground, p.spid B_Ground,
X.sql_text
FROM sys.v_$session S,
sys.v_$process P,
sys.v_$sqlarea X
WHERE s.username = 'CONPEQ'
AND s.paddr = p.addr
AND s.type != 'BACKGROUND'
AND s.sql_address = x.address
AND s.sql_hash_value = x.hash_value
ORDER
BY S.sid;
Forms Server Processes
Date: Mon, 10 May 1999 07:21:00 -0400
From: "Mary Shamray" mshamray@penton.com
Subject: Forms Server Processes
I have run into a problem with trying to shutdown my database cleanly. It has
to do with the f45runw proceesses. If a user reboots their pc without logging
out of the apps, it can leave the f45runw processing still running. Oracle (at
least for me) will not shutdown if there are any of these running. Any ideas on
how to clean these up so I can bring the database down cleanly without having to
call in to kill the f45runw processes?
Thanks in advance.
Mary
Date: Mon, 10 May 1999 14:34:17 +0100
From: jdstuart@globalnet.co.uk
Subject: RE: Forms Server Processes
Mary,
As you have found, if a user doesn't shut down properly or their PC crashes
the f45runw process may be left running. This in turn maintains a database
connection, thus you won't be able to shutdown the database 'normally',
you have to use 'shutdown immediate'.
There are other problems that can crop up too. If the PC crashes while a
user is updating a record any associated row locks will be left on,
preventing users from accessing the record while f45runw is running. Also,
after a while these 'rogue' processes may start spinning, taking up as many
CPU cycles as they can get.
To avoid these problems I suggest you do kill rogue f45runw processes, I
haven't found this approach to do any harm. You can check for redundant
processes by the time/date stamp on the process or by looking at the log
file (if your form server is in log mode). To check for spinning processes
look for how much CPU they are using.
I believe one of the later versions of the forms server includes a
'hearbeat' facility to avoid this problem. Then, the form server checks if
the client is 'alive' every 15 minutes, or whatever, and if the client is
no longer there the forms server process stops.
I hope this helps.
Jonathan.
Date: Mon, 10 May 1999 07:47:30 PDT
From: "J P Bhamu" jpbhamu@hotmail.com
Subject: RE: Forms Server Processes
Just to add on what Jonathan has written. Before killing a rogue process(or
spinning process which is sometime takes all the cpu resources) do check in
the v$transaction table just to cross verify that no activity is going on
for that process/session.
thanks
Date: Mon, 10 May 1999 11:48:50 -0400
From: "Mary Shamray" mshamray@penton.com
Subject: RE: Forms Server Processes
Bharat/Jonathon/Varun/J P,
Thanks for your suggestions. What I am doing now, is shutting down the
concurrent managers before I do a shutdown immediate of the database. The
database does not come down if there are any f45runw processes. The only way I
can think of to bring the database down, is to grep for f45runw and kill these
processes manually. Is there a way to automate this? (HP-UX 11, RDBMS 8.0.4.2.1)
Thanks again,
Mary
Date: Mon, 10 May 1999 19:16:10 +0100
From: "Jonathan Stuart" jdstuart@globalnet.co.uk
Subject: Re: Forms Server Processes
Mary,
The following will produce a script which will kill ALL existing f45runw
processes on your server, and then runs that script. These commands could be
entered manually or put into a shell script and automated. There are other
ways to do this and you could make it more selective if you have multiple
instances on your server, etc, but this is a start.
ps -eaf| grep f45runw | awk '{print "kill -9 " $2}' killf45runw.sh
chmod 744 killf45runw.sh
./killf45runw.sh
Jonathan.
Date: Mon, 10 May 1999 14:31:50 -0400
From: "Scott Wright" swright@skidmore.edu
Subject: RE: Forms Server Processes
Mary,
First... be careful with this information! I could be be wrong and I don't
know much about your situation.
I don't know your platform, but the following may help... I got this info.
about the "Forms Server Heartbeat" from Oracle support in reference to a
problem that I was having where clients were being disconnected (...not your
situation but I think this applies anyway). According to this info. it seems
that if you're set to the default then the offending process should die
after 15 minutes without a heartbeat.
BTW - I've also heard that there is a problem setting the FORMS45_TIMEOUT to
more than 59.
I also think that Oracle will do a "shutdown immediate" even if the f45runw
processes are still there.
You might also consider running a Perl script or something like it to detect
and kill all the f45runw process before shuting down the instance.
Hope this helps!
Here's the info. Oracle sent me:
------------
Forms Server Heartbeat
----------------------------------------------------------------------------
The Problem
Customers have been finding that on NT, if a Forms Server session is
initiated and the client for any reason goes down, the f50web32.exe process
remains in memory until it is manually killed via the Task Manager.
The Fix, Server
A time-bomb has been placed in the server which will cause it to exit after
a default span of 15 minutes assuming no messages have been received from
the client within that timeframe. As soon as a message is received, the
time-bomb resets itself to 15 minutes and starts ticking again.
The Fix, Client
Given that users occasionally may spend more than 15 minutes away from their
machines, a heartbeat thread has been installed inthe client that sends a
simple message every 2 minutes, thereby resetting the server-side time-bomb.
If, of course, the client goes down, the bomb will tick away to zero, and
the f50web32 process will quietly exit.
The Interface
You cannot turn off the heartbeat feature. It is always running on both the
server and client sides. You can however vary the length of time it takes
for the server process to exit. On NT:
* Create a new registry entry under HKEY_LOCAL_MACHINE\\SOFTWARE\\ORACLE as
a DWORD value.
* Name it FORMS50_TIMEOUT. (FORMS45_TIMEOUT, FORMS60_TIMEOUT for 1.6, 6.0
respectively)
* Give it an integer value representing the length of time in minutes until
timeout between 3 and 1440 (1 Day) inclusive.
On Solaris:
* Create an environment variable FORMS50_TIMEOUT. (FORMS45_TIMEOUT,
FORMS60_TIMEOUT for 1.6, 6.0 respectively)
* Give it an integer value representing the length of time in minutes until
timeout between 3 and 1440 (1 Day) inclusive.
Availability
Developer 1.6: Forms 4.5.9.10.0 patch.
Developer 1.6.1: Forms 4.5.10.8.0 patch and later.
Developer 2.0: Forms 5.0.5.6.0 patch and later.
Developer 2.1 Forms 5.0.6.9.0 patch and later.
Developer 6.0 and beyond - all base releases.
NOTE: The heartbeat implementation is available for all platforms for 1.6.1.
For 2.0 and higher it is currently NT only, although porting to other
platforms is planned.
--------------------------------------
Scott Wright
Database Administrator
Skidmore College
Saratoga Springs, NY 12866
swright@skidmore.edu
Phone: (518) 580-5927
Fax: (518) 580-5936
Date: Mon, 24 May 1999 15:25:18 -0400
From: "Mary Shamray" mshamray@penton.com
Subject: RE: forms server processes
Thanks again to all who helped me resolve this issue. The solution provided by
Jonathan worked like a charm! Those defunct f45runw processes were killed and
the database came down with out any problems. Thanks again!
Mary