Oracle E-Business Suite System Administrator's Guide - Configuration Release 12.1 Part Number E12893-04 | Contents | Previous | Next |
A concurrent program is an executable file that runs simultaneously with other concurrent programs and with online operations, fully utilizing your hardware capacity. Typically, a concurrent program is a long-running, data-intensive task, such as posting a journal or generating a report.
Standard Request Submission (SRS) is an Oracle E-Business Suite feature that allows you to select and run your concurrent programs from a single, standard form (Submit Request) or window (Schedule Request). Requests to run concurrent programs are called concurrent requests.
There are two main ways to group concurrent programs. Request sets are defined to run several concurrent program in a single request. Request groups are used to control access to concurrent programs via responsibilities. Both request sets and request groups are discussed in later sections
Related Topics
Organizing Programs into Request Sets
System Administrator Request Set Privileges
Organizing Programs into Request Groups
Copying and Modifying Program Definitions
Running Reports and Programs, Oracle E-Business Suite User's Guide
You can restrict users' access to submit and view concurrent requests.
Note: This method is used in releases prior to Release 12.
A request security group is a collection of reports or concurrent programs. A System Administrator defines request security groups in order to control user access to reports and concurrent programs. Only a System Administrator can create a request security group.
The reports and concurrent programs that may be selected by a user in Standard Request Submission belong to a request security group, which is a request group assigned to a responsibility.
Important: The use of request security groups is for backward compatibility only.
The reports and concurrent programs that may be selected from a customized SRS form or window belong to a request security group that uses a code.
RBAC allows administrators to have more granular control in securing data related on concurrent programs and requests.
Administrators can assign individual programs/sets, all programs/sets in a request group, programs/sets belonging to one or more applications, and so on, either to the user directly or to a role that can then be assigned to one or more users. For more information on RBAC, see: Overview of Access Control with Oracle User Management, Oracle E-Business Suite System Administrator's Guide - Security.
If applications are included in the request groups, all programs/requests sets that are created in these applications will also be automatically included. Please note that request submission applies to both programs and request sets.
The following types of "instance sets" can be used for assignment (but administrators can create new instance sets based on their needs):
All programs in a particular request security group
All request sets in a particular request security group
To enable this functionality, the following are seeded:
Permission "Submit Request"
Permission "View Request"
Permission Set "Request Operations" containing the permissions "Submit Request" and "View Request"
Object "Concurrent Programs"
Object Instance Set "Programs that can be accessed"
Object Instance Set "Request sets that can be accessed"
To grant access to a request security group to a role, follow these steps:
Define your role (User Management responsibility).
Define your request security group (System Administrator responsibility).
Define your grant (Functional Administrator responsibility).
Enter a Name and Description (optional) for the grant.
Enter the Security Context for the grant.
Under Data Security, choose "Concurrent Programs" or "Request Sets" as the object. Click Next.
For the Object Data Context, select "Instance Set" for the Data Context Type. Choose either "Programs that can be accessed" or Request Sets that can be accessed" as appropriate. Click Next.
Review the Instance Set information. Under Instance Set Details, enter the request group and its application. Specifically, enter the request group name as Parameter 1 and the application short name as Parameter 2.
Choose "Request Operations" as the permission set under "Set". Click Next.
Review the grant information and save your work.
Note that there are two seeded grants for all users to account for request group assignments that already exist for legacy responsibilities. These are:
Programs - Grant Defaults
Request Sets - Grant Defaults
You can control users' access to viewing requests with RBAC.
Note: In previous releases, the Concurrent: Report Access Level profile was used to control privileges to report output files and log files generated by a concurrent program. This profile is no longer used.
Seeded "instance sets" allow administrators to grant:
All requests submitted by a user
All requests submitted by a user for a given application
All requests belonging to a program submitted by a user
All requests belonging to a request set submitted by a user (irrespective of the constituent programs' owning application)
to another user (or a group of users - via a role).
System administrators can create new "instance sets" based on their needs. They can grant access to requests (of a particular program/set) submitted by all users to a specific set of users. For example, say a given application's administrators group want to track all requests of a particular type or program submitted by business users. Then the following approach, to grant specific programs' requests to a group of users, can be used:
Create an instance set that selects all the requests belonging to the particular program irrespective of which user submitted it.
For example,
&TABLE_ALIAS.request_id in
( select cr.request_id
from fnd_concurrent_requests cr, fnd_concurrent_programs cp
where cr.concurrent_program_id = cp.concurrent_program_id
and cr.program_application_id = cp.application_id
and cp.concurrent_program_name = &GRANT_ALIAS.PARAMETER1)
If you want to grant access to a set of programs instead of a single program, '&GRANT_ALIAS.PARAMETER1' can be replaced with a subquery that returns all the programs in a particular request group.
Create a grant to grant this instance set to (an existing) role, for example, "<Application> Administrator" role, and assign the program name to grant. Use the "Concurrent Requests" data object in creating this grant.
Ensure that the role is assigned to all users that should have access to these requests.
As System Administrator you can limit the number of requests that may be active (status of Running) for an individual user. This ensures that a user cannot monopolize the request queue. For example, if a user with an Active Request Limit of 5 submits 20 requests, only 5 requests will be run at the same time. The remaining requests will be run when the number of active requests for the user drops below 5. Use the Profile Options window to set the Concurrent: Active Request Limit profile. To set a global limit for all users, set this option at the site level. You can then modify limits for individual users by setting this profile option at the User level.
Reports and concurrent programs can be assembled into request sets.
Request sets define run and print options, and possibly, parameter values, for a collection of reports or concurrent program. End users, with the appropriate privileges, and System Administrators can define request sets. A System Administrator has request set privileges beyond those of an end user. Request sets can be run from Forms-based applications and HTML-based applications.
Request sets are a quick and convenient way to run several reports and concurrent programs with predefined print options and parameter values. Request sets group requests into stages that are submitted by the set. The order in which the stages are submitted is determined by the status of previous stages.
Request sets can also be used by a System Administrator to customize access to reports and concurrent programs. Using request sets, a System Administrator can:
grant users of a responsibility the ability to run selected reports and concurrent programs that are outside their request security group.
grant access to requests and other concurrent programs on a user-by-user basis.
guarantee that reports in the set run with print options and parameter values that cannot be edited by end users.
As System Administrator, you have privileges beyond those of your application users, including a privileged version of the Request Set window.
You can run the same set of concurrent requests regularly by defining a request set, and then submitting the request set from the Submit Requests form.
As System Administrator, you can include any Standard Request Submission report or concurrent program in the request sets you define. When end users define a request set, they can only select from reports and programs that belong to their responsibility's request security group.
Use the Request Set form to create and edit request sets.
This section describes how request set stages are defined and organized.
Request sets are divided into one or more "stages" which are linked to determine the sequence in which 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 a single stage. This allows all of the requests to run in parallel.
Request Set with a Single Stage
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.
Request Set with a Sequence of Stages
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.
Request Set with Multiple Requests Running in Parallel within a Stage
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: a request set always begins with Stage 1. If Stage 1 completes with the status Success, then the Success link is followed, and Stage 2 is submitted. After Stage 2 completes, the set ends. If Stage 1 completes with Warning, then the Warning link is followed, and Stage 3 is submitted. After Stage 3 completes, the set ends. If Stage 1 completes with Error, then the Error link is followed, and Stage 4 is submitted. After Stage 4 completes, the request set ends.
Request Set Using Stage Statuses
In this example, the stage status is determined using the Standard stage function. The Standard stage function uses the statuses of the requests within the stage to calculate the status for the stage. If all of the requests in a stage complete with a status of Success, then the status for the stage is Success. If one or more requests complete with a status of Error, then the status of the stage is Error. For a stage's status to be Warning, one or more of the requests must have a status of Warning, and no request may have a status of Error.
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.
Request Set with Multiple Links to Stages
You determine the end of a request set by not specifying a followup 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:
Variable | Description |
---|---|
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. |
The completion status of a stage is determined by a predefined function. The Oracle E-Business Suite Standard Stage Evaluation function uses the completion status of the requests it contains. Use this function to determine the status of a stage.
When a stage completes with a status for which there is no link defined, the request set ends. The completion status for the request set is determined by one of the following methods:
Using the completion status of the last stage run in the request set. This method is used by default.
The user can override the default behavior by defining a specific stage within the set to be "critical". If the request set has a single critical stage defined, and then runs this critical stage, then the completion status of the set will be the same as the completion status of the critical stage. This can be useful if the final stage of the set is a "clean up" stage and is not considered important to the overall status of the set.
If a request set has more than one critical stages defined, the "worst" completion status of all the critical stages is considered the completion status of the set.
On a report-by-report basis, you can select a different printer for each report in a request set. When you define a request set, print options, such as the printer a report is sent to, are saved so you do not have to specify them again when you run the request set.
Important: If a printer is defined for a concurrent program using the Concurrent Programs form, then that value cannot be updated, either by a user profile option setting, a request set definition, or when running the program or request set.
Note: Defining a printer for a request set concurrent program (for example, Request Set Payables Aging Reports) in the Concurrent Programs form has no effect; the printer definition is not referred to.
In some circumstances, such as when a request set has a large number of stages and takes a long time to execute, administrators may want to yield a request set to higher priority requests. By utilizing the Hold Request Set feature, users can place a running request set on hold and effectively control the execution of request set stages.
The Hold and Remove Hold buttons are available on the OAM View Running Requests page. To hold a request set, simply select the request set and click the Hold button. Click Remove Hold when you want the request set to continue executing.
When you define a request set or a stage within a request set that allows incompatibilities, a concurrent program is created to run the requests in your request set according to the instructions you enter.
All concurrent programs that run request sets are titled Request Set <name of request set>, and programs that run request set stages are titled Request Set Stage <name of request set stage>. In the Concurrent Programs form, to query request set or request set stage concurrent programs on the basis of a program's name, enter the following in the Name field:
"Request Set" or "Request Set Stage" before the name of the concurrent program
"Request Set %" or "Request Set Stage %" to perform a query on all request set programs
Request set and request set stage concurrent programs create log files documenting the execution of the request set or stage. Each report or concurrent program within a request set or stage also creates its own log file.
Note: The recorded actual start time for a request is the start time the request's status is changed to "Running". A request may need to wait to start until it has necessary information from child process(es).
When you run a request set that allows incompatibilities, you submit a request to run the concurrent program that defines the request set. The request set concurrent program submits a request set stage concurrent program. The request set stage concurrent program submits the requests for the individual programs and reports within the stage. A request to run the request set concurrent program or the request set stage concurrent program is a Parent request, while the requests to run the programs and reports are Child requests.
You can review the status of a request set and the programs it contains using the Concurrent Requests form. The following table displays information pertaining to request sets in the Running phase.
Status | Description |
---|---|
Paused | Parent request pauses for all its Child requests to complete. For example, a request set stage pauses for all reports in the stage to complete. |
Resuming | All requests submitted by the same Parent request have completed running. The Parent request resumes running. |
A request set can only be modified by its owner or by a System Administrator. To make modifications, query the request set you want to modify in the Request Set window.
Note: If you wish to retain modifications to request sets provided by your Oracle application during upgrades, you must rename or recreate the request set using a different name before you upgrade. If you modify a predefined request set without changing the name, your modifications are overwritten when you upgrade your Oracle E-Business Suite.
Follow this procedure to create a request set:
Navigate to the Request Set window.
Enter a Name for your request set.
Enter a Set Code for your request set. This name is used internally to reference your request set.
Enter the Application with which you want to associate your request set.
Enter a Description of your request set if you like.
The Owner field defaults to your username and can only be changed by your system administrator.
Enter the Active Dates From and To fields to define an effective period when you and others can run the request set. If the current date is outside the range you define, the request set will not be available in the Submit Requests window. Note that the request set will not be available on the date specified in the To" field.
Check the Print Together check box to send all your requests to the printer together when they complete, or uncheck the check box to send each request one at a time to the printer as it completes.
Check the Allow Incompatibility check box to allow your system administrator to specify programs that this request is incompatible with (may not run with). Leave Allow Incompatibility unchecked to specify that this request set may run with all other concurrent requests or request sets.
Choose Define Stages or Link Stages if you have finished defining your stages.
Follow this procedure to define stages:
The value for the Display Sequence is defaulted in sequence as you enter your stages. You may change the display order of the stages by modifying this field.
Enter a Name for the stage.
Enter a Description of your stage if you like.
Enter a Stage Code for the stage. This code is used internally to reference the stage.
In the Function field of the Function region, use the List of Values to select a function. The default value for this field is the Standard Stage Evaluation function. This function bases its completion status on the normal completion status of the requests it contains. Other functions may be provided by your Oracle product. For a description of these functions, refer to the user's guide for that product.
Use the "The Return Value of this Stage Affects the Set Outcome" check box if you want to ensure that the request set's completion status is equal to the completion status of this stage.
Note: If you choose this check box for more than one stage, the completion status of the request set will equal the completion status of the last of these stages to run within the set.
Use the Allow Incompatibility check box to allow your system administrator to specify programs that this stage is incompatible with (may not run with). Leave Allow Incompatibility unchecked to specify that this stage of the request set may run with all other concurrent requests or request sets.
Choose Requests.
In the Stage Requests window you define which requests you want to include in the stage.
Select the report or program you want to include in your request set. A description of the request you choose and its associated application appears in the Description and Application fields.
The list of requests you can choose includes the requests that your responsibility's request group lets you access from the Submit Requests form.
Use the Allow Stage Function to Use This Program's Results check box to indicate which programs or reports should be included.
The Print Options region reflects the options for the current request. Specify the number of Copies of output to print, the Style to print, the Printer to print to, and whether to save the output to an operating system file.
Standard Request Submission saves these options so you do not have to specify them again when you run the request set. If you do not wish to specify these options for each request when you define the set, Standard Request Submission uses the values of your personal profile options as the default when you submit the request set. See: Concurrent Processing User Profile Settings, Oracle E-Business Suite System Administrator's Guide - Maintenance.
Note: Some requests may have a required Style or Printer that you cannot change.
When you are done with the Print Options, choose Parameters to display the Request Parameters window.
The Request Parameters window lets you customize the parameter values of a specific request in a request set. The fields at the top of the Request Parameters window list general information about the current request set and the request for which you can customize the parameter values. The multi-row portion of the window lists the parameters for that request.
The Sequence field displays the order in which each request parameter appears when you run the request in the Submit Requests window (lower numbers appear before higher numbers). Only your system administrator can change a parameter's order.
The Prompt field is a display-only field that shows the request parameter's prompt.
Check the Display check box to specify that you can see a request parameter at submission time, or uncheck the check box to specify that a parameter should not be displayed at submission time.
Check the Modify check box to specify that you can insert or change the value for a request parameter at submission time, or uncheck the check box to specify that a parameter cannot be changed at submission time.
Use the Shared Parameter field to set a default value for a parameter that occurs in more than one report or program of a request set. Once you enter the same parameter label in the Shared Parameter field for each occurrence of the same parameter, the value that you assign to the first occurrence of the parameter becomes the default value for all subsequent occurrences of the parameter. The shared parameter label simply enables you to set an initial default value for all occurrences of the same parameter so you can avoid typing the same value all over again for every occurrence of the parameter.
For example, suppose you define a request set that includes three reports, and all reports include a parameter called “Set of Books". You want the “Set of Books" parameter to default to the same value in all reports. To accomplish this, enter a label called “Book" in the Shared Parameter field for the first occurrence of this parameter. You can also assign a value in the Default Value field of this parameter now, or wait until you run the request set to assign a default value when the parameter first appears. Enter the label “Book" in the Shared Parameter field of all other occurrences of the “Set of Books" parameter in your request set. When you submit this request set from the Submit Requests window, every parameter that you label “Book" defaults to the value you assign to the first occurrence of the “Set of Books" parameter.
Important: Note that if you later change the value of a parameter that contains a shared parameter label, you change only the value for that instance of the parameter, and not the value for all other occurrences of that labelled parameter.
We recommend that if you make a parameter with a shared parameter label modifiable, that you also display the parameter so you can always see what the parameter's current value is. This helps reinforce the understanding that a later value change to one labelled parameter cannot propagate a value change to all other similarly labelled parameters.
Optionally enter a Default Type and Value for the parameter.
Save your work.
Go back to the Stage Requests window and repeat Steps 9 through 11 to add more requests to the request set stage.
You can select a request more than once if you want to run the same request with different default parameter values.
To start a new stage, return to the Stage window and choose New Record from the File Menu.
Follow this procedure to link stages:
Enter the Start Stage. The stage you enter here is the first stage submitted for the request set.
Enter the stages you want to run following the first stage in the Success, Warning, and Error columns. To ensure that a particular stage follows the preceding stage regardless of the completion status, enter the desired stage in all three columns. To stop the request set if a stage ends in Error, leave the Error column blank. Any time you do not specifically indicate which stage should follow for a completion status, the request set will exit on that completion status.
In the example shown in the table below, the request set will always exit if any stage returns a completion status of error. In addition, stages C and D will terminate the request set regardless of their completion status. If Stage A returns a status other than Error, Stage B will be submitted. Finally, when Stage B completes with a status of Success, it is followed by Stage C, or if the status is Warning, Stage D will follow.
Choose Done.
The following table shows an example of linking stages as in step 2 above:
Display Sequence | Name | Success | Warning | Error |
---|---|---|---|---|
1 | Stage-A | Stage-B | Stage-B | |
2 | Stage-B | Stage-C | Stage-D | |
3 | Stage-C | |||
4 | Stage-D |
If a request set completes with a status of Error, the Restart button, on the Oracle Applications Manager - View Completed Requests page is enabled. The system also automatically captures, records, and saves the information of the first stage that fails so that when the user clicks on the Restart button the request set can restart from that point.
Once the stage has been identified, the request set program submits the stage program in resubmit mode. In this mode, the program looks at the same stage from the previous run and determines which programs need to be rerun, (only those that ended in error), and runs those programs. If this stage completes successfully or has a Warning status, the system proceeds to the next stage using the normal mechanism of restarting the request set program.
Note: Users may restart a request set multiple times. The logs for each stage and individual programs are maintained independent of the number of runs as each stage and program submission generates a new request. However, the logs and associated files for a request set are rewritten each time the set is restarted.
Related Topics
Overview of Concurrent Programs and Requests
There are significant differences between end user and System Administrator privileges when defining or editing request sets.
An end user can create a request set by selecting reports, other request sets, or concurrent programs that are part of the report security group assigned to his or her responsibility.
When an end user creates a request set, the user automatically becomes the “owner" of the request set. Ownership is identified by the person's application username.
End users use the Request Set form to create a new request set, or to query and update any request sets they own. End users can only edit request sets they own.
We sometimes refer to a request set that an end user owns as a private request set. Private request sets are not automatically added to a request security group. That is, other users cannot access your private request sets using the Submit Requests window unless the System Administrator assigns that request set to a request security group.
Request sets owned by an end user are always available to that user, regardless of what responsibility the user is operating under. However, a standard submission form customized to display only reports in a request group using a code does not display private request sets.
When a user signs on to Oracle E-Business Suite, the user can run requests, request sets, and concurrent programs included in:
his or her responsibility's request security group
any request sets they own.
Private request sets offer two main benefits to end users:
The request sets that users own are always available to them, regardless of which responsibility they are working under.
Users can create as many request sets as they want without adding request set choices to the list of standard submission concurrent programs that other users must select from.
As System Administrator, you can:
create request sets that include any reports or concurrent program.
query and edit all request sets using the Request Set form.
permit and define incompatibility rules for individual request sets. See: Request Set Incompatibilities.
After you define a request set, you can assign a user to be its owner if you want the user to be able to run or edit this request set from any responsibility. Request sets without an owner cannot be edited or updated by any end users. In this way, you can guarantee print options and report parameters for a request set. You can also later edit the request set to remove or change its ownership properties.
Other users can also run a request set if you, as System Administrator, assign the request set to their responsibility's request security group. If you do not assign a request set to a request security group, then only the owner can run the request set. In this way, you can grant access to reports and concurrent programs on a user-by-user basis.
As System Administrator you can add any request set, including private request sets, to a request security group. This allows you to provide members of a responsibility access to reports and programs outside their request security group.
Request set editing and report viewing privileges are different for reports that belong to a user's request security group than they are for reports that are not in the user's request security group.
cannot edit the request set.
cannot run an individual report by itself, but can only run the entire request set.
can add any other requests in their request security group to the request set.
can delete any request from the request set, regardless of whether that report is in their request security group.
can update print options or parameters for an individual report in the request set, if the report is in their request security group.
cannot run an individual report by itself, but can only run the entire request set.
Request sets offer three main benefits to System Administrators:
Request sets offer a means of controlling access to concurrent programs on a user-by-user basis.
By defining a request set, assigning it an owner, and then not assigning the request set to any request security group, the reports and programs in the request set are only available to the owner.
By leaving the Owner field blank, System Administrators can create request sets whose individual programs and parameters cannot be edited or updated by end users.
Only a System Administrator can edit a request set that has no owner.
System Administrators can provide members of a responsibility access to reports and programs outside their request security group.
By defining a request set that contains reports or programs not in a request security group, and assigning that request set to the request security group, users can be granted run, but not edit privileges for selected reports or programs.
A request set is actually a concurrent program that submits requests to run each program in the request set. You can allow incompatibility rules to govern your request set so that the request set does not run at the same time as other reports or concurrent programs. You can also apply these rules to the stages that make up the request set.
Use the Concurrent Programs form to query the request set concurrent program and list those programs, and/or stages you want to define as incompatible with your request set. See: Concurrent Programs.
All concurrent programs that run request sets are titled Request Set <name of request set>. In the Concurrent Programs form, if you query a request set concurrent program on the basis of the program's name, you must enter in the Name field the words:
"Request Set" before the name of a concurrent program
"Request Set %" to perform a query on all request set programs
When you list a program as incompatible with your request set, the program will not run simultaneously within the same conflict domain as the request set or any of the reports within the set. See: Defining Program Incompatibility Rules.
Related Topics
Overview of Concurrent Programs and Requests
Defining Program Incompatibility Rules
Parameters, also referred to as arguments, are values that define aspects of a program's execution. You can share a parameter and its entered value among some or all of the requests in your request set.
You identify a parameter as shared by giving it a label. Then, for each concurrent program in your request set, you can assign the same label to a parameter for that program. Among the programs in your request set, the parameters for each program share or accept a common value.
The first time you enter a value for any of the shared parameters, that value becomes the shared parameter's value. This is useful, because you only have to enter a value once, rather than for each program in the request set.
Selecting a value for a shared parameter provides a default for subsequent occurrences of the parameter. Changing a shared parameter's value provides a new default for subsequent occurrences of the parameter, but does not affect prior requests in the set.
Once all the shared parameters contain values, changing the value for a shared parameter has no effect on the other shared parameters.
Important: Do not hide shared parameters. Do not set shared parameters to Display = No (which prevents modifying the value) or Modify = No. This prevents updates to shared parameters, which are not propagated to other reports in the set, from generating unwanted inconsistencies.
We've created a request set containing two reports, a Concurrent Programs Report and the Concurrent Program Details Report. The two reports and their parameters are listed in the table below:
REPORT | PARAMETERS |
---|---|
Concurrent Programs Report | Application Name |
Concurrent Program Detail Report | Application Name, Program |
We identify the parameter Application Name as a parameter shared between the two reports. We want to enter a value only once, that is, when the Report Parameters window appears for the first report in the set, requiring us to enter Application Name.
To identify a shared parameter, we give it a name, in this example, applname, and enter it as a Shared Parameter for each report.
Related Topics
Overview of Concurrent Programs and Requests
Control the Behavior of Request Parameters
This report documents request set definitions, including the set's owner, program incompatibilities, as well as printer and print style information. Use this report when defining or editing request set definitions.
None.
The report headings provide you with general information about the contents of the report.
Related Topics
Overview of Concurrent Programs and Requests
Organizing Programs into Request Sets
This essay explains how you can organize your applications programs and reports into request groups. It presents the following topics:
Request Security Groups
Using Codes with Request Groups
Customizing the Submit Requests Window using Codes
Report Group Responsibilities report
When defining a request group, you can include:
all the reports and concurrent programs owned by an application
individual reports and concurrent programs
request sets, which are collections of reports and concurrent programs that may be selected from an application user's request security groups
request set stage functions, which are used to calculate the status of stages within a request set.
A request group is used by Oracle E-Business Suite at two different levels:
Responsibility level
When a request group is assigned to a responsibility, it is referred to as a request security group, and it defines the reports, request sets, and concurrent programs that a user, operating under that responsibility, can select from the Submit Requests Window.
Form level
When a request group is assigned a code, that code can be passed as a parameter to the Submit Requests Window. The code helps define the function that calls the Submit Requests Window.
The list of values for that unique Submit Requests Window lists the reports, request sets, and concurrent programs in the request group.
When a request group is assigned to a responsibility, the request group is referred to as a request security group. Any user signed on under a responsibility can run the reports and concurrent programs contained in their responsibility's request security group.
The Submit Requests standard submission form displays a list of all the reports and programs in the current responsibility's request security group.
Related Topics
Using Codes with Request Groups
Customizing the Submit Requests Window using Codes
Report Group Responsibilities Report
Normally, when a menu calls the standard request submission form, that form can list the reports and concurrent programs contained in the report security group for the current responsibility.
Alternatively, you can assign a code to a request group so that a customized standard submission form only displays a list of concurrent programs contained in that particular request group. A request group code is simply an argument that is passed from a menu to a customized standard submission form. To summarize:
Request group codes provide a form-based method of controlling user access to concurrent programs and reports.
A code can be assigned to a request group.
You can use the code as an argument passed from a menu to the standard submission form.
When a menu that calls the standard submission form uses the code, that form lists only those programs in the request group identified by the code.
Related Topics
Organizing Programs into Request Groups
Customizing the Submit Requests Window
Customizing the Submit Requests Window using Codes
You can customize the Submit Request window in several ways.
You can change the title to reflect the requests available in the window. See: Customizing the Submit Requests Window using Codes.
You can restrict the reports and programs available to those in a specified request group. See: Customizing the Submit Requests Window using Codes.
You can call Submit Requests form for a single request submission by passing the program/set name as parameters
The parameters window pops up on navigation to the form when called with a program/report_set name. The form exits after the user acknowledges the displayed request ID for the submitted request.
You can call Submit Requests form to submit one or more requests for a single program/set by passing the program/set name as parameters
The parameters window pops up on navigation to the form and the user can submit one or more requests for the program that was passed as a parameter. Requests for other programs cannnot be submitted in this case.
You can pass additional parameters to the Submit Requests form that can be referenced in the value sets to validate the request parameters.
You can pass 5 ORG related parameters and refer to them in the value set. Alternatively, you can bring up a ORG LOV on navigation to the Submit Requests form that populates the ORG parameters which can be referenced in the value sets.
Below is the comprehensive list of parameters supported by the "Run Requests"/SRS form and additional information about their usage.
REQUEST_GROUP_CODE
REQUEST_GROUP_APPL_SHORT_NAME (used with REQUEST_GROUP_CODE)
CONCURRENT_PROGRAM_NAME
PROGRAM_APPL_SHORT_NAME (used with CONCURRENT_PROGRAM_NAME)
REQUEST_SET_NAME
SET_APPL_SHORT_NAME (used with REQUEST_SET_NAME)
SUBMIT_ONCE (default 'N').
SUBMIT_ONCE can be set to either Y or N ( N is the default).
SUBMIT_ONCE is used in conjunction with CONCURRENT_PROGRAM_NAME or REQUEST_SET_NAME.
If SUBMIT_ONCE is set to Y, then the form will exit after the Submit button is clicked.
TITLE
LOOKUP (default 'N')
USE_ORG, ORG_ID, ORG_NAME, ORG_CODE, CHART_OF_ACCOUNTS_ID (five parameters)
If USE_ORG is set to 'Y' (default is 'N') then the Submit Requests form checks to see if the other ORG parameters are set. If the parameters are not set, then it attempts to populate the parameters from the globals (GLOBAL.FND_ORG_ID, GLOBAL.FND_ORG_NAME, etc.). If the globals have not yet been set, the an ORG LOV shows, and both the parameters and the globals are populated from the LOV.
Values sets should always reference the parameters, not the globals.
CHAR1, CHAR2, CHAR3, CHAR4, CHAR5
DATE1, DATE2, DATE3, DATE4, DATE5
NUMBER1, NUMBER2, NUMBER3, NUMBER4, NUMBER5
In your value sets, refer to these parameters as:
:PARAMETER.CHAR1, :PARAMETER.DATE1, :PARAMETER.NUMBER1 etc.
You can give the Submit Requests Window a different title, and define the form so that it allows users to select only those reports or concurrent programs belonging to a request group that you have assigned a code to. To do this, you register a form function that references the Submit Requests Window, and you pass certain arguments to the function. Then you construct your menu to include this form function. For more information, see: the Oracle E-Business Suite System Administrator's Guide: Security.
The following table describes the parameters passed to associate a request group with the Submit Requests Window and to customize the title of that form. Text is entered in the Parameters field of the Form Functions form.
Parameter Syntax followed by Example | Explanation |
---|---|
REQUEST_GROUP_CODE ="Request Group Code" REQUEST_GROUP_CODE = "OE_CONC_PROGRAMS" | This parameter passes the request group's code. (Required) |
REQUEST_GROUP_APPL_SHORT_NAME = "Application short name" REQUEST_GROUP_APPL_SHORT_NAME = "OE" | This parameter identifies the short name for the application associated with the request group. (Required) |
TITLE ="Application_short_name:Message_Name" TITLE = "FND:SRS_NEWTITLE" | This parameter identifies a message whose contents define the title, as well as the application short name of that message. (Optional) |
LOOKUP = "Y|N" LOOKUP = "Y" | This parameter indicates whether the TITLE parameter is a message name or a hardcoded string. The default value is "Y", which indicates that TITLE is a message name. (Optional) |
Related Topics
Customizing the Submit Requests Window
Organizing Programs into Request Groups
Using Codes with Request Groups
Report Group Responsibilities Report
This report lists those responsibilities which have access to a report or a request set. Use this report when granting access privileges to reports and request sets, either by assigning reports and request sets to request security groups, or when assigning owners to a request set.
Choose the application name associated with the report or request set.
Either choose the name of a report or request set.
Related Topics
Overview of Concurrent Programs and Requests
Organizing Programs into Request Groups
This essay explains how you can define incompatibility rules for your concurrent programs and reports.
When a concurrent program is incompatible with another program, the two programs cannot access or update the same data simultaneously.
When you define a concurrent program, you can list those programs you want it to be incompatible with. You can also list the program as incompatible with itself, which means that two instances of the program cannot run simultaneously.
You can also make a program incompatible with all other concurrent programs by defining the program to be run-alone.
There are two types of program incompatibilities, "Global" incompatibilities, and "Domain-specific" incompatibilities.
You can define a concurrent program to be globally incompatible with another program -- that is, the two programs cannot be run simultaneously at all; or you can define a concurrent program to be incompatible with another program in a Conflict Domain. Conflict domains are abstract representations of groups of data. They can correspond to other group identifiers, such as sets of books, or they can be arbitrary.
You define a concurrent program to be run-alone or to be incompatible with specific concurrent programs by editing the concurrent program's definition using the Concurrent Programs window. See: Concurrent Programs.
Program incompatibility and run-alone program definitions are enforced by the Conflict Resolution Manager (CRM).
Note: The concept of "Global" incompatibilities was introduced with Patch 2364876.
With this patch, all pre-existing incompatibilities are converted to the type Global, unless both of the programs have a conflict domain parameter registered. This may mean that if you have been using the Concurrent:Conflicts Domain profile option for your custom programs, you may need to switch the incompatibility type to "Domain-specific" to keep the expected behavior.
Also, the two user-level constraints, set by the Concurrent:Active Request Limit and Concurrent:Sequential Requests profile options, are now enforced globally across all conflict domains.
When you define a request set or request set stage that allows incompatabilities, you create a concurrent program that runs the reports in your request set or stage according to the instructions you entered. Using the Concurrent Programs window, when you list programs as incompatible with a request set, those programs are prevented from starting until all the reports in the set or stage have completed running.
To define incompatibility rules for a request set and request set stage:
For a request set check the Allow Incompatibility check box on the Request Set window.
For a request set stage check the Allow Incompatibility check box on the Stages window.
Navigate to the Incompatible Programs block in the Concurrent Programs form and list those programs that your request set or stage is incompatible with.
All concurrent programs that run request sets are titled Request Set <name of request set> while all concurrent programs that run request set stages are titled Request Set Stage <name of stage>-Request Set <name of request set>. In the Concurrent Programs form, if you query a request set or stage concurrent program on the basis of the program's name, you must enter in the Name field the words:
"Request Set" or "Request Set Stage" before the name of a concurrent program
"Request Set %" to perform a query on all request set and stage programs
Related Topics
Overview of Concurrent Programs and Requests
Modifying an Incompatible Programs list
If two programs are defined as incompatible with one another, the data these programs cannot access simultaneously must also be identified.
In other words, to prevent two programs from concurrently accessing or updating the same data, you have to know where, in terms of data, they are incompatible. A Conflict Domain identifies the data where two incompatible programs cannot run simultaneously.
In Oracle E-Business Suite, data is stored in database tables that belong to a particular application. Each table may also contain information used to determine what conditions need to be met to access the individual records. These conditions may consist of one or more of the following data groupings:
SOB - based on the profile option GL_SET_OF_BOOKS
Multiple installations (referred to as MSOB)
Multiple Operating units (determined by profile option MO_OPERATING_UNIT) (referred as MULTIORG).
Multiple Orgs (determined by profile option INV_ORGANIZATION_ID, Used by Manufacturing Applications)
HR may use business group as a conflict resolution domain
FA may use FA book
etc...
A conflict domain is an abstract representation of the groupings used to partition your data. There is no limit to the number of domains that can be defined, but excessive domains may hurt performance.
All programs are assigned a conflict domain when they are submitted. If a domain is defined as part of a parameter the concurrent manager will use it to resolve incompatibilities. If the domain is not defined by a parameter the concurrent manager uses the value defined for the profile option Concurrent:Conflicts Domain. Lastly, if the domain is not provided by a program parameter and the Concurrent:Conflicts Domain profile option has not been defined the 'Standard' domain is used. The Standard domain is the default for all requests.
All programs use the Standard conflict domain unless a value is defined for the profile option Concurrent:Conflicts Domain or a conflict domain is defined through a program parameter.
Each request submitted uses parameters which identify the records that it will access. For programs that are defined with incompatability rules an additional parameter (conflict domain parameter) is used. The conflict domain may be set automatically based on such variables as a login ID, set of books, or the organization the user is working in. The conflict domain parameter may in some cases be selected in the parameters field of the Submit Requests form. Once the parameter is determined the Conflict Resolution Manager (CRM) uses the domain to ensure that incompatible programs do not run simultaneously in the same domain.
Concurrent managers read requests to start concurrent programs running. The Conflict Resolution Manager checks concurrent program definitions for incompatibility rules.
If a program is identified as Run Alone, then the Conflict Resolution Manager prevents the concurrent managers from starting other programs in the same conflict domain.
When a program lists other programs as being incompatible with it, the Conflict Resolution Manager prevents the program from starting until any incompatible programs in the same domain have completed running.
The figures below illustrate the role of the Conflict Resolution Manager when enforcing program incompatibility rules.
In a simple example without incompatibilities, a user submits a request to run a program. This request is then added to the request table which contains a list of requests. Managers then read requests from this table and start the associated concurrent programs.
A more complex example users may have submitted one request with incompatibility rules and another request to run a program that must be run alone. In this case these requests are added to the request table, but the Conflict Resolution Manager then checks the statuses of the requests in the table and marks which requests are ready to be run. The concurrent managers then read only the "ready" requests and start their concurrent programs.
Simple Run Program Request
Complex Run Program Request
Related Topics
Overview of Concurrent Programs and Requests
Copying and Modifying Program Definitions
Modifying an Incompatible Programs list
This section provides information for system administrators on custom concurrent programs. It explains certain procedures and conventions for creating customized concurrent programs:
For information on creating custom concurrent programs, see the Oracle E-Business Suite Developer's Guide.
For information on setting up the development environment , see the Oracle E-Business Suite Concepts Guide.
Log and output files must have specific names and locations for users to review the files online.
If you use the Oracle Application Object Library routine fdpwrt() to write to files, the concurrent managers automatically name the files according to the operating system's naming conventions. This method of writing to files is completely portable. You do not have to rewrite your programs to name your log and output files differently if you port your application to another platform.
Standard names for log and output files are listed in the following table:
File Type | Location | Filename |
---|---|---|
Log | Default: $<PROD>_TOP/$APPLLOG with Common Directory: $APPLCSF/$APPLLOG | l<request ID>.req |
Output | Default: $<PROD>_TOP/$APPLOUT with Common Directory: $APPLCSF/$APPLOUT | Default: <USERNAME>.<request ID> or O<request ID>.out or user.out based on value of APPCPNAM |
The variable parameters shown in this table have the following values:
<PROD>_TOP - The application's top environment variable.
<Request ID> - The number that identifies the concurrent request.
<USERNAME> - Up to eight characters (uppercase) of the application username of the person who requested the concurrent process.
On UNIX platforms, the filenaming works as described in the following table:
APPCPNAM Variable Assignment in UNIX | Output File Format |
---|---|
APPCPNAM = "REQID" | o999999.out |
APPCPNAM = "USER" | <Applications user>.out |
APPCPNAM = "USER.REQID" | <Applications user>.999999 |
(unset or unrecognized syntax) | o999999.out |
In the above table, <Applications user> refers to an Oracle E-Business Suite user name and '999999' stands for a concurrent request ID.
On Windows platforms, the default format is o<request ID>.out. Setting APPCPNAM to USER on a Windows platform results in the output files having the format <user ID>.out.
If you write concurrent programs in PL/SQL, SQL*Plus, or Oracle Reports, name the program exactly as you identified it in the Execution File field of the Concurrent Program Executable window, plus an extension if necessary.
The following table lists the file extensions used for these programs and the directories where the programs should reside. (This does not apply to PL/SQL stored procedures, which are stored in the database.) The directories are under your custom application's TOP directory, $<PROD>_TOP.
If you use shared PL/SQL libraries with your Oracle Reports programs, and you want to include the libraries you write for your custom application, place the libraries in the $APPLPLS directory under your custom application's TOP directory.
Tool | Extension | Directory | Comments |
---|---|---|---|
SQL*Plus and PL/SQL | .sql | $APPLSQL | The program name is case sensitive and must exactly match the Execution file you defined with Oracle Application Object Library. |
Oracle Reports | .rdf | $APPLREP | Oracle Application Object Library looks for the .rdf file first. It uses the .rex file if it does not find the .rdf file. The program name is case sensitive and must exactly match the execution file name you defined with Oracle Application Object Library. |
SQL*Loader | .ctl | $APPLBIN |
When you write a concurrent program in Pro*C, copy the skeleton programs EXMAIN.c and EXPROG.c from the directory $FND_TOP/$APPLUSR. Rename the files and globally replace SUBROUTINE_NAME with the name of your subroutine.
EXMAIN.c is the skeleton used for your spawned programs. EXPROG.c is the skeleton used for your program's logic. This module can be used to create a spawned or an immediate program. For immediate programs, you must include your copy of EXPROG.c in a program library. See below for information on building a program library.
You can use programs written with these skeleton programs as spawned or immediate concurrent programs. Spawned programs run as a separate process while immediate programs run linked in with a concurrent manager.
Important: Oracle provides information on immediate concurrent programs for backwards compatibility only. We strongly recommend that you do not create any new immediate concurrent programs. You should define your new Pro*C concurrent program executables as spawned.
Name your program's executable file exactly as you identified it in the Execution File field of the Concurrent Program Executable window. Put your executable file in the $APPLBIN directory under your application's TOP directory.
Register a new program library with the Register Concurrent Program Library form and register all the programs you want to include in this library. Then enter "Yes" in the Rebuild field and commit. This creates a request to build a new catalog file called <Library Name>.c under $<PROD>_TOP/$APPLLIB$ . You should compile the <Library Name>.c file after the request completes.
Sample program libraries such as prgcat.c and prglib.c are located under $FND_TOP/$APPLUSR.
Tip: For ease of maintenance, define your concurrent program executables as spawned.
Your environment for compiling custom code depends on the file $FND_TOP/usrxit/devenv. If you change this file, you should reread it by logging in again so that the changes take effect.
You compile your C or Pro*C programs into object modules using $FND_TOP/usrxit/Makefile. You then link your programs using adrelink. We do not support both compiling and linking executables using a single makefile or utility.
To compile the C program example.c, use the following syntax. In all the examples, you should run the commands from the directory in which your files are located.
$ make -f $FND_TOP/usrxit/Makefile example.o
To compile the Pro*C program proexamp.pc, use the following syntax:
$ make -f $FND_TOP/usrxit/Makefile proexamp.o
To compile the four C and Pro*C programs a.c, b.c, c.pc, d.pc (all of which are in the current directory), use the following syntax:
$ make -f $FND_TOP/usrxit/Makefile a.o b.o c.o d.o
If you want your spawned concurrent program to run as a stand-alone program, perform the following steps before compiling your stand-alone executable.
For custom concurrent programs you define under your custom application (as recommended), you should copy the sample.mk file from $FND_TOP/usrxit to your $<PROD>_TOP/$APPLLIB directory. Modify your copy according to the instructions contained in the file. This is the file adrelink uses to link your stand-alone executables.
Then enter the following commands.
$ . $FND_TOP/fndenv
Move to the directory in which your source files are kept.
$ cd <source_directory>
$ make -f $FND_TOP/$APPLLIB/Makefile <source file>.o
Here, <source file> is the name of the file containing your program and <directory> is the directory where the source file is located.
You can then link your stand-alone executable and place the executable in the $APPLBIN directory under the TOP directory for your custom application:
$ adrelink force=y "<appl_short_name> <program name>"
In this relink command, <appl_short_name> is the application short name of the application your program belongs to, and <program name> is the program name.
To create a program library, you link your compiled library catalog with your program object files using an Oracle Application Object Library link procedure.
Important: Oracle provides information on immediate concurrent programs for backwards compatibility only. We strongly recommend that you do not create any new immediate concurrent programs. You should define your new Pro*C concurrent program executables as spawned.
Make sure the environment variable $LUSRLIB includes the modules that define the functions for the immediate concurrent programs and your program library. Set the $LUSRPRG variable to include the object modules of your library catalog. The file devenv in the directory $FND_TOP/$APPLUSR defines the variables $LUSRLIB and $LUSRPRG. The file fndenv executes devenv.
The files devenv and fndenv are UNIX shell scripts that set up the necessary environment variables.
We recommend that you make a copy of the working program library before linking your new immediate concurrent program library in case your new program library does not function as expected. To link your program library, execute this command from the operating system:
$ adrelink force=y "fnd UFNDLIBR"
This creates your new program library as UFNDLIBR. You can rename it, but the name of your new program library must be eight characters or less.
You can use the following method to test your program. You must pass each argument needed by your program. To pass parameters, enter the following at the operating system prompt:
$ <program name> <ORACLE username>/<ORACLE password> 0 Y \
[<parameter 1> <parameter 2>... ]
Instead of the Oracle username and password, you can use an Oracle E-Business Suite username and password, if the corresponding user has the System Administrator responsibility.
The program name must be uppercase and the same name that you entered in the Execution File field of the Concurrent Program Executable window. The 0 and Y arguments are required.
If any of your program-specific parameters includes spaces, enclose that parameter in double quotes. If a parameter contains a literal double quote, precede that mark with a backslash [\].
Name your program <name>.prog, where <name> is the value you enter in the Execution File field of the Concurrent Executable window. Then make a symbolic link using your execution file name (without an extension) to fndcpesr, which is located in the $FND_TOP/$APPLBIN directory. Put your executable file and the linked file in the $APPLBIN directory under your application's TOP directory.
For example, name your custom shell script CUSTOM.prog. Create a symbolic link to fndcpesr named CUSTOM. Place both files in your $APPLBIN directory. Create your concurrent program executable using the execution file CUSTOM.
The concurrent manager running your program puts your program name in $0, the four arguments orauser/pwd, userid, username, and request_id in $1 to $4, and your program specific parameters in $5 and beyond. Each of these arguments can be at most 50 characters.
For example, if you pass two parameters into your program, you use $5 to refer to the first parameter and $6 to refer to the second parameter.
In some cases, there are security concerns with passing your Oracle username and password directly to your HOST program. If you do not want the concurrent manager to pass your username/password to your program, you can have the manager pass it as an environment variable instead. Or you can pass an Oracle E-Business Suite username/password for a user with the System Administrator responsibility. Alternatively, you can not pass it at all.
First, define your concurrent program executable as a HOST program in the Concurrent Program Executable form.
To have the username/password passed as an environment variable, enter the term 'ENCRYPT' in the Execution Options field of the Concurrent Programs window when defining a concurrent program using this executable. 'ENCRYPT' signals the concurrent manager to pass the username/password in the environment variable fcp_login. The argument $1 is left blank.
If you do not want the username/password passed to the program at all, enter 'SECURE' in the Execution Options field. The concurrent manager will not pass the username/password to the program.
By default, a shell script returns success (status code 0). If your script traps an error, use the UNIX exit command "exit 1" to return failure (status code 1) to the concurrent manager running the program.
Use names in FCP_LOG and FCP_OUT. This way log and output/report files can be viewed online.
You should test using the <name>.prog file to make sure your script behaves correctly.
You can test your concurrent program by submitting the program using the CONCSUB utility from the operating system.
You can submit a concurrent request to run any concurrent program by running the CONCSUB program with the following syntax:
$ CONCSUB <APPS username>/<APPS password> \
<responsibility application short name> \
<responsibility name> \
<username> \
[WAIT=N|Y|<n seconds>] \
CONCURRENT \
<program application short name> \
<program name> \
[PROGRAM_NAME="<description>"] \
[REPEAT_TIME=<resubmission time>] \
[REPEAT_INTERVAL= <number>] \
[REPEAT_INTERVAL_UNIT=< resubmission unit>] \
[REPEAT_INTERVAL_TYPE=< resubmission type>] \
[REPEAT_END=<resubmission end date and time>] \
[NLS_LANGUAGE=<language of the request>] \
[NLS_TERRITORY=<territory of the request>] \
[START=<date>] \
[IMPLICIT=< type of concurrent request> \
[<parameter 1> ... <parameter n>]
For parameters that follow the CONCURRENT parameter and include spaces, enclose the parameter argument in double quotes, then again in single quotes. Oracle Application Object Library requires this syntax because it parses the argument string twice. For example, to pass this argument to a program:
This is an example
pass this argument through CONCSUB:
'"This is an example"'
Here is an example of the command to run CONCSUB:
$ CONCSUB APPS/APPS \
SYSADMIN \
"System Administrator" \
SYSADMIN \
WAIT=N \
CONCURRENT \
FND \
FNDFMRTC \
PROGRAM_NAME='"Register Custom Tables Weekly"' \
REPEAT_INTERVAL=7 \
REPEAT_INTERVAL_UNIT="DAYS" \
REPEAT_INTERVAL_TYPE="START" \
START='"08-JUN-96 23:55:00"'
CGL
APPLSYS
ALL
CGL
The following entries explain the required and optional parameters for submitting a concurrent program with CONCSUB. Default values are listed to the right.
Variable | Description |
---|---|
username/ password | Required. The ORACLE username and password that provides access to the data that your program uses. Alternatively, an Oracle E-Business Suite username and password for a user with the System Administrator responsibility. |
responsibility application short name | Required. The application short name of the responsibility whose concurrent processing options you want to use. |
responsibility name | Required. The name of your responsibility. If the name of your responsibility includes spaces, enclose that name in double quotes. |
username | Required. The uppercase username of the application user whose concurrent processing options you want to use. |
WAIT | Optional. A flag that indicates whether to wait for the submitted request to complete. If you leave this parameter out, the default value of N makes CONCSUB return you to the operating system prompt without waiting for your request to complete. Set WAIT=Y to have CONCSUB check the request status every 60 seconds and return you to the operating system prompt when your request is completed. You can also enter an integer value for a number of seconds, as in WAIT=30, for CONCSUB to check for request completion every <number> seconds. Important: Using WAIT=Y or WAIT=<number> requires that your request completes before CONCSUB returns you to the operating system. If the concurrent manager is down, your CONCSUB process waits indefinitely until the concurrent manager is started and the request completes. |
CONCURRENT | Required. A flag that separates the program-specific parameters from the operating system parameters. |
program application short name | Required. The application short name of your concurrent program. |
program name | Required. The uppercase name of your program. It must be the short name that you enter in the Concurrent Programs window when defining a concurrent program. |
PROGRAM_ NAME | Optional. A descriptive name for your program. The program field on the View Requests form displays this as the user-friendly program name. The concurrent program short name passed to CONCSUB is often hard for end users to understand, so the PROGRAM_NAME parameter allows you to pass a more easily remembered name for your concurrent program. If you do not specify a PROGRAM_NAME, the View Requests form displays the user-friendly program name specified in the Concurrent Programs window. You may also use the PROGRAM_NAME parameter to indicate the batch that your request processes for programs that process a set of data, where there could be several requests for a given program that are active at the same time. |
REPEAT_TIME | Optional. The time of day to resubmit the request. The format for the time is HH24:MI or HH24:MI:SS. For example, REPEAT_TIME=14:30 resubmits your request daily at 2:30 p.m.
Important: Do not use REPEAT_TIME with other resubmission parameters except for the optional parameters REPEAT_END and START. |
REPEAT_ INTERVAL | Optional. The interval between resubmission (a positive integer or real number). Use this parameter along with REPEAT_INTERVAL_UNIT to specify the time between resubmissions. |
REPEAT_ INTERVAL_ UNIT | Optional. The unit of time used for the interval between resubmissions. The available units are MINUTES, HOURS, DAYS or MONTHS. Use this parameter along with REPEAT_INTERVAL to specify the time between resubmissions. For example, setting REPEAT_INTERVAL=12 and REPEAT_INTERVAL_UNIT=HOURS resubmits your request every twelve hours. The default value is DAYS.
Important: Do not use REPEAT_INTERVAL and REPEAT_INTERVAL_UNIT with REPEAT_TIME. |
REPEAT_ INTERVAL_ TYPE | Optional. Whether to time the resubmission interval from the requested start time of the request or from its completion. Set this parameter either to START or END. The default value is START.
Important: Use REPEAT_INTERVAL_TYPE only if you use REPEAT_INTERVAL. |
REPEAT_END | Optional. The date and time to stop resubmitting the concurrent request. Use one of the following for the format of the end date: '"DD-MON-RR HH24:MI:SS"' (as in '"07-APR-02 18:32:05"') or '"DD-MON-RRRR HH24:MI:SS"' (as in '"07-APR-2002 18:32:05"') Note that because this date format includes a space, you must enclose the date in double quotation marks and single quotation marks. You can also specify just the date: 'DD-MON-RR' or 'DD-MON-RRRR' |
NLS_LANGUAGE | Optional. The NLS language for the request. |
NLS_TERRITORY | Optional. The NLS territory for the request. |
START | Optional. A start date and time for your program in this format: '"DD-MON-RR HH24:MI:SS"' (as in '"07-APR-02 18:32:05"') Because this date format includes a space, you must enclose the date in double quotation marks and single quotation marks. If you do not specify a start time, your program submits immediately and is processed by the next available concurrent manager. The default value is the current time. |
IMPLICIT | Optional. Whether to show this concurrent request on the View Requests form. Specify NO, YES, ERROR or WARNING. The value IMPLICIT=NO allows the request to appear on the View Request form. The default value is NO. The value IMPLICIT=YES means that only the System Administrator's privileged View Concurrent Requests form displays this request. Use this value if the request is not interesting to the user. Specify IMPLICIT=ERROR or IMPLICIT=WARNING, respectively, if you want the request to appear only if it fails or completes with warnings. |
REPEAT_DAYS | Optional. The number of days after which to repeat the concurrent request, calculated from the last requested start date. The number can be a positive integer or real number. For example, REPEAT_DAYS=1.5 resubmits your request every 36 hours.
Important: Do not use REPEAT_DAYS with other resubmission parameters except for the optional parameters REPEAT_END and START. Tip: REPEAT_DAYS will become obsolete in a future release. You may therefore want to use REPEAT_INTERVAL, REPEAT_INTERVAL_TYPE and REPEAT_INTERVAL_UNIT instead of REPEAT_DAYS. |
parameter 1 ... parameter n | Optional. Your program-specific parameters. If a parameter includes spaces, enclose that parameter in double quotes, then in single quotes. If a parameter contains a double quotation mark as part of the argument, precede that mark with a backslash [\]. |
These sections explain how you can copy and modify concurrent program definitions.
Warning: Do not overwrite program definitions for existing concurrent programs. Copy the program, rename it, then make any desired modifications to the new program.
Related Topics
Overview of Concurrent Programs and Requests
Copying and Renaming a concurrent program
Defining Program Incompatibility Rules
Modifying an Incompatible Programs list
Example of modifying a program's parameters
Warnings for Modifying Program Definitions
You can copy your concurrent programs and modify them to create new programs with definitions that meet your needs. You can modify how a concurrent program operates by changing the program's definition of:
incompatible programs
parameters (arguments)
parameter value sets
printer, print style, etc.
Rather than overwrite a concurrent program's definition, you should customize a program by copying and renaming an existing program, then modifying the new program to suit your needs. The figure below illustrates the basic steps in copying and modifying a new concurrent program.
As the figure illustrates, you can copy parameters, and then modify the behavior of the parameters. Or you can copy the list of incompatible programs, and then modify the list. Finally , you can change the associated printer and/or print style.
Related Topics
Overview of Concurrent Programs and Requests
Copying and Modifying Program Definitions
Example of modifying a program's parameters
You may wish to control the priority of some requests on a program level rather than at the user level.
Setting the priority for a program allows any request to run that concurrent program to use your selected priority rather than the priority of the user submitting the request.
For example, a user can submit a variety of requests at the standard priority determined by the value of the user profile Concurrent:Priority. However, when the user submits a request for a particular concurrent program, you want that request to have a higher priority.
You assign that program a priority of 10. When the user requests that program to run, it receives the higher priority defined on the Concurrent Program window rather than the user's standard priority and is processed ahead of other requests. When the users requests other concurrent programs that do not have a specified priority, those requests use the user's Concurrent:Priority profile value.
Related Topics
Copying and Modifying Program Definitions
A concurrent program's definition may include a list of incompatible programs. When a program is listed as incompatible with another program, the two programs cannot run simultaneously in the same conflict domain. See: Defining Program Incompatibility Rules.
You can view which programs are incompatible with a concurrent program from the Incompatible Programs block on the Concurrent Programs window. The programs listed cannot run simultaneously within the same conflict domain as the concurrent program whose definition you are viewing.
To modify the list of incompatible programs you can either:
Add new programs to the list.
The Scope field refers to whether you want the program by itself to be incompatible, or whether you want the program and all child requests, that is, concurrent programs started by the program as part of a request set, to be incompatible.
Delete programs from the list.
Important: To immediately effect any changes you make in the Incompatible Programs zone, you must navigate to the Administer Concurrent Managers window and choose Verify for the Internal Concurrent Manager.
Related Topics
Copying and Modifying Program Definitions
Administer Concurrent Managers
Parameters, also referred to as arguments, are assigned to standard submission concurrent programs. To define a program as standard submission, set the value of the Standard Submission field in the Concurrent Programs form to Yes.
Important: All the mechanisms for parameter defaulting (including references to values of other parameters, user profiles, etc.) are evaluated only at submission time.
There are two aspects to a parameter associated with a concurrent program: its value set and its behavior.
Variable | Description |
---|---|
Parameter value set | The valid values the parameter can accept. The set of valid values is referred to as a value set. |
Parameter behavior | How the parameter behaves within an application. For example, whether:
|
If you wish to define or modify a value set, you must first carefully plan your value set's purpose and implementation.
Using the Concurrent Programs form, you can see a concurrent program's parameters by choosing Parameters. Each parameter has a value set that defines what values are permissible for the parameter. To see the name of a parameter's value set, look at the Value Set field in the Argument Details block.
Related Topics
Copying and Modifying Program Definitions
Control the Behavior of Request Parameters
Example of modifying a program's parameters
The behavior of parameters in programs running individually may differ from when those programs are run as part of a request set.
You define how a program's parameters behave when you define the program using the Concurrent Programs form.
Using the Request Set form, you can also define how a program's parameters behave when the program is run as part of a request. In addition, you can define parameters in different programs in a request set to all share the same value by labeling them as Shared Parameters. See: Sharing Parameters in a Request Set.
Warning: Modifying a concurrent program's definition by adding new or deleting existing parameters, or changing a parameter's value set can prevent the program from running. See: Warnings for Modifying Program Definitions.
Using the Concurrent Programs form or the Request Set form, you can set a parameter so it does not display to an end user. Because parameters that do not display cannot be modified, setting a parameter to not display:
is a good security measure, guaranteeing a desired default value is used
means you should enter a valid default type and value at either the program's definition, or if the program is part of a request set, at the request set's definition.
Warning: Set defaults for required parameters before setting the Display field to No. Otherwise the Submit Requests form returns an error when attempting to submit the program.
If you define a parameter to not display, then the parameter does not appear when the program is run using the Submit Requests form, nor does it appear in the Request Set form.
If you define a parameter to not display, using the Request Set form, then the parameter does not appear on the Submit Requests form when the program is run as part of a request set.
After a request is submitted to run a concurrent program, the program's parameters may be displayed in the Details block of the Concurrent Requests form.
When a parameter is set to not display, it does not appear in the Details block of the Concurrent Requests form.
These displayed parameter values exactly match the values that the concurrent manager passes to the concurrent program, and may or may not correspond to the displayed value that the user chose.
For example, in the Submit Requests form, the user may choose "Oracle General Ledger" as a parameter, but the corresponding application ID displays in the Concurrent Requests form.
Tip: If your users encounter errors when running a program, you can look at the exact values that the concurrent program uses to help you diagnose the problem.
Parameter default values can be changed by users when they submit a program or request set to run.
You can set a default value for a parameter using the:
Default Type and Default Value fields in the Concurrent Programs form. These values cannot be changed on the Request Set form.
Default Type and Default Value fields in the Request Set form.
This default definition applies only when the program is run as part of a request set.
Shared Parameter and Default Value fields in the Request Set form
This default definition applies only when the program is run as part of a request set. All parameters labeled with the same shared parameter label default to the value you set in the Default Value field.
If the Default Type or Default Value for a parameter is incorrect, when the program is being set to run using the Submit Requests form, a window displays along with an error message.
If the parameter is not displayed, you receive an error message. You cannot update a field that is not displayed.
Warning: Be careful when entering the default type and default value, because these values are not validated with the value sets for your parameters. If you enter incorrect values, they do not appear as defaults when you run this request set using the Submit Requests form.
If a parameter is displayed in the Request Set form and there is no default value provided by the program's definition, you can define a default value or have the parameter inherit a shared value, and then prevent end users from modifying that value.
Set the Modify field in the Request Set form to No if you want to show the value for a parameter but not allow changing it when the request set is run using a Standard Submission form. You can set a value for the parameter using a default value or a shared parameter.
If the Display field is set to No, the Modify field automatically defaults to No, and you cannot update it.
Caution: Set defaults for required parameters before turning Modify to No. Otherwise the Submit Requests form returns an error when attempting to submit this report.
Modifying parameter behavior, for example, changing whether a parameter is displayed to the end user, takes effect immediately after you commit your change. However, some changes do not appear to you unless you change responsibility or select your current responsibility again.
The following table describes how a parameter's details affect its behavior in the Concurrent Programs form and the Run Requests form.
Parameter Details | Concurrent Programs form | Run Requests form |
---|---|---|
Required | Yes | Parameter requires a value (entered by user or a default). |
Display | Yes | Parameter is displayed. |
Display | No | Parameter is not displayed, and cannot be modified. |
Default Type & Value | Yes - Default Type and Value entered. | A default value displays, and can be changed by the user. |
Default Type and Value | No default entered. | No default value is displayed. |
The following table describes how a parameter's details affect its behavior in the Request Sets form and Run Requests form.
Parameter Details | Concurrent Programs form | Request Set form | Run Requests form |
---|---|---|---|
Required | Yes | Parameter does not require a value. | Parameter requires a value. |
Display | Yes | Parameter is displayed. - Display set to Yes. | Parameter is displayed. |
Display | Yes | Parameter is displayed. - Display set to No. | Parameter is not displayed. |
Display | No | Parameter not displayed. | Parameter not displayed. |
Modify | n/a | Yes | Value can be modified. |
Modify | n/a | No | Value cannot be modified. |
Default Type & Value | Yes - Default Type and Value entered. | Default Type and Value cannot be modified. | Default values can be changed by the user. |
Default Type & Value | No default entered. | Yes - a Default Type and Value can be entered. | Default values can be changed by the user. |
Default Type & Value | No default entered. | No - Default Type and Value are not entered. | No default value is displayed. |
The following table lists warnings for modifying program definitions:
Action | Form Used | Warning |
---|---|---|
Changing the number of columns or rows in a report program. | Concurrent Programs - Report Information region. | Some report programs are written to produce a precise output. Changing the output definition could prevent the program from running, or produce poor results. |
Setting print style to Dynamic. | Concurrent Programs - Report Information region - Style field. | Dynamic print style informs the program to generate its output based on output dimensions that may vary. Special coding within a program is required to support the Dynamic print style. |
Changing the number of parameters in a program definition. | Concurrent Programs - Parameters window. | Programs are defined to expect x number of parameters. If you add a new parameter (x + 1), the program will ignore it. Deleting a parameter can cause a program not to run. |
Changing Value Sets. | Concurrent Programs - Argument Details region - Value Set field. | Programs expect values of a certain type and length. Programs may not operate if value set is changed. |
Changing tokens. | Concurrent Programs - Argument Details region - Token field. | Programs expect values of a certain type and length. Program may not operate if expected token is not received. |
Defining a concurrent executable or program's execution method as Immediate. | Concurrent Program Executables - Execution Method field. Concurrent Programs - Executable Information region - Method field. | Concurrent programs whose execution method is Immediate must be registered with the program library FNDLIBR. Application developers can register programs with program libraries, System Administrators cannot. |
Related Topics
Copying and Modifying Program Definitions
Example of modifying a program's parameters
Concurrent Program Details Report
Consider the following example of when and how to modify a concurrent program's parameters.
If one user submits a large number of concurrent requests on a daily basis, for example, an Oracle Bill of Materials or Oracle Purchasing supervisor, you can create a streamlined purge program that only purges that user's concurrent processing records.
You can run this program as System Administrator and have it automatically resubmitted on a specific time interval.
You could also create a request set containing this one program and define the user as the owner of the request set. Then, if you do not assign the request set to any report security group, only the user (owner) can run the program. This way, the user can be responsible for purging their own records.
The System Administrator's Purge Concurrent Request and/or Manager Data program contains twelve parameters. You can copy, rename, and modify the program so it displays only three parameters, with only one parameter requiring user entry. See: Purge Concurrent Request and/or Manager Data, Oracle E-Business Suite System Administrator's Guide - Maintenance.
The table below summarizes the steps to follow in our example.
Form Used | Task |
---|---|
Concurrent Programs (Concurrent Programs Define) | Query the Application Object Library program named "Purge Concurrent Request and/or Manager Data" and press Copy. Select both Copy Arguments and Copy Incompatible Programs. Enter a new name for the program you are going to copy, for example, enter JSMITH PURGE. |
Concurrent Programs | To modify the JSMITH PURGE program's parameters, select the Parameters button. |
Concurrent Programs, Parameter Window | Modify the following seven parameters so they do not display (user JSMITH cannot see nor change the program's default values). - Oracle ID - Program Application - Program - Manager Application - Manager - Responsibility Application - Responsibility Modify the following three parameters so they do not display (user JSMITH cannot see nor change the default values you set). Set the parameters to the following (Type=Constant) defaults: - Entity = Request - Mode = Age - User Name = JSMITH Leave the following two parameters unchanged so they display. Mode Value will require JSMITH to enter a value, and Report is set to a default value of "Yes". - Mode Value - Report |
Request Set (Reports Set) | Create a request set with one program in it, the JSMITH PURGE program. Enter JSMITH in the Owner field. If this request set is not assigned to any report security group, only JSMITH will be able to run the JSMITH PURGE program. |
Standard Request Submission program form. For example, the Run Reports form (Reports Run) | When first submitting the JSMITH PURGE program to run, navigate to the Resubmission Options region and enter, for example, "5" and "Days" in the Interval field. |
Related Topics
Copying and Modifying Program Definitions
Control the Behavior of Request Parameters
Concurrent Program Details Report
A conflict domain is a set of related data stored in one or more ORACLE schemas and linked by grants and synonyms. Do not confuse logical databases with your ORACLE database. The ORACLE database contains all your Oracle E-Business Suite data, with each application's data usually residing in one ORACLE schema. You can think of a logical database as a line drawn around a set of related data for which you wish to define concurrent program incompatibilities. In other words, logical databases determine which concurrent programs cannot run at the same time.
When an ORACLE schema is identified as belonging to a logical database, concurrent program incompatibility rules are enforced when concurrent programs connect to the ORACLE schema.
By checking for incompatibilities between programs running concurrently, accessing the same data, Oracle E-Business Suite ensures that data retrieved by one program is not incorrect or adversely affected when retrieved by another program.
An example of a concurrent program that is incompatible with other concurrent programs is Oracle General Ledger's Posting program, used to post journal entries.
If the Posting program's incompatibility with other Oracle E-Business Suite concurrent programs were not enforced, other financial reports running simultaneously with the Posting program could contain incorrect account balance information. Logical databases ensure that this does not happen.
The installation process automatically defines logical databases and assigns ORACLE schemas to them.
A Standard logical database can be assigned to every Oracle E-Business Suite product so that every concurrent program, if incompatible with any other program, does not run concurrently with that program, regardless of which ORACLE schema those two programs connect to. Assigning every ORACLE schema to the same (e.g., Standard) logical database is a fail-safe method of enforcing program incompatibility rules.
You must define new logical databases only if you build a custom application whose data do not interact with data found in existing logical databases.
As a general rule, you should define a logical database for each custom application, and assign that application's ORACLE schema(s) to the corresponding logical database.
However, if a custom application's data interacts with another application's data, you should assign the two applications' ORACLE schemas to the same logical database.
Registering your custom application's tables ensures that the table names appear as QuickPick values in the Define Alerts form.
This report documents concurrent program definitions, including executable file information, execution method, incompatible program listings, and program parameters. If a concurrent program generates a report, column and row information, as well as print output and print style, are also documented.
Use this report when considering concurrent program modifications, such as modifying program incompatibility rules.
Caution: If you do not enter any parameters, the report returns values for all concurrent programs, and may be very lengthy.
Choose the application name associated with the concurrent program whose program definition details you wish to report on.
Choose only an application name, without a program name, if you wish to run a program definition details report on all concurrent programs associated with an application.
Choose the name of a concurrent program whose program definition details you wish to report on. You must enter a value for Application Name before entering a value for Program.
The report headings display the specified report parameters and provide you with general information about the contents of the report.
This report shows which concurrent programs are currently enabled nand which programs are disabled.
Use this report to record the execution method, argument method, run alone status, standard submission status, request type, and print style information associated with your concurrent programs.
Choose the application name associated with the concurrent programs whose program information you wish to report on.
If you do not enter an application name, the report will return values for all concurrent programs.
The report headings display the specified report parameters and provide you with general information about the contents of the report.
Related Topics
Overview of Concurrent Programs and Requests
Concurrent Program Details Report
Use this window to define a request group. A request security group is the collection of requests, request sets, and concurrent programs that a user, operating under a given responsibility, can select from the Submit Requests window.
System Administrators:
Assign a request security group to a responsibility when defining that responsibility. A responsibility without a request security group cannot run any requests using the Submit Requests window.
Can add any request set to a request security group. Adding a private request set to a request security group allows other users to run that request set using the Submit Requests window.
Users:
Can create their own private request sets using the Request Sets window. In a private request set, users can include only the requests you assign to their request security group.
Cannot update another user's private request set using the Request Sets window.
Cannot delete a private request set if it is assigned to a request security group.
Use the request group's name to assign the request group to a responsibility on the Responsibilities window. An application name and request group name uniquely identify a request group.
Select the name of the application you wish to associate with your request group. An application name and a request security group name uniquely identify a request security group. This application name does not prevent you from assigning requests and request sets from other applications to this request group.
Assign a code to this request group. Some products use the request group code as a parameter that identifies the requests a customized standard submission form can select. See: Customizing the Submit Requests Window using Codes.
Specify the requests and request sets in the request group.
Choose program or set to add one item, or choose application to include all requests in an application.
Related Topics
Overview of Concurrent Programs and Requests
Organizing Programs into Request Groups
Using Codes with Request Groups
Customizing the Submit Requests Window using Codes
Report Group Responsibilities Report
Define a concurrent program executable for each executable source file you want to use with concurrent programs. The concurrent program executable links your source file logic with the concurrent requests you and your users submit to the concurrent manager.
Important: You cannot add new immediate programs to a concurrent manager program library. We recommend that you use spawned concurrent programs instead.
The combination of application name plus program name uniquely identifies your concurrent program executable.
See: Concurrent Programs Window
Enter a name for your concurrent program executable. In the Concurrent Programs window, you assign this name to a concurrent program to associate your concurrent program with your executable logic.
Enter a short name for your concurrent program executable.
The concurrent managers use the application to determine in which directory structure to look for your execution file.
The execution method cannot be changed once the concurrent program executable has been assigned to one or more concurrent programs in the Concurrent Programs window.
The possible execution methods are:
Variable | Description |
---|---|
Host | The execution file is a host script. |
Oracle Reports | The execution file is an Oracle Reports file. |
PL/SQL Stored Procedure | The execution file is a PL/SQL stored procedure. |
Java Stored Procedure | The execution file is a Java stored procedure. |
Java Concurrent Program | The execution file is a program written in Java. |
Multi Language Function | The execution file is a function (MLS function) that supports running concurrent programs in multiple languages (as well as territories and numeric character settings). |
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. We recommend against defining new immediate concurrent programs, and suggest you use either a PL/SQL Stored Procedure or a Spawned C Program instead. |
Request Set Stage Function | PL/SQL Stored Function that can be uesd to calculate the completion statuses of request set stages. |
Enter the operating system name of your execution file. Some operating systems are case sensitive, so the name entered here should match the file name exactly.
Do not include spaces or periods (.) in the execution file name, unless the execution method is PL/SQL stored procedure or Request Set Stage Function.
The maximum size of an execution file name is 60 characters.
Enter the name of your C or Pro*C program subroutine here. Do not use spaces or periods (.) in this field.
Only immediate programs or spawned programs using the Unified C API use the subroutine field.
We recommend against defining new immediate concurrent programs, and suggest you use either a PL/SQL Stored Procedure or a Spawned C Program instead.
The Stage Function Parameters button opens a window that allows you to enter parameters for the Request Set Stage Function. This button is only enabled when you select Request Set Stage Function as your Execution Method.
List the Parameters that your custom Stage Function uses.
Enter a name for the Parameter. This name will be displayed in the Stage Functions Parameter window of the Request Set form.
Enter a short name that will be used by the function to reference the parameter.
Related Topics
Use this window to define and modify your concurrent programs.
Build the execution file for your concurrent program.
Use the Concurrent Program Executables window to define a concurrent program executable for your operating system program.
The combination of application name plus program name uniquely identifies your concurrent program.
You see this longer, more descriptive name when you view your requests in the Requests window. If this concurrent program runs through Standard Request Submission, you see this name in the Submit Requests window when you run this program.
Enter a brief name that Oracle E-Business Suite can use to associate your concurrent program with a concurrent program executable.
The program's application determines what ORACLE username your program runs in and where to place the log and output files.
Indicate whether users should be able to submit requests to run this program and the concurrent managers should be able to run your program.
Disabled programs do not show up in users' lists, and do not appear in any concurrent manager queues. You cannot delete a concurrent program because its information helps to provide an audit trail.
Select the concurrent program executable that can run your program. You define the executable using the Concurrent Program Executables window. You can define multiple concurrent programs using the same concurrent program executable. See: Concurrent Program Executables.
Some execution methods, such as Oracle Reports, support additional execution options or parameters. You can enter such options in this field. The syntax varies depending on the execution method.
If you define a concurrent program with the bitmapped version of Oracle Reports, you can control the orientation of the bitmapped report by passing the ORIENTATION parameter or token. For example, to generate a report with landscape orientation, specify the following option in the Options field:
ORIENTATION=LANDSCAPE
Do not put spaces before or after the execution options values. The parameters should be separated by only a single space. You can also specify an orientation of PORTRAIT.
You can control the dimensions of the generated output with the PAGESIZE parameter. A specified <width>x<height> in the Options field overrides the values specified in the report definition. For example:
ORIENTATION=LANDSCAPE PAGESIZE=8x11.5
The units for your width and height are determined by your Oracle Reports definition. You set the units in your Oracle Reports menu under Report => Global Properties => Unit of Measurement.
If the page size you specify with the PAGESIZE parameter is smaller than what the report was designed for, your report fails with a "REP-1212" error.
The execution method your concurrent program uses appears here.
Valid values are:
Variable | Description |
---|---|
Spawned | Your concurrent program is a stand-alone program in C or Pro*C. |
Host | Your concurrent program is written in a script for your operating system. |
Immediate | Your concurrent program is a subroutine written in C or Pro*C. Immediate programs are linked in with your concurrent manage and must be included in the manager's program library. |
Oracle Reports | Your concurrent program is an Oracle Reports script. |
PL/SQL Stored Procedure | Your concurrent program is a stored procedure written in PL/SQL. |
Java Stored Procedure | Your concurrent program is a Java stored procedure. |
Java Concurrent Program | Your concurrent program is a program written in Java. |
Multi Language Function | A multi-language support function (MLS function) is a function that supports running concurrent programs in multiple languages (as well as territories and numeric character settings). You should not choose a multi-language function in the Executable: Name field. If you have an MLS function for your program (in addition to an appropriate concurrent program executable), you specify it in the MLS Function field. |
SQL*Loader | Your concurrent program is a SQL*Loader program. |
SQL*Plus | Your concurrent program is a SQL*Plus or PL/SQL script. |
Request Set Stage Function | PL/SQL Stored Function that can be used to calculate the completion statuses of request set stages. |
You can switch between Spawned and Immediate, overriding the execution method defined in the Concurrent Program Executable window, only if either method appears when the executable is selected and both an execution file name and subroutine name have already been specified in the Concurrent Program Executable window. See: Concurrent Program Executables.
You can assign this program its own priority. The concurrent managers process requests for this program at the priority you assign here.
If you do not assign a priority, the user's profile option Concurrent:Priority sets the request's priority at submission time.
If you want to associate your program with a predefined request type, enter the name of the request type here. The request type can limit which concurrent managers can run your concurrent program.
For use by Oracle E-Business Suite internal developers only. The incrementor function is shown here.
The MLS function, if any, used by the program.
The Multilingual Concurrent Request feature allows a user to submit a request once to be run multiple times, each time in a different language. If this program utilizes this feature, the MLS function can be used to determine which installed languages are needed for the request.
Beginning with Release 12.1, MLS functions can support multiple territories and numeric character sets as well as multiple languages.
See:
Oracle E-Business Suite Developer's Guide
Note: If your program has an MLS function associated with it and the "Use in SRS" box (below) is not checked, then the MLS function will be ignored.
Check this box to indicate that users can submit a request to run this program from a Standard Request Submission window.
If you check this box, you must register your program parameters, if any, in the Parameters window accessed from the button at the bottom of this window.
If you check the Use in SRS box, you can also check this box to allow a user to enter disabled or outdated values as parameter values.
Many value sets use special table columns that indicate whether a particular value is enabled (using ENABLED_FLAG, START_DATE_ACTIVE, and END_DATE_ACTIVE columns). These value sets normally allow you to query disabled or outdated values but not enter them in new data. For Standard Request Submission, this means that a user would not normally be allowed to enter disabled values as report parameter values when submitting a report, even if the report is a query-only type report.
Indicate whether your program should run alone relative to all other programs in the same logical database. If the execution of your program interferes with the execution of all other programs in the same logical database (in other words, if your program is incompatible with all programs in its logical database, including itself), it should run alone.
You can enter any specific incompatible programs in the Incompatible Programs windows.
Turns on SQL tracing when program runs.
Use this option to indicate that this concurrent program should automatically be restarted when the concurrent manager is restored after a system failure.
This box is checked if the program allows for a user to submit a request of this program that will reflect a language and territory that are different from the language and territory that the users are operating in.
For example, users can enter orders in English in the United Kingdom, using the date and number formats appropriate in the United Kingdom, then generate invoices in German using the date and number formats appropriate to their German customers.
If this box is left blank then a user can associate any installed language with the request, but the territory will default to the territory of the concurrent manager environment.
Note that this option should be set only by the developer of the program. The program must be written as NLS Compliant to utilize this feature. See: the Oracle E-Business Suite Developer's Guide.
Note that this option should be set only by the developer of the program. The program must be written as NLS Compliant to utilize this feature.
Select the output format from the following:
HTML
PCL (HP's Printer Control Language)
PS (Post Script)
Text
Important: If you choose HTML or PDF as the output type with Oracle Report programs, you must use an appropriate printer driver that handles HTML or PDF files.
Indicate whether to automatically save the output from this program to an operating system file when it is run. This value becomes the default for all requests submitted for this program. The output of programs with Save set to No is deleted after printing.
If this is a Standard Request Submission program, users can override this value from the Submit Requests window.
If you enter No, your concurrent program's output is never sent to the printer.
Enter the minimum column and row length for this program's report output. Oracle E-Business Suite uses this information to determine which print styles can accommodate your report.
The print style you select depends on your system and printer setup. Print styles include:
132 columns and 66 lines (Landscape)
180 columns and 66 lines (Landwide)
80 columns and 66 lines (Portrait)
132 columns and 62 lines (A4)
Your list is limited to those styles that meet your program's columns and row length requirements.
If your program requires a specific print style (for example, a checkwriting report), use this check box to enforce that print style.
If you want to restrict your program's output to a single printer, enter the name of the printer to which you want to send your output. If your program has minimum or maximum columns or rows defined, your list of values is limited to those printers that can support your program's requirements.
Users cannot override your choice of printer from the Submit Requests or Requests windows.
Concurrent programs can be integrated with the Business Event System in Oracle Workflow. Business events can be raised at key points of the life cycle of a request to run a concurrent program. Users can subscribe to the business events and create their own business processes interacting with the concurrent programs.
Here you specify the points at which business events are enabled. The possible points are:
Request Submitted
Request On Hold
Request Resumed
Request Running
Program Completed
Post Processing Started
Post Processing Ended
Request Completed
Possible parameters for each event are:
REQUEST_ID
REQUESTED_BY
PROGRAM_APPLICATION_ID
CONCURRENT_PROGRAM_ID
STATUS
COMPLETION_TEXT
TIME_STAMP
Variable | Description |
---|---|
Copy to... | Choose this button to create another concurrent program using the same executable, request and report information. You can elect to copy the incompatibility and parameter details as well. |
Session Control | Choose this window to specify options for the database session of the concurrent program when it is executed. |
Incompatibilities | Choose this button to open the Incompatible Programs window. |
Parameters | Choose this button to open the Concurrent Program Parameters window. |
Create another concurrent program using the same executable, request and report information as the current program. You can optionally copy the incompatibility and parameter details information as well.
Related Topics
See: Incompatible Programs Window
Concurrent Program Parameters Window
Concurrent Program Executables
Use this window to specify options for the database session of the concurrent program when it is executed.
Optionally specify the resource consumer group for the concurrent program.
See: Resource Consumer Groups in Oracle E-Business Suite.
Optionally specify a rollback segment to be used with the concurrent program. This rollback segment will be used instead of the default and will be used up until the first commit.
Important: If you specify a rollback segment here, your concurrent program must use the APIs FND_CONCURRENT.AF_COMMIT and FND_CONCURRENT.AF_ROLLBACK to use the specified rollback segment. See: the Oracle E-Business Suite Developer's Guide.
Optionally specify an optimizer mode. You can choose ALL_ROWS, FIRST_ROWS, Rules, or Choose. You would specify an optimizer mode only for a custom program that may not perform well with the default cost-based optimizer (CBO) and needs tuning. You can use a different optimizer mode until your program is tuned for CBO.
If you are on a PCP/RAC environment, optionally specify the target node on which requests for this program will run. When requests for this program are submitted, they run on this node if possible.
If no specification is made for the concurrent program, a request will be picked up by any manager able to run it.
If the target node is down, any available manager will pick up the request for processing and log a message to FND_LOG_MESSAGES.
Optionally specify a Real Application Cluster (RAC) instance on which the program will run. When requests for this program are submitted, they run on this instance if possible.
Identify programs that should not run simultaneously with your concurrent program because they might interfere with its execution. You can specify your program as being incompatible with itself.
Although the default for this field is the application of your concurrent program, you can enter any valid application name.
The program name and application you specify must uniquely identify a concurrent program.
Your list displays the user-friendly name of the program, the short name, and the description of the program.
Enter Set or Program Only to specify whether your concurrent program is incompatible with this program and all its child requests (Set) or only with this program (Program Only).
Enter Domain or Global. If you choose Domain, the incompatibility is resolved at a domain-specific level. If you choose Global, then this concurrent program will be considered globally incompatible with your concurrent program, regardless of which domain it is running in.
Related Topics
Concurrent Program Parameters Window
Defining Program Incompatibility Rules
Modifying an Incompatible Programs List
Enter and update the program parameters that you wish to pass to the program executable. Program parameters defined here should match the variables in your execution file.
Enter the parameter which will hold the value of the conflict domain of the program. For information on conflict domain parameters, see Concurrent Conflict Domains.
Enter the parameter which will hold the value of the conflict domain of the program.
This field is for HRMS security only. See: Customizing, Reporting, and System Administration in Oracle HRMS.
Choose the sequence numbers that specify the order in which your program receives parameter values from the concurrent manager.
Disabled parameters do not display at request submission time and are not passed to your execution file.
You specify information about your parameter almost exactly as you define a flexfield segment.
Enter the name of the value set you want your parameter to use for validation. You can only select from independent, table, and non-validated value sets.
The maximum size of your value set is 240 characters.
Important: If you are using a value set of dates, this value set should have a format type of either Standard Date or Standard DateTime if you are using the Multilingual Request feature.
If you want to set a default value for this parameter, identify the type of value you need.
Valid types include:
Variable | Description |
---|---|
Constant | The default value can be any literal value. |
Profile | The default value is the current value in the user profile option defined in the Default Value field. Use the profile option name, not the end-user name. You do not need to include $PROFILE$. |
SQL Statement | The default value is determined by the SQL statement you defined in the Default Value field. |
Segment | The default value is the value entered in a prior segment of the same parameter window. |
You can enter a default value for the parameter. This default value for your parameter automatically appears when you enter your parameter window. You determine whether the default value is a constant or a context-dependent value by choosing the default type.
Your default value should be a valid value for your value set. Otherwise you see an error message when you enter your parameter window on the Run Request window and your default value does not appear.
Valid values for each default type include:
Variable | Description |
---|---|
Constant | Enter any literal value for the default value. |
Profile | The default value is the current value of the user profile option you specify here. Enter the profile option name, not the end-user name. |
Segment | The default value is the value entered in a prior segment of the same flexfield window. Enter the name of the segment whose value you want to copy. |
SQL Statement | The default value is determined by the SQL statement you enter here. Your SQL statement must return exactly one row and one column in all cases. |
If the program executable file requires an argument, you should require it for your concurrent program.
If the value set for this parameter does not allow security rules, then this field is display only. Otherwise you can elect to apply any security rules defined for this value set to affect your parameter list.
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 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.
Indicate whether to display this parameter in the Parameters window when a user submits a request to run the program from the Submit Requests window.
You should provide a default type and value for any non-displayed parameter.
Enter the field length in characters for this parameter. The user sees and fills in the field in the Parameters window of the Submit Requests window.
You should ensure that the total of the value set maximum sizes (not the display sizes) for all of your parameters, plus the number of separators you need (number of parameters minus one), does not add up to more than 240. If your program values' concatenated length exceeds 240, you may experience truncation of your data in some forms.
Enter the display length in characters for the parameter value description. Your window may show fewer characters of your description than you specify here if there is not enough room (determined by the sum of your longest prompt plus your display size for this parameter plus seven). However, your window does not display more characters of the description than you specify here.
A user sees the prompt instead of the parameter name in the Parameters window of the Submit Requests window.
Enter the display length in characters for the parameter value description. The user sees the parameter value in the Parameter Description field of the Submit Requests and View Requests forms. The Parameter Description field concatenates all the parameter values for the concurrent program.
Tip: We recommend that you set the Concatenated Description Size for each of your parameters so that the total Concatenated Description Size for your program is 80 or less, since most video screens are 80 characters wide.
For a parameter in an Oracle Reports program, the keyword or parameter appears here. The value is case insensitive. For other types of programs, you can skip this field.
Related Topics
Note: Data groups are no longer supported. This section is provided for reference only.
Use this window to define data groups. A data group is a list of Oracle E-Business Suite and the ORACLE usernames assigned to each application.
If a custom application is developed with Oracle Application Object Library, it may be assigned an ORACLE username, registered with Oracle E-Business Suite, and included in a data group.
An ORACLE username allows access to an application's tables in an ORACLE database. All data groups automatically include an entry for Application Object Library.
A concurrent manager running reports or programs under Oracle E-Business Suite refers to a data group to identify the ORACLE username it uses to access an application's tables in the database.
Transaction managers running synchronous programs can only run programs submitted from responsibilities assigned the same data group as the transaction manager. If you create custom data groups, you should create new transaction managers for the applications that use transaction managers. Consult your product documentation to determine if your application uses transaction managers.
Each responsibility within Oracle E-Business Suite is assigned a data group.
During the installation or upgrading of Oracle E-Business Suite, a standard data group is defined, pairing each installed application with an ORACLE username (note: a standard data group is defined for each set of books). You cannot change or delete the predefined values for Application or ORACLE username in a Standard data group. However, you may:
Modify the Tool ORACLE username and description associated with an Application-ORACLE username pair.
Add new Application-ORACLE username pairs to the group.
Create a new data group, or modify an existing data group.
You cannot change or delete the predefined values for Application or ORACLE username in a Standard data group. However, you may modify the Tool ORACLE username and description, or add new Application-ORACLE username pairs to a Standard group.
A data group is uniquely identified by its name. You cannot create a data group with a name already in use.
Once saved, data group names cannot be edited.
Pair applications with ORACLE usernames.
When you copy a data group, each application, its assigned ORACLE username, and, if present, its Tool ORACLE username and description, appear in this zone automatically. All data groups automatically include an entry for Application Object Library.
Within each data group, an application can be listed only one time.
Select the ORACLE ID you want to assign to an application. An application uses an ORACLE ID to access tables in the database. Each ORACLE ID allows access to a predefined set of tables in the database.
Use this button to copy an existing data group, then add or delete application-ORACLE username pairs to create a new data group.
Related Topics
Overview of Concurrent Programs and Requests
Concurrent conflicts domains ensure that incompatible concurrent programs are not allowed to run simultaneously using related information.
For example, a conflict domain could be a range of numbers. Two concurrent programs could be incompatible if they used the same range of numbers, but compatible if they used different ranges of numbers.
Concurrent managers use concurrent conflicts domains to determine which concurrent programs cannot run at the same time. For example:
When concurrent program A is defined as incompatible with concurrent program B, then A and B cannot run at the same time using the same concurrent conflict domain.
If, for example, the programs A and B are assigned to the concurrent conflicts domains Standard when they are submitted, then programs A and B will not run together at the same time.
To define a conflict domain:
Enter a unique Domain name. The name you enter here may be used as a value for a parameter in the Submit Requests window.
Enter a unique Short Name for your domain. Limit the Short Name to 8 characters.
Optionally, you can provide a description for your domain.
Related Topics
Overview of Applications DBA Duties
Use this page to search for defined concurrent programs.
From this page you can create a new concurrent program or update an existing one.
The following are prerequisites to defining a concurrent program:
Build the execution file for your concurrent program.
Define a concurrent program executable for your operating system program file.
The combination of application name plus program name uniquely identifies your concurrent program.
Optionally enter an annotation for the Integration Repository for the concurrent program.
Indicate whether users should be able to submit requests to run this program and the concurrent managers should be able to run your program.
Disabled programs do not show up in users' lists, and do not appear in any concurrent manager queues. You cannot delete a concurrent program because its information helps to provide an audit trail.
You see this longer, more descriptive name when you view your requests in the Requests window. If this concurrent program runs through Standard Request Submission, you see this name in the Submit Requests window when you run this program.
The program's application determines what ORACLE username your program runs in and where to place the log and output files.
Enter a brief name that Oracle E-Business Suite can use to associate your concurrent program with a concurrent program executable.
Available options are:
Archive - reserved for future use only.
Autoconfig Type
Cloning - reserved for internal use only.
Generic
Purge - for concurrent programs listed in the Oracle Applications Manager dashboard used for purging data.
Refresh
Truncate
Enter the following:
Select the concurrent program executable that can run your program. You define the executable using the Concurrent Program Executables window. You can define multiple concurrent programs using the same concurrent program executable.
Parameters for the concurrent program are listed here. To add a parameter, click on the Create button.
Identify programs that should not run simultaneously with your concurrent program because they might interfere with its execution. You can specify your program as being incompatible with itself.
Enter the parameter which will hold the value of the conflict domain of the program.
For information on conflict domain parameters, see Concurrent Conflict Domains.
Indicate whether your program should run alone relative to all other programs in the same logical database. If the execution of your program interferes with the execution of all other programs in the same logical database (in other words, if your program is incompatible with all programs in its logical database, including itself), it should run alone.
You can enter any specific incompatible programs in the Incompatible Programs windows.
Although the default for this field is the application of your concurrent program, you can enter any valid application name.
The program name and application you specify must uniquely identify a concurrent program.
Your list displays the user-friendly name of the program, the short name, and the description of the program.
Enter Set or Program Only to specify whether your concurrent program is incompatible with this program and all its child requests (Set) or only with this program (Program Only).
Choose the type of incompatibility, either Domain or Global.
For information on incompatibility types, see Incompatible and Run Alone Programs.
Enter the following:
Enter the following:
If you want to associate your program with a predefined request type, enter the name of the request type here. The request type can limit which concurrent managers can run your concurrent program.
For use by Oracle E-Business Suite internal developers only. The incrementor function is shown here.
The MLS (Multi-Lingual Support) function, if any, used by the program.
The Multilingual Concurrent Request feature allows a user to submit a request once to be run multiple times, each time in a different language. If this program utilizes this feature, the MLS function determines which installed languages are needed for the request.
Beginning with Release 12.1, multiple territories and numeric character settings are also supported.
See the Oracle E-Business Suite Developer's Guide for more information.
For internal use only.
The Activity Summarizer is a PL/SQL subprogram summarizing about the purgable data in application tables for a concurrent program of type "Purge". It returns a list of table names and rows to be purged. Oracle developers register the PL/SQL procedure as summarizer procedure for the concurrent program.
For internal use only.
Concurrent programs that produce data for a portlet can call a function to refresh the portlet's data. The value for Refresh Portlet indicates when the function should be called.
If this box is checked, multiple pending requests are allowed; otherwise, only one pending request is allowed.
Check the SRS (Standard Request Submission) box to indicate that users can submit a request to run this program from a Standard Request Submission window.
If you check this box, you must register your program parameters, if any, in the Parameters window accessed from the button at the bottom of this window.
If you check the Use in SRS box, you can also check this box to allow a user to enter disabled or outdated values as parameter values.
Many value sets use special table columns that indicate whether a particular value is enabled (using ENABLED_FLAG, START_DATE_ACTIVE, and END_DATE_ACTIVE columns). These value sets normally allow you to query disabled or outdated values but not enter them in new data. For Standard Request Submission, this means that a user would not normally be allowed to enter disabled values as report parameter values when submitting a report, even if the report is a query-only type report.
Use this option to indicate that this concurrent program should automatically be restarted when the concurrent manager is restored after a system failure.
The NLS (National Language Support) box is checked if the program allows for a user to submit a request of this program that will reflect a language and territory that are different from the language and territory that the users are operating in.
For example, users can enter orders in English in the United Kingdom, using the date and number formats appropriate in the United Kingdom, then generate invoices in German using the date and number formats appropriate to their German customers.
If this box is left blank then a user can associate any installed language with the request, but the territory will default to the territory of the concurrent manager environment.
Note that this option should be set only by the developer of the program. The program must be written as NLS Compliant to utilize this feature. See: Oracle E-Business Suite Developer's Guide.
Enter the following:
Indicate whether to automatically save the output from this program to an operating system file when it is run. This value becomes the default for all requests submitted for this program. The output of programs with Save set to No is deleted after printing.
If this is a Standard Request Submission program, users can override this value from the Submit Requests window.
If you enter No, your concurrent program's output is never sent to the printer.
Select the output format from the following:
The format that you select here is used by the concurrent manager to determine how to display your report output. You must ensure that the output format you choose matches the format generated by your report, unless the report is an Oracle Reports report in which case the format you select, determines the output generated.
HTML
PCL (HP's Printer Control Language)
PS (Post Script)
Text
Important: If you choose HTML or PDF as the output type with Oracle Report programs, you must use an appropriate printer driver that handles HTML or PDF files.
Enter the minimum column and row length for this program's report output. Oracle E-Business Suite uses this information to determine which print styles can accommodate your report.
The print style you select depends on your system and printer setup. Print styles include:
132 columns and 66 lines (Landscape)
180 columns and 66 lines (Landwide)
80 columns and 66 lines (Portrait)
132 columns and 62 lines (A4)
Your list is limited to those styles that meet your program's columns and row length requirements.
If your program requires a specific print style (for example, a checkwriting report), use this check box to enforce that print style.
The following fields are typically specific to the installation.
Enter the following:
You can assign this program its own priority. The concurrent managers process requests for this program at the priority you assign here.
If you do not assign a priority, the user's profile option Concurrent:Priority sets the request's priority at submission time.
If you want to restrict your program's output to a single printer, enter the name of the printer to which you want to send your output. If your program has minimum or maximum columns or rows defined, your list of values is limited to those printers that can support your program's requirements.
Users cannot override your choice of printer from the Submit Requests or Requests windows.
The default layout template for the program. Values for this field are available only if the concurrent program has been registered as a data definition with XML Publisher and templates have been loaded to the Template Manager. For more information on XML Publisher and the Template Manager, see the Oracle XML Publisher documentation..
At the time of request submission, the default template is presented to the user. The user can override this value when submitting the request.
This field indicates how many days the system should retain data for a request of this concurrent program after the request completes. The system will retain this data for this period even if the "Purge Concurrent Request and/or Manager Data" program is run during this time.
This field is for HRMS security only. See: Customizing, Reporting, and System Administration in Oracle HRMS.
The log level is used in diagnostics. If a request to run this concurrent program fails, the failure may be recorded in a log file with the specified log level.
Turns on SQL tracing when program runs.
Enables the collection of timed statistics, such as CPU and elapsed times, by the SQL trace facility, as well as the collection of various statistics in the dynamic performance tables.
By default, a log file is created for each concurrent request. If such log files are not necessary for requests for this concurrent program, you can specify that the log file is automatically deleted for each request of this program.
If you are on a PCP/RAC environment, optionally specify the target node on which requests for this program will run. If no specification is made for the concurrent program, the request will be picked up by any manager able to run it.
If the target node is down, any available manager will pick up the request for processing and log a message to FND_LOG_MESSAGES.
Use this region to specify options for the database session of the concurrent program when it is executed.
Optionally specify the resource consumer group for the concurrent program. See: Resource Consumer Groups in Oracle E-Business Suite.
Optionally specify a rollback segment to be used with the concurrent program. This rollback segment will be used instead of the default and will be used up until the first commit.
Important: If you specify a rollback segment here, your concurrent program must use the APIs FND_CONCURRENT.AF_COMMIT and FND_CONCURRENT.AF_ROLLBACK to use the specified rollback segment. See: Oracle E-Business Suite Developer's Guide.
Optionally specify an optimizer mode. You can choose ALL_ROWS, FIRST_ROWS, Rules, or Choose. You would specify an optimizer mode only for a custom program that may not perform well with the default cost-based optimizer (CBO) and needs tuning. You can use a different optimizer mode until your program is tuned for CBO.
This region provides statistics on earlier requests for a defined concurrent program.
Summary information is collected when a request is completed, and stored in the table fnd_conc_prog_onsite_info.
Enter and update the program parameters that you wish to pass to the program executable. Program parameters defined here should match the variables in your execution file.
Enter the following:
Disabled parameters do not display at request submission time and are not passed to your execution file.
Choose the sequence numbers that specify the order in which your program receives parameter values from the concurrent manager.
Enter the parameter name. The value is case insensitive.
Enter the following:
Enter the name of the value set you want your parameter to use for validation. You can only select from independent, table, and non-validated value sets.
The maximum size of your value set is 240 characters.
Important: If you are using a value set of dates, this value set should have a format type of either Standard Date or Standard DateTime if you are using the Multilingual Request feature.
If you want to set a default value for this parameter, identify the type of value you need.
Valid types include:
Variable | Description |
---|---|
Constant | The default value can be any literal value. |
Profile | The default value is the current value in the user profile option defined in the Default Value field. Use the profile option name, not the end-user name. You do not need to include $PROFILE$. |
SQL Statement | The default value is determined by the SQL statement you defined in the Default Value field. |
Segment | The default value is the value entered in a prior segment of the same parameter window. |
You can enter a default value for the parameter. This default value for your parameter automatically appears when you enter your parameter window. You determine whether the default value is a constant or a context-dependent value by choosing the default type.
Your default value should be a valid value for your value set. Otherwise you see an error message when you enter your parameter window on the Run Request window and your default value does not appear.
Valid values for each default type include:
Variable | Description |
---|---|
Constant | Enter any literal value for the default value. |
Profile | The default value is the current value of the user profile option you specify here. Enter the profile option name, not the end-user name. |
Segment | The default value is the value entered in a prior segment of the same flexfield window. Enter the name of the segment whose value you want to copy. |
SQL Statement | The default value is determined by the SQL statement you enter here. Your SQL statement must return exactly one row and one column in all cases. |
If the program executable file requires an argument, you should require it for your concurrent program.
If the value set for this parameter does not allow security rules, then this field is display only. Otherwise you can elect to apply any security rules defined for this value set to affect your parameter list.
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 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.
If your value set is of the type Pair, this field is display only. The value defaults to Pair.
Enter the following:
Indicate whether to display this parameter in the Parameters window when a user submits a request to run the program from the Submit Requests window.
You should provide a default type and value for any non-displayed parameter.
For a parameter in an Oracle Reports program, the keyword or parameter appears here. The value is case insensitive. For other types of programs, you can skip this field.
Enter the display length in characters for the parameter value description. Your window may show fewer characters of your description than you specify here if there is not enough room (determined by the sum of your longest prompt plus your display size for this parameter plus seven). However, your window does not display more characters of the description than you specify here.
Enter the field length in characters for this parameter. The user sees and fills in the field in the Parameters window of the Submit Requests window.
You should ensure that the total of the value set maximum sizes (not the display sizes) for all of your parameters, plus the number of separators you need (number of parameters minus one), does not add up to more than 240. If your program values' concatenated length exceeds 240, you may experience truncation of your data in some forms.
The default is the name of the parameter.
A user sees the prompt instead of the parameter name in the Parameters window of the Submit Requests window.
Enter the display length in characters for the parameter value description. The user sees the parameter value in the Parameter Description field of the Submit Requests and View Requests forms. The Parameter Description field concatenates all the parameter values for the concurrent program.
Tip: We recommend that you set the Concatenated Description Size for each of your parameters so that the total Concatenated Description Size for your program is 80 or less, since most video screens are 80 characters wide.
Copyright © 1994, 2010, Oracle and/or its affiliates. All rights reserved.