oracle configuratordownload.oracle.com/appsnet/115czimpg.pdforacle configurator implementation guide...

Oracle Configurator

Implementation Guide

Release 11i

January 2001

Part No. A87531-01

The tasks presented here are required to set up and support developers and users of run-time Oracle Configurators.

iii

Contents

List of FiguresList of Tables

Send Us Your Comments ................................................................................................................... xi

Preface........................................................................................................................................................... xiii

Intended Audience ............................................................................................................................... xiiiStructure................................................................................................................................................. xiiiRelated Documents.............................................................................................................................. xivConventions........................................................................................................................................... xvProduct Support.................................................................................................................................... xv

1 Introduction

1.1 Run-time Oracle Configurators........................................................................................... 1–11.2 Oracle Configurator Schema................................................................................................ 1–21.3 Overview of Oracle Configurator Implementation.......................................................... 1–21.3.1 Concurrent Programs .................................................................................................... 1–31.4 Terms....................................................................................................................................... 1–41.5 Requirements ......................................................................................................................... 1–51.6 Oracle Configurator Environments .................................................................................... 1–51.6.1 Development................................................................................................................... 1–61.6.2 Testing.............................................................................................................................. 1–81.6.3 Production....................................................................................................................... 1–81.6.4 Maintenance.................................................................................................................... 1–91.7 Oracle Configurator Architecture Overview ................................................................. 1–101.8 Implementation Tasks ....................................................................................................... 1–11

iv

1.8.1 Commonly Performed Implementation Tasks ....................................................... 1–121.8.1.1 Server Administration ........................................................................................ 1–121.8.1.2 View the Status of Oracle Configurator Concurrent Process Requests ....... 1–161.8.1.3 Query Registered Oracle Configurator Concurrent Programs ..................... 1–181.8.1.4 Connect to a Database Instance.......................................................................... 1–211.8.1.5 Verify Oracle Configurator Schema Version ................................................... 1–21

2 The Spx.ini File

2.0.1 Parameters in spx.ini..................................................................................................... 2–22.0.1.1 [Merlin] .................................................................................................................... 2–32.0.1.2 [DSN] ....................................................................................................................... 2–32.0.1.3 [dsn].......................................................................................................................... 2–42.0.1.4 [Design Chart]......................................................................................................... 2–52.0.1.5 [Test]......................................................................................................................... 2–6

3 The Oracle Configurator Schema

3.1 Characteristics of the Oracle Configurator Schema......................................................... 3–13.1.1 CF Configuration........................................................................................................... 3–23.1.2 GN General Use Tables ................................................................................................ 3–23.1.3 IM Item-Master .............................................................................................................. 3–23.1.4 LC Logic for Configuration (Active Model) .............................................................. 3–23.1.5 PB Publication................................................................................................................ 3–33.1.6 PS Project Structure....................................................................................................... 3–33.1.7 RP Repository ................................................................................................................ 3–33.1.8 UI User Interface (Active UI) ....................................................................................... 3–43.1.9 XF Transfer Specifications and Control ..................................................................... 3–43.2 Oracle Configurator Schema Settings................................................................................ 3–43.2.1 CZ_DB_SETTINGS for SCHEMA............................................................................... 3–73.2.2 CZ_DB_SETTINGS for ORAAPPS_INTEGRATE .................................................... 3–83.2.3 CZ_DB_Settings for IMPORT...................................................................................... 3–93.3 Editing the CZ_DB_SETTINGS Values .......................................................................... 3–103.3.1 Modify Configurator Parameters.............................................................................. 3–113.3.2 View Configurator Parameters.................................................................................. 3–123.4 Oracle Configurator Schema Maintenance..................................................................... 3–123.4.1 Refresh or Update the Production Schema ............................................................. 3–12

v

3.4.2 PURGE.......................................................................................................................... 3–133.4.3 Redo Sequences ........................................................................................................... 3–13

4 Importing Data

4.1 Data Import Overview.......................................................................................................... 4–14.1.1 Import Tables.................................................................................................................. 4–34.1.1.1 Import Control Fields ............................................................................................. 4–34.1.1.2 Online Data Fields .................................................................................................. 4–44.1.1.3 Surrogate Key Fields............................................................................................... 4–44.1.2 Control Tables (CZ_XFR_)............................................................................................ 4–54.2 The Import Process................................................................................................................ 4–94.3 Data Imported into the Oracle Configurator Schema................................................... 4–104.4 Data Import Setup .............................................................................................................. 4–114.5 Importing Data From Oracle Applications..................................................................... 4–124.6 Data Import Concurrent Processes ................................................................................. 4–124.6.1 Importing from Oracle Bills of Material .................................................................. 4–134.6.1.1 Enabling a Server for Import.............................................................................. 4–144.6.1.2 Exploding BOMs in Oracle Applications ......................................................... 4–144.6.1.3 Running the Import Concurrent Process.......................................................... 4–154.7 Verify Data Import ............................................................................................................. 4–164.8 Refresh and Update Imported Data ................................................................................ 4–164.8.1 Enable or Disable Refresh .......................................................................................... 4–194.8.2 Refresh a Single Configuration Model..................................................................... 4–194.8.3 Refresh All Imported Configuration Models.......................................................... 4–204.9 Re-importing/Refreshing BOM Models with Component Models............................ 4–204.9.1 Scenarios for Re-importing/Refreshing BOM Models with Component Models.........

4–204.9.1.1 Scenario 1 - Initial Import of BOM Model........................................................ 4–214.9.1.2 Scenario 2 - Re-Import/Refresh of Initial BOM Model .................................. 4–214.9.1.3 Scenario 3 - Import New BOM Model with References to Existing BOM Models.

4–224.10 Customizing Data Import ................................................................................................ 4–234.10.1 Importing Specific Tables........................................................................................... 4–244.10.2 Importing Specific Fields of CZ_XFR_TABLES...................................................... 4–254.10.3 Modifying CZ_XFR_PROJECT_BILLS.EXPLOSION_TYPE................................. 4–25

vi

4.10.4 Creating a Custom Import ......................................................................................... 4–254.10.4.1 Setup for a Custom Import ................................................................................. 4–264.10.4.2 Extraction Setup for a Custom Import .............................................................. 4–274.10.4.3 Required ASCII File Format for Custom Import ............................................. 4–284.10.4.4 Running a Custom Import.................................................................................. 4–29

5 Pricing in Oracle Configurator

5.1 Pricing in a Run-time Oracle Configurator....................................................................... 5–15.1.1 Pricing Interaction in the User Interfaces .................................................................. 5–25.1.1.1 Pricing Interaction in the Java Applet User Interface ....................................... 5–25.1.1.2 Pricing Interaction in the DHTML User Interface............................................. 5–25.1.2 General Pricing Behavior ............................................................................................. 5–35.2 Run-time Oracle Configurator Pricing Architecture....................................................... 5–35.3 Controlling Pricing in the Run-time Oracle Configurator.............................................. 5–55.3.1 Displaying Price Types................................................................................................. 5–65.3.1.1 Setting the OC Servlet Property for Price Types ............................................... 5–65.3.1.2 Setting the Item Price Display in Oracle Configurator Developer ................. 5–75.3.2 Updating Price Data...................................................................................................... 5–85.3.2.1 Setting the OC Servlet Property for Price Updating ......................................... 5–85.3.2.2 Setting the Price Update in Oracle Configurator Developer ........................... 5–85.3.3 Examples of Controlling Pricing ................................................................................. 5–95.3.3.1 Example: List Prices Only ..................................................................................... 5–95.3.3.2 Example: Selling Prices Only................................................................................ 5–9

6 Publishing Configuration Models

6.1 Overview of Publishing Configuration Models............................................................... 6–16.1.1 Planning Publications ................................................................................................... 6–16.1.2 The Publication Process................................................................................................ 6–26.2 Defining the Publication...................................................................................................... 6–36.2.1 Publication Attributes................................................................................................... 6–36.2.1.1 Product..................................................................................................................... 6–46.2.1.2 Model ...................................................................................................................... 6–46.2.1.3 Database Instance................................................................................................... 6–56.2.1.4 User Interface.......................................................................................................... 6–56.2.2 Publication Applicability Parameters......................................................................... 6–5

vii

6.2.2.1 Publication Mode .................................................................................................... 6–56.2.2.2 Application .............................................................................................................. 6–66.2.2.3 Date Range ............................................................................................................... 6–66.2.2.4 Usages....................................................................................................................... 6–76.3 Creating the Publication....................................................................................................... 6–96.3.1 Publishing a Single Pending Configuration Model ................................................. 6–96.3.2 Publishing All Pending Configuration Models ..................................................... 6–106.4 Tables Used in Publishing................................................................................................. 6–106.5 Profile Options Used in Publishing ................................................................................. 6–116.5.1 Setting Profile Options ............................................................................................... 6–116.6 Publishing and Effectivity................................................................................................. 6–126.7 Publishing and Referencing.............................................................................................. 6–126.8 Updating or Republishing Publications.......................................................................... 6–126.9 Editing Publications ........................................................................................................... 6–136.10 Disabling, Deleting, and Re-enabling Publications....................................................... 6–136.11 Lost Publications Due to Instance Failure ...................................................................... 6–136.11.1 Failed Target Database ............................................................................................... 6–146.11.2 Failed Source Database............................................................................................... 6–14

7 Deploying Oracle Configurator

7.1 Calling an Embedded Oracle Configurator ...................................................................... 7–17.1.1 Java Applet Requirements ............................................................................................ 7–27.1.2 DHTML Requirements.................................................................................................. 7–27.2 Deployment Strategies.......................................................................................................... 7–37.2.1 Architectural Considerations ....................................................................................... 7–37.2.2 Server Considerations ................................................................................................... 7–47.2.2.1 Connection Pooling ................................................................................................ 7–57.2.3 Network Considerations ............................................................................................... 7–67.2.3.1 Firewalls and Timeouts.......................................................................................... 7–67.2.3.2 Router Timeouts...................................................................................................... 7–67.2.3.3 Miscellaneous Issues............................................................................................... 7–77.3 Deployment Tasks................................................................................................................. 7–77.3.1 Setting Profile Options .................................................................................................. 7–77.3.2 Establishing End User Access ...................................................................................... 7–87.3.3 Load Testing.................................................................................................................... 7–8

viii

7.3.3.1 Stress Testing .......................................................................................................... 7–87.3.3.2 User Activity Testing ............................................................................................. 7–87.3.4 Load Balancing .............................................................................................................. 7–9

A Import Tables

A.1 Overview................................................................................................................................ A–1A.2 List of Import Tables ............................................................................................................ A–1A.3 Dependencies Among Import Tables ................................................................................ A–2A.4 Import Tables ........................................................................................................................ A–3

Glossary of Terms

Glossary of Acronyms

Index

ix

List of Figures

1–1 Development Installation..................................................................................................... 1–71–2 Production Installation ......................................................................................................... 1–91–3 Overview of Oracle Configurator Architecture............................................................. 1–111–4 Implementation Task Flow ............................................................................................... 1–124–1 Overview of Data Import ..................................................................................................... 4–24–2 Overview of Data Import from Oracle Bills of Material............................................... 4–124–3 Initial Import of BOM Model with Component Models .............................................. 4–214–4 Re-Import/Refresh of Initial BOM Model ...................................................................... 4–214–5 Import a New BOM Model with References to Existing BOM Models ..................... 4–224–6 Overview of Custom Import ............................................................................................ 4–274–7 Extraction Setup for a Custom Import ............................................................................ 4–275–1 Run-time Oracle Configurator Pricing Architecture........................................................ 5–4

x

List of Tables

1–1 Oracle Configurator Concurrent Programs for Server Administration ..................... 1–143–1 CZ_DB_SETTINGS............................................................................................................... 3–53–2 Oracle Configurator Administration Concurrent Programs........................................ 3–114–1 Import Control Fields........................................................................................................... 4–34–2 CZ_XFR_TABLES Fields ..................................................................................................... 4–54–3 CZ_XFR_FIELDS Fields....................................................................................................... 4–64–4 CZ_XFR_PROJECT_BILLS Fields ...................................................................................... 4–74–5 Oracle Applications Source and Destination Online Tables ........................................ 4–104–6 Properties Imported from Oracle Inventory................................................................... 4–116–1 Publication Tables............................................................................................................... 6–10A–1 Dependencies Among Oracle Configurator Schema Import Tables............................. A–2A–2 Import Table Field Disposition Codes .............................................................................. A–3A–3 Import Table Record Status Codes .................................................................................... A–3A–4 Description of Fields in CZ_IMP_DEVL_PROJECT Import Table................................ A–4A–5 Description of Fields in CZ_IMP_INTL_TEXT Import Table ........................................ A–6A–6 Description of Fields in CZ_IMP_ITEM_MASTER Import Table ................................. A–7A–8 Description of Fields in CZ_IMP_ITEM_PROPERTY_VALUE Import Table........... A–10A–9 Description of Fields in CZ_IMP_ITEM_TYPE Import Table...................................... A–12A–10 Description of Fields in CZ_IMP_ITEM_TYPE_PROPERTY Import Table............... A–14A–11 Description of Fields in CZ_IMP_PROPERTY Import Table....................................... A–17A–12 Description of Fields in CZ_IMP_PS_NODE Import Table ......................................... A–19

xi

Send Us Your Comments

Oracle Configurator Implementation Guide, Release 11i

Part No. A87531-01

Oracle Corporation welcomes your comments and suggestions on the quality and usefulness of this publication. Your input is an important part of the information used for revision.

■ Did you find any errors?■ Is the information clearly presented?■ Do you need more information? If so, where?■ Are the examples correct? Do you need more examples?■ What features did you like most about this manual?

If you find any errors or have any other suggestions for improvement, please indicate the chapter, section, and page number (if available). You can send comments through your call to Oracle Support Services or by sending them to:

Oracle Configurator Oracle Corporation Documentation 21 North Avenue Burlington, MA 01803 USA

If you would like a reply, please give your name, address, and telephone number below.

If you have problems with the software, please contact your local Oracle Support Services.

xiii

Preface

This Oracle Configurator Implementation Guide provides explanations, descriptions, and instructions for the administration tasks required to set up and support development and deployment of a run-time Oracle Configurator.

Intended AudienceThis manual is intended for system administrators and database administrators who are supporting Oracle Configurator developers and end users. Anyone responsible for supporting use of Oracle Configurator should read this book. That includes supporting the development environment (Oracle Configurator Developer) as well as the run-time environment that is created for deployment.

Ordinarily, the tasks presented in this book are performed by a Database Administrator (DBA) or an Oracle Configurator administrator with DBA experience.

StructureThis manual contains the following chapters and appendixes:

■ "Introduction" provides an overview of Oracle Configurator and describes the software components and run-time Oracle Configurators. It provides an overview of Oracle Configurator administrative tasks, terms, the types of Oracle Configurator installations, and the Oracle Configurator architecture.

■ "The Spx.ini File" describes the spx.ini file and how it is used. It provides an example spx.ini file and detailed explanation of its parameters and how they are used.

xiv

■ "The Oracle Configurator Schema" describes the basic characteristics of the Oracle Configurator schema, the schema settings and how they are used, and provides some schema maintenance tips.

■ "Importing Data" provides an overview of why and how data is imported from Oracle Applications and non-Oracle Applications. It describes the import processes, the import tables used during data import, how to import data into the Oracle Configurator schema, data import verification, the process for refreshing or updating imported data, and customizing data import.

■ "Pricing in Oracle Configurator" provides an overview of how pricing works in a run-time Oracle Configurator and the pricing architecture.

■ "Publishing Configuration Models" describes how to publish configuration models for deployment to a production run-time Oracle Configurator application.

■ "Deploying Oracle Configurator" provides information for deploying a run-time Oracle Configurator and accessing a run-time Oracle Configurator from other Oracle Applications.

■ Appendix A, "Import Tables" provides a list of the import tables used in the data import processes, their dependencies, and descriptions of each import table field and the data they expect.

■ "Glossary of Terms"

■ "Glossary of Acronyms"

■ "Index"

Related DocumentsThe following documents are also included in the Oracle Configurator documentation set on the Oracle Configurator Developer compact disc:

■ Oracle Configurator ReadMe

■ Oracle Configurator Release Notes

■ Oracle Configurator Installation Guide

■ Oracle Configurator Developer User’s Guide

■ Oracle Configurator Custom Web Deployment Guide

xv

■ Oracle Configuration Interface Object (CIO) Developer’s Guide

■ Oracle Configurator Technical Reference Manual

For more information, see the documentation for Oracle Applications (Release 11i ) Oracle RDBMS (Release 8i), the Oracle Applications Library, and the product-specific Release Notes for releases supported to work with Oracle Configurator.

ConventionsIn examples, an implied carriage return occurs at the end of each line, unless otherwise noted. You must press the Return key at the end of a line of input.

The following conventions are also used in this manual:

Product SupportThe mission of the Oracle Support Services organization is to help you resolve any issues or questions that you have regarding Oracle Configurator Developer and Oracle Configurator.

To report issues that are not mission-critical, submit a Technical Assistance Request (TAR) via Metalink, Oracle’s customer support Web site, at:

http://metalink.oracle.com

You can also find product-specific documentation and other useful information using Metalink.

Convention Meaning

. . .

Vertical ellipsis points in an example mean that information not directly related to the example has been omitted.

. . . Horizontal ellipsis points in statements or commands mean that parts of the statement or command not directly related to the example have been omitted.

boldface text Boldface type in text indicates a term defined in the text, the glossary, or in both locations.

italic text Italic text in code examples indicates user-supplied parameters or arguments.

[ ] Brackets enclose optional clauses from which you can choose one or none.

xvi

For a complete listing of available Oracle Support Services and phone numbers, see:

http://www.oracle.com/support

For general information about Oracle Applications, visit AppsNet at:

http://www.oracle.com/appsnet/index.html

Introduction 1-1

1Introduction

Oracle Configurator consists of the run-time Oracle Configurator, Oracle Configurator Developer, and the Oracle Configurator schema (CZ). The run-time Oracle Configurator and Oracle Configurator schema are installed with Oracle Applications Release 11i. Oracle Configurator Developer is installed from the Oracle Configurator Developer compact disc.

This book presents all the basic implementation tasks necessary for supporting use of a run-time Oracle Configurator in the following general environments:

■ Oracle Applications Release 11i with a run-time Oracle Configurator add-on in Order Management, Telesales, iStore, or Sales Online

■ A custom web application using Oracle Configurator

■ A run-time Oracle Configurator using imported Oracle Applications Release 11.0 or 10.7, or non-Oracle or legacy data

■ Oracle Configurator Developer

1.1 Run-time Oracle ConfiguratorsThroughout this book, references to a run-time Oracle Configurator means a run-time Oracle Configurator embedded in another application.

A run-time Oracle Configurator is an end-user environment for configuring products and services. Implementers or developers of a run-time Oracle Configurator use Oracle Configurator Developer to develop configuration models and user interface customizations. You can unit test your configuration models in development or test instances of these run-time configurators from within Oracle Configurator Developer. After publishing a model and setting up the host application to call the run-time Oracle Configurator, you can system test your configuration models.

Oracle Configurator Schema

1-2 Oracle Configurator Implementation Guide

A run-time Oracle Configurator is deployed within Oracle Applications or a custom web application as either a Java applet or a DHTML window running in a browser.

1.2 Oracle Configurator SchemaThe Oracle Configurator schema (CZ) is part of the Oracle Applications database that is used by Oracle Configurator. When using existing Oracle Applications data to define configuration models, the data must be imported into the Oracle Configurator schema for use by Oracle Configurator Developer and the runtime configurator. Data imports from within the Release 11i Oracle Applications database are completed by submitting an Oracle Applications concurrent process request. SQL*Plus scripts available on the Oracle Configurator Developer compact disc provide import capabilities for data from Release 10.7 and 11.0 Oracle Applications databases or non-Oracle legacy databases to the Release 11i CZ schema.

1.3 Overview of Oracle Configurator ImplementationThis document presents specific instructions for performing the tasks required to set up and support development and deployment of a run-time Oracle Configurator, including the following categories of tasks:

■ Modifying the spx.ini file

■ Preparing data for import into the Oracle Configurator schema

■ Importing data from within the Oracle Applications Release 11i database

■ Importing data from Oracle Applications Release 10.7 or 11.0

■ Importing data from non-Oracle or legacy databases

■ Publishing a configuration model for use in a production environment

■ Deployment of a run-time Oracle Configurator

This book does not present instructions for

■ Establishing any privileges to any user, including DBA privileges

■ Establishing a database instance

■ Installing Oracle Applications for using the run-time Oracle Configurator

■ Installing and setting up Oracle8i Enterprise Edition RDBMS

See other relevant Oracle documentation for help with these other tasks.

Overview of Oracle Configurator Implementation

Introduction 1-3

The tasks needed to support using Oracle Configurator require both the knowledge of an experienced Oracle Database Administrator (DBA) and some knowledge of application system administration. Although Oracle Configurator projects vary in implementation requirements, this manual provides explicit explanations and directions for common tasks wherever possible.

Oracle Configurator implementation tasks should be handled by the Oracle Applications System Administrator and the Oracle Database Administrator. An Oracle Applications System Administrator administers the user interface or applications side of Oracle Applications. An Oracle Database Administrator administers the data that users enter, update, and delete while using Oracle Applications.

Oracle Configurator integrates with other Oracle Applications by importing data from another Oracle Applications database schema to the Oracle Configurator schema (CZ) which can then be accessed by other Oracle Applications. For example, you can copy or import Bills of Material (BOM) data to the CZ schema, create a configuration model to run in a run-time Oracle Configurator using the Oracle Configurator Developer, then access that configuration model as an item in Order Management, configure the item in the run-time Oracle Configurator within Order Management, and then submit the configured item as part of the order. In Order Management, the configuration model is based on an imported BOM that exactly mirrors the BOM in Oracle Applications Bills of Material.

It is also possible to configure a BOM in the run-time Oracle Configurator of Order Management, Order Capture, and Telesales without ever having imported it into the Oracle Configurator Developer to create a configuration model for it.

1.3.1 Concurrent ProgramsOracle Configurator provides concurrent programs for many of the implementation tasks. In order to run these programs you must be assigned the appropriate Configurator responsibility for the specific program (either Configurator Administrator or Configurator Developer). For more information about assigning responsibilities, see the Oracle Configurator Installation Guide.

Concurrent programs are available for the following tasks:

■ View configurator parameters (see Section 3.3.2, "View Configurator Parameters" on page 3-12)

■ Modify configurator parameters (see Section 3.3.1, "Modify Configurator Parameters" on page 3-11)

■ Purge configurator tables (see Section 3.4.2, "PURGE" on page 3-13)

Oracle Configurator Environments

Introduction 1-5

Applications, there is only one product-specific schema per product, meaning only one CZ schema for each database instance.

In some cases, a data import is required to duplicate data from one database or schema to another schema. Concurrent programs are available to import data from some Oracle Applications Release 10.7, 11.0, and 11i schemas to the 11i Oracle Configurator schema. A custom import is required for data import between non-Oracle Applications databases or among previous releases of the Oracle Applications database.

In the Oracle Configurator product generally, and this book in particular, users are distinguished from end users. Users are the implementers using Oracle Configurator Developer to create a configuration model that runs in a run-time Oracle Configurator. End users are the users of those run-time Oracle Configurators.

1.5 RequirementsAll requirements and prerequisites for installing and using Oracle Configurator Developer are presented in the Oracle Configurator Installation Guide or the Oracle Configurator Release Notes on the Oracle Configurator Developer compact disc. Additional requirements and prerequisites for installing and using Oracle Configurator in a custom web environment are presented in the Oracle Configurator Custom Web Deployment Guide.

1.6 Oracle Configurator EnvironmentsThe Oracle Configurator schema and run-time Oracle Configurator (end-user environment) are part of the Oracle Applications installation. In this release, Oracle Configurator Developer is installed from the Oracle Configurator Developer compact disc. The run-time Oracle Configurator for Release 11i additionally requires an application server installation. See the Oracle Configurator Installation Guide for these installation instructions.

The administrator must be informed of the Oracle Configurator environment(s) needed for the site. Basic environments include:

■ Development

■ Testing

■ Production

■ Maintenance



For each installation, there is likely to be a separate Oracle Applications organization. In any installation, you will be running the Oracle Configurator in one of the following scenarios:

■ Oracle Applications Release 11i with the Java applet run-time Oracle Configurator in Order Management, Telesales, or Order Capture to configure items that are based on a configuration model or configurable BOM.

■ Oracle Applications Release 11i with the DHTML run-time Oracle Configurator in iStore, Sales Online, Order Management, Telesales, or Order Capture to configure items that are based on a configuration model.

■ A custom web application with a DHTML run-time Oracle Configurator for configuring items based on a configuration model.

■ A test instance of a run-time Oracle Configurator launched from Oracle Configurator Developer running on a client Windows machine networked by LAN to the Release 11i Oracle Applications database on a server machine.

Installation-wide customizable settings that describe the structure and content of the CZ schema and give parameters for certain application functions are stored in the CZ_DB_SETTINGS table. Settings in the CZ_DB_SETTINGS table may vary depending on whether the installation is for development, test, production, or maintenance. There is one CZ_DB_SETTINGS table for each Oracle Configurator schema that is in effect for all users of that schema.

For details about what parameters in CZ_DB_SETTINGS apply in each of the scenarios, above, see Section 3.2, "Oracle Configurator Schema Settings" on page 3-4.

1.6.1 DevelopmentA development environment is one in which you create your Oracle Configurator model by constructing an end-user user interface referred to in this manual as a run-time Oracle Configurator. Development is most commonly a networked installation with Oracle Configurator Developer on a client machine which accesses data from the Oracle Applications database and the Oracle Configurator schema that is on a server machine.

Running a run-time Oracle Configurator also requires installing an application server. See the Oracle Configurator Installation Guide for information about application server installation. See the Oracle Configurator Release Notes for additional warnings, requirements, and helpful hints before you begin developing your run-time Oracle Configurator.


Introduction 1-7

In order to develop a run-time Oracle Configurator, data must be imported from a legacy database or an Oracle Applications database into the Oracle Configurator schema to be used as a baseline to define configuration models in Oracle Configurator Developer. The configuration models can then be "published" for either a test or production environment. In a test environment the configuration models are tested for usability in a production environment. In a production environment the configuration models are accessed for use in the downstream manufacturing process.

Data can be imported into the Oracle Configurator schema (CZ tables) from:

■ Other Oracle Applications Release 11i schemas

■ Oracle Applications Release 10.7 or 11.0

■ Any legacy or non-Oracle Applications database

Figure 1–1 Development Installation

The source database containing legacy or non-Oracle Applications data, may or may not be on the same machine as the Oracle Configurator schema. If not, the integration tables in the Oracle Configurator schema must be set up with links to the source database.

Likewise, the production or test instance to which you publish configuration models may or may not be on the same machine as the development instance. If not, you must ensure that a remote server is defined and enabled to complete the publication successfully. See "Server Administration" on page 1-12 for details about defining and enabling a remote server. See Chapter 6, "Publishing Configuration Models" for more information about publishing configuration models.

After successfully importing any legacy data needed for modeling configurations at the start of your development cycle, Oracle recommends that you complete and



unit test your configuration model before transferring new or updated data. Configuration modeling data includes item master, item type, structure, and property data.

1.6.2 TestingA test environment is one in which you perform system testing on your run-time Oracle Configurator in preparation for initial deployment, upgrades, and new releases, decoupled from continuing development.

Unit test the configurator rules and UI functionality in the development environment making sure periodic rule and UI modifications work as required.

System test the runtime configurator functionality in an environment similar to the desired production environment making sure that periodic data transfers and modifications work as required. For example, changed options should propagate through to the hosting application such as Order Management.

1.6.3 ProductionA production environment is one in which end users of the run-time Oracle Configurator use the software in a production mode. To prepare for deployment to your production environment, you should create a production-ready version of the Oracle Configurator schema that is populated with published configuration models or mark models in the development environment for publication to the production environment.

For more efficient use of machine resources, purge records flagged for deletion before creating the production-ready version. See Section 3.4.2, "PURGE" on page 3-13 for more information about purging records.

The possible deployment scenarios are:

■ client/server (networked)

■ web

For information about how to publish a configuration model to a production Oracle Configurator schema, see Chapter 6, "Publishing Configuration Models". For information about how to refresh or update a production Oracle Configurator schema see Section 3.4.1, "Refresh or Update the Production Schema" on page 3-12.


Introduction 1-9

Figure 1–2 Production Installation

The Oracle Configurator schema is installed on the database server machine as part of your Oracle Applications database. In Figure 1–2, the networked run-time Oracle Configurator could be integrated with Oracle Order Management, iStore, TeleSales, or Sales Online. The run-time Oracle Configurator could also be embedded in a custom web store application.

In a Web environment, the run-time Oracle Configurator user interface runs in a browser. The Oracle Configurator (the application itself) runs on the application server machine with the internet commerce server brokering the processes and http connection.

1.6.4 MaintenanceA maintenance environment is similar to a development environment since it is used to upgrade the CZ schema and refresh configuration data.

At the time you deploy your run-time Oracle Configurator and create a production Oracle Configurator schema or publish configuration models, you could also create a maintenance Oracle Configurator schema. In the course of a deployed release of your run-time Oracle Configurator, you may conduct periodic updates from Oracle

Oracle Configurator Architecture Overview


Applications or imports from your legacy data and redeploy the refreshed run-time Oracle Configurator.

Another aspect of maintenance involves fixing and improving the configuration model and publishing these in periodic upgrades. It is important to synchronize these changes in the maintenance Oracle Configurator schema with the Oracle Configurator schema under development for the next release of your run-time Oracle Configurator. For information about refreshing from one version of your Oracle Configurator schema to another, see Section 3.4.1, "Refresh or Update the Production Schema" on page 3-12.

When you upgrade the release version of Oracle Configurator that your run-time Oracle Configurator runs against, you start by upgrading your Oracle Configurator schema. For information on upgrading from one release to another of Oracle Configurator, see the Oracle Configurator Installation Guide on the Oracle Configurator Developer compact disc.

Once you have upgraded your Oracle Configurator schema for a new release, you must re-execute the Generate Active Model command in Oracle Configurator Developer.

1.7 Oracle Configurator Architecture OverviewNo matter what the environment, the Oracle Configurator architecture is essentially the same. A run-time Oracle Configurator consists of a configuration model that is developed in Oracle Configurator Developer. The configuration model is also sometimes called the Active Model and manages the model structure, configuration rules, and UI definitions of the run-time Oracle Configurator.

The model-driven User Interface (UI) definitions in the run-time Oracle Configurator are called the Active UI. The Active UI and Active Model interact with the data in the Oracle Configurator schema to present Oracle Configurator Developer users with the data they need to develop and unit test the run-time Oracle Configurator. The Active Model and Active UI also interact with the Oracle Configurator schema to present end users with a configuration model in which to make their option selections that result in a valid configuration.

Warning: Do not run Oracle Configurator Developer and the Generate Active Model command against a deployed production Oracle Configurator schema.

Implementation Tasks

Introduction 1-11

Figure 1–3 Overview of Oracle Configurator Architecture

The CIO is the Configuration Interface Object, an API used for communication between the Active UI and the Active Model.

1.8 Implementation TasksIn order to support any Oracle Configurator environment, you must perform implementation tasks in the order presented below. The tasks in the right column are additional tasks required for supporting custom import of data from legacy databases to the Oracle Configurator schema. See Section 4.10.4, "Creating a Custom Import" on page 4-25 for more information about custom import.



Figure 1–4 Implementation Task Flow

1.8.1 Commonly Performed Implementation TasksThis book presents specific instructions for performing many of the implementation tasks required to set up and support development and deployment of a run-time Oracle Configurator. Instructions for some frequently performed tasks are included in the following sections:

■ "Server Administration"

■ "View the Status of Oracle Configurator Concurrent Process Requests"

■ "Query Registered Oracle Configurator Concurrent Programs"

■ "Connect to a Database Instance"

■ "Verify Oracle Configurator Schema Version"

1.8.1.1 Server Administration Oracle Configurator can operate within a multi-server environment in order to utilize separate production and development (including testing or maintenance) database instances. These databases are not necessarily separate machines.


Introduction 1-13

However, as long as you are using separate database instances you need to define, enable, or possibly modify the remote server. This is necessary for importing data from an Oracle Applications database instance or to publish a configuration model to a remote Oracle Applications database instance. Oracle Configurator provides the following concurrent programs for server administration:

■ Define Remote Server

■ Enable Remote Server

■ Modify Server Definition

■ View Servers

Table 1–1, "Oracle Configurator Concurrent Programs for Server Administration" describes these Oracle Configurator concurrent processes.



Table 1–1 Oracle Configurator Concurrent Programs for Server Administration

Configurator Concurrent Process Description Parameters

Define Remote Server Creates a new remote server definition. Local Name - local name by which to refer to this server.

Host Name - TCP host name for this server.

DB Listener Port - TCP port number on which this database server is listening for client connections.

Oracle Applications Schema - name of Oracle Applications Schema (FNDNAM).

Global Identity (if any) - when the database initialization parameter GLOBAL_NAMES is set to true, this field should be entered with the name of the remote server. When GLOBAL_NAMES is true, the name of the FND Link Name must match the global name of the database you are linking to.

Notes - any notations you want to make regarding this server.

FND Link Name - name for the link to the Oracle Applications schema.

Import Enabled (Y/N) - enable or disable import on this server. Only one remote server can be enabled for import.

Enable Remote Server Performs all the operations needed to enable a remote server for import. Loads (or links in) the list of remote BOMs into the local instance for use by the Import Bill Models concurrent process.

Remote Server - select from the list of values or enter the name of the server entry to enable. "FOREIGN" (-1) and the local server (0) are not allowed parameters.

Password - password for the Oracle Applications schema (FNDNAM) on this remote server.


Introduction 1-15

1.8.1.1.1 Running Server Administration Concurrent Processes

Only users assigned to the Configurator Administrator responsibility can run the Server Administration concurrent processes. Use the following procedure to run the Server Administration concurrent processes:

1. Log into Oracle Applications under the Configurator Administrator responsibility.

2. Select Configurator > Server Administration.

3. Select the concurrent process you want to run from the Server Administration menu.

4. When necessary, a Parameters form displays to prompt you for the parameters required by the concurrent process you selected. Enter the parameters as

Modify Server Definition Allows the user to modify a remote server definition.

Local Name - local name by which to refer to this server.

Host Name - TCP host name for this server.

DB Listener Port - TCP port number on which this database server is listening for client connections.

Oracle Applications Schema - name of Oracle Applications Schema (FNDNAM).

Global Identity (if any) - when the database initialization parameter GLOBAL_NAMES is set to true, this field should be entered with the name of the remote server. When GLOBAL_NAMES is true, the name of the FND Link Name must match the global name of the database you are linking to.

Notes - any notations you want to make regarding this server.

FND Link Name - name for the link to the Oracle Applications schema.

Import Enabled (Y/N) - enable or disable import on this server. Only one remote server can be enabled for import.

View Servers Writes the server information to the concurrent process log.

None.

Table 1–1 Oracle Configurator Concurrent Programs for Server Administration




described in Table 1–1, "Oracle Configurator Concurrent Programs for Server Administration" on page 1-14.

5. Click OK.

6. Click Submit.

When you run the View Servers concurrent process, the output containing the defined server information is recorded in a log file.

7. To view the output log file, first view your requests as described in "View the Status of Oracle Configurator Concurrent Process Requests" on page 1-16.

8. On the Requests form, verify that this request has completed successfully then click in the space to the left of the Request ID to select this request.

9. Click View Log.

1.8.1.2 View the Status of Oracle Configurator Concurrent Process RequestsSince all reports, processes, and requests are run as concurrent requests in Oracle Applications, you use the Requests window to view the status and output of your requests.

You can use the Requests window to view a list of all submitted concurrent requests, check whether your request has run, change aspects of the request’s processing options, diagnose errors, or find the position of your request in the queues of available concurrent managers.

You can navigate to the Oracle Applications Requests window using the Navigator window. Different Oracle Applications products use different menu paths in the Navigator window to access the Requests windows. To access the Requests window through the Configurator responsibilities:

1. Log into Oracle Applications 11i under the Configurator responsibility to which you are assigned; Configurator Administrator or Configurator Developer.

2. Select Configurator > Requests.

The Find Requests form displays.


Introduction 1-17

f

3. Select the category of Requests you want to view and click Find.

The Requests display with the Request ID, Name, Parent, Phase, Status, Requestor, and Priority.



f

1.8.1.3 Query Registered Oracle Configurator Concurrent ProgramsAs with any other Oracle Application, you can register the Oracle Configurator concurrent programs under any responsibility. You can query to find which Oracle Configurator concurrent programs have been registered for a given instance.

Note: If your system administrator sets the profile option Concurrent: Report Access Level to "User", the Requests window displays the concurrent requests for the current user.

If your system administrator sets this profile option to “Responsibility”, the Requests window displays the concurrent requests for the current responsibility in addition to requests for the current user.


Introduction 1-19

Use the following procedure to query the registered Oracle Configurator concurrent programs:

1. Switch to the System Administrator responsibility.

f

2. Navigate to Concurrent > Programs > Define

3. From the View pull-down menu choose Query By Example > Enter.



4. The Concurrent Programs form displays. Enter CZ% in the Short Name field.

5. From the View pull-down menu choose Query By Example > Run.


Introduction 1-21

6. The Concurrent Programs form displays the registered Oracle Configurator current programs one at a time. Use the arrow keys to scroll through the Configurator concurrent programs.

1.8.1.4 Connect to a Database InstanceCertain implementation tasks must be performed while connected to a specific database instance.

To connect to a specific database, you must specify a user or schema and the instance in which it is defined. For example

1. Connect to your Oracle Configurator schema by connecting to the instance <appssid> as a user of the schema you need to access.

Example:

SQL> connect <oc>/<ocpass>@<appssid>

where <oc> is the owner (DBOwner) of the Oracle Configurator schema, <ocpass> is the owner’s password, and <appssid> is the name for the Oracle8i Enterprise Edition instance on which the Oracle Configurator schema is installed.

Or connect to the database instance as a user with DBA privileges:Example:

SQL> connect <dba>/<dbapass>@<appssid>

2. Connect to the instance <appssid> as the integration user.

Example:

SQL> conn <imp> <imppass>@<appssid>

1.8.1.5 Verify Oracle Configurator Schema VersionThe version of the Oracle Configurator schema is available in the CZ_DB_SETTINGS table.

To verify that the Oracle Configurator schema is correct, select the version settings from the CZ_DB_SETTINGS table.

For example:

SQL> select setting_id, value, desc_text from cz_db_settings where setting_id like ’%_VERSION"



The result for this Release 11i should be MAJOR_VERSION = 15, MINOR_VERSION = i.

The Spx.ini File 2-1

2The Spx.ini File

The spx.ini file contains the parameters that determine connectivity and behavior for development and unit testing of a run-time Oracle Configurator using Oracle Configurator Developer. You must edit the spx.ini file before you can start Oracle Configurator Developer. See the Oracle Configurator Installation Guide for information about creating DSNs and database connectivity.

See "Parameters in spx.ini" on page 2-2 for details about specific parameters.

Example 2–1 shows some of the parameters you may find in an spx.ini file.

Example 2–1 Example spx.ini File

[Merlin]DBOwner=appsJdbcUrl=jdbc:oracle:thin:@ctra-sunserver:1523:DHTMLTest

[DSN]DHTMLTestJavaTest

[DHTMLTest]DBOwner=appsJdbcUrl=jdbc:oracle:thin:@ap320sun:1623:DHTMLTestgwyuid=APPLSYSPUBgwypass=PUBAPPLID=660RESPID=21623

[JavaTest]DBOwner=appsJdbcUrl=jdbc:oracle:thin:@ap320sun:1623:JavaTestgwyuid=APPLSYSPUB


gwypass=PUB

[Design Chart]DEF=M, N, A, TSEC=X, Y, Z

[Test]Launch=2InitServletURL=http://ap882sun.us.oracle.com:10130/servlets/oracle.apps.cz.servlet.UiServletInitCodeBaseUrl=http://app882sun.us.oracle.com:10140/applet

During installation of Oracle Configurator Developer, a default spx.ini file is copied to the winnt directory (for Windows NT machines) or the Windows directory (for Windows 95/98 machines). If the installation procedure encounters an existing spx.ini file, it renames that file spx_ini.bak, so that you do not lose edits you have made when you upgrade or reinstall Oracle Configurator Developer.

2.0.1 Parameters in spx.ini The spx.ini file sets the DBOwner and other parameters for running:

■ Oracle Configurator Developer

■ a test instance of a run-time Oracle Configurator from within Oracle Configurator Developer

Throughout this section, references to the test configurator mean test instances of a run-time Oracle Configurator launched from within Oracle Configurator Developer.

Oracle Configurator Developer and the test configurator require that the DSNs defined in the spx.ini file point to an installed Oracle Configurator schema. The DSNs set in the spx.ini file must also be registered in the ODBC Administrator for each machine running Oracle Configurator Developer and the test configurator.

You must edit the spx.ini file and update the [DSN] entries by adding the ODBC DSN(s) you create for your Oracle Configurator schema(s). The entries then appear in the Oracle Configurator Developer list of available data sources when you log in to Oracle Configurator Developer. You must create the Oracle Configurator schema DSN yourself, following the instructions in the Oracle Configurator Installation Guide; the spx.ini entries will not work until you create the DSN.

You must also edit the spx.ini file and add entries for each of the DSNs available to an instance of the test configurator and DBOwner. The DSNs listed in


Example 2–1 are examples of those installed as part of the Oracle Configurator installation. (See Section 2.0.1.2, "[DSN]".)

Additional parameters may be defined specifically for manipulating the behavior of the test configurator instance.

2.0.1.1 [Merlin]The section [Merlin] is the default parameters section for Oracle Configurator Developer.

DBOwner in [Merlin]The parameter DBOwner in the section [Merlin] specifies the default username of the owner of the Oracle Configurator schema that the spx.ini file accesses when starting up Oracle Configurator Developer. Users log into Oracle Configurator Developer with the schema owner name and the password.

The DBOwner is to the Oracle Configurator Developer as FNDNAM is to the rest of Oracle Applications. To prevent limitations in Oracle Configurator Developer functionality, however, you should log in to Oracle Configurator Developer as an Oracle Applications FND user. To do this, the datasource description in the spx.ini file on the client machine where Oracle Configurator Developer is installed must provide additional gateway parameters (gwyuid and gwypass) that specify the Oracle public gateway login information for FND authentication. See Section 2.0.1.3, "[dsn]" for an example of the usage of the gwyuid and gwypass parameters.

JdbcUrl in [Merlin]The JdbcUrl entry in this section indicates how the run-time Oracle Configurator calling application should connect to the database if the default settings are used.

2.0.1.2 [DSN]The section [DSN] lists the Data Source Names for the Oracle Configurator schemas available for use by Oracle Configurator Developer.

The DSN of the Oracle Configurator schema used with Oracle Configurator Developer must be listed here. Furthermore, a section must also be added for each DSN of the server DBOwner by which users will access the server Oracle Configurator schema (see Section 2.0.1.3, "[dsn]").


2.0.1.3 [dsn]Every Oracle Configurator schema instance to which you need access from Oracle Configurator Developer, must be listed as a discrete [DSN] section.

DBOwner in [dsn]Each [Discrete DSN] section specifies the DBOwner by which the Oracle Configurator schema associated with the DSN will be accessed.

[DSN]DBOwner=DBOwnerJdbcUrl=Jdbc_connectiongwyuid=gateway_user_idgwypass=gateway_passwordapplid=application_idrespid=responsibility_id

In Example 2–1 on page 2-1, there are several DSNs listed as examples. DHTMLTest is an Oracle Applications database available for use by Oracle Configurator Developer to test user interfaces launching a DHTML window. JavaTest is an Oracle Applications database available for use by Oracle Configurator Developer to test user interfaces launching a Java Applet and using Oracle Applications FND authentication.

JdbcUrl in [dsn]The JdbcUrl entry in each discrete [DSN] section indicates how the run-time Oracle Configurator calling application should connect to the database. If you are using only the DHTML window for unit testing, you must add a JdbcUrl entry. If you are using a Java applet window for unit testing, this parameter is not required.

Gwyuid and Gwypass in [dsn] Oracle Configurator uses Oracle Applications FND authentication for user authentication for Oracle Configurator Developer and the run-time Oracle Configurator. Therefore, you must add two entries to each discrete [DSN] section that provide Oracle gateway information, gwyuid and gwypass. Gwyuid is the public Oracle gateway username and gwypass is the public Oracle gateway password that grants access to the Oracle Applications log on form. Gwyuid and

Note: The DBOwner setting here overrides the DBOwner setting in the section [Merlin]. The DBOwner settings under [Merlin]are defaults.


gwypass should be the same as the default username and password in your Oracle Applications environment file. The DHTMLTest and JavaTest DSN sections in Example 2–1 include these entries for Oracle Applications user authentication. In order to use the Oracle Applications login functionality, the value for DBowner here should be the same as the FNDNAM parameter value in the Oracle Applications environment file.

APPLID and RESPID in [dsn]When unit testing a model from Oracle Configurator Developer using a DHTML window, or calling Oracle Configurator from another client (calling) application, you may want to retrieve translated messages (FND messages). In order to do this, an icx_session_ticket must be passed to the XML initialization message from Oracle Configurator Developer. An icx_session_ticket helps to maintain the connection parameters established during connection (user id, responsibility id, and application id).

When the APPLID (application id) and RESPID (responsibility id) parameters are set, they in combination with the FND User ID, are used to generate the icx_session_ticket information for the initialization message string for the database session. This combination determines the language in which FND messages are returned. The APPLID is the identifier for the client application and RESPID is the identifier for the associated responsibility. These parameters are integer values. You can find the appropriate integer value for the application and responsibility that applies to your calling application in the Oracle Applications FND_APPLICATION or FND_RESPONSIBILITY tables.

If these parameters are not specified, Oracle Configurator Developer passes an initialization message using only the database connection (dbc) file. See the Oracle Configurator Installation Guide and the Oracle Configurator Custom Web Deployment Guide for more information about the database connection file and the initialization message.

2.0.1.4 [Design Chart]The section [Design Chart] sets the alpha symbols used to indicate defining (DEF=) and secondary (SEC=) optional features in the Design Chart configuration rule in Oracle Configurator Developer. As Example 2–1 shows, you can assign multiple symbols if you use multiple defining and secondary features in a Design Chart rule. However, the defining (DEF=) set of symbols must be completely different than the secondary (SEC=) symbols.


2.0.1.5 [Test]The section [Test] sets the type of environment to launch when using the Test button in Oracle Configurator Developer.

Launch in [Test]Launch=2 specifies the Dynamic HTML in a browser. When Launch=2 is specified, the parameter InitServletURL must also be set to specify the URL of the servlet generating the Dynamic HTML in a browser.

Launch=3 specifies the Java Applet. When Launch=3 is specified, the parameter InitServletURL must be set to specify the URL of the servlet generating the Java Applet. Additionally, when testing using the Java Applet the InitCodeBaseUrl parameter must be set to specify the URL of the location of the class or Java archive files for the Java Applet. For example:

InitCodeBaseUrl=http://app882sun.us.oracle.com:10140/applet

These test options may also be selected in the Tools > Options > Test dialog in Oracle Configurator Developer which edits the spx.ini file. For any Oracle Configurator Developer session, the setting in Tools > Options > Test is stored in memory and used when launching the test configurator. If you manually edit the spx.ini file, the change will not take affect until you restart .

Note: The InitCodeBaseUrl is used for testing a Java applet or running a Java applet from a stand alone web page only.

The Oracle Configurator Schema 3-1

3The Oracle Configurator Schema

Run-time Oracle Configurators use a standard schema for configuration data referred to as the Oracle Configurator schema (CZ tables) in the Oracle Applications database. The Oracle Configurator schema is used to store all information relative to a configuration model — product data, model structure, configuration rules, and user interface layouts. Product-related data is typically imported into the Oracle Configurator schema from data sources external to Oracle Configurator.

In order to pass data between the Oracle Configurator schema and other Oracle Applications tables or external data, the Oracle Configurator schema includes a set of tables for integration. The integration tables that stage data coming into the Oracle Configurator schema are the import tables. See Appendix A.2, "List of Import Tables" on page A-1 for detailed information about the import tables. The integration tables that are populated with data from the import tables and used by the run-time Oracle Configurator and Oracle Configurator Developer are called the online tables.

3.1 Characteristics of the Oracle Configurator SchemaThe instance name for the Oracle Configurator schema (CZ schema) you use with Oracle Configurator Developer is identified in the spx.ini file. See Chapter 2, "The Spx.ini File" for more information about the spx.ini file.

The Oracle Configurator schema does not use public synonyms.

The Oracle Configurator schema consists of the following subschemas:

CF - ConfigurationGN - General Use tablesIM - Item-MasterLC - Logic for Configuration (Active Model)PB - Publication

Characteristics of the Oracle Configurator Schema


PS - Project StructureRP - RepositoryUI - User InterfaceXF - Transfer specifications and control

The following sections list the tables in each subschema. For detailed information about these and other tables, see the Oracle Configurator Technical Reference Manual.

3.1.1 CF ConfigurationCZ_ATP_REQUESTSCZ_CONFIG_HDRSCZ_CONFIG_INPUTSCZ_CONFIG_ITEMSCZ_CONFIG_MESSAGESCZ_CONFIG_USAGESCZ_PRICING_STRUCTURESCZ_TERMINATE_MSGS

3.1.2 GN General Use TablesCZ_DB_LOGSCZ_DB_SETTINGSCZ_DB_SIZES

3.1.3 IM Item-MasterCZ_ITEM_MASTERSCZ_ITEM_TYPESCZ_PROPERTIESCZ_ITEM_TYPE_PROPERTIESCZ_ITEM_PROPERTY_VALUESCZ_REL_TYPESCZ_ITEM_PARENTS

3.1.4 LC Logic for Configuration (Active Model)CZ_LCE_CLOBSCZ_LCE_HEADERSCZ_LCE_LINESCZ_LCE_OPERANDS

Characteristics of the Oracle Configurator Schema


CZ_LCE_TEXTS

3.1.5 PB PublicationCZ_EFFECTIVITY_SETSCZ_MODEL_PUBLICATIONSCZ_MODEL_USAGESCZ_PB_CLIENT_APPSCZ_PB_MODEL_EXPORTSCZ_PB_TEMP_IDSCZ_PUBLICATION_USAGES

3.1.6 PS Project StructureCZ_DEVL_PROJECTSCZ_PS_NODESCZ_FUNC_COMP_SPECSCZ_FUNC_COMP_REFSCZ_MODEL_REF_EXPLSCZ_PS_PROP_VALSCZ_PS_PROPCOMPAT_GENCZ_INTL_TEXTSCZ_RULESCZ_RULES_FOLDERSCZ_DES_CHART_CELLSCZ_DES_CHART_FEATURESCZ_POPULATORSCZ_POPULATOR_MAPS CZ_FILTER_SETSCZ_EXPRESSIONSCZ_EXPRESSION_NODESCZ_COMBO_FEATURESCZ_GRID_DEFSCZ_GRID_COLSCZ_GRID_CELLSCZ_SUB_CON_SETSCZ_POPULATOR_MAPS

3.1.7 RP RepositoryCZ_RP_ENTRIES

Oracle Configurator Schema Settings


CZ_SERVERS

3.1.8 UI User Interface (Active UI)CZ_UI_DEFSCZ_UI_NODESCZ_UI_PROPERTIESCZ_UI_NODE_PROPS

3.1.9 XF Transfer Specifications and ControlCZ_XFR_PROJECT_BILLSCZ_XFR_PRICE_LISTSCZ_XFR_TABLESCZ_XFR_FIELDSCZ_XFR_RUN_INFOSCZ_XFR_RUN_RESULTSCZ_XFR_STATUS_CODESCZ_XFR_FIELD_REQUIRES

3.2 Oracle Configurator Schema SettingsThe Oracle Configurator schema provides installation-wide customizable settings that describe the structure and the content of the Oracle Configurator schema, and also give parameters for certain application functions. These settings are stored in the CZ_DB_SETTINGS table.

A CZ_DB_SETTINGS table exists in every Oracle Configurator schema instance.

Using SQL*Plus or some concurrent programs, you can customize the values your installation requires by modifying the value fields in the CZ_DB_SETTINGS table.

The table section names (SECTION_NAME) in the CZ_DB_SETTINGS table are:

SCHEMAORAAPPS_INTEGRATEIMPORT

Table 3–1 briefly describes each of these settings. Each setting is grouped by table section and described in more detail in the sections following the table.



Table 3–1 CZ_DB_SETTINGS

Setting_ID Section_name Data_type Default Value Relevance and Contribution

BadItemPropertyValue IMPORT CHAR (1) F Indicates the action to be taken when an item’s PROPERTY _VALUE in the CZ_ITEM_PROPERTY_VALUES online table does not match the DATA_TYPE in the CZ_PROPERTIES online table. See Section 3.2.3, "CZ_DB_Settings for IMPORT" for more information about this setting.

Batchsize SCHEMA integer 10000 Indicates the number of records that are modified before committing a transaction in a batch operation.

BOM_REVISION ORAAPPS_INTEGRATE

any string Null Indicates the BOM revision in the Oracle Applications database from which data is being imported into the CZ schema.Valid values are "5.0.628 for Release 10.7, "11.0.28" for Release 11.0, and "11.5.0" for Release 11i.

CommitSize IMPORT integer 500 Indicates the number of import records in each database transaction at a time, between commits. It is recommended that you set this much larger than the expected number of records.

FREEZE_REVISION SCHEMA any string Revision number at the "freeze" stage. Version of the driver file used for the schema upgrade.

MAJOR_VERSION SCHEMA System setting System setting Indicates the major version label for the Oracle Configurator schema.

MaximumErrors IMPORT integer 10000 Default error limit for import runs before terminating the import.

MINOR_VERSION SCHEMA System setting System setting Indicates the minor version label for the Oracle Configurator schema.



MULTISESSION IMPORT integer 0 A positive value indicates the number of seconds to wait, checking for current state every second and waiting while another import runs. After this number of seconds has elapsed, control goes to the waiting import session if no other session is active, or an exception is raised if another import session is still running. A value of 0 means do not wait, and raise an exception immediately if another import session is already running. Any negative value means ignore other sessions and run immediately.

OracleSequenceIncr SCHEMA integer 20 An integer (default=20) that indicates the number of primary-key values allocated by each use of a sequence. The default means that keys are assigned in increments of 20.

PsNodeName ORAAPPS_INTEGRATE

‘Segment1’ (or Description)

Null Indicates the source field to be loaded into the Name field in the CZ_PS_NODES table. This is either the RefPartNbr or Description field in the MLT_SYSTEM_ITEMS table.

RefPartNbr ORAAPPS_INTEGRATE

‘Segment1’ (or Description)

Segment1 Identifies the field to be used for the name of an imported item in the CZ_ITEM_MASTERS and CZ_DEVL_PROJECTS tables. This is a segment from the System Item flexfield.





3.2.1 CZ_DB_SETTINGS for SCHEMAThe settings in the SCHEMA section control general parameters of the whole Oracle Configurator schema.

BatchSize is an integer (default=10000) that indicates the number of records that are modified before committing a transaction in a batch operation.

BatchSize is provided for batch operations such as import and logic generation and is represented in units of database records inserted, updated, or deleted. Ordinarily a database stored procedure runs as a single transaction which is considered pending until the calling operation commits the transaction. The pending changes are lined up in a "rollback segment" and if the calling operation cancels or ’rolls back’ the transaction, or if there is an error, they are discarded. However, some batch operations, such as import, can involve hundreds, thousands, or more records which may be too big for the database to handle as a single transaction. If the transaction is too big, the database will fail an operation with a rollback-segment error. To avoid this, import and other batch-like operations count up the records they modify in the database. Whenever the count matches ’batchsize’ the operation

ResolvePropertyDataType ORAAPPS_INTEGRATE

YES/NO NO Indicates whether Catalog Descriptive Elements are imported as Properties with a string or a number data_type. If the value for this setting is ’NO’, all Catalog Descriptive Elements are imported as Properties with a string data_type. If the value of this setting is ’YES’, a Catalog Descriptive Element is imported as a Property with a number data_type only if all of its imported values can be interpreted as numbers, otherwise it is imported as a Property with a string data_type.

Revision Date/User SCHEMA any string Timestamp of the creation or upgrade date plus the username of the user that performed the task.

RUN_BILL_EXPLODER ORAAPPS_INTEGRATE

YES/NO YES Indicates whether or not the import process invokes the BOM_EXPLODER procedure. This explodes the BOMs before the import process extracts data.





commits the transaction and resets the counter. Every record is not committed because it is considerably more economical to commit many updates at once.

FREEZE_REVISION is the revision number at the "freeze" stage. Version of the driver file used for the schema upgrade.

MAJOR_VERSION is the major version label for the Oracle Configurator schema.

MINOR_VERSION is the minor version label for the Oracle Configurator schema.

OracleSequenceIncr is an integer (default=20) that indicates the number of primary-key values allocated by each use of a sequence. The default of 20 means that keys are assigned in increments of 20.

See Section 3.4.3, "Redo Sequences" on page 3-13 for more information about the use of this setting.

Revision Date/User is a timestamp of the creation or upgrade date plus the username of the user that performed the task.

3.2.2 CZ_DB_SETTINGS for ORAAPPS_INTEGRATEThe settings in the ORAAPPS_INTEGRATE section control how and what data gets imported to the Oracle Configurator schema.

BOM_REVISION indicates the version in the Oracle Applications database from which BOM data is being imported. The date format used for Oracle Applications Releases 10.7 or 11.0 is "DD/MON/RR" and Release 11i uses a "YYYY-MM-DD" format. This setting is checked to ensure that the correct date format is used in the call to the BOM explosion procedure. Valid values are "5.0.628" for Release 10.7, "11.0.28" for Release 11.0, and "11.5.0" for Release 11i. If null, "11.5.0" is used.

PsNodeName is the field name (default=‘Segment1’) that indicates the source field to be loaded into the Name field in the CZ_PS_NODES (project or model structure) table in the Oracle Configurator schema. 'Segment1' is used by default so that the name loaded into the model structure in Oracle Configurator Developer will match the names in CZ_ITEM_MASTERS.

RefPartNbr is the field name (default=‘Segment1’) that indicates the source field to be loaded from the BOM_EXPLOSIONS table into Ref_Part_Nbr in CZ_ITEM_MASTERS in the Oracle Configurator schema. 'Segment1' is the usual field that contains the name for an item, so this is the default for retrieving the name to be displayed in the Item Master in Oracle Configurator Developer. To display the actual part numbers of items in the Item Master, set RefPartNbr to the name of the field populated with part numbers.



ResolvePropertyDataType is a YES/NO flag (default=NO) that indicates whether the Catalog Descriptive Elements are imported as Properties with a string or a number data_type. If the value for this setting is ’NO’, all Catalog Descriptive Elements are imported as Properties with a string data_type. If the value of this setting is ’YES’, a Catalog Descriptive Element is imported as a Property with a number data_type only if all of its imported values can be interpreted as numbers, otherwise it is imported as a Property with a string data_type.

RUN_BILL_EXPLODER is a YES/NO flag (default=NO) that indicates whether the Oracle Applications Bills of Material exploder should be run on each bill that is marked for transfer or import in the CZ_XFR_PROJECT_BILLS table in the Oracle Configurator schema at the time of data transfer or import.

The OC concurrent programs load bills and items based on top bills listed in the CZ_XFR_PROJECT_BILLS table in the Oracle Configurator schema. Before extracting, if this RUN_BILL_EXPLODER setting is set to YES, the procedure calls the BOM exploder to refresh data in BOM_EXPLOSIONS for each record in the CZ_XFR_PROJECT_BILLS table. If RUN_BILL_EXPLODER is set to NO, the concurrent programs or import scripts will transfer the BOMs that are flagged for import in the CZ_XFR_PROJECT_BILLS table without running the BOM exploder first.

3.2.3 CZ_DB_Settings for IMPORTThe settings in the IMPORT section are for controlling how the import executes.

BadItemPropertyValue is a string (default ’F’) that indicates the action to be taken when an item’s PROPERTY _VALUE in the CZ_IMP_ITEM_PROP_VALUES table does not match the DATA_TYPE in the CZ_PROPERTIES online table so it can be transferred or imported into the CZ_ITEM_PROPERTY_VALUES online table. The valid values for this setting are:

Value Disposition

’R’ Reject the record in the import table and use the old PROPERTY_VALUE

’F’ Force the record to be updated to include the PROPERTY_VALUE from the import table

’K’ Update all information in the record except the item PROPERTY_VALUE

Editing the CZ_DB_SETTINGS Values


CommitSize is an integer (default=‘500') that indicates the number of import records to be operated on at a time, between commits.

MaximumErrors is an integer (default=‘10000') that indicates the default error limit for import runs before terminating. If you have a large amount of data to import or you are not concerned with the process stopping once a certain number of errors is reached, set this to an extremely large number.

MULTISESSION is an integer (default=‘0') that indicates the number of seconds to wait for another import session to complete if another import is running. A positive value indicates the number of seconds to wait, checking for current state every second and waiting while another import runs. After this number of seconds has elapsed, control goes to the waiting import session if no other session is active, or an exception is raised if another import session is still running. A value of 0 means do not wait, and raise an exception immediately if another import session is already running. When MULTISESSION is missing from the CZ_DB_SETTINGS table, it is as if it were set to the default, 0.

Any negative value means ignore other sessions and run immediately. Setting this parameter to a negative number is equivalent to disabling it.

If an import session is terminated, the CZ_XFR_RUN_INFOS table may end up in an inconsistent state with the value of COMPLETED not ’1’. If then MULTISESSION is not disabled, a new import session cannot run.

See Section 4.10.4.1, "Setup for a Custom Import" on page 4-26 for more detailed information about all CZ_DB_SETTINGS that apply to custom import.

3.3 Editing the CZ_DB_SETTINGS Values

Before running a concurrent process request to import BOM model data into the Oracle Configurator schema, you can customize how that data will be extracted and involved in the import. You do this by running a concurrent process to edit the values in the CZ_DB_SETTINGS table.

When you run the Oracle Configurator concurrent processes, you are prompted to enter the required parameters, if any. Once you complete the entry of these

’X’ Reject the record and logically delete any matching item property value record in the CZ_ITEM_PROPERTY_VALUES table. This makes the item property value default to the property default value in the CZ_ITEM_PROPERTY_VALUES table

Value Disposition

Editing the CZ_DB_SETTINGS Values


parameters, they are automatically added to the Oracle Applications Submit Request form.

Table 3–2, "Oracle Configurator Administration Concurrent Programs" describes the Oracle Configurator administrative concurrent programs.

3.3.1 Modify Configurator ParametersUse the following procedure to modify configurator parameters:


2. Select Configurator > Configurator Administration > Modify Configurator Parameters.

3. A Parameters form prompts you to input the parameters required by the concurrent process. Enter the parameters as described in Table 3–2, "Oracle Configurator Administration Concurrent Programs".

4. Click OK.

Table 3–2 Oracle Configurator Administration Concurrent Programs


Modify Configurator Parameters

Sets values for the settings in the CZ_DB_SETTINGS table in the Oracle Configurator schema.

Section Name - from the list of values, select the name of the section in the Oracle Configurator cz_db_settings table where the setting resides.

Setting - from the list of values, select the setting in the Oracle Configurator cz_db_settings table you want to modify.

Type - from the list of values, select the data type ( 1= number or 2= string) of the setting you are modifying.

Value - enter the value to set the setting to. See Table 3–1, "CZ_DB_SETTINGS", on page 3-5 for valid values for these settings.

Description - enter a brief description for this value selection.

View Configurator Parameters

Writes the values of the specified Oracle Configurator schema settings to the concurrent process log.

Section Name - from the list of values, select the name of the section in the Oracle Configurator cz_db_settings table where the setting resides.

Setting - from the list of values, select the setting in the Oracle Configurator cz_db_settings table.

Oracle Configurator Schema Maintenance


3.3.2 View Configurator ParametersUse the following procedure to view configurator parameters:

1. Log into Oracle Applications under either the Configurator Administrator or Configurator Developer responsibility.

2. Select Configurator > Configurator Administration > View Configurator Parameters.

3. In the Parameters form, enter the Section Name and Setting of a specific parameter setting or the % wildcard to query all parameters.

4. Click OK.

5. Click Submit.

The output containing the current settings of the Section Name and Setting you specified are recorded in a log file.

6. To view the output log file, first view your requests as described in Section 1.8.1.2, "View the Status of Oracle Configurator Concurrent Process Requests" on page 1-16.

7. On the Requests form, verify that this request has completed successfully then click in the space to the left of the Request ID to select this request.

8. Click View Log.

3.4 Oracle Configurator Schema Maintenance You maintain the Oracle Configurator Schema by:

■ maintaining data integrity rules and refreshing the schema with updated data (see "Refresh or Update the Production Schema" on page 3-12)

■ eliminating unused data (see "PURGE" on page 3-13)

■ refresh sequences when updating from one Oracle Configurator Schema to another (see "Redo Sequences" on page 3-13)

3.4.1 Refresh or Update the Production SchemaOnce an Oracle runtime configurator has been deployed, data is stored in the Oracle Configurator schema directly through networked use. During deployment, further imports are done to refresh the Oracle Configurator schema as Oracle Applications or legacy data change. The procedures that perform the import prevent



customer-specific groups of fields in the Oracle Configurator schema from being altered or nulled out even when other fields in the row are replaced during an import session.

For additional information about refreshing data in your Oracle Configurator schema, see "Refresh and Update Imported Data" on page 4-16.

3.4.2 PURGEOracle Configurator provides a concurrent process, called Purge Configurator Tables, that purges all of the Oracle Configurator tables in the CZ schema. When you run this concurrent process you can optionally delete information from the CZ_DB_LOGS and CZ_XFR_RUN_RESULTS tables based on the date or run identifier.

The Purge Configurator Tables concurrent process physically deletes all logically-deleted records in the tables and subschemas. In some cases this process will propagate deletions to additional records not marked as deleted, in the same or different tables. For example, the Purge Configurator Tables concurrent process will physically delete children of a logically-deleted PS_NODE record. It will also delete all EXPRESSION_NODE records attached to a deleted EXPRESSION. In other cases, it will not physically delete a logically-deleted record owing to a non-deleted reference to that record; for example, a rule referring to a deleted PS_NODE will prevent the concurrent process from physically deleting the PS_NODE.

Each table has delete-propagation rules describing these characteristics.

When databases get large and performance slows down, submit a request to run the Purge Configurator Tables concurrent process to remove all logically-deleted items.

To submit a request to run the Purge Configurator Tables concurrent process:


2. Select Configurator > Configurator Administration > Purge Configurator Tables.

There are no parameters required for this concurrent process.

3.4.3 Redo SequencesIf updating from one Oracle Configurator Schema to another or restoring a schema from a dump file, you should refresh sequences. REDO_SEQUENCES is invoked by the packages CZ_MANAGER.sql and CZ_subschema_MGR.sql (for example, CZ_PS_MGR.sql).



Depending on the argument given, REDO_SEQUENCES alters or recreates the sequence objects in the database that are used to allocate primary keys for tables in the subschema. The procedure checks the high primary-key value currently in the database and sets a new start value that is higher. It uses the default incremental value specified by ‘OracleSequenceIncr' in the CZ_DB_SETTINGS table unless you specify a new increment. When running the CZ_MANAGER package, the optional new increment argument does not change the default increment in CZ_DB_SETTINGS. To change the default increment, you must change the value of ’OracleSequenceIncr’ in the CZ_DB_SETTINGS table.

For example: CZ_MANAGER.REDO_SEQUENCES (’0’, ’5’) alters the existing sequence by the specified increment of five. CZ_MANAGER.REDO_SEQUENCES (’1’,’15’) drops the existing sequence and creates a new sequence starting with the high primary-key value currently in the database and increments it by 15 for the new start value. If a new increment value was not specified in either case, the value of ’Oracle SequenceIncr’ in the CZ_DB_SETTINGS table would be used.

Importing Data 4-1

4Importing Data

You import data into the Oracle Configurator schema to leverage already existing data and use this data as a baseline to define configuration models in Oracle Configurator Developer and maintain consistency between configuration models and the downstream manufacturing process.

4.1 Data Import OverviewYou can import data from the following sources:

■ Oracle Applications, Release 10.7, 11.0, or 11i tables.

■ A non-Oracle Applications database.

It is possible to use a combination of import sources to define a configuration model and achieve the results you need in a run-time configurator.

Importing data from other Oracle Applications (Release 10.7, 11.0, or 11i) schemas into the Oracle Configurator schema is accomplished by running a concurrent process in Oracle Applications.The concurrent process performs a data extraction into the correct format for transfer, loads the data into the import tables, and populates the online Oracle Configurator schema with imported data from the import tables. In other words, copies of BOM and Item Master data are imported into the Oracle Configurator schema (CZ tables) from tables in the Oracle Applications database that are used by the applications that integrate with Oracle Configurator. See "Data Import Concurrent Processes" on page 4-12.

Importing data from non-Oracle Applications databases is accomplished through a custom import by creating custom extraction and load programs to populate the import tables and running a concurrent process to import the data. See "Creating a Custom Import" on page 4-25 for detailed information.

Data Import Overview


Regardless of which source you use to import data to the Oracle Configurator schema, you will need to occasionally refresh the schema with changes and updates for enterprise-wide consistency. Configuration models in the run-time Oracle Configurator maintain all relationships associated with the refreshed data to minimize model maintenance as data is updated.

Figure 4–1 Overview of Data Import

As you can see in Figure 4–1, the data import process uses import tables in the Oracle Configurator schema to populate online tables with the extracted data used by the run-time Oracle Configurator. The import tables mirror the Oracle Configurator schema Item Master structure, without integrity constraints. The import tables are used in conjunction with extractions from Oracle Applications or legacy data to create, update, or delete records in the Oracle Configurator schema Item Master. Online tables contain the data used by the run-time Oracle Configurator. Every online table that receives imported data is matched by an import table that is equivalent to that table both structurally and relationally.

When importing data from a non-Oracle Applications database, the data must be extracted in a compatible format and custom loaded into the import tables (Custom Import in Figure 4–1). Exactly which extracted data is imported depends on the


Importing Data 4-3

settings in the control tables (CZ_XFR_ tables in the Oracle Configurator schema) or the custom load program, if applicable. The import concurrent process is then run to populate the online tables with the extracted data used by the run-time Oracle Configurator. See "Customizing Data Import" on page 4-23 for information about customizing import.

The Oracle Applications concurrent processes do not provide an automated or scheduled mechanism that clears the import tables.

4.1.1 Import TablesThe import tables represent a "mirror" of the online tables in the Oracle Configurator schema. Every online table that receives imported data is matched by an import table that is equivalent to that table both structurally and relationally. Each import table is named exactly as its online counterpart, but is named with the prefix CZ_IMP_ rather than simply CZ_. For example, the imported data in CZ_IMP_PROPERTIES populate CZ_PROPERTIES. In an import table, all fields are nullable and no data constraints are applied to any field.

Each import table contains the same fields that exist in the online table, plus additional fields used specifically for the import process. Import tables consist of fields for:

■ Import Control

■ Online Data

■ Surrogate Keys

4.1.1.1 Import Control FieldsImport control fields contain data that is used only to manage the import process for each record. Import control data is not transferred to the online tables and is not used to resolve key values or anything else. The import control fields are:

Table 4–1 Import Control Fields

Field Name Type Description

RUN_ID INTEGER Input field that identifies with which run this record is associated

REC_NBR INTEGER Input field that is a one-up sequence number uniquely identifying each record within a RUN_ID



4.1.1.2 Online Data FieldsOnline Data Fields exactly match the fields in the corresponding online table and are used to hold the literal data to be put into the online table.

4.1.1.3 Surrogate Key FieldsSurrogate key fields are fields in the import tables that hold the customer-provided extrinsic identifications for data to be imported. These include both surrogate primary keys and foreign surrogate keys. A foreign surrogate key is a reference to a different table made through that table’s surrogate primary key rather than through the online table’s integer key value.

Surrogate Primary Key – as a rule, imported tables contain a single field named ORIG_SYS_REF which is used to hold the external value that uniquely identifies each record. In some cases, however, the online CZ table has a primary key consisting entirely of references to other tables. In this case, the surrogate primary key will actually consist of the foreign surrogate keys that correspond to the native foreign keys in the online table.

Foreign Surrogate Keys – one or more fields used to resolve references from one import table to another. These keys are named FSK_table_refno_fldnum, where table is the name of the referenced table, refno is the number of the table-to-table reference, and fldnum is the position of the referenced surrogate-key field in the

REC_STATUS VARCHAR(4) Output field which is the validation status of the record. Null indicates the record status is open. Once this status is set, further processing of the record is suppressed. A REC_STATUS of "OK" indicates that the data in this record now exist in the online database table

DISPOSITION CHAR(1) Output field that indicates the disposition of the record after an import:

I = InsertM = ModifyN = No changeR = Rejected

Null indicates not yet known

Table 4–1 Import Control Fields

Field Name Type Description


Importing Data 4-5

referenced import table. Note that refno is required to keep unique names for tables with multiple references to the same table, and generally, the fldnum is ‘1.’

4.1.2 Control Tables (CZ_XFR_)The import process is controlled by a set of tables (CZ_XFR_ tables) with data records that determine what and how data is imported. They also determine which import tables are enabled for import.

There are three tables that control the import process at the table and field level; CZ_XFR_TABLES, CZ_XFR_FIELDS, and CZ_XFR_PROJECT_BILLS. CZ_XFR_TABLES identifies the import table to online table transfer that is to be performed during import.

Table 4–2 CZ_XFR_TABLES Fields

Field Name Required Type Description

XFR_GROUP YES VARCHAR(20)

Used to name and group sequences of imports, such as "EXTRACT", "IMPORT", "GENERIC".

ORDER_SEQ YES NUMBER Indicates the order in which this table should be imported. It also serves as an identifier for defining a transfer of data from one import table to one online table.

SRC_TABLE NO VARCHAR(30)

Identifies the name of the source table in the import subschema.

DST_TABLE NO VARCHAR(30)

Contains the name of the destination online table.

DST_SUBSCHEMA NO INTEGER Identifies the subschema in which the destination online tables resides.

FILTERSYNTAX NO VARCHAR(255)

Limits the records imported from the given src_table.

PK_USEEXPANSION NO CHAR(1) If "Y", the surrogate primary key is passed through the expansion field user_str03 rather than through the ’natural’ surrogate primary key (for example, name, ref_part_nbr).



CZ_XFR_FIELDS identifies transfer rules for fields transferred during the import process. It primarily specifies overrides to normal rules; if a field is transferred for which no entry exists in CZ_XFR_FIELDS, the default is applied.

DISABLED NO CHAR(1) If "1", there is no transfer of data. For XFR_TABLE entries with XFR_GROUP = "EXTRACT", the extraction utility will not load data into the import tables. When XFR_GROUP = "IMPORT" or "GENERIC", any data in the import table is ignored.

Table 4–3 CZ_XFR_FIELDS Fields


XFR_GROUP YES VARCHAR(20)

Used to name and group sequences of imports, such as ’EXTRACT’, ’IMPORT’.

ORDER_SEQ YES NUMBER With XFR_GROUP, identifies the distinct table import to which this record applies.

FIELD_ORDER YES NUMBER Distinguishes the order of the field imported.

SRC_FIELD NO VARCHAR2(40)

Name of the originating field.

DST_FIELD NO VARCHAR2(40)

Name of the destination field.

REQUIRED NO CHAR(1) If "1", this field is required by the online table.

DEFAULTSYNTAX NO VARCHAR2(255)

Not currently supported. Future use is to establish default value when null.

NOUPDATE NO CHAR(1) If "1", this field is not to be modified when an existing online record is matched.

Table 4–2 CZ_XFR_TABLES Fields



Importing Data 4-7

Each entry in the CZ_XFR_PROJECT_BILLS table identifies a top-level item from a bill of material in Oracle Applications for import into the Oracle Configurator schema. Every imported bill must be represented in CZ_XFR_PROJECT_BILLS..

Table 4–4 CZ_XFR_PROJECT_BILLS Fields


ORGANIZATION_ID YES NUMBER Identifies the organization ID that identifies this item in Oracle Applications.

COMPONENT_ITEM_ID

NO NUMBER Provides the item ID that identifies this item in Oracle Applications.

DESCRIPTION NO VARCHAR2(255)

Most recent description of this item.

LAST_IMPORT_RUN_ID

NO NUMBER Identifies the import run in which this bill was last imported.

LAST_IMPORT_DATE NO DATE Gives the date and time for when this bill was last imported.

SOURCE_BILL_DELETED

NO CHAR(1) If ’1’, Indicates that this bill has been deleted from Oracle Applications; if ’0’, it is still active.

TOP_ITEM_ID YES NUMBER Contains the item ID that identifies this top-level item in this bill.

DELETED_FLAG YES CHAR(1) If ’1’, this flag logically deletes (disables) this bill from being imported; if ‘0’, it is still active.



Both the Oracle Configurator SQL*Plus scripts and the concurrent processes use the CZ_XFR_ control tables information in the Oracle Configurator schema. The TOP_

EXPLOSION_TYPE NO (by default)

VARCHAR2(10)

Determines how the BOM exploder handles standard items. If this is set to OPTIONAL (recommended), optional standard items are included in the explosion of the BOM, but included items are not. (Since the count of an included item cannot be modified, it usually does not make sense to include it in a configuration.) If this is set to ALL, both included items and optional standard items are included in the BOM explosion. If this is set to INCLUDED, only included items are included in the BOM explosion.

BILL_REVISION_DATE NO DATE Describes when the source data for this bill in Oracle Applications was last modified.

SOURCE_SERVER Number The server instance that is the source of this field.

EFF_FROM DATE Bill effective from date as defined in Oracle Applications Bills of Material.

EFF_TO DATE Bill effective to date as defined in Oracle Applications Bills of Material.

COPY_ADDL_CHILD_MODELS

VARCHAR2 Indicates whether or not child models should be copied when creating a copy of a model. Default=Yes.

MODEL_PS_NODE_ID NUMBER Model structure node identifier for the model in the CZ schema.

Table 4–4 CZ_XFR_PROJECT_BILLS Fields


The Import Process

Importing Data 4-9

ITEM_ID and ORGANIZATION_ID for each bill of material to be imported from the Oracle Applications database are read from the CZ_XFR_PROJECT_BILLS table. The PS_NODE import updates the CZ_XFR_PROJECT_BILLS table with the timestamp, ID, and description of the most recent import.

CZ_DB_SETTINGS defines which fields from MTL_SYSTEM_ITEMS populates the REF_PART_NBR. Likewise, CZ_XFR_FIELDS defines field-specific controls. For example, NOUPDATE set to "1" for CZ_ITEM_MASTERS.DESC_TEXT would inhibit the synchronization of the Item Master description.

The ORGANIZATION_ID also identifies which BOMs are imported. Oracle Configurator uses the ORGANIZATION_ID when adding a configured line item in Order Management. An order line is only valid with the ORGANIZATION_ID that corresponds to the ORGANIZATION_ID on items of the BOM in Oracle Applications.

CZ_INTL_TEXTS contains the text string from the DESCRIPTION field in the BOM_EXPLOSIONS table for each imported Bill model structure node.

The Oracle Configurator SQL*Plus scripts and concurrent processes target all or a subset of BOMs exploded in the BOM_EXPLOSIONS table in the Oracle Applications database. Selected BOM Items come from the BOM_BILL-OF-MATERIAL and the BOM_INVENTORY_COMPONENTS tables.

4.2 The Import ProcessBOM structure (ATO/PTO BOM Models or ATO/PTO structure and rules) is imported and used in Oracle Configurator Developer at the Model level. BOMs must be complete and identified at the desired root. When BOMs for an ATO or PTO model are imported, Oracle Configurator Developer creates a Model structure. If the imported BOM has components that are ATO models, the import process creates a Model structure for each ATO component and a corresponding reference node in the parent Model structure. Imported BOM models are read-only in Oracle Configurator Developer; although you can add properties, additional structure, and rules for defining your configuration model.

The Oracle Applications tables from which data can be imported are:

Data Imported into the Oracle Configurator Schema


Each Bill corresponds to a Model record inserted in the CZ_DEVL_PROJECTS table. The concurrent program inserts the root Model and hierarchy of each bill in the CZ_PS_NODES table.

The Oracle Configurator schema requires complete BOMs. No partial BOMs or subassemblies can be imported. That means, you must identify the TOP_ITEM_ID for the BOM you want to import from Oracle Applications. The BOM structure is imported at the Model level in the run-time Oracle Configurator. The Oracle Configurator Developer Model name is defaulted from the BOM model name so that it is preserved for use by downstream applications such as Order Management.

4.3 Data Imported into the Oracle Configurator SchemaBOM hierarchy and inventory data can be imported into the Oracle Configurator schema only from other Oracle Applications tables (Release 11i, 10.7, or 11.0) such as the BOM_EXPLOSIONS table. Importing from other Oracle Applications tables enables you to populate the Oracle Configurator schema with the following data:

■ Bills of Material (BOM) structure (ATO/PTO models and structure rules)

■ Inventory data (populates the Oracle Configurator Developer Item Master)

The following types of implicit rules are included in the imported ATO/PTO BOM:

■ optional/required,

■ minimum/maximum,

■ mutually exclusive, and

Table 4–5 Oracle Applications Source and Destination Online Tables

Oracle Applications SourceTable -->

Oracle Configurator Schema Destination Online Table(s)

BOM_EXPLOSIONS --> CZ_PS_NODES, CZ_DEVL_PROJECTS, CZ_INTL_TEXTS

MTL_SYSTEM_ITEMS --> CZ_ITEM_MASTERS

MTL_DESCRIPTIVE_ELEMENTS

--> CZ_PROPERTIES

MTL_ITEM_CATALOG_GROUPS

--> CZ_ITEM_TYPES

MTL_DESCR_ELEMENT_VALUES

--> CZ_ITEM_PROPERTY_VALUES

Data Import Setup

Importing Data 4-11

■ quantity cascade

Properties from Oracle Inventory item catalogs such as descriptive elements and values can also be imported and used in Oracle Configurator Developer.

Each descriptive element is imported as a property name and associated with the corresponding Item type that is imported from the catalog group.

Imported items associated with the Item type contain the associated descriptive element value as a property value.

All descriptive element values are imported into Oracle Configurator Developer as text by default. The CZ_DB_SETTINGS table contains a setting, called ResolvePropertyDataType, to allow for correct data type importing.

See "Creating a Custom Import" on page 4-25 for information about data imported using a custom import.

4.4 Data Import SetupImport setup consists of:

■ making sure that data to be imported is clean, and in the case of BOMs, complete and identified at the desired root

■ defining, enabling, and modifying servers used for import. See Section 1.8.1.1, "Server Administration" on page 1-12 for detailed information about defining or enabling a server for import.

■ identifying or customizing what data gets imported. To do this you run concurrent processes to set the values in the CZ_XFR_ control tables in the Oracle Configurator schema that control import. See "Importing from Oracle Bills of Material" on page 4-13 for information about identifying what gets imported. See "Customizing Data Import" on page 4-23 for information about customizing what gets imported.

Table 4–6 Properties Imported from Oracle Inventory

The following in Oracle Inventory...correspond to the following in Oracle Configurator Developer

Item catalog group Item type

Catalog descriptive element Item property

Catalog descriptive element value Property value

Importing Data From Oracle Applications


4.5 Importing Data From Oracle ApplicationsOracle Configurator integrates with Bills of Material and Inventory in Oracle Applications Release 11i, 10.7 or 11.0. BOM models and their associated data are imported from an Oracle Applications database into the Oracle Configurator schema for use by Oracle Configurator Developer to create Model structure, Oracle Configurator rules, and User Interface layouts for the definition of a run-time configuration model.

You can import data from Oracle Applications, Release 11i, 10.7 or 11.0, into the Release 11i Oracle Configurator schema to create configuration models to be used by a calling application. However, when importing from Release 10.7 or 11.0, you must install the complete Oracle Applications, Release 11i database and the calling application must be registered on both the development and production servers using the same application identifier.

Importing data from Oracle Applications schemas into the Oracle Configurator schema, Release 11i is accomplished by running concurrent processes in Oracle Applications. The concurrent processes import BOM and Item Master data into the Oracle Configurator schema (CZ tables). To do this, they perform the extraction into the correct format for import, load the data into the import tables according to the set up, and populate the online Oracle Configurator schema with imported data from the import tables.

4.6 Data Import Concurrent Processes

If you want to build configuration models based on BOM models from Oracle Applications Release 11i, you can run a series of concurrent processes provided in Oracle Applications under the Configurator Developer responsibility to import BOM and Item Master data from the Bills of Material schema to the Oracle Configurator schema. The Oracle Configurator Developer uses this data to define a configuration model.

Figure 4–2 Overview of Data Import from Oracle Bills of Material

Data Import Concurrent Processes

Importing Data 4-13

The following concurrent processes enable you to import BOM models from the Bills of Material schema to the Oracle Configurator schema or to disable or enable the refresh of previously imported BOM model data in the Oracle Configurator schema:

■ Import Model Bills

■ Disable/Enable Refresh of a Configuration Model

When you run these Oracle Configurator concurrent processes, you are prompted to enter the required parameters, if any. Once you complete the entry of these parameters, they are automatically added to the concurrent Requests form.

You can import data for a single BOM model or for many BOM models at once. In order to import data, these import parameters must be specified.

See "Concurrent Programs" on page 1-3 for a complete list of other concurrent processes available for other Oracle Configurator implementation tasks.

4.6.1 Importing from Oracle Bills of MaterialIf you are importing from Bills of Material (Releases 10.7, 11.0 or 11i) you must:

1. Define and enable the source server for import (see "Enabling a Server for Import" on page 4-14)

2. If not importing from your local server, you must explode the BOM models you want to import (see "Exploding BOMs in Oracle Applications" on page 4-14)



3. Run the import concurrent process (see "Running the Import Concurrent Process" on page 4-15)

4.6.1.1 Enabling a Server for ImportIf you are importing from Bills of Material (Releases 10.7, 11.0 or 11i) or a separate instance of Oracle Configurator (Release 11i), you must first define and enable for import the server on which your source Oracle Applications database resides. See "Server Administration" on page 1-12. The local server is the default server for import. Therefore, if you need to define and enable a remote server for import, you must first submit a Modify Server Definition concurrent request to disable the local server for import then define and enable the remote server where the source database resides. If you do not specifically enable a server for import, the local server is used as the source destination.

4.6.1.2 Exploding BOMs in Oracle ApplicationsIf you are importing from Bills of Material (Releases 10.7, 11.0 or 11i) or just a separate instance, you must explode the BOM model in Oracle Applications prior to submitting the concurrent request to import the BOM models into the Oracle Configurator schema.

4.6.1.2.1 Exploding a BOM in Oracle Applications, Release 11i

To explode a BOM model in Oracle Applications, Release 11i:

1. Log into Oracle Applications using the username/password Operations/Welcome.

2. Select the Order Management responsibility.

3. Select Orders, Returns.

4. Select Sales Order Pad.

5. Click on the Main tab and enter all required fields.

6. Click on the Line Items tab.

7. Select the Ordered Item that you want to import into Oracle Configurator from the Ordered Items list of values. This is exactly the same model that you will select from the list of values when you run the Oracle Configurator Import BOM Models concurrent process.

8. Enter "1" in the Qty field.

9. Click Configurator.


Importing Data 4-15

10. After all the BOM model’s components are displayed, cancel out of the Configurator window.

11. Repeat steps 1 through 10 for each BOM model that you want to import into Oracle Configurator.

12. Run the Import Model Bills concurrent process (see "Running the Import Concurrent Process" on page 4-15).

4.6.1.2.2 Exploding a BOM in Oracle Applications, Release 10.7 or 11.0

To explode a BOM model in Oracle Applications, Release 10.7 or 11.0:

1. Log into Oracle Applications using the username/password Operations/Welcome.

2. Select the Order Entry responsibility.

3. In the Sales Orders window, enter all required fields.

4. On the Order Line, select the model that you want to import into Oracle Configurator from the Item list of values. This is exactly the same model that you will select from the list of values when you run the Oracle Configurator Import BOM Models concurrent process.

5. Enter "1" in the Qty field.

6. Click Configurator.

7. After all the BOM model’s components are displayed, cancel out of the Configurator window.

8. Repeat steps 1 through 7 for each BOM model that you want to import into Oracle Configurator.

9. Run the Import Model Bills concurrent process (see "Running the Import Concurrent Process" on page 4-15).

4.6.1.3 Running the Import Concurrent ProcessUse the following procedure to import the BOM models you want to use from the Bills of Material schema into the Oracle Configurator schema:


2. Select Configurator > Import/Refresh Models > Import Model Bills.

Verify Data Import


3. From the list of values, select the Organization Code for the inventory organization to which the BOM models being imported belong.

4. From the list of values in the Model Inventory Item From parameter, select the

first model inventory item in the range of items for which you want to import data.

Note: All model inventory items between and including the first and last specified in this and the next field, are included in the data import. The range can include multiple types of Model Inventory Items. For example, from ATO800 to CNO500 is a valid range.

5. From the list of values in the Model Inventory Item To parameter, select the last model inventory item in the range of items for which you want to import data. If you want to import only a single model, do not specify this parameter.

6. Click OK.

4.7 Verify Data ImportOnce you have imported your data into the Oracle Configurator schema, start Oracle Configurator Developer to view the Item Master and Model(s) containing the imported data. All Items imported into the Oracle Configurator schema are displayed in the Oracle Configurator Developer Item Master. Items imported into the Oracle Configurator schema Item Master are read/write. Any modifications to the Oracle Configurator schema Item Master (except Property additions and item type assignments) are overwritten with values from the Oracle Applications database when data is refreshed with another import unless the CZ_XFR_ table record for that item type is flagged ‘DELETED’ to suppress the refresh.

4.8 Refresh and Update Imported DataOracle recommends that changes to source data be limited during construction of a Oracle Configurator Model to avoid potential problems introduced by interim data imports and updates. Oracle suggests that unit testing be completed before you import changes from Oracle Applications or legacy data, so that the test cases are up-to-date with the application that has been constructed. Your model’s full application testing should include importing changed data and upgrading the application to match current enterprise or legacy data before deploying the run-time Oracle Configurator. Test cases may have to be updated to match the changes.

Refresh and Update Imported Data

Importing Data 4-17

Although updating imported data in the Oracle Configurator schema randomly during a development phase is not recommended, Oracle recognizes that project managers may need to synchronize with Oracle Applications data frequently. Refreshes and updates require careful control of what data gets imported. Likewise, corrections to the definitions of the configuration model in the run-time Oracle Configurator should be carefully controlled. In many cases, a refresh causes deletion of previously imported data. For example, if components are deleted from a BOM Model, they will be deleted from the Oracle Configurator Model during the next refresh. Oracle Configurator provides a concurrent process, call Disable/Enable Refresh of a Configuration Model, which disables or enables specific configuration models so that you can reduce the number of models affected by a refresh. Oracle Configurator provides a concurrent process, called Refresh a Single Configuration Model, which updates one currently existing configuration model in the Oracle Configurator schema with changes that may have been made in the BOM model.

Import refreshes data on the development schema only. Once a run-time Oracle Configurator has been deployed, data is moved to the production Oracle Configurator schema through the publishing process. During deployment, further imports and publications are done to refresh and update the Oracle Configurator schema as source data changes. The procedures that perform the import prevent customer-specific groups of fields in the Oracle Configurator schema from being altered or nulled out even when other fields in the row are replaced during an import session.

Oracle Configurator provides a concurrent process, called Refresh All Imported Configuration Models, which updates all configuration models in a production Oracle Configurator schema with changes made in a development Oracle Configurator schema. The concurrent process ensures that existing production data, such as saved configuration data, is preserved.

The Refresh All Imported Configuration Models concurrent process refreshes the following tables.

Tables RefreshedCZ_COMBO_FEATURES CZ_DES_CHART_CELLSCZ_DEVL_PROJECTS CZ_EXPRESSIONSCZ_EXPRESSION_NODESCZ_FILTER_SETSCZ_FUNC_COMP_SPECSCZ_GRID_CELLS



CZ_GRID_COLS CZ_GRID_DEFS CZ_INTL_TEXTSCZ_ITEM_MASTERSCZ_ITEM_TYPE_PROPERTIESCZ_ITEM_PROPERTY_VALUESCZ_ITEM_TYPESCZ_LCE_HEADERSCZ_LCE_TEXTSCZ_POPULATORS CZ_POPULATOR_MAPS CZ_PROPERTIESCZ_PS_NODESCZ_PS_PROP_VALSCZ_REL_TYPESCZ_RULESCZ_RULES_FOLDERSCZ_SUB_CON_SETS CZ_UI_DEFSCZ_UI_NODESCZ_UI_PROPERTIESCZ_UI_NODE_PROPS

.

If you are refreshing configuration models based on BOM models previously imported from Bills of Material (Releases 10.7, 11.0 or 11i) you must:

1. Enable the refresh of a configuration model (see "Enable or Disable Refresh" on page 4-19)

Note: Many of these tables are not referenced by run-time Oracle Configurators.

Warning: Never Generate an Active Model, Refresh or Create a user interface, or run any schema maintenance scripts against a production database. Never use Oracle Configurator Developer for any development work on a production database.


Importing Data 4-19

2. If not importing from your local server, you must explode the BOM models you want to import (see "Exploding BOMs in Oracle Applications" on page 4-14)

3. Run the appropriate refresh concurrent process (see "Refresh a Single Configuration Model" on page 4-19 or "Refresh All Imported Configuration Models" on page 4-20)

4.8.1 Enable or Disable RefreshUse the following procedure to enable or disable the refresh of a configuration model from the Bills of Material schema into the Oracle Configurator schema:


2. Select Configurator > Import/Refresh Models > Disable/Enable Refresh of a Configuration Model.

3. Select from the list of values or enter the Configurator Model defined for the BOM model(s) being enabled or disabled.

4. Click OK.

5. Click Submit.

4.8.2 Refresh a Single Configuration ModelUse the following procedure to refresh a single configuration model in a production Oracle Configurator schema with changes made in a development Oracle Configurator schema:


2. Select Configurator > Import/Refresh Models > Refresh a Single Configuration Model.

The Parameters form displays prompting you for the required parameters.

3. Select from the list of values or enter the repository Folder in which the configuration model resides in Oracle Configurator Developer.

4. Select from the list of values or enter the Configuration Model ID of the model you want to refresh.

5. Click OK.

6. Click Submit.

Re-importing/Refreshing BOM Models with Component Models


4.8.3 Refresh All Imported Configuration ModelsUse the following procedure to refresh all imported configuration models in a production Oracle Configurator schema with changes made in a development Oracle Configurator schema:


2. Select Configurator > Import/Refresh Models > Refresh All Imported Configuration Models.

No parameters are required for this concurrent process.

3. Click OK.

4. Click Submit.

The Refresh All Imported Configuration Models concurrent process refreshes the data between the BOM schema and the CZ schema. It updates the Model tree structures and associated Item Master data with new or revised BOM data in Oracle Configurator Developer.

Once a run-time Oracle Configurator has been deployed, further imports or refreshes are done to refresh the CZ schema as Oracle Applications data changes.

4.9 Re-importing/Refreshing BOM Models with Component ModelsWhen you re-import or refresh BOM models that have component models (children), the result you see in Oracle Configurator Developer is a refreshed corresponding Model for each of the the previously imported Models. If new model components were added to the BOM model after the initial import into Configurator Developer, a new reference Model node is created for each of the model components. If these new model components were previously imported, they are refreshed. If they were not previously imported, the new models are created.

Section 4.9.1 describes some scenarios for re-importing or refreshing BOM models that have component models in Oracle Configurator Developer.

4.9.1 Scenarios for Re-importing/Refreshing BOM Models with Component ModelsIn Oracle Applications Bills of Material you have three BOMs that you can import into Oracle Configurator Developer. For simplicity, we’ll call these B1, B2, and B3. B2 and B3 are referenced by B1.


Importing Data 4-21

4.9.1.1 Scenario 1 - Initial Import of BOM ModelIf you import B1 (by running the Import Model Bills concurrent process for the first time),you see three corresponding Models in Oracle Configurator Developer with corresponding child nodes: M1, M2, and M3. Figure 4–3 illustrates this result in Oracle Configurator Developer.

Figure 4–3 Initial Import of BOM Model with Component Models

4.9.1.2 Scenario 2 - Re-Import/Refresh of Initial BOM ModelIn Bills of Material you modify B1 so that it no longer references B3, but now references B2 and a new BOM model B4. B2 now references C1 and C10 but no longer references C2. The new BOM model B4 references C5 and C6. When you re-import or refresh B1 by running either the Import Model Bills or Refresh a Single Configuration Model concurrent process, you see the corresponding models M1 and M2 refreshed in Oracle Configurator Developer. M4 is created corresponding to B4 and M3 is unchanged. Figure 4–4 illustrates this result in Oracle Configurator Developer.

Figure 4–4 Re-Import/Refresh of Initial BOM Model



4.9.1.3 Scenario 3 - Import New BOM Model with References to Existing BOM ModelsIn Bills of Material you create B6 which references B2 and B3. When you import B6 by running the Import Model Bills concurrent process, you see a new corresponding model M6 and M2 and M3 updated in Oracle Configurator Developer. M1 now references the updated M2. Figure 4–5 illustrates this result in Oracle Configurator Developer.

Figure 4–5 Import a New BOM Model with References to Existing BOM Models

Customizing Data Import

Importing Data 4-23

This import might create problems for M1 because the logic and UI may no longer be valid with the changes and updates. The Oracle Configurator Developer user should regenerate logic and UI for M1.

4.10 Customizing Data ImportAlthough it is not recommended, in certain circumstances it may be necessary for you to customize your data import. A data import may be customized in the following ways:

■ Specifying certain tables to be extracted and imported

■ Specifying certain fields of the CZ_XFR_TABLES table to be extracted and imported

■ Modifying the CZ_XFR_PROJECT_BILLS.EXPLOSION_TYPE parameter

Note: If M1 was published, the run-time Oracle Configurator end user can still use M1 at runtime because as a part of the publishing process Oracle Configurator Developer creates another copy.



■ Creating and performing a custom import of legacy data from non-Oracle Applications databases

4.10.1 Importing Specific TablesYou may want to specify only a group of tables from which extracted data is loaded into the import tables. These specifications modify the control tables, CZ_XFR_TABLES.DISABLED field in the Oracle Configurator schema to enable or disable a specific table for import.

Use the following procedure to import into specific tables in the Oracle Configurator schema:


2. From the View menu select Requests.

3. On the Find Requests window, click Submit a New Request.

4. On the Submit a New Request window, accept the default and choose Ok to submit a single request.

5. On the Submit Request window, click the list of values button, select the Select Tables To Be Imported concurrent process from the drop-down list and click OK. You may have to scroll down the list.

6. Click Submit.

7. Enter the following parameters in the Parameters form:

Destination Table Name - from the list of values, select the name of the table in the CZ schema for which import is being enabled or disabled. The table names display with a description of Import, Extract, or Generic. Be sure to select the table name with the appropriate description.

Import Group - from the list of values, select the name of the phase or group in which import is to be enabled or disabled for the specified table, Extract or Import.

Enable (Y/N) - from the list of values, select N to disable or Y to enable the specified table for the specified import phase.

Note: You should always contact your Oracle consultant before attempting any database customization.


Importing Data 4-25

For example, the parameters could be: Table Name: CZ_XFR_TABLES, Phase Name: Import, Enable:Y, meaning that the CZ_XFR_TABLES table is enabled for the import phase of the import process.

You can also display the current tables to be imported by selecting the concurrent process, Show Tables To Be Imported from the list of values in the Submit Request form and enter the following parameters in the Parameters dialog:

■ Table Name - enter the name of the table in the CZ schema for which you are querying the import disability.

■ Import Group - enter the name of the import phase (extract or import) for which you want to display the import Enable setting.

For example, the parameters could be: Table Name: CZ_XFR_TABLES, Phase Name: Import, meaning that you want to display the current import Enable setting for the CZ_XFR_TABLES table import phase of the import process.

4.10.2 Importing Specific Fields of CZ_XFR_TABLESYou can customize which fields in the tables listed in CZ_XFR_TABLES are extracted and imported. See "Control Tables (CZ_XFR_)" on page 4-5 for more information about CZ_XFR_TABLES and other control tables.

There is no concurrent process to complete this customization. Modification of the EXPLOSION_TYPE field can only be accomplished directly using SQL*Plus.

4.10.3 Modifying CZ_XFR_PROJECT_BILLS.EXPLOSION_TYPEYou can modify the CZ_XFR_PROJECT_BILLS.EXPLOSION_TYPE field for previously imported bills to indicate how the BOM exploder should handle standard items. The possible values for this field are OPTIONAL (default), ALL, or INCLUDED. See "Control Tables (CZ_XFR_)" on page 4-5 for more information about CZ_XFR_PROJECT_BILLS and other control tables.

There is no concurrent process to complete this customization. Modification of the EXPLOSION_TYPE field can only be accomplished directly using SQL*Plus.

4.10.4 Creating a Custom ImportUsing a series of custom-written programs and the Oracle Configurator import concurrent processes, you can import other Oracle Applications data or legacy data from non-Oracle Applications databases. This is called a custom import.



A custom import process utilizes the import tables to load data into the online Oracle Configurator schema.

The following tables can be populated through a custom import:

CZ_DEVL_PROJECTSCZ_INTL_TEXTSCZ_ITEM_MASTERSCZ_ITEM_PROPERTY_VALUESCZ_ITEM_TYPESCZ_ITEM_TYPE_PROPERTIESCZ_PROPERTIESCZ_PS_NODES

If you are importing legacy data from non-Oracle Applications databases, you must:

1. Identify and cleanse data for import.

2. Create and run custom extraction programs for the data you want to import and either:

a. generate an ASCII file in the data transfer (DAT) format the import tables require, then create and run load programs that load the data file into the import tables. See "Setup for a Custom Import" on page 4-26 and "Required ASCII File Format for Custom Import" on page 4-28.

OR

b. load the data generated by the custom extraction programs directly into the import tables.

3. Run the concurrent process, Import Model Bills, which populates the Oracle Configurator schema tables with imported data from the import tables. See "Running the Import Concurrent Process" on page 4-15.

4.10.4.1 Setup for a Custom ImportIf you are importing legacy data or Oracle Applications data not accessible through import using the import concurrent processes, you must perform a custom import. Custom import requires writing a custom extraction program to extract the product and product-related data in a format that satisfies the import tables in the Oracle Configurator schema. You must then develop custom load programs to populate the import tables in the Oracle Configurator schema with that extracted data. You


Importing Data 4-27

then run the import concurrent process provided by Oracle Configurator which populates the Oracle Configurator schema from the import tables.

Figure 4–6 Overview of Custom Import

In order to know what data to extract for populating the import tables, you need to know what fields are available in the import tables for data population. See Appendix A.4, "Import Tables", for detailed information about all Import Table fields and Appendix A.3, "Dependencies Among Import Tables", on page A-2 for information about the dependencies among the Import Tables. You can further customize your import setup by indicating in the control tables (CZ_XFR_ tables) what extracted data is loaded into the import tables. To do this, run the concurrent process described in "Importing Specific Tables" on page 4-24.

4.10.4.2 Extraction Setup for a Custom ImportThe process for setting up the extraction portion of a custom import is as follows:

Figure 4–7 Extraction Setup for a Custom Import



Once you have the Data Transfer Files required by the Oracle Configurator schema import tables, you must also create the load programs that populate those import tables with the data contained in the Data Transfer Files.

4.10.4.3 Required ASCII File Format for Custom ImportFor a custom import, you must define the extraction from your legacy database, create the data transfer files containing the extracted data, and the load program that loads the import tables with that data. The format of the data transfer files you load into the import tables must match their target import tables exactly, field for field.

The data transfer files include all data in text (ASCII) format, with fields separated by delimiters such as a vertical bar (“|”).

The following example imports item types. Item type populates the third column of the 21-column import table CZ_IMP_ITEM_MASTER.

||Memory Board|||||||||||||||||||||Dual CPU|||||||||||||||||||||Country|||||||||||||||||||||System Console|||||||||||||||||||||Server Console|||||||||||||||||||


Importing Data 4-29

||Disk Drive|||||||||||||||||||||Storage Media|||||||||||||||||||||Server Size|||||||||||||||||||||Power Supply|||||||||||||||||||||Matrix Printer|||||||||||||||||||||SCSI Disk Drive|||||||||||||||||||||Cache Memory|||||||||||||||||||||Disk Array Model|||||||||||||||||||||SCSI Type|||||||||||||||||||||SCSI Cable|||||||||||||||||||||SCSI Chaining|||||||||||||||||||||SCSI Cabling Configuration|||||||||||||||||||||Server Type|||||||||||||||||||||System Size|||||||||||||||||||

4.10.4.4 Running a Custom ImportIf you are importing data from another Oracle database (non-Oracle Applications) or a non-Oracle database, you are responsible for implementing a custom extraction of your legacy data.

To run a custom import:

1. Be sure your legacy data is available in the ASCII file format required by the import tables. See Appendix 4.10.4.3, "Required ASCII File Format for Custom Import", on page 4-28.

2. Be sure you have extracted legacy data and loaded it into the Oracle Configurator schema import tables. See Section 4.10.4.1, "Setup for a Custom Import", on page 4-26.

3. If you do not load data into all of the Oracle Configurator schema import tables, run the Select Tables To Be Imported concurrent process as described in "Importing Specific Tables" on page 4-24. Select all import tables that you will be importing data into. Minimally, the following tables are used for custom import and should be selected:

■ CZ_ITEM_MASTERS

■ CZ_ITEM_TYPES

■ CZ_ITEM_TYPE_PROPERTIES

■ CZ_ITEM_PROPERTY_VALUES

■ CZ_PROPERTIES



4. Run the Import Model Bills concurrent process as described in "Running the Import Concurrent Process" on page 4-15.

5. Verify your import as described in "Verify Data Import" on page 4-16.

Pricing in Oracle Configurator 5-1

5Pricing in Oracle Configurator

How Oracle Configurator handles pricing is entirely dependent upon the type of run-time Oracle Configurator you choose to use. A run-time Oracle Configurator is designed to be called from a variety of different applications and requires an interface between the run-time Oracle Configurator and the calling application’s pricing mechanism.

5.1 Pricing in a Run-time Oracle ConfiguratorA run-time Oracle Configurator is designed to be called from any of the following applications:

■ Order Management

■ TeleSales

■ Sales Online

■ Order Capture

■ iStore

■ non-Oracle Applications, such as a custom webstore.

The Java Applet interface for the run-time Oracle Configurator presents list prices for all selectable options, selling prices (for example, discounts) for all selected options, and a total price for the configuration as a whole. The Dynamic HTML in a browser interface presents either list prices for all selectable options, or selling prices for all selected options, and enables you to add a total price.

When the calling application is an Oracle Applications product such as Order Management, pricing comes from Oracle Pricing (QP). The QP interface is highly configurable. Depending on how it is configured, it may be necessary that appropriate data records are defined in the calling application in order to determine

Pricing in a Run-time Oracle Configurator


pricing parameters. It is expected that the calling application implement the Oracle Configurator pricing interface package, as described in the Oracle Configurator Custom Web Deployment Guide. Unless you implement a Functional Companion to do the job, it is not possible for the run-time Oracle Configurator to call the QP engine directly to obtain the same pricing that would be obtained by the calling application. Likewise, when the calling application is not an Oracle Applications product, it must implement the Oracle Configurator pricing interface package, so that the run-time Oracle Configurator can know how to determine prices.

Therefore, the calling application to the run-time Oracle Configurator provides an interface PL/SQL package that interacts whenever pricing is requested between the run-time Oracle Configurator and the calling application’s pricing engine. The run-time Oracle Configurator is displayed when the user clicks the Configure button in the calling application. The run-time Oracle Configurator calls the interface package to get:

■ list prices for all selectable Options in the configuration

■ selling prices for all selectable Options in the configuration

■ total price for the configuration as a whole

5.1.1 Pricing Interaction in the User InterfacesThe interaction of the end user with pricing varies in the user interfaces available for Oracle Configurator.

5.1.1.1 Pricing Interaction in the Java Applet User InterfaceWhen the run-time Oracle Configurator is initialized, it displays the list prices for the Options appearing on the first screen page, in the Options Selection window and in the Selected Items or Summary window.

When the end user clicks the Update Prices button, the run-time Oracle Configurator calls the pricing package to get the selling prices for all the selected Options and the total price for the configuration. The selling prices are displayed in the Selected Items and Options Selection windows.

5.1.1.2 Pricing Interaction in the DHTML User InterfaceWhen the run-time Oracle Configurator is initialized, it displays the list prices for the Options appearing on the first screen page, in the Summary window.

When the end user clicks the Summary button, the run-time Oracle Configurator calls the pricing package to get the selling prices for all the

Run-time Oracle Configurator Pricing Architecture


selected components and the total price for the configuration. The selling prices are displayed in the Summary window.

5.1.2 General Pricing BehaviorThe run-time Oracle Configurator caches list prices of the items until it is closed. The run-time Oracle Configurator assumes that the list price of any item does not depend on which other items are selected and is unchanged during the configuration session.

If the calling application requires access to prices computed for the run-time Oracle Configurator after the configuration session ends, it is up to the calling application’s interface package to save the computed prices. Prices should be saved together with enough information to allow them to be correlated with the components of the saved configuration.

If the run-time Oracle Configurator is initialized with a previously saved configuration, it is up to the calling application to either return the saved list and selling prices or to call the pricing engine to get the current price. Direct or manual editing of prices, adjustments, discounts, etc. is the responsibility of the calling application.

5.2 Run-time Oracle Configurator Pricing ArchitectureThe calling application sends an initialization message to the run-time Oracle Configurator with the interface package and procedure name. The run-time Oracle Configurator calls this interface package to get current pricing information for a single item or a list of items.

The interface package determines the full context in which to call the target pricing engine. The interface package then calls the pricing engine and captures all of the results, storing these results in tables (or some other Oracle session-insensitive place) for future reference when the run-time Oracle Configurator session exits. The run-time Oracle Configurator does not reference the contents of these tables.

Note: The run-time Oracle Configurator’s performance depends critically on the performance of the supplied pricing interface package. List prices in particular must be returned very quickly, since they are demanded for every option that is displayed.

Run-time Oracle Configurator Pricing Architecture


The interface package writes the list and/or selling prices for the configuration components in the temporary CZ_PRICING_STRUCTURES table so that they can be presented to the end user.

The run-time Oracle Configurator saves the configuration information in the appropriate CZ tables. The run-time Oracle Configurator does not save list or selling prices. It is up to the calling application to save configuration data, list prices, and selling prices in their own tables (for example, Order Management stores the configuration in OE_ORDER_LINES_ALL, and stores the pricing data in OE_PRICE_ADJUSTMENTS). The calling application decides whether it is necessary to recalculate prices depending on the value of the prices_calculated_flag in the run-time Oracle Configurator termination message.

When the calling application calls the run-time Oracle Configurator to edit an existing configuration, the run-time Oracle Configurator asks the interface package for the current list and selling prices of the already selected components. Figure 5–1, "Run-time Oracle Configurator Pricing Architecture", illustrates this architecture. Illustrated steps 2 through 5 can be repeated many times.

Figure 5–1 Run-time Oracle Configurator Pricing Architecture

Controlling Pricing in the Run-time Oracle Configurator


5.3 Controlling Pricing in the Run-time Oracle ConfiguratorYou can control whether and how pricing and ATP information is presented in the run-time Oracle Configurator.

■ You can control which types of prices appear.

■ You can control when pricing data is obtained from the database.

To control both of these aspects of pricing behavior in the run-time Oracle Configurator, you must:

1. In Oracle Internet Application Server, set the value of the cz.activemodel and cz.activemodel.lazyloadlistprice properties of the OC Servlet.

See the Oracle Configurator Installation Guide for more details about setting OC Servlet properties.

2. In Oracle Configurator Developer, choose options in the Pricing Display attribute of the User Interface for your Model.

In order to take effect, these settings require that the properties mentioned in Step 1 be set. The Pricing Display settings in Oracle Configurator Developer modify, but cannot override, the effect of the properties of the OC Servlet.

See the Oracle Configurator Developer User’s Guide for more details about setting the Pricing Display attribute with Oracle Configurator Developer, and about differences in pricing display behavior between the Java Applet and Dynamic HTML in a browser.

3. If you are creating a custom application, you must also set the appropriate parameters in the initialization message that is posted to the OC Servlet.

See the Oracle Configurator Custom Web Deployment Guide for details about the pricing interface package, and about the initialization and termination messages for pricing and ATP.

Note: See the Oracle Configurator Custom Web Deployment Guide for details about the pricing interface package, and about the initialization and termination messages for a run-time Oracle Configurator session.



5.3.1 Displaying Price Types

5.3.1.1 Setting the OC Servlet Property for Price TypesIn order to control the type of prices to be displayed, you must first set the cz.activemodelproperty of the OC Servlet. (See the Oracle Configurator Installation Guide for details about setting OC Servlet properties.)

The syntax for this setting is:

cz.activemodel=/switch|

Where switch is one of the following:

You can set more than one switch. The syntax for this setting is:

cz.activemodel=/switch1|/switch2|

Note that each switch is separated by the pipe character ( | ), and that the pipe character is required at the end of the property setting.

If you set contradictory switches, then only the first switch is respected. Example:

cz.activemodel=/lp|/nolp|

The default pricing behavior for the OC Servlet is that all price fetching is turned off. You can produce this behavior by omitting the cz.activemodelproperty from the OC Servlet’s configuration files.

If one of the switches that disable fetching has been set, the end user will receive an error message when pricing is requested in the run-time Oracle Configurator.

Switch Effect

lp Fetch List Prices from the database.

dp Fetch Discounted Prices from the database.

atp Fetch ATP data from the database.

nolp Do not fetch List Prices from the database.

nodp Do not fetch Discounted Prices from the database.

noatp Do not fetch ATP data from the database.



Be aware that in Dynamic HTML in a browser, the display of columns for Discount Price and Extended Price is controlled by the initialization message. If you pass pricing parameters, these columns will be displayed.

Examples of Setting Pricing Switches

5.3.1.2 Setting the Item Price Display in Oracle Configurator DeveloperIf you have enabled the appropriate price fetching in the OC Servlet, then you can modify it in the User Interface for your Model, using Oracle Configurator Developer.

In Oracle Configurator Developer, go to the User Interface module for your Model, and choose an option for the Item Price Display setting of the Pricing Display attribute:

For a DHTML User Interface, you can choose either List Prices or Selling Prices, but not both.

See the Oracle Configurator Developer User’s Guide for more details about setting the Pricing Display attribute with Oracle Configurator Developer.

These options are overridden by the settings for the OC Servlet property cz.activemodel. For instance, if cz.activemodel is set to /nolp|, then you cannot turn it on by choosing the List Price option in Configurator Developer.

Setting Effect

cz.activemodel=/lp| List Prices will be fetched and displayed.

cz.activemodel=/nolp| List Pricing is turned off. List Prices will not be fetched or displayed.

cz.activemodel=/lp|/dp| List Prices and Discounted Prices will both be fetched and displayed.

cz.activemodel=/nolp|/nodp| No List Prices or Discounted Prices will be fetched.

Option Effect

List Prices Display the unit list prices for each item.

Selling Prices Display the unit selling price (discounted price) of all selected items.

None Do not display any List Prices or Selling Prices in the UI.



5.3.2 Updating Price DataThe fetching and display of pricing information may impose a significant additional load on the performance of Oracle Configurator. You can improve performance by fetching pricing data only when it is needed for the end users of your application.

5.3.2.1 Setting the OC Servlet Property for Price UpdatingIn order to control when list price data is fetched, you must first set the cz.activemodel.lazyloadlistprice property of the OC Servlet. (See the Oracle Configurator Installation Guide for details about setting OC Servlet properties.)

The syntax for this setting is:

cz.activemodel.lazyloadlistprice=[true|false]

If you set this property to true, then list pricing data is only fetched for the items on the page that is currently being displayed. When the run-time Oracle Configurator is initialized, only the list prices for the items on the first page are fetched and displayed. Thereafter, list prices are displayed for each new page that the end user navigates to.

If you set this property to false, then list pricing data is fetched for the entire configuration Model.

The default value for this property is true.

5.3.2.2 Setting the Price Update in Oracle Configurator DeveloperIf you have enabled the appropriate price updating in the OC Servlet, then you can modify it in the User Interface for your Model, using Oracle Configurator Developer. While this method can affect both list and selling prices, it is useful mainly as a way of controlling selling price updating, since you can control list price updating as described in "Setting the OC Servlet Property for Price Updating" on page 5-8.

In Oracle Configurator Developer, go to the User Interface module for your Model, and choose an option for the Price Update setting of the Pricing Display attribute:

See the Oracle Configurator Developer User’s Guide for more details about setting the Pricing Display attribute with Oracle Configurator Developer.

Note: This property controls the fetching of list prices only, not of selling prices or total price.



These options are overridden by the settings for the OC Servlet property cz.activemodel.lazyloadlistprice. For instance, if cz.activemodel.lazyloadlistprice is set to true, then the Always option in Configurator Developer will be ignored. If cz.activemodel.lazyloadlistprice is set to false in the OC Servlet, then these options in Configurator Developer have no effect on list price updating, since list prices will be displayed for all items in the Model.

5.3.3 Examples of Controlling PricingThis section illustrates how the various settings that control pricing can be used together. See the rest of Section 5.3 for an explanation of these choices.

5.3.3.1 Example: List Prices OnlyThe following example illustrates the values that you should probably choose— subject to the specific nature of your application—if you want to display only list prices.

5.3.3.2 Example: Selling Prices OnlyThe following example illustrates the values that you should probably choose— subject to the specific nature of your application—if you want to display only selling prices.

Property or Setting Value

cz.activemodel /lp|/nodp|

Price Display List Prices

cz.activemodel.lazyloadlistprice true (probably, depending on application)

Price Update any setting

Property or Setting Value

cz.activemodel /nolp|/dp|

Price Display Selling Prices

cz.activemodel.lazyloadlistprice true (or omit altogether)

Price Update any setting

Publishing Configuration Models 6-1

6Publishing Configuration Models

This chapter explains the publishing mechanism and the resulting database processes that make configuration models available to calling applications. For details about creating publications of configuration models, see the Oracle Configurator Developer User’s Guide. For details about calling publications of configuration models from custom applications, see the Oracle Configurator Custom Web Deployment Guide.

6.1 Overview of Publishing Configuration ModelsPublishing configuration models requires careful planning, based on a thorough understanding of the process by which publications of configuration models are defined and made available to calling applications.

6.1.1 Planning PublicationsIn order to use publications effectively, it is necessary to plan and design how publication will be used in your projects.

How you define publications depends on whether you are working with imported BOM models or configuration models that are created from scratch in Oracle Configurator Developer. In this release, only publications of imported BOM models identified at the imported root node can be accessed by Order Management, iStore, Telesales, and SalesOnLine.

As part of your planning, you should identify what you need to accomplish and how the Oracle Configurator publication functionality can help you achieve the results you desire. Once you have determined how the publication functionality applies to your situation, identify the necessary task in Oracle Applications and Oracle Configurator Developer.

Overview of Publishing Configuration Models


Your project design should account for how will you use calling applications, usages, effective date ranges, effectivity sets, publication modes, and database instances, as well as configuration models within products.

■ How many databases are you going to set up? For instance, are you going to develop, test, and go live on only one database, or do you plan to develop configuration models and test them in one database, but run your production environment on a separate, production database?

■ What is your publication plan, relative to the databases you are using.

■ Are you going to use usages centrally to define which users have access to which configuration models?

■ Are you going to use effectivity dates, effectivity sets, and usages locally within configuration models to further delimit access and availability?

■ How will you use publication mode to restrict access to testers and end users? For instance, when testing on the production database before going live, publication mode set to Test excludes end users from accessing those models, even though they exist in the production database.

■ Is the custom application that calls your configuration model a registered application in Oracle Applications?

6.1.2 The Publication ProcessOnce a configuration model has been developed in Oracle Configurator Developer, implementers publish the model to make it available to a calling application. Implementers specify publication attributes for a particular configuration model in Oracle Configurator Developer, and a concurrent process creates a copy based on those attributes. In this document, a publication is the combination of publication attributes and the copy of the configuration model. The publication attributes specify the model to be published, the UI to use, the database where it needs to be available, and applicability parameters such as usage, effective date range, and calling application.

The copy is created by exporting the data of the configuration model within a development database or to another database such as a test or production database on the same or another server machine. Development and maintenance can continue on the original configuration model while the publication is available for test and production.

Applications that call Oracle Configurator can only access publications of configuration models. If several publications exist for one model, only one of those

Defining the Publication


publications can be valid. Oracle Configurator Developer checks for overlap in publication attributes at the time the publication is defined. The Test button in Oracle Configurator Developer accesses only configuration models, never publications of configuration models.

Publishing involves:

■ defining a publication in Oracle Configurator Developer by specifying attributes for that publication that differentiate it from other publications of that same configuration model and determine the run-time circumstances and environment in which the published configuration model is accessible

■ exporting that publication to the same or another database for access by a calling application such as Order Management

■ editing the publication attributes to change the availability of the configuration model

■ re-exporting that publication to overwrite the copy with modifications made to the configuration model

6.2 Defining the PublicationSee the Oracle Configurator Developer User’s Guide for information about using the Publishing window in Oracle Configurator Developer to define publications.

6.2.1 Publication AttributesA publication is defined by its attributes. Publication attributes include

■ Product

■ Model (see "Model" on page 6-4)

■ Database instance (see "Database Instance" on page 6-5)

■ UI Definition (see "User Interface" on page 6-5)

■ Applicability parameters, which are the following:

■ Publication mode (see "Publication Mode" on page 6-5)

■ Application (see "Application" on page 6-6)

■ Date range (see "Date Range" on page 6-6)

■ Usage (see "Usages" on page 6-7)



By defining publication attributes, the implementer defines the run-time circumstances and environment in which the published configuration model is accessible. Effective time is part of the definition.

Every publication you define must be unique, meaning there cannot be any overlap in the definition that would render more than one publication valid for a specific calling application on one database.

Defining a publication creates a publication record with a unique publication ID in the CZ_MODEL_PUBLICATIONS table. See "Tables Used in Publishing" on page 6-10 for a summary of the tables involved in publishing.

6.2.1.1 ProductProduct is a designation relevant only to publications in Oracle Configurator. There is no Product node in the structure of a configuration model.

For configuration models that are based on imported BOM models at the root node, the Model ID and Product ID are the same.

Implementers must specify a product for configuration models that are not imported BOM models. Specifying a product makes it possible to organize the publications of numerous non-imported configuration models within a single product type. For example, you could have several publications of laptop computers, each accessible to different calling applications but all belonging to the same product type laptops.

If the publications are of configuration models based on imported BOM models, the product_key is defaulted to organization_id + inventory_item_id of the root node of the imported model. This product_key cannot be updated by the user.

If the publications are used by a custom application, the initialization message must call the publication by a product_key. This product key is defined by the user when the publication attributes are defined.

6.2.1.2 Model The name of the model as it appears in the Repository window in Oracle Configurator Developer may not be the same as the root node that appears in the Model window. The publication ID associates the publication with the Repository model name, as listed in the Oracle Configurator Developer Publishing window’s list of values for the Model field.

The configuration model’s ID is stored in the CZ_DEVL_PROJ_IDS table.



Publications of imported BOM Models are specified by product_key in CZ_MODEL_PUBLICATIONS.

The initialization message from the calling application only includes product_key for publications of non-imported configuration models.

6.2.1.3 Database InstanceCZ_SERVERS contains information about the databases you define as available targets for publication. The concurrent process Define Remote Servers populates CZ_SERVERS. See Section 1.8.1.1, "Server Administration" on page 1-12 for detailed information. All the databases listed in CZ_SERVERS are displayed in the list of values for the Database Instance publication parameter.

6.2.1.4 User InterfaceBy default, the value for the publication’s UI is NONE. None means do not use a user interface, which is appropriate for batch validation configuration models.

If the configuration model specified by the publication has multiple user interfaces, the list of values for the user interfaces in the Publication dialog in Oracle Configurator Developer comes from the CZ_UI_DEFS table. The user interfaces are listed by the top-level UI node name.

6.2.2 Publication Applicability Parameters



Disabling a publication takes it out of circulation. Marking a publication "disabled" does not delete it from the database.

A publication can be re enabled.

Use the profile option CZ:Publication Mode to set which publication mode should restrict access by a calling application to a configuration model. See "Setting Profile Options" on page 6-11 for details about this profile option.

The user profile option CZ: Publication Mode is required to support the Publication Mode parameter. The calling application must include the value of this profile option in the Oracle Configurator initialize message. If this parameter is missing from the initialize message, the configuration model’s publication mode is assumed to be Production and will be available if value of the profile option is Production.

6.2.2.2 ApplicationThe FND_APPLICATIONS table establishes the list of values, by application short name (application_id), presented in the Application field in the Publishing window in Oracle Configurator Developer.

The following applications are available as seeded data in the FND_APPLICATIONS table:

■ Order Management (ONT)

■ iStore

■ Telesales

■ SalesOnLine

When you save publications, the applications specified in those publications are stored in the CZ_PB_CLIENT_APPS table.

If you want to add applications to FND_APPLICATIONS, be aware that application_id is a sequence ID and that if you are exporting publications from one database to another, the publication must be able to access precisely the same applications defined in FND_APPLICATIONS in both databases.

6.2.2.3 Date RangeThe date range establishes when a publication is valid, relative to the system date of the database in which it is stored.

Date Range consists of a Date From and Date To set of values. Date From and Date To are time stamps. Date To must be greater than or equal to Date From. If Date To is exactly equal to Date From, the publication is never applicable.



The publication date range does not override any effective dates defined in the configuration model. For instance, if the publication date range does not overlap an effective date range or effectivity set for the model, the publication is valid for a model that is not effective.

The model’s effective dates are defined on model nodes and stored in CZ_PS_NODES. The model’s effectivity sets are stored in the CZ_EFFECTIVITY_SETS table. Valid dates may range from 01/01/1601 through 12/31/4710 (inclusive).

6.2.2.4 UsagesThe usages you define throughout your configuration models are stored in CZ_MODEL_USAGES, which are then displayed as the list of values when choosing the usage for your publication.

See the Oracle Configurator Developer User’s Guide for details about defining usages and specifying then for a publication.

The usages defined for the publication are stored in CZ_PUBLICATION_USAGES.

When creating or updating a publication, you can select one, multiple, or all usages. All means that this publication is applicable for all usages, which could easily lead to overlap with other publications that are applicable for only specific usages.

Use the profile option CZ:Usage Name to set which usages should restrict access by a calling application to a configuration model. See "Setting Profile Options" on page 6-11 for details about this profile option.

If you don’t want to use usages, define publications with ANY usage and set CZ:usage Name to ANY.

6.2.2.4.1 Defining Usages You define Usages in Oracle Configurator Developer and assign them to model nodes and configuration Rules to control whether each Rule or node appears in the model at run time. Like Effectivity Sets, Usages provide a method of controlling the availability of Models, Features, Components, Options, Rules, Totals, Resources, and model publications. You can also assign Usages to imported BOM Models and Models created "from scratch" in Configurator Developer. You can assign Usages independently or in addition to an Effectivity Set.

When you create a new Usage, Configurator Developer automatically assigns it to all of the models, model nodes, and configuration Rules you have defined. To make a node or rule unavailable for a specific Usage, you must modify the list of Usages for that node or rule in the Model window.

Creating the Publication


6.3 Creating the PublicationOnce a publication has been defined in Oracle Configurator Developer, it must be exported using one of two possible concurrent processes .

■ Process Pending Publications: Submit this request to copy all new and modified Model data to the target database.

■ Process a Single Publication: Submit this request to copy only data for the configuration model that you specify.

All publications with the status Pending can be exported. The publication export concurrent processes only export pending publications listed in CZ_PB_MODEL_EXPORTS.

Typically, the publication export concurrent processes are scheduled to run automatically. If for some reason you do not have these concurrent processes scheduled, or you cannot wait to publish your model until the next scheduled request run, you can manually run the publication export concurrent processes.

The destination of the export is established by the value of the Database Instance applicability parameter in the publication definition.

6.3.1 Publishing a Single Pending Configuration Model Using concurrent manager, establish a schedule for running the concurrent process that exports a single configuration model.

If you do not have Process a Single Publication scheduled, or cannot wait for the next run, use the following procedure. The concurrent process must be run in the database in which the configuration model and it’s publication are defined. The target of the publication process is specified by the Database Instance applicability parameter of the publication.

1. Log into Oracle Applications of the database where the configuration model and it’s publication are defined. Change to the Configurator Administrator or Configurator Developer responsibility.

2. Select Configurator > Publish Configuration Models > Process a Single Publication.

3. From the list of publication ID values, select the configuration model to export. The publication ID is displayed in the Publication window in Oracle Configurator Developer, and stored in the CZ_MODEL_PUBLICATIONS table.

4. Ensure the program completes successfully.

Tables Used in Publishing


6.3.2 Publishing All Pending Configuration Models

Using concurrent manager, establish a schedule for running the concurrent process that exports all pending configuration models.

If you do not have Process Pending Publications scheduled, or cannot wait for the next run, use the following procedure. The concurrent process must be run in the database in which the configuration model and it’s publication are defined. The target of the publication process is specified by the Database Instance applicability parameter of the publication.

1. Access the database in which the publication is defined by logging into Oracle Applications under either the Configurator Administrator responsibility.

2. Select Configurator > Publish Configuration Models > Process Pending Publications.

There are no parameters required for this concurrent process.

3. Ensure the program completes successfully.

6.4 Tables Used in Publishing

Table 6–1 Publication Tables

Table Name Description

CZ_MODEL_PUBLICATIONS Contains information about publications of the configuration models and publication requests. If the target database of a publication is different from the source, the export concurrent processes copy both the publication record for model and the model data specified by the publication.

This table is automatically (via link) updated in the target database if a corresponding publication in the source database is edited.

CZ_MODEL_USAGES Contains the model usages that have been defined for all the configuration models in the current database.

CZ_PB_CLIENT_APPS Contains the applications that are specified in the publications defined in the current database.

CZ_PB_MODEL_EXPORTS Contains information about which configuration models were exported to which databases.

CZ_PUBLICATION_USAGES Contains the usages included in each publication request.

Profile Options Used in Publishing


For more detailed information about these tables see the Oracle Configurator Technical Reference Manual.

6.5 Profile Options Used in PublishingOracle Applications provides several profile options for establishing an environment that restricts access to configuration models. Access is restricted by defining the publication of a configuration model to be available only for:

■ test or production

■ all, any, or some specific usage

6.5.1 Setting Profile OptionsFor information about setting profile options, see the Oracle System Administration Guide.

CZ:Publication Mode This profile option restricts access by the calling application to those publications defined with the matching Publication Mode applicability parameter. The access restriction applies to the level at which the profile option is

FND_APPLICATIONS Identifies the calling applications that are available for specification in a publications. See "Application" on page 6-6 for details.

Profile Option User System Administrator Requirements

User User Resp App Site Required? Default Value

CZ:PUBLICATION_MODE

X X X X X Required Production

CZ:USAGE_NAMES X X X X X Required Any

Key: X You can update the profile option.

- You can view the profile option value but you cannot change it.

0 You cannot view or change the profile option value.

Table 6–1 Publication Tables

Table Name Description

Publishing and Effectivity


set. The default setting of CZ:Publication Mode is Publication. The other possible value for this profile option is Test.

See also "Publication Mode" on page 6-5 for details about working with publication modes.

CZ:Usage Names his profile option restricts access by the calling application to those publications defined with the matching Usage applicability parameter. The default setting of CZ:Usage Names is Any. The other possible values for this profile option are All and the valid usages stored in CZ_MODEL_USAGES.

See also "Usages" on page 6-7 for details about working with usages.

6.6 Publishing and EffectivitySee "Date Range" on page 6-6.

6.7 Publishing and ReferencingIf the configuration model you are publishing has references to other models, all referenced (child) models are exported when the parent model is published. A referenced model in the configuration model that you publish becomes part of the publication. If the referenced model is itself not published, the reference model can only be accesses by the calling host application as part of the publication representing the parent model.

6.8 Updating or Republishing PublicationsUpdate publications by re-exporting them. You must re-export a publication if you have made changes to the configuration model structure, logic, or user interface definition. If the logic or user interface is not up to date, the publication cannot be exported.

When a publication update is completed successfully, the calling application has access to the updated model.

When the Oracle Configurator Developer user requests an update to a publication, the following occurs:

1. Status of the original publication is changed to "Pending Update"

2. A new publication record is created for the updated publication in the CZ_MODEL_PUBLICATIONS, CZ_PB_CLIENT_APPS, and CZ_PUBLICATION_

Lost Publications Due to Instance Failure


USAGES tables of the development instance with the same applicability records as the original publication.

3. Status of the new (updated) publication is set to "Pending".

4. When one of the publication current processes is executed that includes the updated publication, a copy of the updated model is created and exported to the production instance in the same manner as a new publication.

5. Publication records for the original publication (old) are deleted.

6.9 Editing PublicationsIt is not necessary to re-export a publication if you have made changes to the publication’s attributes and applicability parameters. Edits to a publication are automatically propagated to the CZ_MODEL_PUBLICATIONS table of the target database.

Editing a publication explicitly skips any changes to model structure, logic, or user interface. Depending on the changes the Oracle Configurator Developer user made to the attributes and applicability parameters, editing the publication may involve adding or deleting records in the CZ_PB_CLIENT_APPS or CZ_PUBLICATION_USAGES tables or changing the mode or date range for that publication. See the Oracle Configurator Developer User’s Guide for instructions on editing publications.

6.10 Disabling, Deleting, and Re-enabling PublicationsPublications can be marked as Disabled which signals the run-time Oracle Configurator not to use them. When disabled, however, the publication remains visible and may be edited or updated. A disabled publication may be re-enabled.

A publication (enabled or disabled) can also be deleted. After deletion, the publication is not visible and can not be recovered.

Altering a publication by disabling, deleting, or re-enabling it is propagated to the target database the same way as publication edits. See the Oracle Configurator Developer User’s Guide for specific instructions on disabling, deleting, or re-enabling publications.

6.11 Lost Publications Due to Instance FailureWhen a configuration model is published, the source database exports a copy of the configuration model’s data and a copy of the publication record in CZ_MODEL_

Lost Publications Due to Instance Failure


PUBLICATIONS. If that export is to a separate database, and the source database fails, you may have only the publication copy available. There is currently no way to re-import a publication to restore a configuration model.

If one of the instances you are working with fails, you must follow the relevant restoration process as described in the following sections.

6.11.1 Failed Target DatabaseIf a target database fails, it must be restored from the most recent backup. It is not guaranteed that all the data entered from the time of the backup to the time of the instance failure will be recovered. In some cases, the target’s backup may be in an earlier state than the source instance from which the publication was exported. When this is the case, once the backup is done and the target database instance is up and running, you can re-export the lost publication models stored in the source instance.

6.11.2 Failed Source DatabasePrior to publication, a model is created on or imported to the source database. All publication requests and associated publication history are stored in the CZ_MODEL_PUBLICATIONS and CZ_PB_MODEL_EXPORTS tables, respectively. If the source instance fails it must be restored from the most recent backup. It is not guaranteed that all the data entered from the time of the backup to the time of the instance failure will be recovered.

In some cases, the source’s backup may be in an earlier state than a corresponding target instance. When this is the case, once the backup is done and the source instance is up and running, manually update configuration models to synchronize them with their publications on the target database.

Deploying Oracle Configurator 7-1

7Deploying Oracle Configurator

Deployment involves making a run-time Oracle Configurator available to end users. Oracle Configurator can be deployed in these scenarios:

This chapter describes activities required to complete deployment of a run-time Oracle Configurator embedded in a host Oracle Application such as Order Management or iStore. For information about deploying Oracle Configurator in a custom hosting application, see Oracle Configurator Custom Web Deployment Guide.

See Section 1.6, "Oracle Configurator Environments" on page 1-5 for an overview of possible deployment environments and architecture.

7.1 Calling an Embedded Oracle Configurator Oracle Applications uses an internet server, such as Oracle Internet Application Server (iAS), to run the Oracle Configurator Servlet that connects the run-time Oracle Configurator’s URL to the Oracle Configurator schema. That URL is set in the profile option BOM:Configurator URL of UI Manager.

See the Oracle Configurator Installation Guide for information about installing the OC Servlet and configuring the internet server.

Oracle Configurator embedded in Oracle Applications uses one of these user interfaces:

■ a non-customizable window produced by a Java applet

■ a customizable web browser window produced by DHTML (Dynamic HTML)

HTML-based applications, such as iStore or a custom web application, can only use the DHTML interface.

Calling an Embedded Oracle Configurator


7.1.1 Java Applet RequirementsThe requirements for the run-time Oracle Configurator to use the Java applet interface when running in an Oracle Applications Form are already in place when running Oracle Applications:

■ JInitiator 1.1.8.2 must be installed on the client machine. The JInitiator properties should set Network Access to "Unrestricted", and the Java Runtime Parameters to:

-mx128m -Dcache.size=50000000

■ Pricing behavior must be set, for item price display type, and price data update method. See Section 5.3, "Controlling Pricing in the Run-time Oracle Configurator" on page 5-5.

7.1.2 DHTML RequirementsThe requirements for the run-time Oracle Configurator to use the DHTML interface are:

■ Stylesheets and JavaScript must be enabled in the browser running the DHTML run-time Oracle Configurator. Stylesheets and JavaScript are essential components of DHTML.

■ Use Microsoft Internet Explorer 4.0 or higher, or Netscape Navigator 4.07 or higher, to best view the DHTML run-time Oracle Configurator. The browser must support frames.

■ The browser must be set up to accept and/or send cookies.

■ Recommended screen resolution is 800 X 600 or higher. This depends on how you have generated the Components Tree user interface in Oracle Configurator Developer. See the Oracle Configurator Developer User’s Guide for details.

■ Pricing behavior must be set, for item price display type, and price data update method. See Section 5.3, "Controlling Pricing in the Run-time Oracle Configurator" on page 5-5.

For details on ... See ...

The initialization and termination messages, and other elements of a custom web applications

Oracle Configurator Custom Web Deployment Guide

Setting up the OC Servlet Oracle Configurator Installation Guide

Deployment Strategies


7.2 Deployment StrategiesNo single factor is likely to make your deployment succeed. A successful deployment depends on the relationship and interaction of several critical factors:

■ Architectural Considerations

■ Server Considerations

■ Network Considerations

While it is not possible to give you an exact prescription for your particular application, this section attempts to provide you with an understanding of the principles that affect a typical Oracle Configurator deployment.

7.2.1 Architectural ConsiderationsThe architecture of an application often determines the limits within which the other factors must operate. If you lay out your sequence of pages and controls in an inefficient way, then it will be difficult to overcome this inefficiency later simply by tuning your server software or augmenting your hardware.

As described in "Server Considerations" on page 7-4, an important tuning factor is the number of end users conducting configuration sessions on each instance of the servlet engine. For iAS, the servlet engine is Apache JServ.

To determine the number of users per JServ, you consider:

So, Model loading and data access depending on how the application was written. To get the information required to start tuning your servlet engine requires you to understand the application. You need to take the time to plan a model of what steps end users will experience, and what variety of options will be presented, such as:

■ What users can select page by page

■ How users can navigate from page to page

■ What selectable items are on a page (such as the number of Features per Component, which should generally not exceed twenty)

Using Oracle Configurator Developer Oracle Configurator Developer User’s Guide

For details on ... See ...



■ When events might be interrupted (for example, when a user pauses a long time to consider his choices, or turns to another task before returning to make a selection)

7.2.2 Server ConsiderationsA critical factor in deploying Oracle Configurator on your internet server is the number of instances of the servlet engine (Apache Jserv) that you deploy. This number is based on the number of end users that you expect to be conducting simultaneous configuration sessions in each instance, and the kind of data access that they are going to experience.

You need to consider these factors in determining the load balance of users per JServ:

■ Network data access calls made by your application

■ The length of time that a user requires to work through the application

■ The number of times a user can work through the application in an hour

■ How many of this type of user can use your application at the same time without interfering with other users needing to access the database (for instance, to save a configuration)

Consequently, the architecture of your application affects your ability to balance the load on your server, which determines the server resources that your application requires. See "Architectural Considerations" on page 7-3 for consideration of laying out your application, and "Load Balancing" on page 7-9 for information on factors that impose a load on your resources.

The factors that affect the number of users per JServ include:

■ The size of the application: the number of pages or screens

■ The size of the Model: the number of nodes

■ The number complexity of any Functional Companions used by the application

■ The number of CPUs

■ The memory per CPU

The JDK uses about 16 MB. The JVM for each JServ uses about 45 MB. Oracle Configurator uses native threads.

■ The number of JServ instances running



The maximum pool size is the maximum allowed sum of the number of available connections and the number of locked connections. If the .dbc file does not have a setting for maximum pool size, the default value is used. The default value is the Java static field Integer.MAX, which normally has a value of about 2 billion. Therefore, the default value is essentially unlimited.

The parameter FND_JDBC_MAX_WAIT_TIME specifies the length of time a request waits for a connection to be established. The default value is 10 seconds, and is not configurable.

7.2.3 Network ConsiderationsThere are a number of network issues that can cause serious problems for your deployment if not handled correctly.

7.2.3.1 Firewalls and TimeoutsIt is likely that your application requires more than one server machine. It is recommended that there be separate servers for the Oracle database server and the internet server. If there are firewalls between servers, these firewalls must allow persistent database connections between them.

The OC Servlet is a stateful application. A stateful application keeps its critical data in memory, rather than writing and reading it from disk storage. Oracle Configurator keeps in memory critical data such as the Properties cache and the state of the logic engine, until a configuration is saved.

Stateful applications require a persistent connection between the database server port and the ports used by the servlet engine (in this case, Apache JServ). The default timeout for the JServ engine is 30 minutes.

7.2.3.2 Router TimeoutsRouters have a setting referred to as "stickiness". Router stickiness connects the HTTP request made by a particular client browser (that is, the browser displaying the run-time Oracle Configurator as DHTML) with a particular instance of the servlet engine (JServ).

Warning: If there is an idle time limit set on the TCP/IP database connection across a firewall, this limit can prevent Oracle Configurator from operating.

Deployment Tasks


The stickiness setting is a time limit on the total time allowed for the connection between client and servlet engine. After the time limit is exceeded by the client browser, the connection to the servlet engine instance is broken. If the end user attempts to use the browser, it is very possible that the router may connect that browser to a different, and wholly incorrect, servlet engine instance.

You must determine the appropriate length of time for your application. For instance, if you feel that your users may wish to use your application for one hour, then you must set the router stickiness to match that time.

7.2.3.3 Miscellaneous Issues■ Your application must run in an environment that resolves domain names, to

allow it to communicate with other servers

■ You must be able to set up your router and server so that all users and processes have the access privileges and permissions they need in order to carry out their functions. It is possible for a deployment to be delayed by inattention to this innocuous issue.

7.3 Deployment TasksSeveral categories of tasks are necessary in order to system test and "go live" with a run-time Oracle Configurator.

■ Setting Profile Options

■ Establishing End User Access

■ Load Testing

■ Load Balancing

7.3.1 Setting Profile OptionsDuring your installation and setup, you set a value for each profile option to specify how Oracle Applications access the run-time Oracle Configurator. The values of these profile options may be different for deployment than they were for development.

Warning: If the "stickiness" time limit of your router is too small for the correct use of your application, this limit can prevent Oracle Configurator from operating.

Deployment Tasks


You must set up and update profile option values for users of run-time Oracle Configurators within Oracle Applications. See the Oracle Configurator Installation Guide or Oracle Applications Online Help for information about profile options required for running a run-time Oracle Configurator within Oracle Applications, Release 11i.

7.3.2 Establishing End User AccessEnd users of the run-time Oracle Configurator (DHTML or Java Applet) are established through Oracle Applications administration and reside in the Oracle Applications database.

End users click on a Configure button or a menu command in Oracle Applications to call the run-time Oracle Configurator. This action causes the calling application to initialize a run-time Oracle Configurator session with an initialization message. When an end user saves a configuration and exits a run-time Oracle Configurator session, the run-time Oracle Configurator sends the calling application a termination message to terminate the run-time Oracle Configurator session.

For more information about the initialization message, see the Oracle Configurator Custom Web Deployment Guide.

7.3.3 Load TestingIn order to prepare your application for realistic conditions, you should use a testing tool that allows you to set up reasonable tests that emulate what your end users will do. There are various types of testing you should employ, such as:

■ Stress Testing

■ User Activity Testing

7.3.3.1 Stress TestingIn stress testing, the testing tool fires as many commands as possible at the server, to test CPU utilization rate. Try to measure the number of hits per second you can trigger while keeping the load at 80-85% CPU utilization, which is a prudent level.

7.3.3.2 User Activity TestingIn user activity testing, you use the testing tool to build scripts that represent what your real end users will be doing, with the kinds of delays that a user would experience.

Deployment Tasks


After creating scripts that emulate users, run that number of users against the server, at randomly sequenced times, so that you represent a close approximation of the real user event world that the application will experience.

Examples■ The user might pause and click "Next", "Back", and "Next" several times.

■ The user might click a number of checkboxes rapidly, because he knows what he wants, since he has previously visited that part of your application.

■ The user might pause, thinking, between each click.

The variability of these different scripts, all running within the same time span, gives you a good sense of what your system can actually handle, in terms of number of users.

7.3.4 Load BalancingSee "Server Considerations" on page 7-4 for a discussion of the factors to be considered in load balancing.

See the Oracle Configurator Installation Guide for details about the mechanics of load balancing the machines and processes in your deployment.

Deployment Tasks


Import Tables A-1

AImport Tables

A.1 OverviewThis appendix contains the following information:

"List of Import Tables" in the Oracle Configurator schema"Dependencies Among Import Tables""Import Tables", which describes all import table fields and the data they expect

For a mapping of Oracle Applications database source tables to Oracle Configurator schema destination tables, see Table 4–5, "Oracle Applications Source and Destination Online Tables" on page 4-10.

A.2 List of Import TablesThe import tables are listed in the order in which the concurrent programs and SQL* Plus import procedures populate them.

CZ_IMP_ITEM_MASTERCZ_IMP_INTL_TEXTCZ_IMP_DEVL_PROJECTCZ_IMP_PS_NODE

CZ_IMP_ITEM_PROPERTY_VALUECZ_IMP_ITEM_TYPECZ_IMP_ITEM_TYPE_PROPERTYCZ_IMP_PROPERTY

Dependencies Among Import Tables

A-2 Oracle Configurator Implementation Guide

A.3 Dependencies Among Import TablesDependencies among import tables must be heeded especially when generically importing single tables. In Table A–1, below, "Foreign Surrogate Key" lists the column in the import table whose value is dependent on the table listed in "Depends on". For instance, the FSK_ITEMTYPE_1_1 or FSK_ITEMTYPE_1_EXT column in CZ_IMP_ITEM_MASTER gets its value from CZ_IMP_ITEM_TYPE and helps in key resolution. FSK_ITEMTYPE_1_1 (default) or FSK_ITEMTYPE_1_EXT are populated per some indicator (0 or 1) in CZ_XFR_TABLE.

A strong dependency means a value is required for a successful import of that record. If "Default" is YES, there is already a default value in that column and import will succeed even if the dependency is strong and no value is imported.

Note: Oracle recommends that the usage of FSK_***_EXT columns be very limited as they will not be supported in the near future.

Table A–1 Dependencies Among Oracle Configurator Schema Import Tables

Import Table Name Depends onfor Foreign Surrogate Key

Type of dependen-cies Default

CZ_IMP_DEVL_PROJECT CZ_IMP_INTL_TEXT FSK_INTLTEXT STRONG NO

CZ_IMP_INTL_TEXT NO NO NO NO

CZ_IMP_ITEM_MASTER CZ_IMP_ITEM_TYPE FSK_ITEM_TYPE STRONG YES

CZ_IMP_ITEM_PROPERTY_VALUE

CZ_IMP_PROPERTY FSK_PROPERTY STRONG NO

CZ_IMP_ITEM_PROPERTY_VALUE

CZ_IMP_ITEM_MASTER

FSK_ITEMMASTER STRONG NO

CZ_IMP_ITEM_TYPE NO NO NO NO

CZ_IMP_ITEM_TYPE_PROPERTY

CZ_IMP_ITEM_TYPE FSK_ITEMTYPE STRONG NO

CZ_IMP_ITEM_TYPE_PROPERTY

CZ_IMP_PROPERTY FSK_PROPERTY STRONG NO

CZ_IMP_PROPERTY NO NO NO NO

Import Tables

Import Tables A-3

A.4 Import TablesTable A–2, "Import Table Field Disposition Codes", describes the disposition codes that may result when required columns are queried against the source table. Table A–3, "Import Table Record Status Codes", describes the record status codes for required columns that have not resulted in a successful query. Table A–4 through Table A–12, describe all of the columns in the Oracle Configurator schema import tables. Column order is not necessarily fixed. A column that is denoted as required in this table, means that the column is required in the source table for a successful custom import and is queried against a corresponding column in the target import table.

Disposition codes for the required fields are:

Record status codes for required columns of the import tables are:

CZ_IMP_PS_NODE CZ_IMP_INTL_TEXT FSK_INTLTEXT STRONG NO

CZ_IMP_PS_NODE CZ_IMP_ITEM_MASTER

FSK_ITEMMASTER STRONG NO

CZ_IMP_PS_NODE CZ_IMP_DEVL_PROJECT

FSK_DEVLPROJECT STRONG NO

Table A–2 Import Table Field Disposition Codes

Code Disposition

M marked for modification

I marked for insertion

R rejected

Table A–3 Import Table Record Status Codes

Code Status

PASS marked for either modification or insertion after the key resolution stage

OK modified/inserted into the target table

Table A–1 Dependencies Among Oracle Configurator Schema Import Tables

Import Tables


ERR not modified/inserted into the target table because of an error in the transfer stage

DUPL marked as duplicate

Table A–4 Description of Fields in CZ_IMP_DEVL_PROJECT Import Table

COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

EDescription

DEVL_PROJECT_ID

N Y NUMBER Designates an OC identifier for the development project

INTL_TEXT_ID N Y NUMBER Contains the OC international text ID for this project

NAME Y N VARCHAR2 (255)

Contains name of the development project. Disposition if null - ERR

GSL_FILENAME N Y VARCHAR2 (255)

Contains gsl filename of the project

VERSION N Y NUMBER Contains version number of the project

DESC_TEXT N Y VARCHAR2 (255)

Description text for this project

ORIG_SYS_REF Y N VARCHAR2 (255)

Unique identification of a record in this table. Contains a foreign surrogate-key value matching CZ_DEVL_PROJECTS.ORIG_SYS_REF.

Disposition:

■ if found - M■ if not found - I■ if not unique - R-DUPL■ if null - R-N7

CREATION_DATE N Y DATE Indicates the date on which this record was created

LAST_UPDATE_DATE

N Y DATE Contains the date on which the record was last modified

DELETED_FLAG N Y CHAR (1) Indicates (’1’/’0’) that this record has been deleted

EFF_FROM N Y DATE Indicates the beginning date for which this record is effective

Table A–3 Import Table Record Status Codes

Import Tables

Import Tables A-5

EFF_TO N Y DATE Indicates the ending date through which this record is effective

CREATED_BY N Y NUMBER Identifies the user that created this record

LAST_UPDATED_BY

N Y NUMBER Records the login name for the user that last modified this record

SECURITY_MASK N Y VARCHAR2 (40)

Reserved for future use in record-level access control

EFF_MASK N Y VARCHAR2 (40)

Reserved for future use

CHECKOUT_USER N Y VARCHAR2 (40)

Reserved for future use in checkout user

RUN_ID N Y NUMBER Contains a number indicating the Import run in which this record was loaded/processed

REC_STATUS N Y VARCHAR2 (4)

Records a coded status describing the import results for this record; if null it indicates the record has not yet been completely processed

DISPOSITION N Y CHAR (1) Indicates whether the record was inserted, updated, unchanged, or rejected

FSK_INTLTEXT_1_1

N Y VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_IMP_INTL_TEXT on TEXT_STR

Table A–4 Description of Fields in CZ_IMP_DEVL_PROJECT Import Table

COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables

Import Tables A-7





Table A–6 Description of Fields in CZ_IMP_ITEM_MASTER Import Table

COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

ITEM_ID N Y NUMBER Designates an OC identifier for this record

ITEM_TYPE_ID N Y NUMBER Contains the OC Item-type ID for this Item


Unique identification of a record in this table. Contains a foreign surrogate-key value matching CZ_ITEM_MASTERS.ORIG_SYS_REF.

Disposition:



Describes this item-master part entry

REF_PART_NBR Y N VARCHAR2 (255)

Contains a part number for the item described in this record. Disposition if null - ERR

QUOTEABLE_FLAG

N Y CHAR (1) Indicates that this Item can be separately quoted

Table A–5 Description of Fields in CZ_IMP_INTL_TEXT Import Table

COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables


PRIMARY_UOM_CODE

N Y VARCHAR2 (3)

Contains code for primary unit of measure

LEAD_TIME N Y NUMBER Indicates the ordering/manufacturing lead time

ITEM_STATUS N Y NUMBER Holds a status code number for the item

REC_NBR N Y NUMBER Provides a one-up sequence number identifying the record in this run










USER_STR01 N Y VARCHAR2 (255)

Textual user expansion field




Textual user expansion field; may be used as an alternate ’surrogate key’ for the record



USER_NUM01 N Y NUMBER (16,9)

Numeric user expansion field


COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables

Import Tables A-9










LAST_UPDATE_DATE



LAST_UPDATED_BY




FSK_ITEMTYPE_1_1

Y N VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_IITEM_TYPES.ORIG_SYS_REF.

Disposition:■ if found - assign item type ID■ if not found - assign default item type ID, if defined, R-F27■ if null - assign default item type ID, if defined, R-F27

FSK_ITEMTYPE_1_EXT

N Y VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_IMP_ITEM_TYPE on USER_STR03. Note: It is recommended that the usage of this column be very limited as it will not be supported in the near future


COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables


Table A–8 Description of Fields in CZ_IMP_ITEM_PROPERTY_VALUE Import Table

COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

PROPERTY_ID N Y NUMBER Contains the OC ID for the referenced property

ITEM_ID N Y NUMBER Contains the OC Item-Master ID to which this property value applies

PROPERTY_VALUE

N Y VARCHAR2 (255)

Contains the value that is assigned to the property for this item





DISPOSITION N Y CHAR Indicates whether the record was inserted, updated, unchanged, or rejected

DELETED_FLAG N Y CHAR Indicates (’1’/’0’) that this record has been deleted















Import Tables

Import Tables A-11










LAST_UPDATE_DATE



LAST_UPDATED_BY




FSK_PROPERTY_1_1

Y N VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_PROPERTIES.ORIG_SYS_REF.

Disposition:■ if found - assign property ID■ if not found - R-F23■ if not unique - R-DUPL■ if null - R-N23

FSK_PROPERTY_1_EXT

N Y VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_IMP_PROPERTY on USER_STR03. Note: It is recommended that the usage of this column be very limited as it will not be supported in the near future


COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables


FSK_ITEMMASTER_2_1

Y N VARCHAR2 (255)

Contains foreign surrogate-key values matching CZ_ITEM_MASTERS.ORIG_SYS_REF.

Disposition:

■ if found - assign item ID■ if not found - R-F25■ if not unique - R-DUPL■ if null - R-N25

FSK_ITEMMASTER_2_EXT

N Y VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_IMP_ITEM_MASTER on USER_STR03. Note: It is recommended that the usage of this column be very limited as it will not be supported in the near future

Assigned property ID and item ID

Y Additional columns required in source table. Queried against CZ_ITEM_PROPERTY_VALUES.PROPERTY_ID and CZ_ITEM_PROPERTY_VALUES.ITEM_ID.

Disposition:

■ if found - M■ if not found - I

Table A–9 Description of Fields in CZ_IMP_ITEM_TYPE Import Table

COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

ITEM_TYPE_ID N Y NUMBER Designates an OC Identifier for the item type


Describes this item type

NAME N Y VARCHAR2 (255)

Contains the name of the Item Type



COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables

Import Tables A-13







Unique identification of a record in this table. Contains a foreign surrogate-key value matchingCZ_ITEM_TYPES.ORIG_SYS_REF.

Disposition:■ if found - M■ if not found - I■ if not unique - R-DUPL■ if null - R-N11
















COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables











LAST_UPDATE_DATE



LAST_UPDATED_BY




Table A–10 Description of Fields in CZ_IMP_ITEM_TYPE_PROPERTY Import Table

COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

ITEM_TYPE_ID N Y NUMBER Designates an OC identifier for an item type

PROPERTY_ID N Y NUMBER Contains the OC property ID for an item type




COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables

Import Tables A-15








Reserved for future use.





















COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables


LAST_UPDATE_DATE



LAST_UPDATED_BY




FSK_ITEMTYPE_1_1

Y N VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_ITEM_TYPES.ORIG_SYS_REF.

Disposition:

■ if found - assign item type ID■ if not found - R-F22■ if not unique - R-DUPL■ if null - R-N22

FSK_ITEMTYPE_1_EXT

N Y VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_IMP_ITEM_TYPE on USER_STR03

FSK_PROPERTY_2_1

Y N VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_PROPERTIES.ORIG_SYS_REF.

Disposition:

■ if found - assign property ID■ if not found - R-F24■ if not unique - R-DUPL■ if null - R-N24

FSK_PROPERTY_2_EXT

N Y VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_IMP_PROPERTY on USER_STR03. Note: It is recommended that the usage of this column be very limited as it will not be supported in the near future

Assigned property ID and item type ID

Y Additional columns required in source table. Queried against CZ_ITEM_TYPE_PROPERTIES.PROPERTY_ID and CZ_ITEM_TYPE_PROPERTIES.ITEM_TYPE_ID.

Disposition:

■ if found - M■ if not found - I


COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables

Import Tables A-17

Table A–11 Description of Fields in CZ_IMP_PROPERTY Import Table

COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

PROPERTY_ID N Y NUMBER Designates an OC Identifier for the property

PROPERTY_UNIT N Y VARCHAR2 (8)

Indicates the units in which this property is measured or allocated


Describes this property

NAME Y N VARCHAR2 (255)

Contains the name of the Property. Disposition if null - ERR

DATA_TYPE Y N NUMBER Indicates the data type that this property bears. Disposition if null - ERR

DEF_VALUE N Y VARCHAR2 (255)

Records a default value for the property








Unique identification of a record in this table. Contains a foreign surrogate-key value matchingCZ_PROPERTIES.ORIG_SYS_REF.

Disposition:



Import Tables
























LAST_UPDATE_DATE



LAST_UPDATED_BY




Table A–11 Description of Fields in CZ_IMP_PROPERTY Import Table

COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables

Import Tables A-19

Table A–12 Description of Fields in CZ_IMP_PS_NODE Import Table

COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

PS_NODE_ID N Y NUMBER Designates an OC Identifier for the model node

DEVL_PROJECT_ID

N Y NUMBER Contains the OC development project ID for this record

FROM_POPULATOR_ID

N Y NUMBER Set when the node is created by a populator; designates the OC identifier for the populator that created this record

PROPERTY_BACKPTR

N Y NUMBER Set when the node is created by a populator; identifies the property from which this record was created

ITEM_TYPE_BACKPTR

N Y NUMBER Set when the node is created by a populator; identifies the item type of the populator that created this record

INTL_TEXT_ID N Y NUMBER Contains the OC international text ID for this record

SUB_CONS_ID N Y NUMBER Currently not used

ITEM_ID N Y NUMBER Contains the OC item ID for this record

NAME N Y VARCHAR2 (255)

Contains the OC name for the model node (i.e. component, feature, etc.)

RESOURCE_FLAG N Y CHAR (1) Indicates that this node is a Total or Resource

INITIAL_VALUE N Y VARCHAR2 (255)

Records the initial value for this node when instantiated in a configuration

PARENT_ID N Y NUMBER Contains the OC identifier for the parent node

MINIMUM N Y NUMBER (16,9)

Contains the minimum selection requirement

MAXIMUM N Y NUMBER (16,9)

Contains the maximum selection requirement

PS_NODE_TYPE Y N NUMBER Contains a numeric identification of the node’s type such as component, feature, etc. Disposition if null - ERR

FEATURE_TYPE N Y NUMBER Contains the data type of the feature node

PRODUCT_FLAG N Y CHAR (1) Contains a flag indicating that the node is a parent node

Import Tables


REFERENCE_ID N Y NUMBER Contains a reference to a project structure subtree for which this PS node is a surrogate. Note: Referencing is not currently supported

MULTI_CONFIG_FLAG

N Y CHAR (1) Indicates node children can be configured separately

ORDER_SEQ_FLAG

N Y CHAR (1) Indicates the component is a ordered sequence

SYSTEM_NODE_FLAG

N Y CHAR (1) Indicates this record is a system node, i.e. either root node or template for roots

TREE_SEQ Y N NUMBER Contains the order of this child node within the parent. Disposition if null - ERR

COUNTED_OPTIONS_FLAG

N Y CHAR (1) Indicates this feature has counted options

UI_OMIT N Y CHAR (1) Indicates whether or not the node is visible in the UI

UI_SECTION N Y NUMBER Indicates in which section of the UI the node is visible

BOM_TREATMENT

N Y NUMBER Indicates how BOM should be enumerated during configuration order generation


Unique identification of a record in this table. Contains a foreign surrogate-key value matching CZ_PS_NODES.ORIG_SYS_REF.

Disposition:







COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables

Import Tables A-21

























LAST_UPDATE_DATE




COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables


LAST_UPDATED_BY




FSK_INTLTEXT_1_1

Y N (see description)

VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_INTL_TEXTS.TEXT_STR.

Disposition:

■ if found - assign international text ID■ if not found - R-F44 (except model and project structure nodes)■ if null - R-N44 (Only Model and Project Structure nodes are

nullable.)

FSK_INTLTEXT_1_EXT

N Y VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_IMP_INTL_TEXT on USER_STR03. Note: It is recommended that the usage of this column be very limited as it will not be supported in the near future

FSK_ITEMMASTER_2_1

Y Y VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_ITEM_MASTERS.ORIG_SYS_REF.

Disposition:

■ if found - assign item ID■ if not found - R-F46 (except model and project structure nodes)

FSK_ITEMMASTER_2_EXT

N Y VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_IMP_ITEM_MASTER on ORIG_SYS_REF. Note: It is recommended that the usage of this column be very limited as it will not be supported in the near future

FSK_PSNODE_3_1 Y N (see description)

VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_PS_NODES.ORIG_SYS_REF.

Disposition:

■ if found - assign parent Project Structure node ID■ if not found - R-F48 (except model nodes)■ if null - R-N48.(Only Model nodes are nullable.)

FSK_PSNODE_3_EXT

N Y VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_IMP_PS_NODE on USER_STR03. Note: It is recommended that the usage of this column be very limited as it will not be supported in the near future


COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables

Import Tables A-23

FSK_PSNODE_4_1 N Y VARCHAR2 (255)

Currently not used

FSK_PSNODE_4_EXT

N Y VARCHAR2 (255)

Currently not used

FSK_DEVLPROJECT_5_1

Y N VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_DEVL_PROJECTS.ORIG_SYS_REF.

Disposition:

■ if found - assign development project ID■ if not found - R-F50■ if null - R-N50

FSK_DEVLPROJECT_5_EXT

N Y VARCHAR2 (255)

Contains a foreign surrogate-key value matching CZ_IMP_DEVL_PROJECT on USER_STR03. Note: It is recommended that the usage of this column be very limited as it will not be supported in the near future

COMPONENT_SEQUENCE_ID

N Y NUMBER Component sequence identifier from BOM explosions

COMPONENT_CODE

N Y VARCHAR2 (1000)

Contains the path from the root BOM node

PLAN_LEVEL N Y NUMBER For internal use only. Indicates the depth of this node in the BOM structure. Disposition if null - ERR

BOM_ITEM_TYPE N Y NUMBER Indicates whether this node is a Model, Standard, or OptionClass BOM node

SO_ITEM_TYPE_CODE

N Y VARCHAR2 Describes the application’s item type for ordering: model, class, kit, standard

MINIMUM_SELECTED

N Y NUMBER For OptionClass nodes, indicates the minimum quantity selection for its children

MAXIMUM_SELECTED

N Y NUMBER For OptionClass nodes, indicates the maximum quantity selection for its children

BOM_REQUIRED N Y CHAR (1) Contains a flag indicating that this node is required for BOM


COLUMN_NAME Req

uir

ed

Nu

llab

le

DA

TA_T

YP

E

Description

Import Tables


Glossary of Terms-1

Glossary of Terms

This glossary for Oracle Configurator is followed by a Glossary of Acronyms

Active Model

The part of Oracle Configurator runtime architecture that processes model structure and rules to create configurations. Interfaces dynamically with the end user Active UI and data.

Active User Interface

The part of Oracle Configurator runtime architecture that provides the graphical views necessary to create configurations interactively. Interfaces with the Active Model and data to give users access to customer requirements gathering, product selection, and customer-centric extensions.

Applet

A Java application running inside a web browser. See also Java and Servlet.

Application Architecture

The software structure of an application at runtime. Architecture affects how an application is used, maintained, extended, and changed.

Architecture

The software structure of a system. Architecture affects how a system is used, maintained, extended, and changed. See also Application Architecture.

Glossary of Terms-2

Beta

An external release, delivered as an installable application, and subject to system, validation, and acceptance testing. Specially selected and prepared end users may participate in beta testing.

Bill of Material

A list of component items associated with a parent item (assembly) and information about how each item relates to the parent item.

BOM

See Bill of Material.

BOM Item

The nodes imported into the Oracle Configurator Developer Model that correspond to an Oracle BOM.

BOM Model

The imported Model node in the Oracle Configurator Developer that corresponds to Standard Model in an Oracle BOM.

BOM OptionClass

The imported Model node in the Oracle Configurator Developer that corresponds to Option Class in an Oracle BOM.

BOM StandardItem

The imported Model node in the Oracle Configurator Developer that corresponds to Standard Item in an Oracle BOM.

Boolean Expression

An element of a component in the Model that has two options: true or false.

Bug

See Defect.

Build

A specific instance of an application during its construction. A build must have an install early in the project so that application implementers can unit test their latest work in the context of the entire available application.

Glossary of Terms-3

CIO

See Oracle Configuration Interface Object.

Client

A runtime program using a server to access functionality shared with other clients.

Comparison Rule

An Oracle Configurator Developer rule type to establish a relationship that determines the selection state of a logical item (option, boolean feature, or list-of-options feature) based on a comparison of two numeric values (numeric features, totals, resources, option counts, or numeric constants). The numeric values being compared can be computed or they can be discrete intervals in a continuous numeric input.

Compatibility Rule

An Oracle Configurator Developer rule type to establish a relationship among features in the Model that specifies the allowable combinations of options. See also, Property-based Compatibility Rule.

Compatibility Table

A type of compatibility relationship where the allowable combination of options are explicitly enumerated.

Component

Represents a configurable element in a product. An element of the Model structure, typically containing features. May correspond to one screen of selections in an Oracle runtime configurator.

Component Set

An element of the Model that contains a number of components of the same type, where each component of the set is independently configured.

Concurrent Manager

A process manager that coordinates the concurrent processes generated by users’ concurrent requests. An Oracle Applications product group can have several concurrent managers.

Glossary of Terms-4

Concurrent Process

A task that can be scheduled and is run by a concurrent manager. A concurrent process runs simultaneously with interactive functions and other concurrent processes.

Concurrent Processing Facility

An Oracle Applications facility that runs time-consuming, non-interactive tasks in the background.

Concurrent Program

Executable code (usually written in SQL*Plus or Pro*C) that performs the function(s) of a requested task.

Concurrent Request

A user-initiated request issued to the concurrent processing facility to submit a non-interactive task, such as running a report.

Configuration

A specific set of specifications for a product, resulting from selections made in an Oracle runtime configurator.

Configuration Model

The model structure and rules-based content of an Oracle runtime configurator. The configuration model is constructed and maintained using Oracle Configurator Developer, and is interpreted at runtime by the Active Model.

Configuration Rules

The Oracle Configurator Developer logic rules and numeric rules available for defining configurations.

Configurator

The part of an application that provides custom configuration capabilities.

Constraint Rule

An Oracle Configurator Developer rule type to create a logical relationship among features and options. See also Rules.

Glossary of Terms-5

Contributes to

An Oracle Configurator Developer numeric rule type for accumulating a total value.

Consumes from

An Oracle Configurator Developer numeric rule type for specifying the quantity of a resource used.

CRM

Customer Relationship Management. The aspect of the enterprise that involves contact with customers, from lead generation to support services.

Customer

The person or persons for whom products are configured by end users of the Oracle Configurator or other ERP and CRM applications.

Customer-centric Extensions

See Customer-centric Views.

Customer-centric Views

Optional extensions to core functionality that supplement product selection with rules for pre-selection, validation, and intelligent views. View capabilities include generative geometry, drawings, sketches and schematics, charts, performance analyses, and ROI calculations.

Customer Requirements

The needs of the customer that serve as the basis for determining the configuration of products, systems, and/or services. Also called Needs Assessment.

Data Import

Populating the Oracle Configurator schema with enterprise data from ERP or legacy systems via import tables.

Data Integration Object

Data Integration Object. A server in the runtime application that creates and manages the interface between the client (usually a user interface like the Active User Interface) and the Oracle Configurator schema.

Glossary of Terms-6

Data Maintenance Environment

The environment in which the Oracle runtime configurator data is maintained.

Data Replication

The activity of downloading and uploading configuration, quote, and order data between the Oracle Configurator schema on the enterprise server and Oracle Configurator Mobile Database on end-user mobile laptop PCs. See also Data Synchronization.

Datasource

A programmatic reference to a database. Referred to by a datasource name, or DSN.

Data Synchronization

A process for matching the data in the Oracle Configurator schema and the data available to client processes such as the Oracle SellingPoint application. See also Data Replication.

Default

The automatic selection of an option based on the pre-selection rules or the selection of another option.

Defaults

An Oracle Configurator Developer logic rule to determine the logic state of features or options in a default relation to other features and options. For instance, if you set A to True by selecting it, B becomes true (selected) if it is available (not false) and can be set to True without contradicting a non-default rule or a previous default setting for B.

Defect

A failure in a product to satisfy the users’ requirements. Defects are prioritized as critical, major, or minor, and fixes range from corrections or workarounds to enhancements. Also known as a “bug”.

Defect Tracking

A system of identifying defects for managing additional tests, testing, and approval for release to users.

Deliverable

A work product that is specified for review and delivery.

Glossary of Terms-7

Demonstration

A presentation of the tested application, showing a particular usage scenario.

Design Chart

An Oracle Configurator Developer rule type for defining advanced Explicit Compatibilities interactively in a chart view.

Design Review

A technical review that focuses on application or system design.

Developer

The tool (Oracle Configurator Developer) used to create configuration models. The person who uses Oracle Configurator Developer to create a configurator. See also Implementer.

DIO

See Data Integration Object.

End User

The ultimate user of the Oracle runtime configurator. The types of end users vary by project but may include salespeople or distributors, administrative office staff, marketing personnel, order entry personnel, product engineers, or customers directly accessing the application via web or kiosk.

Enterprise

The systems and resources of a business.

Environment

The arena in which software tools are used, such as operating system, applications, and server processes.

ERP

Enterprise Resource Planning. A software system and process that provides automation for the customer’s back-room operations, including order processing.

Excludes

An Oracle Configurator Developer rule type for determining the logic state of features or options in an excluding relation to other features and options. For instance, if you set A to True, B becomes false, since it is not allowed when A is true.

Glossary of Terms-8

If you set A to False, there is no effect on B, meaning it could be true, false, or unknown.

Extended Functionality

A release after delivery of core functionality that extends that core functionality with customer-centric views, more complex proposal generation, discounting, quoting, and expanded integration with ERP, CRM, and third-party software.

Feature

An element of the Model structure. A configurable parameter of a component. Features can either have a value (numeric or boolean) or enumerated options.

Functional Companion

An object associated with a component that supplies methods that can be used to initialize, validate and generate customer-centric views and outputs for the configuration.

Functional Specification

Document describing the functionality of the application based on user requirements.

Incremental Construction

The process of organizing the construction of the application into builds, where each build is designed to meet a specified portion of the overall requirements and is unit tested.

Implementation

The stage in a project between defining the problem by selecting a configuration technology vendor, such as Oracle, and deploying the completed sales configuration application. The Implementation stage includes gathering requirements, defining test cases, designing the application, constructing and testing the application, and delivering it to users.

Implementer

The person who uses Oracle Configurator Developer to build the model structure, rules, and UI customizations that make up an Oracle runtime configurator.

Implies

An Oracle Configurator Developer logic rule type that determines the logic state of features or options in an implied relation to other features and options. For instance,

Glossary of Terms-9

if you set A to True by selecting it, B becomes true, since selecting A implies that B is also selected. If you set A to False by deselecting it, there is no effect on B, meaning it could be true false or unknown based on other relations B participates in. And if you set B to True by selecting it, there is no effect on A, meaning it could be true false or unknown based on other relations A participates in. But if you set B to False by deselecting it, the relation of A implies B is preserved only by having A be false (deselected) as well.

Import Tables

Tables mirroring the Oracle Configurator schema Item Master structure, but without integrity constraints. Import Tables allow batch population of the Oracle Configurator schema Item Master. Import Tables are used in conjunction with extractions from Oracle Applications or legacy data to create, update, or delete records in the Oracle Configurator schema Item Master.

Install

A program that sets up the local machine and installs the application for testing and use.

Integration

The process of combining multiple software components and making them work together.

Integration Testing

Testing the interaction among software programs that have been integrated into an application or system.

Intelligent Views

Configuration output, such as reports, graphs, schematics, and diagrams, that help to illustrate the value proposition of what is being sold.

Item Master

A table in the Oracle Configurator schema containing data used to structure the product. Data in the item master is either entered manually or imported from Oracle Applications or legacy data.

Item Type

A table in the Oracle Configurator schema containing data used to classify the product data in the item master table.

Glossary of Terms-10

Java

An object-oriented programming language commonly used in internet applications, where Java applications run inside web browsers and servers. See also Applet and Servlet.

Log File

A file containing errors, warnings and other information output by the running application.

Logic Rules

Logic rules directly or indirectly set the logical state (true, false, or unknown) of features and options in the Model.

There are four (4) primary logic rules: Implies, Requires, Excludes, and Negates. Each of these rules takes a list of features or options as operands. See also Logic, Implies, Requires, Excludes, and Negates.

Maintainability

The characteristic of a product or process to allow straightforward maintenance, alteration, and extension. Maintainability must be built into the product or process from inception.

Maintenance

The effort of keeping a system running once it has been deployed, through bug fixes, procedure changes, infrastructure adjustments, data replication schedules, etc.

Maintenance Guide

A guide for maintaining a specific application or system. The maintenance guide covers all aspects of maintenance described in the generic Maintenance Plan.

Maintenance Plan

A document that outlines what is required for successful maintenance, and who is responsible for all the actions and deliverables of carrying out maintenance on a system.

MDUI

See Model-driven UI.

Mobile Database

See Oracle Configurator Mobile Database.


Model

The entire hierarchical “tree” view of all the data required for configurations, including model structure, variables such as resources and totals, and elements in support of intermediary rules. May consist of BOM Items.

Model-driven UI

The graphical views of the model structure and rules generated by the Active UI to present end users with interactive product selection based on configuration models.

Model Structure

Hierarchical, “tree” view of data in terms of product elements (Models, Products Components, Features, Options, BOM Models, BOM OptionClasses, BOM StandardItems, Resources, and Totals). May include reusable components.

MRP

Manufacturing Resource Planning. A software system and process for monitoring and maintaining the customer's manufacturing systems.

Negates

An Oracle Configurator Developer logic rule type that determines the logic state of features or options in a negating relation to other features and options. For instance, if you set one item in the relationship to True, the other item must be false. And if you set one item to False, the other item must be true.

Node

The place in a Model occupied by a component, feature, option or variable, BOM Model, BOM OptionClass, or BOM StandardItem.

Numeric Rules

Rules that are used to set the global parameters specified in product structuring. See also, Contributes to and Consumes from.

OC

See Oracle Configurator.

Opportunity

The workspace in the Oracle SellingPoint application and Oracle Sales Online in which products, systems, and/or services are configured, quotes and proposals are generated, and orders are submitted.


Option

An element of the Model. A choice for the value of an enumerated feature.

A logical selection made by the end user when configuring a component.

Oracle Configurator

The product family consisting of development tools and runtime applications such as Oracle Configurator schema, Oracle Configurator Developer, run-time Oracle Configurator, and Oracle SellingPoint application. Also the Oracle runtime configurator variously packaged for use in networked, mobile, or web deployments.

Oracle Configurator Architecture

The application runtime architecture consists of the Active User Interface, the Active Model, and the Oracle Configurator schema or Oracle Configurator Mobile Database. The application development architecture consists of Oracle Configurator Developer and the Oracle Configurator schema, with test instances of an Oracle runtime configurator.

Oracle Configurator Developer

The suite of tools in the Oracle Configurator product family for constructing and maintaining configurators.

Oracle Configuration Interface Object (CIO)

A server in the runtime application that creates and manages the interface between the client (usually a user interface like the Active User Interface) and the underlying representation of model structure and rules in the Active Model.

CIO protocols support creating and navigating the Model, querying and modifying selection states, and saving and restoring configurations.

Oracle Configurator Mobile Database

The runtime version of the standard Oracle Configurator schema that manages data for the configuration model in a mobile deployment. The runtime schema includes customer, product, and pricing data as well as data created during operation of an Oracle Configurator.

Oracle Configurator Schema

The implementation version of the standard Oracle runtime configurator data-warehousing schema that manages data for the configuration model. The


implementation schema includes all the data required for the runtime system as well as specific tables used during the construction of the configurator.

Oracle SellingPoint Application

The test application generated by Oracle Configurator Developer. Also a full configuration environment with opportunity management, quotes, and proposals for networked or mobile deployments.

Output

The output generated by a configurator, such as quotes, proposals, bills of material (BOM), and customer-centric views.

PDM

Product Data Management. A software system that manages the version control of product data.

Populator

An entity in the Oracle Configurator Developer that defines how to create a Model from information in the item master.

Pre-selection

The default state in a configurator that defines an initial selection of components, features, and options for configuration.

A process that is implemented to select the initial element(s) of the configuration.

Principal Design Consultant

Member of the project team responsible for architecting the design of the application.

Product

Whatever is subjected to configuration and is the output of the application.

The root element of the Model.

Product Family

A collection of products or product lines, which are organized as a group by a provider or manufacturer.


Project

The workspace in Oracle Configurator Developer in which configurators are constructed

Project Manager

A member of the project team who is responsible for directing the project during implementation.

Project Plan

A document that outlines the logistics of successfully implementing the project, including the schedule.

Property

A named value associated with an object in the Model or the item master. A set of properties may be associated with an item type.

Property-based Compatibility Rule

A kind of compatibility relationship where the allowable combinations of options are specified implicitly by relationships among property values of the options.

Prototype

A construction technique in which a preliminary version of the application, or part of the application, is built to facilitate user feedback, to prove feasibility or examine other implementation issues.

Reference

The use of a reusable component within the Model. Not implemented in Release 11i or before.

Regression Test

An automated test that ensures the newest build still meets previously tested requirements and functionality.

Requires

An Oracle Configurator Developer logic rule type that determines the logic state of features or options in a requirement relation to other features and options. For instance, if you set one item in the relationship to True, the other item is required to be true as well. And if you set one item to False, the other item must be false as well.


Resource

Staff or materials available or needed within an enterprise.

A variable in the Model used to maintain the balance of features not consuming more of a specific resource than has been provided by other features.

Reusable Component

A component that is referenced from multiple locations in the Model. Not implemented in Release 11i or before.

Reusability


System

The hardware and software components and infrastructure integrated to satisfy functional and performance requirements.

Test Case

A description of inputs, execution instructions, and expected results, which are created for the purpose of determining whether a specific software feature works correctly or a specific requirement has been met.

Total

A variable in the Model used to accumulate a numeric total, such as total price or total weight.

Undetermined

The logic state that is neither true nor false, but unknown at the time a logic rule is executed. This logic state is also referred to as Available, especially when considered from the point of view of the Oracle runtime configurator end user.

Unit Test

Execution of individual routines and modules by the application implementer or by an independent test consultant for the purposes of finding defects.

Update

Moving a production configurator to a new version of configuration model.

Upgrade

Moving the configurator to a new release of Oracle Configurator.

User

The person using the Oracle Configurator Developer tools and methods to build an Oracle runtime configurator. See also end user.

User Interface

The visible part of the application, including menus, dialog boxes, and other on-screen elements. The part of a system where the user interacts with the software.

User Requirements

A description of what the Oracle Configurator or Oracle SellingPoint application is expected to do from the end user’s perspective.


User’s Guide

Documentation on using the application or configurator to solve the intended problem.

Validation

Tests that ensure that the configured components will meet specific performance or acceptance criteria.

A type of functional companion that is implemented to ensure that the configured components will meet specific performance or acceptance criteria.

Variable

Parts of the Model that are represented by Totals, Resources, or numeric Features.

Verification

Tests that check whether the result agrees with the specification.

Glossary of Acronyms-1

Glossary of Acronyms

API

Application Programming Interface

ATP

Available to Promise

BOM

Bill of Material

CIO

Configuration Interface Object

CM

Configuration Management

COM

Component Object Model

CRM

Customer Relationship Management

DBMS

Database Management System

DCOM

Distributed Component Object Modeling


DHTML

Dynamic Hypertext Markup Language

DIO

Data Integration Object

DLL

Dynamically Linked Library

DXF

Drawing Exchange Format (AutoCAD drawings)

ECO

Engineering Change Order

ERM

Enterprise Relationship Management

ERP

Enterprise Resource Planning

ESD

Electronic Software Distribution

ESP

External Service Provider

ESS

Enterprise Selling System

HT

High Tech

HTML

Hypertext Markup Language

IP

Industrial Products


IS

Information Services

ISS

Interactive Selling System

ISV

Independent Software Vendor

LAN

Local Area Network

MAPI

Messaging Application Programming Interface

MC/S

Mobile Client/Server System

MDUI

Model-Driven User Interface

MES

Marketing Encyclopedia System (Catalog)

MIS

Management Information Systems

MRP

Manufacturing Resource Planning

MS

Microsoft

OC

Oracle Configurator

OCX

Object Control File, OLE custom controls


ODBC

Open Database Connectivity

OLE

Object linking and embedding

OMS

Opportunity Management System

OOD

Object-Oriented Design

ORB

Object Request Broker

PDM

Product Data Management

PIA

Project Impact Assessment

POS

Point of Sale

QA

Quality Assurance

RAD

Rapid Application Development

RDBMS

Relational Database Management System

RFQ

Request for Quote

ROI

Return on Investment


SAS

Sales Analysis System

SCM

Supply Chain Management

SCS

Sales Configuration System

SE

Sales Engineer

SFA

Sales Force Automation

SI

System Integrator

SOT

Strategic Options Theory

SQA

Software Quality Assurance

SQL

Structured Query Language

TERM

Technology-Enabled Relationship Management

TES

Technology-Enabled Selling

UI

User Interface

VAR

Value-Added Reseller


VB

Microsoft Visual Basic

WAN

Wide Area Network

WIP

Work In Progress

Index-1

IndexAActive Model

definition, 1–10Oracle Configurator LC subschema, 3–2upgrade, 1–10

Active UIdefinition, 1–10

AOL (Applications Object Library), 7–5AOL/J, 7–5applet, 7–1application

publication applicability parameter, 6–6application id

applid, 2–5applications

state, 7–6applid

parameter in spx.ini, 2–5

BBadItemPropertyValue

CZ_DB_SETTING for import, 3–9description, 3–9disposition codes, 3–9

BatchSizeCZ_DB_SETTING for SCHEMA, 3–7

BILL_REVISION_DATEin CZ_XFR_PROJECT_BILLS, 4–8

BOMsee also Bills of Materialconfigure directly, 1–3import root, 4–10

imported, 1–3imported data, 4–10

BOM_EXPLOSIONSdata refresh, 3–9data transfer source, 4–10DESCRIPTION field in CZ_INTL_TEXTS, 4–9source field from, 3–8

BOM_REVISIONCZ_DB_SETTING for Oracle Applications

integration, 3–8browser

requirements for DHTML configurator, 7–2

CCIO, 1–11client/server environment

deploymentCommitSize

CZ_DB_SETTING for direct import, 3–10COMPONENT_ITEM_ID

in CZ_XFR_PROJECT_BILLS, 4–7concurrent processes

Define Remote Server, 1–14Disable/Enable Refresh of a Configuration

Model, 4–17Enable Remote Server, 1–14Export Data for a Single Publication, 6–9Export Data for All Published Models, 6–10for editing Oracle Configurator settings, 3–10for import, 4–12for publication, 6–9for server administration, 1–12Import Model Bills, 4–15

Index-2

Modify Configurator Parameters, 3–11Modify Server Definition, 1–15Process a Single Publication, 6–9Process Pending Publications, 6–10Purge Configurator Tables, 3–13query registered processes, 1–18Refresh a Single Configuration Model, 4–17Refresh All Previously Imported Models, 4–17running Server Administration processes, 1–15Select Tables to be Imported, 4–24, 4–29Show Tables to be Imported, 4–25View Configurator Parameters, 3–11View Servers, 1–15view status of, 1–16view submitted requests, 1–16

ConfigurationOracle Configurator CF subschema, 3–2

Configuration Interface Object, see CIO

Configuratorsee also DHTML configuratorsee also Java applet configuratorsee also Oracle Configurator windowsee also Oracle SellingPoint applicationarchitecture, 1–10installations, 1–5parameters

modifying, 3–11viewing, 3–12

requirements for installation, 1–5Configure

button, 5–2, 7–8connection cache, 7–5control tables

see CZ_XFR control tablescookies

DHTML configurator requirement, 7–2COPY_ADDL_CHILD_MODELS

in CZ_XFR_PROJECT_BILLS, 4–8CZ:Publication Mode

profile option, 6–11CZ:Usage Names

profile option, 6–12CZ_ATP_REQUESTS

table in CZ schema - CF subschema, 3–2

CZ_COMBO_FEATURESrefreshing, 4–17table in CZ schema - PS subschema, 3–3

CZ_CONFIG_HDRStable in CZ schema - CF subschema, 3–2

CZ_CONFIG_INPUTStable in CZ schema - CF subschema, 3–2

CZ_CONFIG_ITEMStable in CZ schema - CF subschema, 3–2

CZ_CONFIG_MESSAGEStable in CZ schema - CF subschema, 3–2

CZ_CONFIG_USAGEStable in CZ schema - CF subschema, 3–2

CZ_DB_LOGSTABLE IN cz SCHEMA - GN subschema, 3–2

CZ_DB_SETTINGSBadItemPropertyValue, 3–5Batchsize, 3–5BOM_REVISION, 3–5CommitSize, 3–5for IMPORT, 3–9for ORAAPPS_INTEGRATE, 3–8for SCHEMA, 3–7FREEZE_REVISION, 3–5MAJOR_VERSION, 1–22, 3–5MaximumErrors, 3–5MINOR_VERSION, 1–22, 3–5MULTISESSION, 3–6OracleSequenceIncr, 3–6PsNodeName, 3–6RefPartNbr, 3–6ResolvePropertyDataType, 3–7Revison Date/User, 3–7RUN_BILL_EXPLODER, 3–7table in CZ schema - GN subschema, 3–2

CZ_DB_SETTINGS table, 1–6, 3–4export settings, 3–9schema version, 1–21

CZ_DB_SIZEStable in CZ schema - GN subschema, 3–2

CZ_DES_CHART_CELLSrefreshing, 4–17table in CZ schema - PS subschema, 3–3

CZ_DES_CHART_FEATUREStable in CZ schema - PS subschema, 3–3

Index-3

CZ_DEVL_PROJECTSrefreshing, 4–17table in CZ schema - PS subschema, 3–3transferred data, 4–10

CZ_EFFECTIVITY_SETStable in CZ schema - PB subschema, 3–3

CZ_EXPRESSION_NODESrefreshing, 4–17table in CZ schema - PS subschema, 3–3

CZ_EXPRESSIONSrefreshing, 4–17table in CZ schema - PS subschema, 3–3

CZ_FILTER_SETSrefreshing, 4–17table in CZ schema - PS subschema, 3–3

CZ_FUNC_COMP_REFStable in CZ schema - PS subschema, 3–3

CZ_FUNC_COMP_SPECSrefreshing, 4–17table in CZ schema - PS subschema, 3–3

CZ_GRID_CELLSrefreshing, 4–17table in CZ schema - PS subschema, 3–3

CZ_GRID_COLSrefreshing, 4–18table in CZ schema - PS subschema, 3–3

CZ_GRID_DEFSrefreshing, 4–18table in CZ schema - PS subschema, 3–3

CZ_INTL_TEXTS, 4–9refreshing, 4–18table in CZ schema - PS subschema, 3–3transferred data, 4–10

CZ_ITEM_MASTERSrefreshing, 4–18table in CZ schema - IM subschema, 3–2transferred data, 4–10

CZ_ITEM_PARENTStable in CZ schema - IM subschema, 3–2

CZ_ITEM_PROPERTY_VALUESrefreshing, 4–18table in CZ schema - IM subschema, 3–2

CZ_ITEM_TYPE_PROPERTIESrefreshing, 4–18table in CZ schema - IM subschema, 3–2

CZ_ITEM_TYPESrefreshing, 4–18table in CZ schema - IM subschema, 3–2

CZ_LCE_CLOBStable in CZ schema - LC subschema, 3–2

CZ_LCE_HEADERSrefreshing, 4–18table in CZ schema - LC subschema, 3–2

CZ_LCE_LINEStable in CZ schema - LC subschema, 3–2

CZ_LCE_OPERANDStable in CZ schema - LC subschema, 3–2

CZ_LCE_TEXTSrefreshing, 4–18table in CZ schema - LC subschema, 3–3

CZ_MODEL_PUBLICATIONSpublications tables, 6–10table in CZ schema - PB subschema, 3–3

CZ_MODEL_REF_EXPLStable in CZ schema - PS subschema, 3–3

CZ_MODEL_USAGESpublications tables, 6–10table in CZ schema - PB subschema, 3–3

CZ_PB_CLIENT_APPSpublications tables, 6–10table in CZ schema - PB subschema, 3–3

CZ_PB_MODEL_EXPORTSpublications tables, 6–10table in CZ schema - PB subschema, 3–3

CZ_PB_TEMP_IDStable in CZ schema - PB subschema, 3–3

CZ_POPULATOR_MAPSrefreshing, 4–18table in CZ schema - PS subschema, 3–3

CZ_POPULATORSrefreshing, 4–18table in CZ schema - PS subschema, 3–3

CZ_PRICING_STRUCTURES, 5–4table in CZ schema - CF subschema, 3–2

CZ_PROPERTIESrefreshing, 4–18table in CZ schema - IM subschema, 3–2

CZ_PS_NODES, 3–8refreshing, 4–18table in CZ schema - PS subschema, 3–3

Index-4

transferred data, 4–10CZ_PS_PROP_VALS

refreshing, 4–18table in CZ schema - PS subschema, 3–3

CZ_PS_PROPCOMPAT_GENtable in CZ schema - PS subschema, 3–3

CZ_PUBLICATION_USAGESpublications tables, 6–10table in CZ schema - PB subschema, 3–3

CZ_REL_TYPESrefreshing, 4–18table in CZ schema - IM subschema, 3–2

CZ_RP_ENTRIEStable in CZ schema - RP subschema, 3–3

CZ_RULESrefreshing, 4–18table in CZ schema - PS subschema, 3–3

CZ_RULES_FOLDERSrefreshing, 4–18table in CZ schema - PS subschema, 3–3

CZ_SERVERStable in CZ schema - RP subschema, 3–4

CZ_SUB_CON_SETSrefreshing, 4–18table in CZ schema - PS subschema, 3–3

CZ_TERMINATE_MSGStable in CZ schema - CF subschema, 3–2

CZ_UI_DEFSrefreshing, 4–18table in CZ schema - UI subschema, 3–4

CZ_UI_NODE_PROPSrefreshing, 4–18table in CZ schema - UI subschema, 3–4

CZ_UI_NODESrefreshing, 4–18table in CZ schema - UI subschema, 3–4

CZ_UI_PROPERTIESrefreshing, 4–18table in CZ schema - UI subschema, 3–4

CZ_XFR control tablesOracle Configurator XF subschemause with scripts and concurrent programs, 4–8

CZ_XFR_FIELD_REQUIREStable in CZ schema - XF subschema, 3–4

CZ_XFR_FIELDS, 4–9

table in CZ schema - XF subschema, 3–4CZ_XFR_PRICE_LISTS

table in CZ schema - XF subschema, 3–4CZ_XFR_PROJECT_BILLS, 3–9, 4–7, 4–9

table in CZ schema - XF subschema, 3–4CZ_XFR_RUN_INFOS

table in CZ schema - XF subschema, 3–4CZ_XFR_RUN_RESULTS

table in CZ schema - XF subschema, 3–4CZ_XFR_STATUS_CODES

table in CZ schema - XF subschema, 3–4CZ_XFR_TABLES

table in CZ schema - XF subschema, 3–4cz.activemodel, 5–5, 5–6, 5–8cz.activemodel.lazyloadlistprice, 5–5

Ddata extraction

setup, 4–27data import, 4–12data transfer

file for generic import, 4–28file format, 4–28

database instanceconnect to, 1–21definition, 1–4

database ownersee also DBOwnerdefinition, 1–4

date rangepublication applicability parameter, 6–6

DB_SETTINGS, see CZ_DB_SETTINGSDBC file, 7–5DBOwner

definition, 1–4in spx.ini, 2–2

DELETED_FLAGin CZ_XFR_PROJECT_BILLS, 4–7

deploymentclient/server, 1–8DHTML, 7–2Java applet, 7–2requirements for web, 7–1web, 1–8, 7–1

Index-5

DESCRIPTIONin CZ_XFR_PROJECT_BILLS, 4–7

Design Chartsection in the spx.ini file, 2–5settings, 2–5

Developerspx.ini parameters, 2–3

DHTML (Dynamic HTML), 7–1DHTML configurator

browser requirements, 7–2cookies, 7–2deployment of, 7–2essential components, 7–2recommended screen resolution, 7–2

Disable/Enable Refresh of a Configuration Model, 4–19

disposition codesBadItemPropertyValue, 3–9import tables, A–3

EEFF_FROM

in CZ_XFR_PROJECT_BILLS, 4–8EFF_TO

in CZ_XFR_PROJECT_BILLS, 4–8effectivity

and publishing, 6–12effectivity date

for planning publications, 6–2effectivity sets

for planning publications, 6–2end user

definition, 1–5EXPLOSION_TYPE

in CZ_XFR_PROJECT_BILLS, 4–8

Ffeature

symbol in Design Chart, 2–5field disposition codes, A–3firewalls

effect on servlet connections, 7–6interference with application, 7–6

FND_APPLICATIONSpublications tables, 6–11

FND_JDBC_MAX_WAIT_TIME, 7–6FND_MAX_JDBC_CONNECTIONS, 7–5Foreign Surrogate Key, A–2FREEZE_REVISION

CZ_DB_SETTING for SCHEMA, 3–8

Ggateway username

gwyuid, 2–4General Use tables

Oracle Configurator GN subschema, 3–2Generate Active Model

after schema upgrade, 1–10generic import, see importgwypass

parameter in spx.ini, 2–4gwyuid

parameter in spx.ini, 2–4

IIMPORT

CZ_DB_SETTINGS, 3–4import

control tables, 4–3custom, 4–1, 4–25dependencies among tables, A–2execution, 3–9from Oracle Applications 10.7 or 11.0, 1–2generic, 4–26, 4–29online tables, 3–1order of, 1–7, A–1schedule during deployment, 1–9schedule during development, 1–8setup for generic, 4–26setup process, 4–11single tables, A–2

import tablesclearing, 4–3definition, 3–1field disposition codes, A–3record status codes, A–3

Index-6

RUN_ID, 4–7importing

re-importing BOMs with component models, 4–20

InitCodeBaseUrlparameter in the spx.ini file, 2–6

init.ora file, 7–5InitServletURL

parameter in the spx.ini file, 2–6installations

deployment, 1–8development, 1–6maintenance, 1–9scenarios, 1–6test, 1–8types of, 1–5

instancedefinition, 1–4

Internet Explorer, 7–2Item-Master

Oracle Configurator IM subschema, 3–2

JJava

applet, 7–1Java applet

deployment of, 7–2JavaScript

enabled for DHTML configurator, 7–2JDBC, 7–5JdbcUrl

parameter in spx.ini, 2–3, 2–4

LLAST_IMPORT_DATE

in CZ_XFR_PROJECT_BILLS, 4–7LAST_IMPORT_RUN_ID

in CZ_XFR_PROJECT_BILLS, 4–7Launch

parameter in the spx.ini file, 2–6Logic for Configuration, see Active Modellost publications

due to failed source database, 6–14

due to failed target database, 6–14due to instance failure, 6–13

Mmaintenance

PURGE, 3–13REDO_SEQUENCES, 3–13

MAJOR_VERSIONCZ_DB_SETTING for SCHEMA, 3–8

MaximumErrorsCZ_DB_SETTING for direct import, 3–10

Merlinsee Developersection in the spx.ini file, 2–1

Microsoft, 7–2MINOR_VERSION

CZ_DB_SETTING for SCHEMA, 3–8MODEL_PS_NODE_ID

in CZ_XFR_PROJECT_BILLS, 4–8MTL_DESCR_ELEMENT_VALUES

data transfer source, 4–10MTL_DESCRIPTIVE_ELEMENTS

data transfer source, 4–10MTL_ITEM_CATALOG_GROUPS

data transfer source, 4–10MTL_SYSTEM_ITEMS

data transfer source, 4–10MULTISESSION

CZ_DB_SETTING for direct import, 3–10

NNetscape Navigator, 7–2networked environment, see client/server

environment

Oonline tables, 3–1Options Selection window, 5–2ORAAPPS_INTEGRATE

CZ_DB_SETTINGS, 3–4Oracle Applications

10.7, 1–2

Index-7

11.0, 1–2Oracle Configurator

see also Configuratorintegration in Oracle Applications, 1–3, 1–6release upgrade, 1–10

Oracle Configurator Schema, A–2Oracle Configurator schema

characteristics, 3–1publishing a production version, 4–17purging, 1–8, 3–13redoing sequences, 3–13settings, see CZ_DB_SETTINGSsubschemas, 3–1synonyms, 3–1tables to refresh for publication, 4–17updates, 4–17verifying version, 1–21

Oracle Configurator windowarchitecture, 1–10deployment upgrades, 1–10

Oracle Order Managementintegrated with an Oracle runtime

Configurator, 1–3OracleSequenceIncr

CZ_DB_SETTING for SCHEMA, 3–8ORGANIZATION_ID, 4–9

in CZ_XFR_PROJECT_BILLS, 4–7

Pperformance

pricing interface package, 5–3prices_calculated_flag, 5–4pricing

adjustments, 5–3architecture, 5–3CZ_PRICING_STRUCTURES table, 5–4discounts, 5–3editing, 5–3in an Oracle Configurator window, 5–1interface package

definition of, 5–2performance impacts, 5–8types of, 5–2

Pricing Display

setting attribute with Oracle Configurator Developer, 5–5, 5–7, 5–8

profile optionsCZ:Publication Mode, 6–11CZ:Usage Names, 6–12

Project StructureOracle Configurator PS subschema, 3–3

PsNodeNameCZ_DB_SETTING for Oracle Applications

integration, 3–8Publication

Oracle Configurator PB subschema, 3–3publication

creating, 6–9defining, 6–3planning, 6–1process, 6–2tables used for, 6–10

publication applicability parameters, 6–5application, 6–3, 6–6date range, 6–3, 6–6publication mode, 6–3, 6–5usages, 6–3, 6–7

publication attributesdatabase instance, 6–3, 6–5model, 6–3, 6–4product, 6–3, 6–4UI definition, 6–3, 6–5

publication modepublication applicability parameter, 6–5

publicationsdeleting, 6–13disabling, 6–13editing, 6–13lost, 6–13of configuration models, 6–1re-enabling, 6–13updating, 6–12

publications tables, 6–10publish

list of tables, 4–17production Oracle Configurator schema, 4–17

publishingconfiguration models, 6–1planning, 6–1

Index-8

PURGEconcurrent processes, 3–13DB maintenance package, 3–13

Rrecord status codes, A–3

import tables, A–3REDO_SEQUENCES

DB maintenance package, 3–13invoked by scripts, 3–13

REF_PART_NBR, 4–9referencing

and publishing, 6–12RefPartNbr

CZ_DB_SETTING for Oracle Applications integration, 3–8

refreshlist of tables, 4–17production Oracle Configurator schema, 4–17

Refresh a Single Configuration Model, 4–19Refresh All Previously Imported Models, 4–20refreshing

models with references, 4–20remote server

define, enable, or modify, 1–13Repository

Oracle Configurator RP subschema, 3–3ResolvePropertyDataType

CZ_DB_SETTING for property import, 3–9respid

parameter in spx.ini, 2–5responsibility id

respid, 2–5Revision Date/User

CZ_DB_SETTING for SCHEMA, 3–8rollback segment, 3–7RUN_BILL_EXPLODER

CZ_DB_SETTING for direct import, 3–9data refresh, 3–9

SSCHEMA

CZ_DB_SETTINGS, 3–4

schemadefinition, 1–4subschemas, 3–1verifying version, 1–21

Selected Items window, 5–2sequences

reset increments, 3–13server

definition, 1–4SOURCE_BILL_DELETED

in CZ_XFR_PROJECT_BILLS, 4–7SOURCE_SERVER

in CZ_XFR_PROJECT_BILLS, 4–8spx.ini file

example, 2–1parameters for development and testing, 2–2

stateful application, 7–6stickiness

effect on servlet connections, 7–7router property, 7–6

Stylesheetsenabled for DHTML configurator, 7–2

Summary button, 5–2Summary window, 5–2

TTCP/IP

time limit, 7–6Test

button in Developer, 2–6section in the spx.ini file, 2–6

timeoutsdatabase connection, 7–6JServ

default, 7–6router, 7–7

TOP_ITEM_ID, 4–8in CZ_XFR_PROJECT_BILLS, 4–7

Transfer specifications, see CZ_XFR control tables

UUI Servlet

properties, 5–5, 5–6, 5–8

Index-9

updatelist of tables to, 4–17production Oracle Configurator schema, 4–17

Update Prices button, 5–2upgrade

Oracle Configurator release, 1–10regenerate Active Model to, 1–10

URLsee also InitServletURL, 2–6runtime Oracle Configurator requirement, 2–6

usagesand initialization message, 6–8defining, 6–7for planning publications, 6–2publication applicability parameter, 6–7

usersee also end userdefinition, 1–5

User InterfaceOracle Configurator UI subschema, 3–4

Vverify

data import, 4–16schema version, 1–21

Wweb

deployment, 1–8, 7–1

XXFR_ control tables, see CZ_XFR control tables

Index-10