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. Oracle Configurator Implementation Guide, Release 11i
Part No. A87531-01
Copyright © 1996, 2001, Oracle Corporation. All rights reserved.
Primary Author: Denise Boyer
Contributing Authors: Mark Sawtelle, Tina Brand
Contributors: Ashot Khachatryan, Serge Kudravtsev, Sarit Manna, Helen Reznik, Michael Sheehy, Alexander Siaston, Andrew Wolfe
The Programs (which include both the software and documentation) contain proprietary information of Oracle Corporation; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs is prohibited.
Program Documentation is licensed for use solely to support the deployment of the Programs and not for any other purpose.
The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. Oracle Corporation does not warrant that this document is error free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Oracle Corporation.
If the Programs are delivered to the U.S. Government or anyone licensing or using the programs on behalf of the U.S. Government, the following notice is applicable:
Restricted Rights Notice Programs delivered subject to the DOD FAR Supplement are "commercial computer software" and use, duplication, and disclosure of the Programs, including documentation, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement. Otherwise, Programs delivered subject to the Federal Acquisition Regulations are "restricted computer software" and use, duplication, and disclosure of the Programs shall be subject to the restrictions in FAR 52.227-19, Commercial Computer Software - Restricted Rights (June, 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and Oracle Corporation disclaims liability for any damages caused by such use of the Programs.
Oracle is a registered trademark, and Oracle Application Object Library, SQL*Net, SQL*Loader, SQL*Plus, Net8, SellingPoint, Oracle8, and Oracle8i are trademarks or registered trademarks of Oracle Corporation. Other names may be trademarks of their respective owners. Contents
List of TablesFigures
Send Us Your Comments ...... xi
Preface...... xiii Intended Audience ...... xiii Structure...... xiii Related Documents...... xiv Conventions...... xv Product Support...... xv
1 Introduction 1.1 Run-time Oracle Configurators...... 1–1 1.2 Oracle Configurator Schema...... 1–2 1.3 Overview of Oracle Configurator Implementation...... 1–2 1.3.1 Concurrent Programs ...... 1–3 1.4 Terms...... 1–4 1.5 Requirements ...... 1–5 1.6 Oracle Configurator Environments ...... 1–5 1.6.1 Development...... 1–6 1.6.2 Testing...... 1–8 1.6.3 Production...... 1–8 1.6.4 Maintenance...... 1–9 1.7 Oracle Configurator Architecture Overview ...... 1–10 1.8 Implementation Tasks ...... 1–11
iii 1.8.1 Commonly Performed Implementation Tasks ...... 1–12 1.8.1.1 Server Administration ...... 1–12 1.8.1.2 View the Status of Oracle Configurator Concurrent Process Requests ...... 1–16 1.8.1.3 Query Registered Oracle Configurator Concurrent Programs ...... 1–18 1.8.1.4 Connect to a Database Instance...... 1–21 1.8.1.5 Verify Oracle Configurator Schema Version ...... 1–21
2 The Spx.ini File 2.0.1 Parameters in spx.ini...... 2–2 2.0.1.1 [Merlin] ...... 2–3 2.0.1.2 [DSN] ...... 2–3 2.0.1.3 [dsn]...... 2–4 2.0.1.4 [Design Chart]...... 2–5 2.0.1.5 [Test]...... 2–6
3 The Oracle Configurator Schema 3.1 Characteristics of the Oracle Configurator Schema...... 3–1 3.1.1 CF Configuration...... 3–2 3.1.2 GN General Use Tables ...... 3–2 3.1.3 IM Item-Master ...... 3–2 3.1.4 LC Logic for Configuration (Active Model)...... 3–2 3.1.5 PB Publication...... 3–3 3.1.6 PS Project Structure...... 3–3 3.1.7 RP Repository ...... 3–3 3.1.8 UI User Interface (Active UI)...... 3–4 3.1.9 XF Transfer Specifications and Control ...... 3–4 3.2 Oracle Configurator Schema Settings...... 3–4 3.2.1 CZ_DB_SETTINGS for SCHEMA...... 3–7 3.2.2 CZ_DB_SETTINGS for ORAAPPS_INTEGRATE ...... 3–8 3.2.3 CZ_DB_Settings for IMPORT...... 3–9 3.3 Editing the CZ_DB_SETTINGS Values ...... 3–10 3.3.1 Modify Configurator Parameters...... 3–11 3.3.2 View Configurator Parameters...... 3–12 3.4 Oracle Configurator Schema Maintenance...... 3–12 3.4.1 Refresh or Update the Production Schema ...... 3–12
iv 3.4.2 PURGE...... 3–13 3.4.3 Redo Sequences ...... 3–13
4 Importing Data 4.1 Data Import Overview...... 4–1 4.1.1 Import Tables...... 4–3 4.1.1.1 Import Control Fields...... 4–3 4.1.1.2 Online Data Fields ...... 4–4 4.1.1.3 Surrogate Key Fields...... 4–4 4.1.2 Control Tables (CZ_XFR_)...... 4–5 4.2 The Import Process...... 4–9 4.3 Data Imported into the Oracle Configurator Schema...... 4–10 4.4 Data Import Setup...... 4–11 4.5 Importing Data From Oracle Applications...... 4–12 4.6 Data Import Concurrent Processes ...... 4–12 4.6.1 Importing from Oracle Bills of Material ...... 4–13 4.6.1.1 Enabling a Server for Import...... 4–14 4.6.1.2 Exploding BOMs in Oracle Applications ...... 4–14 4.6.1.3 Running the Import Concurrent Process...... 4–15 4.7 Verify Data Import...... 4–16 4.8 Refresh and Update Imported Data ...... 4–16 4.8.1 Enable or Disable Refresh ...... 4–19 4.8.2 Refresh a Single Configuration Model...... 4–19 4.8.3 Refresh All Imported Configuration Models...... 4–20 4.9 Re-importing/Refreshing BOM Models with Component Models...... 4–20 4.9.1 Scenarios for Re-importing/Refreshing BOM Models with Component Models...... 4–20 4.9.1.1 Scenario 1 - Initial Import of BOM Model...... 4–21 4.9.1.2 Scenario 2 - Re-Import/Refresh of Initial BOM Model ...... 4–21 4.9.1.3 Scenario 3 - Import New BOM Model with References to Existing BOM Models. 4–22 4.10 Customizing Data Import ...... 4–23 4.10.1 Importing Specific Tables...... 4–24 4.10.2 Importing Specific Fields of CZ_XFR_TABLES...... 4–25 4.10.3 Modifying CZ_XFR_PROJECT_BILLS.EXPLOSION_TYPE...... 4–25
v 4.10.4 Creating a Custom Import ...... 4–25 4.10.4.1 Setup for a Custom Import ...... 4–26 4.10.4.2 Extraction Setup for a Custom Import...... 4–27 4.10.4.3 Required ASCII File Format for Custom Import...... 4–28 4.10.4.4 Running a Custom Import...... 4–29
5 Pricing in Oracle Configurator 5.1 Pricing in a Run-time Oracle Configurator...... 5–1 5.1.1 Pricing Interaction in the User Interfaces ...... 5–2 5.1.1.1 Pricing Interaction in the Java Applet User Interface ...... 5–2 5.1.1.2 Pricing Interaction in the DHTML User Interface...... 5–2 5.1.2 General Pricing Behavior ...... 5–3 5.2 Run-time Oracle Configurator Pricing Architecture...... 5–3 5.3 Controlling Pricing in the Run-time Oracle Configurator...... 5–5 5.3.1 Displaying Price Types...... 5–6 5.3.1.1 Setting the OC Servlet Property for Price Types ...... 5–6 5.3.1.2 Setting the Item Price Display in Oracle Configurator Developer ...... 5–7 5.3.2 Updating Price Data...... 5–8 5.3.2.1 Setting the OC Servlet Property for Price Updating ...... 5–8 5.3.2.2 Setting the Price Update in Oracle Configurator Developer ...... 5–8 5.3.3 Examples of Controlling Pricing ...... 5–9 5.3.3.1 Example: List Prices Only ...... 5–9 5.3.3.2 Example: Selling Prices Only...... 5–9
6 Publishing Configuration Models 6.1 Overview of Publishing Configuration Models...... 6–1 6.1.1 Planning Publications ...... 6–1 6.1.2 The Publication Process...... 6–2 6.2 Defining the Publication...... 6–3 6.2.1 Publication Attributes...... 6–3 6.2.1.1 Product...... 6–4 6.2.1.2 Model ...... 6–4 6.2.1.3 Database Instance...... 6–5 6.2.1.4 User Interface...... 6–5 6.2.2 Publication Applicability Parameters...... 6–5
vi 6.2.2.1 Publication Mode ...... 6–5 6.2.2.2 Application ...... 6–6 6.2.2.3 Date Range ...... 6–6 6.2.2.4 Usages...... 6–7 6.3 Creating the Publication...... 6–9 6.3.1 Publishing a Single Pending Configuration Model ...... 6–9 6.3.2 Publishing All Pending Configuration Models ...... 6–10 6.4 Tables Used in Publishing...... 6–10 6.5 Profile Options Used in Publishing ...... 6–11 6.5.1 Setting Profile Options ...... 6–11 6.6 Publishing and Effectivity...... 6–12 6.7 Publishing and Referencing...... 6–12 6.8 Updating or Republishing Publications...... 6–12 6.9 Editing Publications...... 6–13 6.10 Disabling, Deleting, and Re-enabling Publications...... 6–13 6.11 Lost Publications Due to Instance Failure ...... 6–13 6.11.1 Failed Target Database ...... 6–14 6.11.2 Failed Source Database...... 6–14
7 Deploying Oracle Configurator 7.1 Calling an Embedded Oracle Configurator ...... 7–1 7.1.1 Java Applet Requirements ...... 7–2 7.1.2 DHTML Requirements...... 7–2 7.2 Deployment Strategies...... 7–3 7.2.1 Architectural Considerations ...... 7–3 7.2.2 Server Considerations ...... 7–4 7.2.2.1 Connection Pooling ...... 7–5 7.2.3 Network Considerations...... 7–6 7.2.3.1 Firewalls and Timeouts...... 7–6 7.2.3.2 Router Timeouts...... 7–6 7.2.3.3 Miscellaneous Issues...... 7–7 7.3 Deployment Tasks...... 7–7 7.3.1 Setting Profile Options ...... 7–7 7.3.2 Establishing End User Access ...... 7–8 7.3.3 Load Testing...... 7–8
vii 7.3.3.1 Stress Testing ...... 7–8 7.3.3.2 User Activity Testing...... 7–8 7.3.4 Load Balancing ...... 7–9
A Import Tables A.1 Overview...... A–1 A.2 List of Import Tables ...... A–1 A.3 Dependencies Among Import Tables...... A–2 A.4 Import Tables ...... A–3
Glossary of Terms
Glossary of Acronyms Index
viii List of Figures 1–1 Development Installation...... 1–7 1–2 Production Installation ...... 1–9 1–3 Overview of Oracle Configurator Architecture...... 1–11 1–4 Implementation Task Flow ...... 1–12 4–1 Overview of Data Import ...... 4–2 4–2 Overview of Data Import from Oracle Bills of Material...... 4–12 4–3 Initial Import of BOM Model with Component Models ...... 4–21 4–4 Re-Import/Refresh of Initial BOM Model...... 4–21 4–5 Import a New BOM Model with References to Existing BOM Models ...... 4–22 4–6 Overview of Custom Import ...... 4–27 4–7 Extraction Setup for a Custom Import ...... 4–27 5–1 Run-time Oracle Configurator Pricing Architecture...... 5–4
ix List of Tables
1–1 Oracle Configurator Concurrent Programs for Server Administration ...... 1–14 3–1 CZ_DB_SETTINGS...... 3–5 3–2 Oracle Configurator Administration Concurrent Programs...... 3–11 4–1 Import Control Fields...... 4–3 4–2 CZ_XFR_TABLES Fields ...... 4–5 4–3 CZ_XFR_FIELDS Fields...... 4–6 4–4 CZ_XFR_PROJECT_BILLS Fields ...... 4–7 4–5 Oracle Applications Source and Destination Online Tables ...... 4–10 4–6 Properties Imported from Oracle Inventory...... 4–11 6–1 Publication Tables...... 6–10 A–1 Dependencies Among Oracle Configurator Schema Import Tables...... A–2 A–2 Import Table Field Disposition Codes ...... A–3 A–3 Import Table Record Status Codes ...... A–3 A–4 Description of Fields in CZ_IMP_DEVL_PROJECT Import Table...... A–4 A–5 Description of Fields in CZ_IMP_INTL_TEXT Import Table ...... A–6 A–6 Description of Fields in CZ_IMP_ITEM_MASTER Import Table ...... A–7 A–8 Description of Fields in CZ_IMP_ITEM_PROPERTY_VALUE Import Table...... A–10 A–9 Description of Fields in CZ_IMP_ITEM_TYPE Import Table...... A–12 A–10 Description of Fields in CZ_IMP_ITEM_TYPE_PROPERTY Import Table...... A–14 A–11 Description of Fields in CZ_IMP_PROPERTY Import Table...... A–17 A–12 Description of Fields in CZ_IMP_PS_NODE Import Table ...... A–19
x 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.
xi xii 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 Audience This 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.
Structure This 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.
xiii ■ "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 Documents The 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
xiv ■ 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.
Conventions In 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:
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.
Product Support The 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.
xv 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
xvi 1 Introduction
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 Configurators Throughout 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.
Introduction 1-1 Oracle Configurator Schema
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 Schema The 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 Implementation This 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.
1-2 Oracle Configurator Implementation Guide Overview of Oracle Configurator Implementation
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 Programs Oracle 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)
Introduction 1-3 Terms
■ Define a remote server (see "Server Administration" on page 1-12)
■ Enable a remote server (see "Server Administration" on page 1-12)
■ View servers (see "Server Administration" on page 1-12)
■ Modify server definitions (see "Server Administration" on page 1-12)
■ Process all published configuration models (see Section 6.3.2, "Publishing All Pending Configuration Models" on page 6-10)
■ Process a single publication (see Section 6.3.1, "Publishing a Single Pending Configuration Model" on page 6-9)
■ Import Bills (see Section 4.6.1, "Importing from Oracle Bills of Material" on page 4-13)
■ Refresh all imported configuration models (see Section 4.8.3, "Refresh All Imported Configuration Models" on page 4-20)
■ Disable or enable the refresh of a configuration model (see Section 4.8.1, "Enable or Disable Refresh" on page 4-19)
■ Show or select specific tables to be imported (see Section 4.10.1, "Importing Specific Tables" on page 4-24)
1.4 Terms Oracle and Oracle Configurator use specific terminology to refer to the concepts and components of databases and applications. Oracle8i Enterprise Edition, the Oracle RDBMS required by Oracle Applications, is installed, set up, and started as an Oracle Server. An Oracle Server consists of one or more Oracle database instances. A database instance consists of memory and processes that manage a single, self-contained collection of data. An instance provides controlled access to the user(s) of the database. An Oracle database is a collection of data treated as a unit. It has logical and physical structures. The logical structures are the schema objects (tables, views, stored procedures, database links). The physical structures include the datafiles and log files. Datafiles contain all of a database’s data, including physical data, that is used to build up the logical structures. A schema in a database is a collection of database objects. There can be multiple schemas in a single database. A schema (all the objects that make up a schema) takes the name of its owner (also called a database owner or DBOwner). In Oracle
1-4 Oracle Configurator Implementation Guide Oracle Configurator Environments
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 Requirements All 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 Environments The 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
Introduction 1-5 Oracle Configurator Environments
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 Development A 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.
1-6 Oracle Configurator Implementation Guide Oracle Configurator Environments
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
Introduction 1-7 Oracle Configurator Environments
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 Testing A 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 Production A 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.
1-8 Oracle Configurator Implementation Guide Oracle Configurator Environments
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 Maintenance A 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
Introduction 1-9 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.
Warning: Do not run Oracle Configurator Developer and the Generate Active Model command against a deployed production Oracle Configurator schema.
1.7 Oracle Configurator Architecture Overview No 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.
1-10 Oracle Configurator Implementation Guide Implementation Tasks
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 Tasks In 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.
Introduction 1-11 Implementation Tasks
Figure 1–4 Implementation Task Flow
1.8.1 Commonly Performed Implementation Tasks This 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.
1-12 Oracle Configurator Implementation Guide Implementation Tasks
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.
Introduction 1-13 Implementation Tasks
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 Remote Server - select from the list of values or enable a remote server for import. Loads (or enter the name of the server entry to enable. links in) the list of remote BOMs into the "FOREIGN" (-1) and the local server (0) are not local instance for use by the Import Bill allowed parameters. Models concurrent process. Password - password for the Oracle Applications schema (FNDNAM) on this remote server.
1-14 Oracle Configurator Implementation Guide Implementation Tasks
Table 1–1 Oracle Configurator Concurrent Programs for Server Administration
Configurator Concurrent Process Description Parameters
Modify Server Definition Allows the user to modify a remote server Local Name - local name by which to refer to this definition. 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 None. concurrent process log.
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
Introduction 1-15 Implementation Tasks
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 Requests Since 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.
1-16 Oracle Configurator Implementation Guide Implementation Tasks
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.
Introduction 1-17 Implementation Tasks
f
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.
1.8.1.3 Query Registered Oracle Configurator Concurrent Programs As 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.
1-18 Oracle Configurator Implementation Guide Implementation Tasks
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.
Introduction 1-19 Implementation Tasks
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.
1-20 Oracle Configurator Implementation Guide Implementation Tasks
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 Instance Certain 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
SQL> connect
where
Or connect to the database instance as a user with DBA privileges: Example:
SQL> connect
2. Connect to the instance
1.8.1.5 Verify Oracle Configurator Schema Version The 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"
Introduction 1-21 Implementation Tasks
The result for this Release 11i should be MAJOR_VERSION = 15, MINOR_ VERSION = i.
1-22 Oracle Configurator Implementation Guide 2 The 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=apps JdbcUrl=jdbc:oracle:thin:@ctra-sunserver:1523:DHTMLTest
[DSN] DHTMLTest JavaTest
[DHTMLTest] DBOwner=apps JdbcUrl=jdbc:oracle:thin:@ap320sun:1623:DHTMLTest gwyuid=APPLSYSPUB gwypass=PUB APPLID=660 RESPID=21623
[JavaTest] DBOwner=apps JdbcUrl=jdbc:oracle:thin:@ap320sun:1623:JavaTest gwyuid=APPLSYSPUB
The Spx.ini File 2-1 gwypass=PUB
[Design Chart] DEF=M, N, A, T SEC=X, Y, Z
[Test] Launch=2 InitServletURL=http://ap882sun.us.oracle.com:10130/servlets/oracle.apps.cz.servl et.UiServlet InitCodeBaseUrl=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
2-2 Oracle Configurator Implementation Guide 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]").
The Spx.ini File 2-3 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=DBOwner JdbcUrl=Jdbc_connection gwyuid=gateway_user_id gwypass=gateway_password applid=application_id respid=responsibility_id
Note: The DBOwner setting here overrides the DBOwner setting in the section [Merlin]. The DBOwner settings under [Merlin]are defaults.
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
2-4 Oracle Configurator Implementation Guide 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.
The Spx.ini File 2-5 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
Note: The InitCodeBaseUrl is used for testing a Java applet or running a Java applet from a stand alone web page only.
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 .
2-6 Oracle Configurator Implementation Guide 3 The 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 Schema The 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 - Configuration GN - General Use tables IM - Item-Master LC - Logic for Configuration (Active Model) PB - Publication
The Oracle Configurator Schema 3-1 Characteristics of the Oracle Configurator Schema
PS - Project Structure RP - Repository UI - User Interface XF - 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 Configuration CZ_ATP_REQUESTS CZ_CONFIG_HDRS CZ_CONFIG_INPUTS CZ_CONFIG_ITEMS CZ_CONFIG_MESSAGES CZ_CONFIG_USAGES CZ_PRICING_STRUCTURES CZ_TERMINATE_MSGS
3.1.2 GN General Use Tables CZ_DB_LOGS CZ_DB_SETTINGS CZ_DB_SIZES
3.1.3 IM Item-Master CZ_ITEM_MASTERS CZ_ITEM_TYPES CZ_PROPERTIES CZ_ITEM_TYPE_PROPERTIES CZ_ITEM_PROPERTY_VALUES CZ_REL_TYPES CZ_ITEM_PARENTS
3.1.4 LC Logic for Configuration (Active Model) CZ_LCE_CLOBS CZ_LCE_HEADERS CZ_LCE_LINES CZ_LCE_OPERANDS
3-2 Oracle Configurator Implementation Guide Characteristics of the Oracle Configurator Schema
CZ_LCE_TEXTS
3.1.5 PB Publication CZ_EFFECTIVITY_SETS CZ_MODEL_PUBLICATIONS CZ_MODEL_USAGES CZ_PB_CLIENT_APPS CZ_PB_MODEL_EXPORTS CZ_PB_TEMP_IDS CZ_PUBLICATION_USAGES
3.1.6 PS Project Structure CZ_DEVL_PROJECTS CZ_PS_NODES CZ_FUNC_COMP_SPECS CZ_FUNC_COMP_REFS CZ_MODEL_REF_EXPLS CZ_PS_PROP_VALS CZ_PS_PROPCOMPAT_GEN CZ_INTL_TEXTS CZ_RULES CZ_RULES_FOLDERS CZ_DES_CHART_CELLS CZ_DES_CHART_FEATURES CZ_POPULATORS CZ_POPULATOR_MAPS CZ_FILTER_SETS CZ_EXPRESSIONS CZ_EXPRESSION_NODES CZ_COMBO_FEATURES CZ_GRID_DEFS CZ_GRID_COLS CZ_GRID_CELLS CZ_SUB_CON_SETS CZ_POPULATOR_MAPS
3.1.7 RP Repository CZ_RP_ENTRIES
The Oracle Configurator Schema 3-3 Oracle Configurator Schema Settings
CZ_SERVERS
3.1.8 UI User Interface (Active UI) CZ_UI_DEFS CZ_UI_NODES CZ_UI_PROPERTIES CZ_UI_NODE_PROPS
3.1.9 XF Transfer Specifications and Control CZ_XFR_PROJECT_BILLS CZ_XFR_PRICE_LISTS CZ_XFR_TABLES CZ_XFR_FIELDS CZ_XFR_RUN_INFOS CZ_XFR_RUN_RESULTS CZ_XFR_STATUS_CODES CZ_XFR_FIELD_REQUIRES
3.2 Oracle Configurator Schema Settings The 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: SCHEMA ORAAPPS_INTEGRATE IMPORT
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.
3-4 Oracle Configurator Implementation Guide Oracle Configurator Schema Settings
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_ any string Null Indicates the BOM revision in the INTEGRATE 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.
The Oracle Configurator Schema 3-5 Oracle Configurator Schema Settings
Table 3–1 CZ_DB_SETTINGS
Setting_ID Section_name Data_type Default Value Relevance and Contribution
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_ ‘Segment1’ (or Null Indicates the source field to be loaded INTEGRATE Description) 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_ ‘Segment1’ (or Segment1 Identifies the field to be used for the INTEGRATE Description) 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-6 Oracle Configurator Implementation Guide Oracle Configurator Schema Settings
Table 3–1 CZ_DB_SETTINGS
Setting_ID Section_name Data_type Default Value Relevance and Contribution
ResolvePropertyDataType ORAAPPS_ YES/NO NO Indicates whether Catalog Descriptive INTEGRATE 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_ YES/NO YES Indicates whether or not the import INTEGRATE process invokes the BOM_EXPLODER procedure. This explodes the BOMs before the import process extracts data.
3.2.1 CZ_DB_SETTINGS for SCHEMA The 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
The Oracle Configurator Schema 3-7 Oracle Configurator Schema Settings
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_INTEGRATE The 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.
3-8 Oracle Configurator Implementation Guide Oracle Configurator Schema Settings
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 IMPORT The 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
The Oracle Configurator Schema 3-9 Editing the CZ_DB_SETTINGS Values
Value Disposition ’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
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
3-10 Oracle Configurator Implementation Guide 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.
Table 3–2 Oracle Configurator Administration Concurrent Programs
Configurator Concurrent Process Description Parameters
Modify Configurator Sets values for the settings Section Name - from the list of values, select the name of the Parameters in the CZ_DB_SETTINGS section in the Oracle Configurator cz_db_settings table where the table in the Oracle setting resides. Configurator schema. 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 Writes the values of the Section Name - from the list of values, select the name of the Parameters specified Oracle section in the Oracle Configurator cz_db_settings table where the Configurator schema setting resides. settings to the concurrent Setting - from the list of values, select the setting in the Oracle process log. Configurator cz_db_settings table.
3.3.1 Modify Configurator Parameters Use the following procedure to modify configurator parameters: 1. Log into Oracle Applications under the Configurator Administrator responsibility. 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.
The Oracle Configurator Schema 3-11 Oracle Configurator Schema Maintenance
3.3.2 View Configurator Parameters Use 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 Schema Once 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
3-12 Oracle Configurator Implementation Guide Oracle Configurator Schema Maintenance
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 PURGE Oracle 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: 1. Log into Oracle Applications under the Configurator Administrator responsibility. 2. Select Configurator > Configurator Administration > Purge Configurator Tables. There are no parameters required for this concurrent process.
3.4.3 Redo Sequences If 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).
The Oracle Configurator Schema 3-13 Oracle Configurator Schema Maintenance
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.
3-14 Oracle Configurator Implementation Guide 4 Importing 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 Overview You 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.
Importing Data 4-1 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
4-2 Oracle Configurator Implementation Guide Data Import Overview
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 Tables The 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 Fields Import 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
Importing Data 4-3 Data Import Overview
Table 4–1 Import Control Fields Field Name Type Description 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 = Insert M = Modify N = No change R = Rejected Null indicates not yet known
4.1.1.2 Online Data Fields Online 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 Fields Surrogate 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
4-4 Oracle Configurator Implementation Guide Data Import Overview
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 Used to name and group sequences (20) 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 Identifies the name of the source (30) table in the import subschema. DST_TABLE NO VARCHAR Contains the name of the (30) destination online table. DST_SUBSCHEMA NO INTEGER Identifies the subschema in which the destination online tables resides. FILTERSYNTAX NO VARCHAR Limits the records imported from (255) 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).
Importing Data 4-5 Data Import Overview
Table 4–2 CZ_XFR_TABLES Fields Field Name Required Type Description 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.
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.
Table 4–3 CZ_XFR_FIELDS Fields Field Name Required Type Description XFR_GROUP YES VARCHAR Used to name and group sequences (20) 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 VARCHAR Name of the originating field. 2(40) DST_FIELD NO VARCHAR Name of the destination field. 2(40) REQUIRED NO CHAR(1) If "1", this field is required by the online table. DEFAULTSYNTAX NO VARCHAR Not currently supported. Future 2(255) 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.
4-6 Oracle Configurator Implementation Guide Data Import Overview
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 Field Name Required Type Description ORGANIZATION_ID YES NUMBER Identifies the organization ID that identifies this item in Oracle Applications. COMPONENT_ITEM_ NO NUMBER Provides the item ID that ID identifies this item in Oracle Applications. DESCRIPTION NO VARCHAR2 Most recent description of (255) this item. LAST_IMPORT_RUN_ NO NUMBER Identifies the import run in ID 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_ NO CHAR(1) If ’1’, Indicates that this bill DELETED 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.
Importing Data 4-7 Data Import Overview
Table 4–4 CZ_XFR_PROJECT_BILLS Fields Field Name Required Type Description EXPLOSION_TYPE NO (by VARCHAR2 Determines how the BOM default) (10) 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_ VARCHAR2 Indicates whether or not child MODELS 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.
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_
4-8 Oracle Configurator Implementation Guide The Import Process
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 Process BOM 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:
Importing Data 4-9 Data Imported into the Oracle Configurator Schema
Table 4–5 Oracle Applications Source and Destination Online Tables Oracle Applications Source Oracle Configurator Schema Destination Table --> Online Table(s) BOM_EXPLOSIONS --> CZ_PS_NODES, CZ_DEVL_PROJECTS, CZ_ INTL_TEXTS MTL_SYSTEM_ITEMS --> CZ_ITEM_MASTERS MTL_DESCRIPTIVE_ --> CZ_PROPERTIES ELEMENTS MTL_ITEM_CATALOG_ --> CZ_ITEM_TYPES GROUPS MTL_DESCR_ELEMENT_ --> CZ_ITEM_PROPERTY_VALUES VA LU ES
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 Schema BOM 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
4-10 Oracle Configurator Implementation Guide Data Import Setup
■ quantity cascade Properties from Oracle Inventory item catalogs such as descriptive elements and values can also be imported and used in Oracle Configurator Developer.
Table 4–6 Properties Imported from Oracle Inventory correspond to the following in Oracle The following in Oracle Inventory... Configurator Developer Item catalog group Item type Catalog descriptive element Item property Catalog descriptive element value Property value
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 Setup Import 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.
Importing Data 4-11 Importing Data From Oracle Applications
4.5 Importing Data From Oracle Applications Oracle 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
4-12 Oracle Configurator Implementation Guide Data Import Concurrent Processes
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 Material If 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)
Importing Data 4-13 Data Import Concurrent Processes
3. Run the import concurrent process (see "Running the Import Concurrent Process" on page 4-15)
4.6.1.1 Enabling a Server for Import If 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 Applications If 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.
4-14 Oracle Configurator Implementation Guide Data Import Concurrent Processes
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 Process Use the following procedure to import the BOM models you want to use from the Bills of Material schema into the Oracle Configurator schema: 1. Log into Oracle Applications under either the Configurator Administrator or Configurator Developer responsibility. 2. Select Configurator > Import/Refresh Models > Import Model Bills.
Importing Data 4-15 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 Import Once 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 Data Oracle 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.
4-16 Oracle Configurator Implementation Guide Refresh and Update Imported Data
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 Refreshed CZ_COMBO_FEATURES CZ_DES_CHART_CELLS CZ_DEVL_PROJECTS CZ_EXPRESSIONS CZ_EXPRESSION_NODES CZ_FILTER_SETS CZ_FUNC_COMP_SPECS CZ_GRID_CELLS
Importing Data 4-17 Refresh and Update Imported Data
CZ_GRID_COLS CZ_GRID_DEFS CZ_INTL_TEXTS CZ_ITEM_MASTERS CZ_ITEM_TYPE_PROPERTIES CZ_ITEM_PROPERTY_VALUES CZ_ITEM_TYPES CZ_LCE_HEADERS CZ_LCE_TEXTS CZ_POPULATORS CZ_POPULATOR_MAPS CZ_PROPERTIES CZ_PS_NODES CZ_PS_PROP_VALS CZ_REL_TYPES CZ_RULES CZ_RULES_FOLDERS CZ_SUB_CON_SETS CZ_UI_DEFS CZ_UI_NODES CZ_UI_PROPERTIES CZ_UI_NODE_PROPS
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.
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)
4-18 Oracle Configurator Implementation Guide Refresh and Update Imported Data
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 Refresh Use the following procedure to enable or disable the refresh of a configuration model from the Bills of Material schema into the Oracle Configurator schema: 1. Log into Oracle Applications under either the Configurator Administrator or Configurator Developer responsibility. 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 Model Use the following procedure to refresh a single configuration model in a production Oracle Configurator schema with changes made in a development Oracle Configurator schema: 1. Log into Oracle Applications under either the Configurator Administrator or Configurator Developer responsibility. 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.
Importing Data 4-19 Re-importing/Refreshing BOM Models with Component Models
4.8.3 Refresh All Imported Configuration Models Use the following procedure to refresh all imported configuration models in a production Oracle Configurator schema with changes made in a development Oracle Configurator schema: 1. Log into Oracle Applications under the Configurator Administrator responsibility. 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 Models When 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 Models In 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.
4-20 Oracle Configurator Implementation Guide Re-importing/Refreshing BOM Models with Component Models
4.9.1.1 Scenario 1 - Initial Import of BOM Model If 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 Model In 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
Importing Data 4-21 Re-importing/Refreshing BOM Models with Component Models
4.9.1.3 Scenario 3 - Import New BOM Model with References to Existing BOM Models In 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
4-22 Oracle Configurator Implementation Guide Customizing Data Import
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.
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.
4.10 Customizing Data Import Although 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
Importing Data 4-23 Customizing Data Import
Note: You should always contact your Oracle consultant before attempting any database customization.
■ Creating and performing a custom import of legacy data from non-Oracle Applications databases
4.10.1 Importing Specific Tables You 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: 1. Log into Oracle Applications under the Configurator Administrator responsibility. 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.
4-24 Oracle Configurator Implementation Guide Customizing Data Import
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_TABLES You 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_TYPE You 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 Import Using 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.
Importing Data 4-25 Customizing Data 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_PROJECTS CZ_INTL_TEXTS CZ_ITEM_MASTERS CZ_ITEM_PROPERTY_VALUES CZ_ITEM_TYPES CZ_ITEM_TYPE_PROPERTIES CZ_PROPERTIES CZ_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 Import If 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
4-26 Oracle Configurator Implementation Guide Customizing Data Import
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 Import The process for setting up the extraction portion of a custom import is as follows:
Figure 4–7 Extraction Setup for a Custom Import
Importing Data 4-27 Customizing Data 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 Import For 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|||||||||||||||||||
4-28 Oracle Configurator Implementation Guide Customizing Data Import
||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 Import If 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
Importing Data 4-29 Customizing Data Import
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.
4-30 Oracle Configurator Implementation Guide 5 Pricing 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 Configurator A 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 Oracle Configurator 5-1 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 Interfaces The 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 Interface When 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 Interface When 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
5-2 Oracle Configurator Implementation Guide 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 Behavior The 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.
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.
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 Architecture The 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.
Pricing in Oracle Configurator 5-3 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
5-4 Oracle Configurator Implementation Guide Controlling Pricing in the Run-time Oracle Configurator
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 Controlling Pricing in the Run-time Oracle Configurator You 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.
Pricing in Oracle Configurator 5-5 Controlling Pricing in the Run-time Oracle Configurator
5.3.1 Displaying Price Types
5.3.1.1 Setting the OC Servlet Property for Price Types In 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:
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.
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.
5-6 Oracle Configurator Implementation Guide Controlling Pricing in the Run-time Oracle Configurator
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
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.
5.3.1.2 Setting the Item Price Display in Oracle Configurator Developer If 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:
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.
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.
Pricing in Oracle Configurator 5-7 Controlling Pricing in the Run-time Oracle Configurator
5.3.2 Updating Price Data The 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 Updating In 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.
Note: This property controls the fetching of list prices only, not of selling prices or total price.
5.3.2.2 Setting the Price Update in Oracle Configurator Developer If 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.
5-8 Oracle Configurator Implementation Guide Controlling Pricing in the Run-time Oracle Configurator
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 Pricing This 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 Only The 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.
Property or Setting Value cz.activemodel /lp|/nodp|
Price Display List Prices cz.activemodel.lazyloadlistprice true (probably, depending on application) Price Update any setting
5.3.3.2 Example: Selling Prices Only The 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 /nolp|/dp|
Price Display Selling Prices cz.activemodel.lazyloadlistprice true (or omit altogether) Price Update any setting
Pricing in Oracle Configurator 5-9 Controlling Pricing in the Run-time Oracle Configurator
5-10 Oracle Configurator Implementation Guide 6 Publishing 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 Models Publishing 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 Publications In 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.
Publishing Configuration Models 6-1 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 Process Once 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
6-2 Oracle Configurator Implementation Guide 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 Publication See 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 Attributes A 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)
Publishing Configuration Models 6-3 Defining the Publication
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 Product Product 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.
6-4 Oracle Configurator Implementation Guide Defining the Publication
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 Instance CZ_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 Interface By 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 Defining a publication results in a collection of attributes based on the following parameters:
■ 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)
6.2.2.1 Publication Mode A publication can only have one mode. The valid values are Test, Production, or Disabled. The default value of this parameter is Test. Only publications with the mode Production or Test can be accessed by a calling application.
Publishing Configuration Models 6-5 Defining the Publication
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 Application The 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 Range The 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.
6-6 Oracle Configurator Implementation Guide Defining the Publication
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 Usages The 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.
Publishing Configuration Models 6-7 Defining the Publication
When a configuration model is invoked by Oracle Order Management or iStore, the Usage or Usages provided by the host application determine which parts of the Model are displayed to the end user. Any Model nodes that are not assigned to the Usages specified do not appear in the Configurator run time UI. Usages can be a very powerful tool you can use to manipulate the availability of Model nodes and Model publications, based on a variety of business requirements. Therefore, we recommend that you plan for and implement Usages very carefully when developing configuration models.
6.2.2.4.2 Usages and the Session Initialization Message When setting up the calling application that end users will use to create configurations, you set parameters for the application’s session initialization message. This message includes database connection parameters and other information that invokes the configuration window and identifies a particular Model. When the configuration window is invoked, the hosting application sends the initialization message you defined to the Configurator UI Servlet, which then selects the Model matching the effective date, publication mode, and Usage(s) provided. For example, your company makes and sells cars. The Environmental Protection Agency requires that cars sold in California meet more rigorous emissions guidelines than other states in the U.S. Therefore, you must install a different type of exhaust system on any car sold in California. When defining the configuration models that represent each car you sell, you create a different Component for the two types of exhaust systems. You then create two Usages, CAL-EPA for cars sold in California and US-EPA for cars sold in other states, and assign them to your exhaust system Components. When an end user wants to configure an automobile, the hosting application first collects information about the user, including (in this example) the state in which the car will be sold. The host application uses this information to construct the intialization message. If the car will be sold in California, the CAL-EPA Usage is set in the initialization message. Otherwise, the US-EPA Usage is included. The host application then passes the initialization message to the configurator window, which then selects and displays the Model with the appropriate exhaust system. See the Oracle Configurator Custom Web Deployment Guide for more information about setting intialization message parameters. For information on how Usages affect the availability of model publications, see "Publication Applicability Parameters" on page 6-5.
6-8 Oracle Configurator Implementation Guide Creating the Publication
6.3 Creating the Publication Once 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.
Publishing Configuration Models 6-9 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.
6-10 Oracle Configurator Implementation Guide Profile Options Used in Publishing
Table 6–1 Publication Tables Table Name Description FND_APPLICATIONS Identifies the calling applications that are available for specification in a publications. See "Application" on page 6-6 for details.
For more detailed information about these tables see the Oracle Configurator Technical Reference Manual.
6.5 Profile Options Used in Publishing Oracle 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 Options For information about setting profile options, see the Oracle System Administration Guide.
Profile Option User System Administrator Requirements
User User Resp App Site Required? Default Value
CZ:PUBLICATION_ XXXXXRequiredProduction MODE
CZ:USAGE_NAMESXXXXXRequiredAny
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.
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
Publishing Configuration Models 6-11 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 Effectivity See "Date Range" on page 6-6.
6.7 Publishing and Referencing If 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 Publications Update 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_
6-12 Oracle Configurator Implementation Guide 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 Publications It 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 Publications Publications 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 Failure When 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_
Publishing Configuration Models 6-13 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 Database If 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 Database Prior 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.
6-14 Oracle Configurator Implementation Guide 7 Deploying 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.
Deploying Oracle Configurator 7-1 Calling an Embedded Oracle Configurator
7.1.1 Java Applet Requirements The 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 Requirements The 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 Oracle Configurator Custom Web Deployment Guide messages, and other elements of a custom web applications Setting up the OC Servlet Oracle Configurator Installation Guide
7-2 Oracle Configurator Implementation Guide Deployment Strategies
For details on ... See ... Using Oracle Configurator Developer Oracle Configurator Developer User’s Guide
7.2 Deployment Strategies No 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 Considerations The 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)
Deploying Oracle Configurator 7-3 Deployment Strategies
■ 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 Considerations A 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
7-4 Oracle Configurator Implementation Guide Deployment Strategies
■ The number of connections available in the connection pool (see "Connection Pooling" on page 7-5)
■ The frequency and type of database accesses caused by user actions (see "Load Balancing" on page 7-9)
Example Consider a hypothetical deployment that includes:
■ 6 CPUs
■ 2 JServ instances per CPU
■ 20 end users expected per JServ This deployment can support 240 simultaneous user configuration sessions: 6 CPUs x 2 JServs per CPU x 20 users per JServ = 240 users Due to the nature of the application, and the kind of data access that occurs in the application, you should consider what kind of peak events might occur when several users perform a "save" operation in the same minute. If there are not enough database connections in the connection pool when many users save their configuration at the same time, those users will experience an unacceptable wait until enough connections are freed.
7.2.2.1 Connection Pooling Connection pooling allows multiple configuration sessions in a JServ instance to make database connections. (Previous versions of Oracle Configurator were only able to use a single database connection for each JServ instance.) When a configuration session is started—by the posting of the initialization message to the OC Servlet—then a connection is obtained from the pool. When the session is over, the connection is returned to the pool. Each connection uses up memory. Oracle Configurator uses AOL/J (Java classes for AOL (Applications Object Library)) to provide connection pooling. To modify the default setting for connection pooling, you use the AdminAppServer class to create or update a DBC file, setting a value for the parameter FND_MAX_JDBC_CONNECTIONS. The parameter FND_MAX_JDBC_CONNECTIONS specifies the maximum number of open connections in the JDBC connection cache. This number is dependent on the amount of memory available, the number of processes specified in the init.ora file of the database and the per-processor file descriptor limit.
Deploying Oracle Configurator 7-5 Deployment Strategies
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 Considerations There are a number of network issues that can cause serious problems for your deployment if not handled correctly.
7.2.3.1 Firewalls and Timeouts It 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.
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.
7.2.3.2 Router Timeouts Routers 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).
7-6 Oracle Configurator Implementation Guide 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.
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.
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 Tasks Several 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 Options During 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.
Deploying Oracle Configurator 7-7 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 Access End 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 Testing In 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 Testing In 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 Testing In 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.
7-8 Oracle Configurator Implementation Guide 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 Balancing See "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.
Deploying Oracle Configurator 7-9 Deployment Tasks
7-10 Oracle Configurator Implementation Guide A Import Tables
A.1 Overview This 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 Tables The import tables are listed in the order in which the concurrent programs and SQL* Plus import procedures populate them. CZ_IMP_ITEM_MASTER CZ_IMP_INTL_TEXT CZ_IMP_DEVL_PROJECT CZ_IMP_PS_NODE
CZ_IMP_ITEM_PROPERTY_VALUE CZ_IMP_ITEM_TYPE CZ_IMP_ITEM_TYPE_PROPERTY CZ_IMP_PROPERTY
Import Tables A-1 Dependencies Among Import Tables
A.3 Dependencies Among Import Tables Dependencies 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.
Note: Oracle recommends that the usage of FSK_***_EXT columns be very limited as they will not be supported in the near future.
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.
Table A–1 Dependencies Among Oracle Configurator Schema Import Tables Type of for Foreign dependen- Import Table Name Depends on Surrogate Key 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_ CZ_IMP_PROPERTY FSK_PROPERTY STRONG NO VALUE CZ_IMP_ITEM_PROPERTY_ CZ_IMP_ITEM_ FSK_ITEMMASTER STRONG NO VALUE MASTER CZ_IMP_ITEM_TYPE NO NO NO NO CZ_IMP_ITEM_TYPE_ CZ_IMP_ITEM_TYPE FSK_ITEMTYPE STRONG NO PROPERTY CZ_IMP_ITEM_TYPE_ CZ_IMP_PROPERTY FSK_PROPERTY STRONG NO PROPERTY CZ_IMP_PROPERTY NO NO NO NO
A-2 Oracle Configurator Implementation Guide Import Tables
Table A–1 Dependencies Among Oracle Configurator Schema Import Tables CZ_IMP_PS_NODE CZ_IMP_INTL_TEXT FSK_INTLTEXT STRONG NO CZ_IMP_PS_NODE CZ_IMP_ITEM_ FSK_ITEMMASTER STRONG NO MASTER CZ_IMP_PS_NODE CZ_IMP_DEVL_ FSK_DEVLPROJECT STRONG NO PROJECT
A.4 Import Tables Table 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:
Table A–2 Import Table Field Disposition Codes Code Disposition M marked for modification I marked for insertion Rrejected
Record status codes for required columns of the import tables are:
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
Import Tables A-3 Import Tables
Table A–3 Import Table Record Status Codes 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 Description Required Nullable DATA_TYPE DEVL_PROJECT_ N Y NUMBER Designates an OC identifier for the development project ID INTL_TEXT_ID N Y NUMBER Contains the OC international text ID for this project NAME Y N VARCHAR2 Contains name of the development project. Disposition if (255) null - ERR GSL_FILENAME N Y VARCHAR2 Contains gsl filename of the project (255) VERSION N Y NUMBER Contains version number of the project DESC_TEXT N Y VARCHAR2 Description text for this project (255) ORIG_SYS_REF Y N VARCHAR2 Unique identification of a record in this table. Contains a (255) 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_ N Y DATE Contains the date on which the record was last modified DATE 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
A-4 Oracle Configurator Implementation Guide Import Tables
Table A–4 Description of Fields in CZ_IMP_DEVL_PROJECT Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE 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_ N Y NUMBER Records the login name for the user that last modified this BY record SECURITY_MASK N Y VARCHAR2 Reserved for future use in record-level access control (40) EFF_MASK N Y VARCHAR2 Reserved for future use (40) CHECKOUT_USER N Y VARCHAR2 Reserved for future use in checkout user (40) RUN_ID N Y NUMBER Contains a number indicating the Import run in which this record was loaded/processed REC_STATUS N Y VARCHAR2 Records a coded status describing the import results for (4) 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_ N Y VARCHAR2 Contains a foreign surrogate-key value matching CZ_ 1 (255) IMP_INTL_TEXT on TEXT_STR
Import Tables A-5 Import Tables
Table A–5 Description of Fields in CZ_IMP_INTL_TEXT Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE INTL_TEXT_ID N Y NUMBER Designates an OC identifier for international text TEXT_STR Y Y VARCHAR2 String describes the international text. Contains a foreign (255) surrogate-key value matching CZ_INTL_TEXTS.TEXT_ STR. Disposition:
■ if found - M ■ if not found - I ■ if not unique - R-DUPL CREATION_DATE N Y DATE Indicates the date on which this record was created LAST_UPDATE_ N Y DATE Contains the date on which the record was last modified DATE 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 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_ N Y NUMBER Records the login name for the user that last modified this BY record SECURITY_MASK N Y VARCHAR2 Reserved for future use in record-level access control (40) EFF_MASK N Y VARCHAR2 Reserved for future use (40) CHECKOUT_USER N Y VARCHAR2 Reserved for future use in checkout user (40)
A-6 Oracle Configurator Implementation Guide Import Tables
Table A–5 Description of Fields in CZ_IMP_INTL_TEXT Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE RUN_ID N Y NUMBER Contains a number indicating the Import run in which this record was loaded/processed REC_STATUS N Y VARCHAR2 Records a coded status describing the import results for (4) 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
Table A–6 Description of Fields in CZ_IMP_ITEM_MASTER Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE 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 ORIG_SYS_REF Y N VARCHAR2 Unique identification of a record in this table. Contains a (255) foreign surrogate-key value matching CZ_ITEM_ MASTERS.ORIG_SYS_REF. Disposition:
■ if found - M ■ if not found - I ■ if not unique - R-DUPL ■ if null - R-N9 DESC_TEXT N Y VARCHAR2 Describes this item-master part entry (255) REF_PART_NBR Y N VARCHAR2 Contains a part number for the item described in this (255) record. Disposition if null - ERR QUOTEABLE_ N Y CHAR (1) Indicates that this Item can be separately quoted FLAG
Import Tables A-7 Import Tables
Table A–6 Description of Fields in CZ_IMP_ITEM_MASTER Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE PRIMARY_UOM_ N Y VARCHAR2 Contains code for primary unit of measure CODE (3) 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 RUN_ID N Y NUMBER Contains a number indicating the Import run in which this record was loaded/processed REC_STATUS N Y VARCHAR2 Records a coded status describing the import results for (4) 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 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 EFF_TO N Y DATE Indicates the ending date through which this record is effective EFF_MASK N Y VARCHAR2 Reserved for future use (40) USER_STR01 N Y VARCHAR2 Textual user expansion field (255) USER_STR02 N Y VARCHAR2 Textual user expansion field (255) USER_STR03 N Y VARCHAR2 Textual user expansion field; may be used as an alternate (255) ’surrogate key’ for the record USER_STR04 N Y VARCHAR2 Textual user expansion field (255) USER_NUM01 N Y NUMBER Numeric user expansion field (16,9)
A-8 Oracle Configurator Implementation Guide Import Tables
Table A–6 Description of Fields in CZ_IMP_ITEM_MASTER Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE USER_NUM02 N Y NUMBER Numeric user expansion field (16,9) USER_NUM03 N Y NUMBER Numeric user expansion field (16,9) USER_NUM04 N Y NUMBER Numeric user expansion field (16,9) CHECKOUT_USER N Y VARCHAR2 Reserved for future use in checkout user (40) CREATION_DATE N Y DATE Indicates the date on which this record was created LAST_UPDATE_ N Y DATE Contains the date on which the record was last modified DATE CREATED_BY N Y NUMBER Identifies the user that created this record LAST_UPDATED_ N Y NUMBER Records the login name for the user that last modified this BY record SECURITY_MASK N Y VARCHAR2 Reserved for future use in record-level access control (40) FSK_ITEMTYPE_1_ Y N VARCHAR2 Contains a foreign surrogate-key value matching CZ_ 1 (255) 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_ N Y VARCHAR2 Contains a foreign surrogate-key value matching CZ_ EXT (255) 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
Import Tables A-9 Import Tables
Table A–8 Description of Fields in CZ_IMP_ITEM_PROPERTY_VALUE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE 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_ N Y VARCHAR2 Contains the value that is assigned to the property for this VALUE (255) item REC_NBR N Y NUMBER Provides a one-up sequence number identifying the record in this run RUN_ID N Y NUMBER Contains a number indicating the Import run in which this record was loaded/processed REC_STATUS N Y VARCHAR2 Records a coded status describing the import results for (4) this record; if null it indicates the record has not yet been completely processed 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 EFF_FROM N Y DATE Indicates the beginning date for which this record is effective EFF_TO N Y DATE Indicates the ending date through which this record is effective EFF_MASK N Y VARCHAR2 Reserved for future use (40) USER_STR01 N Y VARCHAR2 Textual user expansion field (255) USER_STR02 N Y VARCHAR2 Textual user expansion field (255) USER_STR03 N Y VARCHAR2 Textual user expansion field; may be used as an alternate (255) ’surrogate key’ for the record USER_STR04 N Y VARCHAR2 Textual user expansion field (255) USER_NUM01 N Y NUMBER Numeric user expansion field (16,9)
A-10 Oracle Configurator Implementation Guide Import Tables
Table A–8 Description of Fields in CZ_IMP_ITEM_PROPERTY_VALUE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE USER_NUM02 N Y NUMBER Numeric user expansion field (16,9) USER_NUM03 N Y NUMBER Numeric user expansion field (16,9) USER_NUM04 N Y NUMBER Numeric user expansion field (16,9) CHECKOUT_USER N Y VARCHAR2 Reserved for future use in checkout user (40) CREATION_DATE N Y DATE Indicates the date on which this record was created LAST_UPDATE_ N Y DATE Contains the date on which the record was last modified DATE CREATED_BY N Y NUMBER Identifies the user that created this record LAST_UPDATED_ N Y NUMBER Records the login name for the user that last modified this BY record SECURITY_MASK N Y VARCHAR2 Reserved for future use in record-level access control (40) FSK_PROPERTY_1_ Y N VARCHAR2 Contains a foreign surrogate-key value matching CZ_ 1 (255) 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_ N Y VARCHAR2 Contains a foreign surrogate-key value matching CZ_ EXT (255) 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
Import Tables A-11 Import Tables
Table A–8 Description of Fields in CZ_IMP_ITEM_PROPERTY_VALUE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE FSK_ Y N VARCHAR2 Contains foreign surrogate-key values matching CZ_ ITEMMASTER_2_1 (255) 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_ N Y VARCHAR2 Contains a foreign surrogate-key value matching CZ_ ITEMMASTER_2_ (255) IMP_ITEM_MASTER on USER_STR03. Note: It is EXT recommended that the usage of this column be very limited as it will not be supported in the near future Assigned property Y Additional columns required in source table. Queried ID and item ID 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 Description Required Nullable DATA_TYPE ITEM_TYPE_ID N Y NUMBER Designates an OC Identifier for the item type DESC_TEXT N Y VARCHAR2 Describes this item type (255) NAME N Y VARCHAR2 Contains the name of the Item Type (255) REC_NBR N Y NUMBER Provides a one-up sequence number identifying the record in this run
A-12 Oracle Configurator Implementation Guide Import Tables
Table A–9 Description of Fields in CZ_IMP_ITEM_TYPE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE RUN_ID N Y NUMBER Contains a number indicating the Import run in which this record was loaded/processed REC_STATUS N Y VARCHAR2 Records a coded status describing the import results for (4) 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 DELETED_FLAG N Y CHAR (1) Indicates (’1’/’0’) that this record has been deleted ORIG_SYS_REF Y N VARCHAR2 Unique identification of a record in this table. Contains a (255) 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 EFF_FROM N Y DATE Indicates the beginning date for which this record is effective EFF_TO N Y DATE Indicates the ending date through which this record is effective EFF_MASK N Y VARCHAR2 Reserved for future use (40) USER_STR01 N Y VARCHAR2 Textual user expansion field (255) USER_STR02 N Y VARCHAR2 Textual user expansion field (255) USER_STR03 N Y VARCHAR2 Textual user expansion field; may be used as an alternate (255) ’surrogate key’ for the record USER_STR04 N Y VARCHAR2 Textual user expansion field (255) USER_NUM01 N Y NUMBER Numeric user expansion field (16,9)
Import Tables A-13 Import Tables
Table A–9 Description of Fields in CZ_IMP_ITEM_TYPE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE USER_NUM02 N Y NUMBER Numeric user expansion field (16,9) USER_NUM03 N Y NUMBER Numeric user expansion field (16,9) USER_NUM04 N Y NUMBER Numeric user expansion field (16,9) CHECKOUT_USER N Y VARCHAR2 Reserved for future use in checkout user (40) CREATION_DATE N Y DATE Indicates the date on which this record was created LAST_UPDATE_ N Y DATE Contains the date on which the record was last modified DATE CREATED_BY N Y NUMBER Identifies the user that created this record LAST_UPDATED_ N Y NUMBER Records the login name for the user that last modified this BY record SECURITY_MASK N Y VARCHAR2 Reserved for future use in record-level access control (40)
Table A–10 Description of Fields in CZ_IMP_ITEM_TYPE_PROPERTY Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE 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 REC_NBR N Y NUMBER Provides a one-up sequence number identifying the record in this run RUN_ID N Y NUMBER Contains a number indicating the Import run in which this record was loaded/processed
A-14 Oracle Configurator Implementation Guide Import Tables
Table A–10 Description of Fields in CZ_IMP_ITEM_TYPE_PROPERTY Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE REC_STATUS N Y VARCHAR2 Records a coded status describing the import results for (4) 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 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 EFF_TO N Y DATE Indicates the ending date through which this record is effective EFF_MASK N Y VARCHAR2 Reserved for future use. (40) USER_STR01 N Y VARCHAR2 Textual user expansion field (255) USER_STR02 N Y VARCHAR2 Textual user expansion field (255) USER_STR03 N Y VARCHAR2 Textual user expansion field; may be used as an alternate (255) ’surrogate key’ for the record USER_STR04 N Y VARCHAR2 Textual user expansion field (255) USER_NUM01 N Y NUMBER Numeric user expansion field (16,9) USER_NUM02 N Y NUMBER Numeric user expansion field (16,9) USER_NUM03 N Y NUMBER Numeric user expansion field (16,9) USER_NUM04 N Y NUMBER Numeric user expansion field (16,9) CHECKOUT_USER N Y VARCHAR2 Reserved for future use in checkout user (40) CREATION_DATE N Y DATE Indicates the date on which this record was created
Import Tables A-15 Import Tables
Table A–10 Description of Fields in CZ_IMP_ITEM_TYPE_PROPERTY Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE LAST_UPDATE_ N Y DATE Contains the date on which the record was last modified DATE CREATED_BY N Y NUMBER Identifies the user that created this record LAST_UPDATED_ N Y NUMBER Records the login name for the user that last modified this BY record SECURITY_MASK N Y VARCHAR2 Reserved for future use in record-level access control (40) FSK_ITEMTYPE_1_ Y N VARCHAR2 Contains a foreign surrogate-key value matching CZ_ 1 (255) 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_ N Y VARCHAR2 Contains a foreign surrogate-key value matching CZ_ EXT (255) IMP_ITEM_TYPE on USER_STR03 FSK_PROPERTY_2_ Y N VARCHAR2 Contains a foreign surrogate-key value matching CZ_ 1 (255) 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_ N Y VARCHAR2 Contains a foreign surrogate-key value matching CZ_ EXT (255) 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 Y Additional columns required in source table. Queried ID and item type ID against CZ_ITEM_TYPE_PROPERTIES.PROPERTY_ID and CZ_ITEM_TYPE_PROPERTIES.ITEM_TYPE_ID. Disposition:
■ if found - M ■ if not found - I
A-16 Oracle Configurator Implementation Guide Import Tables
Table A–11 Description of Fields in CZ_IMP_PROPERTY Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE PROPERTY_ID N Y NUMBER Designates an OC Identifier for the property PROPERTY_UNIT N Y VARCHAR2 Indicates the units in which this property is measured or (8) allocated DESC_TEXT N Y VARCHAR2 Describes this property (255) NAME Y N VARCHAR2 Contains the name of the Property. Disposition if null - (255) ERR DATA_TYPE Y N NUMBER Indicates the data type that this property bears. Disposition if null - ERR DEF_VALUE N Y VARCHAR2 Records a default value for the property (255) REC_NBR N Y NUMBER Provides a one-up sequence number identifying the record in this run RUN_ID N Y NUMBER Contains a number indicating the Import run in which this record was loaded/processed REC_STATUS N Y VARCHAR2 Records a coded status describing the import results for (4) 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 DELETED_FLAG N Y CHAR (1) Indicates (’1’/’0’) that this record has been deleted ORIG_SYS_REF Y N VARCHAR2 Unique identification of a record in this table. Contains a (255) foreign surrogate-key value matchingCZ_ PROPERTIES.ORIG_SYS_REF. Disposition:
■ if found - M ■ if not found - I ■ if not unique - R-DUPL ■ if null - R-N17 EFF_FROM N Y DATE Indicates the beginning date for which this record is effective
Import Tables A-17 Import Tables
Table A–11 Description of Fields in CZ_IMP_PROPERTY Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE EFF_TO N Y DATE Indicates the ending date through which this record is effective EFF_MASK N Y VARCHAR2 Reserved for future use (40) USER_STR01 N Y VARCHAR2 Textual user expansion field (255) USER_STR02 N Y VARCHAR2 Textual user expansion field (255) USER_STR03 N Y VARCHAR2 Textual user expansion field; may be used as an alternate (255) ’surrogate key’ for the record USER_STR04 N Y VARCHAR2 Textual user expansion field (255) USER_NUM01 N Y NUMBER Numeric user expansion field (16,9) USER_NUM02 N Y NUMBER Numeric user expansion field (16,9) USER_NUM03 N Y NUMBER Numeric user expansion field (16,9) USER_NUM04 N Y NUMBER Numeric user expansion field (16,9) CHECKOUT_USER N Y VARCHAR2 Reserved for future use in checkout user (40) CREATION_DATE N Y DATE Indicates the date on which this record was created LAST_UPDATE_ N Y DATE Contains the date on which the record was last modified DATE CREATED_BY N Y NUMBER Identifies the user that created this record LAST_UPDATED_ N Y NUMBER Records the login name for the user that last modified this BY record SECURITY_MASK N Y VARCHAR2 Reserved for future use in record-level access control (40)
A-18 Oracle Configurator Implementation Guide Import Tables
Table A–12 Description of Fields in CZ_IMP_PS_NODE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE PS_NODE_ID N Y NUMBER Designates an OC Identifier for the model node DEVL_PROJECT_ N Y NUMBER Contains the OC development project ID for this record ID FROM_ N Y NUMBER Set when the node is created by a populator; designates POPULATOR_ID the OC identifier for the populator that created this record PROPERTY_ N Y NUMBER Set when the node is created by a populator; identifies the BACKPTR property from which this record was created ITEM_TYPE_ N Y NUMBER Set when the node is created by a populator; identifies the BACKPTR 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 Contains the OC name for the model node (i.e. (255) component, feature, etc.) RESOURCE_FLAG N Y CHAR (1) Indicates that this node is a Total or Resource INITIAL_VALUE N Y VARCHAR2 Records the initial value for this node when instantiated (255) in a configuration PARENT_ID N Y NUMBER Contains the OC identifier for the parent node MINIMUM N Y NUMBER Contains the minimum selection requirement (16,9) MAXIMUM N Y NUMBER Contains the maximum selection requirement (16,9) 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 A-19 Import Tables
Table A–12 Description of Fields in CZ_IMP_PS_NODE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE 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_ N Y CHAR (1) Indicates node children can be configured separately FLAG ORDER_SEQ_ N Y CHAR (1) Indicates the component is a ordered sequence FLAG SYSTEM_NODE_ N Y CHAR (1) Indicates this record is a system node, i.e. either root node FLAG or template for roots TREE_SEQ Y N NUMBER Contains the order of this child node within the parent. Disposition if null - ERR COUNTED_ N Y CHAR (1) Indicates this feature has counted options OPTIONS_FLAG 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_ N Y NUMBER Indicates how BOM should be enumerated during TREATMENT configuration order generation ORIG_SYS_REF Y N VARCHAR2 Unique identification of a record in this table. Contains a (1500) foreign surrogate-key value matching CZ_PS_ NODES.ORIG_SYS_REF. Disposition:
■ if found - M ■ if not found - I ■ if not unique - R-DUPL ■ if null - R-N9 RUN_ID N Y NUMBER Contains a number indicating the Import run in which this record was loaded/processed REC_STATUS N Y VARCHAR2 Records a coded status describing the import results for (4) 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
A-20 Oracle Configurator Implementation Guide Import Tables
Table A–12 Description of Fields in CZ_IMP_PS_NODE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE 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 EFF_TO N Y DATE Indicates the ending date through which this record is effective EFF_MASK N Y VARCHAR2 Reserved for future use (40) USER_STR01 N Y VARCHAR2 Textual user expansion field (255) USER_STR02 N Y VARCHAR2 Textual user expansion field (255) USER_STR03 N Y VARCHAR2 Textual user expansion field; may be used as an alternate (255) ’surrogate key’ for the record USER_STR04 N Y VARCHAR2 Textual user expansion field (255) USER_NUM01 N Y NUMBER Numeric user expansion field (16,9) USER_NUM02 N Y NUMBER Numeric user expansion field (16,9) USER_NUM03 N Y NUMBER Numeric user expansion field (16,9) USER_NUM04 N Y NUMBER Numeric user expansion field (16,9) CHECKOUT_USER N Y VARCHAR2 Reserved for future use in checkout user (40) CREATION_DATE N Y DATE Indicates the date on which this record was created LAST_UPDATE_ N Y DATE Contains the date on which the record was last modified DATE CREATED_BY N Y NUMBER Identifies the user that created this record
Import Tables A-21 Import Tables
Table A–12 Description of Fields in CZ_IMP_PS_NODE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE LAST_UPDATED_ N Y NUMBER Records the login name for the user that last modified this BY record SECURITY_MASK N Y VARCHAR2 Reserved for future use in record-level access control (40) FSK_INTLTEXT_1_ YN VARCHAR2 Contains a foreign surrogate-key value matching CZ_ 1 (see (255) INTL_TEXTS.TEXT_STR. descr Disposition: iptio n) ■ 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_ N Y VARCHAR2 Contains a foreign surrogate-key value matching CZ_ EXT (255) 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_ Y Y VARCHAR2 Contains a foreign surrogate-key value matching CZ_ ITEMMASTER_2_1 (255) ITEM_MASTERS.ORIG_SYS_REF. Disposition:
■ if found - assign item ID ■ if not found - R-F46 (except model and project structure nodes) FSK_ N Y VARCHAR2 Contains a foreign surrogate-key value matching CZ_ ITEMMASTER_2_ (255) IMP_ITEM_MASTER on ORIG_SYS_REF. Note: It is EXT 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 VARCHAR2 Contains a foreign surrogate-key value matching CZ_PS_ (see (255) NODES.ORIG_SYS_REF. descr Disposition: iptio n) ■ 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_ N Y VARCHAR2 Contains a foreign surrogate-key value matching CZ_ EXT (255) 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
A-22 Oracle Configurator Implementation Guide Import Tables
Table A–12 Description of Fields in CZ_IMP_PS_NODE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE FSK_PSNODE_4_1 N Y VARCHAR2 Currently not used (255) FSK_PSNODE_4_ N Y VARCHAR2 Currently not used EXT (255) FSK_ Y N VARCHAR2 Contains a foreign surrogate-key value matching CZ_ DEVLPROJECT_5_ (255) DEVL_PROJECTS.ORIG_SYS_REF. 1 Disposition:
■ if found - assign development project ID ■ if not found - R-F50 ■ if null - R-N50 FSK_ N Y VARCHAR2 Contains a foreign surrogate-key value matching CZ_ DEVLPROJECT_5_ (255) IMP_DEVL_PROJECT on USER_STR03. Note: It is EXT recommended that the usage of this column be very limited as it will not be supported in the near future COMPONENT_ N Y NUMBER Component sequence identifier from BOM explosions SEQUENCE_ID COMPONENT_ N Y VARCHAR2 Contains the path from the root BOM node CODE (1000) 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_ N Y VARCHAR2 Describes the application’s item type for ordering: model, CODE class, kit, standard MINIMUM_ N Y NUMBER For OptionClass nodes, indicates the minimum quantity SELECTED selection for its children MAXIMUM_ N Y NUMBER For OptionClass nodes, indicates the maximum quantity SELECTED selection for its children BOM_REQUIRED N Y CHAR (1) Contains a flag indicating that this node is required for BOM
Import Tables A-23 Import Tables
A-24 Oracle Configurator Implementation Guide 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-1 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-2 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-3 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-4 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-5 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-6 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-7 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-8 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-9 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.
Glossary of Terms-10 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.
Glossary of Terms-11 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
Glossary of Terms-12 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.
Glossary of Terms-13 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.
Glossary of Terms-14 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 The extent to and ease with which parts of a system can be put to use in other systems.
Rules Also called business rules or configuration rules. Constraints applied among elements of the product to ensure that defined relationships are preserved during configuration. Elements of the product are components, features, and options. Rules express logic, numeric parameters, implicit compatibility, or explicit compatibility. Rules are used to provide pre-selection and validation capability in an application. See also Logic Rules and Numeric Rules.
Runtime The environment and context in which applications are run or used, rather than developed.
Sales Configuration A part of the sales process to which configuration technology has been applied in order to increase sales effectiveness and decrease order errors. Commonly identifies needs assessment and product configuration.
Server Centrally located software processes or hardware, shared by clients.
Servlet A Java application running inside a web server. See also Java and Applet.
Solution The deployed system as a response to a problem or problems.
Glossary of Terms-15 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.
Glossary of Terms-16 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 Terms-17 Glossary of Terms-18 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
Glossary of Acronyms-1 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
Glossary of Acronyms-2 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
Glossary of Acronyms-3 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
Glossary of Acronyms-4 SAS Sales Analysis System
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
Glossary of Acronyms-5 VB Microsoft Visual Basic
WAN Wide Area Network
WIP Work In Progress
Glossary of Acronyms-6 Index
A imported, 1–3 imported data, 4–10 Active Model BOM_EXPLOSIONS definition, 1–10 data refresh, 3–9 Oracle Configurator LC subschema, 3–2 data transfer source, 4–10 upgrade, 1–10 DESCRIPTION field in CZ_INTL_TEXTS, 4–9 Active UI source field from, 3–8 definition, 1–10 BOM_REVISION AOL (Applications Object Library), 7–5 CZ_DB_SETTING for Oracle Applications AOL/J, 7–5 integration, 3–8 applet, 7–1 browser application requirements for DHTML configurator, 7–2 publication applicability parameter, 6–6 application id applid, 2–5 C applications CIO, 1–11 state, 7–6 client/server environment applid deployment parameter in spx.ini, 2–5 CommitSize CZ_DB_SETTING for direct import, 3–10 B COMPONENT_ITEM_ID in CZ_XFR_PROJECT_BILLS, 4–7 BadItemPropertyValue concurrent processes CZ_DB_SETTING for import, 3–9 Define Remote Server, 1–14 description, 3–9 Disable/Enable Refresh of a Configuration disposition codes, 3–9 Model, 4–17 BatchSize Enable Remote Server, 1–14 CZ_DB_SETTING for SCHEMA, 3–7 Export Data for a Single Publication, 6–9 BILL_REVISION_DATE Export Data for All Published Models, 6–10 in CZ_XFR_PROJECT_BILLS, 4–8 for editing Oracle Configurator settings, 3–10 BOM for import, 4–12 see also Bills of Material for publication, 6–9 configure directly, 1–3 for server administration, 1–12 import root, 4–10 Import Model Bills, 4–15
Index-1 Modify Configurator Parameters, 3–11 CZ_COMBO_FEATURES Modify Server Definition, 1–15 refreshing, 4–17 Process a Single Publication, 6–9 table in CZ schema - PS subschema, 3–3 Process Pending Publications, 6–10 CZ_CONFIG_HDRS Purge Configurator Tables, 3–13 table in CZ schema - CF subschema, 3–2 query registered processes, 1–18 CZ_CONFIG_INPUTS Refresh a Single Configuration Model, 4–17 table in CZ schema - CF subschema, 3–2 Refresh All Previously Imported Models, 4–17 CZ_CONFIG_ITEMS running Server Administration processes, 1–15 table in CZ schema - CF subschema, 3–2 Select Tables to be Imported, 4–24, 4–29 CZ_CONFIG_MESSAGES Show Tables to be Imported, 4–25 table in CZ schema - CF subschema, 3–2 View Configurator Parameters, 3–11 CZ_CONFIG_USAGES View Servers, 1–15 table in CZ schema - CF subschema, 3–2 view status of, 1–16 CZ_DB_LOGS view submitted requests, 1–16 TABLE IN cz SCHEMA - GN subschema, 3–2 Configuration CZ_DB_SETTINGS Oracle Configurator CF subschema, 3–2 BadItemPropertyValue, 3–5 Configuration Interface Object, see CIO Batchsize, 3–5 BOM_REVISION, 3–5 Configurator CommitSize, 3–5 see also DHTML configurator for IMPORT, 3–9 see also Java applet configurator for ORAAPPS_INTEGRATE, 3–8 see also Oracle Configurator window for SCHEMA, 3–7 see also Oracle SellingPoint application FREEZE_REVISION, 3–5 architecture, 1–10 MAJOR_VERSION, 1–22, 3–5 installations, 1–5 MaximumErrors, 3–5 parameters MINOR_VERSION, 1–22, 3–5 modifying, 3–11 MULTISESSION, 3–6 viewing, 3–12 OracleSequenceIncr, 3–6 requirements for installation, 1–5 PsNodeName, 3–6 Configure RefPartNbr, 3–6 button, 5–2, 7–8 ResolvePropertyDataType, 3–7 connection cache, 7–5 Revison Date/User, 3–7 control tables RUN_BILL_EXPLODER, 3–7 see CZ_XFR control tables table in CZ schema - GN subschema, 3–2 cookies CZ_DB_SETTINGS table, 1–6, 3–4 DHTML configurator requirement, 7–2 export settings, 3–9 COPY_ADDL_CHILD_MODELS schema version, 1–21 in CZ_XFR_PROJECT_BILLS, 4–8 CZ_DB_SIZES CZ:Publication Mode table in CZ schema - GN subschema, 3–2 profile option, 6–11 CZ_DES_CHART_CELLS CZ:Usage Names refreshing, 4–17 profile option, 6–12 table in CZ schema - PS subschema, 3–3 CZ_ATP_REQUESTS CZ_DES_CHART_FEATURES table in CZ schema - CF subschema, 3–2 table in CZ schema - PS subschema, 3–3
Index-2 CZ_DEVL_PROJECTS CZ_ITEM_TYPES refreshing, 4–17 refreshing, 4–18 table in CZ schema - PS subschema, 3–3 table in CZ schema - IM subschema, 3–2 transferred data, 4–10 CZ_LCE_CLOBS CZ_EFFECTIVITY_SETS table in CZ schema - LC subschema, 3–2 table in CZ schema - PB subschema, 3–3 CZ_LCE_HEADERS CZ_EXPRESSION_NODES refreshing, 4–18 refreshing, 4–17 table in CZ schema - LC subschema, 3–2 table in CZ schema - PS subschema, 3–3 CZ_LCE_LINES CZ_EXPRESSIONS table in CZ schema - LC subschema, 3–2 refreshing, 4–17 CZ_LCE_OPERANDS table in CZ schema - PS subschema, 3–3 table in CZ schema - LC subschema, 3–2 CZ_FILTER_SETS CZ_LCE_TEXTS refreshing, 4–17 refreshing, 4–18 table in CZ schema - PS subschema, 3–3 table in CZ schema - LC subschema, 3–3 CZ_FUNC_COMP_REFS CZ_MODEL_PUBLICATIONS table in CZ schema - PS subschema, 3–3 publications tables, 6–10 CZ_FUNC_COMP_SPECS table in CZ schema - PB subschema, 3–3 refreshing, 4–17 CZ_MODEL_REF_EXPLS table in CZ schema - PS subschema, 3–3 table in CZ schema - PS subschema, 3–3 CZ_GRID_CELLS CZ_MODEL_USAGES refreshing, 4–17 publications tables, 6–10 table in CZ schema - PS subschema, 3–3 table in CZ schema - PB subschema, 3–3 CZ_GRID_COLS CZ_PB_CLIENT_APPS refreshing, 4–18 publications tables, 6–10 table in CZ schema - PS subschema, 3–3 table in CZ schema - PB subschema, 3–3 CZ_GRID_DEFS CZ_PB_MODEL_EXPORTS refreshing, 4–18 publications tables, 6–10 table in CZ schema - PS subschema, 3–3 table in CZ schema - PB subschema, 3–3 CZ_INTL_TEXTS, 4–9 CZ_PB_TEMP_IDS refreshing, 4–18 table in CZ schema - PB subschema, 3–3 table in CZ schema - PS subschema, 3–3 CZ_POPULATOR_MAPS transferred data, 4–10 refreshing, 4–18 CZ_ITEM_MASTERS table in CZ schema - PS subschema, 3–3 refreshing, 4–18 CZ_POPULATORS table in CZ schema - IM subschema, 3–2 refreshing, 4–18 transferred data, 4–10 table in CZ schema - PS subschema, 3–3 CZ_ITEM_PARENTS CZ_PRICING_STRUCTURES, 5–4 table in CZ schema - IM subschema, 3–2 table in CZ schema - CF subschema, 3–2 CZ_ITEM_PROPERTY_VALUES CZ_PROPERTIES refreshing, 4–18 refreshing, 4–18 table in CZ schema - IM subschema, 3–2 table in CZ schema - IM subschema, 3–2 CZ_ITEM_TYPE_PROPERTIES CZ_PS_NODES, 3–8 refreshing, 4–18 refreshing, 4–18 table in CZ schema - IM subschema, 3–2 table in CZ schema - PS subschema, 3–3
Index-3 transferred data, 4–10 table in CZ schema - XF subschema, 3–4 CZ_PS_PROP_VALS CZ_XFR_PRICE_LISTS refreshing, 4–18 table in CZ schema - XF subschema, 3–4 table in CZ schema - PS subschema, 3–3 CZ_XFR_PROJECT_BILLS, 3–9, 4–7, 4–9 CZ_PS_PROPCOMPAT_GEN table in CZ schema - XF subschema, 3–4 table in CZ schema - PS subschema, 3–3 CZ_XFR_RUN_INFOS CZ_PUBLICATION_USAGES table in CZ schema - XF subschema, 3–4 publications tables, 6–10 CZ_XFR_RUN_RESULTS table in CZ schema - PB subschema, 3–3 table in CZ schema - XF subschema, 3–4 CZ_REL_TYPES CZ_XFR_STATUS_CODES refreshing, 4–18 table in CZ schema - XF subschema, 3–4 table in CZ schema - IM subschema, 3–2 CZ_XFR_TABLES CZ_RP_ENTRIES table in CZ schema - XF subschema, 3–4 table in CZ schema - RP subschema, 3–3 cz.activemodel, 5–5, 5–6, 5–8 CZ_RULES cz.activemodel.lazyloadlistprice, 5–5 refreshing, 4–18 table in CZ schema - PS subschema, 3–3 D CZ_RULES_FOLDERS refreshing, 4–18 data extraction table in CZ schema - PS subschema, 3–3 setup, 4–27 CZ_SERVERS data import, 4–12 table in CZ schema - RP subschema, 3–4 data transfer CZ_SUB_CON_SETS file for generic import, 4–28 refreshing, 4–18 file format, 4–28 table in CZ schema - PS subschema, 3–3 database instance CZ_TERMINATE_MSGS connect to, 1–21 table in CZ schema - CF subschema, 3–2 definition, 1–4 CZ_UI_DEFS database owner refreshing, 4–18 see also DBOwner table in CZ schema - UI subschema, 3–4 definition, 1–4 CZ_UI_NODE_PROPS date range refreshing, 4–18 publication applicability parameter, 6–6 table in CZ schema - UI subschema, 3–4 DB_SETTINGS, see CZ_DB_SETTINGS CZ_UI_NODES DBC file, 7–5 refreshing, 4–18 DBOwner table in CZ schema - UI subschema, 3–4 definition, 1–4 CZ_UI_PROPERTIES in spx.ini, 2–2 refreshing, 4–18 DELETED_FLAG table in CZ schema - UI subschema, 3–4 in CZ_XFR_PROJECT_BILLS, 4–7 CZ_XFR control tables deployment Oracle Configurator XF subschema client/server, 1–8 use with scripts and concurrent programs, 4–8 DHTML, 7–2 CZ_XFR_FIELD_REQUIRES Java applet, 7–2 table in CZ schema - XF subschema, 3–4 requirements for web, 7–1 CZ_XFR_FIELDS, 4–9 web, 1–8, 7–1
Index-4 DESCRIPTION FND_APPLICATIONS in CZ_XFR_PROJECT_BILLS, 4–7 publications tables, 6–11 Design Chart FND_JDBC_MAX_WAIT_TIME, 7–6 section in the spx.ini file, 2–5 FND_MAX_JDBC_CONNECTIONS, 7–5 settings, 2–5 Foreign Surrogate Key, A–2 Developer FREEZE_REVISION spx.ini parameters, 2–3 CZ_DB_SETTING for SCHEMA, 3–8 DHTML (Dynamic HTML), 7–1 DHTML configurator G browser requirements, 7–2 cookies, 7–2 gateway username deployment of, 7–2 gwyuid, 2–4 essential components, 7–2 General Use tables recommended screen resolution, 7–2 Oracle Configurator GN subschema, 3–2 Disable/Enable Refresh of a Configuration Generate Active Model Model, 4–19 after schema upgrade, 1–10 disposition codes generic import, see import BadItemPropertyValue, 3–9 gwypass import tables, A–3 parameter in spx.ini, 2–4 gwyuid E parameter in spx.ini, 2–4 EFF_FROM I in CZ_XFR_PROJECT_BILLS, 4–8 EFF_TO IMPORT in CZ_XFR_PROJECT_BILLS, 4–8 CZ_DB_SETTINGS, 3–4 effectivity import and publishing, 6–12 control tables, 4–3 effectivity date custom, 4–1, 4–25 for planning publications, 6–2 dependencies among tables, A–2 effectivity sets execution, 3–9 for planning publications, 6–2 from Oracle Applications 10.7 or 11.0, 1–2 end user generic, 4–26, 4–29 definition, 1–5 online tables, 3–1 EXPLOSION_TYPE order of, 1–7, A–1 in CZ_XFR_PROJECT_BILLS, 4–8 schedule during deployment, 1–9 schedule during development, 1–8 setup for generic, 4–26 F setup process, 4–11 feature single tables, A–2 symbol in Design Chart, 2–5 import tables field disposition codes, A–3 clearing, 4–3 firewalls definition, 3–1 effect on servlet connections, 7–6 field disposition codes, A–3 interference with application, 7–6 record status codes, A–3
Index-5 RUN_ID, 4–7 due to failed target database, 6–14 importing due to instance failure, 6–13 re-importing BOMs with component models, 4–20 M InitCodeBaseUrl parameter in the spx.ini file, 2–6 maintenance init.ora file, 7–5 PURGE, 3–13 InitServletURL REDO_SEQUENCES, 3–13 parameter in the spx.ini file, 2–6 MAJOR_VERSION installations CZ_DB_SETTING for SCHEMA, 3–8 deployment, 1–8 MaximumErrors development, 1–6 CZ_DB_SETTING for direct import, 3–10 maintenance, 1–9 Merlin scenarios, 1–6 see Developer test, 1–8 section in the spx.ini file, 2–1 types of, 1–5 Microsoft, 7–2 instance MINOR_VERSION definition, 1–4 CZ_DB_SETTING for SCHEMA, 3–8 Internet Explorer, 7–2 MODEL_PS_NODE_ID Item-Master in CZ_XFR_PROJECT_BILLS, 4–8 Oracle Configurator IM subschema, 3–2 MTL_DESCR_ELEMENT_VALUES data transfer source, 4–10 J MTL_DESCRIPTIVE_ELEMENTS data transfer source, 4–10 Java MTL_ITEM_CATALOG_GROUPS applet, 7–1 data transfer source, 4–10 Java applet MTL_SYSTEM_ITEMS deployment of, 7–2 data transfer source, 4–10 JavaScript MULTISESSION enabled for DHTML configurator, 7–2 CZ_DB_SETTING for direct import, 3–10 JDBC, 7–5 JdbcUrl N parameter in spx.ini, 2–3, 2–4 Netscape Navigator, 7–2 networked environment, see client/server L environment LAST_IMPORT_DATE in CZ_XFR_PROJECT_BILLS, 4–7 O LAST_IMPORT_RUN_ID in CZ_XFR_PROJECT_BILLS, 4–7 online tables, 3–1 Launch Options Selection window, 5–2 parameter in the spx.ini file, 2–6 ORAAPPS_INTEGRATE Logic for Configuration, see Active Model CZ_DB_SETTINGS, 3–4 lost publications Oracle Applications due to failed source database, 6–14 10.7, 1–2
Index-6 11.0, 1–2 setting attribute with Oracle Configurator Oracle Configurator Developer, 5–5, 5–7, 5–8 see also Configurator profile options integration in Oracle Applications, 1–3, 1–6 CZ:Publication Mode, 6–11 release upgrade, 1–10 CZ:Usage Names, 6–12 Oracle Configurator Schema, A–2 Project Structure Oracle Configurator schema Oracle Configurator PS subschema, 3–3 characteristics, 3–1 PsNodeName publishing a production version, 4–17 CZ_DB_SETTING for Oracle Applications purging, 1–8, 3–13 integration, 3–8 redoing sequences, 3–13 Publication settings, see CZ_DB_SETTINGS Oracle Configurator PB subschema, 3–3 subschemas, 3–1 publication synonyms, 3–1 creating, 6–9 tables to refresh for publication, 4–17 defining, 6–3 updates, 4–17 planning, 6–1 verifying version, 1–21 process, 6–2 Oracle Configurator window tables used for, 6–10 architecture, 1–10 publication applicability parameters, 6–5 deployment upgrades, 1–10 application, 6–3, 6–6 Oracle Order Management date range, 6–3, 6–6 integrated with an Oracle runtime publication mode, 6–3, 6–5 Configurator, 1–3 usages, 6–3, 6–7 OracleSequenceIncr publication attributes CZ_DB_SETTING for SCHEMA, 3–8 database instance, 6–3, 6–5 ORGANIZATION_ID, 4–9 model, 6–3, 6–4 in CZ_XFR_PROJECT_BILLS, 4–7 product, 6–3, 6–4 UI definition, 6–3, 6–5 P publication mode publication applicability parameter, 6–5 performance publications pricing interface package, 5–3 deleting, 6–13 prices_calculated_flag, 5–4 disabling, 6–13 pricing editing, 6–13 adjustments, 5–3 lost, 6–13 architecture, 5–3 of configuration models, 6–1 CZ_PRICING_STRUCTURES table, 5–4 re-enabling, 6–13 discounts, 5–3 updating, 6–12 editing, 5–3 publications tables, 6–10 in an Oracle Configurator window, 5–1 publish interface package list of tables, 4–17 definition of, 5–2 production Oracle Configurator schema, 4–17 performance impacts, 5–8 publishing types of, 5–2 configuration models, 6–1 Pricing Display planning, 6–1
Index-7 PURGE schema concurrent processes, 3–13 definition, 1–4 DB maintenance package, 3–13 subschemas, 3–1 verifying version, 1–21 R Selected Items window, 5–2 sequences record status codes, A–3 reset increments, 3–13 import tables, A–3 server REDO_SEQUENCES definition, 1–4 DB maintenance package, 3–13 SOURCE_BILL_DELETED invoked by scripts, 3–13 in CZ_XFR_PROJECT_BILLS, 4–7 REF_PART_NBR, 4–9 SOURCE_SERVER referencing in CZ_XFR_PROJECT_BILLS, 4–8 and publishing, 6–12 spx.ini file RefPartNbr example, 2–1 CZ_DB_SETTING for Oracle Applications parameters for development and testing, 2–2 integration, 3–8 stateful application, 7–6 refresh stickiness list of tables, 4–17 effect on servlet connections, 7–7 production Oracle Configurator schema, 4–17 router property, 7–6 Refresh a Single Configuration Model, 4–19 Stylesheets Refresh All Previously Imported Models, 4–20 enabled for DHTML configurator, 7–2 refreshing Summary button, 5–2 models with references, 4–20 Summary window, 5–2 remote server define, enable, or modify, 1–13 T Repository Oracle Configurator RP subschema, 3–3 TCP/IP ResolvePropertyDataType time limit, 7–6 CZ_DB_SETTING for property import, 3–9 Test respid button in Developer, 2–6 parameter in spx.ini, 2–5 section in the spx.ini file, 2–6 responsibility id timeouts respid, 2–5 database connection, 7–6 Revision Date/User JServ CZ_DB_SETTING for SCHEMA, 3–8 default, 7–6 rollback segment, 3–7 router, 7–7 RUN_BILL_EXPLODER TOP_ITEM_ID, 4–8 CZ_DB_SETTING for direct import, 3–9 in CZ_XFR_PROJECT_BILLS, 4–7 data refresh, 3–9 Transfer specifications, see CZ_XFR control tables
S U SCHEMA UI Servlet CZ_DB_SETTINGS, 3–4 properties, 5–5, 5–6, 5–8
Index-8 update list of tables to, 4–17 production Oracle Configurator schema, 4–17 Update Prices button, 5–2 upgrade Oracle Configurator release, 1–10 regenerate Active Model to, 1–10 URL see also InitServletURL, 2–6 runtime Oracle Configurator requirement, 2–6 usages and initialization message, 6–8 defining, 6–7 for planning publications, 6–2 publication applicability parameter, 6–7 user see also end user definition, 1–5 User Interface Oracle Configurator UI subschema, 3–4
V verify data import, 4–16 schema version, 1–21
W web deployment, 1–8, 7–1
X XFR_ control tables, see CZ_XFR control tables
Index-9 Index-10