Home » Applications » Oracle Fusion Apps & E-Business Suite » Concurrent Manager Failing to Throw Error
| Concurrent Manager Failing to Throw Error [message #201101] |
Thu, 02 November 2006 09:13  |
annagel
Messages: 220
Registered: April 2006
|
Senior Member |
|
|
Not sure if this is an Ebusiness problem, but listing it here because it seemed like the best place to go.
My problem is that the concurrent manager for some reason seems to be catching my unhanded exceptions. As an example I will get a no_data_found exception, the program will stop execution when the exception is encountered, but the concurrent manager displays no error in the log and show a completed status of success. My initial code has NO error handling, if I add an error handler I can catch the error and display the error code/message in the log, but if I don't catch it I get no notification about it from the concurrent manager it just stops executing.
This seems to happen on some but not all of the programs in the system. On the ones in which is occurs it always happens when there is an error, so I am thinking it is perhaps something wrong with the way I am defining the program/executable. I use PL/SQL to do this definition and the code it bellow. Does anyone see anything I might be doing wrong here?
thanks
Andrew
BEGIN
fnd_program.executable
(executable => 'RIDOT_DOCUMENT_GENERATOR',
application => 'RIDOT',
short_name => 'RIDOT_DOCUMENT_GENERATOR',
description => 'The Document Generator will query Object Info from the database and create HTML Documentation for it',
execution_method => 'PL/SQL Stored Procedure',
execution_file_name => 'ridot_documentation_generator.main'
);
fnd_program.REGISTER (program => 'RIDOT Document Generator',
application => 'RIDOT',
enabled => 'Y',
short_name => 'RIDOT_DOCUMENT_GENERATOR',
description => NULL,
executable_short_name => 'RIDOT_DOCUMENT_GENERATOR',
executable_application => 'RIDOT',
execution_options => NULL,
priority => NULL,
save_output => 'Y',
PRINT => 'Y',
cols => NULL,
ROWS => NULL,
style => 'Portrait',
style_required => 'N',
printer => NULL,
request_type => NULL,
request_type_application => NULL,
use_in_srs => 'Y',
allow_disabled_values => 'N',
run_alone => 'N',
output_type => 'TEXT',
enable_trace => 'N',
restart => 'Y',
nls_compliant => 'Y',
icon_name => NULL,
language_code => 'US',
mls_function_short_name => NULL,
mls_function_application => NULL,
incrementor => NULL,
refresh_portlet => NULL
);
fnd_program.add_to_group (program_short_name => 'RIDOT_DOCUMENT_GENERATOR',
program_application => 'RIDOT',
request_group => 'System Administrator Reports',
group_application => 'FND'
);
END;
|
|
|
|
| Re: Concurrent Manager Failing to Throw Error [message #201374 is a reply to message #201101] |
Fri, 03 November 2006 16:24  |
agostino_neto
Messages: 180
Registered: July 2005
|
Senior Member |
|
|
ridot_documentation_generator.main surely have two parameters (perhaps with a different name):
errbuf OUT VARCHAR2
retcode OUT NUMBER
When there is an error, set errbuf to SQLERRM and retcode to 2 for example. You can also print errbuf to log file using FND_FILE API.
|
|
|
|
| Re: Concurrent Manager Failing to Throw Error [message #201404 is a reply to message #201374] |
Sat, 04 November 2006 01:16 |
adragnes
Messages: 241
Registered: February 2005
Location: Oslo, Norway
|
Senior Member |
|
|
| agostino_neto wrote on Fri, 03 November 2006 23:24 | When there is an error, set errbuf to SQLERRM and retcode to 2 for example. You can also print errbuf to log file using FND_FILE API.
|
If there is a fatal error you should set "retcode" to 2. In the concurrent manager form the job will show up as red. If the error is not fatal, but you want to warn the user of some minor error, you should set "retcode" to 1 -- which will cause the job to show up as yellow.
I would not recommend putting SQLERRM into "errbuf" except perhaps during debugging. The content in errbuf should be intelligible for an end user. According to Oracle Applications development standards so should anything written to the log file using the FND_FILE API.
Instrumentation of the code logging debugging information should be logged using the FND_LOG API. This API uses autonomous transactions to write to a table. The good thing about using FND_LOG is that your errors are logged even if your code is used in a form or in a workflow.
--
Aleksander Dragnes
|
|
|
|
Goto Forum:
Current Time: Mon Jul 01 07:07:28 CDT 2024
|
] 
Blog
Search
Help
Members
Register
Login
Home
