This chapter describes the format and parameters of the initialization message for the runtime Oracle Configurator.
This chapter covers the following topics:
This chapter describes the format, parameters, and use of the initialization message for the runtime Oracle Configurator, including information about:
Note: If your host application is part of Oracle Applications, then the initialization message is already defined, and you do not need to define it yourself. However, this chapter may be of great value to you in understanding how that initialization message calls the runtime Oracle Configurator.
If your host application is a custom application, then you must define your own initialization message, as described in this chapter.
See Configurator Architecture for an explanation of the interaction between the elements discussed in this chapter.
In a typical host application (such as a web store), a button, tab, or similar control is coded so that it launches the runtime Oracle Configurator, allowing the end user to configure a model of a product or service. For the purposes of this explanation, think of this control as "the Configure button". This chapter describes how to make the Configure button select the wanted configuration model and user interface in the runtime Oracle Configurator.
Session initialization takes place when your host application calls the runtime Oracle Configurator and renders your configuration model in the user interface you have specified. The initialization message allows a host application to start a configuration session with specified characteristics.
When you set the parameters of the initialization message in your host application, your parameters handle the types of responsibilities listed in Initialization Parameter Types.
When your host application calls the runtime Oracle Configurator, the initialization message is sent to the Oracle Configurator Servlet, using the HTTP POST method. (POST is used in preference to GET to accommodate the length of the message).
See Invocation of Oracle Configurator by Host Application for a description of how the initialization message is routed, depending on the requirements of the host application, and the type of user interface.
The initialization message is written in XML, and has <initialize> as its document element. You must specify the parameters for <initialize> to determine the state in which the runtime Oracle Configurator opens. See Setting Parameters for details.
The responsibilities of the host application for initializing and integrating the runtime Oracle Configurator are:
Providing end users with a means (such as a Configure button) of posting the initialization message to the Oracle Configurator Servlet. See Setting Parameters for details.
Handling initialization of the runtime Oracle Configurator, to prepare it for your user’s configuration session. See Invocation of Oracle Configurator by Host Application for background.
Disabling visible functions in the surrounding host application that would confuse the user while interacting with the runtime Oracle Configurator.
Handling the output from the return URL (as described in Return URL Parameter), and closing the configurator window by resetting its frame’s location property.
Handling termination of the runtime Oracle Configurator, to return control and results to the host application when your user closes the window. See Definition of Session Termination for background.
You may be able to provide your host application with improved performance by preloading the Oracle Configurator Servlet, which involves providing an initialization message in a text file. The name of the text file is specified with the OC Servlet property cz.uiservlet.pre_load_filename, as described in the Oracle Configurator Installation Guide. For details on preloading with an initialization message, see the Oracle Configurator Performance Guide.
You specify <initialize> and its parameters as the value of an XML message that is passed to the Oracle Applications Framework, as described in Invocation of Oracle Configurator by Host Application. The Oracle Applications Framework is called through the URL specified in the profile option BOM: Configurator URL of UI Manager. See the Oracle Configurator Installation Guide for details about setting profile options. For more information on the Oracle Applications Framework, see the Oracle Application Framework Documentation Resources, Release 12, on MetaLink.
All parameters to the XML initialization message are specified as name-value pairs, using attributes of the <param> document element, in the form:
<param name="parameter_name">parameter_value</param>
Syntax of initialization message in HTML context shows the basic syntax for specifying the Oracle Configurator Servlet’s URL and the initialization message as you would typically use them in your host application. The parts that you need to modify are typographically emphasized.
Syntax of initialization message in HTML context
...
<script language="javascript" >
function init() {document.test1.submit();}
</script>
<body onload="init();">
<form
action="URL_of_OC_Servlet"
method="post" id="test1" name="test1">
<input type="hidden" name="XMLmsg" value=
'<initialize>
<param name="parameter_1_name">parameter_1_value</param>
<param name="parameter_n_name">parameter_n_value</param>
</initialize>'>
</form>
</body>
...
When a Web page containing the kind of HTML coding shown in Syntax of initialization message in HTML context is rendered in a browser, the initialization message is posted to the URL of the Oracle Configurator Servlet, as described in Invocation of Oracle Configurator by Host Application.
See Basic XML initialization parameters for some typical values for the parameters, and Minimal HTML for invoking the Runtime Oracle Configurator for a test page that puts the values in context.
Be aware that XML permits you to use either single or double quotation marks around the value of an element’s attribute, so you might also write:
"<initialize>
<param name='parameter_name'>parameter_value</param>
</initialize>"XML messages are, by default, case-sensitive. The names of initialization parameters (shown as parameter_name in the syntax examples in this chapter) are also case-sensitive. If you pass a custom initialization parameter named MyParam, but your code tests for a parameter named myparam, then your test will fail.
You can only insert a given parameter once in the initialization message. If you insert the same parameter more than once, the last occurrence of the parameter is processed, and any preceding occurrences are ignored. This is important to remember when you specify Custom Initialization Parameters in the Configurator Preferences page in Oracle Configurator Developer, as described in the Oracle Configurator Developer User’s Guide. These custom initialization parameters are prepended to the parameters provided by Configurator Developer itself during a test session. Custom parameters that duplicate Configurator Developer parameters are thus ignored.
If you need to include non-ASCII characters in your initialization parameters, then specify the required character set as the value of the charset parameter in the meta element of your HTML page. Several examples follow:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta http-equiv="Content-Type" content="text/html; charset=EUC-JP">
If you omit a parameter entirely from the initialization message, then the parameter is ignored by the runtime Oracle Configurator.
However, if a parameter has a default value, then you must either accept the effect of the default, or override the default with a specified value. The default values for the parameters are provided in Initialization Parameter Descriptions.
Note: If you include a parameter in the initialization message, do not leave its value empty. Doing so causes an error when the initialization message is processed. If you omit the value of a parameter, then the runtime Oracle Configurator generates an error message indicating which parameter is missing a value. The message appears in the browser window, and in the servlet’s session log.
The example Basic XML initialization parameters shows an example of a basic set of initialization parameters, illustrating the types of responsibility shown in Types of Initialization Parameters.
See Syntax of initialization message in HTML context for the syntax of the initialization message, and Minimal HTML for invoking the Runtime Oracle Configurator for a test page that puts the values in context.
For the complete list of valid initialization message parameters, see Initialization Parameter Descriptions.
Basic XML Initialization Parameters
<initialize> <param name="database_id">serv02_sid01</param> <param name="user">operations</param> <param name="pwd">welcome</param> <param name="calling_application_id">708</param> <param name="responsibility_id">22713</param> <param name="ui_def_id">9740</param> <param name="ui_type">JRAD</param> <param name="return_url">http://www.mysite.com:8802/OA_HTML/myorg/myservlets/Checkout</param> </initialize>
The Explanation of initialization parameters table explains the parameters used in the example Basic XML initialization parameters.
The following table explains the basic initialization parameters.
| Parameter type | Name | Description |
|---|---|---|
| Login | database_id | The DBC file that identifies the login database. |
| Login | user | The user ID of the login user. |
| Login | pwd | The password of the login user. |
| Login | calling_application_id | The ID of the host application. |
| Login | responsibility_id | The responsibility of the login user. |
| Configuration | ui_def_id | The ID of the UI of the model to be configured. |
| Configuration | ui_type | The type of the UI identified by ui_def_id. |
| Return | return_url | The URL of the return URL servlet. |
Minimal HTML for invoking the Runtime Oracle Configurator shows the HTML for a minimal web page that calls the runtime Oracle Configurator. combines the invocation of the runtime Oracle Configurator shown in Syntax of initialization message in HTML context with the initialization message parameters shown in Basic XML initialization parameters. (For simplicity, omits the return_url parameter, which is shown in HTML for Invoking the Runtime Oracle Configurator with Return URL.)
You can use this test page as a stand-in for your host application, by opening it in a browser. You must substitute your own site-specific values for the parameters database_id and ui_def_id. You must also provide a site-specific host name and port for the action attribute of the form element in Minimal HTML for invoking the Runtime Oracle Configurator.
Minimal HTML for invoking the Runtime Oracle Configurator
<html>
<head>
<title>Minimal Configurator Test</title>
</head>
<script language="javascript" >function init() {document.test1.submit();}</script>
<body onload="init();">
<form
action="http://www.mysite.com:8802/OA_HTML/configurator/UiServlet"
method="post" id="test1" name="test1">
<input type="hidden" name="XMLmsg" value=
'<initialize>
<param name="database_id">serv02_sid01</param>
<param name="user">operations</param>
<param name="pwd">welcome</param>
<param name="calling_application_id">708</param>
<param name="responsibility_id">22713</param>
<param name="ui_def_id">9740</param>
<param name="ui_type">JRAD</param>
</initialize>'>
</form>
<pre>Loading... </pre></body>
</html>
When your host application calls the runtime Oracle Configurator, the Oracle Configurator Servlet validates the parameters of the initialization message.
There must be a way of connecting to the database, such as the parameter database_id.
There must be a way to choose a Model to be configured, so the initialization message must include one of the combinations described in Model Identification Parameters.
If there is an error processing the initialization message, the results are posted to the URL specified in the return_url parameter.
Initialization parameters are accessible to Configurator Extensions and custom applications that use the Configuration Interface Object (CIO), by calling the method Configuration.getUserParameters(), which is described in the Oracle Configurator Extensions and Interface Object Developer’s Guide.
To determine exactly which values of the initialization parameters were used in a configuration session, you can examine the configuration session log files for the Oracle Configurator Servlet. For more information on logging, see Troubleshooting.
This section describes the use of the types of initialization parameters listed in the Types of Initialization Parameters table. All of the initialization parameters are described alphabetically in Initialization Parameter Descriptions.
| Type | Required? | Description | See |
|---|---|---|---|
| Login | Yes | Information required for access to the proper data, such as database, user, and password. | Login Parameters |
| Configuration | Yes | Identification of the Model to be configured, or of the existing configuration to be modified. | Model Identification Parameters |
| Publication | Yes, for published models | Information required to select the correct Model publication. | Model Publication Identification Parameters |
| Return | No, but recommended | Identification of the return URL that handles the results from the runtime Oracle Configurator, such as configuration outputs. | Return URL Parameter |
| Pricing and ATP | No | Identification of the procedures and interfaces to be used for obtaining prices and ATP dates. | Pricing Parameters ATP Parameters |
| Other | No | Miscellaneous information. | Arbitrary Parameters |
To connect the runtime Oracle Configurator to the database, your initialization message must specify one of the combinations of parameters listed in Initialization Parameters Required for Login.
For descriptions of the individual parameters, see Initialization Parameter Descriptions.
| Parameter Combination | Used to Launch Oracle Configurator From ... |
|---|---|
| database_id, icx_session_ticket, and responsibility_id | |
| database_id, calling_application_id, responsibility_id, user, and pwd |
|
You can use the same set of login parameters for both legacy and generated (HTML-based) UIs. If you do, use the ui_type parameter to distinguish between the UI types.
There are several different ways in which you can identify the Model to be configured, or the existing configuration to be modified. In your initialization message, you must use one of the parameters or a combination of the parameters listed in Model Identification Parameters:
| Method for Configuration Identification | Initialization Parameters | Described in ... |
|---|---|---|
| User Interface | ui_def_id | Identifying the User Interface Definition |
| Configuration | config_header_id config_rev_nbr |
Identifying the Configuration |
| Model | For Imported BOM Models:
For Models created in Configurator Developer: |
Identifying the Model |
For detailed descriptions of the individual parameters, see Initialization Parameter Descriptions.
Parameter to specify:
Using this parameter creates a new configuration. It is most useful for identifying a Model created entirely in Oracle Configurator Developer. It is also useful for specifying a particular UI out of several that may be available for a Model, whether or not the Model was created entirely in Configurator Developer.
This ID identifies a User Interface created in Configurator Developer. The User Interface includes identification of the Model to be configured (which is associated with configuration rules).
Parameters to specify:
Using this combination of parameters restores an existing saved configuration, and thus also the model used to create the configuration.
The Configuration Header ID is the main identifier of an existing configuration record previously created and saved by your host application or another application that knows how to save configurations to the CZ schema, such as the runtime Oracle Configurator. The Configuration Revision Number distinguishes among particular saved configurations sharing the same header information.
The parameters you should use to identify the configuration model depend on whether the model is an imported BOM Model or a Model created in Configurator Developer.
Using this combination of parameters creates a new configuration. It is only useful for identifying a Model that was originally created in another application (such as Oracle Applications Bills of Materials) and then imported into Oracle Configurator Developer.
Your host application must determine which Model to configure and be able to identify it by Inventory Item ID and Organization ID. See the individual descriptions of these parameters for more detail.
For backward compatibility only, you may need to specify these parameters:
context_org_id instead of organization_id
model_id instead of inventory_item_id
Parameters to specify:
config_effective_usage_id (for custom applications only)
publication_mode (for custom applications only)
If the root of your configuration model is a Model that you created in Oracle Configurator Developer, and you entered a Product ID when you published the Model, then you should specify only the product_id in your initialization message to identify the Model to configure. See the Oracle Configurator Developer User’s Guide for details about publishing Models.
The use of the Product ID to identify the Model requires the additional specification of the Usage and Mode for publication, according to the following conditions:
If the host application is a custom application (that is, not part of Oracle Applications), then you must also pass publication_mode and config_effective_usage_id in the initialization message.
If you do not pass config_effective_usage_id, then Oracle Configurator uses the default value of this parameter, which is Any Usage.
If you do not pass publication_mode, then Oracle Configurator uses the default value of this parameter, which is P (Production mode).
If the host application is part of Oracle Applications (such as Order Management), then Oracle Configurator automatically obtains the Usage and Mode from the profile options CZ: Publication Usage and CZ: Publication Lookup Mode and applies the values to the configuration session. Consequently, you do not have to specify the parameters yourself.
If your Model has been published, then you need to identify the specific Model publication that you want to configure. This requires that you specify publishing applicability parameters in your initialization message, in addition to those that identify the Model (which are described in Model Identification Parameters).
To determine the Model publication to display, you must specify in your initialization message one or more of the applicability parameters listed in Initialization Parameters for Publishing Applicability. These initialization parameters correspond to the applicability parameters that you specify when creating the publication in the Publications area of the Repository in Oracle Configurator Developer. See Publishing Configuration Models and the Oracle Configurator Developer User’s Guide for more information about publishing.
The following table lists the publishing initialization parameters as they appear in the initialization message and in Configurator Developer.
| Initialization Parameter | OCD Publishing Parameter |
|---|---|
| calling_application_id | Applications |
| config_effective_usage_id | Usages |
| config_model_lookup_date | Valid From/Valid To |
| publication_mode | Mode |
This following parameter indicates whether a host application supports multiple instantiation:
At runtime, Oracle Configurator checks this flag to see if the host application supports multiple instantiation. If this parameter is present in the initialization message, the model is launched regardless of its type. If the parameter is not present, users are prevented from working with the PTO model and its references to the BOM models under the root model. A message is returned informing the end user that the host application does not support multiple instantiation.
The return URL is the fully qualified URL of a Java servlet installed on your Web server that implements the behavior that you want to invoke after the user has ended a configuration session. The return URL for a configuration session is specified by the following initialization parameter:
The example Initialization Messagefor Invoking Oracle Configurator with Return URL shows the use of this parameter in an initialization message, to specify an example servlet class myorg.myservlets.Checkout. That example class is described in Implementing a Return URL Servlet
Initialization Message for Invoking Oracle Configurator with Return URL
<initialize> <param name="database_id">serv02_sid01</param> <param name="user">operations</param> <param name="pwd">welcome</param> <param name="calling_application_id">708</param> <param name="responsibility_id">22713</param> <param name="ui_def_id">9740</param> <param name="ui_type">JRAD</param> <param name="return_url">http://www.mysite.com:8802/OA_HTML/myorg/myservlets/Checkout</param> </initialize>
The URL specification in the return_url parameter must stop at the name of the servlet class. You cannot pass parameters to the class in this URL (for example, with the classname?parameter=value syntax). The return URL servlet should only get data from the termination message, which is passed to it as the value of the XMLmsg argument.
The termination message is sent to the return URL when a configuration session is terminated. This occurs in the event of normal termination, cancellation by the end user, or exceptions.
See The Return URL for details on the implementation of the return servlet.
These parameters are used when the runtime Oracle Configurator calls existing APIs to get pricing data for configured items.
Because these parameters are designed to be used with an interface using callback procedures, they are also referred to as callback pricing parameters.
This guide assumes that you are using Oracle Applications Release 12 and Oracle Advanced Pricing (QP), or your own callback pricing procedures that call Oracle Advanced Pricing.
To use callback pricing, provide the following set of parameters in your initialization message:
For descriptions of the individual parameters, see Initialization Parameter Descriptions.
See Pricing and ATP in Oracle Configurator for details on the use of these parameters. See Pricing and ATP Callback Procedures for examples of procedures that might be specified by these parameters.
These parameters are used when the runtime Oracle Configurator calls existing APIs to get ATP (Available To Promise) data for configured items.
Because these parameters are designed to be used with an interface using callback procedures, they are also referred to as callback ATP parameters.
This guide assumes that you are using Oracle Applications Release 12.
To use callback ATP, provide these parameters:
requested_date (optional, defaults to SYSDATE)
and one of the following:
For descriptions of the individual parameters, see Initialization Parameter Descriptions.
See Pricing and ATP in Oracle Configurator for details on the use of these parameters. See Pricing and ATP Callback Procedures for examples of procedures that might be specified by these parameters.
You can use the <param> document element to send arbitrary parameters that are not already provided, or that may be required for particular applications. You specify the arbitrary parameter as a name-value pair, using the syntax described in Parameter Syntax:
<param name="parameter_name">parameter_value</param>
For example:
<param name="org_home_page">http://www.oracle.com</param>
Such arbitrary parameters are not processed by the UI Server, but are passed to the Oracle Configuration Interface Object (CIO), thus making them available to Configurator Extensions. See the Oracle Configurator Extensions and Interface Object Developer’s Guide for information about obtaining a list of the initialization parameters passed.
While the architecture of Oracle Configurator allows for the possibility of validating XML parameters against a DTD, this is not currently enforced.
Initialization parameters are backwardly compatible. A host application can continue to use the initialization message parameters provided for a previous release with the same results, unless a parameter has been replaced or withdrawn, thus making it obsolete.
Obsolete parameters in the initialization message are ignored by Oracle Configurator. Your host application does not need to remove these parameters from the initialization message, but they have no effect on the initialization of Oracle Configurator.
This section lists alphabetically all the parameters of the initialization message. The use of parameters in the initialization message is described in Setting Parameters. The parameters are summarized in Initialization Parameters for Oracle Configurator.
A fully specified JDBC connect string or URL, specifying the JDBC driver and the database alias of the database to connect to.
This parameter is recommended for use during development of your application, as an alternative to connecting as an Oracle Applications user. It is not recommended for production deployment. To provide security in a production deployment, you can disable this parameter by setting the OC Servlet property cz.uiserver.allow_alt_database_login to false. This setting prevents a login that uses this parameter. For details on setting this property, see the current release or patch information for Oracle Configurator on MetaLink, Oracle's technical support Web site.
This login parameter is retained for backward compatibility. It is only valid for legacy Oracle Configurator User Interfaces, not for generated User Interfaces (HTML-based). It must be accompanied by user and pwd.
You must specify thin drivers in the connect string, as shown in the following example.
Example for alt_database_name
jdbc:oracle:thin:@server01:1521:vis11
The ID from FND_APPLICATION.APPLICATION_ID that is the ID of the host application.
If Oracle Configurator is running in one database (for example, Release 12), and connecting to another database to perform pricing, this parameter describes how to connect to the other database. The apps_connection_info element can contain one of the following parameters or sets of parameters:
alt_database_name, user, and pwd
The name of the PL/SQL interface package that the runtime Oracle Configurator calls to get ATP information. This parameter is required if the ATP callback interface is to be used. The particular procedure in the package to be used for calculating ATP dates is specified by get_atp_dates_proc.
The ID obtained from FND_APPLICATION.APPLICATION_ID that identifies the host application. The predefined APPLICATION_ID for Oracle Configurator is 708.
When publishing Models from Oracle Configurator Developer, you must select at least one application from the list of all registered applications. Applications that are not part of Oracle Applications must be registered in Oracle Applications before they can use this parameter. For more information about registering applications, see the Oracle E-Business Suite System Administrator’s Guide.
If the host application is part of Oracle Applications (for example, Order Management, iStore, or TeleSales), it is important to note that the host application displays the publication only if:
The publication’s Application applicability parameter includes the short name of the application (for example, ONT is the short name for Oracle Order Management)
The application is assigned to the end user’s Responsibility, which is defined in Oracle Applications
An Oracle Applications user can often choose one of many Responsibilities, but each Responsibility is assigned to only one application.
You specify applicability parameters when defining a publication in Configurator Developer. For more information, see the Oracle Configurator Developer User’s Guide.
When the publication is created, a value for FND_APPLICATION.APPLICATION_ID is saved in the database. It is very important to ensure that if the development and production publications are on separate servers, then the custom application must be registered on both servers; it is your responsibility to verify that the custom application’s ID is the same on both servers.
See also responsibility_id.
This is a required parameter.
Note: Oracle Order Management (OM) launches Oracle Configurator using a calling application ID in the initialization message that is based on the Responsibility selected by the OM user. When a user accesses the Sales Order form using the "Order Management Super User" responsibility, all configuration models that were published with the "ONT" Publication applicability parameter can be configured using Oracle Configurator. However, when accessing the Sales Order form using the Manufacturing and Distribution Manager responsibility, these same published models are not available, even though the host application is the same (OM). To make the same models available to the Manufacturing and Distribution Manager responsibility, republish your models such that they are also available to Oracle Manufacturing (appears as "Manufacturing" in Configurator Developer).
A string or number identifying the unit of work for the host application (for example, an order or quote). Used in conjunction with the methodology for input configuration attributes, which is described in the Oracle Configurator Methodologies documentation. See also client_line and client_line_detail.
A string or number identifying the particular part of the order or quote that the configuration is initiated against. Used in conjunction with the methodology for input configuration attributes, which is described in the Oracle Configurator Methodologies documentation. See also client_header and client_line_detail.
A string or number used to provide additional information if client_line does not provide enough. Used in conjunction with the methodology for input configuration attributes, which is described in the Oracle Configurator Methodologies documentation. See also client_header and client_line.
The host application’s notion of when the configuration is created.
The value for the config_creation_date parameter must be determined by your host application. It is the host application’s notion of when the configuration was created.
See also: config_effective_date and config_model_lookup_date.
Oracle Order Management specifies a value for this parameter when invoking Oracle Configurator, using by default the value of Model Line Creation Date. The values of config_effective_date and config_model_lookup_date are defaulted.
The value of this parameter must be in the format MM-DD-YYYY-HH-MM-SS. The values for the tokens in this format are shown in Date and Time Format for Parameter:
The following table lists the date and time formats used for the config_creation_date parameter.
| Token | Meaning |
|---|---|
| MM | The number of the month |
| DD | The number of the day of the month |
| YYYY | The year |
| HH | The 24-hour representation of the hour |
| MM | The number of minutes |
| SS | The number of seconds |
Default for config_creation_date
For a new configuration: the value of SYSDATE. For a restored configuration: the saved value of config_creation_date. If the parameter value does not include the HH-MM-SS portion, then the default time is assumed to be midnight (00-00-00).
Example for config_creation_date
<param name="config_creation_date">03-25-2001-19-30-02</param>
The date used to filter effective nodes and rules.
This parameter has the same structure as config_creation_date.
See also config_creation_date and config_model_lookup_date.
This parameter is not required.
Default for config_effective_date
For a new configuration: the value of config_creation_date. For a restored configuration: the saved value of config_effective_date.
This parameter is now deprecated. If you are implementing Multiple Language Support (MLS), you should instead use config_effective_usage_id. You cannot use both parameters together.
The name of a Usage created in Oracle Configurator Developer. Usage names are used to identify publications, and to set the Usage on a runtime configuration session. See the Oracle Configurator Developer User’s Guide for details.
The value is not case-sensitive.
Default for config_effective_usage
The default value of this parameter is Any Usage.
The numeric ID associated with a Usage created in Oracle Configurator Developer, where you specify a Name and Description for the Usage. Usage IDs are used to identify publications, and to set the Usage on a runtime configuration session. See the Oracle Configurator Developer User’s Guide for details.
The Usage ID is stored in the database column MODEL_USAGE_ID in the table CZ_MODEL_USAGES. For more information, see Usages.
To obtain the ID value for this parameter, run the following query, then choose the MODEL_USAGE_ID value that corresponds to the NAME or DESCRIPTION of the desired Usage.
Query for Usage IDs
SELECT
cz_model_usages.MODEL_USAGE_ID,
cz_model_usages.NAME,
cz_model_usages_tl.DESCRIPTION,
cz_model_usages_tl.LANGUAGE,
cz_model_usages_tl.SOURCE_LANG
FROM
cz_model_usages,
cz_model_usages_tl
WHERE
cz_model_usages_tl.LANGUAGE = USERENV ('LANG')
AND
cz_model_usages.MODEL_USAGE_ID=cz_model_usages_tl.MODEL_USAGE_ID
AND
cz_model_usages.in_use = '1';
This parameter determines the publishing Usage name for the configuration model. See Models Created in Configurator Developer for more information about using this parameter.
This parameter replaces config_effective_usage. You cannot use both parameters together.
This parameter is not required.
Default for config_effective_usage_id
The default value of this parameter is Any Usage, whose MODEL_USAGE_ID is normally -1.
The identifier for an existing configuration. Only used for retrieving a configuration previously saved by the runtime Oracle Configurator. Not present if the configuration was not saved.
The value for the config_header_id parameter is obtained from CZ_CONFIG_HDRS.CONFIG_HDR_ID in the CZ schema.
Date to look up the publication for the configuration Model. This parameter has the same structure as config_creation_date.
See also: config_effective_date and config_model_lookup_date.
This parameter is not required.
Default for config_model_lookup_date
For a new configuration: the value of config_creation_date. For a restored configuration: the saved value of config_effective_date, or SYSDATE, as determined by RestoredConfigDefaultModelLookupDate in CZ_DB_SETTINGS; see RestoredConfigDefaultModelLookupDate for details.
The configuration revision number. Only used for retrieving a configuration previously saved by the runtime Oracle Configurator. Not present if the configuration was not saved.
The value for the config_rev_nbr parameter is obtained from CZ_CONFIG_HDRS.CONFIG_REV_NBR in the CZ schema.
An application-dependent string that identifies a configuration session, and allows linking a pricing or ATP request from the runtime Oracle Configurator to the host application entity that started the configuration session. Examples for creating this key might be: order header ID with order line ID, or quote ID with quote revision number.
This parameter is for backward compatibility only. Instead of this parameter you should use its synonym, organization_id.
This parameter is the organization identifier for the BOM exploder. The value for the context_org_id parameter must be determined by your host application. It is ultimately derived from MTL_SYSTEM_ITEMS.ORGANIZATION_ID.
When getting ATP dates, the ID of the customer to which the configured product is to be shipped. Must be used with customer_site_id.
When getting ATP dates, the ID of the customer site to which the configured product is to be shipped. Must be used with customer_id.
The name of the DBC file that contains database connectivity information, without its filename extension of .dbc. This file can be found in a standard Oracle Applications installation by calling the PL/SQL function fnd_web_config.database_id. This parameter must be used with certain other parameters, as described in Login Parameters.
Example for database_id
myhost01_mysid05
The name of the "get ATP dates" procedure to be called from the package specified by atp_package_name. This parameter is conditionally required; it must be provided if the ATP callback interface is to be used.
An ICX session ticket encodes an Oracle Applications session.
This is the recommended way for Oracle Applications to call the runtime Oracle Configurator.
You can use the PL/SQL function cz_cf_api.icx_session_ticket to obtain a value for this parameter. (See the description of ICX_SESSION_TICKET for details about the function cz_cf_api.icx_session_ticket.)
When passing an icx_session_ticket, the host application must also pass a database_id.
This parameter is a synonym that replaces model_id.
This parameter is the imported Inventory Item ID for the top-level imported BOM Model. It is used together with organization_id to identify the configuration model. The value for this parameter must be determined by your host application. It is ultimately derived from MTL_SYSTEM_ITEMS.INVENTORY_ITEM_ID.
This parameter is conditionally required. There is no default value.
Controls whether the user interface for the runtime Oracle Configurator is designed to stand alone in its own window, or to be part of its host application’s window. The standalone design includes the page header and global buttons provided by the Oracle Applications Framework. For more information about the Oracle Applications Framework, see the Oracle Application Framework Documentation Resources, Release 12, on MetaLink.
The values allowed for this parameter are shown in the following table:
| Value | Meaning |
|---|---|
| true | The UI for the runtime Oracle Configurator is rendered with a header and global buttons. |
false |
The UI for the runtime Oracle Configurator is rendered without a header or global buttons. |
Default for jrad_standalone
The default value of this parameter is false.
This parameter is for backward compatibility only. Instead of this parameter you should use its synonym, inventory_item_id.
This parameter is the inventory item identifier for the top-level Model.
The value for the model_id parameter must be determined by your host application. It is ultimately derived from MTL_SYSTEM_ITEMS.INVENTORY_ITEM_ID.
Conditionally required. No default.
Only BOM Models can be configured with this parameter. The value of this parameter is a number that indicates how many identical copies of the Model are being configured. The model quantity may change during a configuration session, so the final quantity should be read from the associated output item in the termination message.
Default for model_quantity
For a new configuration, the default is 1. The host application may set a different number.
Be aware of the effect of passing various values for this parameter when:
The model is a BOM Model. (Only BOM Models can be configured with the model_quantity parameter.)
There exist configuration rules that contribute some quantity to the numeric value of the model root (that is, the rules specify that a certain quantity of the model should be in the configuration).
Background: Only rules defined on non-BOM nodes can make such contributions. Otherwise, Quantity Cascade calculations result in a numeric cycle.
These rules are triggered when the configuration is created, rather than as the result of user selections.
Background: A rule is triggered when the conditions defined for it are satisfied.
Examples:
A BOM Model is modified by adding a Feature with one Option and a Min/Max of (1,1). A Numeric Rule is defined on that Feature which contributes a value to the quantity of the root BOM Model. When a configuration is created, the condition for the rule is satisfied (because a Min/Max of (1,1) results in a mandatory selection of the Option), and the quantity specified by the Numeric Rule is contributed.
A BOM Model is modified by adding an Integer Feature with an initial value. A Numeric Rule is defined on that Feature, which contributes the value of the Feature to the quantity of the root BOM Model. When a configuration is created, the condition for the rule is satisfied, and the quantity specified by the Numeric Rule is contributed.
The effects of combining contributions to the model’s quantity with passing a value for the initialization parameter model_quantity when creating or restoring a configuration is illustrated in Effects of Contributions to Model Quantity. Not all of the possible scenarios are illustrated.
In Effects of Contributions to Model Quantity, the following symbols are used:
C represents a contribution from a configuration rule to the root BOM model that exists at the creation of the configuration.
NM represents a value for the model_quantity parameter that is passed in while creating a new configuration.
RM represents a value for the model_quantity parameter that is passed in while restoring a saved configuration.
The following table lists the effects of contributions to Model Quantity by different values of the model_quantity parameter.
| Contribution | Model Quantity | Final Quantity | |
|---|---|---|---|
| New Configuration: | |||
| Case 1 | C | NM>=C | NM |
| Case 2 | C | NM<C | C, with Validation FailureThese Validation Failure messages are deleted once their text is viewed. |
| Case 3 | None or 1 | None | 1 |
| Case 4 | C>1 | None | C |
| Restored Configuration: | |||
| Saved In Case 1 | C | RM>=C | RM |
| Saved In Case 1 | C | RM<C | C, with Validation Failure |
| Saved In Case 1 | None | RM | RM |
| Saved In Case 1 | C | None | NM |
The Organization ID for the Oracle Applications Operating Unit Organization.
This parameter supports the use of Multiple Organization Access Control (MOAC), which requires the Operating Unit to be provided for a configuration session.
Oracle Applications that call Advanced Pricing or ATP pass this parameter when invoking the Runtime Oracle Configurator. You must provide this parameter in a customized initialization message, or in the Custom Initialization Parameters field in Oracle Configurator Developer, if you use Advanced Pricing or ATP, or use MOAC-enabled code in a Configurator Extension.
When this parameter is provided, Oracle Configurator establishes the provided Operating Unit Organization for the configuration session. If the parameter is not provided, the default Operating Unit Organization is established. If there is no default, then no Operating Unit Organization is established.
The Organization ID for the Oracle Applications Item Validation Organization.
This parameter is a synonym that replaces context_org_id.
This parameter is the imported Organization ID for the top-level imported BOM Model. It is used together with inventory_item_id to identify the configuration model. The value for this parameter must be determined by your host application. It is ultimately derived from MTL_SYSTEM_ITEMS.ORGANIZATION_ID.
If you are using Oracle Order Management, this is the organization identifier for the BOM exploder. See the documentation for Order Management for information on setting the Item Validation organization.
This is the name of the "price multiple items" procedure to be called in an MLS environment. This parameter should be used by a host application that supports multiple currencies, not just USD (US dollars).
When using pricing callbacks, you must include a parameter that specifies a pricing procedure, such as price_mult_items_mls_proc. However, this parameter is mandatory in an MLS environment. See Pricing Parameters for background information about parameters that are required for pricing callbacks.
Use this parameter instead of price_mult_items_proc, because the procedure called through this parameter displays prices in the correct currency and format.
The name of the "price multiple items" procedure to be called from the package specified by pricing_package_name.
This parameter is conditionally required; either this parameter, price_single_item_proc or price_mult_items_mls_proc must be provided if pricing callbacks are used.
Use price_mult_items_mls_proc instead of this parameter, because the procedure called through this parameter displays prices only in USD (US dollars).
This parameter takes precedence over price_single_item_proc.
This parameter is now deprecated. Use price_mult_items_proc if possible.
The name of the "price single item" procedure to be called from the package specified by pricing_package_name.
This parameter is conditionally required; one of this parameter, price_mult_items_proc, or price_mult_items_mls_proc must be provided if pricing callbacks are to be used.
This procedure is not called if price_mult_items_proc is provided.
The name of the PL/SQL interface package that the runtime Oracle Configurator calls to get pricing information. This parameter is required if the pricing callback interface is to be used. The particular procedure in the package to be used for performing pricing is specified by either price_mult_items_proc or price_single_item_proc.
For a Model created in Configurator Developer, the value for this parameter is the string you enter for Product ID when you create the publication record for the Model.
For an imported BOM Model, the value for this parameter is automatically generated when you create the publication record for the BOM Model (by concatenating the imported Organization ID with the imported Inventory Item ID) and cannot be modified. If you are configuring a BOM Model, you should probably use the combination of organization_id and inventory_item_id instead of this parameter.
If this parameter is included in the initialization message, Oracle Configurator uses the function CZ_CF_API.CONFIG_MODEL_FOR_PRODUCT to determine which Model and User Interface should be used.
The value for this parameter is obtained from CZ_MODEL_PUBLICATIONS.PRODUCT_KEY in the CZ schema.
The use of the Product ID to identify the model requires the additional specification of the Usage and Mode for publication. If the host application is a custom application (that is, not part of Oracle Applications), then you must also pass publication_mode and config_effective_usage_id. If the host application is part of Oracle Applications (such as Order Management), then the Usage and Mode are obtained directly from the profile options CZ: Publication Usage and CZ: Publication Lookup Mode.
See Models Created in Configurator Developer for more information about using this parameter.
Default for product_id
This parameter is conditionally required. There is no default value.
Examples for product_id
To make your application use a Configurator Developer Model with the Product ID of ABC1234, insert the following parameter in your initialization message:
<param name="product_id">ABC1234</param>
To make your application use an imported BOM Model with the organization_id 204 and the inventory_item_id 137, insert the following parameter in your initialization message:
<param name="product_id">204:137</param>
Determines the publication mode for the configuration model. See Models Created in Configurator Developer for more information about using this parameter.
The values allowed for this parameter are shown in the following table:
| Value | Meaning |
|---|---|
P |
Production |
T |
Test |
This parameter is not required.
Default for publication_mode
The default value of this parameter is P.
The password to use when logging in to the Oracle Applications database. Use the Oracle Applications password if you identified the database with the database_id parameter. Use the database password if you identified the database with the alt_database_name parameter. Used in conjunction with user.
If the value is true, the UI Server provides a read-only UI for viewing configurations. The end user can examine options, but cannot select any. The Finish button is disabled. The UI Server displays a message at the beginning of the configuration session, indicating that the session is read-only. If the value is false, the UI Server provides the normal UI for configuring a model.
Default for read_only
The default value of this parameter is false.
When getting ATP dates, the requested date entered on the order line. The format of the date must be MM-dd-yyyy. The default value of SYSDATE is used if you do not specify a different date.
When logging in to Oracle Applications, the responsibility determines the functions available to the login user. The value to use for this ID is obtained from FND_RESPONSIBILITY_VL.RESPONSIBILITY_ID.
The predefined RESPONSIBILITY_ID for the Oracle Configurator Developer responsibility is 22713. The responsibilities related to Oracle Configurator are described in The Predefined Configurator Developer Responsibilities.
See also calling_application_id.
The fully qualified URL of a Java servlet installed on your Web server that implements the necessary behavior after a configuration session is terminated. See Return URL Parameter for details, and Implementing a Return URL Servlet for a code example.
The example below shows the use of this parameter to specify a servlet class myorg.myservlets.Checkout, which is the example described in Implementing a Return URL Servlet
Example for return_url
<param name="return_url">http://www.mysite.com:8802/OA_HTML/myorg/myservlets/Checkout</param>
Note: It is necessary to register an alias for the return URL servlet. For details, see the Oracle Configurator Installation Guide.
The values allowed for this parameter are shown in the following table:
| Value | Meaning |
|---|---|
never |
A new configuration is not saved. |
new_config |
A new configuration is saved. |
new_revision |
A new revision of the configuration is saved. (If no existing revision is found, a new configuration is saved.) |
overwrite |
The existing configuration header and revision is used. |
Default for save_config_behavior
The default value of this parameter is new_revision.
If the value is overwrite, an error is signalled.
This parameter indicates whether the host application supports multiple instantiation. To support multiple instantiation the host application must have the appropriate patch applied. The following table describes the valid values for the sbm_flag parameter.
| Value | Meaning |
|---|---|
True |
The host application has installed the appropriate software patch that supports multiple instantiation. |
False |
The software patch supporting multiple instantiation has not been installed, and multiple instantiation is not supported by the host application. |
A message is returned when an end user attempts to instantiate a component at runtime, and the host application does not support instantiation. If the sbm_flag is not passed at all, host application support of multiple instantiation is considered False.
See the description of the related servlet property cz.uiservlet.dio_share in the Oracle Configurator Installation Guide. This initialization parameter overrides that servlet property, if both are present.
The values allowed for this parameter are shown in the following table.
| Value | Meaning |
|---|---|
false |
Disables sharing the cached version of the Model. This provides slower loading of the Model, but reflects the latest changes to the Model. |
true |
Enables sharing the cached version of the Model. This provides faster loading after the initial loading of the Model, but does not reflect the latest changes to the Model. |
When getting ATP dates, the ID of the organization to which the configured product is to be shipped. This value is obtained from SHIP_TO_ORG_ID in the OE_ORDER_LINES_ALL table.
Used only with DHTML legacy user interfaces, which are no longer supported..
Important: As of this release, DHTML UIs are no longer supported.
Identification number used to support guided selling in Oracle Order Management. An Applet session running in the UI Server generates a termination ID (which is a sequence number) and inserts it into the initialization message for the DHTML session (also running in the UI Server), as the value of this initialization parameter. When the DHTML session terminates, it stores its XML termination message in the database, identified by this termination ID. The Applet session then uses the termination ID to fetch the XML termination message from the database and return it to the host application (Order Management). For a related subject, see the discussion of the heartbeat mechanism and guided selling in the Oracle Configurator Installation Guide.
The values allowed for this parameter are shown in the following table:
| Value | Meaning |
|---|---|
full |
The entire termination message is passed back to the host application. This includes prices, if you have used a pricing interface package (see Pricing and ATP in Oracle Configurator ). |
brief |
No output or messages are passed to the caller. |
It is recommended that host applications using the CZ_CONFIG_DETAILS_V view to read configuration outputs use brief when the configuration is saved. If the configuration is not saved, then the outputs and messages are not readable from the database. If Oracle Configurator receives a connection error or other error, the error messages that it receives are passed back as messages even if the terminate_msg_behavior is brief.
The identifier for a particular User Interface created in Configurator Developer. The value for the ui_def_id parameter is obtained by:
Examining the UI ID column in the User Interface area of the Workbench in Oracle Configurator Developer
Calling the PL/SQL function cz_cf_api.ui_for_item (see UI_FOR_ITEM)
Indicates the type of user interface being specified for the model being configured. The type determines the agent that renders the UI in the runtime Oracle Configurator. See Runtime UI Types for background on the UI types provided by Oracle Configurator.
The values allowed for this parameter are shown in the following table:
| Value | Meaning |
|---|---|
Applet |
The UI is a legacy Applet UI. |
Custom |
The UI is a custom JSP UI. |
DHTML |
The UI is a legacy DHTML UI.
Important: As of this release, DHTML UIs are no longer supported. |
JRAD |
The UI is a generated HTML UI. |
The initialization message for all UI types is posted to the Oracle Configurator Servlet. For the JRAD type, the UI is rendered by the Oracle Applications Framework. For the Applet type, the UI is rendered by the Oracle Configurator Servlet.
You cannot change the actual type of a UI by changing the value of this parameter.
The username to use when logging in. Use the Oracle Applications username if you identified the database with the database_id parameter. Use the database username if you identified the database with the alt_database_name parameter. Used in conjunction with pwd.
When getting ATP dates, the ID of the organization that is going to ship the configured product to the customer. This value is obtained from SHIP_FROM_ORG_ID in the OE_ORDER_LINES_ALL table.