Session Initialization

This chapter describes the format and parameters of the initialization message for the runtime Oracle Configurator.

This chapter covers the following topics:

Overview

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.

Introduction

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.

Definition of Session Initialization

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.

Responsibilities of the Host Application

The responsibilities of the host application for initializing and integrating the runtime Oracle Configurator are:

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.

Setting Parameters

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.

Parameter Syntax

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.

Omitting Parameters or Values

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.

Typical Parameter Values

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.

Explanation of initialization parameters in Basic XML 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 Test of Initialization

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>

Parameter Validation

When your host application calls the runtime Oracle Configurator, the Oracle Configurator Servlet validates the parameters of the initialization message.

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.

Logging of Parameter Use

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.

Initialization Parameter Types

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.

Types of Initialization Parameters
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

Login 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.

Initialization Parameters Required for Login
Parameter Combination Used to Launch Oracle Configurator From ...
database_id, icx_session_ticket, and responsibility_id
  • A host application, using Oracle Applications login authentication

  • Oracle Configurator Developer, by using the Test Model button

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.

Model Identification Parameters

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:

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.

Identifying the User Interface Definition

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).

Identifying the Configuration

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.

Identifying the Model

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.

Imported BOM Models

Parameters to specify:

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:

Models Created in Configurator Developer

Parameters to specify:

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:

Model Publication Identification Parameters

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 Parameters for Publishing Applicability
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

Support of Multiple Instantiation

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.

Return URL Parameter

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.

Pricing Parameters

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.

ATP 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:

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.

Arbitrary 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.

Parameter Compatibility

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.

Initialization Parameter Descriptions

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.

Initialization Parameters for Oracle Configurator
Name
alt_database_name
application_id
apps_connection_info
atp_package_name
calling_application_id
client_header
client_line
client_line_detail
config_creation_date
config_effective_date
config_effective_usage
config_effective_usage_id
config_header_id
config_model_lookup_date
config_rev_nbr
configurator_session_key
context_org_id
customer_id
customer_site_id
database_id
get_atp_dates_proc
icx_session_ticket
inventory_item_id
jrad_standalone
model_id
model_quantity
operating_unit_org_id
organization_id
price_mult_items_mls_proc
price_mult_items_proc
price_single_item_proc
pricing_package_name
product_id
publication_mode
pwd
read_only
requested_date
return_url
save_config_behavior
share_dio
sbm_flag
ship_to_org_id
template_url
terminate_id
terminate_msg_behavior
ui_def_id
ui_type
user
user_id
warehouse_id

alt_database_name

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

application_id

The ID from FND_APPLICATION.APPLICATION_ID that is the ID of the host application.

apps_connection_info

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:

atp_package_name

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.

calling_application_id

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:

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).

client_header

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.

client_line

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.

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.

config_creation_date

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.

Date and Time Format for 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>

config_effective_date

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.

config_effective_usage

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.

config_effective_usage_id

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.

config_header_id

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.

config_model_lookup_date

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.

config_rev_nbr

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.

configurator_session_key

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.

context_org_id

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.

customer_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.

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.

database_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

get_atp_dates_proc

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.

icx_session_ticket

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.

inventory_item_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.

jrad_standalone

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.

model_id

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.

model_quantity

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.

Notes

Be aware of the effect of passing various values for this parameter when:

Examples:

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:

The following table lists the effects of contributions to Model Quantity by different values of the model_quantity parameter.

Effects of Contributions to Model Quantity
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

operating_unit_org_id

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.

organization_id

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.

price_mult_items_mls_proc

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.

price_mult_items_proc

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.

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.

pricing_package_name

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.

product_id

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>

publication_mode

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.

pwd

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.

read_only

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.

requested_date

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.

responsibility_id

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.

return_url

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.

save_config_behavior

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.

sbm_flag

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.

share_dio

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.

ship_to_org_id

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.

template_url

Used only with DHTML legacy user interfaces, which are no longer supported..

terminate_id

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.

terminate_msg_behavior

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.

ui_def_id

The identifier for a particular User Interface created in Configurator Developer. The value for the ui_def_id parameter is obtained by:

ui_type

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.

user

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.

user_id

The ID from FND_USER.USER_ID.

warehouse_id

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.