Professional Documents
Culture Documents
Conc Req
Conc Req
X
Author: Roland Daane Last updated: 20-NOV-2003
Table Of Contents
How To Create Custom Concurrent Requests for Oracle ................................................ 1 Applications Release 11.X .............................................................................................. 1 PURPOSE ...................................................................................................................... 2 Registering Your Concurrent Request............................................................................. 2 Defining the Executable............................................................................................... 2 Defining the Concurrent Program ................................................................................ 3 Assigning the Concurrent Program to a Request Group .............................................. 5 Implementing a SQL*PLUS Concurrent Request ............................................................ 5 Implementing a PL/SQL Concurrent Request.................................................................. 6 Implementing a Host Concurrent Request....................................................................... 8 APPENDIX 1: Sample SQL*PLUS Script ........................................................................ 9 APPENDIX 2: Sample Stored Procedure ......................................................................10 APPENDIX 3: Sample Host Program (UNIX) ................................................................12
PURPOSE
This document discusses steps to set up custom concurrent request that are integrated into Oracle Applications Release 11.0.X. The following discussion is pertinent for all releases of Oracle Applications Release 11 on UNIX. This paper specifically addresses SQL*PLUS, PL/SQL Stored Procedure, and HOST program concurrent request types and generically addresses the steps to register any concurrent request.
Executable Name - is the logical name for the executable, it is informational only. The executable name can be changed after the executable has already been assigned to a concurrent program. Short Name - is the Name that is queried from the executable zone on the Define Concurrent Program form. The Short Name cannot be changed after the record has been saved in the database. Application - is the application that the executable should be registered under. The Application field cannot be changed after the record has been saved in the database, the Application determines the product_top that will be searched when Oracle Applications
attempts to locate the executable i.e. if you specify Application Object Library the $FND_TOP will be searched. Description - field is informational only and can be changed anytime. The Execution Method - determines how Oracle Applications will invoke your concurrent program and also determines which directory under the product top that will be interrogated to find your executable i.e. if the Execution Method is SQL*PLUS then the executable should be located under $PRODUCT_TOP/sql. Execution File Name - is the name of the program unit that will be executed, this is a physical entity and must be located in the correct directory in the file system or database. The Execution File Name can be changed and does not permit the standard extension to be specified, the standard extension should be used when the executable is created in the file system i.e. specify TEST_SQL for the Execution File Name in the form but create a script named TEST_SQL.sql on the file system. Subroutine Name - is only applicable for the spawned and immediate execution methods. After an executable has been defined an executable cannot be deleted once it has been assigned to a concurrent program. If you must delete the executable you would have to delete the concurrent program first. (SEE 6-48 Oracle Applications Systems Administration Guide)
Program - is the logical name for the concurrent request, it is informational only and can be changed at any time. Short Name - is the name that can be used to query the FND_CONCURRENT_PROGRAMS table by CONCURRENT_PROGRAM_NAME column. You can use the information in this table to join other tables by CONCURRENT_PROGRAM_ID (primary key). The short name cannot be changed after the record has been saved in the database. Application - is used to determine what ORALCE user name your program runs in and where to place log and output files. The Application assigned to the concurrent program can be different than the Application assigned to the executable that is assigned to the concurrent program i.e. you can assign executable A (registered under the Application Object Library application) to concurrent program B (registered under General Ledger application). Enabled Check Box - must be checked to be able to submit the concurrent request after it has been defined. If this box is not checked the request will not show up in userslists and does not appear in any concurrent manager queues. Executable Zone - of this form contains the information for the executable that will be invoked by this concurrent program. The executable must have been defined prior to setting up the concurrent program and can be selected from a list of values. Priority - is used to indicate the priority that the concurrent request will be assigned when it is submitted. If you do not assign a priority, the user s profile option Concurrent:Priority sets the request s priority at submission. For detail explanations of the Request zone, Output zone and how to define incompatibilities from this form see (6-53 of the Oracle Applications System Administration Guide).
Use Query from the toolbar, select Find and select the Report Group that you would like to add your concurrent request to. Then place your cursor in the TYPE column and use Edit from the toolbar to create a new record. Specify type as programand then select the concurrent program from the LOV. After you have completed this step you are able to submit the concurrent request from a responsibility that has the request group assigned.
If you want to use parameters with your script first, you must define the parameters for the concurrent request by navigating to the Concurrent:Program:Define form via depressing the parameters button which will display the Concurrent Program Parameters form (see below). For detailed explanation on how to define parameters see page 6-57 of the Oracle Applications Systems Administration Guide.
The key item to remember when defining parameters for SQL*PLUS concurrent programs is that the reference to the parameter being passed to the script is based on the order of the parameters specified in the above form. For example in the above form the parameter for the User ID should be named &1 and Signon Date should be named &2 in the script (See Appendix 1 for example script). The sequence specified in the form does not correlate to the value that should be specified in the script. For example if the sequence for User Id remains 1 and the Signon Date is changed to sequence 5 the names of the parameters in the script should still be called &1 and &2 respectively. If you change the order of the parameters on the form you will have to change the script to reflect the correct names based on the order of the parameters on the form. Lastly, the name of the parameter must be a &number where number is the order of the parameter specified on the form, i.e. the form has 5 parameters the names in the script would be &1, &2, &3, &4 and &5 respectively. If your custom script contains a date format parameter and you want to schedule the request and have the request increment that date parameter the value set used for the parameter must be FND_DATE. Otherwise when you submit the request to be rescheduled and check the box to increment date parameters the date will not change from each execution to the next. The output from any SQL select statements in your script will be written to the output file for the request automatically. It is not necessary to specify an alternate spool file for output unless the client wants the output to be written to a different directory or file name.
should be passed to the procedure. The exception is that the user defined parameters will be the 3 rd thru N parameter passed because the first two parameters are reserved for errbuf and retcode. The errbuf and retcode parameters are not defined on the form (SEE Appendix 2 for example Stored Procedure). For example if you have defined two parameters for your concurrent request called user_id (character) and cutoff_date (date) then your procedure specification should look like this: test_procedure ( errbuf OUT VARCHAR2, retcode OUT NUMBER, uid IN VARCHAR2, cutoffdate IN DATE); The names of the parameters in the form and the names on the procedure are inconsequential, the important thing is that the order and format are correct. If you would like to write messages to the log and output files of your PL/SQL Stored Procedure concurrent request you should use the FND_FILE package to accomplish these tasks. The FND_FILE package is documented in the Oracle Applications Developer s Guide (20-15). The FND_FILE package will only work if the APPLPTMP environment variable is set to a directory value specified for the UTL_FILE_DIR parameter in the INIT.ora file.
Package Body
/* || PACKAGE BODY */ CREATE or REPLACE PACKAGE BODY test_package AS /* || Implementation of purge_signon_data */ PROCEDURE purge_signon_data ( errbuf OUT VARCHAR2 , retcode OUT NUMBER , v_user_name IN VARCHAR2 , v_cutoff_date IN DATE ) IS v_num_recs_deleted NUMBER := 0; -- records deleted v_username VARCHAR2(100); -- user name v_login_id NUMBER := 0; -- login id v_text_msg VARCHAR2(100); -- text message v_error_code NUMBER; -- error code v_error_message VARCHAR2(255); -- error message CURSOR purge_signon_cursor ( v_user_name VARCHAR2, v_cutoff_date DATE ) IS SELECT fu.user_name , fl.login_id FROM fnd_user fu , fnd_logins fl WHERE fu.user_id = fl.user_id AND fu.user_name = UPPER(v_user_name) AND fl.start_time < v_cutoff_date; BEGIN errbuf := NULL; retcode := 0; /* || Open cursor, fetch each r ecord that meets selection criteria, || delete each record that meets selection criteria and commit
|| changes. */ fnd_file.put_line (fnd_file.log , 'Beginning Procedure purge_signon_data' ); fnd_file.put_line (fnd_file.log, ''); fnd_file.put_line (fnd_file.log , 'User Name: ' || v_user_name); fnd_file.put_line (fnd_file.log , 'Cutoff Date: ' || v_cutoff_date); fnd_file.put_line (fnd_file.log, ''); OPEN purge_signon_cursor ( v_user_name, v_cutoff_date ); LOOP FETCH purge_signon_cursor INTO v_username, v_login_id; EXIT WHEN purge_signon_cursor %NOTFOUND; DELETE FROM fnd_logins WHERE login_id = v_login_id; v_num_recs_deleted := v_num_recs_deleted + 1; END LOOP; CLOSE purge_signon_cursor; IF v_num_recs_deleted > 0 THEN COMMIT; v_text_msg := 'Total Records Deleted: ' || TO_CHAR (v_num_recs_deleted , '999,999'); ELSE v_text_msg := 'No Records Matched Selection Cri teria'; END IF; fnd_file.put_line (fnd_file.log, v_text_msg); fnd_file.put_line (fnd_file.log, ''); fnd_file.put_line (fnd_file.log , 'Ending Procedure purge_signon_data' ); EXCEPTION /* || Catch all error. */ WHEN OTHERS THEN ROLLBACK; v_error_code := SQLCODE; v_text_msg := 'Fatal Error, Oracle Error is: ' || TO_CHAR (v_error_code, '99999'); fnd_file.put_line (fnd_file.log, v_text_msg); v_error_message := SQLERRM; fnd_file.put_line (fnd_file.log, v_error_message ); END purge_signon_data ; -- end purge_signon_data END test_package; -- end test_package