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.
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. 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. 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.
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. 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. 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. 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.
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:. 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:. 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.
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.
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. See: Concurrent Programs. 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:. 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. 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. This prevents updates to shared parameters, which are not propagated to other reports in the set, from generating unwanted inconsistencies. The two reports and their parameters are listed in the table below:.
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.
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.
This essay explains how you can organize your applications programs and reports into request groups. It presents the following topics:.
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. 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.
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. 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. You can customize the Submit Request window in several ways. You can change the title to reflect the requests available in the window. You can restrict the reports and programs available to those in a specified request group.
The form exits after the user acknowledges the displayed request ID for the submitted request. 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. 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. 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. 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. 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. Note: The concept of "Global" incompatibilities was introduced with Patch 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.
Navigate to the Incompatible Programs block in the Concurrent Programs form and list those programs that your request set or stage is incompatible with. 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:. 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:. 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. This section provides information for system administrators on custom concurrent programs.
It explains certain procedures and conventions for creating customized concurrent programs:. 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. The following table lists the file extensions used for these programs and the directories where the programs should reside. This module can be used to create a spawned or an immediate program. 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. Name your program's executable file exactly as you identified it in the Execution File field of the Concurrent Program Executable window.
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. Tip: For ease of maintenance, define your concurrent program executables as spawned. If you change this file, you should reread it by logging in again so that the changes take effect. 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. In all the examples, you should run the commands from the directory in which your files are located. 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. Modify your copy according to the instructions contained in the file. This is the file adrelink uses to link your stand-alone executables. To create a program library, you link your compiled library catalog with your program object files using an Oracle Application Object Library link procedure. 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:. 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:. 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. Each of these arguments can be at most 50 characters. In some cases, there are security concerns with passing your Oracle username and password directly to your HOST program.
Alternatively, you can not pass it at all. 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. Oracle Application Object Library requires this syntax because it parses the argument string twice.
For example, to pass this argument to a program:. Default values are listed to the right. If the concurrent manager is down, your CONCSUB process waits indefinitely until the concurrent manager is started and the request completes. 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. 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:. 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.
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 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. 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. 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. 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.
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. 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.
There are two aspects to a parameter associated with a concurrent program: its value set and its behavior. 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.
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:. 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. These values cannot be changed on 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. The following table describes how a parameter's details affect its behavior in the Request Sets form and Run Requests form. The following table lists warnings for modifying program definitions:.
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. You can copy, rename, and modify the program so it displays only three parameters, with only one parameter requiring user entry. 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. 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. 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.
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. Skip to content. This is really good example with screen shot Thanks. Keep it up sir. You are helping many of troubled engineers. Thanks a lot. These include:. Run this batch job after you have loaded Oracle Inventory items and set the Inventory organizations.
This program populates Oracle iStore's category search table with product information from the Oracle Inventory tables. Typically, you should not run the iStore Search Insert concurrent program more than once. However, you may need to rerun this program under one of the following three conditions:.
To switch from category-level to section-level search, run only the iStore Section Search Refresh program. If you have enabled a section-level search, rerun this concurrent program whenever you change the setting of the fuzzy search functionality.
If you need to duplicate a section having more than 1, child sections, use the iStore Duplicate Section concurrent program. See the "Creating and Maintaining Sections" section in the chapter, Implementing the Catalog, for more information. To copy the layout mappings from a parent section to all of the children sections underneath it, use the iStore Section Layout Mapping Concurrent Program.
See the "Creating and Maintaining Sections" section in the chapter, Implementing the Catalog , for more information. Note: This concurrent program only works with sections using Configurable Layout.
Schedule this program as a batch process that runs at pre-determined intervals. This program converts the Express Checkout shopping carts into orders. Refer to the chapter, Implementing Reports , for more information. The functionality is implemented as two concurrent programs:. The concurrent program request set, iStore Lead Import Set, pulls data matching certain parameters into the Oracle Sales leads database table.
The iStore Autoplacement concurrent program can be used to populate leaf sections with products from Oracle Inventory categories. The program also can remove products from sections that no longer match the criteria of the concurrent program and section-category mappings. Both existing customers and new customers who want to use the OCM integration must run the concurrent program as a mandatory step to migrate the seed and customer data.
0コメント