Set Up Oracle Configurator and Customize the Solution

This chapter covers the following topics:

Overview of Set Up Oracle Configurator Chapter

This chapter describes setup tasks that you perform to Oracle Configurator that are specific to the Oracle Telecommunications Service Ordering (TSO) solution.

Before You Begin

Before you can set up Oracle Configurator for use with the Oracle TSO solution, you must set up Oracle Bills of Material, Oracle Installed Base, and Oracle Order Management.

In addition to this chapter, there is another chapter on setting up Oracle Configurator for use with the TSO solution, Set Up Oracle Configurator Extensions.

Setup Checklist

Following is the setup checklist for implementing TSO-specific functionality for Oracle Configurator.

Oracle Configurator-TSO Setup Checklist
Setup Step Required/Optional
Implement Oracle Configurator Required
Create Configuration Model Required
Publish Container Model Required
Define Profile Options Required
Disable Pricing Optional
Customize Oracle Configurator Optional

For more information on functionality, setting up, or using Oracle Configurator, refer to:

Configurator Concepts

This section discusses Oracle Configurator concepts you need to be familiar with before implementing a TSO solution.

Conventions for Connector and Components of a Model

Some of the diagrams that appear in this chapter show the structural relationship between Connectors and Components of a Model. The following sample diagram and table show and describe the conventions for the Model diagrams.

the picture is described in the document text

The following table refers to the preceding diagram.

Model Diagram Conventions
Diagram Part Description
Model A
|_ Component X		 This part represents a simple Model structure. In this case, Component X is a child of Model A.
| |_Feature 1 Feature 1 is a child of Component X.
|->Model B This represents a Reference node. Model A references Model B.
| |~> Model C This represents a Connector node. Model B has a Connector to Model C.

Using Container Models

You can mark Oracle Bills of Material (BOM) Models within a Container Model as trackable. You can also mark BOM Option Classes and BOM Standard Items as trackable if they are inside a BOM Model. Tracking enables Oracle Installed Base to record information about an instance of that item, including its location, status, current configuration, change history, and so on. You must define the Container Model itself as non-trackable. Oracle Installed Base does not record information about non-trackable items. For more information about making an item Installed Base trackable, see the chapter, Set Up Installed Base.

Before an end user can reconfigure any of a Container Model's installed configurable instances, the Container Model must meet certain requirements, such as a valid Container Model structure, Connectors, and rules, to ensure that the configured items are trackable in Oracle Install Base. For more information about the necessary requirements, see the section, "Container Model Settings and Structure", below, and the chapter, Set Up Install Base.

Container Model Settings and Structure

The following list identifies the requirements for a Container Model in Oracle Inventory and Oracle Bills of Material.

A Container Model must be:

A Container Model cannot:

For example, the following figure shows BOM trackable items StndItem1, StndItem2, and BOM OC 1. This structure is invalid because these BOM items are all direct children of the Container Model.

Invalid Container Model Structure

the picture is described in the document text

Container models can contain Standard Items that are tangible. See Tangible Items for details.

For more information on creating or specifying Container Models, see the chapter, Set Up Inventory.

Importing Container Models into Oracle Configurator

To develop a Container Model in Oracle Configurator Developer, you must import the Oracle Inventory and BOM data into the Oracle Configurator (CZ) schema of the Oracle Applications database. For information about populating the CZ schema, see the Oracle Configurator Implementation Guide.

The concurrent programs under Populate and Refresh Configuration Models in Oracle Applications import the completed bills of material into the Oracle Configurator schema. Run the concurrent programs from the Oracle Configurator Administrator menu.

These concurrent programs import BOM structure (assemble-to-order, PTO, or Container Models, structure, and rules) and require complete BOMs that are identified at the desired root.

The concurrent programs under Populate and Refresh Configuration Models in Oracle Applications include:

When importing a container BOM Model, the system creates a Model node in Oracle Configurator Developer. If the imported Model has Components that are assemble-to-order (ATO) or PTO Models, then the import process creates:

If a Standard Item is marked as Shippable, Inventory Transactable, and Serializable, then it is imported as a tangible item. See Tangible Items for details.

Note that the importing of a BOM Model into Oracle Configurator Developer is not TSO-specific functionality. The preceding section sets the context for what may happen when a BOM Model that is also a container is imported or refreshed into Oracle Configurator Developer.

Verification Abilities of Populate and Refresh Concurrent Programs

The concurrent programs under Populate and Refresh Configuration Models do not verify that all of the settings that you selected when defining a Container Model in Oracle Applications are correct. If a Container Model violates any of the requirements listed in this section, an error occurs only when you generate logic in Configurator Developer, not when you import or refresh the Model.

The Refresh a Configuration Model and the Refresh all Imported Configuration Models concurrent programs check only two settings that you specify in Oracle Applications. When you refresh a Container Model, the concurrent program displays:

Structuring Container Models

In a Container Model, if one of the trackable child Models does not have a trackable parent or ancestor, there cannot be a limit on how many instances of that trackable child Model can be created at runtime. In other words, the trackable BOM Model's Instantiability setting must be Multiple or Variable Instances with an Initial Minimum of 0 and Initial Maximum of null in Configurator Developer.

If the Initial Minimum and Initial Maximum values are not 0/null, respectively, for a trackable item, Configurator Developer displays an error when you generate logic. A trackable item can contain both trackable and non-trackable items, such as BOM Models and Option Classes, as well as Components created in Configurator Developer.

Note: The first time you import a Container Model, the Populate Configuration Models concurrent program sets the Initial Minimum and Initial Maximum values to 0/null, respectively, for all trackable child BOM Models. However, refreshing a Container Model does not reset these values if you change them in Oracle Configurator Developer. If the Model's structure violates any of the requirements listed in this section, Oracle Configurator Developer displays an error when you generate logic.

Because you can create multiple instances of such a BOM Model during configuration, and Oracle Install Base tracks these instances when they are installed, a BOM Model matching this criteria is a trackable item. An example of a trackable item appears in the figure below.

Remember that you can only track BOM items, and that Oracle Install Base only records information about trackable BOM items.

Example of Trackable Items

the picture is described in the document text

In the above figure, PTO Trackable1 and PTO Trackable3 are trackable items because they are themselves trackable and do not have a trackable parent or ancestor. Therefore, you must set the Instantiability Initial Minimum and Initial Maximum values to 0 and null, respectively. The figure shows these settings as 0/null.

Note that the Initial Minimum and Initial Maximum values for PTO Trackable 2 and PTO Trackable 4 are not set to 0/null. This is because a trackable Model that is a child or a descendant of a trackable item does not have the same configuration requirements as a trackable item. That is, the trackable child item does not have to obey the rule when no instances exist, as long as the following is true:

Refer to the Oracle Configurator Developer User's Guide for more information about creating multiple instances of Components during configuration.

Examples of Valid and Invalid Container Model Structure

This section provides examples of how trackable items can impact the validity of a Container Model's structure in Oracle Configurator Developer.

In a Container Model, a trackable descendant Model can be a child of a non-trackable Model only if the non-trackable Model's Initial Minimum and Initial Maximum values are both set to 1, and:

or

In the figure above, the Model structure is valid because the Initial Minimum and Initial Maximum for Trackable2 equals 0/null.

Valid Model Structure: Trackable Child and Trackable Ancestor

the picture is described in the document text

Although Trackable2 is a child of NonTrackable2, the structure shown in the second figure is valid because the Initial Minimum and Initial Maximum for Trackable1 equal 0/null and Trackable1 is an ancestor of Trackable2. Because Trackable1 is a trackable item, an Oracle Install Base or Oracle Quoting user can select an installed instance of Trackable1 and launch Oracle Configurator to reconfigure it.

The following shows an invalid structure. It is invalid because NonTrackable's Initial Minimum equals 0.

Invalid Model Structure: Non-Trackable Parent and Trackable Child

the picture is described in the document text

If an Oracle Install Base or Oracle Quoting user selects an instance of Trackable2 for reconfiguration, its parent (NonTrackable) is not part of the configuration when the Oracle Configurator session begins. Therefore, Oracle Configurator cannot add an instance of Trackable2 to the configuration either.

In the following figure, Trackable2 is the first trackable BOM Model in the Container Model's structure. However, its instances values are not 0/null.

Invalid Model Structure: Non-Trackable Parent and Trackable Child

the picture is described in the document text

This structure is invalid because although you can configure and track Trackable2 in Oracle Install Base, there is a restriction on how many instances of Trackable2 are allowed at runtime.

Connecting Components

Oracle Install Base tracks the relationships that connections form between Components. Oracle Install Base keeps a record only of trackable BOM items, so any connections made at runtime must be from an instance of a trackable BOM Model to instances of other trackable BOM Models.

Because Oracle Install Base keeps a record of connected instances only if they are trackable, any Connectors that you create within a Container Model in Oracle Configurator Developer must be valid. If a Container Model contains Connectors that violate any of the requirements listed in this section, Oracle Configurator Developer displays an error when you generate logic.

Connectors enable you to define rules that include nodes from trackable items as participants. For more information, see the section, "Using Configuration Rules", above.

When working in a Container Model in Oracle Configurator Developer, you must create Connectors only from:

You must not create Connectors:

For example, a Container Model references a trackable Model named PTO1. PTO1 references a non-trackable Model named PTO2. You create a Connector from the Container Model to PTO2. Because you created a Connector from the Container Model to a Model that is a child of a trackable Model, Oracle Configurator Developer displays an error when you generate logic.

In the above figure:

But there are differences. Connector C5 has only a non-trackable target in NonTrackable5. Connector C4 has a non-trackable target with Model NonTrackable4 being a child of the Container. The Model NonTrackable4 is also a child of Trackable4, but these instances would be excluded from consideration by the Connector, and will not appear in the list of eligible targets.

Note: In Oracle Configurator Developer, when you select a BOM Model node, the BOM Item Type field indicates whether it is an ATO, PTO or Container Model. Additionally, when you select any BOM node, the Trackable check box indicates whether the item is trackable. You can expand the Definition attribute to view these settings.

Network Link Items

A network Link item is a BOM Model that connects trackable items. At runtime, an instance of a Link item connects instances of trackable items. In the TSO context, a Link item has only one unique aspect: it does not require that a location be assigned to it. For an explanation of the need for location information, see Locations.

An item is defined as a Link in Oracle Inventory, as described in Set Up Link Items. To determine at runtime whether a trackable item instance is a Link, Oracle Configurator checks whether the item's link flag is set to true. The link flag is described in Link Items Column. The link flag setting for a BOM Model is part of the structure that is imported with the Model.

In Oracle Configurator Developer, you must complete the definition of a Link by adding exactly two child Connectors to a BOM Model having a link flag set to true, to specify the connections that are valid between trackable items at runtime.

Transient Items and Attributes

A transient item is a BOM Standard Item used for the purpose of pricing a non-recurring service or fee. This concept is narrower than that of a one-time charge.

The ordering of a wireless phone may be a one-time charge that requires a 1-time fulfillment. This charge can also be trackable, in which case it reappears during a subsequent reconfiguration of the service. Another type of charge associated with changing a service, such as an installation fee or a service termination fee, is also a 1-time charge, but should never reappear during a subsequent reconfiguration of a service. Such items are termed transient.

Transient items are not trackable. They are never installed as instances in Installed Base. They do not appear in Oracle Configurator when the item they were initially ordered with is reconfigured. To ensure that these items do not appear during reconfiguration (where they might confuse the end user), you must use the transient flag to designate the transient items in your configuration Model.

Transient items can never be discontinued. Consequently, the method RuntimeNode.isDiscontinued() always returns false when used on a node that is a transient item or attribute. See About Discontinued Items for an explanation of discontinuation.

Since only BOM Standard Items can be transient, and since BOM Standard Items are always leaf nodes (i.e., nodes without children) in a configuration Model hierarchy, transient items are always leaf nodes.

Flagging Transient Items

You flag items as transient in Oracle Configurator Developer.

If a node satisfies all of the following criteria, then the Transient checkbox is enabled:

To mark an item as transient:

  1. In Main area of the Repository, edit the BOM Model containing the BOM Standard Item.

  2. Navigate to the Structure area of the Workbench.

  3. Edit the BOM Standard Item.

  4. In the Details page for the BOM Standard Item, select the Transient checkbox.

  5. Click Apply.

See the section, "Transient Items Column", below for related database details.

Transient Attributes

A transient attribute is conceptually similar to a transient item. After a service is fulfilled, attributes that are transient are not restored during the reconfiguration of the service.

You model transient attributes in Configurator Developer, with Features. Any type of Feature (Integer, Decimal, Boolean, Text, or Option Feature) can be used as a transient attribute.

During the reconfiguration of a trackable instance, Oracle Configurator ignores any inputs that are values of features flagged as Transient.

Attributes are assigned by implementing the IBAttribute Configurator Extension. See the chapter, Set Up Configurator Extensions, for details.

Flagging Transient Attributes

You flag attributes as transient in Oracle Configurator Developer. If node satisfies all of the following criteria, then the Transient checkbox is enabled.

Do not choose an Option Feature with a Maximum greater than 1. This will cause an error at runtime.

To mark an item as transient:

  1. In Main area of the Repository, edit the Model containing the Feature.

  2. Navigate to the Structure area of the Workbench.

  3. Edit the Feature.

  4. In the Details page for the Feature, select the Transient checkbox.

  5. Click Apply.

Assumptions and Restrictions

During the design and testing phases of your solution, you must ensure that the following issues do not cause problems.

Tangible Items

Physical BOM standard items (or Kits) in a container model that are shippable, inventory transactable, and serializable are called tangible items.

See "Specify Install Base Tracking" in the chapter "Set Up Oracle Inventory" for details on how to make an item tangible.

This functionality enables a sales representative to provide customers with the option to purchase shippable items (such as wireless handsets or Customer Premises Equipment (CPE)) while ordering services.

Oracle Configurator allows the end user to perform these actions related to tangible items:

In order to be a tangible item in a Container Model, an item must meet the following restrictions:

If a tangible item is discontinued then only the transaction relationship (which will have relationship type "Component-Of") corresponding to that item is discontinued. The discontinued shippable item remains in Oracle Install Base.

You can only add or delete tangible items from a configuration. You cannot change the state of tangible items relative to their state in Oracle Install Base.

When defining configuration Rules in Oracle Configurator Developer, Since a tangible item cannot have a quantity greater than 1, you cannot define a numeric rule in Oracle Configurator Developer that contributes to or consumes from the quantity of a tangible item.

Instance Locking for Trackable Items

It is possible for Oracle Install Base data to become corrupted if orders become stacked. In previous releases, a stacked order could occur when a trackable instance of an item was reconfigured before the fulfillment of the previous revision of the instance was complete. This situation could arise when the previous fulfillment failed or was still pending when the item was reconfigured and booked for fulfillment.

To prevent data corruption, Oracle Configurator locks instances until they are completely fulfilled, to ensure the integrity of their revision data. Specifically:

Using Configuration Rules

Oracle Quoting and Oracle Install Base end users typically need to reconfigure only a few Components within a network of connected Components. To facilitate this process and improve runtime performance, you can view only the following Components when an Oracle Configurator session begins:

When an end user reconfigures an installed configuration, Oracle Configurator may need to add Components to the configuration session to ensure the validity of all connections and the entire configuration. At runtime, only rules that you define using Connectors can propagate to Component instances that may not be visible in the configuration session. For this reason, it is important to define rules using Connectors when any rule participants are not part of the same trackable item. In other words, no parent-and-child or ancestor-and-descendant relationship exists between the trackable items. For more information on trackable items, see the section, "Structuring Container Models", above.

Note: If two trackable items are part of the same trackable item, it is not necessary to create a Connector between them in order to define a rule in which they are both participants. For example, Model A is a trackable BOM Model that has two children, Model B and Model C. Since Model A references these Models (thus they are Model A's children), you can use nodes from both Model B and Model C when defining rules.

When a rule defined using Connectors propagates to instances that are not visible in the configuration session, Oracle Configurator prompts you to add instances to the configuration session so other required changes are applied and the configuration remains valid.

For more information on using Connectors to define rules, see the Oracle Configurator Developer User's Guide.

Valid Configuration Rule Combinations

The following are examples of valid configuration rules for trackable Models within a Container Model.

Using the structure in the following figure as an example, you can create rules using nodes from Connector A and Connector B, even though their targets are the same. (You can also create rules using nodes from Connector A and Connector B if their targets are different.)

Connectors to the Same Trackable Model

the picture is described in the document text

Invalid Configuration Rule Combinations

If a configuration rule violates any of the requirements in this section, Oracle Configurator Developer displays an error when you generate logic.

The following are examples of invalid configuration rules for trackable Models within a Container Model.

Invalid Container Model Structure Examples

Example 1: A rule between a trackable Model and a non-trackable Model that is not one of the trackable Model's children.

Using the structure shown in the following figure, create a rule containing participants from Trackable1 and NonTrackable1. This rule is invalid and causes an error when you generate logic. This restriction does not apply to Configurator Extensions.

Container Model Structure

the picture is described in the document text

Example 2: A rule with participants from one trackable Model and any other node from a non-trackable child of the Container Model.

For example, in the structure appearing in the following figure, both PortSpeed and Speed are Features. A rule using PortSpeed and Speed is invalid because Port is trackable, PortSpeed is a Feature in Port, and Speed is a direct child of the Container Model.

Container Model Structure

the picture is described in the document text

Example 3: An invalid rule in a referenced Model.

In the structure appearing in the following figure, the Container Model contains a tangible item, and the referenced model RefModel_3 contains a numeric rule that contributes a quantity greater than 1 to the tangible item. The numeric rule is invalid, because a tangible item cannot have a quantity greater than 1. This invalid rule causes an error when you generate logic in RefModel_3, which contains the rule. However, this invalid rule does not cause an error when you generate logic in Container_Model, if the logic in the referenced model RefModel_3 is already up-to-date. You can force Oracle Configurator to generate and validate the logic of all referenced models, regardless of whether their logic is up-to-date, by setting the value of GenerateUpdatedOnly in the CZ_DB_SETTINGS table to NO.

See the Oracle Configurator Implementation Guide for background on viewing or editing the values in the CZ_DB_SETTINGS table.

Container Model Structure

the picture is described in the document text

Configurator Implementation in the Solution

This section contains information about implementing Oracle Configurator in the TSO solution.

Create Configuration Model

This section explains how to define a configuration Model specifically for an Oracle TSO solution. In the procedure below, you log in to Oracle Forms with Configurator Administrator responsibility and navigate to Populate/Refresh Configuration Models, Populate Configuration Models.

Steps

  1. Import the Container Model by running the Import Configuration Models concurrent program.

  2. After importing the Container Model, verify that its structure is valid by opening the Model for editing in Configurator Developer and choosing Generate Logic from the General area of the Workbench.

  3. Add the Model structure and define configuration rules. For transient items and attributes, set the transient flag.

  4. Generate a User Interface and optionally create Activate Instance UI controls on specific UI windows.

    Important: Oracle Configurator does not provide any User Interfaces in your installation. Since User Interfaces are based on specific model structure and configuration rules, you must generate your User Interfaces with Oracle Configurator Developer, or construct your own custom UIs.

    An Activate Instance UI control is a button or picture to which you assign the Activate Instance action.

    Customizing the User Interface consists of adding Activate buttons, creating Connection List buttons, hiding Configurator Extensions, and altering the format in the UI Editor.

    To help end users to navigate when updating an installed configuration, you may also want to display the Navigation Tree in a Container Model's User Interface.

    The Activate Instance UI control appears in a UI window only if you create the control on the selected Component's UI window. When you make the Oracle Configurator UI window editable, the Activate Instance control does not appear.

  5. Define Line Types in Oracle Order Management. In Oracle Order Management, Transaction Types are the source of various attributes on a sales order's header and lines. When you reconfigure an installed configuration, Oracle Configurator uses Line transaction types to describe the type of change made to each item.

  6. Use the following Configurator Extensions. These Configurator Extensions should be suitable without modification, but you may adapt them if necessary.

    • Line Type: Identifies the Line Type for use in the Summary window, and for use in downstream quoting and fulfillment activities. The Line Type column in the Summary window lists the type of change made to each item during the reconfiguration session.

    • Interactive Location Search: Sets the Location ID and Location Type Code for BOM trackable root instances and passes this information to downstream applications.

    • IBAttribute: Collects configuration attributes of configured Components.

    See the chapter, Set Up Configurator Extensions, for more information on these extensions.

  7. Publish the Container Model and specify the hosting applications that you want the Model available to (e.g., Oracle Install Base, Oracle Quoting, Oracle Order Management, or Oracle iStore) in the list of hosting applications. For a list of Oracle Applications short names, see the Oracle Configurator Implementation Guide. For information about publishing, see the Oracle Configurator Developer User's Guide.

Publish Container Model

To allow users of downstream applications to reconfigure installed configurations, you must include these applications when publishing the Model from Configurator Developer. Additionally, you must make the publication available to Oracle Order Management. For more information about publishing, see the Oracle Configurator Developer User's Guide.

Define Profile Options

You must define some profile options before uses of other applications can reconfigure installed configurations using Oracle Configurator. The following Oracle Configurator profile options affect how Oracle Configurator integrates with Oracle Install Base, or how Oracle Configurator saves data internally and returns it for use by the host application:

These profile options have default values, but you may want to modify them for your installation. For more information, see the Oracle Configurator Installation Guide.

You should also set certain profile options to disable pricing, as described in Disable Pricing.

You must also define some additional profile options to allow other applications to integrate with Oracle Configurator. For more information, refer to:

Disable Pricing

Pricing attributes sourced from Oracle Configurator output configuration attributes are not available to the pricing engine until you have exited the Configurator by clicking Done. Therefore, if you are sourcing pricing attributes from Oracle Configurator output configuration attributes, you should disable pricing display within the Configurator.

If your application that supports reconfigurations of installed configurations includes pricing that depends on the Line Type (action) or configuration attributes of the line item, then you should disable pricing. Since such a dependency is likely to be common, it is recommended that you disable pricing in Oracle Configurator if your application supports reconfigurations of installed configurations.

To disable pricing in Oracle Configurator, set the following profile options to the value No:

For more information on setting these profile options, see the Oracle Configurator Installation Guide.

Map Install Base Extended Attributes to Configuration Attributes

If you are using extended attributes with the TSO solution, you must map the following to each other for all trackable items:

The result of this mapping is that the values of configuration attributes produced during a session in Oracle Configurator remain associated with their trackable items in Oracle Install Base.

You may not need to map transient attributes to Install Base Extended Attributes. You should map them if they are needed during fulfillment. See the section, "Transient Attributes", above, for background.

In the following procedure, log in to Oracle Forms with Oracle Installed Base Admin responsibility and navigate to Setups, Extended Attribute Template.

Steps

  1. Define the desired extended attributes, associating them at the item group level. For information on defining Oracle Install Base attributes, see Create Extended Attributes in the chapter on setting up Oracle Install Base, and the Oracle Install Base Implementation Guide.

  2. In Oracle Configurator Developer, modify your Model to add attribute Features and Properties. The methodology for modifying your Model is described in Oracle Configurator Methodologies, in the section on implementing configuration attributes for output. Consult that chapter for guidance, with these essential differences:

    • Instead of descriptive flexfield segments and contexts, use Oracle Install Base extended attributes and groups.

    • In place of the Property names, ATTR_CONTEXT and ATTR_n_CONTEXT, use ATTR_GROUP and ATTR_n_GROUP.

Example:

In Oracle Install Base, define an extended attribute at the Inventory Item group access level with:

Note: The Attribute Name must be unique, for extended attributes used in the TSO flow.

In Configurator Developer, in a trackable BOM Model, define an attribute Feature with:

For the Feature named Port_Speed, define a Property with:

For the trackable BOM Model, define a Property with:

For the trackable BOM Model, define a second Property with:

For the trackable BOM Model, define a third Property with:

Oracle Configurator Schema Customizations

For your enhanced understanding of the TSO solution, this section describes some ways in which the Oracle Configurator (CZ) schema is adapted for TSO.

DISPLAY_SUMMARY_FULFILLMENT_ACTION Parameter

Using the DISPLAY_SUMMARY_FULFILLMENT_ACTION parameter, you can control whether the Line Type column appears in the Oracle Configurator Summary window during a reconfiguration session. Following are the settings of this parameter in the CZ_DB_SETTINGS table:

Note: This parameter affects only reconfiguration scenarios, not new configurations. In a new configuration, the Line Type column never appears.

If the parameter is True or is not defined, then the Line Type column appears in the Summary window, if a reconfiguration. If set to False, the Line Type column does not appear.

More information on Line Types can be found in the chapter, Set Up Configurator Extensions.

See the Oracle Configurator Implementation Guide for background on viewing or editing the values in the CZ_DB_SETTINGS table.

CZ_CONFIG_EXT_ATTRIBUTES Table

The table, CZ_CONFIG_EXT_ATTRIBUTES, is the intermediate store of configuration attribute data between Oracle Configurator and Oracle Install Base. Oracle Configurator writes output data to the table when the IBAttribute Configurator Extension runs. Oracle Configurator compares the attribute values written to CZ_CONFIG_EXT_ATTRIBUTES with the values of the corresponding columns in the Oracle Install Base tables.

For more information about this Configurator Extension, see the chapter, Set Up Configurator Extensions.

The following table shows the layout and description of the CZ_CONFIG_EXT_ATTRIBUTES table.

CZ_CONFIG_EXT_ATTRIBUTES
Column Name Null? PK? Type Comments
CONFIG_HDR_ID N Y NUMBER Instance Header ID. Corresponds to CZ_CONFIG_ITEMS.INSTANCE_HDR_ID.
CONFIG_REV_NBR N Y NUMBER Instance Revision Number. Corresponds to CZ_CONFIG_ITEMS.INSTANCE_REV_NBR.
CONFIG_ITEM_ID N Y NUMBER Configuration Item ID. Corresponds to CZ_CONFIG_ITEMS.CONFIG_ITEM_ID.
ATTRIBUTE_LEVEL N Y VARCHAR2(255) Corresponds to CSI_I_EXTENDED_ATTRIBS.ATTRIBUTE_LEVEL.
ATTRIBUTE_NAME N Y VARCHAR2(255) Corresponds to CSI_I_EXTENDED_ATTRIBS.ATTRIBUTE_CODE.
ATTRIBUTE_GROUP Y N VARCHAR2(255) Corresponds to CSI_I_EXTENDED_ATTRIBS.ATTRIBUTE_GROUP.
ATTRIBUTE_VALUE Y N VARCHAR2(255) Corresponds to CSI_I_EXTENDED_ATTRIBS.ATTRIBUTE_VALUE.
SEQUENCE_NBR Y N NUMBER Sequence number for operations.

The columns, CONFIG_HDR_ID, CONFIG_REV_NBR, CONFIG_ITEM_ID, ATTRIBUTE_LEVEL, and ATTRIBUTE_NAME, are the primary key for CZ_CONFIG_EXT_ATTRIBUTES.

The column SEQUENCE_NBR indicates a global sequence number for a batch validation session’s processing of configuration operations and extended attributes. This sequence number is used only during the batch validation of pseudo-configurations, such as when an item is validated by Oracle Contact Center. For more details, see the section, "Batch Validation Parameters"

For brevity, the preceding table does not include standard columns such as LAST_UPDATE_DATE.

Mapping of Configurator Tables to Install Base Schema

When adding trackable data, the system adds the item into the Oracle Install Base table, CSI_T_TXN_LINE_DETAILS. If change occurs to a transaction value after a reconfiguration, then a comparison happens between CSI_T_TXN_LINE_DETAILS and CZ_CONFIG_ITEMS to report the change. The CSI_T_TRANSACTION_LINES table contains the transaction detail for the configured item. There is one transaction line for each source transaction.

The following table shows the mapping of the Oracle Configurator (CZ) tables to the Oracle Install Base (IB) schema.

Mapping of CZ Tables to CSI Tables
CZ_TABLE.COLUMN CSI_TABLE.COLUMN Description
CZ_CONFIG_ITEMS.INSTANCE_HDR_ID CSI_T_TXN_LINE_DETAILS.CONFIG_HDR_ID Each configured Component has its own unique instance header identification. The CONFIG_HDR_ID populates the INSTANCE_HDR_ID from the CZ_CONFIG_ITEMS table.
CZ_CONFIG_ITEMS.INSTANCE_REV_NBR CSI_T_TXN_LINE_DETAILS.CONFIG_REV_NBR Each configured Component has its own unique instance revision number. The CONFIG_REV_NBR populates the INSTANCE_REV_NBR from the CZ_CONFIG_ITEMS table.
CZ_CONFIG_ITEMS.CONFIG_ITEM_ID CSI_T_TXN_LINE_DETAILS.CONFIG_ITEM_ID This is the unique identifier for the configured item.
CZ_CONFIG_ITEMS.TARGET_HDR_ID CSI_T_II_RELATIONSHIPS.OBJ_CONFIG_INST_HDR_ID This field is populated only for Connectors that point to the target.
CZ_CONFIG_ITEMS.TARGET_REV_NBR CSI_T_II_RELATIONSHIPS.OBJ_CONFIG_REV_NBR This field is populated only for Connectors that point to the target.
CZ_CONFIG_ITEMS.TARGET_ITEM_ID CSI_T_II_RELATIONSHIPS.OBJ_CONFIG_ITEM_ID This field is populated only for Connectors that point to the target.
CZ_CONFIG_ITEMS.CONFIG_ITEM_ID CSI_T_TRANSACTION_LINES.SOURCE_TRANSACTION_ID This is the ID of the item being configured.
CZ_CONFIG_ITEMS.UOM_CODE CSI_T_TXN_LINE_DETAILS.UNIT_OF_MEASURE This is the units of measurement code.
CZ_CONFIG_ITEMS.LOCATION_ID CSI_T_TXN_LINE_DETAILS.LOCATION_ID This is the Location ID for the item.
CZ_CONFIG_ITEMS.LOCATION_TYPE_ID CSI_T_TXN_LINE_DETAILS.LOCATION_TYPE_CODE This is the Location Type Code for the item.
CZ_CONFIG_HDRS_V.BASELINE_REV_NBR CSI_ITEM_INSTANCES.CONFIG_INST_REV_NUM
CSI_T_TXN_LINE_DETAILS.CONFIG_INST_BASELINE_REV_NUM		 CZ_CONFIG_HDRS_V.BASELINE_REV_NBR is a reference to CSI_ITEM_INSTANCES.CONFIG_INST_REV_NUM, which is the existing instance revision in Install Base that is being reconfigured. When Oracle Configurator writes transactions for a reconfiguration, it inserts this number in both CZ_CONFIG_HDRS_V.BASELINE_REV_NBR and CSI_T_TXN_LINE_DETAILS.CONFIG_INST_BASELINE_REV_NUM.
CZ_CONFIG_EXT_ATTRIBUTES.ATTRIBUTE_NAME CSI_T_EXTEND_ATTRIBS_V.ATTRIBUTE_CODE The name of the extended attribute for the item. .
CZ_CONFIG_EXT_ATTRIBUTES.ATTRIBUTE_VALUE CSI_T_EXTEND_ATTRIBS_V.ATTRIBUTE_VALUE The value of the extended attribute for the item. .

Link Items Column

The column, IB_LINK_ITEM_FLAG, indicates whether a node is a link item. This column is part of the tables, CZ_PS_NODES and CZ_IMP_PS_NODES. A true value for this column means that the node is a link item. This data is regarded as the link flag. For more information on links, see the chapter, Set Up Inventory and Network Link Items.

See the chapter, Configurator Extensions, for information on how the CIO uses the link flag.

For table details, see the CZ eTRM on MetaLink, Oracle's technical support Web site.

Transient Items Column

The column, TRANSIENT_FLAG, indicates whether a node is a transient item. This column is part of the table, CZ_PS_NODES. A true value for this column means that the node is a transient item. This data is regarded as the transient flag.

For table details, see the CZ eTRM on MetaLink, Oracle's technical support Web site.

Tangible Items Columns

The columns SHIPPABLE_ITEM_FLAG, INVENTORY_TRANSACTABLE_FLAG, SERIALIZABLE_ITEM_FLAG, and ASSEMBLE_TO_ORDER_FLAG indicate whether a node is a tangible item. These columns are part of the tables CZ_PS_NODES and CZ_IMP_PS_NODES.

The columns TANGIBLE_ITEM_FLAG and RETURNED_FLAG indicate whether a node is a tangible item that has been returned. These columns are part of the table CZ_CONFIG_ITEMS.

For table details, see the CZ eTRM on MetaLink, Oracle's technical support Web site.

Initialization Parameters

This section describes parameters that are specific to the TSO solution.

For information on the use of parameters in the initialization message, see the Oracle Configurator Implementation Guide.

When configuring instances of trackable Components prior to their installation in Oracle Install Base, the system uses the following parameters:

For background on updating configuration instances, see the chapter, Oracle TSO Business Process.

instance

The system uses the instance parameter when configuring instances of trackable Components. This parameter lets you configure multiple instances in the same configuration session. In a host application, this corresponds to the end user's ability to select multiple Components for configuration.

This is the only initialization parameter that can be specified multiple times in the initialization message.

In order to specify each instance that requires configuration, provide the Configuration Header ID (CZ_CONFIG_DETAILS_V.CONFIG_HDR_ID) as the value of the header_id sub-parameter. For example:

<instance header_id="17848"/>
<instance header_id="18333"/>
<instance header_id="23445"/>

validation_context

The system uses the validation_context parameter when configuring instances of trackable configuration Components. The value sets the context in which the following occur:

Batch validation uses the validation_context parameter. For more information, see the section, Batch Validation Parameters.

The only allowed value for the validation_context parameter is INSTALLED. This value compares the revisions of the current instances only to the revisions of those instances that have been installed in Oracle Install Base.

Batch Validation Parameters

For background and details about batch validation, see the Oracle Configurator Implementation Guide.

TSO implementers must use one of the following optional values for the p_validation_type parameter to the CZ_CF_API.VALIDATE procedure. (For details on the VALIDATE procedure used by batch validation, see VALIDATE Procedure.)

Values are:

Example

<batch_validate validation_type="validate_order">

Programmatic Tools for TSO Instance Management

You can use certain programmatic tools to help manage TSO instance configurations. This section describes the following tools or procedures modified for use with the TSO solution:

For full background and details about these programmatic tools for development, see the Oracle Configurator Implementation Guide.

The versions of these procedures described in this section are adapted to operate on configurations that have connectivity, as well as on those that do not.

These procedures use the custom data type, CZ_API_PUB.NUMBER_TBL_TYPE, which is a table of number type. For background on custom data types, see the appropriate references in the Oracle Configurator Implementation Guide and in Custom Data Types in the Package CZ_CF_API.

COPY_CONFIGURATION Procedure

This procedure, COPY_CONFIGURATION in the CZ_CONFIG_API_PUB package, makes a copy of a saved configuration in the Oracle Configurator schema.

This procedure, created for use with the TSO solution, is a variation of COPY_CONFIGURATION in the CZ_CF_API package. For a description of the CZ_CF_API package, see the Oracle Configurator Implementation Guide. The most important difference is that this TSO procedure has two additional OUT parameters: x_orig_item_id_tbl and x_new_item_id_tbl. These parameters inform host applications about changes to the Configuration Item IDs (CZ_CONFIG_ITEMS.CONFIG_ITEM_ID) in the configuration in a case where you are copying Component instances that are not yet installed in Oracle Install Base. These parameters are of type CZ_API_PUB.NUMBER_TBL_TYPE, which is a table of the NUMBER type. As used by the COPY_CONFIGURATION procedure, these output tables are indexed from 1 to n, where n is the number of Configuration Item IDs changed from the source configuration to the new configuration. You can use the index number of the IDs stored in the tables to map the Configuration Item IDs in the original configuration to the Configuration Item IDs in the new copy of that configuration. The following example shows how a host application might process these outputs using Oracle Configurator.

Example: Mapping Original Configuration Item IDs to New IDs When Copying a Configuration

...
FORALL i IN x_orig_item_id_tbl.FIRST..x_orig_item_id_tbl.LAST 
  UPDATE my_order_lines 
  SET config_item_id = x_new_item_id_tbl(i) 
  WHERE my_order_header = l_header 
    AND config_hdr_id = x_config_hdr_id 
    AND config_rev_nbr = x_config_rev_nbr 
    AND config_item_id = x_orig_item_id_tbl(i); 
...

The non-TSO version of COPY_CONFIGURATION, in the package CZ_CF_API, has been modified to create an exception if it generates any new Configuration Item IDs. This averts data corruption in Oracle Order Management, Order Capture, and Order Contracts. If you encounter this exception, you must apply the appropriate patch for your host application that invokes the new COPY_CONFIGURATION procedure from CZ_CONFIG_API_PUB.

For background on configurations, see the chapter on managing configurations in the Oracle Configurator Implementation Guide.

Considerations Before Running

Keep the following considerations in mind when running COPY_CONFIGURATION.

Prerequisites

The configuration that you are copying must exist. If the configuration has been logically deleted, then you can pass 0 as the value of p_handle_deleted_flag to enable copying.

Timing

You should use this procedure every time you copy a configuration. The procedure ensures copying of all inputs, outputs, attributes, and messages.

Warnings

If the configuration does not exist, or if the copy fails, x_msg_count will be greater than zero, and x_msg_data will contain error information. Check x_return_status for the return status.

Syntax and Parameters

The syntax for this procedure is:

PROCEDURE copy_configuration(p_api_version IN  NUMBER 
    ,p_config_hdr_id        IN  NUMBER 
    ,p_config_rev_nbr       IN  NUMBER 
    ,p_copy_mode            IN  VARCHAR2 
    ,x_config_hdr_id        OUT NOCOPY  NUMBER 
    ,x_config_rev_nbr       OUT NOCOPY  NUMBER 
    ,x_orig_item_id_tbl     OUT NOCOPY  CZ_API_PUB.number_tbl_type 
    ,x_new_item_id_tbl      OUT NOCOPY  CZ_API_PUB.number_tbl_type 
    ,x_return_status        OUT NOCOPY  VARCHAR2 
    ,x_msg_count            OUT NOCOPY  NUMBER 
    ,x_msg_data             OUT NOCOPY  VARCHAR2 
    ,p_handle_deleted_flag  IN  VARCHAR2 := NULL 
    ,p_new_name             IN  VARCHAR2 := NULL 
);

The following table describes the parameters for the COPY_CONFIGURATION procedure.

Parameters for the COPY_CONFIGURATION Procedure
Parameter Data Type Mode Note
p_api_version number in Required. See the description of API Version Numbers in the Oracle Configurator Implementation Guide.
p_config_hdr_id number in Required. Specifies the Configuration Header ID of the source configuration to copy.
p_config_rev_nbr number in Required. Specifies the Configuration Revision Number of the source configuration to copy.
p_copy_mode varchar2 in Required. Flag that specifies whether creating a new Configuration Header ID or new Configuration Revision Number has one of the following values:

  • CZ_API_PUB.G_NEW_HEADER_COPY_MODE, which creates a new Configuration Header ID. Used in the case of reordering. Equivalent to the value new_config for the initialization parameter save_config_behavior.

  • CZ_API_PUB.G_NEW_REVISION_COPY_MODE, which creates a new Configuration Revision Number. Used in the case of reconfiguring or repricing. Equivalent to the value new_revision for the initialization parameter save_config_behavior.
x_config_hdr_id number out Identifies the Configuration Header ID of the new copy of the source configuration.
x_config_rev_nbr number out Identifies the Configuration Revision Number of the new copy of the source configuration.
x_orig_item_id_tbl CZ_API_PUB.number_tbl_type out Indexed table of Configuration Item IDs from the source configuration that were changed when being copied to the new configuration. Empty if the configuration does not contain trackable instances.
x_new_item_id_tbl CZ_API_PUB.number_tbl_type out Indexed table of Configuration Item IDs from the new copy of the source configuration that were changed when being copied from the source configuration. Empty if the configuration does not contain trackable instances.
x_return_status varchar2 out Standard out parameter. Value is: FND_API.G_RET_STS_SUCCESS, FND_API.G_RET_STS_ERROR, or FND_API.G_RET_STS_UNEXP_ERROR.
x_msg_count number out Standard out parameter.
x_msg_data varchar2 out Standard out parameter.
p_handle_deleted_flag varchar2 in Specifies how to handle an attempt to copy a logically deleted source configuration. If the source configuration is logically deleted, and the value passed to this parameter is 0, then the source configuration is undeleted so that the copy can proceed. If the value passed is null, then an error is raised by the attempt to copy.
p_new_name varchar2 in The new name applied to the copied configuration.

Considerations After Running

Keep the following considerations in mind after running COPY_CONFIGURATION.

Results

This procedure copies all database records associated with a configuration to a new Configuration Header ID and Configuration Revision Number. The changes that the procedure made are not automatically committed. When you call this procedure, you must check x_return_status and commit the transaction if the copy was successful.

Troubleshooting

Examine x_return_status. If it does not indicate success, then examine x_msg_count for the number of error messages, and x_msg_data for the error messages themselves.

COPY_CONFIGURATION_AUTO Procedure

This procedure runs COPY_CONFIGURATION within an autonomous transaction. If the copy is successful, new data will be committed to the database without impacting the caller's transaction.

VALIDATE Procedure

This section describes a new parameter signature for the VALIDATE procedure in the CZ_CF_API package. For a description of the previous signature for the VALIDATE procedure, see the Oracle Configurator Implementation Guide. Existing calls to the previous signature will continue to operate correctly, and do not need to be changed.

For TSO, you must call this procedure with the parameter, p_validation_type. When Oracle Configurator calls this procedure during batch validation, it uses the following values for that parameter:

Syntax and Parameters

The syntax for this procedure is:

procedure validate(p_api_version         IN  NUMBER
                  ,p_config_item_tbl     IN  config_item_tbl_type
                  ,p_config_ext_attr_tbl IN  config_ext_attr_tbl_type
                  ,p_url                 IN  VARCHAR2
                  ,p_init_msg            IN  VARCHAR2
                  ,p_validation_type     IN  VARCHAR2
                  ,x_config_xml_msg  OUT NOCOPY CFG_OUTPUT_PIECES
                  ,x_return_status   OUT NOCOPY VARCHAR2
                  ,x_msg_count       OUT NOCOPY NUMBER
                  ,x_msg_data        OUT NOCOPY VARCHAR2
                  );

The following table describes the parameters for the new parameter signature of the VALIDATE procedure. Several parameters are new, as indicated. Parameters retained from the previous signature are described in more detail in the Oracle Configurator Implementation Guide

The parameter p_validation_type has special meaning for the TSO solution, as noted elsewhere.

Parameters for the VALIDATE Procedure
Parameter Data Type Mode Note
p_api_version number in Required. See the description of API Version Numbers in the Oracle Configurator Implementation Guide.
p_config_item_tbl
(new)		 config_item_tbl_type
(new)
See Custom Data Types in the Package CZ_CF_API		 in List of input selections. Can be null if only updating attributes. Individual field can be null, FND_API.G_MISS_NUM or FND_API.G_MISS_CHAR, or another value
p_config_ext_attr_tbl
(new)		 config_ext_attr_tbl_type
(new)
See Custom Data Types in the Package CZ_CF_API		 in List of extended attributes to be updated.
p_url varchar2 in The URL of the Oracle Configurator Servlet. If null, the value of the profile option CZ_UIMGR_URL is used.
Same as previous parameter url
p_init_msg varchar2(2000) in The XML initialization message for Oracle Configurator. Cannot be null.
Same as previous parameter init_message
p_validation_type varchar2 in Validation type. The possible values are CZ_API_PUB.VALIDATE_ORDER, CZ_API_PUB.VALIDATE_FULFILLMENT, and CZ_API_PUB.INTERACTIVE. The default is CZ_API_PUB.VALIDATE_ORDER.
x_config_xml_msg CFG_OUTPUT_PIECES out nocopy A table of the output XML messages produced by validating the configuration.
Same as previous parameter config_messages
x_return_status
(new)		 varchar2 out nocopy Standard out parameter. Value is: FND_API.G_RET_STS_SUCCESS, FND_API.G_RET_STS_ERROR, or FND_API.G_RET_STS_UNEXP_ERROR.
x_msg_count
(new)		 number out nocopy Standard out parameter. Number of log messages.
x_msg_data
(new)		 varchar2 out nocopy Standard out parameter. If x_msg_count equals 1, contains message.

This version of the VALIDATE procedure uses standard Oracle Applications (FND) logging. If logging is enabled, the following information will be written into the log:

Some parameters of the VALIDATE procedure use custom data types. These are described in Custom Data Types in the Package CZ_CF_API. For background, see the section on Custom Data Types in the Oracle Configurator Implementation Guide.

Custom Data Types in the Package CZ_CF_API
Custom Type Description
config_item_tbl_type Table of config_item_rec_type, indexed by BINARY_INTEGER
config_ext_attr_tbl_type Table of config_ext_attr_rec_type, indexed by BINARY_INTEGER
config_item_rec_type Record consisting of: 
config_item_id      cz_config_items.config_item_id%TYPE
component_code      cz_config_items.node_identifier%TYPE
sequence_nbr        cz_config_items.sequence_nbr%TYPE
operation           NUMBER
quantity            cz_config_items.item_num_val%TYPE
instance_name       cz_config_items.name%TYPE
location_id         cz_config_items.location_id%TYPE
location_type_code  cz_config_items.location_type_code%TYPE
config_ext_attr_rec_type Record consisting of: 
config_item_id      cz_config_ext_attributes.config_item_id%TYPE
component_code      VARCHAR2(1200)
sequence_nbr        NUMBER
attribute_name      cz_config_ext_attributes.attribute_name%TYPE
attribute_group     cz_config_ext_attributes.attribute_group%TYPE
attribute_value     cz_config_ext_attributes.attribute_value%TYPE
Constants 
BV_OPERATION_UPDATE  CONSTANT  NUMBER := 1;
BV_OPERATION_DELETE  CONSTANT  NUMBER := 2;

For an example of how you might call the VALIDATE procedure, see Calling the VALIDATE Procedure. This example is not ready to run as shown. You must replace some of the placeholder values in it to fit your own implementation.

Calling the VALIDATE Procedure

-- sample_bvapicall.sql
set serveroutput on;
DECLARE
  l_config_item_rec CZ_CF_API.config_item_rec_type;
  l_config_item_tbl CZ_CF_API.config_item_tbl_type;
  l_config_attr_rec  CZ_CF_API.config_ext_attr_rec_type;
  l_config_attr_tbl  CZ_CF_API.config_ext_attr_tbl_type;
  l_url              VARCHAR2(100);
  l_init_msg         VARCHAR2(2000);
  l_validation_type  VARCHAR2(1) := CZ_API_PUB.VALIDATE_ORDER;
  l_config_xml_msg   CZ_CF_API.CFG_OUTPUT_PIECES;
  l_return_status    VARCHAR2(1);
  l_msg_count        NUMBER;
  l_msg_data         VARCHAR2(1000);

  l_user_id number := 1111; -- your user id
  l_resp_id number := 2222; -- responsibility id
  l_appl_id number := 3333; -- application id

BEGIN
  l_url := 'http://www.mysite.com:myportnumber/configurator/oracle.apps.cz.servlet.UiServlet';
  l_init_msg := 
    '<initialize>'
      || '<param name="database_id">mydbhost_mydbname</param>'
      || '<param name="responsibility_id">2222</param>'
      || '<param name="calling_application_id">3333</param>'
      || '<param name="context_org_id">4444</param>'
      || '<param name="model_id">5555</param>'
      || '<param name="config_creation_date">'||to_char(sysdate)||'</param>'
      || '<param name="config_header_id">6666</param>'
      || '<param name="config_rev_nbr">1</param>'
      || '<param name="save_config_behavior">new_revision</param>'
      || '<param name="read_only">FALSE</param>'
      || '<param name="terminate_msg_behavior">brief</param>' ||
    '</initialize>';
  
  -- update instance name
  l_config_item_rec.config_item_id := 1000;
  l_config_item_rec.component_code := '123-456';
  l_config_item_rec.operation := CZ_CF_API.bv_operation_update;
  l_config_item_rec.sequence_nbr := 1;
  l_config_item_rec.instance_name := 'new instance name';
  l_config_item_tbl(l_config_item_tbl.count+1) := l_config_item_rec;

  -- clear out location_id and location_type_code
  l_config_item_rec := null;
  l_config_item_rec.config_item_id := 1011;
  l_config_item_rec.component_code := '123-456-789';
  l_config_item_rec.operation := CZ_CF_API.bv_operation_update;
  l_config_item_rec.sequence_nbr := 3;
  l_config_item_rec.location_id := fnd_api.G_MISS_NUM;
  l_config_item_rec.location_type_code := fnd_api.G_MISS_NUM;
  l_config_item_tbl(l_config_item_tbl.count+1) := l_config_item_rec;
  
  -- delete an instance
  l_config_item_rec := null;
  l_config_item_rec.config_item_id := 1001;
  l_config_item_rec.component_code := '123-456';
  l_config_item_rec.operation := CZ_CF_API.bv_operation_delete;  
  l_config_item_rec.sequence_nbr := 4;
  l_config_item_tbl(l_config_item_tbl.count+1) := l_config_item_rec;

  l_config_attr_rec.config_item_id := 1010;
  l_config_attr_rec.component_code := '123-456-678';
  l_config_attr_rec.sequence_nbr := 2;
  l_config_attr_rec.attribute_name := 'an attr name';
  l_config_attr_rec.attribute_group := 'an attr group';
  l_config_attr_rec.attribute_value := 'a new attr value';
  l_config_attr_tbl(l_config_attr_tbl.count+1) := l_config_attr_rec;

  fnd_global.apps_initialize(1111,2222,3333);
  CZ_CF_API.VALIDATE(1.0
                    ,l_config_item_tbl
                    ,l_config_attr_tbl
                    ,l_url
                    ,l_init_msg
                    ,l_validation_type
                    ,l_config_xml_msg
                    ,l_return_status
                    ,l_msg_count
                    ,l_msg_data
                    );

  dbms_output.put_line('Return status: ' || l_return_status);
  if l_return_status = fnd_api.G_RET_STS_SUCCESS then
    -- parse xml output msg
  else
    dbms_output.put_line('message count: ' || l_msg_count);
    if  l_msg_count = 1 then
      dbms_output.put_line('message: ' || l_msg_data);
    else
      for i in 1 .. l_msg_count loop
        dbms_output.put_line('message ' || i || ': '
                     || fnd_msg_pub.get(i,fnd_api.g_false));
      end loop;
    end if;
  end if;
exception
  when others then
    dbms_output.put_line('Unexpected err: ' || SQLERRM);
end;
/