Setting Up the Concurrent Executable : The steps to register the executable for a report are as follows:
1. Log on to the Oracle Application, choosing the System Administrator or Application Developer responsibility.
2. The path to follow to the Concurrent Program Executable form is:
System Administrator - Concurrent --> Program --> Executable
Application Developer - Concurrent --> Executable
3. In the Executable field, enter the name of the executable file, leaving off the extension.
4. The Short Name should be the same as the value entered in the Executable field, with the exception of an executable that will be used multiple times.
5. Depending on which function the program is proform,ing the Application field should be
‘ASC Custom – General’
‘ASC Custom – Interfaces’
‘ASC Custom – Invoice Engine’
‘ASC Custom – Migration’
‘ASC Custom – Transition’
6. The Description field should be a user-defined description.
7. The appropriate method should be entered for Execution Method. Possible methods include:
FlexRpt The execution file is written using the FlexReport API.
FlexSql The execution file is written using the FlexSql API.
Host The execution file is a host script (e.g. unix shell script)
Oracle Reports The execution file is an Oracle Reports file.
PL/SQL Stored Procedure The execution file is a stored procedure or function (optionally in a package)
SQL*Loader The execution file is a SQL script.
SQL*Plus The execution file is a SQL*Plus script.
Spawned The execution file is a C or Pro*C program.
Immediate The execution file is a program written to run as a subroutine of the concurrent manager.
8. The Execution File Name is identical to the value entered in the Executable and Short Name fields.
Once this information is saved, Oracle will recognize the executable file.
Setting Up The Concurrent Program : The steps to register the form for a report are as follows:
1. Log on to the Oracle Application, choosing the System Administrator or Application Developer responsibility.
2. The path to follow to the Concurrent Programs form is:
System Administrator – Concurrent -> Program -> Define
Application Developer - Concurrent -> Program
3. The Program Name is the name the user will use to reference the report. It should start with ASC
4. The Short Name is the name associated with the executable.
5. The Application is the same described in step 5 in the previous section.
6. The Description should be the name of the report entered as the Program Name.
7. The Name in the Executable block should be the name of the executable. The Method will default to the value entered as the Execution Method for the executable.
8. In the Request block, if you want to associate the program with a predefined request type, enter the name of the request type in the Type field. The request type can limit which concurrent managers can run your concurrent program (e.g. this is how the US production installation enforces some programs to be able to be run through a “Batch” concurrent manager only).
9. Set the Use In SRS checkbox if users should be able to submit a request to run the program from a Standard Request Submission window (e.g. from a “Reports” menu). If unchecked, the program would probably be started from another program or from a special form, only.
10. If you check the Use In SRS box, you can also check the Allow Disabled Values box to allow a user to enter disabled or outdated values as parameter values.
11. To indicate that the program should run alone relative to all other programs in the same logical database, set the Run Alone box. In most situations, this should remain unchecked.
12. Setting the Enable Trace box turns on SQL tracing when the program runs. This should only be checked on during adhoc, diagnostic purposes.
13. Set the Restart On System Failure box to indicate that the program should automatically restart after a system failure.
14. In the Output block…For Reports, the Format should be text, and the Save and Print boxes should be checked. The Columns, Rows, and Style depend on the layout of the output. Current standards are:
Portrait – 80 columns by 66 lines
Landscape – 132 columns by 45 lines
For programs that are not reports, the Save and Print boxes do not need to be checked.
15. Style Required and Printer are optional. The printer should not be set at this level. This should be done when submitting the request.
Save the form. The report is now registered within the Oracle application.
Adding Parameters to Concurrent Programs : The steps to add parameters to a report are as follows:
1. Log on to the Oracle Application, choosing the System Administrator or Application Developer responsibility.
2. The path to follow to the Concurrent Program form is:
System Administrator – Concurrent -> Program -> Define
Application Developer - Concurrent -> Program
3. Run a query to view the desired report. Click on the Parameters button on the lower right to open the Parameters form.
4. The Program and Application fields are populated automatically.
5. Enter Seq number, Parameter name, and Description. The Sequence number specifies the order in which the program receives parameter values from the concurrent manager. The Parameter name is the name that will display when the application prompts for parameter values. The Description is optional. The Enabled box will be checked by default.
6. In the Validation block, enter the name of the value set you want the parameter to use for validation in the Value Set field. The description will be populated automatically.
7. If you want to set a default value for this parameter, enter it in the Default Type field. Valid types include: Constant, Current Date, Current Time, Profile, SQL Statement, and Segment.
8. If you have chosen a default value other than Current Date or Current Time, enter a default in the Default Value field.
9. If the program executable file requires an argument, check the Required box for the parameter.
10. If the value set allows security rules, you can apply any security rules defined for the value set. If it does not allow security rules, this field is display only.
11. In the Range field, choose either ‘Low’ or ‘High’ if you want to validate your parameter value against the value of another parameter in this structure. Parameters with a range of ‘Low’ must appear before parameters with a range of ‘High’ (the low parameter must have a lower sequence number than the high parameter). For example, if you plan two parameters named "Start Date" and "End Date," you may want to force users to enter an end date later than the start date. You could assign "Start Date" a range of ‘Low’ and "End Date" a range of ‘High’. In this example, the parameter you name "Start Date" must appear before the parameter you name "End Date." If you choose ‘Low’ for one parameter, you must also choose ‘High’ for another parameter in that structure (and vice versa). Otherwise you cannot commit your changes.
12. If this parameter needs to be displayed in the Parameters window when a user submits a request to run the program from the Submit Requests window, check the Display box. The length in characters should be entered in the Display Size, Description Size, and Concatenated Description Size fields. The Prompt field should contain the label the user will see in the Parameters window when submitting a request.
13. For a parameter in an Oracle Reports program, the keyword or parameter appears in the Token field. The value is case insensitive.
14. To enter another parameter, set focus on the Seq field immediately below the one just entered.
Note: The values in the Validation block, Display block, and Token fields are specific to the parameter being entered. When setting focus on the next line to enter Seq and Parameter, these fields will have to be entered again for the new parameter.
15. After all parameters are entered, save the information.
Setting Incompatibilities For A Concurrent Program
This screen identifies programs that should not run simultaneously with your concurrent program because they might interfere with its execution.
1. Log on to the Oracle Application, choosing the System Administrator or Application Developer responsibility.
2. The path to follow to the Concurrent Program form is:
System Administrator – Concurrent -> Program -> Define
Application Developer - Concurrent -> Program
3. Run a query to view the desired report. Click on the Incompatibilities button to open the Incompatible Programs form.
As with the Parameters screen, the Program and Application fields at the top are automatically populated.
4. Although the default for the Application field is the application of the concurrent program, any valid application name can be entered.
5. A value must be entered in the Name field that, with the application, uniquely identifies a concurrent program.
6. Enter ‘Set’ or ‘Program Only’ in the Scope field to specify whether the concurrent program is incompatible with this program and all its child requests (Set) or only with this program (Program Only).
7. Save the form.
Adding The Report To A Program Group
1. Log on to the Oracle Application, choosing the System Administrator responsibility.
2. The path to follow to the Concurrent Program form is: Security -> Responsibility -> Request
3. Run a query using the Application field, entering the application the report will be run in (Oracle Assets - GADFMS, Order Entry Custom, etc.) Alternatively, the default request group can be determined by querying the responsibility (The path to this screen is Security -> Responsibility -> Define). A query can then be run for the Responsibility to add the report to, and then retrieve the default Request Group Name.
Each application should have a general report group defined, usually called ‘All Reports’. Custom request groups can be set up by the System Administrator which allow the report to be run only by certain user responsibilities.
4. Tab the cursor to the first record under the Type column and select ‘New Record’ from the Edit menu option. This will allow a new row to be entered.
5. Set the Type to ‘Program’ or ‘Set’ to add one item.
6. Enter the report name in the Name field, and the application it was registered in (Oracle Assets – GADFMS, etc.) will be populated in the Application field.
7. Save the new record. After logging on to the appropriate application, the user should now see the report listed when submitting a request.
Concurrent Request Sets
Responsibility: (N) Requests->Set
When creating a new Set there are now two options of how the developer may choose to have the individual requests complete. The requests may run in sequence, like in 10.7, or if determined to be more efficient the requests may run in unison.
The best way to create a Set is through the Request Wizard which is located at the bottom of the Request Set block.
Organizing Requests with Stages : Request sets are divided into one or more "stages" which are linked to determine the sequence in which your requests are run. Each stage consists of one or more requests that you want to run in parallel (at the same time in any order). For example, in the simplest request set structure, all requests are assigned to one stage. This allows all of the requests to run in parallel.
To run requests in sequence, you assign requests to different stages, and then link the stages in the order you want the requests to run.
The concurrent manager allows only one stage in a request set to run at a time. When one stage is complete the following stage is submitted. A stage is not considered to be complete until all of the requests in the stage are complete. One advantage of using stages is the ability to run several requests in parallel and then move sequentially to the next stage. This allows for a more versatile and efficient request set.
Using Stage Status : Like request sets and concurrent requests, stages can complete with different statuses. Each stage can complete with a status of Success, Warning, or Error. You can use these completion statuses to structure your request set, by defining which stage will follow the current stage based on its completion status. For example, the request set in the figure below always begins with Stage 1. If Stage 1 were to complete with the status Warning, then the Warning link would be followed, and Stage 3 would be submitted. After Stage 3 completes, the set ends, since there are no links that may be followed.
Linking of Stages : There are no restrictions on linking stages within a request set. Any stage may be linked to any other stage, including itself. Two or more links can point to the same stage. For example, Stage 1 can link to Stage 2 if the completion status of Stage 1 is Success or Warning, and link to Stage 3 if the status is Error.
The developer determines the end of a request set by not specifying a follow-up stage for each completion status. You can end a request set after any stage in the request set. When any stage completes with a status that does not link to another stage, the request set ends.
You can use the linking of stages to control your request set. In previous releases you had three options: run in parallel, run sequentially, and run sequentially but abort on error. All of these are easy to recreate using the request set wizard. You can use the Request Set Wizard button in the Request Set window to start the wizard. The wizard takes your input and creates the request set as follows:
Run in Parallel : Creates one stage containing all of the requests you wish to run in parallel.
Run Sequentially Creates a separate stage containing the request or requests for each step in the sequence and link in the appropriate order.
Run Sequentially but abort on Error Sets up your sequence the same as it did for Run Sequentially, but when it links the stages, it does not enter a follow up stage as a link in the Error completion status field.
Other : There is now an option available to notify an individual(s) of the completion of specific Request Sets. This option is located under Completion Options in the Request submission block.
Printing : Print Options (Style, Printer, and Number of Copies) are located under Completion Options on the Request submission block.
It is possible to reprint a Request without rerunning the Request. From the Request submission block access Special->Reprint. The cursor must be on the Request the user wants to reprint
Output and Statuses : It is still possible to view the Details, Report, or Log of the set on the Request submission block. These are located at the bottom of the block.
It is possible to put on a Hold, or to Cancel a Request from the Request summary block by the buttons located at the bottom of the screen.
Concurrent Managers
Concurrent Managers and the Concurrent Managers Queue can be located through the Request summary block by accessing Special->Managers located on the blocks’ toolbar.
The Requestor field is now under the Details button located on the Request summary screen or the Request Queue which can be located from the Request summary block by accessing: Special->Managers->Managers Queue
The Priority of the Set is displayed under two different views now: the View Details block and the System Administrator responsibility. It is no longer visible in the Request summary block.
The System Administrator responsibility gives both the requestor and priority in the Request summary block. These fields replace the “Parameters” field shown in other responsibilities.
Reports/Report Sets are now termed Requests/Request Sets.
Concurrent Managers Queue : Located in the Concurrent Managers Queue block and also in the Request Queue block is a check box on the upper right side. If this box is checked it will allow the screen to be refreshed automatically. If left unchecked it will refresh only upon a new visit to the block.
Copying a Prior Request : This option is available on the Request submission screen. In addition to the name of the set it also provides dates for which the Set was submitted and also the Parent ID of the Request Set. Copying the Request will also copy the parameters that were entered originally for that report and create a unique Request ID.
Submitting another Request Set :After submission of the first Request Set the user will be brought to the Request summary block. To enter another Request click on ‘Submit Request’. This will bring the user back to the Submit a New Request block.
Submitting Multiple Requests
Profile Option: Concurrent: Show Requests Summary After Each Request Submission
If there is a need to submit multiple Requests quickly there is a User Profile Option that may be switched to ‘No’. This will allow the user to skip the summary block and stay on the submission block to quickly enter Requests. This option will display the Request Set ID as it is submitted and prompt the user to enter another Request or Quit.
Scheduling of a Request Set : Run time of each set can be determined under the heading of Schedule located under the Request summary block. Here the user has 5 options: As Soon As Possible, Once, Periodically, On Specific Days, or Advanced. The capabilities of R.11 are similar to 10.7. It is possible to apply a previously defined and saved schedule to the Set. A schedule must be applied every time a Request is submitted if the schedule is something other that As Soon As Possible.
As Soon As Possible : Will allow the request to begin running immediately following submission.
Once : Provides the user with a start date and time for the request to begin running which the user may change.
Periodically : Provides the user with a start date and time for the request to begin running, which the user may change. There is also a field for a possible end date, though not required. There is an option to re-run the request in an almost infinite range. The user may choose every minute, every twelve months, or greater. It is even possible to have it run every few seconds. If you do not specify a start time, Oracle Applications uses the value from your user profile option Concurrent: Request Start Time or the current time as the default.
The user may also apply the interval from the start or completion of the prior run of that request.
There is an option to increment date parameters on each run. Simply check off the box located on the bottom of the Schedule block. If your request contains date parameters, you can choose "Increment date parameters each run" to have the value for that parameter be adjusted to match the resubmission interval. For example, if the value for the parameter is 25-JUL-1997 07:00:00 and your interval is monthly, the parameter is adjusted to 25-AUG-1997 07:00:00 for the next submission.
On Specific Days : As with the Once and Periodically options, On Specific Days allows you to specify a start time and date and additionally an end time and date if so desired. Also, the user may select to increment the date parameters each run. With this option comes the possibility of choosing to run requests on pre-specified days and times. It is possible to run everyday all the time, or simply at month end. And/or the user may specify which single day of the week to run or multiple days in one week or month, using one schedule. The option to increment date parameters is also available here as in the Periodically option.
Advanced : Reserved for a future release.
Documenting Request Scheduling for Deployment : If a concurrent request or request set should be scheduled to run on a consistent basis at each deployed site, the installation document “Scheduling.doc” MUST be updated.
Request Querying and Viewing :
Profile Options - Concurrent: Show Request Stages
If set to ‘No’, this default operation will allow you to Query->Enter
Query with the Parent Request ID of the completed Set in the Parent field. This will return only the Request Set children that completed normal.
In order to query on a Parent and have it return the Request Stages, the box ‘Include Request Set Stages in Query’, located in the Find Requests block, must be checked.
If any part of your request completes with error, neither the stage nor the stages’ child report will be retrieved when running a specific query for that Request or Set. In order to view the erred request the button ‘Include Request Set Stages’ must be checked and you must perform a ‘Find All’.
Concurrent:Report Access Level
If set to “Responsibility”, you will be able to see the requests and reports of any other user who has submitted a request from the same responsibility.
Access Levels for Viewing Request Information
Viewing ALL Users’ Requests : Responsibility: System Administrator
(N) Concurrent->Requests
Will allow the user to search and retrieve requests submitted by ALL USERS. This is the ONLY responsibility/menu that will show all users’ requests. On this screen, you will be able to enter a “%” in the Request Name field and the screen will accept the wildcard character and run the query for ALL requestors.
Viewing a Specific Individual’s Requests : Responsibility: System Administrator
(N) Requests->View
NOTE: There are comparable menu paths in all applications that provide access to this same screen. It can also be accessed from the Toolbar menu (Help, View My Requests).
Will allow the user to search and retrieve requests submitted only under a specific username.
No comments:
Post a Comment