Oracle® Configurator
Implementation Guide
Release 11i
April 2002 Part No. A87531-04
This book provides explanations, description, and instructions for the administration tasks required to set up and support development and deployment of a runtime Oracle Configurator. Oracle Configurator Implementation Guide Release 11i
Part No. A87531-04
Copyright © 1999, 2002 Oracle Corporation. All rights reserved.
Primary Author: Harriet Shanzer
Contributing Author: Tina Brand
Contributor: Josh Jujjavarapu, Vinay Kamath, Sarit Manna, Helen Reznick, Mike Sheehy, Alex Tsyaston
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, except to the extent required to obtain interoperability with other independently created software or as specified by law, 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 JInitiator, Oracle8, Oracle8i, Oracle9i, PL/SQL, SQL*Net, SQL*Plus, and SellingPoint are trademarks or registered trademarks of Oracle Corporation. Other names may be trademarks of their respective owners. Contents
List of TablesFiguresExamples
Send Us Your Comments ...... xxi
Preface...... xxiii Intended Audience ...... xxiii Documentation Accessibility ...... xxiii Structure...... xxiv Related Documents...... xxv Conventions...... xxvi Product Support...... xxvii
1 Introduction 1.1 Runtime Oracle Configurators ...... 1–1 1.1.1 Keyboard Access in the Runtime Configurator...... 1–2 1.2 Oracle Configurator Schema...... 1–3 1.3 Overview of Oracle Configurator Implementation...... 1–3 1.3.1 Concurrent Programs ...... 1–5 1.4 Terms...... 1–6 1.5 Profile Options...... 1–7 1.6 Requirements ...... 1–7 1.7 Oracle Configurator Environments ...... 1–7 1.7.1 Development...... 1–8 1.7.2 Testing...... 1–10 1.7.3 Production...... 1–11
v 1.7.4 Maintenance ...... 1–12 1.8 Oracle Configurator Architecture Overview...... 1–13 1.8.1 Multiple Language Support...... 1–14 1.8.1.1 Precedence of Language Settings...... 1–15 1.8.1.2 Installed Languages ...... 1–15 1.9 Implementation Tasks...... 1–15 1.9.1 Commonly Performed Implementation Tasks ...... 1–16 1.9.1.1 Server Administration ...... 1–17 1.9.1.2 View the Status of Oracle Configurator Concurrent Programs Requests ... 1–21 1.9.1.3 Query Registered Oracle Configurator Concurrent Programs ...... 1–22 1.9.1.4 Connect to a Database Instance...... 1–22 1.9.1.5 Verify Oracle Configurator Schema Version ...... 1–23 1.9.1.6 Checking BOM and Model Similarity...... 1–24
2 The spx.ini File 2.1 Parameters in spx.ini ...... 2–3 2.1.1 [Merlin] ...... 2–4 2.1.2 [DSN]...... 2–4 2.1.3 [odbc-dsn]...... 2–5 2.1.4 [Design Chart]...... 2–8 2.1.5 Data Source-Specific Test Sessions ...... 2–8 2.1.6 Parameterized Startup of Oracle Configurator Developer ...... 2–10
3 The Oracle Configurator Schema 3.1 Characteristics of the Oracle Configurator Schema...... 3–1 3.1.1 ADMN Administrative Tables ...... 3–2 3.1.2 CNFG Configuration Tables...... 3–2 3.1.3 ITEM Item-Master Tables...... 3–2 3.1.4 LCE Logic for Configuration Tables...... 3–3 3.1.5 PB Publication Tables ...... 3–3 3.1.6 PROJ Project Structure Tables ...... 3–3 3.1.7 RULE Rule Tables...... 3–3 3.1.8 RP Repository Tables...... 3–4 3.1.9 UI User Interface Tables ...... 3–4 3.1.10 XFR Transfer Specifications and Control Tables ...... 3–4
vi 3.1.11 Obsolete Tables or Relevant to Oracle SellingPoint...... 3–4 3.1.11.1 Obsolete Tables ...... 3–4 3.1.11.2 Tables currently not used ...... 3–5 3.1.11.3 Oracle SellingPoing tables ...... 3–5 3.2 Oracle Configurator Schema Settings ...... 3–6 3.2.1 CZ_DB_SETTINGS for SCHEMA...... 3–12 3.2.2 CZ_DB_SETTINGS for ORAAPPS_INTEGRATE...... 3–12 3.2.3 CZ_DB_Settings for IMPORT...... 3–14 3.3 Editing the CZ_DB_SETTINGS Values ...... 3–16 3.3.1 Modify Configurator Parameters ...... 3–17 3.3.2 View Configurator Parameters ...... 3–17 3.3.3 Modify Description Translation Supported by MLS ...... 3–17 3.3.3.1 Update the PS Node Description With Translations ...... 3–18 3.3.3.2 Updating the UI Node’s Label Text with Translations ...... 3–20 3.4 Oracle Configurator Schema Maintenance...... 3–22 3.4.1 Refresh or Update the Production Schema ...... 3–22 3.4.2 Purge Configurator Tables...... 3–23 3.4.3 Redo Sequences ...... 3–24
4 Importing Data 4.1 Data Import Overview...... 4–1 4.1.1 Data Import and Multiple Language Support (MLS)...... 4–3 4.1.1.1 New Models...... 4–4 4.1.1.2 Existing Models...... 4–5 4.1.2 Import Tables...... 4–5 4.1.2.1 Import Control Fields...... 4–5 4.1.2.2 Online Data Fields ...... 4–6 4.1.2.3 Surrogate Key Fields...... 4–6 4.1.3 Control Tables (CZ_XFR_)...... 4–7 4.2 The Import Process...... 4–12 4.3 Data Imported into the CZ Schema ...... 4–13 4.4 Data Import Setup...... 4–14 4.5 Importing Data From Oracle Applications...... 4–15 4.5.1 Decimal or Integer Quantities ...... 4–15 4.5.1.1 Impact on Import ...... 4–16
vii 4.6 Data Import Concurrent Program ...... 4–17 4.6.1 Importing from Oracle Bills of Material...... 4–18 4.6.1.1 Enabling a Server for Import...... 4–18 4.6.1.2 Changing a Server for Import ...... 4–19 4.6.1.3 Exploding BOMs in Oracle Applications ...... 4–19 4.6.1.4 Running the Populate Configuration Models Concurrent Program...... 4–21 4.6.1.5 Running the Synchronize All Models Concurrent Program ...... 4–22 4.7 Verify Data Import ...... 4–22 4.8 Refresh and Update Imported Data...... 4–23 4.8.1 Running the Disable/Enable Refresh of a Configuration Model Concurrent Program ...... 4–25 4.8.2 Running the Refresh A Single Configuration Model Concurrent Program ...... 4–26 4.8.3 Running the Refresh All Imported Configuration Models Concurrent Program ...... 4–26 4.8.4 Refreshing BOM Models that Have Changed Type...... 4–27 4.8.4.1 Populate and Refresh Scenarios...... 4–27 4.9 Customizing Data Import ...... 4–31 4.9.1 Importing Data Into Specific Tables ...... 4–32 4.9.2 Importing/Extracting Data from Specific Fields...... 4–33 4.9.3 Modifying CZ_XFR_PROJECT_BILLS.EXPLOSION_TYPE...... 4–33 4.9.4 Creating a Custom Import ...... 4–33 4.9.4.1 Setup for a Custom Import ...... 4–34 4.9.4.2 Extraction Setup for a Custom Import...... 4–35 4.9.4.3 Required ASCII File Format for Custom Import...... 4–36 4.9.4.4 Running a Custom Import...... 4–37
5 Pricing in Oracle Configurator 5.1 Pricing in a Runtime 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–2 5.2 Runtime Oracle Configurator Pricing Architecture ...... 5–3 5.3 Controlling Pricing in the Runtime Oracle Configurator...... 5–5 5.3.1 Displaying Price Types...... 5–5
viii 5.3.1.1 Setting the OC Servlet Property for Price Types ...... 5–5 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 Publications...... 6–4 6.2.1 Publication Attributes...... 6–4 6.2.1.1 Product ...... 6–4 6.2.1.2 Model ...... 6–5 6.2.1.3 Database Instance...... 6–5 6.2.1.4 User Interface...... 6–6 6.2.2 Publication Applicability Parameters ...... 6–6 6.2.2.1 Publication Mode ...... 6–6 6.2.2.2 Application ...... 6–7 6.2.2.3 Date Range ...... 6–8 6.2.2.4 Usages...... 6–8 6.2.2.5 Decimal Quantities ...... 6–10 6.3 Synchronizing a Configuration Model with the BOM...... 6–10 6.4 Creating the Publication...... 6–11 6.4.1 Publishing a Single Pending Configuration Model ...... 6–11 6.4.2 Publishing All Pending Configuration Models ...... 6–12 6.5 Tables Used in Publishing...... 6–12 6.6 Profile Options Used in Publishing ...... 6–13 6.6.1 Setting Profile Options ...... 6–13 6.7 Publishing and Effectivity...... 6–14 6.8 Publishing and Referencing...... 6–14 6.9 Updating or Republishing Publications...... 6–14
ix 6.9.1 Determining Publishing Information...... 6–15 6.10 Editing Publications ...... 6–15 6.11 Disabling, Deleting, and Re-enabling Publications ...... 6–15 6.12 Lost Publications Due to Database Instance Failure ...... 6–16 6.12.1 Failed Target Database ...... 6–16 6.12.2 Failed Source Database...... 6–16
7 Programmatic Tools for Development 7.1 Overview of the CZ_CF_API Package ...... 7–1 7.1.1 Purpose of the Package...... 7–1 7.1.2 Overview of Procedures and Functions...... 7–1 7.1.3 Installation of the Package ...... 7–3 7.1.4 References for Working with PL/SQL Procedures and Functions...... 7–3 7.2 Choosing the Right Tool for the Job...... 7–4 7.2.1 Establishing Session Identity ...... 7–4 7.2.2 Setting Configuration Dates ...... 7–4 7.2.3 Validating Configurations ...... 7–4 7.2.4 Copying and Deleting Configurations...... 7–4 7.2.5 Working with Common Bills...... 7–5 7.2.6 Identifying Publications ...... 7–5 7.2.6.1 Functions for Identifying Publications...... 7–5 7.2.6.2 Applicability Parameters ...... 7–6 7.2.6.3 List Parameters ...... 7–7 7.3 Reference for the CZ_CF_API Package ...... 7–8 7.3.1 Custom Data Types...... 7–8 7.3.2 Procedures and Functions in the CZ_CF_API Package...... 7–9 COMMON_BILL_FOR_ITEM ...... 7–11 CONFIG_MODEL_FOR_ITEM ...... 7–13 CONFIG_MODELS_FOR_ITEMS...... 7–15 CONFIG_MODEL_FOR_PRODUCT ...... 7–17 CONFIG_MODELS_FOR_PRODUCTS ...... 7–19 CONFIG_UI_FOR_ITEM...... 7–21 CONFIG_UI_FOR_ITEM_LF...... 7–24 CONFIG_UI_FOR_PRODUCT...... 7–27
x CONFIG_UIS_FOR_ITEMS ...... 7–29 CONFIG_UIS_FOR_PRODUCTS...... 7–31 COPY_CONFIGURATION...... 7–33 COPY_CONFIGURATION_AUTO...... 7–35 DEFAULT_NEW_CFG_DATES...... 7–37 DEFAULT_RESTORED_CFG_DATES...... 7–39 DELETE_CONFIGURATION ...... 7–41 ICX_SESSION_TICKET ...... 7–43 MODEL_FOR_ITEM...... 7–44 MODEL_FOR_PUBLICATION_ID ...... 7–46 PUBLICATION_FOR_ITEM...... 7–47 PUBLICATION_FOR_PRODUCT ...... 7–49 PUBLICATION_FOR_SAVED_CONFIG ...... 7–51 UI_FOR_ITEM ...... 7–53 UI_FOR_PUBLICATION_ID...... 7–55 VALIDATE...... 7–57
8 Programmatic Tools for Maintenance 8.1 Overview of the CZ_modelOperations_pub Package ...... 8–1 8.1.1 Purpose of the Package ...... 8–1 8.1.2 Installation of the Package ...... 8–1 8.1.3 References for Working with PL/SQL Procedures...... 8–2 8.2 Choosing the Right Tool for the Job ...... 8–2 8.3 Queries to Support the CZ_modelOperations_pub Package...... 8–3 8.3.1 Querying for Model IDs...... 8–3 8.3.2 Querying for User Interface IDs...... 8–4 8.3.3 Querying for Referenced User Interface IDs...... 8–4 8.3.4 Querying for Populators ...... 8–5 8.3.5 Querying for Error and Warning Information...... 8–6 8.4 Reference for the CZ_modelOperations_pub Package...... 8–6 8.4.1 Custom Data Types...... 8–7 8.4.2 API Version Numbers ...... 8–7 8.4.2.1 Format of API Version Numbers...... 8–7
xi 8.4.2.2 Current API Version Number for This Package...... 8–8 8.4.2.3 Checking for Incompatible API Calls...... 8–8 8.4.3 Procedures in the CZ_modelOperations_pub Package...... 8–8 CREATE_UI...... 8–10 DEEP_MODEL_COPY...... 8–13 EXECUTE_POPULATOR...... 8–15 GENERATE_LOGIC ...... 8–17 IMPORT_SINGLE_BILL...... 8–19 PUBLISH_MODEL...... 8–20 REFRESH_SINGLE_MODEL...... 8–21 REFRESH_UI...... 8–22 REPOPULATE ...... 8–24 REPUBLISH_MODEL...... 8–26
9 Configuration Attributes 9.1 Overview of Configuration Attributes...... 9–1 9.1.1 Purpose ...... 9–1 9.1.1.1 Typical Problems To Be Solved...... 9–1 9.1.1.2 Solutions ...... 9–2 9.1.1.3 Use of Configuration Attributes for Input ...... 9–3 9.1.1.4 Use of Configuration Attributes for Output ...... 9–3 9.1.2 Overviews of Implementing Configuration Attributes...... 9–5 9.1.2.1 Overview of Implementing Configuration Attributes for Input ...... 9–5 9.1.2.2 Overview of Implementing Configuration Attributes for Output ...... 9–6 9.1.3 Deploying the Solution...... 9–6 9.2 Implementing Configuration Attributes for Input...... 9–7 9.2.1 Example for Implementing Input Configuration Attributes ...... 9–7 9.2.2 Host Application Integration with Oracle Configurator...... 9–9 9.2.2.1 Responsibilities For Oracle Applications Host ...... 9–9 9.2.2.2 Responsibilities For Custom Application Host ...... 9–12 9.2.2.3 Responsibilities For Functional Companion Implementer ...... 9–12 9.2.3 Modifying the Model...... 9–12 9.2.3.1 Creating Features ...... 9–13 9.2.3.2 Creating Options ...... 9–13
xii 9.2.3.3 Creating Functional Companion Rules ...... 9–13 9.2.4 Modifying the Functional Companion Example...... 9–14 9.2.4.1 Implementing AutoFunctionalCompanion Methods...... 9–15 9.2.4.2 Structuring the Behavior...... 9–16 9.2.4.3 Getting Session Parameters ...... 9–17 9.2.4.4 Identifying the Host Application...... 9–18 9.2.4.5 Extracting Input Attribute Data for the Specified Quote Line ...... 9–19 9.2.4.6 Transferring Data to Features ...... 9–20 9.2.4.7 Guidelines for the Functional Companion...... 9–22 9.2.5 Runtime Behavior ...... 9–24 9.3 Implementing Configuration Attributes for Output...... 9–24 9.3.1 The CZ_CONFIG_ATTRIBUTES Table ...... 9–27 9.3.1.1 Table Layout and Description...... 9–27 9.3.2 Defining Descriptive Flexfields...... 9–28 9.3.3 Modifying the Model...... 9–30 9.3.3.1 Design Principles ...... 9–30 9.3.3.2 Example of Model Structure...... 9–33 9.3.3.3 Alternative Modeling Strategies...... 9–37 9.3.3.4 Special Considerations ...... 9–40 9.3.3.5 Creating Functional Companion Rules ...... 9–41 9.3.4 The Output Functional Companion ...... 9–42 9.3.5 Using Configuration Attributes in the Downstream Application ...... 9–43 9.3.5.1 Storing Output Data for Downstream Use ...... 9–44 9.3.5.2 Using Output Data in Downstream Applications ...... 9–45 9.3.5.3 Linking Configuration Attributes to Flexfields...... 9–46 9.3.5.4 Downstream User Interfaces...... 9–47 9.3.6 Maintaining the Output Solution...... 9–48 9.3.7 Optional Flows ...... 9–49 9.3.7.1 Modifying the Functional Companion ...... 9–49
10 Deploying Oracle Configurator 10.1 Calling an Embedded Oracle Configurator ...... 10–1 10.1.1 Java Applet Requirements ...... 10–2 10.1.2 DHTML Requirements...... 10–2 10.2 Deployment Strategies...... 10–3
xiii 10.2.1 Architectural Considerations...... 10–3 10.2.2 Server Considerations...... 10–4 10.2.2.1 Connection Pooling...... 10–5 10.2.3 Implementing Oracle Configurator with Secure Sockets Layer...... 10–6 10.2.3.1 Editing jserv.properties for Secure Sockets Layer...... 10–7 10.2.3.2 Verifying AltBatchValidateURL ...... 10–8 10.2.3.3 Enabling the Oracle Configurator Client for Secure Sockets Layer...... 10–8 10.2.4 Network Considerations ...... 10–10 10.2.4.1 Firewalls and Timeouts...... 10–10 10.2.4.2 Router Timeouts...... 10–10 10.2.4.3 Miscellaneous Issues...... 10–11 10.2.5 Multiple Language Support Considerations...... 10–11 10.2.6 Changing Development and Production Database Instances ...... 10–11 10.2.7 Pre-Loading the Oracle Configurator Servlet ...... 10–12 10.3 Deployment Tasks...... 10–13 10.3.1 Setting Profile Options...... 10–13 10.3.1.1 Profile Option - Populate Decimal Quantity Flag ...... 10–14 10.3.2 Establishing End User Access...... 10–14 10.3.3 Load Testing...... 10–14 10.3.3.1 Stress Testing ...... 10–15 10.3.3.2 User Activity Testing...... 10–15 10.3.4 Load Balancing ...... 10–15
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
B Code Examples B.1 Using Configuration Attributes for Input...... B–1 B.2 Using Configuration Attributes for Output ...... B–10
xiv Glossary of Terms and Acronyms Index
xv List of Examples 2–1 Default Installed spx.ini...... 2–1 2–2 Modified spx.ini File ...... 2–2 4–1 Data Transfer File Format...... 4–36 7–1 Using the UI_FOR_PUBLICATION_ID Function ...... 7–55 8–1 Query for Models and Folders...... 8–3 8–2 Query for User Interface IDs...... 8–4 8–3 Query for Referenced User Interface IDs...... 8–4 8–4 Query for Populators ...... 8–5 8–5 Query for Error and Warning Information...... 8–6 8–6 Using the GENERATE_LOGIC Procedure ...... 8–18 9–1 Configuration Attribute Parameters in the Initialization Message...... 9–11 9–2 Query for Names of Oracle Applications ...... 9–19 9–3 Structure of Sample BOM Model ...... 9–33 9–4 Configuration Attributes for Sample BOM Model...... 9–34 9–5 Flexfield Contexts and Segments for Sample BOM Model ...... 9–34 9–6 Configuration Model Structure for Sample BOM Model ...... 9–34 9–7 Reusing an Attribute Value for Multiple Items ...... 9–37 9–8 Reusing an Attribute Value for Multiple Contexts...... 9–38 9–9 Using Different Contexts with Different Values...... 9–39 9–10 Query for Value of ATTRIBUTE1 ...... 9–45 9–11 Value of ATTRIBUTE1...... 9–45 9–12 Strings for Property Names in the Functional Companion...... 9–49 10–1 The jserv.properties File System Parameters for SSL...... 10–7 10–2 Change Development and Production Database Instances ...... 10–11 B–1 Using Configuration Attributes for Input (CfgInputExample.java) ...... B–2 B–2 Using Configuration Attributes for Output (WriteAttributes.java)...... B–10
xvi Oracle Configurator Implementation Guide List of Figures 1–1 Development Installation...... 1–9 1–2 Production Installation ...... 1–12 1–3 Overview of Oracle Configurator Architecture...... 1–14 1–4 Implementation Task Flow ...... 1–16 2–1 OCD Logon Screen...... 2–5 4–1 Overview of Data Import ...... 4–2 4–2 Overview of Data Import from Oracle Bills of Material...... 4–17 4–3 Initial Import of BOM Model with Submodels...... 4–28 4–4 Populate and Refresh of Initial BOM Model ...... 4–29 4–5 Import a New BOM Model with References to Existing BOM Models ...... 4–30 4–6 Importing a Common Bill Referenced in Another Organization...... 4–31 4–7 Overview of Custom Import ...... 4–35 4–8 Extraction Setup for a Custom Import ...... 4–36 5–1 Runtime Oracle Configurator Pricing Architecture ...... 5–4 9–1 Control and Data Flow at Design Time for Output ...... 9–26 9–2 Control and Data Flow at Run Time for Output ...... 9–27 9–3 Segments Summary for a Context ...... 9–30 9–4 Flow for Oracle Applications UI with Flexfields...... 9–47 9–5 Flow for Oracle Applications UI with Flexfields with Joined Tables...... 9–48 9–6 Flow for Custom Application UI ...... 9–48
xvii List of Tables
1–1 Keyboard Access in the Configurator Runtime UI...... 1–2 1–2 Oracle Configurator Concurrent Programs for Server Administration ...... 1–18 1–3 Fields Synchronized for Import...... 1–25 3–1 CZ_DB_SETTINGS...... 3–7 3–2 Valid Values for the BadItemPropertyValue Setting ...... 3–15 3–3 Oracle Configurator Administration Concurrent Programs...... 3–16 4–1 Import Control Fields...... 4–5 4–2 Fields in CZ_XFR_TABLES...... 4–7 4–3 Fields in CZ_XFR_FIELDS ...... 4–8 4–4 Fields in CZ_XFR_PROJECT_BILLS...... 4–9 4–5 Oracle Applications Source and Destination Online Tables ...... 4–12 4–6 Properties Imported from Oracle Inventory...... 4–14 5–1 Switch Effects ...... 5–6 5–2 Examples and Effect of Pricing Switches ...... 5–7 5–3 Item Price Option Effects...... 5–7 5–4 List Price Property Settings...... 5–9 5–5 Selling Price Property Settings...... 5–9 6–1 Publication Tables...... 6–13 7–1 Overview of Procedures and Functions in the Package CZ_CF_API...... 7–1 7–2 References for Working with PL/SQL Procedures and Functions...... 7–3 7–3 Applicability Parameters for Publication Searches ...... 7–6 7–4 Custom Data Types in the Package CZ_CF_API...... 7–8 7–5 Procedures and Functions in the Package CZ_CF_API...... 7–9 7–6 Parameters for the COMMON_BILL_FOR_ITEM Procedure...... 7–12 7–7 Parameters for the CONFIG_MODEL_FOR_ITEM Function...... 7–14 7–8 Parameters for the CONFIG_MODELS_FOR_ITEMS Function...... 7–16 7–9 Parameters for the CONFIG_MODEL_FOR_PRODUCT Function ...... 7–18 7–10 Parameters for the CONFIG_MODELS_FOR_PRODUCTS Function...... 7–20 7–11 Parameters for the CONFIG_UI_FOR_ITEM Function ...... 7–22 7–12 Parameters for the CONFIG_UI_FOR_ITEM_LF Function...... 7–25 7–13 Parameters for the CONFIG_UI_FOR_PRODUCT Function...... 7–28 7–14 Parameters for the CONFIG_UIS_FOR_ITEMS Function ...... 7–30 7–15 Parameters for the CONFIG_UIS_FOR_PRODUCTS Function ...... 7–32 7–16 Parameters for the COPY_CONFIGURATION Procedure ...... 7–34 7–17 Parameters for the COPY_CONFIGURATION_AUTO Procedure ...... 7–36 7–18 Parameters for the DEFAULT_NEW_CFG_DATES Procedure ...... 7–37 7–19 Parameters for the DEFAULT_RESTORED_CFG_DATES Procedure ...... 7–40 7–20 Parameters for the DELETE_CONFIGURATION Procedure...... 7–41 7–21 Parameters for the MODEL_FOR_ITEM Function...... 7–45
xviii 7–22 Parameters for the MODEL_FOR_PUBLICATION_ID Function ...... 7–46 7–23 Parameters for the PUBLICATION_FOR_ITEM Function...... 7–48 7–24 Parameters for the PUBLICATION_FOR_PRODUCT Function...... 7–50 7–25 Parameters for the PUBLICATION_FOR_SAVED_CONFIG Function...... 7–52 7–26 Parameters for the UI_FOR_ITEM Function ...... 7–54 7–27 Parameters for the UI_FOR_PUBLICATION_ID Function...... 7–55 7–28 Parameters for the VALIDATE Procedure ...... 7–57 8–1 Procedures in the Package CZ_modelOperations_pub...... 8–8 8–2 Parameters for the CREATE_UI Procedure...... 8–11 8–3 Parameters for the DEEP_MODEL_COPY Procedure...... 8–13 8–4 Parameters for the EXECUTE_POPULATOR Procedure...... 8–15 8–5 Parameters for the GENERATE_LOGIC Procedure ...... 8–17 8–6 Parameters for the IMPORT_SINGLE_BILL Procedure...... 8–19 8–7 Parameters for the PUBLISH_MODEL Procedure...... 8–20 8–8 Parameters for the REFRESH_SINGLE_MODEL Procedure...... 8–21 8–9 Parameters for the REFRESH_UI Procedure...... 8–22 8–10 Parameters for the REPOPULATE Procedure ...... 8–24 8–11 Parameters for the REPUBLISH_MODEL Procedure...... 8–27 9–1 Sources for Values of the client_header Parameter...... 9–10 9–2 Sources for Values of the client_line Parameter...... 9–10 9–3 Sources for Values of the client_line_detail Parameter...... 9–11 9–4 Typical IDs and Short Names for Oracle Applications ...... 9–19 9–5 The CZ_CONFIG_ATTRIBUTES Table ...... 9–28 9–6 Flexfield Settings for All Contexts ...... 9–29 9–7 Properties for Defining Configuration Attributes ...... 9–32 9–8 Example Attribute Properties (Database Results) ...... 9–37 9–9 Reusing an Attribute Value for Multiple Items (Database Results) ...... 9–38 9–10 Reusing an Attribute Value for Multiple Contexts (Database Results)...... 9–39 9–11 Using Different Contexts with Different Values (Database Results)...... 9–40 10–1 Information Details Mapped to Oracle Configurator Documentation...... 10–3 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_ITEM_MASTER Import Table...... A–6 A–6 Description of Fields in CZ_IMP_ITEM_PROPERTY_VALUE Import Table...... A–9 A–7 Description of Fields in CZ_IMP_ITEM_TYPE Import Table ...... A–12 A–8 Description of Fields in CZ_IMP_ITEM_TYPE_PROPERTY Import Table...... A–14 A–9 Description of Fields in CZ_IMP_LOCALIZED_TEXTS Import Table...... A–17 A–10 Description of Fields in CZ_IMP_PROPERTY Import Table...... A–18 A–11 Description of Fields in CZ_IMP_PS_NODES Import Table...... A–21
xix xx Send Us Your Comments
Oracle Configurator Implementation Guide, Release 11i Part No. A87531-04
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 title and part number of the documentation and the chapter, section, and page number (if available). You can send comments to us in the following ways:
■ Electronic mail: [email protected] ■ FAX: 781-238-9898 Attn: Oracle Configurator Documentation ■ Postal service: Oracle Corporation Oracle Configurator Documentation 10 Van de Graaff Drive Burlington, MA 01803-5146 USA
If you would like a reply, please give your name, address, telephone number, and electronic mail address (optional). If you have problems with the software, please contact your local Oracle Support Services.
xxi xxii Preface
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 runtime 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.
Documentation Accessibility Our goal is to make Oracle products, services, and supporting documentation accessible, with good usability, to the disabled community. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Standards will continue to evolve over time, and Oracle Corporation is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For additional information, visit the Oracle Accessibility Program Web site at http://www.oracle.com/accessibility/.
xxiii Accessibility of Code Examples in Documentation JAWS, a Windows screen reader, may not always correctly read the code examples in this document. The conventions for writing code require that closing braces should appear on an otherwise empty line; however, JAWS may not always read a line of text that consists solely of a bracket or brace.
Accessibility of Links to External Web Sites in Documentation This documentation may contain links to Web sites of other companies or organizations that Oracle Corporation does not own or control. Oracle Corporation neither evaluates nor makes any representations regarding the accessibility of these Web sites.
Structure This manual contains a table of contents, lists of examples, tables and figures, a reader comment form, several chapters, appendix, glossary and index:
■ Chapter 1, "Introduction" provides an overview of Oracle Configurator and describes the software components and runtime Oracle Configurators. It provides an overview of Oracle Configurator administrative tasks, terms, the types of Oracle Configurator installations, and the Oracle Configurator architecture.
■ Chapter 2, "The spx.ini File" describes the spx.ini file and how it is used. It provides an example of a spx.ini file and detailed explanation of its parameters and how they are used.
■ Chapter 3, "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.
■ Chapter 4, "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.
■ Chapter 5, "Pricing in Oracle Configurator" provides an overview of how pricing works in a runtime Oracle Configurator and the pricing architecture.
■ Chapter 6, "Publishing Configuration Models" explains the publishing process and the resulting database processes that make configuration models available to hosting applications.
xxiv ■ Chapter 7, "Programmatic Tools for Development" describes a set of programmatic tools (PL/SQL procedures and functions) that may be useful in developing a configuration model and deploying a runtime Oracle Configurator.
■ Chapter 8, "Programmatic Tools for Maintenance" describes a set of programmatic tools (PL/SQL procedures) that you can use primarily to maintain a deployed runtime Oracle Configurator.
■ Chapter 9, "Configuration Attributes" describes the methodology for using certain configuration features of Oracle Configurator and host applications to capture and exchange data that is not standard inventory information.
■ Chapter 10, "Deploying Oracle Configurator" provides information for deploying a runtime Oracle Configurator and accessing a runtime 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.
■ Appendix B, "Code Examples" contains code examples that support other chapters of this document. These examples are fuller and longer than the examples provided in the rest of this document, which are often fragments.
■ "Glossary of Terms and Acronyms" contains definitions that you may need while working with Oracle Configurator documentation.
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
■ Oracle Configuration Interface Object (CIO) Developer’s Guide For more information, see the documentation for Oracle Applications (Release 11i) Oracle RDBMS (Release 8i or 9i), the Oracle Applications Library, the product-specific
xxv Release Notes for releases supported to work with Oracle Configurator, and the eTRM on metalink, Oracle’s Customer Support Web site at: http://metalink.oracle.com
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 new term, a term defined in the glossary, specific keys, and labels of user interface objects. Boldface type also indicates a menu, command, or option, especially within procedures italics Italic type in text, tables, or code examples indicates user-supplied text. Replace these placeholders with a specific value or string. [ ] Brackets enclose optional clauses from which you can choose one or none. > The left bracket alone represents the MS DOS prompt. $ The dollar sign represents the DIGITAL Command Language prompt in Windows and the Bourne shell prompt in Digital UNIX. % The per cent sign alone represents the UNIX prompt. name() In text other than code examples, the names of programming language methods and functions are shown with trailing parentheses. The parentheses are always shown as empty. For the actual argument or parameter list, see the reference documentation. This convention is not used in code examples.
xxvi 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) using Metalink, Oracle’s customer support Web site, at: http://metalink.oracle.com/
Log into your Metalink account and navigate to the Configurator TAR template: 1. Choose the TARs link in the left menu. 2. Click on Create a TAR. 3. Fill in or choose a profile. 4. In the same form: a. Choose Product: Oracle Configurator or Oracle Configurator Developer b. Choose Type of Problem: Oracle Configurator Generic Issue template 5. Provide the information requested in the iTAR template. You can also find product-specific documentation and other useful information using Metalink. For a complete listing of available Oracle Support Services and phone numbers, see: http://www.oracle.com/support
xxvii xxviii 1 Introduction
Oracle Configurator consists of the runtime Oracle Configurator, Oracle Configurator Developer, and the Oracle Configurator schema (CZ). The runtime 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 the basic implementation tasks necessary for supporting use of a runtime Oracle Configurator in the following general environments:
■ Oracle Applications Release 11i hosting applications that support Oracle Configurator. For a list of the hosting applications see the Oracle Configurator Release Notes.
■ A custom web application using Oracle Configurator.
■ A runtime Oracle Configurator using imported Oracle Applications Release 11.0 or 10.7, or non-Oracle or legacy data.
■ Oracle Configurator Developer.
1.1 Runtime Oracle Configurators Throughout this book, references to a runtime Oracle Configurator means a runtime Oracle Configurator embedded in another application. A runtime Oracle Configurator is an end user environment for configuring products and services. Implementers or developers of a runtime Oracle Configurator use Oracle Configurator Developer to develop configuration models and user interface customizations. You can unit test your configuration models in the development instance from within Oracle Configurator Developer. See Section 1.7.1, "Development" on page 1-8 for more information. After publishing a Model and
Introduction 1-1 Runtime Oracle Configurators
setting up the host application to call the runtime Oracle Configurator, you can system test your configuration models. A runtime 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.1.1 Keyboard Access in the Runtime Configurator Oracle Configurator Developer enables end users with disabilities to navigate the runtime Configurator window using only the keyboard. For example, end users can shift the focus onto each item in the runtime UI by pressing the Tab key, and then move to each item from left to right and from the top to the bottom of the page. (The item with the focus is highlighted in the UI.) Table 1–1 lists all of the available keystrokes and the corresponding actions at runtime. These commands perform the same action in both the Configurator Java applet and DHTML runtime UIs.
Table 1–1 Keyboard Access in the Configurator Runtime UI Press this . . . If you want to . . . Tab Move the focus forward to each item in the UI (from left to right, top to bottom of the page). Navigate to the next frame. For example, from the navigation tree to the selection window. Shift+Tab Move the focus in the reverse order through the UI (right to left, bottom to top). In the Java applet, Shift+Tab navigates to the previous frame. In the DHTML window, this combination moves the focus to each control in the current frame in reverse order before navigating to the previous frame. Ctrl+Shift+Tab In the DHTML window, navigates to the previous frame, skipping each UI control in the current frame. Ctrl+Tab In the DHTML window, navigates to the next frame. Enter Select an item or implement an action (for example, activate the Done button to commit the configuration). Expand or collapse the selected branch in the navigation tree. Space Bar Toggle the state of a check box. For example, change the status from selected (true) to deselected (false).
1-2 Oracle Configurator Implementation Guide Overview of Oracle Configurator Implementation
Table 1–1 (Cont.) Keyboard Access in the Configurator Runtime UI Press this . . . If you want to . . . Up and Down Arrow Move the focus through each item in a list of options. Keys Move the focus up and down through the navigation tree. Left and Right Arrow Scroll to the left or right. Keys Delete Deselect a selected item.
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 program request. SQL*Plus scripts available on the Oracle Configurator Developer compact disc enable you to import 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 runtime 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
■ Deploying a runtime Oracle Configurator This book does not present instructions for
Introduction 1-3 Overview of Oracle Configurator Implementation
■ Establishing any privileges to any user, including DBA privileges
■ Establishing a database instance
■ Installing Oracle Applications for using the runtime Oracle Configurator
■ Installing and setting up Oracle8i Enterprise Edition RDBMS
■ Maintaining a deployed runtime Oracle Configurator See other relevant Oracle documentation for help with these other tasks. 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 provides support for problems with the system. They may perform setup and initial maintenance of the production system or advise their client’s operational staff on these tasks. The system administrator works with the project team to optimize system performance, install packaged applications environments, and convert data. An Oracle Database Administrator installs and maintains database access controls. This person also provides consultation on performance and is responsible for monitoring growth and fragmentation of the production database and ensuring database backup and recovery. 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 as a runtime Oracle Configurator using the Oracle Configurator Developer, then access that configuration model as an item in Order Management, configure the item in the runtime 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 access an ATO or PTO BOM in Bills of Material, Order Management, Oracle Quoting, or Telesales without importing it into the CZ schema or using Oracle Configurator Developer to create a configuration model.
1-4 Oracle Configurator Implementation Guide Overview of Oracle Configurator Implementation
1.3.1 Concurrent Programs Oracle Configurator provides concurrent programs for many 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 information about assigning responsibilities, see the Oracle Configurator Installation Guide. Concurrent programs are available for the following tasks:
■ View Configurator Parameters on page 3-17
■ Modify Configurator Parameters on page 3-17
■ Purge Configurator Tables on page 3-23
■ Define a remote server (see Section 1.9.1.1, "Server Administration" on page 1-17)
■ Enable a remote server (see Section 1.9.1.1, "Server Administration" on page 1-17)
■ View servers (see Section 1.9.1.1, "Server Administration" on page 1-17)
■ Modify server definitions (see Section 1.9.1.1, "Server Administration" on page 1-17)
■ Process pending publications (see Section 6.4.2, "Publishing All Pending Configuration Models" on page 6-12)
■ Process a single publication (see Section 6.4.1, "Publishing a Single Pending Configuration Model" on page 6-11)
■ Import Bills (see Section 4.6.1, "Importing from Oracle Bills of Material" on page 4-18)
■ Refresh a single configuration model (see Section 4.8.2, "Running the Refresh A Single Configuration Model Concurrent Program" on page 4-26)
■ Refresh all imported configuration models (see Section 4.8.3, "Running the Refresh All Imported Configuration Models Concurrent Program" on page 4-26)
■ Disable or enable the refresh of a configuration model (see Section 4.8.1, "Running the Disable/Enable Refresh of a Configuration Model Concurrent Program" on page 4-25)
■ Show or select specific tables to be imported (see Section 4.9.1, "Importing Data Into Specific Tables" on page 4-32)
Introduction 1-5 Terms
■ Synchronize all Models (for details see Section 1.9.1.6, "Checking BOM and Model Similarity" on page 1-24)
■ Requests (see Section 1.9.1.2, "View the Status of Oracle Configurator Concurrent Programs Requests" on page 1-21)
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 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. The database instance that serves as the source of data to be imported or refreshed in the CZ schema is called the import server or remote server. 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 runtime Oracle Configurator. End users are the users of runtime Oracle Configurators
1-6 Oracle Configurator Implementation Guide Oracle Configurator Environments
accessing a configuration model for a host system such as Order Management or iStore.
1.5 Profile Options Profile Options affect the way Oracle Applications look and behave. A System Administrator can set user profile values at the site, application, responsibility and user levels. See Oracle Applications System Administrator’s Guide for more information. For a listing of Oracle Configurator Profile Options, see the Oracle Configurator Installation Guide. The following profile options are discussed in the Oracle Configurator Implementation Guide: Decimal Quantity flag, see Section 4.5.1, "Decimal or Integer Quantities" on page 4-15. Profile Options relating to Publishing, see Section 6.6, "Profile Options Used in Publishing" on page 6-13.
1.6 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.7 Oracle Configurator Environments The Oracle Configurator schema and runtime 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 runtime 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:
Introduction 1-7 Oracle Configurator Environments
■ Development on page 1-8
■ Testing on page 1-10
■ Production on page 1-11
■ Maintenance on page 1-12 In any installation, you will be running the Oracle Configurator in one of the following scenarios:
■ Oracle Applications Release 11i with the Java applet runtime Oracle Configurator in a supported hosting application. For a list of hosting applications that support Oracle Configurator refer to the Oracle Configurator Release Notes.
■ Oracle Applications Release 11i with the DHTML runtime Oracle Configurator in a supported hosting application. For a list of hosting applications that support Oracle Configurator refer to the Oracle Configurator Release Notes.
■ A custom web application with a DHTML runtime Oracle Configurator for configuring items based on a configuration model.
■ A test instance of a runtime 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 scenario, see Section 3.2, "Oracle Configurator Schema Settings" on page 3-6.
1.7.1 Development A development environment is one in which you create your Oracle Configurator Model by constructing an end user interface referred to in this manual as a runtime 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.
1-8 Oracle Configurator Implementation Guide Oracle Configurator Environments
Note: There should only be one development instance.
Running a runtime 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 runtime Oracle Configurator. In order to develop a runtime 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" to either a test or production environment. See Chapter 6, "Publishing Configuration Models". In a test environment, the configuration models are tested for usability. 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" shows the flow of Imported Data such as legacy data or Oracle Applications 10.7 or 11.0 databases into the Oracle 8i Server and the network communication between the Oracle 8i Server with Oracle Configurator Developer.
Figure 1–1 Development Installation
Introduction 1-9 Oracle Configurator Environments
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 the source database and the Oracle Configurator schema are not on the same machine, then the remote server that holds the source database must be defined and enabled. Defining and enabling the remote server sets up the necessary database links between the source database and the Oracle Configurator schema. See the Define Remote Server and Enable Remote Server concurrent programs in Table 1–2, " Oracle Configurator Concurrent Programs for Server Administration" on page 1-18 for additional information. Likewise, the production or test instance to which you publish configuration models may or may not be the same instance as the development instance. If they are not the same instance, you must ensure that a remote server is defined and enabled to complete the publication successfully. See Section 1.9.1.1, "Server Administration" on page 1-17 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, Oracle recommends that you unit test your configuration model before transferring new or updated model data. Unit testing configuration models is performed in the Oracle Configurator Developer using the Test button. See the Oracle Configurator Developer User’s Guide for more information.
1.7.2 Testing A test environment is one in which you publish the Model to test the instance/environment and performs system testing on your runtime Oracle Configurator in preparation for initial deployment, upgrades, and new releases. Unit test is implemented by using the Test button in Oracle Configurator Developer. This enables the developer to test a configuration model’s rules and UI functionality in the development environment, making sure periodic rule and UI modifications work as desired. For additional information see the Oracle Configurator Developer User’s Guide. System test is implemented by publishing the Model to a testing environment/instance and having access to the Model from the host application. The testing environment is similar to the desired production environment, making sure that periodic data transfers and modifications work as required. For example, changes to the Model structure in Oracle Configurator Developer should propagate to the hosting application such as Order Management.
1-10 Oracle Configurator Implementation Guide Oracle Configurator Environments
1.7.3 Production A production environment is one in which end users of the runtime 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. If the developement database and the production database are not on the same machine, then the server holding the production database must be defined. Defining the remote server sets up the necessary database links between the development database and the production databse. See the Define Remote Server concurrent programs in Table 1–2, " Oracle Configurator Concurrent Programs for Server Administration" on page 1-18 for additionalinformation. For more efficient use of machine resources, purge records flagged for deletion before creating the production-ready version. See Section 3.4.2, "Purge Configurator Tables" on page 3-23 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-22. The Oracle Configurator schema is installed on the database server machine as part of your Oracle Applications database. In Figure 1–2, the networked runtime Oracle Configurator can be integrated with those hosting applications that support Oracle Configurator. For a list of supporting applications refer to the Oracle Configurator Release Notes. The runtime Oracle Configurator could also be embedded in a custom Web application. Figure 1–2, "Production Installation" shows the Production installation flow in the Oracle Applications Client/Server environment.
Introduction 1-11 Oracle Configurator Environments
Figure 1–2 Production Installation
In a Web environment, the runtime Oracle Configurator user interface runs in a browser. The Oracle Configurator (the application itself) runs on the application server machine with the internet application server brokering the processes and http connection. For more information see the Oracle Configurator Custom Web Deployment Guide.
1.7.4 Maintenance A maintenance environment is similar to a development environment since it is used to upgrade the CZ schema and refresh configuration data. When you deploy a runtime 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 runtime Oracle Configurator, you may conduct periodic updates from Oracle Applications or imports from your legacy data and redeploy the refreshed runtime Oracle Configurator. Another aspect of maintenance involves fixing and improving the configuration model and republishing it periodically. It is important to synchronize these changes in the maintenance Oracle Configurator schema with the Oracle Configurator
1-12 Oracle Configurator Implementation Guide Oracle Configurator Architecture Overview
schema under development for the next release of your runtime Oracle Configurator. When you upgrade the release version of Oracle Configurator that your runtime Oracle Configurator runs against, you start by upgrading your Oracle Configurator schema. For information about updating your Oracle Configurator schema, see Section 3.4.1, "Refresh or Update the Production Schema" on page 3-22 and Section 3.4.3, "Redo Sequences" on page 3-24. 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 the Oracle Configurator schema, you must re-run the Generate Active Model command in Oracle Configurator Developer for each configuration model. There are precautions you must take so that you do not get unpredictable behavior at run time. See Chapter 6, "Publishing Configuration Models".
1.8 Oracle Configurator Architecture Overview No matter what the environment, the Oracle Configurator architecture is essentially the same. A runtime 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 runtime Oracle Configurator. The User Interface 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 runtime Oracle Configurator. The Active Model and UI also interact with the Oracle Configurator schema to present end users with a configuration model in which to make selections that result in a valid configuration. Figure 1–3, "Overview of Oracle Configurator Architecture" shows the an overview of the Oracle Configurator Architecture. Oracle Configurator and the Oracle Configurator Schema are installed on an Application server, and the Oracle Configurator Developer is on the client machine.
Introduction 1-13 Oracle Configurator Architecture Overview
Figure 1–3 Overview of Oracle Configurator Architecture
The CIO is the Configuration Interface Object, an API used for communication between the UI and the Active Model. For more information see the Oracle Configuration Interface Object (CIO) Developer’s Guide
1.8.1 Multiple Language Support Each Oracle Applications installation has a base language and can have additional installed languages. Multiple Language Support (MLS) enables you to create configuration models and one or more user interfaces in your base language, and then display the Model in any language in which you do business. For a list of all languages that Oracle Applications supports, see the Oracle 8i National Language Support Guide. Descriptions for BOM items are entered in Oracle Applications. You enter descriptions for nodes created in Configurator Developer using PL/SQL or a custom translation facility. See Section 3.3.3, "Modify Description Translation Supported by MLS" on page 3-17 for sample PL/SQL translations. When publishing the Model and UI, you specify in which languages the publication is available using the Language applicability parameter. All language translations defined for the model are exported when you create the publication. When the publication is accessed at runtime, the language specified by the host application determines which language to display in the UI. See the Oracle Configurator Developer User’s Guide for more information about publishing and MLS.
1-14 Oracle Configurator Implementation Guide Implementation Tasks
1.8.1.1 Precedence of Language Settings When determining which language to display in the Configurator window, the runtime Oracle Configurator searches the following sources, in this order: 1. The language parameter in the initialization message. (See the Oracle Configurator Custom Web Deployment Guide for additional information.) This parameter overrides other language specifications, but is optional, and might not be present. 2. The Language property of the AppsContext object. This property’s value is derived from the settings in the ICX Session Ticket. If no ICX Session Ticket is found, then the default language associated with the AppsContext object is used. 3. The base language of the Oracle Applications database.
1.8.1.2 Installed Languages If you are working in two server environments (such as "development" and "production"), the base language and the set of installed languages on both Oracle Applications servers must be exactly the same.
1.9 Implementation Tasks In order to support any Oracle Configurator environment, you must perform implementation tasks mentioned in Section 1.9.1, "Commonly Performed Implementation Tasks" on page 1-16. Figure 1–4, "Implementation Task Flow" shows the task flow. 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.9.4, "Creating a Custom Import" on page 4-33 for more information about custom import.
Introduction 1-15 Implementation Tasks
Figure 1–4 Implementation Task Flow
1.9.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 runtime Oracle Configurator. Instructions for some frequently performed tasks are included in the following sections:
■ Server Administration on page 1-17
■ View the Status of Oracle Configurator Concurrent Programs Requests on page 1-21
■ Query Registered Oracle Configurator Concurrent Programs on page 1-22
■ Connect to a Database Instance on page 1-22
■ Verify Oracle Configurator Schema Version on page 1-23
■ Checking BOM and Model Similarity on page 1-24
1-16 Oracle Configurator Implementation Guide Implementation Tasks
1.9.1.1 Server Administration Oracle Configurator can operate within a multi-server environment to utilize separate production and development (including testing or maintenance) database instances. These databases are not necessarily separate machines. However, if 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. Only one environment should be enabled for import. See Import/Enabled in Table 1–2, " Oracle Configurator Concurrent Programs for Server Administration" on page 1-18. Oracle Configurator provides the following concurrent programs for server administration:
■ Define Remote Server
■ Enable Remote Server
■ Modify Server Definition
■ View Servers Table 1–2, " Oracle Configurator Concurrent Programs for Server Administration" describes these concurrent programs.
Introduction 1-17 Implementation Tasks
Table 1–2 Oracle Configurator Concurrent Programs for Server Administration Configurator Concurrent Program Description Parameters Define Servers Creates a new remote server Local Name - This resolves a net definition. Run this concurrent service name to a network address. It program if: is stored in the TNSNAMES.ORA file. For example, CZVIS. a model is imported from an instance that is not on the Host Name - TCP host name for this server the user is currently server where the Oracle Configurator logged in to. Only one server schema is found. It can be an IP can be enabled for import at a address or the actual name of the time. server. For example, ctra-sunserver. the instance to which you DB Listener Port - TCP port number publish a BOM - based on which this database server is configuration model is listening for client connections. For different from the instance example, 1523. from which you imported the Instance Name - The name that BOM. The target database identifies a specific instance of the does not have to be enabled, Oracle database. Also known as the but it does have to be defined SID. to be included in the list of values from which you select Oracle Applications Schema - Name the Database Instance of Oracle Applications Schema publication attribute. See (FNDNAM). Section 6.2.1.3, "Database Global Identity (if any) - When the Instance" on page 6-5. database initialization parameter GLOBAL_NAMES is set to true, this field should be set to 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. Description - Any notes you want to make regarding this server. FND Link Name - Name of the remote server link to the Oracle Applications schema. For example, czvis1.world. Import Enabled (Y/N) - Enable or disable import on this server. Only one remote server can be enabled for import at a time.
1-18 Oracle Configurator Implementation Guide Implementation Tasks
Table 1–2 (Cont.) Oracle Configurator Concurrent Programs for Server Configurator Concurrent Program Description Parameters Enable Remote Performs all the operations Server Local Name - Select from the Server needed to enable a remote list of values or enter the name of the server for import. Loads (or server entry to enable. "FOREIGN" links in) the list of remote (-1) and the local server (0) are invalid BOMs into the local instance parameters. for use by the Password - Password for the Oracle Populate/Refresh Applications schema (FNDNAM) on Configuration Models this remote server. concurrent program.
Introduction 1-19 Implementation Tasks
Table 1–2 (Cont.) Oracle Configurator Concurrent Programs for Server Configurator Concurrent Program Description Parameters Modify Server Modifies a remote server Local Name - This resolves a net Definition definition. service name to a network address. It is stored in the TNSNAMES.ORA file. For example, CZVIS. Host Name - TCP host name for this server where the Oracle Configurator schema is found. It can be an IP address or the actual name of the server. For example, ctra-sunserver. 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 set to 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. Description - Any notes you want to make regarding this server. FND Link Name - Name of the remote server link to the Oracle Applications schema. For example, czvis1.world. Import Enabled (Y/N) - Enable or disable import on this server. Only one remote server can be enabled for import at a time. View Servers Writes the server information None. to the concurrent process log.
1-20 Oracle Configurator Implementation Guide Implementation Tasks
1.9.1.1.1 Running Server Administration Concurrent Programs Only users assigned to the Configurator Administrator responsibility can run the Server Administration concurrent programs. Use the following procedure to run the Server Administration concurrent programs: 1. Log into Oracle Applications under the Configurator Administrator responsibility. 2. Select Configurator > Server Administration. 3. Select the concurrent program you want to run from the Server Administration menu. 4. When necessary, a Parameters form appears. Enter the parameters as described in Table 1–2, " Oracle Configurator Concurrent Programs for Server Administration" on page 1-18. 5. Click OK. 6. Click Submit. When you run the View Servers concurrent program, 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 Section 1.9.1.2, "View the Status of Oracle Configurator Concurrent Programs Requests" on page 1-21. 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.9.1.2 View the Status of Oracle Configurator Concurrent Programs Requests Since all reports, programs, and requests are run as concurrent requests in Oracle Applications, use the Requests window to view the status and output of your requests. The Requests window is used 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. Navigate to the Oracle Applications Requests window using the Navigator window. Different Oracle Applications products use different menu paths in the
Introduction 1-21 Implementation Tasks
Navigator window to access the Requests windows. To access the Requests window through the Configurator responsibilities: 1. Log into Oracle Applications under the Configurator responsibility to which you are assigned; Configurator Administrator or Configurator Developer. 2. Select Configurator > Requests. 3. The Find Requests form displays. 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. 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 all concurrent requests for the current responsibility in addition to the current user’s requests.
1.9.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. Use the following procedure to query the registered Oracle Configurator concurrent programs: 1. Switch to the System Administrator responsibility. 2. Navigate to Concurrent > Programs > Define. 3. From the View pull-down menu choose Query By Example > Enter. 4. The Concurrent Programs form displays. Enter CZ% in the Short Name field. 5. From the View pull-down menu choose Query By Example > Run. 6. The Concurrent Programs form displays the registered Oracle Configurator current programs. Use the arrow keys to scroll through the Configurator concurrent programs.
1.9.1.4 Connect to a Database Instance Certain implementation tasks must be performed while connected to a specific database instance.
1-22 Oracle Configurator Implementation Guide Implementation Tasks
To connect to a specific database, you must specify a user or schema and the instance in which it is defined. For example: 1. Connect to your Oracle Configurator schema by connecting to the instance appssid as a user of the schema you need to access. Example:
SQL> connect oc/ocpass@appssid
where oc is the owner (DBOwner) of the Oracle Configurator schema, ocpass is the owner’s password, and appssid is the name for the Oracle8i Enterprise Edition instance on which the Oracle Configurator schema is installed.
Alternatively, connect to the database instance as a user with DBA privileges: Example:
SQL> connect dba/dbapass@appssid
1. Connect to the appssid instance as the integration user. Example: SQL> conn imp imppass@appssid
1.9.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"
The result for this Release 11i should be MAJOR_VERSION = 17, MINOR_ VERSION = c. These values will vary depending on the latest installed version. To determine which version of Oracle Configurator Developer goes with which version of Configurator, refer to note #131088.1 on http://metalink.oracle.com/
Introduction 1-23 Implementation Tasks
1.9.1.6 Checking BOM and Model Similarity The BOM imported into a configuration model is a mirror of the source BOM that participates in Oracle Applications processes such as ordering. For configurations against a particular BOM to be orderable, the BOM in the CZ schema must match exactly the BOM in Bills of Materials. The same BOM in Bills of Material on two different database instances may result in different ORIG_SYS_REF identification in the configuration model. ORIGI_SYS_REF uniquely identifies a BOM. So if the instance from which the BOM was imported into the CZ schema is replaced with a new instance containing the same BOM, the ORIG_SYS_REF identification will most likely no longer match the source BOM. Likewise, if the configuration model is being published to an instance that did not serve as the import server, the ORIG_ SYS_REF identification will not necessarily match the source BOM. The difference in ORIG_SYS_REF identification prevents a BOM-based configuration model from being synchronized with its source BOM during re-import, refresh, or Model publication. Attempting to synchronize mismatched BOMs results in errors. The two concurrent programs available for checking if the mirror BOM in the CZ schema matches the source BOM are Check Model/Bill Similarity on page 1-27 and Check All Models/Bill Similarity on page 1-27. You might run either Check Model/Bill Similarity or Check All Models/Bill Similarity if:
■ You changed the import server from which you are importing or refreshing the BOMs into the CZ schema
■ You are publishing BOM-based configuration models to a target database instance that is different from the one used as the source import server Check Model/Bill Similarity and Check All Models/Bill Similarity concurrent programs return a report detailing the fields that are not in synch. See Model/Bill Similarity Check Report on page 1-27 for details.
1.9.1.6.1 Validation Criteria The validation criteria for a BOM-based configuration model to be similar and synchronizable with the source BOM are as follows:
■ Both structures use the same Inventory items. For example: The bill’s item identity is identified by the concatenated values of segments 1 through 20 in MTL_SYSTEM_ITEMS of the corresponding item. CZ_PS_NODES are identified by the corresponding value of CZ_ITEM_MASTERS.REF_PART_ NBR.
1-24 Oracle Configurator Implementation Guide Implementation Tasks
■ Parent-child relationships are the same. For example, each imported parent node has the same imported children items as in the BOM structure. The order of the children may be different.
■ Certain Item characteristics are the same. For example, ’Required when parent is selected’ Property, or minimum/maximum default quantities.
■ A child’s effectivity range does not fall outside the effectivity range of its parent.
■ If there is only one child node with the given identity (INVENTORY_ITEM_ ID) then its disable date (effective to date) should be the same as the parent node and the effective dates (effective from date) should either be before SYSDATE or the same for the child node and the parent.
■ If there is more than one child node with the given identity (INVENTORY_ ITEM_ID), then the previous scenario is only valid for the child node that has the earliest effective date. For the other child nodes the ranges should be exactly the same. Table 1–3, " Fields Synchronized for Import" lists the fields that must be synchronized for import. For publication, all but CZ_LOCALIZED_TEXTS and CZ_ XFR_PROJECT_BILLS must be synchronized.
Table 1–3 Fields Synchronized for Import Table Field CZ_DEVL_PROJECTS ORIG_SYS_REF includes back pointers to EXPLOSION_ TYPE:ORGANIZATION_ID:TOP_ITEM_ID CZ_ITEM_MASTERS ORIG_SYS_REF includes back pointers to INVENTORY_ ITEM_ID:ORGANIZATION_ID CZ_ITEM_TYPES ORIG_SYS_REF includes back pointers to ITEM_CATALOG_ GROUP_ID CZ_LOCALIZED_TEXTS ORIG_SYS_REF includes back pointers to COMPONENT_ ITEM_ID:EXPLOSION_TYPE:ORGANIZATION_ID CZ_MODEL_ PRODUCT_KEY includes back pointers to ORGANIZATION_ PUBLICATIONS ID:TOP_ITEM_ID ORGANIZATION_ID TOP_ITEM_ID CZ_PS_NODES ORIG_SYS_REF includes back pointers to COMPONENT_ CODE:EXPLOSION_TYPE:ORGANIZATION_ID:TOP_ITEM_ ID
Introduction 1-25 Implementation Tasks
Table 1–3 (Cont.) Fields Synchronized for Import Table Field COMPONENT_SEQUENCE_PATH COMPONENT_SEQUENCE_ID CZ_XFR_PROJECT_BILLS ORGANIZATION_ID TOP_ITEM_ID COMPONENT_ITEM_ID SOURCE_SERVER
Mapping of Organizations is done by matching ORG_ORGANIZATION_ DEFINITIONS.ORGANIZATION_CODE. If the matching Organization is not found on the production instance, then an error occurs. Since CZ_ITEM_TYPE_PROPERTIES and CZ_ITEM_PROPERTY_VALUES do not have the ORIG_SYS_REF field, there is no way to verify that the imported Properties and Property values correspond to the Descriptive Elements and their values on the target instance. Runtime Models use the imported Property values. You must verify that the Descriptive Elements and their values are the same on both the development and production instances.
Note: It is important that the Item Flexfield structure and the concatenation characters for the Item Flexfield be the same on all database instances and should not be updated.
Once you determine that the source BOM and the BOM-based configuration model are similar, you can proceed with either synchronizing the BOM in the configuration model for reimport or refresh, or publishing the configuration model. Running the publication concurrent programs includes synchronization. For details, see Section 4.6.1.5, "Running the Synchronize All Models Concurrent Program" on page 4-22 and Section 6.4, "Creating the Publication" on page 6-11. Synchronization causes the BOM-based configuration model in the CZ schema to be modified to match the source BOM. Synchronization checks the models that are candidates for synchronization but results in an error if a model does not have an EXPLOSION_TYPE of OPTIONAL. See Table 4–4, " Fields in CZ_XFR_PROJECT_ BILLS" for more information about EXPLOSION_TYPE setting. Synchronization does not check the mandatory fields.
1-26 Oracle Configurator Implementation Guide Implementation Tasks
1.9.1.6.2 Check Model/Bill Similarity This concurrent program is available to both the Configurator Administrator and the Configurator Developer responsibilities. The input parameters are:
■ Target Instance: This is a list of available instances, as defined by the Define Remote Server concurrent program. Select the instance that contains the source BOM with which the configuration model needs to be synchronized.
■ Folder: This is a list of directories (folders) on the current instance. Select the folder that contains the Model to be checked against the BOM in the Target Instance.
■ List of Models: This is a list of all Models in the specified folder on the current instance. A single Model is selected. If all Models are to be checked, see Section 1.9.1.6.3, "Check All Models/Bill Similarity" on page 1-27.
1.9.1.6.3 Check All Models/Bill Similarity This concurrent program is available to both the Configurator Administrator and the Configurator Developer responsibilities. All imported models in the CZ schema of the current instance are compared with the structures of the bills on a target instance. See Section 1.9.1.6.1, "Validation Criteria" on page 1-24 for validation criteria. The input parameter is:
■ Target Instance: This is a list of available instances, as defined by the Define Remote Server concurrent program. Select the instance that contains the source BOMs with which the configuration models need to be synchronized.
■ A report is generated with the results. See Section 1.9.1.6.4, "Model/Bill Similarity Check Report" on page 1-27
1.9.1.6.4 Model/Bill Similarity Check Report This report is generated every time you run the Check Model/Bill Similarity, Check All Model/Bill Similarity and Synchronize All Models concurrent programs. The report is displayed in a standard report log file generated by concurrent programs. For detailed information on concurrent processing reporting options, see the Oracle Application’s User’s Guide. This report contains a comprehensive message describing the list of problems that were encountered. The list starts with a message providing the version of the package and the run time. For example, the following error message occurs when the BOM does not exist on the target server: BOM Synchronization, version 115.15, started 2001/10/23/14:05:16, session run
Introduction 1-27 Implementation Tasks
ID: 12017 There is no root bill for configuration model Name of the Model, unable to verify the model."
The following error message occurs when there is a discrepancy with an Inventory item. BOM Synchronization, version 115.15, started 2001/10/29/14:05:16, session run ID: 12018 'PTO_OC1' with parent 'BOM_SYNCH' in configuration model 'BOM_SYNCH' cannot be matched with any inventory item.
1-28 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 runtime Oracle Configurator using Oracle Configurator Developer. 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. To restore the edits you made to spx.ini, examine the new spx.ini file and copy any new entries in this file to the existing spx_ini.bak back to spx.ini as new functionality may have been introduced. See Section 2.1, "Parameters in spx.ini" on page 2-3 for details about specific parameters. Example 2–1 is the spx.ini file that is installed with Oracle Configurator.
Example 2–1 Default Installed spx.ini [Merlin] ;In order to use Developer please uncomment (i.e. remove the ’;’) from ;the sample lines for each odbc dsn and replace each word ;
[DSN] ;
;[odbc-dsn-1]
The spx.ini File 2-1 ;DBOwner=
[odbc-dsn-2] ;DBOwner=
[Design Chart] DEF=M SEC=X
Example 2–2 shows a modified spx.ini file. The czprd instance uses the [Merlin] default values for InitServletURL and InitCodeBaseUrl as those values are not specified in the [dsn]. Similarly, czapp instance uses the [Merlin] default values for Launch, InitServletURL and InitCodeBaseUrl.See Section 2.1.1, "[Merlin]" on page 2-4 for more information.
Example 2–2 Modified spx.ini File [Merlin] DBOwner=apps JdbcUrl=jdbc:oracle:thin:@ctra-sunserver:1523:czpro Launch=1
InitServletURL=http://ap882sun.us.oracle.com:10130/servlets/oracle.apps.cz.servl et.UiServlet InitCodeBaseUrl=http://app882sun.us.oracle.com:10140/applet
[DSN] czviseng czvisprd czvisdev
[czviseng] DBOwner=apps JdbcUrl=jdbc:oracle:thin:@ap320sun:1623:czviseng gwyuid=APPLSYSPUB gwypass=PUB APPLID=660
2-2 Oracle Configurator Implementation Guide Parameters in spx.ini
RESPID=21623 Launch=1
[czvisprd] DBOwner=apps JdbcUrl=jdbc:oracle:thin:@ap320sun:1623:czvisprd gwyuid=APPLSYSPUB gwypass=PUB APPLID=660 RESPID=21623
[czvisdev] DBOwner=apps JdbcUrl=jdbc:oracle:thin:@ap320sun:1623:czvisdev gwyuid=APPLSYSPUB gwypass=PUB APPLID=660 RESPID=21623 Launch=2 InitServletURL=http://ap882sun.us.oracle.com:10130/servlets/oracle.apps.cz.servl et.UiServlet InitCodeBaseUrl=http://app882sun.us.oracle.com:10140/applet
[Design Chart] DEF=M, N, A, T SEC=X, Y, Z
2.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 runtime Oracle Configurator from within Oracle Configurator Developer Throughout this section, references to the test configurator mean test instances of a runtime Oracle Configurator launched from Oracle Configurator Developer by clicking the Test button.
The spx.ini File 2-3 Parameters in spx.ini
2.1.1 [Merlin] This section lists default DBOwner and JdbcUrl parameters for Oracle Configurator Developer. When a required parameter is missing in the [dsn], then the value found in [Merlin] is used.
DBOwner in [Merlin] The parameter DBOwner 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 DBOwner in [dsn] on page 2-6 for an example of the usage of the gwyuid and gwypass parameters.
JdbcUrl in [Merlin] The JdbcUrl entry in this section indicates the default JDBC connection URL that is used when testing a DHTML user interface in Oracle Configurator Developer. If the database instance does not specify a JdbcUrl, then the value in [Merlin] will be used.
2.1.2 [DSN] This section lists the Data Source Names (DSN) of the Oracle Configurator schemas available to Oracle Configurator Developer. The DSN of the Oracle Configurator schema used with Oracle Configurator Developer must be listed here. 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.1.3, "[odbc-dsn]" on page 2-5). 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.
2-4 Oracle Configurator Implementation Guide Parameters in spx.ini
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. See the Oracle Configurator Installation Guide for information about creating DSNs and database connectivity. Figure 2–1, "OCD Logon Screen" shows the DSN entries found in a spx.ini file.
Figure 2–1 OCD Logon Screen
You must also edit the spx.ini file and add entries for each of the DSNs available to an instance of the test configurator and DBOwner. The DSNs listed in Example 2–2 on page 2-2 are examples of those installed as part of the Oracle Configurator installation. (See Section 2.1.2, "[DSN]" on page 2-4.) Additional parameters may be defined specifically for manipulating the behavior of the test configurator instance.
2.1.3 [odbc-dsn] This is a discrete [dsn] section to an Oracle Configurator schema instance. The settings in this section override the default settings in [Merlin]. This instance must also be specified in the [DSN] section.
The spx.ini File 2-5 Parameters in spx.ini
DBOwner in [dsn] Each discrete DSN section specifies the DBOwner by which the Oracle Configurator schema associated with the DSN will be accessed. [dsn1] DBOwner=DBOwner JdbcUrl=Jdbc_connection gwyuid=gateway_user_id gwypass=gateway_password applid=application_id respid=responsibility_id
JdbcUrl in [dsn] Each discrete dsn section indicates how the runtime Oracle Configurator should connect to the database. If you are using only Dynamic HTML in a browser 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. If you are using DHTML and this value is not specified in the [dsn] section, there is no entry in the Test dialog box in Oracle Configurator Developer, then the JdbcUrl value in [Merlin] is used.
Gwyuid and Gwypass in [DSN] Oracle Configurator uses Oracle Applications FND authentication for user authentication for Oracle Configurator Developer and the runtime 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 gwypass should be the same as the default username and password in your Oracle Applications environment file. The DHTMLTest and JavaTest sections in Example 2–2 on page 2-2 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
2-6 Oracle Configurator Implementation Guide Parameters in spx.ini
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 database session initialization message. 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_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 for information about the dbc file. See the Oracle Configurator Custom Web Deployment Guide for information about the initialization message.
Launch This parameter determines the type of runtime environment to launch when using the Test button in OCD. Launch=1 specifies Dynamic HTML in a browser. When Launch=1 is specified, the parameter InitServletURL must also be set to specify the URL of the servlet generating the Dynamic HTML in a browser. Launch=2 specifies Java Applet. When using the Java Applet, the parameter InitServletURL must be set to specify the URL of the servlet generating the Java Applet. Additionally, when unit testing in Oracle Configurator Developer using the Java Applet, the InitCodeBaseURL parameter must be set to specify the URL of the location of the class or Java archive (.jar) files for the Java Applet. For example: InitCodeBaseUrl=http://app882sun.us.oracle.com:10140/applet
Note: The InitCodeBaseUrl is used only when unit testing a Model and UI in a Java applet using the Test button in Configurator Developer.
You can also specify the test environment in the Options window in Oracle Configurator Developer. Changes you make to the InitServletURL or
The spx.ini File 2-7 Parameters in spx.ini
InitCodeBaseURL in the Options window are automatically updated in the spx.ini file. For any Oracle Configurator Developer session, the setting in the Options window is stored in memory and used when launching the test Configurator. If you manually edit the spx.ini file, the change does not take affect until you restart Configurator Developer. For more information about the Options window, see the Oracle Configurator Developer User’s Guide.
2.1.4 [Design Chart] This section sets the alpha symbols used to indicate defining (DEF=) and secondary (SEC=) Optional Features in Oracle Configurator Developer Design Chart configuration rules. As Example 2–2 on page 2-2 shows, you can assign multiple symbols if you use multiple defining and secondary Features in a Design Chart rule. However, the defining (DEF=) set of symbols must be completely different than the secondary (SEC=) symbols.
2.1.5 Data Source-Specific Test Sessions If you wish, you can set separate testing parameters for each data source used by Oracle Configurator Developer. These parameters are set in a [dsn} section of the spx.ini file. The values for the following parameters can be different for each data source: Launch InitServletURL InitCodeBaseURL jinitVersion jinitClassID
Syntax: [odbc_dsn] DbOwner=db_owner JdbcUrl=jdbc:oracle:thin:@db_host:db_port:sid Launch=option InitServletURL=http://web_ host:port/configurator/oracle.apps.cz.servlet.UiServlet jinitVersion=version jinitClassID = clsid_of_jinitiator
If you are using Microsoft Internet Explorer when unit testing a configuration model in Oracle Configurator Developer, you must specify the both the version and
2-8 Oracle Configurator Implementation Guide Parameters in spx.ini
class ID of JInitiator in your spx.ini file, using the jinitVersion and jinitClassID parameters. For example: [dsn1] ... jinitVersion=1.1.8.7 jinitClassID = clsid:ff348b6e-fd21-11d4-a3f0-00c04fa32518
If you omit a value for jinitClassID from the spx.ini file, Oracle Configurator Developer assumes that you are using version 1.1.8.7 of JInitiator (required by Oracle Applications), and uses a hardcoded class ID which specifies this version.
Note: It is recommended the user specify the value found in the jinit-version.txt on their client machine.
You can determine the version number and class ID of your installed version of JInitiator by examining the file jinit-version.txt in the doc subfolder of your JInitiator installation folder (for example, C:\Program Files\Oracle\JInitiator 1.1.8.7\doc\jinit-version.txt). When you upgrade, you can use your existing spx.ini file. If you use the Tools > Options > Test dialog in Oracle Configurator Developer to change any test options, then your spx.ini file is rewritten to place the test parameters in the section for the data source that you logged in to.
Example Here are some sections of spx.ini before you log in: [sid01] DbOwner=apps JdbcUrl=jdbc:oracle:thin:@db01:1521:sid01
[sid02] DbOwner=apps JdbcUrl=jdbc:oracle:thin:@db04:1521:sid02
[sid03] Launch=1 InitServletURL=http://webhost05:8010/configurator/oracle.apps.cz.servlet.UiServl et jinitVersion=1.1.8.7 jinitClassID = clsid:ff348b6e-fd21-11d4-a3f0-00c04fa32518
The spx.ini File 2-9 Parameters in spx.ini
Here are the same sections of spx.ini after you log in to the data source sid01 and change the web_host specified in the InitServletURL parameter: [sid01] DbOwner=apps JdbcUrl=jdbc:oracle:thin:@db01:1521:sid01 Launch=1 InitServletURL=http://webhost12:4199/configurator/oracle.apps.cz.servlet.UiServl et jinitVersion=1.1.8.7 jinitClassID = clsid:ff348b6e-fd21-11d4-a3f0-00c04fa32518
[sid02] DbOwner=apps JdbcUrl=jdbc:oracle:thin:@db04:1521:sid02
[sid03] Launch=1 InitServletURL=http://webhost05:8010/configurator/oracle.apps.cz.servlet.UiServl et jinitVersion=1.1.8.7 jinitClassID = clsid:ff348b6e-fd21-11d4-a3f0-00c04fa32518
2.1.6 Parameterized Startup of Oracle Configurator Developer You can start up Oracle Configurator Developer with predefined parameters. This enables you to provide preset values for the mandatory login parameters (user, password, data source name), and bypass the OCD login screen where you normally enter them. You can also control logging with a parameter. For more information, see the Oracle Configurator Installation Guide.
2-10 Oracle Configurator Implementation Guide 3 The Oracle Configurator Schema
Runtime Oracle Configurators use a standard schema for storing configuration data. This schema is referred to as the Oracle Configurator schema (CZ tables) in the Oracle Applications database. The Oracle Configurator schema is used to store all information related 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, such as Oracle Inventory. 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 runtime 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: ADMN - Administrative CNFG - Configuration GN - General Use tables ITEM - Item-Master
The Oracle Configurator Schema 3-1 Characteristics of the Oracle Configurator Schema
LCE - Logic for Configuration (Active Model) PB - Publication PROJ - Project Structure RP - Repository RULE - Rule UI - User Interface XFR - Transfer specifications and control
The following sections list the tables in each subschema. For detailed information about these and other tables, see the eTRM on Metalink, Oracle’s Customer Support Web site: http://metalink.oracle.com
3.1.1 ADMN Administrative Tables CZ_DB_LOGS CZ_DB_SETTINGS
3.1.2 CNFG Configuration Tables CZ_ATP_REQUESTS CZ_CONFIG_ATTRIBUTES CZ_CONFIG_DETAILS_V CZ_CONFIG_HDRS CZ_CONFIG_INPUTS CZ_CONFIG_ITEMS CZ_CONFIG_MESSAGES CZ_PRICING_STRUCTURES CZ_TERMINATE_MSGS CZ_TERMINATE_MSGS_V
3.1.3 ITEM Item-Master Tables CZ_IMP_ITEM_MASTER CZ_IMP_ITEM_PROPERTY_VALUE CZ_IMP_ITEM_TYPE CZ_IMP_ITEM_TYPE_PROPERTY CZ_IMP_PROPERTY CZ_ITEM_MASTERS CZ_ITEM_PROPERTY_VALUES CZ_ITEM_TYPES
3-2 Oracle Configurator Implementation Guide Characteristics of the Oracle Configurator Schema
CZ_ITEM_TYPE_PROPERTIES CZ_PROPERTIES
3.1.4 LCE Logic for Configuration Tables CZ_LCE_HEADERS CZ_LCE_TEXTS
3.1.5 PB Publication Tables CZ_EFFECTIVITY_SETS CZ_EXT_APPLICATIONS_V CZ_MODEL_APPLICABILITIES_V CZ_MODEL_PUBLICATIONS CZ_MODEL_USAGES CZ_PB_CLIENT_APPS CZ_PB_LANGUAGES CZ_PB_MODEL_EXPORTS CZ_PUBLICATION_USAGES
3.1.6 PROJ Project Structure Tables CZ_DEVL_PROJECTS CZ_IMP_DEVL_PROJECTS CZ_IMP_MODEL_REF_EXPLS CZ_IMP_PS_NODES CZ_MODEL_REF_EXPLS CZ_POPULATORS CZ_PS_NODES CZ_PS_PROP_VALS
3.1.7 RULE Rule Tables CZ_COMBO_FEATURES CZ_DES_CHART_CELLS CZ_DES_CHART_COLUMNS CZ_DES_CHART_FEATURES CZ_EXPRESSIONS CZ_EXPRESSION_NODES CZ_FILTER_SETS CZ_FUNC_COMP_SPECS
The Oracle Configurator Schema 3-3 Characteristics of the Oracle Configurator Schema
CZ_GRID_CELLS CZ_GRID_COLS CZ_GRID_DEFS CZ_RULES CZ_RULE_FOLDERS
3.1.8 RP Repository Tables CZ_REPOS_TREE_V CZ_RP_DIRECTORY_V CZ_RP_ENTRIES CZ_SERVERS
3.1.9 UI User Interface Tables CZ_IMP_INTL_TEXT CZ_IMP_LOCALIZED_TEXTS CZ_INTL_TEXTS CZ_LOCALIZED_TEXTS CZ_LOCALIZED_TEXTS_VL CZ_UI_DEFS CZ_UI_NODES CZ_UI_NODE_PROPS CZ_UI_PROPERTIES
3.1.10 XFR Transfer Specifications and Control Tables CZ_XFR_FIELDS CZ_XFR_PROJECT_BILLS CZ_XFR_RUN_INFOS CZ_XFR_RUN_RESULTS CZ_XFR_STATUS_CODES CZ_XFR_TABLES
3.1.11 Obsolete Tables or Relevant to Oracle SellingPoint Oracle discourages customization because of the potential for problems upgrading to future releases. .
3.1.11.1 Obsolete Tables CZ_IMP_INTL_TEXT
3-4 Oracle Configurator Implementation Guide Characteristics of the Oracle Configurator Schema
CZ_LCE_OPERANDS CZ_MODELS_V CZ_POPULATOR_MAPS CZ_PSNODE_PROPCOMPAT_GENS
3.1.11.2 Tables currently not used CZ_FUNC_COMP_REFS CZ_CONFIG_USAGES CZ_IMP_ITEM_PARENT CZ_ITEM_PARENTS CZ_LOCALES CZ_REL_TYPES CZ_SUB_CON_SETS CZ_XFR_FIELD_REQUIRES
3.1.11.3 Oracle SellingPoing tables CZ_ADDRESS_USES CZ_ADDRESSES CZ_CONTACTS CZ_CUSTOMER_END_USERS CZ_CUSTOMERS CZ_DRILL_DOWN_ITEMS CZ_DEVL_PRJ_USER_GROUPS CZ_END_USER_GROUPS CZ_END_USERS CZ_EXP_TMP_LINES CZ_IMP_ADDRESS CZ_IMP_ADDRESS_USE CZ_IMP_CONTACT CZ_IMP_CUSTOMER CZ_IMP_CUSTOMER_END_USER CZ_IMP_END_USER CZ_IMP_END_USER_GROUP CZ_IMP_PRICE CZ_IMP_PRICE_GROUP CZ_IMP_USER_GROUP CZ_OPP_HDR_CONTACTS CZ_OPPORTUNITY_HDRS CZ_PRICE_GROUPS CZ_PRICES
The Oracle Configurator Schema 3-5 Oracle Configurator Schema Settings
CZ_PROP_QUOTE_HDRS CZ_PROPOSAL_HDRS CZ_QUOTE_HDRS CZ_QUOTE_MAIN_ITEMS CZ_QUOTE_ORDERS CZ_QUOTE_SPARES CZ_QUOTE_SPECIAL_ITEMS CZ_SPARES_SPECIALS CZ_USER_GROUPS CZ_XFR_PRICE_LISTS
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 the Modify Configurator Parameters concurrent program, 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 LogicGen UISERVER
All CZ_DB_SETTINGS values are stored as VARCHAR2(255) in the VALUE field. The DATA_TYPE field stores the datatype of the setting. For example, the Batchsize setting default value is stored as 1000, but its DATA_TYPE is integer. The configurator code converts the string to an integer value before using it. Table 3–1, " CZ_DB_SETTINGS" 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-6 Oracle Configurator Implementation Guide Oracle Configurator Schema Settings
Table 3–1 CZ_DB_SETTINGS SECTION_ Default SETTING_ID NAME DATA_TYPE Value Relevance and Contribution AltBatchValidateURL ORAAPPS_ string Null Allows the batch validation INTEGRATE process to bypass the URL that would normally be used for batch validation. This is needed if Oracle Configurator uses SSL. The value must be the non-secure URL. Note: This field must be populated by the user as there is no seeded data. APPS_PREFER_UI_0 ORAAPPS_ string Null This is a comma delimited list of INTEGRATE applications which prefer to invoke a Configurator DHTML (components tree) User Interface. APPS_PREFER_UI_3 ORAAPPS_ string Null This is a comma delimited list of INTEGRATE applications which prefer to invoke a Configurator Applet (model tree) User Interface. 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" on page 3-14 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.
The Oracle Configurator Schema 3-7 Oracle Configurator Schema Settings
Table 3–1 (Cont.) CZ_DB_SETTINGS SECTION_ Default SETTING_ID NAME DATA_TYPE Value Relevance and Contribution BOM_REVISION ORAAPPS_ string Null Indicates the BOM revision in the INTEGRATE Oracle Applications database from which data is being imported into the CZ schema.The revision value upto the second decimal point is checked. If this value is 11.5., then the 11i date format is used. Otherwise, the older format is is used. CommitSize IMPORT integer 500 Indicates the number of import records in each database transaction at a time, between commits. FREEZE_REVISION SCHEMA string Revision number at the "freeze" stage. Version of the driver file used for the schema upgrade. GenerateGatedCombo LogicGen string YES Deternunes how a FALSE setting is propagated in Explicit Compatibility, Property-based Compatibility and Design Chart Rules. See the Oracle Configurator Developer User’s Guide for additional information. MAJOR_VERSION SCHEMA integer System Indicates the major version label setting for the Oracle Configurator schema. MaximumErrors IMPORT integer 10000 Default error limit for import runs before terminating the import. MINOR_VERSION SCHEMA string System Indicates the minor version label setting for the Oracle Configurator schema.
3-8 Oracle Configurator Implementation Guide Oracle Configurator Schema Settings
Table 3–1 (Cont.) CZ_DB_SETTINGS SECTION_ Default SETTING_ID NAME DATA_TYPE 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. PsNodeName ORAAPPS_ RefPartNbr Null Indicates the source field to be INTEGRATE loaded into the Name field in the CZ_PS_NODES table. This is either the RefPartNbr or Description field in the MTL_ SYSTEM_ITEMS table. PublicationLogging ORAAPPS_ YES/NO NO If set to YES, a trace of the INTEGRATE model(s) copied during publishing is logged into CZ_DB_ LOGS. The trace is helpful for debugging purposes. PublishingCopyRules ORAAPPS_ YES/NO YES If set to NO, the rule subschema of INTEGRATE the Model being published is not copied. RefPartNbr ORAAPPS_ Segment1, or CONCATEN Identifies the field to be used for INTEGRATE concatenated ATED_ the name of an imported item in segments SEGMENTS the CZ_ITEM_MASTERS and CZ_ DEVL_PROJECTS tables. This is a segment from the System Item flexfield.
The Oracle Configurator Schema 3-9 Oracle Configurator Schema Settings
Table 3–1 (Cont.) CZ_DB_SETTINGS SECTION_ Default SETTING_ID NAME DATA_TYPE Value Relevance and Contribution ResolvePropertyDataType ORAAPPS_ YES/NO YES Indicates whether Catalog INTEGRATE Descriptive Elements are imported as Properties with a string or a number data type. If the value for this setting is NO, all Catalog Descriptive Elements are imported as Properties with a string data type. If the value of this setting is YES, a Catalog Descriptive Element is imported as a Property with a number data type only if all of its imported values can be interpreted as numbers; otherwise it is imported as a Property with a string data type. Revision Date/User SCHEMA any string This is read-only and documents the date and time at which the Configurator schema was last upgraded, and the username of the user that performed the task.
3-10 Oracle Configurator Implementation Guide Oracle Configurator Schema Settings
Table 3–1 (Cont.) CZ_DB_SETTINGS SECTION_ Default SETTING_ID NAME DATA_TYPE Value Relevance and Contribution RUN_BILL_EXPLODER ORAAPPS_ YES/NO YES Indicates whether or not the INTEGRATE import process invokes the BOM_ EXPLODER procedure. This explodes the BOMs before the import process extracts data. Note: BOMs are never exploded when importing from a remote server. SuppressSuccessMessage UISERVER YES/NO NO This setting determines whether a message is displayed after fixing a validation error. NO - After fixing a validation error a meaningful success message is displayed. YES - After fixing a validation error a success message is not displayed. Note: This field must be populated by the user as there is no seeded data. UI_NODE_NAME_ ORAAPPS_ string , Sets the concatenation character CONCAT_CHARS INTEGRATE that is used when generating UI captions using both the node name and description. The default concatenation separating each text string is a comma surrounded by two spaces. (For example: "AT62431 , Sentinal Custom Laptop"). You can change the character Configurator Developer uses to separate each string by running the Modify Configurator Parameters concurrent process. The comma is the default setting as stated here.
The Oracle Configurator Schema 3-11 Oracle Configurator Schema Settings
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 fails 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 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. This is the 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 setting means that keys are assigned in increments of 20.
Warning: The value should not be modified.
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.
3-12 Oracle Configurator Implementation Guide Oracle Configurator Schema Settings
BOM_REVISION indicates the version in the Oracle Applications database from which BOM data is being imported. The date format used for Oracle Applications Release 10.7 or 11.0 is "DD/MON/RR". 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=RefPartNbr) 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. RefPartNbr is used by default so that the name loaded into the Model structure in Oracle Configurator Developer matches the names in CZ_ITEM_MASTERS. RefPartNbr is the field name that determines what name is displayed for each imported Model structure node. It indicates the source field to be loaded from the MTL_SYSTEM_ITEMS table into Ref_Part_Nbr in CZ_ITEM_MASTERS in the Oracle Configurator schema. The default value for RefPartNbr in CZ_DB_ SETTINGS is ’CONCATENATED_SEGMENTS’. This setting enables the BOM import process to construct BOM node names using multi-segment part numbers. With RefPartNbr set to ’SEGMENT1’, only MTL_SYSTEM_ITEMS.SEGMENT1 is the source of the node names in the imported structure. If you want to use only the first segment of a part number as the node name, the Configurator Administrator must manually set RefPartNbr to ’SEGMENT1’ by running the Modify Configurator Parameters concurrent process. Any value for RefPartNbr other than ’CONCATENATED_SEGMENTS’ or ’SEGMENT1’ causes the import process to retrieve the value of the DESCRIPTION column from MTL_SYSTEM_ITEMS and displays the item description as the node name in Configurator Developer.
Warning: Examine MTL_SYSTEM_ITEMS_VL. CONCATENATED_SEGMENTS to verify that the field is correctly populated. If the field is incorrectly populated, then the entry in Oracle Inventory is wrong. If the entry is correct, check CZ_IMP_ITEM_MASTER.REF_PART_NBR to see that the value is the same as that in MTL_SYSTEM_ITEMS_VL. CONCATENATED_SEGMENTS.
Concatenated segments, including separators, must not be longer than 1000 characters, the limit of the CZ_PS_NODES.NAME field. Any description longer than 1000 characters is truncated. The default separator is a dot (.). Other separators
The Oracle Configurator Schema 3-13 Oracle Configurator Schema Settings
are '|', '-', or a custom value. See the Oracle Inventory User’s Guide for more information about setting up part numbers. When running either the Populate or Refresh Configuration Models concurrent program, you can enter multi-segment items in the From Item and To Item input fields. When entering multi-segment item names, you must include any separators that exist in the item’s part number.
Warning: To update an existing Model in Configurator Developer to use multi- segment part numbers, you must either reimport or refresh the BOM. Confirm that the BOM is getting re-exploded during import. The DB_SETTINGS.RUN_BILL_EXPLODER should be Yes.
ResolvePropertyDataType is a YES/NO flag (default=NO) that indicates whether Catalog Descriptive Elements are imported as Properties with a string or a number data type. If the value for this setting is NO, all Catalog Descriptive Elements are imported as Properties with a string data type. If the value of this setting is YES, a Catalog Descriptive Element is imported as a Property with a number data type only if all of its imported values can be interpreted as numbers, otherwise it is imported as a Property with a string data type. RUN_BILL_EXPLODER is a YES/NO flag (default=YES) 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. See Chapter 4, "Importing Data" for more information on exploding a BOM. The OC concurrent process load bills and items based on top bills listed in the CZ_ XFR_PROJECT_BILLS table in the Oracle Configurator schema. Before extracting, if the 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 process or import scripts transfers 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 importing BOM data into the CZ schema is implemented.
3-14 Oracle Configurator Implementation Guide Oracle Configurator Schema Settings
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. Table 3–2, "Valid Values for the BadItemPropertyValue Setting" lists the valid values for this setting and the disposition:
Table 3–2 Valid Values for the BadItemPropertyValue Setting 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 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 equivalent 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.
The Oracle Configurator Schema 3-15 Editing the CZ_DB_SETTINGS Values
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.9.4.1, "Setup for a Custom Import" on page 4-34 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 is 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. After you enter these parameters, they are automatically added to the Oracle Applications Submit Request form. Table 3–3, "Oracle Configurator Administration Concurrent Programs" describes the Oracle Configurator administrative concurrent programs.
Table 3–3 Oracle Configurator Administration Concurrent Programs Configurator Concurrent Programs Description Parameters Modify Configurator Sets values for the Section Name - From the list of values, select the name of Parameters settings in the CZ_DB_ the section in the Oracle Configurator CZ_DB_SETTINGS SETTINGS table in the table where the setting resides. Oracle Configurator Setting ID - From the list of values, select the setting in the schema. Oracle Configurator CZ_DB_SETTINGS table you want to modify. Data Type - From the list of values, select the data type (1= number or 4= 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-7 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 Parameters specified Oracle the section in the Oracle Configurator cz_db_settings table Configurator schema where the setting resides. settings to the Setting - from the list of values, select the setting in the concurrent process log. Oracle Configurator cz_db_settings table.
3-16 Oracle Configurator Implementation Guide Editing the CZ_DB_SETTINGS Values
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–3, "Oracle Configurator Administration Concurrent Programs" on page 3-16. 4. Click OK.
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 enter 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.9.1.2, "View the Status of Oracle Configurator Concurrent Programs Requests" on page 1-21. 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.3.3 Modify Description Translation Supported by MLS See the Oracle Configurator Developer User’s Guide for MLS information.
The Oracle Configurator Schema 3-17 Editing the CZ_DB_SETTINGS Values
There are several tables that can be used when writing queries to update the descriptions for a specified source language and language. CZ_DEVL_PROJECTS.INTL_TEXT_ID - this is the international text identifier for the specific project CZ_PS_NODES.VIOLATION_TEXT_ID - this is the violation message when a Resource is over consumed CZ_RULES.REASON_ID - this is the violation message for a rule CZ_RULES.UNSATISFIED_MSG_ID - this is the message when the rule is not satisfied CZ_UI_NODES.TOOL_TIP_ID - this is the INTL_TEXT record that holds the text for a 'tool tip' describing the UI component The following sections are suggested PL/SQL queries that can be run to update appropriate nodes with translations.
3.3.3.1 Update the PS Node Description With Translations 1. First determine the development project’s ID: SQL> select devl_project_id, name 2 from cz_devl_projects 3 where name like '%Sen%'
DEVL_PROJECT_ID NAME
2020 Sentinel Custom Desktop (204 137)
2. Using the DEVL_PROJECT_ID in the following query determines whether PS_ NODE_IDs have INTL_TEXT records. If a PS node was created without a description, it would not have an INTL_TEXT_ID. SQL> ps_node_id, name, intl_text_id 2 from cz_ps_nodes 3 where devl_project_id = 2020
PS_NODE_ID NAME INTL_TEXT_ID 2601 Total RAM Available 10781 3960 Software-Web Browser
3-18 Oracle Configurator Implementation Guide Editing the CZ_DB_SETTINGS Values
3. Add a description for Software-Web Browser and then run the query to get the INTL_TEXT_ID. SQL> ps_node_id, name, intl_text_id 2 from cz_ps_nodes 3 where devl_project_id = 2020
PS_NODE_ID NAME INTL_TEXT_ID 2601 Total RAM Available 10781 3960 Software-Web Browser 10959
4. Using the appropriate DEVL_PROJECT_ID, the following query returns those PS_NODES_ID that have INTL_TEXT_IDs, and their descriptions in LOCALIZED_STR. SQL> column name format a20 column localized_str format a40 select a.ps_node_id, a.name, a.intl_text_id, b.source_lang, b.language, b.localized_str from cz_ps_nodes a, cz_localized_texts b where a.intl_text_id = b.intl_text_id and devl_project_id = 2020 order by a.ps_node_id
PS_NODE_ID NAME INTL_TEXT_ID SOUR LANG LOCALIZED_STR 2916 CM56560 10959 US AR Software-Web Browser 2916 CM56560 10959 US F Software-Web Brpwser 2916 CM56560 10959 US US Software-Web Browser 2916 CM56560 10959 US JA Software-Web Browser
5. Use the INTL_TEXT_ID in the following SQL statement to update the description with the French translation. SOURCE_LANG must be updated when translating to establish that the translation has been accomplished SQL> update cz_localized_texts
The Oracle Configurator Schema 3-19 Editing the CZ_DB_SETTINGS Values
set localized_str = 'Logiciel-Web Browser (Description)' source_lang = 'F' where intl_text_id = 10959 and language = ’F’
6. Verify the new French translation and commit: SQL> select intl_text_id, language, localized_str, source_lang from cz_localized_texts where intl_text_id = 10959 commit
INTL_TEXT_ID SOURCE_LANG LANG LOCALIZED_STR 10959 US AR Software-Web Browser 10959 F F Logiciel-Web Browser (Description) 10959 US US Software-Web Browser 10959 US JA Software-Web Browser
3.3.3.2 Updating the UI Node’s Label Text with Translations 1. First you must determine the development project’s ID: SQL> select devl_project_id, name 2 from cz_devl_projects 3 where name like '%Sen%'
DEVL_PROJECT_ID NAME 2020 Sentinel Custom Desktop (204 137)
2. Get the UI_DEF_ID: SQL> select name, ui_def_id from cz_ui_defs where devl_project_id = 2020
UI_DEF_ID NAME 2340 Sentinel Custom Desktop (204 137) User Interface
3-20 Oracle Configurator Implementation Guide Editing the CZ_DB_SETTINGS Values
3. Use the UI_DEF_ID in the following SQL statement to retrieve the UI node’s INTL_TEXT_IDs. SQL> column "UI Node Name" format a25 column localized_str format a40 select a.caption_id "INTL_TEXT_ID", ui_node_id, a.name "UI Node Name", b.source_lang, b.language, b.localized_str from cz_ui_nodes a, cz_localized_texts b where a.caption_id=b.intl_text_id and a.ui_def_id = 2340 and b.localized_str like ’%Web Browser%’
INTL_TEXT_ID UI Node Name ui_node_id SOUR Lang LOCALIZED_STR 11459 Software-Web 68940 US JA Software-Web Browser Browser 11459 Software-Web 68940 US AR Software-Web Browser Browser 11459 Software-Web 68940 US F Software-Web Browser Browser 11459 Software-Web 68940 US US Software-Web Browser Browser 11460 Text - 70300 68942 US JA Software-Web Browser 11460 Text - 70300 68942 US AR Software-Web Browser 11460 Text - 70300 68942 US F Software-Web Browser 11460 Text - 70300 68942 US US Software-Web Browser
4. Use the UI node’s INTL_TEXT_ID in the following SQL statement to update the UI node’s label text with the French translation. SQL> update cz_localized_texts set localized_str = ’Logiciel - Web Browser (Label Text)’, source_lang = ’F’ where intl_text_id in (11460) and language = ’F’
5. Update the CZ_UI_NODES.MODIFIED FLAGS to non-zero value. This ensures that the PS_NODE descriptions do not overwrite the UI node’s label text during refresh.
The Oracle Configurator Schema 3-21 Oracle Configurator Schema Maintenance
SQL> update cz_ui_nodes set modified_flags = 1 where caption_ID = 11460 6. Verify changes and commit. SQL> select a.intl_text_id, b.ui_node_id, b.name "UI Node Name", a.source_ lang, a.language, a.localized_str, b.modified_flags from cz_localized_texts a, cz_ui_nodes b where a.intl_text_id = b.caption_id and a.intl_text_id in (11460)
INTL_TEXT_ UI_NODE_ LOCALIZED_ ID ui_node_id NAME SOUR Lang STR Modifie 11460 68942 Text - US AR Software-Web 70300 Browser 11460 68942 Text - F F Logiciel - Label Text 70300 Web Browser 11460 68942 Text - US US Software-Web 70300 Browser
commit
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 Section 3.4.1, "Refresh or Update the Production Schema" on page 3-22)
■ eliminating unused data (see Section 3.4.2, "Purge Configurator Tables" on page 3-23)
■ restoring sequences from a dump file (see Section 3.4.3, "Redo Sequences" on page 3-24)
■ synchronizing BOM-based configuration models on a server with BOMs on a remote server (see Section 1.9.1.5, "Verify Oracle Configurator Schema Version" on page 1-23)
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,
3-22 Oracle Configurator Implementation Guide Oracle Configurator Schema Maintenance
further imports are performed to refresh the Oracle Configurator schema as Oracle Applications or legacy 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. For additional information about refreshing data in your Oracle Configurator schema, see Section 4.8, "Refresh and Update Imported Data" on page 4-23.
3.4.2 Purge Configurator Tables Oracle Configurator provides the concurrent program, Purge Configurator Tables, which purges all of the Oracle Configurator tables in the CZ schema. When databases get large and performance is affected, the Purge Configurator Tables concurrent program removes all logically-deleted items in the CZ schema. When you run this concurrent program 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 program physically deletes all logically-deleted records in the tables and subschemas. In some cases this program propagates deletions to additional records not marked as deleted, in the same or different tables. For example, the Purge Configurator Tables concurrent program physically deletes children of a logically-deleted PS_NODE record. It also deletes all EXPRESSION_NODE records attached to a deleted EXPRESSION. In other cases, it does not physically delete a logically-deleted record due to a non-deleted reference to that record. For example, a rule referring to a deleted PS_NODE prevents the concurrent process from physically deleting the PS_NODE. Each table has delete-propagation rules describing these characteristics. To run the Purge Configurator Tables concurrent program: 1. Log in to 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. Click Submit
The Oracle Configurator Schema 3-23 Oracle Configurator Schema Maintenance
3.4.3 Redo Sequences When restoring a schema from a dump file, you should refresh the database sequences. REDO_SEQUENCES is invoked by the packages CZ_MANAGER.sql and CZ_subschema_MGR.sql (for example, CZ_PS_MGR.sql). Depending on the arguments you enter, 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 setting in the CZ_DB_SETTINGS table unless you specify a new increment.
3-24 Oracle Configurator Implementation Guide 4 Importing Data
You import data into the Oracle Configurator schema (CZ schema) to:
■ Leverage existing data
■ Use existing data as a baseline to define configuration models in Oracle Configurator Developer
■ Maintain consistency between configuration models and the downstream manufacturing process. For information about setting up "Oracle Configurator Environments", see Section 1.7.1, "Development".
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 runtime Configurator. Only one source at a time is designated as the import server. This server contains the BOMs that are imported into the CZ schema. This is also the server identified when synchronizing Models with BOMs. For details on checking configuration models with BOMs, see Section 1.9.1.6, "Checking BOM and Model Similarity" on page 1-24. You import data from other Oracle Applications (Release 10.7, 11.0, or 11i) schemas into the CZ schema by running a concurrent program in Oracle Applications. The Populate/Refresh Configuration Models concurrent program performs a data extraction into the correct format for transfer, loads the data into the import tables, and populates the online CZ schema with imported data from the import tables.
Importing Data 4-1 Data Import Overview
In other words, copies of BOM and Item Master data are imported into the CZ tables from tables in the Oracle Applications database that are used by the applications that integrate with Oracle Configurator. See Section 4.6, "Data Import Concurrent Program" on page 4-17. 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 program to import the data. See Section 4.9.4, "Creating a Custom Import" on page 4-33 for detailed information. Regardless of which source you use to import data to the CZ schema, you will need to occasionally refresh the schema with changes and updates for enterprise-wide consistency. Configuration models in the runtime Oracle Configurator maintain all relationships associated with the refreshed data to minimize Model maintenance as data is modified. Figure 4–1, "Overview of Data Import" shows how the data import process uses import tables in the CZ schema to populate the online tables with the extracted data used by the runtime Oracle Configurator.
Figure 4–1 Overview of Data Import
The import tables mirror the CZ schema Item Master structure, without integrity constraints. The import tables temporarily store extracted or legacy data which the concurrent programs access to create, update, or delete records in the CZ schema.
4-2 Oracle Configurator Implementation Guide Data Import Overview
Online tables contain the data used by the runtime Oracle Configurator. Every online table that receives imported data is equivalent to an import table. When importing data from a non-Oracle Applications database, the data must be extracted in a ASCII (text) file format and custom loaded into the import tables. See Custom Import in Figure 4–1, "Overview of Data Import" on page 4-2. Exactly what extracted data is imported depends on the settings in the control tables (CZ_XFR_ tables in the CZ schema) or the custom load program, if applicable. The Populate Configuration Models concurrent program is then run to populate the online tables with the extracted data used by the runtime Oracle Configurator. See Section 4.9, "Customizing Data Import" on page 4-31 for information about customizing import. The Oracle Applications concurrent programs do not provide an automated or scheduled mechanism that clears the import tables.
4.1.1 Data Import and Multiple Language Support (MLS) When defining an Item in Oracle Inventory, an Oracle Applications user can enter an alternate description for the Item in each language installed on the system. (You cannot enter translations for Item names in Oracle Applications.) For example, the base language of your Oracle Applications installation is English, but French, Spanish, and German are installed. When creating a new Item, an Oracle Inventory user enters the Item name and description in English, then uses the Translation window to enter alternate descriptions in French, Spanish, and German. (For more information, see Creating Translations for a Record in the Oracle Applications User’s Guide.) All translatable strings for BOMs created in Oracle Applications are available in the MTL_SYSTEM_ITEMS_TL table. When you import a BOM Model into the CZ schema, the Item descriptions are also imported, including the base language and any alternate translations. Before importing a BOM, be sure that all Items defined in Oracle Inventory contain descriptions. If an Item does not have a description, both the name and description columns in the DHTML Summary screen may be blank at runtime. See the Oracle Configurator Installation Guide for information about the MLS Servlet property option to hide the Item name.
Importing Data 4-3 Data Import Overview
Warning: The Populate/Refresh Configuration Models concurrent programs import any new or modified descriptions from Oracle Applications and overwrite any BOM Item descriptions that you may have modified in the CZ schema. Therefore, it is recommended that you enter and modify the translated Item descriptions only in Oracle Inventory.
Import extracts all strings (translated or not) from MTL_SYSTEM_ITEMS_TL for all languages installed on the import target machine. Import populates CZ_ LOCALIZED_TEXTS with MTL_SYSTEM_ITEMS_TL.DESCRIPTION. If you want to publish the UI and display information in all installed languages, you must manually translate the description of each non-BOM node (remember that all translated descriptions are imported with the BOM). You can translate non-BOM descriptions using either SQL*Plus or a translation facility that you create. It is recommended that you review the predefined tooltip text and all Configurator Developer validation, warning, and error messages to ensure that the translated version of each message exists and is correct. Then, modify the information using SQL*Plus or a custom translation facility as required. Tooltip text and any messages created in Configurator Developer are stored in the CZ_LOCALIZED_TEXTS table. All predefined Configurator Developer messages are stored in the FND_NEW_ MESSAGES table. See Section 3.3.3, "Modify Description Translation Supported by MLS" on page 3-17. During the Populate/Refresh Configuration Models concurrent programs, if SOURCE_LANG in the source database is different from LANGUAGE in the source database and if the SOURCE_LANG and LANGUAGE are the same in the target database, then the descriptions are not imported. They are marked as ’Rejected’ with a status of ’R’.
Warning: When importing from a remote server, the list of installed languages on the source database must be the same as the list of installed languages on the target database.
4.1.1.1 New Models When importing a new BOM Model, the Oracle Configurator import procedures import all available translations for each item in the BOM.
4-4 Oracle Configurator Implementation Guide Data Import Overview
4.1.1.2 Existing Models Existing configuration models must be refreshed so that the CZ_LOCALIZED_ TEXTS table is populated with the new or modified translations that have been entered in Oracle Inventory for the BOM Models.
4.1.2 Import Tables The import tables represent a "mirror" of the online tables in the CZ schema Item Master structure, but without integrity constraints. The import tables allow batch population of the CZ schema. Each import table is named exactly as its online counterpart, but is prefixed with CZ_IMP_ rather than simply CZ_. For example, the imported data in CZ_IMP_ PROPERTIES populates CZ_PROPERTIES. In an import table, all fields are nullable and no data constraints are applied to any field. Each import table also contains the same fields that exist in the online table, but contains additional fields used specifically by the import process. Import tables consist of fields for:
■ Import Control
■ Online Data
■ Surrogate Keys
4.1.2.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. Table 4–1, " Import Control Fields" describes the import control fields.
Table 4–1 Import Control Fields Field Name Type Description RUN_ID INTEGER Input field that identifies which import run the 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-5 Data Import Overview
Table 4–1 (Cont.) 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 exists in the online database table. DISPOSITION CHAR(1) Output field that indicates whether the record was inserted, modified, unchanged, or rejected after an import: I = Insert M = Modify N = No change R = Rejected Null indicates not yet known
4.1.2.2 Online Data Fields Online data fields exactly match the fields in the corresponding online table and are used to hold the data to be put into the online table.
4.1.2.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 – These are one or more fields that 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-6 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.3 Control Tables (CZ_XFR_) The import process is controlled by a set of tables with data records that determine what and how data is imported. They also determine which import tables are enabled for import. These tables are prefixed with CZ_XFR There are six tables that control the import process at the table and field level; CZ_ XFR_TABLES, CZ_XFR_FIELDS, CZ_XFR_PROJECT_BILLS, CZ_XFR_RUN_ INFOS, CZ_XFR_RUN_RESULTS, and CZ_XFR_STATUS_CODES. CZ_XFR_ TABLES identifies the import table to online table transfer that is to be performed during import. Table 4–2, " Fields in CZ_XFR_TABLES" describes the fields in the CZ_XFR_ TABLES.
Table 4–2 Fields in CZ_XFR_TABLES Field Name Required Type Description XFR_GROUP YES VARCHAR2 Used to name and group sequences (20) of imports, such as EXTRACT, IMPORT, GENERIC. ORDER_SEQ YES NUMBER(9) Indicates the order in which data from 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 VARCHAR2 Identifies the name of the source (40) table in the import subschema. DST_TABLE NO VARCHAR2 Contains the name of the (40) destination online table. DST_SUBSCHEMA NO VARCHAR2 Currently this field is not used. (40) FILTERSYNTAX NO VARCHAR2 Currently this field is not used. (255)
Importing Data 4-7 Data Import Overview
Table 4–2 (Cont.) Fields in CZ_XFR_TABLES Field Name Required Type Description PK_USEEXPANSION NO VARCHAR2 The following values indicate (1) which key is passed through the user expansion field and used for resolution: 0 - surrogate key 1 - expansion key 2 - ORIG_SYS_REF DISABLED NO VARCHAR2 If 1, there is no transfer of data. For (1) 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, " Fields in CZ_XFR_FIELDS" describes the fields in the CZ_XFR_FIELDS table.
Table 4–3 Fields in CZ_XFR_FIELDS Field Name Required Type Description XFR_GROUP YES VARCHAR2 Used to name and group sequences (20) of imports, such as EXTRACT, IMPORT. ORDER_SEQ YES NUMBER(9) Identifies the XFR_TABLES order to which this field record refers. FIELD_ORDER YES NUMBER Orders field transfers within the transferred table. SRC_FIELD NO VARCHAR2 Name of the source field from the (40) source table identified in XFR_ TABLES. DST_FIELD NO VARCHAR2 Name of the destination field in the (40) destination table identified in XFR_ TABLES.
4-8 Oracle Configurator Implementation Guide Data Import Overview
Table 4–3 (Cont.) Fields in CZ_XFR_FIELDS Field Name Required Type Description REQUIRED NO VARCHAR2 Indicates whether this field is (1) required or not (0 or1). The default is 0 (not required). DEFAULTSYNTAX NO VARCHAR2 Currently this field is not used. (255) NOUPDATE NO VARCHAR2 Applies to records being updated (1) by the successive import of the same row into the database. If 1, then this field is not to be updated. If 0 (default), then this field will be updated with the rest of the row.
Each entry in the CZ_XFR_PROJECT_BILLS table identifies a top-level item from a bill of material in (BOM) Oracle Applications for import into the CZ schema. Every imported bill must be represented in CZ_XFR_PROJECT_BILLS. Table 4–4, " Fields in CZ_XFR_PROJECT_BILLS" describes the fields in the CZ_XFR_PROJECT_BILLS table.
Table 4–4 Fields in CZ_XFR_PROJECT_BILLS Field Name Required Type Description ORGANIZATION_ID YES NUMBER Identifies the BOM’s organization ID in Oracle Applications Bills of Material. This field is used when imported Models are synchronized with BOMs on a different server. COMPONENT_ITEM_ NO NUMBER This is the component item ID identifier of the top item from the Oracle Bills of Material for the bill to be imported. This field is used when imported Models are synchronized with BOMs on a different server. DESCRIPTION NO VARCHAR2 Description of this item. (255) LAST_IMPORT_RUN_ NO NUMBER Identifies the import run in which ID this bill was last imported. LAST_IMPORT_DATE NO DATE Gives the date and time for when this bill was last imported.
Importing Data 4-9 Data Import Overview
Table 4–4 (Cont.) Fields in CZ_XFR_PROJECT_BILLS Field Name Required Type Description SOURCE_BILL_ NO VARCHAR2 1 - Indicates that this bill has been DELETED (1) deleted from Oracle Applications. 0 - Indicates that this bill is still active. TOP_ITEM_ID YES NUMBER The identifier for the top-level Item. This field is used when imported Models are synchronized with BOMs on a different server. DELETED_FLAG YES VARCHAR2 Flag indicating if this record was (1) deleted by the user. 1 - indicates that the record was deleted and will be purged. 0 - indicates that the record is still active. EXPLOSION_TYPE YES VARCHAR2 Determines how the BOM exploder (10) handles standard items. 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.) ALL, both included Items and optional standard Items are included in the BOM explosion. INCLUDED, only included Items are included in the BOM explosion. BILL_REVISION_DATE NO DATE The date when the source data for this bill in Oracle Applications was last modified. SOURCE_SERVER YES NUMBER The server instance that is the source of this bill. This field is used when imported Models are synchronized with BOMs on a different server. EFF_FROM NO DATE Bill "Effective from" date as defined in Oracle Applications Bills of Material.
4-10 Oracle Configurator Implementation Guide Data Import Overview
Table 4–4 (Cont.) Fields in CZ_XFR_PROJECT_BILLS Field Name Required Type Description EFF_TO NO DATE Bill "Effective to" date as defined in Oracle Applications Bills of Material. COPY_ADDL_CHILD_ NO VARCHAR2 Indicates whether or not child MODELS (1) models should be copied when creating a copy of a model. 0 - Reference existing models if available. 1 - Always import copies of newly-added models. MODEL_PS_NODE_ID YES NUMBER Model structure node identifier of the Model in the CZ schema.
Both the Oracle Configurator SQL*Plus scripts and the concurrent programs use the CZ_XFR_ control tables information in the CZ schema. The TOP_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 if it contains the ORGANIZATION_ ID that corresponds to the ORGANIZATION_ID on BOM items in Oracle Applications. CZ_INTL_TEXTS contains the text string from the DESCRIPTION field in the BOM_EXPLOSIONS table for each imported BOM Model structure node. The Oracle Configurator SQL*Plus scripts and concurrent programs 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.
Importing Data 4-11 The Import Process
4.2 The Import Process A BOM structure (ATO or PTO BOM Models, ATO or PTO structure and rules) is imported and used in Oracle Configurator Developer at the Model level. When an ATO or PTO BOM Model is imported, a Model node is created in Oracle Configurator Developer. If the imported BOM Model 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. Imported BOM Models are read-only in Oracle Configurator Developer, although you can add Properties, create additional Model structure, and define rules when defining your configuration model. To import any type of Oracle Inventory Item into Oracle Configurator Developer, the Item must be associated with a BOM in Oracle Bills of Material. Additionally, if an Item that is defined as a Model in Oracle Inventory exists as a component in another BOM (for example, a PTO BOM that contains an ATO), the ATO Item must itself be defined as a BOM in Oracle Bills of Material in order to be successfully imported into Oracle Configurator Developer. The Oracle Applications tables from which data can be imported are listed in Table 4–5, " Oracle Applications Source and Destination Online Tables".
Table 4–5 Oracle Applications Source and Destination Online Tables Oracle Applications Source Table CZ Schema Destination Online Table(s) BOM_EXPLOSIONS CZ_PS_NODES, CZ_DEVL_PROJECTS, CZ_ INTL_TEXTS MTL_SYSTEM_ITEMS CZ_ITEM_MASTERS CZ_DEV_PROJECTS MTL_DESCRIPTIVE_ CZ_PROPERTIES ELEMENTS MTL_ITEM_CATALOG_ CZ_ITEM_TYPES GROUPS MTL_DESCR_ELEMENT_ CZ_ITEM_PROPERTY_VALUES VALUES
Each bill corresponds to a Model record inserted in the CZ_DEVL_PROJECTS table. The Populate Configuration Models concurrent program inserts the root Model and hierarchy of each bill in the CZ_PS_NODES table.
4-12 Oracle Configurator Implementation Guide Data Imported into the CZ Schema
The CZ schema requires complete BOMs; you cannot import partial BOMs or subassemblies. You must identify the TOP_ITEM_ID for the BOM you want to import from Oracle Applications when running the Populate Configuration Model concurrent program. See Section 4.6.1.4, "Running the Populate Configuration Models Concurrent Program" on page 4-21. The BOM structure is imported as a Model into Oracle Configurator Developer. The Model is then visible in the Oracle Configurator Developer Model window. 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 CZ Schema BOM hierarchy and Inventory data can be imported into the CZ schema only from other Oracle Applications tables (Release 11i, 10.7, or 11.0) such as the BOM_ EXPLOSIONS table. Both engineering and manufacturing bills and items can be imported into the CZ schema. If an Inventory Item is in both the engineering and manufacturing bills, then Oracle Configurator imports the first one that the Populate Configuration Models concurrent program finds in the table, and only that one. Similarly, Order Management does not make a distinction between engineering and manufacturing at the order entry level. If an Inventory Item is in both engineering and manufacturing, you cannot pick whether you want the engineering or the manufacturing version. See the Oracle Bills of Material Users Guide for information about engineering and maufacturing bills. Importing from Oracle Applications tables enables you to populate the CZ schema with the following data:
■ Bills of Material (BOM) structure (ATO or 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 or PTO BOM:
■ optional or required
■ minimum and maximum quantity
■ mutually exclusive
■ quantity cascade Properties from Oracle Inventory such as item catalog group, catalog descriptive elements and values can also be imported and used in Oracle Configurator
Importing Data 4-13 Data Import Setup
Developer. Table 4–6, " Properties Imported from Oracle Inventory" lists the properties imported from Oracle Inventory.
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 is associated with the corresponding Item Type 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 Section 4.9.4, "Creating a Custom Import" on page 4-33 for information about data imported using a custom import.
4.4 Data Import Setup Import setup consists of:
■ Making sure that the data to be imported is clean. BOMs must be complete and identified at the desired root.
■ Defining, enabling, and modifying the server used for import. See Section 1.9.1.1, "Server Administration" on page 1-17 for detailed information about defining, enabling, and modifying a server for import. Several servers can be defined and enabled, but only one server is Import Enabled. See Table 1–2, " Oracle Configurator Concurrent Programs for Server Administration" on page 1-18. If an import server is changed after a BOM has been imported, then the configuration models must be synchronized to the BOMs on the new import server. For details, see Section 4.6.1.5, "Running the Synchronize All Models Concurrent Program" on page 4-22.
■ Identifying or customizing what data gets imported. To do this you run concurrent programs to set the values in the CZ_XFR_ control tables in the CZ
4-14 Oracle Configurator Implementation Guide Importing Data From Oracle Applications
schema that control import. See Section 4.6.1, "Importing from Oracle Bills of Material" on page 4-18 for information about identifying what gets imported. See Section 4.9, "Customizing Data Import" on page 4-31 for information about customizing what gets imported.
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 CZ schema for use by Oracle Configurator Developer to create Model structure, Oracle Configurator rules, and User Interface layouts for the definition of a configuration model. You can import data from Oracle Applications, Release 11i, 10.7 or 11.0, into the Release 11i CZ 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 (APPLID). Importing data from Oracle Applications schemas into the CZ schema, Release 11i is accomplished by running concurrent programs in Oracle Applications. The concurrent programs import BOM and Item Master data into the CZ schema. To do this, the concurrent programs 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 CZ schema with imported data from the import tables.
4.5.1 Decimal or Integer Quantities BOM Standard Items can be imported as either integers or decimals. The Oracle Inventory and BOM applications can treat quantities as either integers or decimals. When defining an item in Oracle Inventory, you can specify whether the quantity for the item is to be entered as either an integer or decimal value when ordering the item in Oracle Order Management. You do this by setting the OM Indivisible attribute, which is on the Physical Attributes tab of the Item Master window in Oracle Inventory. By default, the OM Indivisible check box is unchecked, indicating that the item accepts decimal quantities. Order Management uses this option to determine whether a partial quantity can be ordered in the item’s base unit of measure (for example, 3.7 pounds).
Importing Data 4-15 Importing Data From Oracle Applications
Warning: Release 11i of Oracle Order Management does not yet support decimal quantities, so it cannot book an order for a configuration that uses decimal quantities. To find out when this feature is available, please search the Order Management area of Oracle’s customer support web site at http://metalink.oracle.com. See the Oracle Configurator Installation Guide for additional information about the CZ: Populate Decimal Quantity Flags profile option.
4.5.1.1 Impact on Import The behavior of import is controlled by the profile option CZ: Populate Decimal Quantity Flags (internal name: CZ_IMP_DECIMAL_QTY_FLAG). During each import or import refresh, the value of CZ_IMP_DECIMAL_QTY_FLAG is examined.
■ If the value is No, then import populates the DECIMAL_QTY_FLAG column in both CZ_ITEM_MASTERS and CZ_PS_NODES with a value of 0. Consequently, all items are imported as allowing only integer input, regardless of how they were defined in Oracle Inventory.
■ If the value is Yes, then the value of MTL_SYSTEM_ITEMS.INDIVISIBLE_ FLAG for an item determines the value of the DECIMAL_QTY_FLAG column in both CZ_ITEM_MASTERS and CZ_PS_NODES.
■ If INDIVISIBLE_FLAG is 0 or NULL, then DECIMAL_QTY_FLAG in both tables will be set to 1, which means that decimal quantities are allowed.
■ If INDIVISIBLE_FLAG is 1, then DECIMAL_QTY_FLAG in both tables will be set to 0, which means that decimal quantities are not allowed. If the profile option is set to Yes to enable the import of decimal quantities, then you must refresh existing Models in order to receive the decimal quantity setting from Oracle Inventory. You must also republish existing publications. See Section 4.8.3, "Running the Refresh All Imported Configuration Models Concurrent Program" on page 4-26 and Section 6.2.2.5, "Decimal Quantities" on page 6-10. See the Oracle Configurator Developer User’s Guide for additional information on the impact of decimal quantities on configuration models and rules. See Oracle Configuration Interface Object (CIO) Developer’s Guide on the impact of decimal quantities and the CIO.
4-16 Oracle Configurator Implementation Guide Data Import Concurrent Program
4.6 Data Import Concurrent Program If you want to build configuration models based on BOM Models from Oracle Applications Release 11i, you can run concurrent programs provided in Oracle Applications under the Configurator Developer and Configurator Administrator responsibilities. The Populate Configuration Models concurrent program imports BOM and Item Master data from the Bills of Material schema into the CZ schema. The Oracle Configurator Developer uses this data to define a configuration model. Figure 4–2 is an overview flow for importing data from Oracle Bills of Material into the CZ schema.
Figure 4–2 Overview of Data Import from Oracle Bills of Material
The following concurrent programs enable you to import BOM Models from the Bills of Material schema into the CZ schema, refresh a configuration model, refresh all configuration models, or to disable or enable the refresh of previously imported BOM Model data in the CZ schema:
■ Populate Configuration Models - see Section 4.6.1.4, "Running the Populate Configuration Models Concurrent Program" on page 4-21
■ Refresh a Single Configuration Model - Section 4.8.2, "Running the Refresh A Single Configuration Model Concurrent Program" on page 4-26
■ Refresh All Configuration Models - see Section 4.8.3, "Running the Refresh All Imported Configuration Models Concurrent Program" on page 4-26
Importing Data 4-17 Data Import Concurrent Program
■ Disable/Enable Refresh of a Configuration Model - see Section 4.8.1, "Running the Disable/Enable Refresh of a Configuration Model Concurrent Program" on page 4-25 When you run these Oracle Configurator concurrent programs, 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. Section 4.6.1.4, "Running the Populate Configuration Models Concurrent Program" on page 4-21, Section 4.8.2, "Running the Refresh A Single Configuration Model Concurrent Program" on page 4-26, and Section 4.8.1, "Running the Disable/Enable Refresh of a Configuration Model Concurrent Program" on page 4-25. You can import data for a single BOM Model or for several BOM Models at once. In order to import data, parameters mentioned in on page 4-21 must be specified. See Section 1.3.1, "Concurrent Programs" on page 1-5 for a complete list of other concurrent programs 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 Section 4.6.1.1, "Enabling a Server for Import" on page 4-18) 2. Explode the BOM Models you want to import if you are not importing from your local instance. (see Section 4.6.1.3, "Exploding BOMs in Oracle Applications" on page 4-19) 3. Synchronize your BOM-based configuration models with the BOM Models on the new import server if you are not importing from the original remote (import) server from which you originally imported the BOM Models. (Section 4.6.1.2, "Changing a Server for Import" on page 4-19). 4. Run the Populate Configuration Models concurrent program (see Section 4.6.1.4, "Running the Populate Configuration Models Concurrent Program" on page 4-21).
4.6.1.1 Enabling a Server for Import The local server is the default 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 Section 1.9.1.1, "Server Administration" on page 1-17. Therefore, if you need to define and enable a remote
4-18 Oracle Configurator Implementation Guide Data Import Concurrent Program
server for import, you must first submit a Modify Server Definition (see Table 1–2, " Oracle Configurator Concurrent Programs for Server Administration" on page 1-18) 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. It is strongly recommended that there is only one server defined for import. The server that is defined for import is the server that is used when the concurrent program Synchronize All Models is implemented. See Section 4.6.1.5, "Running the Synchronize All Models Concurrent Program" on page 4-22.
4.6.1.2 Changing a Server for Import Oracle Configurator supports import from only one Oracle Applications database. This is because the information used to refresh imported Oracle Applications BOM Models can overlap between multiple Applications databases. If a different database server is enabled for Import after data has been imported into the CZ schema, Models can become corrupt when they are populated or refreshed. The Synchronize All Models concurrent program , synchronizes all imported Models on the current server with the BOM Models on the new import server. You must run the Synchronize All Models concurrent program if the import server has changed. For details, see Section 4.6.1.5, "Running the Synchronize All Models Concurrent Program" on page 4-22.
4.6.1.3 Exploding BOMs in Oracle Applications If you are importing from Bills of Material (Releases 10.7, 11.0, or 11i), and you are importing from another instance (remote server), 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. If there are child nodes in the BOM, the child nodes must be exploded prior to exploding the parent node.
4.6.1.3.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 appropriate username and password. 2. Select Order Management responsibility. 3. Select Orders, Returns. 4. Select Sales Order Pad. 5. Click on the Main tab and enter all required fields.
Importing Data 4-19 Data Import Concurrent Program
6. Click on the Line Items tab. 7. Select the Ordered Item that you want to import into Oracle Configurator from the list of values. This is the same model that you will select from the list of values when you run the Oracle Configurator Populate Configuration Models concurrent program. 8. Enter 1 in the Qty field. 9. Click Configurator. 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 Populate Configuration Models concurrent program (see Section 4.6.1.4, "Running the Populate Configuration Models Concurrent Program" on page 4-21).
4.6.1.3.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 appropriate username and password. 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 Populate Configuration Models concurrent program. 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 Populate Configuration Models concurrent program (see Section 4.6.1.4, "Running the Populate Configuration Models Concurrent Program" on page 4-21).
4-20 Oracle Configurator Implementation Guide Data Import Concurrent Program
4.6.1.4 Running the Populate Configuration Models Concurrent Program 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 as either the Configurator Administrator or Configurator Developer responsibility. 2. Select Populate/Refresh Configuration Models > Populate Configuration Models. 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. 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 PTO500 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 a single model, enter the same Model Inventory Item that was entered in the Model Inventory Item From parameter box. 6. Click OK.
4.6.1.4.1 Possible Error Messages during the Populate Configuration Models Concurrent Program On certain error conditions there is no data in the extraction views and the list of values for a new import does not have any data. In these cases, the list of values for the Populate Configuration Models concurrent program displays a ’No entries found for List of Values’ message. Possible reasons for the missing data include:
■ A server has not been enabled for import
■ The Enable Remote Server concurrent program did not complete successfully
■ The database link is down
■ The remote database is down
■ The extraction views are invalid
Importing Data 4-21 Verify Data Import
If the database link is down, the message 'error 2019: connection description for remote database not found' followed by the SQL statement being run is displayed. Action: 1. The Configurator Administrator responsibility must select the Modify Server Definition concurrent program and enable a Server for import (if one is not already selected). See Table 1–2, " Oracle Configurator Concurrent Programs for Server Administration" on page 1-18. 2. Run Enable Remote Server if the enabled server is not LOCAL. See Table 1–2, " Oracle Configurator Concurrent Programs for Server Administration" on page 1-18. Rerunning this concurrent program recreates the extraction views.
4.6.1.5 Running the Synchronize All Models Concurrent Program If the import server changes after the BOM is imported, you must first check that the BOMs of your configuration models are similar with the BOMs on the new server. See Section 1.9.1.6, "Checking BOM and Model Similarity" on page 1-24 for details. The Synchronize All Models concurrent program synchronizes all Models on the server you are logged into with the BOMs on the server that is now enabled as the import server. 1. Log into Oracle Applications using the appropriate username and password. 2. Select the Configurator Administrator responsibility 3. Select Synchronize All Models concurrent program. There are no required input parameters for this concurrent program. 4. Submit the request. The Synchronize All Models concurrent program produces a report containing comprehensive messages describing any problems that were encountered when attempting to synchronize the Models with the Bills and Items on the new remote server. Only satisfied Models are synchronized. See Section 1.9.1.6.4, "Model/Bill Similarity Check Report" on page 1-27.
4.7 Verify Data Import After you import data into the CZ schema, start Oracle Configurator Developer to view the Item Master and Model(s) containing the imported data. All Items
4-22 Oracle Configurator Implementation Guide Refresh and Update Imported Data
imported into the CZ schema are displayed in the Oracle Configurator Developer Item Master. Items imported into the CZ schema Item Master can be edited.
4.8 Refresh and Update Imported Data Oracle recommends that you limit changes to the source data during construction of an Oracle Configurator Model in order 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 runtime Oracle Configurator. Test cases may have to be updated to match the changes. Although randomly updating imported data in the CZ schema 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 runtime 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. If components are added to the BOM Model, they will be added to the Oracle Configurator Model during the next refresh. Oracle Configurator’s Running the Disable/Enable Refresh of a Configuration Model Concurrent Program concurrent program, disables or enables specific configuration models so that you can reduce the number of Models affected by a refresh. Oracle Configurator’s Running the Refresh A Single Configuration Model Concurrent Program concurrent program, updates a currently existing configuration model in the Oracle Configurator schema with changes that may have been made in the BOM Model. Refreshing configuration models, refreshes the data on the development schema only. Once a runtime Oracle Configurator has been deployed, data is copied to the production CZ schema through the publishing process (see Chapter 6, "Publishing Configuration Models"). During deployment, further imports and publications are done to refresh and update the CZ schema as source data changes. The procedures that perform the import prevent customer-specific groups of fields in the CZ schema from being altered or nulled out even when other fields in the row are replaced during an import session. Oracle Configurator’s Running the Refresh All Imported Configuration Models Concurrent Program concurrent program, updates all configuration models in a
Importing Data 4-23 Refresh and Update Imported Data
development Oracle Configurator schema with changes that have been made in a production schema. The concurrent program ensures that existing production data, such as saved configuration data, is preserved. After the Running the Refresh All Imported Configuration Models Concurrent Program concurrent program is run, the Models must be republished to the production schema. See the Oracle Configurator Developer User’s Guide for additional publishing information. The first time a BOM is imported, the minimum and maximum Instance setting is 1. Subsequently, the BOM Model’s minimum and maximum Instance may be changed in Oracle Configurator Developer, but refreshing the BOM does not override the minimum and maximum Instance values. Refreshing the BOM does update the Quantity. The Refresh All Imported Configuration Models concurrent program refreshes the following tables: 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 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
4-24 Oracle Configurator Implementation Guide Refresh and Update Imported Data
CZ_UI_NODES CZ_UI_PROPERTIES CZ_UI_NODE_PROPS
Many of these tables are not referenced by runtime 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 that were previously imported from Bills of Material (Releases 10.7, 11.0, or 11i) you must: 1. Enable the refresh of a configuration model (see Section 4.8.1, "Running the Disable/Enable Refresh of a Configuration Model Concurrent Program" on page 4-25) 2. Explode the BOM Models you want to import if you are not importing from your local server (see Section 4.6.1.3, "Exploding BOMs in Oracle Applications" on page 4-19) 3. Run the appropriate refresh concurrent program (see Section 4.8.2, "Running the Refresh A Single Configuration Model Concurrent Program" on page 4-26 or Section 4.8.3, "Running the Refresh All Imported Configuration Models Concurrent Program" on page 4-26)
4.8.1 Running the Disable/Enable Refresh of a Configuration Model Concurrent Program Use the following procedure to disable or enable the refresh of a configuration model from the Bills of Material schema into the CZ schema: 1. Log into Oracle Applications under either the Configurator Administrator or Configurator Developer responsibility. 2. Select Configurator > Populate/Refresh Configuration 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) that is being enabled or disabled. 4. Click OK.
Importing Data 4-25 Refresh and Update Imported Data
5. Click Submit.
4.8.2 Running the Refresh A Single Configuration Model Concurrent Program 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 as either the Configurator Administrator or Configurator Developer responsibility. 2. Select Configurator > Populate/Refresh Configuration 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.
4.8.3 Running the Refresh All Imported Configuration Models Concurrent Program Once a runtime Oracle Configurator has been deployed, further imports or refreshes are done to refresh the CZ schema when Oracle Applications data changes. The Refresh All Imported Configuration Models concurrent program updates the data between the BOM schema and the CZ schema. The concurrent program also updates the Model tree structures and associated Item Master data with new or revised BOM data in Oracle Configurator Developer. Use the following procedure to refresh all imported BOM Models. No parameters are required for this concurrent program: 1. Log into Oracle Applications as the Configurator Administrator responsibility. 2. Select Configurator > Populate/Refresh Configuration Models > Refresh All Imported Configuration Models. 3. Click Open. 4. Click Submit.
4-26 Oracle Configurator Implementation Guide Refresh and Update Imported Data
4.8.4 Refreshing BOM Models that Have Changed Type When you refresh BOM Models that have submodels, all changes that were made in the BOM Model and its submodels are reflected in Oracle Configurator Developer. See Section 4.8, "Refresh and Update Imported Data" on page 4-23 for more information. When a PTO Model is refreshed, and its source model has been changed to an ATO Model, the Refresh A Single Configuration Model concurrent program checks to see if the PTO Model needs to support multiple instantiation. If the PTO Model in Oracle Configurator Developer does not need to support multiple instantiation, then the Refresh A Single Configuration Model concurrent program continues refreshing the Developer Model with the information from the source BOM Model. The Developer Model is changed to an ATO Model. If the PTO Model in Oracle Configurator Developer supports multiple instantiation, then the Refresh A Single Configuration Model concurrent program returns a message indicating that the PTO Model cannot be changed to an ATO Model and that the BOM Model must be changed to a PTO Model. See Oracle Configurator Developer User’s Guide for more information about Solution-based Models and Multiple Instantiation.
4.8.4.1 Populate and Refresh Scenarios There are limitations when you import multiple BOMs that have references. For instance, 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. B1 contains references to B2 and B3.
4.8.4.1.1 Scenario 1 - Initial Import of BOM Model When you import B1 (by running the Populate Configuration Models concurrent program for the first time), you see three corresponding Models (M1, M2, and M3) in Oracle Configurator Developer Repository with corresponding child nodes. You also see M1 contains references to M2 and M3 in the Model window. Figure 4–3 illustrates this result in Oracle Configurator Developer.
Importing Data 4-27 Refresh and Update Imported Data
Figure 4–3 Initial Import of BOM Model with Submodels
4.8.4.1.2 Scenario 2 - Populate and 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 populate or refresh B1 by running either the Populate Configuration Models or Refresh a Single Configuration Model concurrent program, 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.
4-28 Oracle Configurator Implementation Guide Refresh and Update Imported Data
Figure 4–4 Populate and Refresh of Initial BOM Model
4.8.4.1.3 Scenario 3 - Import New BOM Model with References to Existing BOM Models In Oracle Bills of Material you create BOM Model B6, that references B2 and B3. When you import B6 by running the Populate Configuration Models concurrent program, 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.
Importing Data 4-29 Refresh and Update Imported Data
Figure 4–5 Import a New BOM Model with References to Existing BOM Models
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 the Active Model and UI for M1. If M1 was published, the runtime Oracle Configurator end user can still use M1 at runtime because as a part of the publishing process Oracle Configurator Developer creates another copy. See Section 6.1.2, "The Publication Process" on page 6-2, and the Oracle Configurator Developer User’s Guide.
4.8.4.1.4 Scenario 4 - Import New BOM with Reference to a Common Bill The reference to a common bill is lost when importing a BOM into the CZ schema that references the common bill. A common bill is a read-only shared bill defined in the Item Master Inventory Organization that can be referred to when defining bills in other organizations. In Bills of Material, Organization 1, BOM X is created and references common bill A. In Organization 2, BOM Y references A’. A’ references A (common bill) and does not have any contents of its own. When BOM Y is imported in Oracle Configurator Developer (Organization 2), the reference between Model A’ and the original A is lost. A’ references a different Model A in the CZ schema. Oracle Configurator
4-30 Oracle Configurator Implementation Guide Customizing Data Import
imports common bills, but the relationship between A' and A is not preserved. Figure 4–6 shows the lost reference after import.
Figure 4–6 Importing a Common Bill Referenced in Another Organization
4.9 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
Note: You should always contact your Oracle consultant before attempting any database customization.
Importing Data 4-31 Customizing Data Import
■ Creating and performing a custom import of legacy data from non-Oracle Applications databases
4.9.1 Importing Data Into 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 as the Configurator Administrator responsibility. 2. From the View menu select Requests. 3. In the Find Requests window, click Submit a New Request. 4. In the Submit a New Request window, accept the default and choose Ok to submit a single request. 5. In the Submit Request window, click the ... button, select the Select Tables To Be Imported concurrent program 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, Generic, or Populators. 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 or N) - from the list of values, select N to disable or Y to enable the specified table for the specified import phase. 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.
4-32 Oracle Configurator Implementation Guide Customizing Data Import
You can also display the current tables to be imported by selecting the concurrent program, 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.9.2 Importing/Extracting Data from Specific Fields You can customize which fields in the tables listed in CZ_XFR_TABLES are extracted and imported. See Section 4.1.3, "Control Tables (CZ_XFR_)" on page 4-7 for more information about CZ_XFR_TABLES and other control tables. There is no concurrent program to complete this customization. Modification of the EXPLOSION_TYPE field can only be accomplished by using SQL*Plus.
4.9.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 Section 4.1.3, "Control Tables (CZ_XFR_)" on page 4-7 for more information about CZ_XFR_PROJECT_BILLS and other control tables. There is no concurrent program to complete this customization. Modification of the EXPLOSION_TYPE field can only be accomplished by using SQL*Plus.
4.9.4 Creating a Custom Import Using a series of custom-written programs and the Oracle Configurator import concurrent programs, you can import other Oracle Applications data or legacy data from non-Oracle Applications databases. This is called a custom import. A custom import process utilizes the import tables to load data into the online CZ schema. The following tables can be populated through a custom import:
Importing Data 4-33 Customizing Data 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:
■ 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 Section 4.9.4.1, "Setup for a Custom Import" on page 4-34 and Section 4.9.4.3, "Required ASCII File Format for Custom Import" on page 4-36. OR
■ Load the data generated by the custom extraction programs directly into the import tables. 3. Run the concurrent program, Populate Configuration Models, that populates the CZ schema tables with imported data from the import tables. See Section 4.6.1.4, "Running the Populate Configuration Models Concurrent Program" on page 4-21.
4.9.4.1 Setup for a Custom Import If you are importing legacy data or Oracle Applications data that is not accessible through import using the import concurrent programs, you must perform a custom import. Custom import requires writing a custom program to extract the product and product-related data in a format that satisfies the import tables in the CZ schema. You must then develop custom load programs to populate the import tables in the CZ schema with that extracted data. You then run the Populate Configuration Models concurrent program provided by Oracle Configurator that populates the CZ schema from the import tables.
4-34 Oracle Configurator Implementation Guide Customizing Data Import
Figure 4–7 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, "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_) what extracted data is loaded into the import tables. To do this, follow the procedure described in Section 4.9.1, "Importing Data Into Specific Tables" on page 4-32. There is a flag in the CZ_PS_NODES table (QUOTEABLE_FLAG). The OC Servlet server looks at this flag in order to decide whether to display a particular item in the DHTML Summary screen. Custom import programs should take this new flag into consideration. For more information about the DHTML window and Summary screen see the Oracle Configurator Developer User’s Guide.
4.9.4.2 Extraction Setup for a Custom Import Figure 4–8, "Extraction Setup for a Custom Import" shows the process for setting up the extraction portion of a custom import.
Importing Data 4-35 Customizing Data Import
Figure 4–8 Extraction Setup for a Custom Import
After creating the Data Transfer Files required by the CZ 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.9.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 (|). Example 4–1, "Data Transfer File Format" imports item types. Item type populates the third column of the 21-column import table CZ_IMP_ITEM_MASTER.
Example 4–1 Data Transfer File Format ||Memory Board||||||||||||||||||| ||Dual CPU|||||||||||||||||||
4-36 Oracle Configurator Implementation Guide Customizing Data Import
||Country||||||||||||||||||| ||System Console||||||||||||||||||| ||Server Console||||||||||||||||||| ||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.9.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.9.4.3, "Required ASCII File Format for Custom Import", on page 4-36. 2. Be sure you have extracted legacy data and loaded it into the CZ schema import tables. See Section 4.9.4.1, "Setup for a Custom Import", on page 4-34. 3. If you do not load data into all of the CZ schema import tables, run the Select Tables To Be Imported concurrent request as described in Section 4.9.1, "Importing Data Into Specific Tables" on page 4-32. 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
Importing Data 4-37 Customizing Data Import
■ CZ_PROPERTIES 4. Run the Populate Configuration Models concurrent program as described in Section 4.6.1.4, "Running the Populate Configuration Models Concurrent Program" on page 4-21. 5. Verify your import as described in Section 4.7, "Verify Data Import" on page 4-22.
4-38 Oracle Configurator Implementation Guide 5 Pricing in Oracle Configurator
How Oracle Configurator handles pricing depends on the type of runtime Oracle Configurator you choose to use. A runtime Oracle Configurator can be called from a variety of different applications and requires an interface between the runtime Oracle Configurator and the calling application’s pricing mechanism.
5.1 Pricing in a Runtime Oracle Configurator For a list of hosting applications that support Oracle Configurator, see the Oracle Configurator Release Notes. The Java Applet interface for the runtime 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 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 runtime 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 runtime Oracle Configurator knows how to determine prices.
Pricing in Oracle Configurator 5-1 Pricing in a Runtime Oracle Configurator
Therefore, the calling application to the runtime Oracle Configurator provides an interface PL/SQL package that interacts whenever pricing is requested between the runtime Oracle Configurator and the calling application's pricing engine. The runtime Oracle Configurator is displayed when the user clicks the Configure button in the calling application. The runtime Oracle Configurator calls the pricing 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 entire configuration For more information about the Pricing Callback Interface, see the Oracle Configurator Custom Web Deployment Guide.
5.1.1 Pricing Interaction in the User Interfaces The interaction of the end user with pricing varies depending on the Oracle Configurator user interface.
5.1.1.1 Pricing Interaction in the Java Applet User Interface When the runtime Oracle Configurator is initialized, it displays the list prices for the options appearing on the first screen page, in the Options Selection region and in the Selected Items or Summary region. When the end user clicks the Update Prices button, the runtime Oracle Configurator calls the pricing package to get the selling prices for all 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 end user clicks the Summary button in the DHTML UI, the runtime Oracle Configurator calls the pricing package to get the selling prices for all selected options and the total price for the configuration. The selling prices are then displayed in the Summary window.
5.1.2 General Pricing Behavior The runtime Oracle Configurator caches list prices of the items until it is closed. The runtime 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.
5-2 Oracle Configurator Implementation Guide Runtime Oracle Configurator Pricing Architecture
The runtime 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 runtime 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 runtime 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 Runtime Oracle Configurator Pricing Architecture The calling application sends an initialization message to the runtime Oracle Configurator with the interface package and procedure name. The runtime 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 runtime Oracle Configurator session exits. The runtime Oracle Configurator does not reference the contents of these tables. The interface package temporarily 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 CZ_PRICING_STRUCTURES table does not support pricing rules based on the fact that items belong to the same instance. Pricing is done per component instance. The runtime Oracle Configurator saves the configuration information in the appropriate CZ tables. The runtime Oracle Configurator does not save lists 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
Pricing in Oracle Configurator 5-3 Runtime Oracle Configurator Pricing Architecture
necessary to recalculate prices depending on the value of the prices_ calculated_flag in the runtime Oracle Configurator termination message. When the calling application calls the runtime Oracle Configurator to edit an existing configuration, the runtime Oracle Configurator asks the interface package for the current list and selling prices of the already selected components. Figure 5–1, "Runtime Oracle Configurator Pricing Architecture", illustrates this architecture. Illustrated steps 2 through 5 can be repeated many times.
Figure 5–1 Runtime Oracle Configurator Pricing Architecture
See the Oracle Configurator Custom Web Deployment Guide for details about the pricing interface package, and about the initialization and termination messages for a runtime Oracle Configurator session.
5-4 Oracle Configurator Implementation Guide Controlling Pricing in the Runtime Oracle Configurator
5.3 Controlling Pricing in the Runtime Oracle Configurator You can control whether and how pricing and ATP information is presented in the runtime 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 runtime 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.
5.3.1 Displaying Price Types The following sections explain how to control the type of prices to be displayed to the end user.
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.activemodel property of the OC Servlet. (See the Oracle Configurator Installation Guide for details about setting OC Servlet properties.)
Pricing in Oracle Configurator 5-5 Controlling Pricing in the Runtime Oracle Configurator
The syntax for this setting is: cz.activemodel=/switch|
Table 5–1, " Switch Effects" lists the switch and its effect:
Table 5–1 Switch Effects 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.activemodel property 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 runtime 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 Table 5–2, " Examples and Effect of Pricing Switches" lists examples and the effect of pricing switches:
5-6 Oracle Configurator Implementation Guide Controlling Pricing in the Runtime Oracle Configurator
Table 5–2 Examples and Effect of 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. Table 5–3, " Item Price Option Effects" lists the options and the effects:
Table 5–3 Item Price Option Effects 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 Runtime 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 runtime 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. 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 Section 5.3.2.1, "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. Table 5–4, "List Price Property Settings" lists the Option and the corresponding effect. 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 Runtime 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 for an explanation of these choices.
5.3.3.1 Example: List Prices Only Table 5–4, "List Price Property Settings" illustrates the values that you should probably choose— subject to the specific nature of your application—if you want to display only list prices.
Table 5–4 List Price Property Settings 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 Table 5–5, "Selling Price Property Settings" illustrates the values that you should probably choose— subject to the specific nature of your application—if you want to display only selling prices.
Table 5–5 Selling Price Property Settings 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 Runtime Oracle Configurator
5-10 Oracle Configurator Implementation Guide 6 Publishing Configuration Models
This chapter explains the publishing process 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. See Section 1.7.3, "Production" for additional information about Oracle Configurator Environments.
6.1.1 Planning Publications In order to use publications effectively, it is necessary to plan and design how each publication will be used. 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. For a list of hosting applications that support Oracle Configurator, see Oracle Configurator Release Notes. 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 tasks in Oracle Applications and Oracle Configurator Developer.
Publishing Configuration Models 6-1 Overview of Publishing Configuration Models
Your project design should account for how 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?
Warning: The Configurator publication process does not prevent users on multiple development instances from publishing Models to the same target instance. However, you can only be sure that you are not introducing applicability parameter overlaps in a target instance if all publications are exported from a single development instance.
■ 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
6-2 Oracle Configurator Implementation Guide Overview of Publishing Configuration Models
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 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 publications can be valid. Oracle Configurator Developer checks for overlap in the publication attributes in the development environment at the time the publication is defined. It does not check the target database to which the Models are being published. When the development and production are different databases, do not run Oracle Configurator Developer and Generate Active Model command against the deployed production Oracle Configurator schema on Models that were published from the development database. Models should only be published from a single development instance to avoid Models with overlapping applicability from coexisting on the target database. Overlapping publications could result in unpredictable behavior at runtime. 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 runtime circumstances and environment in which the published configuration model is accessible
■ checking that the BOM-based configuration models being published are sufficiently similar to the corresponding BOMs on the target database, if the target database is different from the import server
■ 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
Publishing Configuration Models 6-3 Defining Publications
6.2 Defining Publications 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 (see Section 6.2.1.1, "Product" on page 6-4)
■ Model (see Section 6.2.1.2, "Model" on page 6-5)
■ Database instance (see Section 6.2.1.3, "Database Instance" on page 6-5)
■ UI Definition (see Section 6.2.1.4, "User Interface" on page 6-6)
■ Applicability parameters, which:
■ Publication mode (see Section 6.2.2.1, "Publication Mode" on page 6-6)
■ Application (see Section 6.2.2.2, "Application" on page 6-7)
■ Date range (see Section 6.2.2.3, "Date Range" on page 6-8)
■ Usage (see Section 6.2.2.4, "Usages" on page 6-8) By defining publication attributes, the implementer defines the runtime 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 Section 6.5, "Tables Used in Publishing" on page 6-12 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. Publications of imported BOM Models are specified by PRODUCT_KEY in CZ_MODEL_PUBLICATIONS.
6-4 Oracle Configurator Implementation Guide Defining Publications
The Product ID for a non-BOM Model defaults to the name of the Model, which the user defines and can change. The Product ID becomes the PRODUCT_KEY in the CZ_MODEL_PUBLICATIONS table. See Section 6.5, "Tables Used in Publishing" on page 6-12 for a summary of the tables involved in publishing. 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 the 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, a non-imported BOM configuration model, the PRODUCT_KEY is the Model name and can be updated by the user.
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. The Model name becomes the NAME in the CZ_DEVL_PROJECTS table. Publications of imported BOM Models are specified by PRODUCT_KEY in CZ_ MODEL_PUBLICATIONS. The initialization message from the calling application only includes the PRODUCT_KEY for publications of non-imported BOM configuration models, whereas the initialization message for publications of imported BOMs could be the PRODUCT_KEY or the INVENTORY_ITEM_ID and the ORGANIZATION_ID.
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.9.1.1, "Server Administration" on page 1-17 for detailed
Publishing Configuration Models 6-5 Defining Publications
information. All databases listed in CZ_SERVERS appear in the list of values for this publication parameter. If the configuration model is based on an imported BOM, and the target database is different from the database from which you imported the BOM, you must first check to see if the imported BOM is sufficiently similar to the corresponding BOM on the target database. See Section 1.9.1.6, "Checking BOM and Model Similarity" on page 1-24 for details. If the BOM-based configuration model does not match the BOM in the target database, publication will fail. For more information, see Section 6.3, "Synchronizing a Configuration Model with the BOM" on page 6-10.
6.2.1.4 User Interface By default, the value for the publication’s UI is NONE. This value means do not publish 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 Applicability Parameters determine the availability of a publication to hosting applications. Applicability Parameters include:
■ Publication mode (see Section 6.2.2.1, "Publication Mode" on page 6-6)
■ Application (see Section 6.2.2.2, "Application" on page 6-7)
■ Date range (see Section 6.2.2.3, "Date Range" on page 6-8)
■ Usages (see Section 6.2.2.4, "Usages" on page 6-8)
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 Production. Only publications with the mode Production or Test can be accessed by a hosting application such as Order Management or iStore. Disabling a publication makes it unavailable to hosting applications. Marking a publication "disabled" does not delete it from the database. You can make a disabled
6-6 Oracle Configurator Implementation Guide Defining Publications
publication available to hosting applications simply by editing the publication and changing the Publication Mode to Test or Production. The hosting application typically provides a publication mode as part of the session initialization message, which specifies the publication to access. If the publication mode is not provided in the initialization message, the Oracle Configurator Servlet uses the value of the Oracle Applications profile option CZ: Publication Lookup Mode. For more information about this profile option, see the Oracle Configurator Installation Guide.
6.2.2.2 Application This is the list of registered applications that can access Model publications. See the Oracle Applications System Administrator’s Guide for information about registering applications in order to extend the list of client applications available for publication. The FND_APPLICATION 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_APPLICATION table:
■ Order Management (ONT)
■ iStore (IBE)
■ Telesales (AST)
■ SalesOnLine
■ Bills of Material (BOM)
■ Sales for Comms (XNC)
■ Oracle Quoting. When you save a publication, the application(s) specified are stored in the CZ_PB_ CLIENT_APPS table. If you want to add applications to FND_APPLICATION, 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_APPLICATION in both databases.
Publishing Configuration Models 6-7 Defining Publications
The database view of CZ_MODEL_APPLICABILITIES_V may be useful for custom reporting or other data requirements. It associates published Models with their assigned Usages and hosting Applications.
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 available. 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).
Note: If a publication record is created with the default Valid From current time, it is possible that when the Model is launched from the hosting application, a Java applet is run rather than the expected DHTML window. This can happen if the machine time running Configurator Developer is out of synch with the machine time running the hosting application. Work around: When creating the Publication record, override the default Valid From setting and check the No Start Date box.
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 them for a publication. The Usages defined for a publication are stored in CZ_PUBLICATION_USAGES.
6-8 Oracle Configurator Implementation Guide Defining Publications
When creating or updating a publication, you can select one, multiple, or all Usages. Selecting All means that the 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:Publication Usage to set which Usages should restrict access by a calling application to a configuration model. For more information about this profile option, see the Oracle Configurator Installation Guide.
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 Products, Models, Model References, 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. 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 runtime Configurator. Usages can be a very powerful tool 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 identifies a particular Model and invokes the configuration window. When the Configurator window is invoked, the hosting application sends the initialization message you defined to the OC Servlet, which then selects the Model matching the effective date, publication mode, and Usage(s) provided.
Publishing Configuration Models 6-9 Synchronizing a Configuration Model with the BOM
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 Section 6.2.2.4, "Usages" on page 6-8.
6.2.2.5 Decimal Quantities You must republish existing publications in order to use the imported decimal quantity settings if you set the profile option CZ: Populate Decimal Quantity Flags to Yes, and imported or refreshed your BOM Models.
6.3 Synchronizing a Configuration Model with the BOM Synchronization is part of the concurrent program that publish the configuration models. When a configuration model that is based on an imported BOM needs to be published to a database instance that was not the source from which the BOM was imported, you must first check to see that the imported BOM is sufficiently similar to the corresponding BOM in the target database. For more information see Section 1.9.1.6, "Checking BOM and Model Similarity" on page 1-24. If the Models are not similar enough, publication will fail during synchronization. BOM synchronization is also necessary when changing the import server. For more information see Section 4.6.1.2, "Changing a Server for Import" on page 4-19 and Section 10.2.6, "Changing Development and Production Database Instances" on page 10-11.
6-10 Oracle Configurator Implementation Guide Creating the Publication
6.4 Creating the Publication Once a publication has been defined in Oracle Configurator Developer, it must be exported using one of the following concurrent programs:
■ 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 exports 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. See Section 6.2.1.3, "Database Instance" on on page 6-5 for additional information. If the configuration model is based on an imported BOM, and the database is different from the database where the configuration model originated, then the BOM in the configuration model must be synched with the BOM in the destination database before publication. See Section 1.9.1.6, "Checking BOM and Model Similarity" on page 1-24.
6.4.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 its 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 its publication are defined. Select the Configurator Administrator or Configurator Developer responsibility. 2. Select Configurator > Publish Configuration Models > Process a Single Publication.
Publishing Configuration Models 6-11 Tables Used in Publishing
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. See Section 1.9.1.2, "View the Status of Oracle Configurator Concurrent Programs Requests" on page 1-21. Knowing a publication’s ID can be helpful in determining publishing information. See Section 6.9.1, "Determining Publishing Information" on page 6-15.
6.4.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 its publication are defined. The target of the publication process is specified by the Database Instance publication attribute. The publication instance must be defined and enabled as a remote server. See Table 1–2, " Oracle Configurator Concurrent Programs for Server Administration" on page 1-18. 1. Access the database in which the publication is defined by logging into Oracle Applications under either the Configurator Administrator or Configurator Developer 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. See Section 1.9.1.2, "View the Status of Oracle Configurator Concurrent Programs Requests" on page 1-21.
6.5 Tables Used in Publishing Table 6–1, " Publication Tables" lists a description of the publication tables.
6-12 Oracle Configurator Implementation Guide Profile Options Used in Publishing
Table 6–1 Publication Tables Table Name Description CZ_MODEL_PUBLICATIONS Contains information about publications and pending publication requests. If the target database of a publication is different from the source, the export concurrent processes copy both the publication record for the configured 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 Usages defined for all configuration models in the current database. CZ_PB_CLIENT_APPS Contains the applications defined for each publication 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. FND_APPLICATION Identifies the calling applications that are available for specification in a publication. See Section 6.2.2.2, "Application" on page 6-7 for details.
For more detailed information about these tables, see the eTRM on Metalink, Oracle’s Customer Support Web site, at: http://metalink.oracle.com
6.6 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 a specific Usage
6.6.1 Setting Profile Options Following are the profile options that are used during the publishing process:
Publishing Configuration Models 6-13 Publishing and Effectivity
■ CZ:Publication Mode
■ CZ:Publication Usage For more information about these profile options, see the Oracle Configurator Installation Guide. For information about setting profile options, see the Oracle Applications System Administrator’s Guide.
6.7 Publishing and Effectivity See Section 6.2.2.3, "Date Range" on page 6-8.
6.8 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.9 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, rules, or user interface definition. If the rules or user interface are 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_ 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.
6-14 Oracle Configurator Implementation Guide Disabling, Deleting, and Re-enabling Publications
4. When one of the publication concurrent processes is run that includes the updated publication, a copy of the updated Model is created and exported to the target instance in the same manner as a new publication. 5. Publication records for the original publication (old) are deleted.
6.9.1 Determining Publishing Information Using the PUBLICATION_ID from Oracle Configurator Developer’s publishing window in a simple SQL*Plus query returns the UI_DEF_ID. Knowing the UI_DEF_ ID can be helpful in determining publishing information. UI_DEF_ID can then be used in queries on the CZ_CONFIG_HDRS, CZ_MODEL_PUBLICATIONS, CZ_UI_ DEFS, CZ_UI_NODES, CZ_UI_NODE_PROPS, CZ_UI_PROPERTIES. SQL> select ui_def_id 2 from cz_model_publications 3 where publication_id=publication number ; UI_DEF_ID 2760
UI_DEF_ID can also be obtained by CZ_CF_API.UI_FOR_ITEM.
6.10 Editing Publications It is not necessary to re-export a publication after changing a 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.11 Disabling, Deleting, and Re-enabling Publications Publications can be marked as Disabled, which signals the runtime 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. You can also delete a publication. After deletion, the publication is not visible and cannot be recovered.
Publishing Configuration Models 6-15 Lost Publications Due to Database Instance Failure
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.12 Lost Publications Due to Database Instance Failure When a configuration model is published, the concurrent program exports a copy of the configuration model’s data and a copy of the publication record in CZ_ MODEL_PUBLICATIONS. If the export is to a different database, and the source database fails, you may only have the publication copy available. When this happens, you should synchronize the configured model and BOMs. See Section 1.9.1.6, "Checking BOM and Model Similarity" on page 1-24. If one of the instances you are working with fails, you must follow the relevant restoration process as described in the following sections.
6.12.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.12.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 edit configuration models to synchronize them with their publications on the target database.
6-16 Oracle Configurator Implementation Guide 7 Programmatic Tools for Development
This chapter describes programmatic tools that you can use primarily to develop a configuration model and deploy a runtime Oracle Configurator. For information on tools for maintaining a deployed runtime Oracle Configurator, see Chapter 8, "Programmatic Tools for Maintenance".
7.1 Overview of the CZ_CF_API Package
7.1.1 Purpose of the Package
7.1.2 Overview of Procedures and Functions Table 7–1, " Overview of Procedures and Functions in the Package CZ_CF_API" on page 7-1 summarizes and categorizes the procedures and functions available in the package CZ_CF_API. These procedures and functions are described in individual detail in Section 7.3, "Reference for the CZ_CF_API Package" on page 7-11.
Table 7–1 Overview of Procedures and Functions in the Package CZ_CF_API Category API Name P/F1 Working with COMMON_BILL_FOR_ITEM P Common Bills See Section 7.2.5.
Programmatic Tools for Development 7-1 Overview of the CZ_CF_API Package
Table 7–1 (Cont.) Overview of Procedures and Functions in the Package CZ_CF_API Category API Name P/F1 Copying and Deleting COPY_CONFIGURATION P Configurations See Section 7.2.4. COPY_CONFIGURATION_AUTO P DELETE_CONFIGURATION P Setting Configuration DEFAULT_NEW_CFG_DATES P Dates See Section 7.2.2. DEFAULT_RESTORED_CFG_DATES P Establishing Session ICX_SESSION_TICKET F Identity See Section 7.2.1. Identifying CONFIG_MODEL_FOR_ITEM F Publications See Section 7.2.6. CONFIG_MODEL_FOR_PRODUCT F CONFIG_MODELS_FOR_ITEMS F CONFIG_MODELS_FOR_PRODUCTS F CONFIG_UI_FOR_ITEM F CONFIG_UI_FOR_ITEM_LF F CONFIG_UI_FOR_PRODUCT F CONFIG_UIS_FOR_ITEMS F CONFIG_UIS_FOR_PRODUCTS F MODEL_FOR_ITEM F MODEL_FOR_PUBLICATION_ID F PUBLICATION_FOR_ITEM F PUBLICATION_FOR_PRODUCT F PUBLICATION_FOR_SAVED_CONFIG F UI_FOR_ITEM F UI_FOR_PUBLICATION_ID F
7-2 Oracle Configurator Implementation Guide Overview of the CZ_CF_API Package
Table 7–1 (Cont.) Overview of Procedures and Functions in the Package CZ_CF_API Category API Name P/F1 Validating VALIDATE P Configurations See Section 7.2.3. 1 P = procedure, F = function
7.1.3 Installation of the Package This package is installed in the Oracle Applications database as part of Oracle Configurator.
■ If you installed a new instance of Oracle Applications, then this package was installed by using Oracle Rapid Install.
■ If you installed Oracle Configurator in an existing instance of Oracle Applications, then this package was installed by applying the appropriate Oracle Configurator patch. See the Oracle Configurator Installation Guide for details about installing Oracle Configurator.
7.1.4 References for Working with PL/SQL Procedures and Functions For background information and details on basic aspects of working with the PL/SQL procedures and functions in this package, see Table 7–2, " References for Working with PL/SQL Procedures and Functions", which suggests relevant topics in the Oracle Documentation Library.
Table 7–2 References for Working with PL/SQL Procedures and Functions See this topic ... In this reference document ... User-defined data types Oracle8i Concepts Procedures and packages Using procedures and packages Oracle8i Application Developer's Guide - Fundamentals Calling stored procedures Understanding the Oracle programmatic environments
Programmatic Tools for Development 7-3 Choosing the Right Tool for the Job
Table 7–2 (Cont.) References for Working with PL/SQL Procedures and Functions See this topic ... In this reference document ... Language elements PL/SQL User's Guide and Reference Packages Index-by tables Collections and records User-defined subtypes Using SQL*Plus SQL*Plus User's Guide and Reference UTL_HTTP Oracle8i Supplied PL/SQL Packages Reference
7.2 Choosing the Right Tool for the Job These procedures and functions are described in detail in Section 7.3, "Reference for the CZ_CF_API Package" on page 7-11.
7.2.1 Establishing Session Identity Use the following function to establish the identity of a Oracle Applications database session:
■ ICX_SESSION_TICKET
7.2.2 Setting Configuration Dates Use these procedures to determine the dates that would be used for configurations:
■ DEFAULT_NEW_CFG_DATES
■ DEFAULT_RESTORED_CFG_DATES
7.2.3 Validating Configurations Use this procedure to validate a configuration:
■ VALIDATE
7.2.4 Copying and Deleting Configurations Use these procedures to copy and delete configurations:
7-4 Oracle Configurator Implementation Guide Choosing the Right Tool for the Job
■ COPY_CONFIGURATION
■ COPY_CONFIGURATION_AUTO
■ DELETE_CONFIGURATION
7.2.5 Working with Common Bills Use this procedure to retrieve a common bill:
■ COMMON_BILL_FOR_ITEM
7.2.6 Identifying Publications After publishing Models, you can verify whether a publication lookup will succeed for a given set of applicability parameters. See Section 7.2.6.2 on page 7-6 for details about specifying applicability parameters.
7.2.6.1 Functions for Identifying Publications Use these functions to look up publications for a given set of applicability parameters:
■ CONFIG_MODEL_FOR_ITEM
■ CONFIG_MODEL_FOR_PRODUCT
■ CONFIG_MODELS_FOR_ITEMS
■ CONFIG_MODELS_FOR_PRODUCTS
■ CONFIG_UI_FOR_ITEM
■ CONFIG_UI_FOR_ITEM_LF
■ CONFIG_UI_FOR_PRODUCT
■ CONFIG_UIS_FOR_ITEMS
■ CONFIG_UIS_FOR_PRODUCTS
■ MODEL_FOR_ITEM
■ MODEL_FOR_PUBLICATION_ID
■ PUBLICATION_FOR_ITEM
■ PUBLICATION_FOR_PRODUCT
■ PUBLICATION_FOR_SAVED_CONFIG
Programmatic Tools for Development 7-5 Choosing the Right Tool for the Job
■ UI_FOR_ITEM
■ UI_FOR_PUBLICATION_ID
7.2.6.2 Applicability Parameters Applicability parameters control the availability of a publication in your development or production environment You can use applicability parameters in Oracle Configurator Developer (OCD) to determine which Model and UI to display when you publish a Model. See the Oracle Configurator Developer User’s Guide for more information about applicability parameters and publishing. You can also use applicability parameters in the initialization message that a host application sends to the Oracle Configurator Servlet. See the Oracle Configurator Custom Web Deployment Guide for more information. Table 7–3 on page 7-6 lists the applicability parameters that many of the functions and procedures in this package use to search for Models, UIs, and publications.
Table 7–3 Applicability Parameters for Publication Searches Parameter in this Data Parameter in package type OCD1 Description calling_application_id number Applications The registered ID of an application for which the Model is published. This is a valid APPLICATION_ID from FND_ APPLICATION. Example value: 660 config_lookup_date date Date (Valid Provide a date that falls inside the From, Valid applicable range for the publication. Use To) the standard Oracle TO_DATE function to format the date. language varchar2 Languages Language code for an installed language (such as ’US’). CZ_PB_LANGUAGES is accessed to identify the publication assigned to the specified language. The default is NULL. If the parameter is NULL, then userenv("LANG") determines the language. Example value: 'US'
7-6 Oracle Configurator Implementation Guide Choosing the Right Tool for the Job
Table 7–3 (Cont.) Applicability Parameters for Publication Searches Parameter in this Data Parameter in package type OCD1 Description product_key varchar2 Product ID For imported models, the product_key is the ORGANIZATION_ID concatenated with the INVENTORY_ITEM_ID, in MTL_SYSTEMS_ITEMS. For Models created in Oracle Configurator Developer, the Product ID is generated from the name of the Model when you publish the Model. Example value (for an imported Model): 204:2510 publication_mode varchar2 Mode The publication mode for the publication. Values are ’P’ (production) or ’T’ (test). The default is NULL. If NULL, then the CZ:Publication Mode profile option value is checked. Example value: 'T' usage_name varchar2 Usages Name of a Usage defined in Oracle Configurator Developer. If this is NULL, then the CZ:Usage Name profile option value is checked. Example value: 'my usage' 1 These names are for fields in the Model Publishing window of Oracle Configurator Developer.
7.2.6.3 List Parameters In order to reduce the number of function calls when an application needs to find Models for multiple products or items, some functions in this package take parameters that are lists of values, and return a list of values (as identified in the syntax for the function). To pass a list of values, this package defines several custom data types that are collections, also known as index-by tables:
■ date_tbl_type
■ number_tbl_type
■ varchar2_tbl_type Parameters in this package that are of one of these list types do not default to NULL.
Programmatic Tools for Development 7-7 Reference for the CZ_CF_API Package
See Section 7.3.1, "Custom Data Types" on page 7-8 for the definition of these types.
7.3 Reference for the CZ_CF_API Package
■ This section provides descriptions of each of the procedures and functions in the CZ_CF_API package. These procedures and functions are listed alphabetically in Table 7–5, " Procedures and Functions in the Package CZ_CF_ API" on page 7-9
■ Descriptions of the custom data types defined in the package are provided in Section 7.3.1, "Custom Data Types" on page 7-8.
■ For a basic example of how to call one of the functions in the CZ_CF_API package, see Example 7–1, "Using the UI_FOR_PUBLICATION_ID Function" on page 7-55.
■ See also Section 7.1, "Overview of the CZ_CF_API Package" on page 7-1.
7.3.1 Custom Data Types Table 7–4, " Custom Data Types in the Package CZ_CF_API" describes the custom data types that are defined in this package.
■ For background on the record data type, see the references for collections and records.
■ For background on the table data type, see the references for collections.
■ For background on subtypes, see the references for user-defined subtypes.
■ For background on the UTL_HTTP package, see the references for UTL_HTTP. For background on these custom data types, see the references under Section 7.1.4, "References for Working with PL/SQL Procedures and Functions" on page 7-3:
Table 7–4 Custom Data Types in the Package CZ_CF_API Custom Type Description INPUT_SELECTION Record consisting of: COMPONENT_CODE VARCHAR2(1200) QUANTITY NUMBER INPUT_SEQ NUMBER CONFIG_ITEM_ID DEFAULT NULL
7-8 Oracle Configurator Implementation Guide Reference for the CZ_CF_API Package
Table 7–4 (Cont.) Custom Data Types in the Package CZ_CF_API Custom Type Description CFG_INPUT_LIST Table of INPUT_SELECTION indexed by BINARY_INTEGER CFG_OUTPUT_PIECES This is a result of the batch validation message. Subtype of UTL_HTTP.HTML_PIECES. It is a table of VARCHAR2(2000). NUMBER_TBL_TYPE Table of NUMBER DATE_TBL_TYPE Table of DATE VARCHAR2_TBL_TYPE Table of VARCHAR2(255)
7.3.2 Procedures and Functions in the CZ_CF_API Package This section provides descriptions of each of the procedures and functions in the CZ_CF_API package, arranged alphabetically. These procedures and functions are listed alphabetically in Table 7–5, " Procedures and Functions in the Package CZ_ CF_API".
Table 7–5 Procedures and Functions in the Package CZ_CF_API API Name P/F1 COMMON_BILL_FOR_ITEM on page 7-11 P CONFIG_MODEL_FOR_ITEM on page 7-13 F CONFIG_MODEL_FOR_PRODUCT on page 7-17 F CONFIG_MODELS_FOR_ITEMS on page 7-15 F CONFIG_MODELS_FOR_PRODUCTS on page 7-19 F CONFIG_UI_FOR_ITEM on page 7-21 F CONFIG_UI_FOR_ITEM_LF on page 7-24 F CONFIG_UI_FOR_PRODUCT on page 7-27 F CONFIG_UIS_FOR_ITEMS on page 7-29 F CONFIG_UIS_FOR_PRODUCTS on page 7-31 F COPY_CONFIGURATION on page 7-33 P COPY_CONFIGURATION_AUTO on page 7-35 P DEFAULT_NEW_CFG_DATES on page 7-37 P DEFAULT_RESTORED_CFG_DATES on page 7-39 P
Programmatic Tools for Development 7-9 Reference for the CZ_CF_API Package
Table 7–5 (Cont.) Procedures and Functions in the Package CZ_CF_API API Name P/F1 DELETE_CONFIGURATION on page 7-41 P ICX_SESSION_TICKET on page 7-43 F MODEL_FOR_ITEM on page 7-44 F MODEL_FOR_PUBLICATION_ID on page 7-46 F PUBLICATION_FOR_ITEM on page 7-47 F PUBLICATION_FOR_PRODUCT on page 7-49 F PUBLICATION_FOR_SAVED_CONFIG on page 7-51 F UI_FOR_ITEM on page 7-53 F UI_FOR_PUBLICATION_ID on page 7-55 F VALIDATE on page 7-57 P 1 P = procedure, F = function
7-10 Oracle Configurator Implementation Guide COMMON_BILL_FOR_ITEM
COMMON_BILL_FOR_ITEM
Considerations Before Running
Purpose Retrieves the common bill item, if any, for the organization ID and inventory item ID that are passed in as parameters. This procedure is used by the PUBLICATION_FOR_ITEM function to retrieve the common bill's details if the Model has not been published.
Prerequisites None.
Timing Intended as a utility method during development.
Dependencies None.
Restrictions and Limitations None.
Warnings None.
Syntax and Parameters The syntax for this procedure is: PROCEDURE common_bill_for_item ( in_inventory_item_id IN NUMBER, in_organization_id IN NUMBER, common_inventory_item_id OUT NUMBER, common_organization_id OUT NUMBER);
Table 7–6 on page 7-12 describes the parameters for the COMMON_BILL_FOR_ ITEM procedure.
Programmatic Tools for Development 7-11 COMMON_BILL_FOR_ITEM
Table 7–6 Parameters for the COMMON_BILL_FOR_ITEM Procedure Parameter Data Type Mode Note in_inventory_item_id number in Inventory Item ID of item for which common bill may be defined. in_organization_id number in Organization ID of Item for which common bill may be defined. common_inventory_item_id number out Inventory Item ID of the common bill item. NULL if no common bill defined. common_organization_id number out Organization ID of the common bill Item. NULL if no common bill defined.
7-12 Oracle Configurator Implementation Guide CONFIG_MODEL_FOR_ITEM
CONFIG_MODEL_FOR_ITEM
Considerations Before Running
Purpose This function finds a published configuration model for an item, and other applicability parameters. Returns NULL if the Model cannot be found.
Timing This function should be used after publishing Models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any Usage" and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION config_model_for_item (inventory_item_id IN NUMBER, organization_id IN NUMBER, config_lookup_date IN DATE, calling_application_id IN NUMBER, usage_name IN VARCHAR2, publication_mode IN VARCHAR2 DEFAULT NULL, language IN VARCHAR2 DEFAULT NULL) RETURN NUMBER;
Table 7–7 on page 7-14 describes the parameters for the CONFIG_MODEL_FOR_ ITEM function.
Programmatic Tools for Development 7-13 CONFIG_MODEL_FOR_ITEM
Table 7–7 Parameters for the CONFIG_MODEL_FOR_ITEM Function Data Parameter Type Mode Note inventory_item_id number in If the Model was imported from Oracle BOM, this is the Inventory Item ID for the published Model, from the MTL_SYSTEM_ITEMS table, on which configuration models are based. organization_id number in If the Model was imported from Oracle BOM, this is the organization ID for the published Model, from the MTL_SYSTEM_ITEMS table, on which configuration models are based. config_lookup_date date in Date to search for inside the applicable range for the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. calling_application_id number in The registered ID of an application for which the Model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. usage_name varchar2 in Usage name to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. publication_mode varchar2 in Publication mode to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. language varchar2 in Language code to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
Considerations After Running
Results This function returns the devl_project_id of the configuration model published for this combination of inputs. NULL is returned if there is no matching publication.
7-14 Oracle Configurator Implementation Guide CONFIG_MODELS_FOR_ITEMS
CONFIG_MODELS_FOR_ITEMS
Considerations Before Running
Purpose This function finds the Models that are associated with each entry in a list of Inventory Items that are published with the matching applicability parameters. The function returns the list of Model IDs (devl_project_id values) that meet the specified parameters.
Timing This function should be used after publishing Models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, the CZ:Usage Name and/or CZ: Publication Mode profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any Usage" and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION config_models_for_items (inventory_item_id IN NUMBER_TBL_TYPE, organization_id IN NUMBER_TBL_TYPE, config_lookup_date IN DATE_TBL_TYPE, calling_application_id IN NUMBER_TBL_TYPE, usage_name IN VARCHAR2_TBL_TYPE, publication_mode IN VARCHAR2_TBL_TYPE, language IN VARCHAR2_TBL_TYPE) RETURN NUMBER_TBL_TYPE;
Table 7–8 on page 7-16 describes the parameters for the CONFIG_MODELS_FOR_ ITEMS function.
Programmatic Tools for Development 7-15 CONFIG_MODELS_FOR_ITEMS
Table 7–8 Parameters for the CONFIG_MODELS_FOR_ITEMS Function Parameter Data Type Mode Note inventory_item_id number_tbl_type in If the Model was imported from Oracle BOM, this is a list of Inventory Item IDs for the published Model from the MTL_ SYSTEM_ITEMS table, on which configuration models are based. organization_id number_tbl_type in If the Model was imported from Oracle BOM, this is a list of organization IDs for the published Model from the MTL_ SYSTEM_ITEMS table, on which configuration models are based. config_lookup_date date_tbl_type in List of dates to search for inside the applicable range for the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. calling_application_id number_tbl_type in List of registered IDs of applications for which the Model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. usage_name varchar2_tbl_type in List of Usage names to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. publication_mode varchar2_tbl_type in List of publication modes to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. language varchar2_tbl_type in List of language codes to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
Considerations After Running
Results This function returns an array in which each element is a devl_project_id value for the associated item. NULL is returned if there is no matching publication.
7-16 Oracle Configurator Implementation Guide CONFIG_MODEL_FOR_PRODUCT
CONFIG_MODEL_FOR_PRODUCT
Considerations Before Running
Purpose This function finds a published configuration model for a product key and other applicability parameters. Returns NULL if the Model cannot be found.
Timing This function should be used after publishing Models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, the CZ:Usage Name and/or CZ: Publication Mode profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any Usage" and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION config_model_for_product (product_key IN VARCHAR2, config_lookup_date IN DATE, calling_application_id IN NUMBER, usage_name IN VARCHAR2, publication_mode IN VARCHAR2 DEFAULT NULL, language IN VARCHAR2 DEFAULT NULL) RETURN NUMBER;
Table 7–9 on page 7-18 describes the parameters for the CONFIG_MODEL_FOR_ PRODUCT function.
Programmatic Tools for Development 7-17 CONFIG_MODEL_FOR_PRODUCT
Table 7–9 Parameters for the CONFIG_MODEL_FOR_PRODUCT Function Parameter Data Type Mode Note product_key varchar2 in Product key to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. config_lookup_date date in Date to search for inside the applicable range for the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. calling_application_id number in The registered ID of an application for which the Model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. usage_name varchar2 in Usage name to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. publication_mode varchar2 in Publication mode to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. language varchar2 in Language code to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
Considerations After Running
Results This function returns the devl_project_id of the configuration model published for this combination of inputs. NULL is returned if there is no matching publication.
7-18 Oracle Configurator Implementation Guide CONFIG_MODELS_FOR_PRODUCTS
CONFIG_MODELS_FOR_PRODUCTS
Considerations Before Running
Purpose This function returns a list of Model IDs (devl_project_id values) associated with each entry in a list of product keys that are published with matching applicability parameters.
Timing This function should be used after publishing Models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, the CZ:Usage Name and/or CZ: Publication Mode profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any + and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION config_models_for_products ( product_key IN VARCHAR2_TBL_TYPE, config_lookup_date IN DATE_TBL_TYPE, calling_application_id IN NUMBER_TBL_TYPE, usage_name IN VARCHAR2_TBL_TYPE, publication_mode IN VARCHAR2_TBL_TYPE, language IN VARCHAR2_TBL_TYPE) RETURN NUMBER_TBL_TYPE;
Table 7–10, " Parameters for the CONFIG_MODELS_FOR_PRODUCTS Function" on page 7-20 describes the parameters for the CONFIG_MODELS_FOR_ PRODUCTS function.
Programmatic Tools for Development 7-19 CONFIG_MODELS_FOR_PRODUCTS
Table 7–10 Parameters for the CONFIG_MODELS_FOR_PRODUCTS Function Parameter Data Type Mode Note product_key varchar2_tbl_type in List of product keys to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. config_lookup_date date_tbl_type in List of dates to search for inside the applicable range for the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. calling_application_id number_tbl_type in List of registered IDs of applications for which the Model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. usage_name varchar2_tbl_type in List of Usage names to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. publication_mode varchar2_tbl_type in List of publication modes to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. language varchar2_tbl_type in List of language codes to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
Considerations After Running
Results This function returns a list of Model IDs (devl_project_id values) associated with each entry in a list of product keys that are published with matching applicability parameters.
7-20 Oracle Configurator Implementation Guide CONFIG_UI_FOR_ITEM
CONFIG_UI_FOR_ITEM
Considerations Before Running
Purpose This function returns the user interface ID associated with the publication found for the input item, organization ID, and applicability.
Timing This function should be used after publishing Models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, the CZ:Usage Name and/or CZ: Publication Mode profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any Usage" and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION config_ui_for_item (inventory_item_id IN NUMBER, organization_id IN NUMBER, config_lookup_date IN DATE, ui_type IN OUT VARCHAR2, calling_application_id IN NUMBER, usage_name IN VARCHAR2, publication_mode IN VARCHAR2 DEFAULT NULL, language IN VARCHAR2 DEFAULT NULL) RETURN NUMBER;
Table 7–11 on page 7-22 describes the parameters for the CONFIG_UI_FOR_ITEM function.
Programmatic Tools for Development 7-21 CONFIG_UI_FOR_ITEM
Table 7–11 Parameters for the CONFIG_UI_FOR_ITEM Function Parameter Data Type Mode Note inventory_item_id number in If the Model was imported from Oracle BOM, this is the Inventory Item ID for the published Model, from the MTL_ SYSTEM_ITEMS table, on which configuration models are based. organization_id number in If the Model was imported from Oracle BOM, this is the organization ID for the published Model, from the MTL_ SYSTEM_ITEMS table, on which configuration models are based. config_lookup_date date in Date to search for inside the applicable range for the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. ui_type varchar2 in/out This is the type of UI sought and found for each product. Values are ’APPLET’ or ’DHTML’. calling_application_id number in The registered ID of an application for which the Model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. usage_name varchar2 in Usage name to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. publication_mode varchar2 in Publication mode to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. language varchar2 in Language code to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
7-22 Oracle Configurator Implementation Guide CONFIG_UI_FOR_ITEM
Considerations After Running
Results This function returns the user interface ID associated with the selected publication.
Programmatic Tools for Development 7-23 CONFIG_UI_FOR_ITEM_LF
CONFIG_UI_FOR_ITEM_LF
Considerations Before Running
Purpose This function does the same work as CONFIG_UI_FOR_ITEM, but also returns the look_and_feel of the UI (’APPLET’, ’BLAF’, or ’FORMS’).
Timing This function should be used after publishing Models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, CZ:Usage Name and/or CZ: Publication Mode profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any Usage" and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION config_ui_for_item_lf ( inventory_item_id IN NUMBER, organization_id IN NUMBER, config_lookup_date IN DATE, ui_type IN OUT VARCHAR2, calling_application_id IN NUMBER, usage_name IN VARCHAR2, look_and_feel OUT VARCHAR2, publication_mode IN VARCHAR2 DEFAULT NULL, language IN VARCHAR2 DEFAULT NULL) RETURN NUMBER;
Table 7–12 on page 7-25 describes the parameters for the CONFIG_UI_FOR_ITEM_ LF function.
7-24 Oracle Configurator Implementation Guide CONFIG_UI_FOR_ITEM_LF
Table 7–12 Parameters for the CONFIG_UI_FOR_ITEM_LF Function Parameter Data Type Mode Note inventory_item_id number in If the Model was imported from Oracle BOM, this is the Inventory Item ID for the published Model, from the MTL_ SYSTEM_ITEMS table, on which configuration models are based. organization_id number in If the Model was imported from Oracle BOM, this is the organization ID for the published Model, from the MTL_ SYSTEM_ITEMS table, on which configuration models are based. config_lookup_date date in Date to search for inside the applicable range for the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. ui_type varchar2 in/out This is the type of UI sought and found for each product. Values are ’APPLET’ or ’DHTML’. calling_application_id number in The registered ID of an application for which the Model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. usage_name varchar2 in Usage name to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. look_and_feel varchar2 out This is a tag that overrides the default look and feel for component-style UIs (when UI_STYLE=0) in the CZ_UI_ DEFS table. publication_mode varchar2 in Publication mode to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
Programmatic Tools for Development 7-25 CONFIG_UI_FOR_ITEM_LF
Table 7–12 (Cont.) Parameters for the CONFIG_UI_FOR_ITEM_LF Function Parameter Data Type Mode Note language varchar2 in Language code to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
Considerations After Running
Results This function returns the user interface ID of the selected publication.
7-26 Oracle Configurator Implementation Guide CONFIG_UI_FOR_PRODUCT
CONFIG_UI_FOR_PRODUCT
Considerations Before Running
Purpose This function finds UI for a product, returns null if no UI can be found. If ui_type is passed in, the function will validate the UI it finds against this type. If the types do not match, no UI will be returned. If no ui_type is passed, the type of the UI will be returned in ui_type.
Timing This function should be used after publishing Models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, the CZ:Usage Name and/or CZ: Publication Mode profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any Usage" and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION config_ui_for_product ( product_key IN VARCHAR2, config_lookup_date IN DATE, ui_type IN OUT VARCHAR2, calling_application_id IN NUMBER, usage_name IN VARCHAR2, publication_mode IN VARCHAR2 DEFAULT NULL, language IN VARCHAR2 DEFAULT NULL) RETURN NUMBER;
Table 7–13, " Parameters for the CONFIG_UI_FOR_PRODUCT Function" describes the parameters for the CONFIG_UI_FOR_PRODUCT function.
Programmatic Tools for Development 7-27 CONFIG_UI_FOR_PRODUCT
Table 7–13 Parameters for the CONFIG_UI_FOR_PRODUCT Function Parameter Data Type Mode Note product_key varchar2 in Product key to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. config_lookup_date date in Date to search for inside the applicable range for the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. ui_type varchar2 in/out This is the type of UI sought and found for each product. Values are ’APPLET’ or ’DHTML’. calling_application_id number in The registered ID of an application for which the Model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. usage_name varchar2 in Usage name to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. publication_mode varchar2 in Publication mode to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. language varchar2 in Language code to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
Considerations After Running
Results This function finds UI for a product, returns null if no UI can be found. If ui_type is passed in, the function will validate the UI it finds against this type. If the types do not match, no UI will be returned. If no ui_type is passed, the type of the UI will be returned in ui_type
7-28 Oracle Configurator Implementation Guide CONFIG_UIS_FOR_ITEMS
CONFIG_UIS_FOR_ITEMS
Considerations Before Running
Purpose This function returns a list of user interfaces that are associated with each entry in the list of Inventory Items that are published with matching applicability parameters.
Timing This function should be used after publishing Models to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, the CZ:Usage Name and/or CZ: Publication Mode profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any Usage" and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION config_uis_for_items ( inventory_item_id IN NUMBER_TBL_TYPE, organization_id IN NUMBER_TBL_TYPE, config_lookup_date IN DATE_TBL_TYPE, ui_type IN OUT VARCHAR2_TBL_TYPE, calling_application_id IN NUMBER_TBL_TYPE, usage_name IN VARCHAR2_TBL_TYPE, publication_mode IN VARCHAR2_TBL_TYPE, language IN VARCHAR2_TBL_TYPE ) RETURN NUMBER_TBL_TYPE;
Table 7–14, " Parameters for the CONFIG_UIS_FOR_ITEMS Function" describes the parameters for the CONFIG_UIS_FOR_ITEMS function.
Programmatic Tools for Development 7-29 CONFIG_UIS_FOR_ITEMS
Table 7–14 Parameters for the CONFIG_UIS_FOR_ITEMS Function Parameter Data Type Mode Note inventory_item_id number_tbl_type in If the Model was imported from Oracle BOM, this is a list of Inventory Item IDs for the published Model from the MTL_SYSTEM_ITEMS table, on which configuration models are based. organization_id number_tbl_type in If the Model was imported from Oracle BOM, this is a list of organization IDs for the published Model from the MTL_SYSTEM_ITEMS table, on which configuration models are based. config_lookup_date date_tbl_type in List of dates to search for inside the applicable range for the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. ui_type varchar2_tbl_type in/ out List of the types of UIs sought and found for each product. Values are ’APPLET’ or ’DHTML’. calling_application_id number_tbl_type in List of registered IDs of applications for which the Model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. usage_name varchar2_tbl_type in List of Usage names to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. publication_mode varchar2_tbl_type in List of publication modes to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. language varchar2_tbl_type in Language code to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
7-30 Oracle Configurator Implementation Guide CONFIG_UIS_FOR_PRODUCTS
CONFIG_UIS_FOR_PRODUCTS
Considerations Before Running
Purpose This function returns a list of user interfaces that are associated with each entry in the list of product keys that are published with matching applicability parameters.
Timing This function should be used after publishing Models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, the CZ:Usage Name and/or CZ: Publication Mode profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any Usage" and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION config_uis_for_products ( product_key IN VARCHAR2_TBL_TYPE, config_lookup_date IN DATE_TBL_TYPE, ui_type IN OUT VARCHAR2_TBL_TYPE, calling_application_id IN NUMBER_TBL_TYPE, usage_name IN VARCHAR2_TBL_TYPE, publication_mode IN VARCHAR2_TBL_TYPE, language IN VARCHAR2_TBL_TYPE ) RETURN NUMBER_TBL_TYPE;
Table 7–15, " Parameters for the CONFIG_UIS_FOR_PRODUCTS Function" describes the parameters for the CONFIG_UIS_FOR_PRODUCTS function.
Programmatic Tools for Development 7-31 CONFIG_UIS_FOR_PRODUCTS
Table 7–15 Parameters for the CONFIG_UIS_FOR_PRODUCTS Function Parameter Data Type Mode Note product_key varchar2_tbl_type, in List of product keys to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. config_lookup_date date_tbl_type, in List of dates to search for inside the applicable range for the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. ui_type varchar2_tbl_type, in/out List of the types of UIs sought and found for each product. Values are ’APPLET’ or ’DHTML’. calling_application_id number_tbl_type, in List of registered IDs of applications for which the Model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. usage_name varchar2_tbl_type, in List of Usage names to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. publication_mode varchar2_tbl_type, in List of publication modes to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. language varchar2_tbl_type in List of language codes to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
7-32 Oracle Configurator Implementation Guide COPY_CONFIGURATION
COPY_CONFIGURATION
Considerations Before Running
Purpose This procedure copies a configuration in the database. If the NEW_CONFIG_FLAG is 1, then a new CONFIG_HDR_ID value is generated for the new configuration and it is REV_NBR 1. If NEW_CONFIG_FLAG is 0, the copy keeps the CONFIG_ HDR_ID and has a REV_NBR incremented to be greater than the original.
Prerequisites The configuration to be copied must exist.
Timing This procedure should be used every time a configuration is copied. The procedure will ensure that all inputs, outputs, and messages are copied.
Warnings If the configuration does not exist, or if the copy fails, return_value will be zero, and error_message will contain error information.
Syntax and Parameters The syntax for this procedure is: PROCEDURE copy_configuration( config_hdr_id IN NUMBER, config_rev_nbr IN NUMBER, new_config_flag IN VARCHAR2, out_config_hdr_id IN OUT NUMBER, out_config_rev_nbr IN OUT NUMBER, Error_message IN OUT VARCHAR2, Return_value IN OUT NUMBER, handle_deleted_flag IN VARCHAR2 DEFAULT NULL, new_name IN VARCHAR2 DEFAULT NULL);
Table 7–16 on page 7-34 describes the parameters for the COPY_CONFIGURATION procedure.
Programmatic Tools for Development 7-33 COPY_CONFIGURATION
Table 7–16 Parameters for the COPY_CONFIGURATION Procedure Parameter Data Type Mode Note config_hdr_id number in Specifies which configuration to copy. Uses CZ_CONFIG_HDRS, CZ_CONFIG_ INPUTS, CZ_CONFIG_ITEMS, and CZ_ CONFIG_MESSAGES. config_rev_nbr number in Specifies which configuration to copy. Uses CZ_CONFIG_HDRS, CZ_CONFIG_ INPUTS, CZ_CONFIG_ITEMS, and CZ_ CONFIG_MESSAGES. new_config_flag varchar2 in A ’1' indicates that the copied configuration should have a new CONFIG_HDR_ID. A '0' indicates that the copied configuration should have the same CONFIG_HDR_ID and a unique CONFIG_REV_NBR. For example it is a revision of the existing configuration. out_config_hdr_id number in/out Identifies the new copy of the configuration. out_config_rev_nbr number in/out Identifies the new copy of the configuration. error_message varchar2 in/out Contains an error message if an error occurs. return_value number in/out Indicates the success (1) or failure (0) of the copy. handle_deleted_flag varchar2 in When ’0’, it will indelete the copied configuration if the original configuration is deleted. new_name varchar2 in Applies a new name for the configuration
Considerations After Running
Results This procedure copies all database records associated with a configuration to a new config_hdr_id and config_rev_nbr.
Troubleshooting Examine return_value and error_message to determine what the next step should be.
7-34 Oracle Configurator Implementation Guide COPY_CONFIGURATION_AUTO
COPY_CONFIGURATION_AUTO
Considerations Before Running
Purpose This procedure runs COPY_CONFIGURATION within an autonomous transaction. If the copy is successful, new data will be committed to the database without affecting the caller’s transaction. See other information for "COPY_CONFIGURATION" on page 7-33.
Prerequisites The configuration to be copied must exist.
Timing This procedure should be used every time a configuration is copied. The procedure will ensure that all inputs, outputs, and messages are copied.
Warnings If configuration does not exist, or if the copy fails, return_value will be zero, and error_message will contain error information.
Syntax and Parameters The syntax for this procedure is: PROCEDURE copy_configuration_auto(config_hdr_id IN NUMBER, config_rev_nbr IN NUMBER, new_config_flag IN VARCHAR2, out_config_hdr_id IN OUT NUMBER, out_config_rev_nbr IN OUT NUMBER, Error_message IN OUT VARCHAR2, Return_value IN OUT NUMBER, handle_deleted_flag IN VARCHAR2 DEFAULT NULL, new_name IN VARCHAR2 DEFAULT NULL);
Table 7–17 on page 7-36 describes the parameters for the COPY_ CONFIGURATION_AUTO procedure.
Programmatic Tools for Development 7-35 COPY_CONFIGURATION_AUTO
Table 7–17 Parameters for the COPY_CONFIGURATION_AUTO Procedure Parameter Data Type Mode Note config_hdr_id number in See corresponding parameter in Table 7–16 on page 7-34. config_rev_nbr number in See corresponding parameter in Table 7–16 on page 7-34. new_config_flag varchar2 in See corresponding parameter in Table 7–16 on page 7-34. out_config_hdr_id number in/out See corresponding parameter in Table 7–16 on page 7-34. out_config_rev_nbr number in/out See corresponding parameter in Table 7–16 on page 7-34. error_message varchar2 in/out See corresponding parameter in Table 7–16 on page 7-34. return_value number in/out See corresponding parameter in Table 7–16 on page 7-34. handle_deleted_flag varchar2 default null in See corresponding parameter in Table 7–16 on page 7-34. new_name varchar2 default null in See corresponding parameter in Table 7–16 on page 7-34.
Considerations After Running
Results This procedure copies all database records associated with a configuration to a new config_hdr_id and config_rev_nbr.
Troubleshooting Examine return_value and error_message to determine what the next step should be.
7-36 Oracle Configurator Implementation Guide DEFAULT_NEW_CFG_DATES
DEFAULT_NEW_CFG_DATES
Considerations Before Running
Purpose This utility procedure provides default date values used by Oracle Configurator for a new configuration. The caller should pass in dates that will be included in the initialization message for the runtime Oracle Configurator. The procedure will return the value that will be used by the runtime Oracle Configurator for any dates not passed in.
Prerequisites None.
Timing This procedure should be used if the developer wants to find out the default dates used by the runtime Oracle Configurator for publication lookup, effectivity, and configuration creation.
Dependencies None.
Restrictions and Limitations None.
Syntax and Parameters The syntax for this procedure is: PROCEDURE DEFAULT_NEW_CFG_DATES( p_creation_date IN OUT DATE, p_lookup_date IN OUT DATE, p_effective_date IN OUT DATE);
Table 7–18, " Parameters for the DEFAULT_NEW_CFG_DATES Procedure" describes the parameters for the DEFAULT_NEW_CFG_DATES procedure.
Table 7–18 Parameters for the DEFAULT_NEW_CFG_DATES Procedure Parameter Data Type Mode Note p_creation_date date in/out This specifies the creation date for the new configuration.
Programmatic Tools for Development 7-37 DEFAULT_NEW_CFG_DATES
Table 7–18 (Cont.) Parameters for the DEFAULT_NEW_CFG_DATES Procedure Parameter Data Type Mode Note p_lookup_date date in/out This specifies the lookup date for the new configuration. p_effective_date date in/out This specifies the effective date for the new configuration.
Considerations After Running
Results Any of the parameters (p_creation_date, p_lookup_date, p_effective_ date) that were not passed in are populated with the date that the runtime Oracle Configurator would use for that parameter.
7-38 Oracle Configurator Implementation Guide DEFAULT_RESTORED_CFG_DATES
DEFAULT_RESTORED_CFG_DATES
Considerations Before Running
Purpose This utility procedure provides default date values used by Oracle Configurator for a restored configuration. The caller should pass in dates that will be included in the initialization message for the runtime Oracle Configurator. The procedure will return the value that will be used by the runtime Oracle Configurator for any dates not passed in. The CONFIG_HEADER_ID and a configuration revision (CONFIG_ REV_NBR) must be supplied. Default date values are determined differently for a restored configuration that for a new configuration.
Prerequisites None.
Timing This procedure should be used if the developer is interested in finding out the default dates used by the runtime Oracle Configurator for publication lookup, effectivity, and configuration creation.
Dependencies None.
Restrictions and Limitations None.
Syntax and Parameters The syntax for this procedure is: PROCEDURE DEFAULT_RESTORED_CFG_DATES( p_config_hdr_id IN NUMBER, p_config_rev_nbr IN NUMBER, p_creation_date IN OUT DATE, p_lookup_date IN OUT DATE, p_effective_date IN OUT DATE );
Table 7–19, " Parameters for the DEFAULT_RESTORED_CFG_DATES Procedure" describes the parameters for the DEFAULT_RESTORED_CFG_DATES procedure.
Programmatic Tools for Development 7-39 DEFAULT_RESTORED_CFG_DATES
Table 7–19 Parameters for the DEFAULT_RESTORED_CFG_DATES Procedure Parameter Data Type Mode Note p_config_hdr_id number in Specifies which configuration to use. p_config_rev_nbr number in Specifies which configuration to use p_creation_date date in/out If this is not null, it will be returned as is. Otherwise, the existing setting for this configuration is returned. p_lookup_date date in/out If this is not null, it will be returned as is. Otherwise, the existing setting for this configuration is returned. p_effective_date date in/out If this is not null, it will be returned as is. Otherwise, the existing setting for this configuration is returned.
Considerations After Running
Results Any of the parameters (p_creation_date, p_lookup_date, p_effective_ date) that were not passed in are populated with the date that the runtime Oracle Configurator would use for that parameter.
7-40 Oracle Configurator Implementation Guide DELETE_CONFIGURATION
DELETE_CONFIGURATION
Considerations Before Running
Purpose This procedure removes a configuration from the database.
Prerequisites The configuration to be deleted must exist.
Timing This procedure should be used when a configuration is obsolete.
Warnings You should not delete configurations that are referred to by any host applications.
Syntax and Parameters The syntax for this procedure is: PROCEDURE delete_configuration( config_hdr_id IN NUMBER, config_rev_nbr IN NUMBER, usage_exists IN OUT NUMBER, Error_message IN OUT VARCHAR2, Return_value IN OUT NUMBER);
Table 7–20, " Parameters for the DELETE_CONFIGURATION Procedure" on page 7-41 describes the parameters for the DELETE_CONFIGURATION procedure.
Table 7–20 Parameters for the DELETE_CONFIGURATION Procedure Parameter Data Type Mode Note config_hdr_id number in Specifies the header ID of the configuration to be deleted config_rev_nbr number in Specifies the revision number of the configuration to be deleted usage_exists number in/out This returns 1 if a configuration usage record exists and the configuration is not deleted. (Requires custom code to populate the CZ_CONFIG_USAGES table.)
Programmatic Tools for Development 7-41 DELETE_CONFIGURATION
Table 7–20 (Cont.) Parameters for the DELETE_CONFIGURATION Procedure Parameter Data Type Mode Note error_message varchar2 in/out If there is an error, this field contains a message describing the error. return_value number in/out If 1, then the configuration was successfully deleted. If 0, then deletion of the configuration failed.
Considerations After Running
Troubleshooting Examine the output in the error_message parameter.
7-42 Oracle Configurator Implementation Guide ICX_SESSION_TICKET
ICX_SESSION_TICKET
Considerations Before Running
Purpose This function returns a value for the session ticket that Oracle Applications should pass as "icx_session_ticket" when calling Oracle Configurator. This ticket allows the runtime Oracle Configurator to maintain the Oracle Applications session identity. A null value is returned if user_id, resp_id, or appl_id are not defined within the Oracle Applications session or if the icx calls fail.
Prerequisites In order to use this function, the database session must have been initialized with Oracle Applications parameters in order for the icx_session_ticket to return a value.
Timing This function should be used before launching a configuration session from PL/SQL.
Syntax and Parameters The syntax for this function is: FUNCTION icx_session_ticket RETURN VARCHAR2;
There are no parameters for this function. It derives its inputs from the environment of the database session.
Considerations After Running
Results This function returns the ICX ticket that represents the Oracle Applications session.
Troubleshooting If this function returns NULL, the database session is not an Oracle Applications session.
Programmatic Tools for Development 7-43 MODEL_FOR_ITEM
MODEL_FOR_ITEM
Considerations Before Running
Purpose This function returns a published Model passed on the inventory item ID, organization id, and applicability. This function is used for backward compatibility. It calls CONFIG_MODEL_FOR_ ITEM with usage_name equal to "Any Usage" and publication_mode equal to ’P’.
Timing This function should be used after publishing Models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, the CZ:Usage Name and/or CZ: Publication Mode profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any Usage" and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION model_for_item( inventory_item_id NUMBER, organization_id NUMBER, config_creation_date DATE, user_id NUMBER, responsibility_id NUMBER, calling_application_id NUMBER ) RETURN NUMBER;
Table 7–21, " Parameters for the MODEL_FOR_ITEM Function" on page 7-45 describes the parameters for the MODEL_FOR_ITEM function.
7-44 Oracle Configurator Implementation Guide MODEL_FOR_ITEM
Table 7–21 Parameters for the MODEL_FOR_ITEM Function Parameter Data Type Mode Note inventory_item_id number in If the Model was imported from Oracle BOM, this is the inventory item ID for the published Model, from the MTL_ SYSTEM_ITEMS table, on which configuration models are based. organization_id number in If the Model was imported from Oracle BOM, this is the organization ID for the published Model, from the MTL_ SYSTEM_ITEMS table, on which configuration models are based. config_creation_date date in This is the lookup date for the configuration user_id number in This is the ID for the Oracle Applications user that is logged into from FND_USER. responsibility_id number in This is the responsibility that the Oracle Applications user had in the calling application. calling_application_id number in The registered ID of an application for which the Model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
Considerations After Running
Results This function returns the devl_project_id of the configuration model published for this combination of inputs. NULL is returned if there is no matching publication.
Programmatic Tools for Development 7-45 MODEL_FOR_PUBLICATION_ID
MODEL_FOR_PUBLICATION_ID
Considerations Before Running
Purpose This function returns the Model ID for a specified publication.
Timing This function should be used after publishing Models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Syntax and Parameters The syntax for this function is: FUNCTION model_for_publication_id (publication_id NUMBER) RETURN NUMBER;
Table 7–22, " Parameters for the MODEL_FOR_PUBLICATION_ID Function" on page 7-46 describes the parameters for the MODEL_FOR_PUBLICATION_ID function.
Table 7–22 Parameters for the MODEL_FOR_PUBLICATION_ID Function Parameter Data Type Mode Note publication_id number in This is the specified publication id in the CZ_ MODEL_PUBLICATIONS table.
7-46 Oracle Configurator Implementation Guide PUBLICATION_FOR_ITEM
PUBLICATION_FOR_ITEM
Considerations Before Running
Purpose This function returns the publication ID for a specified inventory item.
Timing This function should be used after publishing Models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, the CZ:Usage Name and/or CZ: Publication Mode profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any Usage" and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION publication_for_item ( inventory_item_id IN NUMBER, organization_id IN NUMBER, config_lookup_date IN DATE, calling_application_id IN NUMBER, usage_name IN VARCHAR2, publication_mode IN VARCHAR2 DEFAULT NULL, language IN VARCHAR2 DEFAULT NULL) RETURN NUMBER;
Table 7–23, " Parameters for the PUBLICATION_FOR_ITEM Function" on page 7-48 describes the parameters for the PUBLICATION_FOR_ITEM function.
Programmatic Tools for Development 7-47 PUBLICATION_FOR_ITEM
Table 7–23 Parameters for the PUBLICATION_FOR_ITEM Function Parameter Data Type Mode Note inventory_item_id number in If the Model was imported from Oracle BOM, this is the Inventory Item ID for the published Model, from the MTL_ SYSTEM_ITEMS table, on which configuration models are based. organization_id number in If the Model was imported from Oracle BOM, this is the organization ID for the published Model, from the MTL_ SYSTEM_ITEMS table, on which configuration models are based. config_lookup_date date in Date to search for inside the applicable range for the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. calling_application_id number in The registered ID of an application for which the Model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. usage_name varchar2 in Usage name to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. publication_mode varchar2 in Publication mode to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. language varchar2 in Language code to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
7-48 Oracle Configurator Implementation Guide PUBLICATION_FOR_PRODUCT
PUBLICATION_FOR_PRODUCT
Considerations Before Running
Purpose This function returns the publication ID for a product key.
Timing This function should be used after publishing Models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a Model to be returned. This function must be run on the instance that the Model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any Usage" and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION publication_for_product( product_key IN VARCHAR2, config_lookup_date IN DATE, calling_application_id IN NUMBER, usage_name IN VARCHAR2, publication_mode IN VARCHAR2 DEFAULT NULL, language IN VARCHAR2 DEFAULT NULL) RETURN NUMBER;
Table 7–24, " Parameters for the PUBLICATION_FOR_PRODUCT Function" on page 7-50 describes the parameters for the PUBLICATION_FOR_PRODUCT function.
Programmatic Tools for Development 7-49 PUBLICATION_FOR_PRODUCT
Table 7–24 Parameters for the PUBLICATION_FOR_PRODUCT Function Parameter Data Type Mode Note product_key varchar2 in Product key to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. config_lookup_date date in Date to search for inside the applicable range for the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. calling_application_id number in The registered ID of an application for which the Model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. publication_mode varchar2 in Publication mode to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. language varchar2 in Language code to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
7-50 Oracle Configurator Implementation Guide PUBLICATION_FOR_SAVED_CONFIG
PUBLICATION_FOR_SAVED_CONFIG
Considerations Before Running
Purpose This function is used to determine the publication that should be used to reopen a saved configuration. The function returns a publication ID for an existing configuration based on its model information and applicability parameters.
Timing This function should be used after publishing models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a model to be returned. This function must be run on the instance that the model is published to.
Warnings If usage_name and/or publication_mode are NULL or not provided, the CZ:Usage Name and/or CZ: Publication Mode profile option values will be checked. However, Oracle Applications session parameters are not defined by default within a SQL*Plus session. If profile option values are not defined for this or any other reason, the defaults for usage_name and/or publication_mode will be "Any Usage" and "P" (Production) respectively.
Syntax and Parameters The syntax for this function is: FUNCTION publication_for_saved_config ( config_hdr_id IN NUMBER, config_rev_nbr IN NUMBER, config_lookup_date IN DATE, calling_application_id IN NUMBER, usage_name IN VARCHAR2, publication_mode IN VARCHAR2 DEFAULT NULL, language IN VARCHAR2 DEFAULT NULL) RETURN NUMBER;
Table 7–25, " Parameters for the PUBLICATION_FOR_SAVED_CONFIG Function" on page 7-52 describes the parameters for the PUBLICATION_FOR_SAVED_ CONFIG function.
Programmatic Tools for Development 7-51 PUBLICATION_FOR_SAVED_CONFIG
Table 7–25 Parameters for the PUBLICATION_FOR_SAVED_CONFIG Function Parameter Data Type Mode Note config_hdr_id number in Identifies the saved configuration to use. config_rev_nbr number in Identifies the saved configuration. config_lookup_date date in Date to search for inside the applicable range for the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. calling_application_id number in The registered ID of an application for which the model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. usage_name varchar2 in Usage name to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. publication_mode varchar2 in Publication mode to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6. language varchar2 in Language code to search for in the publication. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
7-52 Oracle Configurator Implementation Guide UI_FOR_ITEM
UI_FOR_ITEM
Considerations Before Running
Purpose This function returns a UI definition (ui_def_id) for a given inventory item (inventory_item_id) and organization item (organization_id) based on publication applicability parameters. This function is used for backward compatibility. It calls CONFIG_UI_FOR_ITEM with usage_name equal to "Any Usage" and publication_mode equal to ’P’.
Timing This function should be used after publishing models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a model to be returned. This function must be run on the instance that the model is published to.
Syntax and Parameters The syntax for this function is: FUNCTION ui_for_item( inventory_item_id NUMBER, organization_id NUMBER, config_creation_date DATE, ui_type VARCHAR2, user_id NUMBER, responsibility_id NUMBER, calling_application_id NUMBER ) RETURN NUMBER;
Table 7–26, " Parameters for the UI_FOR_ITEM Function" on page 7-54 describes the parameters for the UI_FOR_ITEM function.
Programmatic Tools for Development 7-53 UI_FOR_ITEM
Table 7–26 Parameters for the UI_FOR_ITEM Function Parameter Data Type Mode Note inventory_item_id number in If the model was imported from Oracle BOM, this is the Inventory Item ID for the published model, from the MTL_ SYSTEM_ITEMS table, on which configuration models are based. organization_id number in If the model was imported from Oracle BOM, this is the organization ID for the published model, from the MTL_ SYSTEM_ITEMS table, on which configuration models are based. config_creation_date date in This is the date the configuration was created. ui_type varchar2 in This is the type of UI sought and found for each product. Values are ’APPLET’ or ’DHTML’. user_id number in This is the ID for the Oracle Applications user that is logged into from FND_ USER. responsibility_id number in This is the responsibility that the Oracle Applications user had in the calling application. calling_application_id number in The registered ID of an application for which the model is published. See Section 7.2.6.2, "Applicability Parameters" on page 7-6.
7-54 Oracle Configurator Implementation Guide UI_FOR_PUBLICATION_ID
UI_FOR_PUBLICATION_ID
Considerations Before Running
Purpose This function returns a UI definition (ui_def_id) for a specified publication ID.
Timing This function should be used after publishing models, to verify if publication lookup will succeed for a given set of applicability parameters.
Dependencies Publications must exist for a model to be returned. This function must be run on the instance that the model is published to.
Syntax and Parameters The syntax for this function is: FUNCTION ui_for_publication_id ( publication_id NUMBER ) RETURN NUMBER;
Table 7–27, " Parameters for the UI_FOR_PUBLICATION_ID Function" on page 7-55 describes the parameters for the UI_FOR_PUBLICATION_ID function. See Example 7–1 on page 7-55 for an example of how these parameters are used.
Table 7–27 Parameters for the UI_FOR_PUBLICATION_ID Function Parameter Data Type Mode Note publication_id number in This is the specified publication id in the CZ_ MODEL_PUBLICATIONS table.
Example When executed in SQL*Plus, this example prints out the ID of the UI definition associated with the publication identified by the publication_id parameter. If the publication has no associated UI, then a message is printed.
Example 7–1 Using the UI_FOR_PUBLICATION_ID Function set serveroutput on
Programmatic Tools for Development 7-55 UI_FOR_PUBLICATION_ID
DECLARE v_ui_def_id number; BEGIN -- The publication must have status of 'OK' ("Complete"). v_ui_def_id := cz_cf_api.ui_for_publication_id(12345); IF v_ui_def_id IS NULL THEN dbms_output.put_line('UI Def ID: '||'NOT FOUND'); ELSE dbms_output.put_line('UI Def ID: '||v_ui_def_id); END IF; END;
7-56 Oracle Configurator Implementation Guide VALIDATE
VALIDATE
Considerations Before Running
Purpose This procedure is for the configurator to validate a configuration. This checks to see if a configuration is still valid, either because the rules may have changed, the configuration is imported from another system, or another program wants to change one of the configuration inputs. This procedure is a single call validation procedure that uses tables to exchange multi-valued data. A validation_status and a table of XML messages are returned.
Syntax and Parameters The syntax for this procedure is: PROCEDURE VALIDATE ( config_input_list IN CFG_INPUT_LIST, init_message IN VARCHAR2, config_messages IN OUT CFG_OUTPUT_PIECES, validation_status IN OUT NUMBER, URL IN VARCHAR2 DEFAULT FND_PROFILE.Value('CZ_UIMGR_URL'));
Table 7–28, " Parameters for the VALIDATE Procedure" on page 7-57 describes the parameters for the VALIDATE procedure.
Table 7–28 Parameters for the VALIDATE Procedure Parameter Data Type Mode Note config_input_list CFG_INPUT_ in This is a list of input selections. LIST1 init_message varchar2 in Initialization message config_messages CFG_OUTPUT_ out This is a table of the output XML messages PIECES2 produced by validating the configuration.
Programmatic Tools for Development 7-57 VALIDATE
Table 7–28 (Cont.) Parameters for the VALIDATE Procedure Parameter Data Type Mode Note validation_status varchar2 out The status code returned by validating the configuration. 0 - call succeeds and config_messages contains a terminate message 1 - CONFIG_PROCESSED 2 - CONFIG_PROCESSED_NO_ TERMINATE 3 - INIT_TOO_LONG 4 - INVALID_OPTION_REQUEST 5 - CONFIG_EXCEPTION 6 - DATABASE_ERROR 7 - UTL_HTTP_INIT_FAILED 8 - UTL_HTTP_REQUEST_FAILED url varchar2 in This is the URL for the Oracle Configurator Servlet. Default will interrogate the current profile for this URL, using FND_ PROFILE.Value('CZ_UIMGR_URL').
1 See Section 7.3.1, "Custom Data Types" on page 7-8 for a definition of this type. 2 See Section 7.3.1, "Custom Data Types" on page 7-8 for a definition of this type.
Considerations After Running
Results This procedure returns the following values:
Return Value Description CONFIG_PROCESSED Configuration processed successfully CONFIG_PROCESSED_NO_TERMINATE Configuration, no terminate message returned INIT_TOO_LONG Initialization message must be less than 2048 characters INVALID_OPTION_REQUEST Returned when an input does not include a component code or quantity.
7-58 Oracle Configurator Implementation Guide VALIDATE
Return Value Description CONFIG_EXCEPTION Unknown error DATABASE_ERROR Unknown error UTL_HTTP_INIT_FAILED Procedure uses UTL_ HTTP package to pass UTL_HTTP_REQUEST_FAILED data to Configurator Servlet. THese exceptions can be returned by UTL_ HTTP procedures. See Oracle8i Supplied PL/SQL Packages Reference for additional information.
Programmatic Tools for Development 7-59 VALIDATE
7-60 Oracle Configurator Implementation Guide 8 Programmatic Tools for Maintenance
This chapter describes a set of programmatic tools that you can use primarily to maintain a deployed runtime Oracle Configurator. For information on tools for developing a configuration model or deploying a runtime Oracle Configurator, see Chapter 7, "Programmatic Tools for Development".
8.1 Overview of the CZ_modelOperations_pub Package The programmatic tools that you use to maintain a deployed runtime Oracle Configurator are provided in the PL/SQL package CZ_modelOperations_pub.
8.1.1 Purpose of the Package The CZ_modelOperations_pub package contains a set of APIs that allow for automated updating to handle day-to-day maintenance activities and thus reduce the maintenance workload. The operations covered by this are:
■ importing and refreshing configuration models with data from Oracle Applications BOMs
■ generation and refreshing of Active Models and User Interfaces
■ publication of Active Models and User Interfaces
■ initial execution and refreshing of Item Master Populators
8.1.2 Installation of the Package The information provided for the package CZ_CF_API in Section 7.1.3, "Installation of the Package" on page 7-3 also applies to the package CZ_modelOperations_pub.
Programmatic Tools for Maintenance 8-1 Choosing the Right Tool for the Job
8.1.3 References for Working with PL/SQL Procedures For background information and details on basic aspects of working with the PL/SQL procedures in this package, see Table 7–2 on page 7-3 in Section 7.1.4, "References for Working with PL/SQL Procedures and Functions", which suggests relevant topics in the Oracle Documentation Library.
8.2 Choosing the Right Tool for the Job These procedures are described in detail in Section 8.4, "Reference for the CZ_ modelOperations_pub Package" on page 8-6.
Importing and Refreshing Models ■ IMPORT_SINGLE_BILL
■ REFRESH_SINGLE_MODEL
Generating Logic ■ GENERATE_LOGIC
Generating and Refreshing UIs ■ CREATE_UI
■ REFRESH_UI
Copying Models ■ DEEP_MODEL_COPY
Publishing Models ■ PUBLISH_MODEL
■ REPUBLISH_MODEL
Running Populators ■ EXECUTE_POPULATOR
■ REPOPULATE
8-2 Oracle Configurator Implementation Guide Queries to Support the CZ_modelOperations_pub Package
8.3 Queries to Support the CZ_modelOperations_pub Package This section contains PL/SQL queries which provide the values that you need to provide as parameters to certain procedures in the CZ_modelOperations_pub package.
8.3.1 Querying for Model IDs Example 8–1 on page 8-3 provides a PL/SQL query that lists the names and IDs of source (not published) Models, and the Folders which contain them in the Repository of Oracle Configurator Developer. The ID of a Model is stored as CZ_DEVL_PROJECTS.DEVL_PROJECT_ID. This query selects a value for DEVL_PROJECT_ID. You would use this ID as a value for the parameter p_devl_project_id to the following procedures:
■ CREATE_UI
■ GENERATE_LOGIC
■ REFRESH_SINGLE_MODEL
■ DEEP_MODEL_COPY
■ REPOPULATE
Example 8–1 Query for Models and Folders select P.devl_project_id, P.name, R.enclosing_folder, R2.name FOLDER from cz_devl_projects P, cz_rp_entries R, cz_rp_entries R2 where R.object_type = 'PRJ' and R.deleted_flag = '0' and P.deleted_flag = '0' and P.devl_project_id = R.object_id and R2.object_id = R.enclosing_folder and R2.object_type ='FLD';
Programmatic Tools for Maintenance 8-3 Queries to Support the CZ_modelOperations_pub Package
You can add the following condition to the beginning of the WHERE clause of this query to specify the name of a particular Model as it appears in Oracle Configurator Developer. P.name like '%your Model’s name%' and
8.3.2 Querying for User Interface IDs Example 8–2 on page 8-4 provides a PL/SQL query that lists the names and IDs of available user interfaces for a specified Model. To determine the devl_project_ ID for the specified Model, you would use the query in Example 8–1 on page 8-3. This query selects values for the column CZ_UI_DEFS.UI_DEF_ID. This UI_DEF_ID is returned by the procedure CREATE_UI. You would use this ID as a value for the p_ui_def_id parameter for the procedure REFRESH_UI.
Example 8–2 Query for User Interface IDs select ui_def_id, name from cz_ui_defs where devl_project_id = devl_project_ID and deleted_flag = '0';
8.3.3 Querying for Referenced User Interface IDs Example 8–3 on page 8-4 provides a PL/SQL query that lists the IDs of available referenced (child) user interfaces for a specified parent_ui_def_ID. To determine the parent_ui_def_ID for a specified Model, you would use the query in Example 8–2 on page 8-4. This query selects a value for the column CZ_UI_NODES.UI_DEF_ID. You would then use this value as a parameter for the following procedures:
■ REFRESH_UI
Example 8–3 Query for Referenced User Interface IDs select distinct
8-4 Oracle Configurator Implementation Guide Queries to Support the CZ_modelOperations_pub Package
ui_def_id from cz_ui_nodes where cz_ui_nodes.deleted_flag = '0' start with ui_def_id = parent_ui_def_ID connect by prior cz_ui_nodes.ui_def_ref_id = cz_ui_nodes.ui_def_id and prior deleted_flag = '0' order by cz_ui_nodes.ui_def_id;
8.3.4 Querying for Populators Example 8–4 on page 8-5 provides a PL/SQL query that lists the names and IDs of Populators for a given Model. To determine the devl_project_ID_for_model for the specified Model, you would use the query in Example 8–1 on page 8-3. This query selects a value for the column CZ_POPULATORS.POPULATOR_ID. You would use this value as a parameter for the following procedures:
■ EXECUTE_POPULATOR
Example 8–4 Query for Populators select populator_id, a.name POPULATOR_NAME, b.ps_node_id, b.name from cz_populators a, cz_ps_nodes b where a.owned_by_node_id = b.ps_node_id and b.devl_project_id = devl_project_ID_for_model and a.deleted_flag = '0' and b.deleted_flag = '0';
Programmatic Tools for Maintenance 8-5 Reference for the CZ_modelOperations_pub Package
8.3.5 Querying for Error and Warning Information Example 8–5 on page 8-6 provides a PL/SQL query that retrieves the error and warning information that is recorded in the table CZ_DB_LOGS after you run one of the following procedures:
■ CREATE_UI
■ GENERATE_LOGIC
■ IMPORT_SINGLE_BILL This query selects values for the columns URGENCY, STATUSCODE, and MESSAGE from the table CZ_DB_LOGS. URGENCY and STATUSCODE only have significant values when populated by the GENERATE_LOGIC procedure. The URGENCY values used by GENERATE_ LOGIC are 0 for errors and 1 for warnings. STATUSCODE values are not meaningful to the user but are important to the Oracle Configurator engineering team for the debugging of logic generation code.
Example 8–5 Query for Error and Warning Information select urgency, statuscode, message from cz_db_logs where run_id = run_ID_returned_from_procedure;
8.4 Reference for the CZ_modelOperations_pub Package
■ This section provides descriptions of each of the procedures in the CZ_ modelOperations_pub package. These procedures are listed alphabetically in Table 8–1 on page 8-8.
■ Descriptions of the custom data types defined in the package are also provided, in Custom Data Types on page 8-6.
■ For a basic example of how to call one of the functions in the CZ_CF_API package, see Example 8–6, "Using the GENERATE_LOGIC Procedure" on page 8-17.
8-6 Oracle Configurator Implementation Guide Reference for the CZ_modelOperations_pub Package
■ See also Section 8.1, "Overview of the CZ_modelOperations_pub Package" on page 8-1.
8.4.1 Custom Data Types There are no custom data types defined in the CZ_modelOperations_pub package.
8.4.2 API Version Numbers Oracle APIs incorporate a mechanism called API version numbers. This mechanism:
■ Allows an API to differentiate between changes that require you to change your API calling code and those that don't.
■ Allows an API to detect incompatible calls.
■ Allows you to quickly determine if calling a new version of an API requires you to change any of your code.
■ Allows you to easily figure out which version of an API you need to call to take advantage of new features.
8.4.2.1 Format of API Version Numbers API version numbers consist of two segments separated by a decimal point. The first segment is the major version number; the second segment is the minor version number. The starting version number for an API is always 1.0. Examples:
API Version Major Minor Number Version Version 1.0 1 0 2.4 2 4
If the major version number has changed, then you probably need to modify your programs that call that API. Major version changes include changes to the list of required parameters or changing the value of an API OUT parameter. If only the minor version number has changed, then you probably do not need to modify your programs.
Programmatic Tools for Maintenance 8-7 Reference for the CZ_modelOperations_pub Package
8.4.2.2 Current API Version Number for This Package The API version number for the APIs included in the current version of the CZ_ modelOperations_pub package is: 1.0
The local constant that stores this version number is: l_api_version CONSTANT NUMBER
8.4.2.3 Checking for Incompatible API Calls To detect incompatible calls, programs calling an API must pass an API version number as one of the input parameters. The API can then compare the passed version number to its current version number, and detect any incompatible calls. The Oracle standard parameter used by all procedures in this package to pass in the API version number is: p_api_version IN NUMBER
This parameter is required, and has no initial values, thus forcing your program to pass this parameter when calling an API. If your call to the API results in a version incompatibility, then an error message is inserted in the table CZ_DB_LOGS. You can examine the message using a query like the one shown in Example 8–5 on page 8-6.
8.4.3 Procedures in the CZ_modelOperations_pub Package This section provides descriptions of each of the procedures in the CZ_ modelOperations_pub package, arranged alphabetically. These procedures are listed in Table 8–1 on page 8-8.
Table 8–1 Procedures in the Package CZ_modelOperations_pub API Name CREATE_UI on page 8-9 DEEP_MODEL_COPY on page 8-12 EXECUTE_POPULATOR on page 8-14 GENERATE_LOGIC on page 8-16 IMPORT_SINGLE_BILL on page 8-18
8-8 Oracle Configurator Implementation Guide Reference for the CZ_modelOperations_pub Package
Table 8–1 (Cont.) Procedures in the Package CZ_modelOperations_pub API Name PUBLISH_MODEL on page 8-19 REFRESH_SINGLE_MODEL on page 8-20 REFRESH_UI on page 8-21 REPOPULATE on page 8-23 REPUBLISH_MODEL on page 8-25
Programmatic Tools for Maintenance 8-9 CREATE_UI
CREATE_UI
The CREATE_UI procedure generates a new user interface for a model. If referenced models are present, then the behavior is the following: 1. If a referenced model has one or more user interfaces of the input UI style (DHTML or applet), then the root UI will refer to the last UI created with this style. 2. If a referenced model has no user interface, the procedure will generate a new UI for that model.
Considerations Before Running
Alternatives As an alternative to using this procedure, you can create a UI in Oracle Configurator Developer, by switching to the UI module, selecting the root UI node, then choosing Create > New User Interface.
Syntax and Parameters The syntax for this procedure is: PROCEDURE create_ui(p_api_version IN NUMBER, p_devl_project_id IN NUMBER, x_ui_def_id OUT NUMBER, x_run_id OUT NUMBER, x_status OUT NUMBER, p_ui_style IN VARCHAR2 DEFAULT 'COMPONENTS', p_frame_allocation IN NUMBER DEFAULT 30, p_width IN NUMBER DEFAULT 640, p_height IN NUMBER DEFAULT 480, p_show_all_nodes IN VARCHAR2 DEFAULT '0', p_look_and_feel IN VARCHAR2 DEFAULT 'BLAF', p_wizard_style IN VARCHAR2 DEFAULT '0', p_max_bom_per_page IN NUMBER DEFAULT 10, p_use_labels IN VARCHAR2 DEFAULT '1');
Table 8–2 on page 8-10 describes the parameters for the CREATE_UI procedure.
8-10 Oracle Configurator Implementation Guide CREATE_UI
Table 8–2 Parameters for the CREATE_UI Procedure Parameter Mode Data Type Note p_api_version in number See API Version Numbers on page 8-7. p_devl_project_id in number The ID of the Model for which to create a UI. See Example 8–1 on page 8-3 for a query that provides this ID (DEVL_PROJECT_ID). x_ui_def_id out number The ID of the UI that is created. This is stored as CZ_UI_DEFS.UI_DEF_ID. x_run_id out number The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, 0 is stored. x_status out number Either G_STATUS_ERROR or G_STATUS_ SUCCESS. p_ui_style in varchar2 The style of the UI. Values are: '0' or 'COMPONENTS' for a Component Tree (DHTML) style, '3' or 'APPLET' for an Applet UI style. The default is ‘COMPONENTS’. p_frame_allocation in number The left-hand frame allocation for the new UI, in %. The default is 30 (30% of the screen allocated to the left-hand frame). p_width in number The width of the screens in the new UI, in pixels. The default is 640. p_height in number The height of the screens in the new UI, in pixels. The default is 480. p_show_all_nodes in varchar2 Controls whether the "display in UI" flag on Model nodes is respected. If this parameter is '1' then the new UI will include all Model nodes including those marked as "do not display in UI". If this parameter is '0' then the new UI will respect the "display in UI" flag on Model nodes. The default is ‘0’. p_look_and_feel in varchar2 The look and feel for the new UI. Values are: 'BLAF', 'APPLET', or 'FORMS'. The default is 'BLAF'. ’FORMS’ can only be used if p_ui_ style is ’COMPONENTS’. The default is 'BLAF'.
Programmatic Tools for Maintenance 8-11 CREATE_UI
Table 8–2 (Cont.) Parameters for the CREATE_UI Procedure Parameter Mode Data Type Note p_wizard_style in varchar2 Whether to generate wizard style navigation. Values are: ’0’ for No, ’1’ for Yes. The default is ’0’ (No). p_max_bom_per_page in number The maximum number of BOM Option Class children per screen. The default is 10. p_use_labels in varchar2 Indicates how to generate captions: ’0’ for description only, ’1’ for name only, ’2’, for name and description. The default is ’1’.
8-12 Oracle Configurator Implementation Guide DEEP_MODEL_COPY
DEEP_MODEL_COPY
The DEEP_MODEL_COPY procedure performs a deep copy of a specified Model. Deep copying creates a new copy of the specified Model, along with new copies of any referenced Models. You can choose to copy the Model without its configuration rules, user interfaces, or referenced child Models.
Syntax and Parameters The syntax for this procedure is: PROCEDURE deep_model_copy(p_api_version IN NUMBER, p_devl_project_id IN NUMBER, p_folder IN NUMBER, p_copy_rules IN NUMBER, p_copy_uis IN NUMBER, p_copy_root IN NUMBER, x_devl_project_id OUT NUMBER, x_run_id OUT NUMBER, x_status OUT NUMBER);
Table 8–3 on page 8-12 describes the parameters for the DEEP_MODEL_COPY procedure.
Table 8–3 Parameters for the DEEP_MODEL_COPY Procedure Parameter Mode Data Type Note p_api_version in number See API Version Numbers on page 8-7. p_devl_project_id in number The ID of the Model of which a copy is to be made. See Example 8–1 on page 8-3 for a query that provides this ID (DEVL_PROJECT_ID). p_folder in number The folder to which the copy is made. p_copy_rules in number Set to 1 to copy configuration rules with the model, 0 to omit the rules. p_copy_uis in number Set to 1 to copy user interfaces with the model, 0 to omit the user interfaces. p_copy_root in number Set to 1 to copy only the root model, 0 to copy all referenced models as well.
Programmatic Tools for Maintenance 8-13 DEEP_MODEL_COPY
Table 8–3 (Cont.) Parameters for the DEEP_MODEL_COPY Procedure Parameter Mode Data Type Note x_devl_project_id out number The ID (DEVL_PROJECT_ID) of the Model created by the copying operation. x_run_id out number The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. x_status out number Either G_STATUS_ERROR or G_STATUS_ SUCCESS.
8-14 Oracle Configurator Implementation Guide EXECUTE_POPULATOR
EXECUTE_POPULATOR
The EXECUTE_POPULATOR procedure can be used to refresh the CZ_PS_NODES table by executing a Populator. A Populator is a mechanism that automatically builds Model structure from data in the Item Master. See the Oracle Configurator Developer User’s Guide for more details on Populators. The CZ_PS_NODES table in the Oracle Configurator schema describes the structure of the Active Model. See the description of REPOPULATE on page 8-23 for information on the related procedure for repopulating Model structure.
Considerations Before Running
Alternatives As an alternative to using this procedure, you can define and run a Populator using Oracle Configurator Developer. See the Oracle Configurator Developer User’s Guide for instructions on using Populators.
Syntax and Parameters The syntax for this procedure is: PROCEDURE execute_populator(p_api_version IN NUMBER, p_populator_id IN NUMBER, p_imp_run_id IN OUT VARCHAR2, x_run_id OUT NUMBER, x_status OUT NUMBER);
Table 8–4 on page 8-14 describes the parameters for the EXECUTE_POPULATOR procedure.
Table 8–4 Parameters for the EXECUTE_POPULATOR Procedure Parameter Mode Data Type Note p_api_version in number See API Version Numbers on page 8-7.
Programmatic Tools for Maintenance 8-15 EXECUTE_POPULATOR
Table 8–4 (Cont.) Parameters for the EXECUTE_POPULATOR Procedure Parameter Mode Data Type Note p_populator_id in number The value of CZ_POPULATORS.POPULATOR_ID for the Populator to be executed. p_imp_run_id in/out varchar2 Stored in CZ_IMP_PS_NODES.RUN_ID. x_run_id out number The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, 0 is stored. x_status out number Either G_STATUS_ERROR or G_STATUS_SUCCESS.
8-16 Oracle Configurator Implementation Guide GENERATE_LOGIC
GENERATE_LOGIC
The GENERATE_LOGIC procedure generates logic for a model and all of its referenced models if necessary.
Considerations Before Running
Alternatives As an alternative to using this procedure, you can generate logic in Oracle Configurator Developer, by choosing Tools > Generate Active Model.
Syntax and Parameters The syntax for this procedure is: PROCEDURE generate_logic(p_api_version IN NUMBER, p_devl_project_id IN NUMBER, x_run_id OUT NUMBER, x_status OUT NUMBER);
Table 8–5 on page 8-16 describes the parameters for the GENERATE_LOGIC procedure.
Table 8–5 Parameters for the GENERATE_LOGIC Procedure Parameter Mode Data Type Note p_api_version in number See API Version Numbers on page 8-7. p_devl_project_id in number The ID of the Model for which to generate logic. See Example 8–1 on page 8-3 for a query that provides this ID (DEVL_PROJECT_ID). x_run_id out number The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, 0 is stored. x_status out number Either G_STATUS_ERROR, G_STATUS_WARNING, or G_STATUS_SUCCESS.
Programmatic Tools for Maintenance 8-17 GENERATE_LOGIC
Example When executed in SQL*Plus, this example generates logic for a model with the ID (DEVL_PROJECT_ID) specified by the p_devl_project_id parameter. After the procedure runs, it prints the run ID and status.
Example 8–6 Using the GENERATE_LOGIC Procedure set serveroutput on declare x_run_id number; x_status varchar2(100); begin CZ_modelOperations_pub.generate_logic(1.0,12345,x_run_id,x_status); dbms_output.put_line('Run id: '||x_run_id); dbms_output.put_line('x_status: '||x_status); end;
8-18 Oracle Configurator Implementation Guide IMPORT_SINGLE_BILL
IMPORT_SINGLE_BILL
The IMPORT_SINGLE_BILL procedure can be used to import a model from Oracle Bills of Materials (BOM).
Syntax and Parameters The syntax for this procedure is: PROCEDURE import_single_bill(p_api_version IN NUMBER, p_org_id IN NUMBER, p_top_inv_item_id IN NUMBER, x_run_info_id OUT NUMBER, x_run_id OUT NUMBER, x_status OUT NUMBER);
Table 8–6 on page 8-18 describes the parameters for the IMPORT_SINGLE_BILL procedure.
Table 8–6 Parameters for the IMPORT_SINGLE_BILL Procedure Parameter Mode Data Type Note p_api_version in number See API Version Numbers on page 8-7. p_org_id in number The organization ID of the bill to be imported. p_top_inv_item_id in number The Inventory Item ID of the top item to be imported (the BOM root). x_run_info_id out number This is not CZ_DB_LOGS.RUN_ID, but is generated by executing: (select max(run_id) from CZ_XFR_RUN_ INFOS);
x_run_id out number The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. x_status out number Either G_STATUS_ERROR or G_STATUS_ SUCCESS.
Programmatic Tools for Maintenance 8-19 PUBLISH_MODEL
PUBLISH_MODEL
After a publication record is created through Oracle Configurator Developer, the PUBLISH_MODEL procedure will export the models and UIs associated with the publication.
Considerations Before Running
Restrictions and Limitations This procedure should only be run on publications with a status of Pending.
Alternatives As an alternative to using this procedure, you can publish models in Oracle Configurator Developer using the Model Publishing window
Syntax and Parameters The syntax for this procedure is: PROCEDURE publish_model(p_api_version IN NUMBER, p_publication_id IN NUMBER, x_run_id OUT NUMBER, x_status OUT NUMBER);
Table 8–7 on page 8-19 describes the parameters for the PUBLISH_MODEL procedure.
Table 8–7 Parameters for the PUBLISH_MODEL Procedure Parameter Mode Data Type Note p_api_version in number See API Version Numbers on page 8-7. p_publication_id in number The publication ID generated when you publish a model in Oracle Configurator Developer, stored as CZ_MODEL_PUBLICATIONS.PUBLICATION_ID. x_run_id out number The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. x_status out number Either G_STATUS_ERROR or G_STATUS_SUCCESS.
8-20 Oracle Configurator Implementation Guide REFRESH_SINGLE_MODEL
REFRESH_SINGLE_MODEL
The REFRESH_SINGLE_MODEL procedure can be used to refresh a model imported from Oracle Bills of Materials (BOM).
Syntax and Parameters The syntax for this procedure is: PROCEDURE refresh_single_model(p_api_version IN NUMBER, p_devl_project_id IN VARCHAR2, x_run_info_id OUT NUMBER, x_run_id OUT NUMBER, x_status OUT NUMBER);
Table 8–8 on page 8-20 describes the parameters for the REFRESH_SINGLE_ MODEL procedure.
Table 8–8 Parameters for the REFRESH_SINGLE_MODEL Procedure Parameter Mode Data Type p_api_version in number See API Version Numbers on page 8-7. p_devl_project_id in varchar2 The ID of the Model for which to refresh imported data. See Example 8–1 on page 8-3 for a query that provides this ID (DEVL_PROJECT_ ID). x_run_info_id out number This is not CZ_DB_LOGS.RUN_ID, but is generated by executing: (select max(run_id) from CZ_XFR_RUN_ INFOS);
x_run_id out number The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. x_status out number Either G_STATUS_ERROR or G_STATUS_ SUCCESS.
Programmatic Tools for Maintenance 8-21 REFRESH_UI
REFRESH_UI
The REFRESH_UI procedure refreshes an existing user interface based on the current model data.
Considerations Before Running
Restrictions and Limitations This procedure only refreshes the UI specified. It does not refresh referenced user interfaces.
Alternatives As an alternative to using this procedure, you can refresh a UI in Oracle Configurator Developer, by switching to the UI module, selecting a User Interface, then choosing Edit > Refresh.
Syntax and Parameters The syntax for this procedure is: PROCEDURE refresh_ui(p_api_version IN NUMBER, p_ui_def_id IN OUT NUMBER, x_run_id OUT NUMBER, x_status OUT NUMBER);
Table 8–9 on page 8-21 describes the parameters for the REFRESH_UI procedure.
Table 8–9 Parameters for the REFRESH_UI Procedure Parameter Mode Data Type p_api_version in number See API Version Numbers on page 8-7. p_ui_def_id in/out number UI definition ID of user interface to be refreshed. If user interface is Applet style, a new ui_def_id is returned through this parameter. If the style is DHTML, the same ui_def_id is returned. x_run_id out number The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, 0 is stored.
8-22 Oracle Configurator Implementation Guide REFRESH_UI
Table 8–9 (Cont.) Parameters for the REFRESH_UI Procedure Parameter Mode Data Type x_status out number Either G_STATUS_ERROR, G_STATUS_WARNING or G_STATUS_SUCCESS.
Programmatic Tools for Maintenance 8-23 REPOPULATE
REPOPULATE
The REPOPULATE procedure iterates through all Populators associated with the input model and executes them.
Considerations Before Running
Alternatives As an alternative to using this procedure, you can repopulate the Model with current data when data in the Item Master changes in Oracle Configurator Developer, by choosing Tools > RePopulate.
Syntax and Parameters The syntax for this procedure is: PROCEDURE repopulate(p_api_version IN NUMBER, p_devl_project_id IN NUMBER, p_regenerate_all IN VARCHAR2 DEFAULT 1, p_handle_invalid IN VARCHAR2 DEFAULT 1, p_handle_broken IN VARCHAR2 DEFAULT 1, x_run_id OUT NUMBER, x_status OUT NUMBER);
Table 8–10 on page 8-23 describes the parameters for the REPOPULATE procedure.
Table 8–10 Parameters for the REPOPULATE Procedure Parameter Mode Data Type Note p_api_version in number See API Version Numbers on page 8-7. p_devl_project_id in number The ID of the Model to repopulate. See Example 8–1 on page 8-3 for a query that provides this ID (DEVL_PROJECT_ID). p_regenerate_all in varchar2 Set to 0 if all Populators should be regenerated unconditionally before execution. Set to 1 to regenerate only modified Populators. The default is 1.
8-24 Oracle Configurator Implementation Guide REPOPULATE
Table 8–10 (Cont.) Parameters for the REPOPULATE Procedure Parameter Mode Data Type Note p_handle_invalid in varchar2 Allows caller to specify how to handle invalid Populators. Pass 0 to skip invalid Populators, or pass 1 to regenerate them. The default is 1. p_handle_broken in varchar2 Allows caller to specify whether to continue (1) or not (0) when a Populator cannot be regenerated successfully. The default is 1. x_run_id out number The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, 0 is stored. x_status out number Either G_STATUS_ERROR or G_STATUS_ SUCCESS.
Programmatic Tools for Maintenance 8-25 REPUBLISH_MODEL
REPUBLISH_MODEL
The REPUBLISH_MODEL procedure is the server side API to create a publication request and republish the model. Only valid publications can be republished. A valid publication’s DELETED_ FLAG=0, STATUS=OK, and SOURCE_TARGET_FLAG=S. Possible reasons for the REPUBLISH_MODEL procedure to fail, are:
■ Input dates were not valid for the p_publication_id
■ There is an overlap with existing publications for the same Model
■ The Model was regenerated and the UI was refreshed If the validation fails for any reason, the error messages are logged in CZ_DB_ LOGS.
Considerations Before Running
Alternatives As an alternative to using this procedure, you can republish an existing model in Oracle Configurator Developer, by choosing Tools > Publishing..., selecting a model >Republish.
Syntax and Parameters The syntax for this procedure is: PROCEDURE republish_model(p_api_version IN NUMBER, p_publication_id IN NUMBER, p_start_date IN DATE, p_end_date IN DATE, x_run_id OUT NUMBER, x_status OUT NUMBER);
Table 8–11 on page 8-26 describes the parameters for the REPUBLISH_MODEL procedure.
8-26 Oracle Configurator Implementation Guide REPUBLISH_MODEL
Table 8–11 Parameters for the REPUBLISH_MODEL Procedure Parameter Mode Data Type Note p_api_version in number 1.0. See API Version Numbers on page 8-7 for additional information. p_publication_id in number This is the ID of the publication that is being republished. p_start_datel in date This is the start date of the original publication. p_end_date in date This is the end date of the original publication. p_handle_broken in varchar2 Allows caller to specify whether to continue (1) or not (0) when a Populator cannot be regenerated successfully. The default is 1. x_run_id out number The ID of the running of this procedure. This value is stored in CZ_DB_LOGS.RUN_ID. If there are no warnings or errors, 0 is stored. x_status out number Either G_STATUS_ERROR, G_STATUS_ SUCCESS, or G_STATUS_WARNING.
Programmatic Tools for Maintenance 8-27 REPUBLISH_MODEL
8-28 Oracle Configurator Implementation Guide 9 Configuration Attributes
This chapter describes a methodology for using configuration attributes.
9.1 Overview of Configuration Attributes The term configuration attributes denotes a methodology for using certain existing features of Oracle Configurator and host applications to capture and exchange data that is not standard inventory information.
9.1.1 Purpose There are situations in which you need the ability to capture and pass certain miscellaneous items of data between Oracle Configurator and a host application. Such miscellaneous items can include free-form text (such as addresses) or computed values (such as dimensions). The inventory information used by the runtime Oracle Configurator does not always provide the structure needed to store such non-standard data.
9.1.1.1 Typical Problems To Be Solved This list of problems is by no means exhaustive. It is meant to illustrate the problems that this methodology addresses.
■ In fabrication industries, raw material is often purchased in standard sizes. A problem occurs when the unit of measurement of the item in inventory (typically "Each") is different from the unit of measurement (UOM) required by the manufacturing process on the factory floor. Configuration rules can determine how many inventory items are needed for the process, but cannot capture the difference between the inventory measurement and the process measurement.
Configuration Attributes 9-1 Overview of Configuration Attributes
Example: A fabrication company stocks the inventory items listed in the following table:
Item ID Description UOM AA248 2 x 4 Pine Stud, 8’ Each AA148 1 x 4 Pine Stud, 8’ Each
Oracle Configurator may determine that a specific fabricated item requires 3 2x4s, each 61 inches long. While the quantity (3) and item ID (AA248) can be passed back to the host application, the additional information as to the required length of the item is not. The information that needs to be communicated to the manufacturing floor is "Get 3 of Item AA248 and cut all three down to 61 inches each".
■ In many applications, end users need to enter or compute multiple attributes for a given item. This is common in the metals industry where multiple parameters may be required in order to specify or "formulate" a metal component. For example, a number of attributes may be required to specify a sheet of aluminum, including its length, width, gauge, and the percentages of the various components that make up the metal.
■ It may be necessary to enter or determine attribute information and have that information associated with many items. For example, an attribute such as "voltage" may apply to a number of items within the configuration that share electrical properties.
9.1.1.2 Solutions To solve the problems listed in Section 9.1.1.1, you can use Oracle Configurator configuration attributes. These are attributes that you design and attach to certain nodes of existing configuration models. There are two distinct strategies for using configuration attributes, which you can implement independently of each other:
■ input, described in Section 9.1.1.3
■ output, described in Section 9.1.1.4 You can use the two strategies together, but there is no requirement to do so, and there are no special provisions in Oracle Configurator for making them interact.
9-2 Oracle Configurator Implementation Guide Overview of Configuration Attributes
As background for the output strategy, you should familiarize yourself with descriptive flexfields, which are a feature of Oracle Applications that allow you to capture non-standard information.
9.1.1.3 Use of Configuration Attributes for Input The use of configuration attributes for input permits values that are stored by a host application in a database to be retrieved by Oracle Configurator and inserted into the configuration model at the beginning of a configuration session, as the initial values of specified Features. During the session, the values can be modified in the normal way.
Implementing the Strategy Section 9.1.2.2 on page 9-5 provides an overview of how the input strategy works, and the steps required to implement it. Section 9.2 on page 9-6 provides the details for implementing the input strategy.
9.1.1.4 Use of Configuration Attributes for Output The use of configuration attributes for output permits values to be captured as part of an Oracle Configurator configuration session and, after the session, be provided back to a host application for further use in the downstream process. By using configuration attributes for output, you can capture miscellaneous text or numeric data during the configuration session, store it in text or numeric Features in the configuration model, and then provide it to the hosting application so that it is still associated with the configured item. At design time, you can:
■ Supplement model structure in Oracle Configurator Developer (OCD) with attributes for storing additional parameters, such as: dimensions, location names, pricing annotations, and manufacturing notes.
■ Write configuration rules against the added attributes
■ Specify the level of association of the attribute values:
■ Only where attached in the configuration model
■ Where attached plus immediate selected model children
■ Where attached plus all selected model descendents At runtime, you can:
Configuration Attributes 9-3 Overview of Configuration Attributes
■ Associate the configuration attributes’ values to specific line items, through descriptive flexfield context definitions
■ Write configuration attributes with different contexts for the same line item
■ Associate a single configuration attribute value:
■ to a single line item
■ to many line items
■ Associate many configuration attribute values to a single line item
Context for Processing Output To understand the requirements that are filled by using configuration attributes, it is helpful to summarize the events in a configuration session. When a sales order or quote is created at runtime in a host application (for instance, Order Management, iStore, or Oracle Quoting), the end user is asked to specify a particular item to be configured. In the runtime Oracle Configurator, the end user selects predefined options and enters numeric values, such as dimensions. Oracle Configurator uses the configuration rules written for the configuration model in Oracle Configurator Developer to automatically select or deselect additional items as being required or excluded by the explicit user selections. After the configuration session is completed (with the Done button), a complete configuration is saved, in the Oracle Configurator schema of the application’s database. After the configuration is saved, the host application performs downstream processing that varies according to the specifics of that application. Consider Order Management as an example here. When booking the order, Order Management validates the configuration and explodes the configuration items onto the order, creating additional order lines for each selected subcomponent of the configurable model. Through invoking the Auto-Create Final Assembly concurrent program, the order (that is, all order lines) can be passed to Oracle Manufacturing to be scheduled and executed. In addition to ensuring the valid configuration of selections and quantities in the BOM, Oracle Configurator can provide additional configuration attributes attached to the selected components that may or may not be directly related to the quantities. Through a custom procedure (which must be written as part of this methodology), a downstream application can access the configuration attribute data. The methodology described in this chapter provides a solution for:
■ Defining these configuration attributes
9-4 Oracle Configurator Implementation Guide Overview of Configuration Attributes
■ End-user entry of data for these configuration attributes
■ Saving the values of these configuration attributes
Implementing the Strategy Section 9.1.2.2 on page 9-5 provides an overview of how the output strategy works, and the steps required to implement it. Section 9.3 on page 9-23 provides the details for implementing the output strategy.
9.1.2 Overviews of Implementing Configuration Attributes See Section 9.1.1.3 on page 9-3 and Section 9.1.1.4 on page 9-3 for overviews of the use of these strategies.
9.1.2.1 Overview of Implementing Configuration Attributes for Input See Section 9.2 on page 9-6 for the details on implementation.
How the Solution Works A Model is specially modified to contain configuration attribute data. During the initialization of an end user configuration session with that Model, a Functional Companion retrieves the configuration attribute data from the host application’s tables and inserts it into the Model so that it can be used during configuration session.
What You Do to Implement the Solution To use configuration attributes for the input of data from a host application to Oracle Configurator, you must:
■ Modify the host application’s initialization message to Oracle Configurator to specify the source of the configuration attribute data. See Section 9.2.2 on page 9-8.
■ Modify the structure of the configuration model so that it includes elements that can receive the data (such as numeric Features). You must also associate a Functional Companion with the structure. See Section 9.2.3 on page 9-11.
■ Modify the example Functional Companion to pass the data from the host application to the locations that you have created in the modified model. See Section 9.2.4 on page 9-13.
■ Deploy the Model and the Functional Companion. See Section 9.1.3 on page 9-6.
Configuration Attributes 9-5 Overview of Configuration Attributes
9.1.2.2 Overview of Implementing Configuration Attributes for Output See Section 9.3 on page 9-23 for the details on implementation.
How the Solution Works A configuration model is specially modified to contain configuration attribute data. After an end user configuration session with that model terminates, a Functional Companion captures the configuration attribute data from the model and inserts it in the table CZ_CONFIG_ATTRIBUTES. A custom procedure retrieves the data from this table and inserts it into descriptive flexfield segments, where it can be accessed by the Oracle Applications host.
What You Do to Implement the Solution To use configuration attributes for the output of data from Oracle Configurator to a host application, you must:
■ Understand the structure of the table CZ_CONFIG_ATTRIBUTES. See Section 9.3.1 on page 9-25.
■ Modify Oracle Applications to add flexfield definitions. See Section 9.3.2 on page 9-26.
■ Modify the configuration model to capture configuration attribute data. See Section 9.3.3 on page 9-28.
■ Possibly modify the example Functional Companion to match changes to the configuration model. See Section 9.3.4 on page 9-39.
■ Deploy the Model and the Functional Companion. See Section 9.1.3 on page 9-6.
■ Write a custom procedure and customize the downstream application so that it can use the configuration attribute data stored in CZ_CONFIG_ATTRIBUTES. See Section 9.3.5 on page 9-40.
9.1.3 Deploying the Solution The tasks for deploying your configuration attributes solution are the same for both input and output. After you have modified the host application, the Model, and the Functional Companion, you must: 1. Using Oracle Configurator Developer, generate the Active Model and unit-test it with the Test module. See the Oracle Configurator Developer User’s Guide for details.
9-6 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Input
2. Publish the modified Model. See Chapter 6 for information on publishing. 3. Compile the Functional Companion, as described in the Oracle Configuration Interface Object (CIO) Developer’s Guide. 4. Install the Functional Companion, as described in the Oracle Configurator Installation Guide. This involves placing the Java class file for the Functional Companion in the class path of the Oracle Configurator Servlet, updating the OC Servlet’s configuration files, and restarting the OC Servlet.
9.2 Implementing Configuration Attributes for Input This section describes the details for implementing a configuration attributes input solution. See Section 9.1.2.2, "Overview of Implementing Configuration Attributes for Output" on page 9-5 for an overview. See the following sections for details on the tasks required for implementing configuration attributes for input:
■ Section 9.2.1, "Example for Implementing Input Configuration Attributes" on page 9-7.
■ Section 9.2.2, "Host Application Integration with Oracle Configurator" on page 9-8.
■ Section 9.2.3, "Modifying the Model" on page 9-11.
■ Section 9.2.4, "Modifying the Functional Companion Example" on page 9-13.
■ Section 9.1.3, "Deploying the Solution" on page 9-6.
9.2.1 Example for Implementing Input Configuration Attributes The methodology for implementing input configuration attributes is illustrated throughout Section 9.2 by use of a simple hypothetical example. This section describes that example.
Note: This chapter, Chapter 9, "Configuration Attributes", discusses methodological examples of implementing configuration attributes, and provides examples of Functional Companion coding. The term example is used for both.
Configuration Attributes 9-7 Implementing Configuration Attributes for Input
Assumptions for the Example Assume that you have the following requirements:
■ The product that you are selling through your host application must be configured partly on the basis of the U.S. state to which it is shipped.
■ You want to use Oracle Configurator to decide which version of your product must be selected, based on the U.S. state.
■ The host application is Oracle Quoting.
■ For a given quote line, you want to capture the identity of the U.S. state for the customer associated with the quote, so that you can pass it to Oracle Configurator. Assume that the address is associated with the order header.
Methodology for the Example The example uses the following method to fulfill your requirements: 1. The host application (Oracle Quoting) calls the runtime Oracle Configurator when the end user clicks the Configure button. The initialization message posted from Oracle Quoting to OC includes a parameter that identifies the current quote line. 2. Oracle Configurator creates a new configuration. In doing so, it triggers the execution of the onNew() method of the Functional Companion associated with the configuration model. 3. The Functional Companion uses a custom query to extract the data associated with quote line, using the quote header to access the U.S. state for the customer’s address. 4. The Functional Companion processes the result set returned by the query to isolate the value for the U.S. state name. 5. The Functional Companion stores the value of the U.S. state name in a local variable. 6. The configuration model includes a Feature named US_State dedicated to storing the name of a U.S. state, so that state-specific configuration rules can be written against it. Each Option of this Feature is named for a U.S. state, in a way that matches the state name stored in the customer record used by the host application (that is, with the state’s two-letter postal abbreviation). 7. The Functional Companion uses a custom method to locate the Feature named US_State. The search starts from the node with which the Functional Companion has been previously associated in Configurator Developer.
9-8 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Input
8. The Functional Companion uses the same custom method to locate the Option whose name matches the U.S. state name that was extracted from the database. 9. The Functional Companion selects that particular Option. Now, any configuration rules written against that Option will be invoked or set or applied.
9.2.2 Host Application Integration with Oracle Configurator The responsibilities for this task depend on
■ If you are integrating Oracle Configurator with Oracle Applications, see Section 9.2.2.1, "Responsibilities For Oracle Applications Host" on page 9-8.
■ If you are integrating Oracle Configurator with a custom application, Section 9.2.2.2, "Responsibilities For Custom Application Host" on page 9-11.
■ If you are implementing the Functional Companion used for input configuration attributes, see Section 9.2.2.3, "Responsibilities For Functional Companion Implementer" on page 9-11. See Section 9.2.1, "Example for Implementing Input Configuration Attributes" on page 9-7 for background.
9.2.2.1 Responsibilities For Oracle Applications Host The host application must pass to Oracle Configurator the information that identifies the quote line item, order line item, or equivalent that is associated with the desired configuration attribute data. The mechanism for passing this identification information is a set of parameters in the initialization message that is sent by the Oracle Applications host to the Oracle Configurator Servlet.
■ The parameters themselves are described in Initialization Parameters for Input Configuration Attributes on page 9-9.
■ The task of adding the parameters is described in Adding the Parameters to the Initialization Message on page 9-10.
Initialization Parameters for Input Configuration Attributes The set of parameters that must be added to the initialization message depends on the particular host application. The host application must specify its identity, with the parameter calling_application_id (see calling_application_id on page 9-10). In addition the host application must specify the set of parameters that
Configuration Attributes 9-9 Implementing Configuration Attributes for Input
are sufficient to identify the quote line, order line or equivalent that is associated with the desired configuration attribute data. The full set of available parameters intended for this purpose are:
■ client_header
■ client_line
■ client_line_detail
client_header Use this parameter to specify the unit of work for the application (for example, an order or quote). Table 9–2 lists some potential sources, in certain host Oracle Applications, for the data that can be provided for this parameter.
Table 9–1 Sources for Values of the client_header Parameter Application Source for Parameter Data Oracle Order Management (ONT) OE_ORDER_LINES_ALL.HEADER_ID Oracle Quoting (ASO) Probably not used. Oracle Contracts Core (OKC) Probably not used.
client_line The particular part of the order or quote that the configuration is initiated against. Table 9–2 lists some potential sources, in certain host Oracle Applications, for the data that can be provided for this parameter.
Table 9–2 Sources for Values of the client_line Parameter Application Source for Parameter Data Oracle Order Management (ONT) OE_ORDER_LINES_ALL.LINE_ID Oracle Quoting (ASO) ASO_QUOTE_LINE.QUOTE_LINE_ID Oracle Contracts Core (OKC) OKC_K_LINES.ID
client_line_detail This parameter is used to provide additional information if client_line does not provide enough.
9-10 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Input
Table 9–3 lists some potential sources, in certain host Oracle Applications, for the data that can be provided for this parameter.
Table 9–3 Sources for Values of the client_line_detail Parameter Application Source for Parameter Data Oracle Order Management (ONT) Not used. Oracle Quoting (ASO) ASO_QUOTE_LINE.LINE_NUMBER Oracle Contracts Core (OKC) OKC_K_LINES.LINE_NUMBER calling_application_id Use this parameter to identify the Oracle Applications host that is invoking Oracle Configurator. The value of the ID for your application is obtained from FND_APPLICATION.APPLICATION_ID. (See the Oracle Configurator Custom Web Deployment Guide for other information about this parameter.) See Section 9.2.4.4, "Identifying the Host Application" on page 9-17 for information about determining the value to use for this parameter.
Adding the Parameters to the Initialization Message Example 9–1 on page 9-10 shows sample parameters for identifying the quote or order line in the initialization message sent by the Order Management application to the runtime Oracle Configurator. The parameters not related to configuration attributes are omitted from this example. The values for client_header and client_line are hypothetical, but the value for calling_application_id is real.
Example 9–1 Configuration Attribute Parameters in the Initialization Message
For general background and specific details on initialization parameters and the initialization message, see the Oracle Configurator Custom Web Deployment Guide.
Configuration Attributes 9-11 Implementing Configuration Attributes for Input
9.2.2.2 Responsibilities For Custom Application Host If you are integrating Oracle Configurator with a custom host application, you must perform the tasks described for integration with Oracle Applications:
■ Initialization Parameters for Input Configuration Attributes on page 9-9
■ Adding the Parameters to the Initialization Message on page 9-10 The difference is that you have to provide your own means of:
■ Identifying the line item associated with the configuration attribute data
■ Identifying the host application
9.2.2.3 Responsibilities For Functional Companion Implementer When you modify the example Functional Companion (Example B–1 on page B-2):
■ You must know which of the configuration attribute initialization parameters are being passed in the initialization message. The recommended parameters are described in Initialization Parameters for Input Configuration Attributes on page 9-9.
■ You must get the names and values of the passed parameters, including calling_application_id, as described in Section 9.2.4.3 on page 9-16.
■ You must write a query that extracts the desired data from the tables associated with the quote or order line, as described in Section 9.2.4.5 on page 9-18.
■ See Section 9.2.4 on page 9-13 for details on the rest of the tasks required when modifying the Functional Companion.
9.2.3 Modifying the Model See Section 9.2.1, "Example for Implementing Input Configuration Attributes" on page 9-7 for background. To create configuration rules that operate on the input configuration attribute data, your Model must include some additional structure that receives the data when it is transferred to the runtime Model by your Functional Companion. To create this structure, you use Oracle Configurator Developer, as described in Section 9.2.3.1 and following. See the Oracle Configurator Developer User’s Guide for details on creating structure.
9-12 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Input
9.2.3.1 Creating Features To work with the example, create a Feature named US_State, with a Type set to List of Options, and Minimum and Maximum both set to 1. The name of the Feature must agree exactly with the name that you specify for the findFirstNodeByName() method of the Functional Companion, since the Feature is located by a case-sensitive string search on each character of the name. See Section 9.2.4.6, "Transferring Data to Features" on page 9-19. You can use this Feature as a participant in a configuration rule that specifies a particular U.S. state.
9.2.3.2 Creating Options The name of each Option must match the data value stored in the customer record used by the host application. To work with the example, create a list of Options for the Feature named US_State. Set the Name of each Option to be the postal abbreviation for a U.S. state (for example, CA, NY, MA, RI). The name of each Option must agree exactly with one of the values retrieved from the host application’s database by the custom query in the Functional Companion. The retrieved value is passed as an argument to the findFirstNodeByName() method of the Functional Companion,which performs a case-sensitive string search on each character of the name. See Section 9.2.4.6, "Transferring Data to Features" on page 9-19. You can use this Option as a participant in a configuration rule that specifies a particular U.S. state.
9.2.3.3 Creating Functional Companion Rules The Functional Companion must be associated with the node in the Model’s structure that is the starting point for locating the Feature that contains the configuration attribute Options. To work with the example, create a Functional Companion rule and associate it with a parent node of the Feature named US_State. Choose a node that is certain to contain the Feature, so that the search for it by the findFirstNodeByName() method of the Functional Companion will be successful and efficient. Consider that choosing a node high in the Model’s hierarchical structure will result in a longer search, and may result in locating the wrong Feature if there is another one with the same name.
Configuration Attributes 9-13 Implementing Configuration Attributes for Input
Set the Definition of the Functional Companion rule as shown in the following table:
Rule Definition Attribute Definition Value Base Component The node from which the Functional Companion will search for the specified Feature. Type Event-Driven Implementation Java Program String The name of the Java class that implements the input Functional Companion. For the example, this is CfgInputExample (Example B–1 on page B-2).
For more details on defining Functional Companion rules, see the Oracle Configuration Interface Object (CIO) Developer’s Guide. For details on defining other kinds of configuration rules, see the Oracle Configurator Developer User’s Guide.
9.2.4 Modifying the Functional Companion Example For the complete Java code example that supports this section, see Example B–1 on page B-2, in Section B.1, which demonstrates a Functional Companion that uses configuration attributes for input to a configuration model This section includes excerpts from Example B–1.
Caution: Example B–1 demonstrates a Functional Companion that uses configuration attributes for input to a configuration model. This example is only a template for your own solution to the problem; you must modify the code in the example to suit your own configuration model and host application.
For a summary of the flow of data and control in the Functional Companion example, see Methodology for the Example under Section 9.2.1, "Example for Implementing Input Configuration Attributes" on page 9-7. When you customize the Functional Companion, keep in mind that it should only perform the function of transferring data into your configuration model. For simplicity and maintainability, you should not perform other operations in this Functional Companion.
9-14 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Input
This Functional Companion example is customized to work with Oracle Quoting. The customizations are identified and explained where they occur in the following sections, so that you can customize your Functional Companion for your own host application.
Note: Be sure to check the Oracle Configuration Interface Object (CIO) Developer’s Guide for a description of the Java development skills required for success with Functional Companions.
9.2.4.1 Implementing AutoFunctionalCompanion Methods For your Functional Companion to be run automatically when the host application invokes the runtime Oracle Configurator, you must extend the class AutoFunctionalCompanion, as shown in the following code fragment. public class CfgInputExample extends AutoFunctionalCompanion { // body of class defined here ... }
You must also override the onNew() and onRestore() methods of AutoFunctionalCompanion, to provide functionality when the configuration associated with the Functional Companion is either created, or restored, respectively. The following code fragment shows the structure of this overriding. public void onNew() throws LogicalException { // functionality of method defined here doInputAttributeTransfer(); }
public void onRestore() throws LogicalException { // functionality of method defined here doInputAttributeTransfer(); }
Your Functional Companion can define functionality for both methods. The appropriate method will be triggered by the runtime Oracle Configurator when the configuration associated with the Functional Companion is either created or restored. The method doInputAttributeTransfer() is part of the example, and is explained in Section 9.2.4.2, "Structuring the Behavior" on page 9-15.
Configuration Attributes 9-15 Implementing Configuration Attributes for Input
You should be careful in deciding what functionality to define in onNew(), in onRestore(), or in both.
■ If you use only onNew(), then the input configuration attribute data is retrieved only once, when the configuration is created. You should do this if you want the configuration attribute data to remain the same throughout the life of the configuration. If you want to ensure that the original input data is never changed, and to specify an unchangeable set of logical assertions against that data, you should use initial requests (which are described in the Oracle Configuration Interface Object (CIO) Developer’s Guide).
■ If you use only onRestore(), then the input configuration attribute data is retrieved only whenever the saved configuration is restored from the database. It is unlikely that you would want to use only onRestore(), since the result would be that no configuration attribute data would be input into your configuration model when a configuration is created.
■ If you use both onNew() and onRestore(), then the input configuration attribute data is retrieved when the configuration is created and also whenever it is restored. (Note that if you used initial requests in onNew(), then onRestore() will not be able to change those values.) The effect is that the current source data in the host application’s database is always put into your configuration model. However, be aware that if the host application has changed the source data since the configuration was created, that changed data will be put into your configuration model, and may produce different results when it interacts with your configuration rules.
9.2.4.2 Structuring the Behavior The main tasks that must be performed by the Functional Companion are:
■ Getting the session parameters from the initialization message. Section 9.2.4.3 on page 9-16.
■ Identifying the host application. See Section 9.2.4.4 on page 9-17.
■ Extracting the input configuration attribute data for the quote (or order) line associated with the configuration. See Section 9.2.4.5 on page 9-18.
■ Transferring the configuration attribute data to the configuration model. See Section 9.2.4.6 on page 9-19.
9-16 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Input
In the example, the methods for performing these tasks are gathered together for convenience in the method doInputAttributeTransfer(), as shown in the following code fragment. private void doInputAttributeTransfer() throws LogicalException {
// Get the session parameters getSessionParameters(); if (mOrderLineNumber == null) return;
// Identify the host application if (mApplicationId.longValue() != 697) return;
// Specify the quote/order line and extract the attribute data getInputAttributes();
// Transfer the attribute data to the configuration model transferInputAttributesIntoModel(); }
See Section 9.2.4.4, "Identifying the Host Application" on page 9-17 for background on the value of mApplicationId.
9.2.4.3 Getting Session Parameters The Functional Companion must extract the parameter values it needs from the initialization message posted to Oracle Configurator by the host application. The parameters used for obtaining configuration attribute data are described in Initialization Parameters for Input Configuration Attributes on page 9-9. The example defines the method getSessionParameters(), as shown in the following code fragment. private void getSessionParameters() {
// 1. Get the parameters in the initialization message NameValuePairSet initParams = getRuntimeNode().getConfiguration().getInitParameters(); String paramValue = null;
// 2. Get the value of the parameter "client_line" paramValue = (String)initParams.getValueByName("client_line");
// 3. Store the parameter value if (paramValue != null) mOrderLineNumber = Long.valueOf(paramValue);
Configuration Attributes 9-17 Implementing Configuration Attributes for Input
// 4. Get and store the value of the parameter "calling_application_id" paramValue = (String)initParams.getValueByName("calling_application_id"); if (paramValue != null) mApplicationId = Long.valueOf(paramValue); }
The method getSessionParameters() performs the following tasks: 1. Gets the parameters of the initialization message, with Configuration.getInitParameters(). 2. Gets the value of the parameter that identifies the quote line or order line (client_line), using NameValuePairSet.getValueByName(). You may need to customize this to extract other parameter values. 3. Stores the value of the parameter in the variable mOrderLineNumber, if it is not null. You may have to change the data type of the variable depending on the type of the initialization parameter data being passed. 4. Gets the value of the parameter that identifies the host application (calling_application_id), using NameValuePairSet.getValueByName(). If it is not null, store it in the variable mApplicationId.
9.2.4.4 Identifying the Host Application The Functional Companion must check the identity of the host application that posted the initialization message to the runtime Oracle Configurator. This allows you to process the initialization parameters and configuration attribute data differently, depending on the host application. The Oracle Applications host is supposed to pass the identity of the application in the initialization parameter calling_application_id. If your host application is not part of Oracle Applications, then you must design your own mechanism for identifying the host application to the Functional Companion. The following test from the example’s doInputAttributeTransfer() method compares the mApplicationId obtained from getSessionParameters()to the application ID for Oracle Quoting, and returns immediately out of the method if it does not match. if (mApplicationId.longValue() != 697) return;
9-18 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Input
The following test from the example’s getInputAttributes() method checks whether the mApplicationId matches the application ID for Oracle Quoting, and proceeds if it does. if (mApplicationId.longValue() == 697) { ... }
The PL/SQL query in Example 9–2 on page 9-18 lists the IDs, short names, and long names for Oracle Applications. You can examine the results of the query to determine the application ID for your own host application.
Example 9–2 Query for Names of Oracle Applications SELECT SUBSTR(application_short_name,1,10) sName, SUBSTR(application_name,1,32) application, application_id as id FROM fnd_application_vl ORDER BY application_short_name;
The IDs and names for some typical hosting Oracle Applications, are listed in Table 9–4 on page 9-18.
Table 9–4 Typical IDs and Short Names for Oracle Applications Short Name Application Name Application ID ASO Oracle Quoting 697 AST TeleSales 521 OKC Oracle Contracts Core 510 ONT Oracle Order Management 660 XNC Oracle Sales for Communications 532
9.2.4.5 Extracting Input Attribute Data for the Specified Quote Line The Functional Companion extracts the configuration attribute data from the host application’s database by means of a customized PL/SQL query that specifies the mOrderLineNumber that was obtained by getSessionParameters() (see Section 9.2.4.3 on page 9-16). To perform this data extraction, the example defines the method getInputAttributes(), as shown in the following fragment. private void getInputAttributes() {
Configuration Attributes 9-19 Implementing Configuration Attributes for Input
Connection conn = getRuntimeNode().getConfiguration().getContext().getJDBCConnection(); PreparedStatement pStmt = null; ResultSet rs; int ret; ... // Define a custom query to extract the U.S. state for a quote line String sql = "select p.state " + "from hz_parties p, " + " aso_quote_headers_all_v q, " + " ASO_QUOTE_LINES_ALL_V l " + "where p.party_id = q.cust_account_id " + "and l.quote_header_id = q.quote_header_id " + "and l.quote_line_id = ?";
pStmt = conn.prepareStatement(sql);
// Put the line number into the first (and only) parameter // of the PreparedStatement, for quote_line_id pStmt.setLong(1, mOrderLineNumber.longValue());
// Execute the query, putting the results in a ResultSet rs = pStmt.executeQuery(); // Iterate through the ResultSet and get the first value ... mUsState = rs.getString(1); ... }
Note: The code fragment shown here omits error handling, for clarity. The full coding of the example for getInputAttributes() includes error handling for the query and processing of the results. Be sure to examine Example B–1 on page B-2.
9.2.4.6 Transferring Data to Features At this point, the Functional Companion has obtained the configuration attribute data (the abbreviation for a U.S. state), and stored it in a local variable (mUsState). Now the value must be transferred into a Feature of your configuration model (named US_State) that is dedicated to storing the configuration attribute data (the abbreviation of the U.S. state).
9-20 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Input
To perform this transfer, the example first defines a general transfer method transferInputAttributesIntoModel(), which is called in doInputAttributeTransfer(). This general method in turn calls a more specific transfer method, transferUsState(), which you must customize or replace, to transfer the configuration attribute data to the dedicated Feature of your configuration model. This arrangement, which is intended to provide modularity and ease of customization, is shown in the following fragment. private void transferInputAttributesIntoModel() throws LogicalException { transferUsState(); } private void transferUsState()throws LogicalException {
if (mUsState == null) return;
// Find the Feature dedicated to the attribute data IRuntimeNode rtNode = findFirstNodeByName(getRuntimeNode(), "US_State");
if (rtNode == null) return;
if (rtNode.getType() != IRuntimeNode.OPTION_FEATURE) return;
// Use the attribute value to find the Option with the matching name IOption option = (IOption)findFirstNodeByName(rtNode, mUsState); if (option == null) return; ... // Select the option to set its value option.select(); ... }
Starting from the runtime node to which it has been previously associated, the transfer method uses a custom method (findFirstNodeByName()) to locate the Feature named US_State. The transfer method then uses findFirstNodeByName() to locate the Option whose name matches the U.S. state name that was extracted from the database. Finally, the transfer method selects that particular Option. Now, any configuration rules written against that Option will be able to operate on it. The utility method findFirstNodeByName() is defined in the full example. See Example B–1 on page B-2 for the definition of this method.
Configuration Attributes 9-21 Implementing Configuration Attributes for Input
Note: The code fragment shown here omits some error handling, for simplicity. Be sure to examine Example B–1 on page B-2.
9.2.4.7 Guidelines for the Functional Companion This section lists guidelines for writing a Functional Companion for input configuration attributes. See the preceding subsections of Section 9.2.4 for illustrations of these guidelines.
General ■ The sole purpose of the Functional Companion should be to transfer configuration attribute data from a host application to the runtime Oracle Configurator. Do not perform any calculations on the configuration attribute data in the Functional Companion. Instead, perform the calculations through the structure and rules of the configuration model. This practice greatly improves the maintainability of the configuration rules, since the rules can be modified by using Oracle Configurator Developer, instead of by programming.
■ Assign only one Functional Companion that implements AutoFunctionalCompanion.onNew() for configuration attribute transfer per configuration model. The same guideline applies to a Functional Companion that implements AutoFunctionalCompanion.onRestore().
■ Design the Functional Companion so that it works with all of your host applications that include configuration models. The example demonstrates how to test for different applications.
■ The Functional Companion is not able to return messages resulting from exceptions, since an exception (which produces a message) returned from any Functional Companion that runs during the initialization of the runtime Oracle Configurator is treated as a fatal exception. The end-user session is terminated, displaying the message thrown from the exception. Consequently, structure the configuration model so that validation failures, rather than exceptions, will be produced when configuration attribute values have changed between sessions (assuming that you want your end user to know about this change during the configuration session). See the Oracle Configuration Interface Object (CIO) Developer’s Guide for background on validating configurations.
9-22 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Input
■ You can write a single Functional Companion that focuses on a single configuration attribute, and it will work with all configuration models that are modified to include that configuration attribute’s data. You do not have to create a separate Functional Companion for each of these configuration models. This is true because the Functional Companion is written to search for the Feature that corresponds to the configuration attribute, regardless of where it is placed in a Model.
■ Because the example uses the findFirstNodeByName() method to locate the attribute Feature, you cannot write a single Functional Companion to provide input to more than one configuration attribute
When Implementing the onNew() Method See Section 9.2.4.1, "Implementing AutoFunctionalCompanion Methods" on page 9-14 for coverage of the onNew() method.
■ If your Functional Companion’s custom query to the host application’s database does not find a value for the configuration attribute, then the Functional Companion should not attempt to provide a default value. Instead, your configuration model should include a Defaults rule that provides the default value. See the Oracle Configurator Developer User’s Guide for details on Defaults rules. The Functional Companion should report an error, as is shown in the full example (Example B–1 on page B-2).
When Implementing the onRestore() Method See Section 9.2.4.1, "Implementing AutoFunctionalCompanion Methods" on page 9-14 for coverage of the onRestore() method.
■ Not all previously saved attributes need to be loaded. For example, if a Feature value is calculated from several configuration attributes, then only the inputs to the calculation need to be restored. It may also be that these inputs may be the values of BOM items, which don't need to be restored through the Functional Companion.
■ You must decide when to update configuration attribute data: whether to restore it from the saved configuration or by extracting it again from the host application. Getting the most current value from the host application is usually the best course. However, if you don’t want the most current value from the host application, then the value is already restored, and you don’t need to take further action.
■ You must consider the host application domain when restoring a configuration into a different host application. For example, when the configuration is saved
Configuration Attributes 9-23 Implementing Configuration Attributes for Output
in Oracle Quoting, submitted to Order Management, and later is restored in Order Management (with batch validation), there can be different treatment of an input configuration attribute, but only if you code your Functional Companion to do that.
9.2.5 Runtime Behavior See Methodology for the Example under Section 9.2.1, "Example for Implementing Input Configuration Attributes" on page 9-7 for a summary of the behavior of the host application and Oracle Configurator at runtime.
Interactive Configuration Session Scenario When the runtime Oracle Configurator is invoked by the host application, the user interface is loaded and presented to the user. If there are any validation failures resulting from creating the configuration, they are displayed to the user. The session then waits to interact with the user. Any errors other than validation failures cause the session to terminate.
Batch Validation Scenario When the host application performs batch validation (for example, when Order Management books the order), any validation failures are recorded into the CZ_CONFIG_MESSAGES table. Then each user input, if any, is set by Order Management. All contradictions are recorded in CZ_CONFIG_MESSAGES. Overridable contradictions are overridden. Any errors other than validation failures cause the session to terminate.
9.3 Implementing Configuration Attributes for Output This section describes the details for implementing a configuration attributes output solution. See Section 9.1.2.2 on page 9-5 for an overview. See the following sections for details on the tasks required for implementing configuration attributes for output:
■ Section 9.3.1, "The CZ_CONFIG_ATTRIBUTES Table" on page 9-25.
■ Section 9.3.2, "Defining Descriptive Flexfields" on page 9-26.
■ Section 9.3.3, "Modifying the Model" on page 9-28.
9-24 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
■ Section 9.3.4, "The Output Functional Companion" on page 9-39.
■ Section 9.1.3, "Deploying the Solution" on page 9-6.
■ Section 9.3.5, "Using Configuration Attributes in the Downstream Application" on page 9-40.
Recommended Control and Data Flows The control and data flow at design time is shown in Figure 9–1 on page 9-24. The control and data flow at runtime is shown in Figure 9–2 on page 9-25.
Note: The flows shown here illustrate the methodology recommended in this chapter for Oracle Applications. If you are integrating with a custom host application, then you must make the appropriate adjustments to your flow, and also to the Functional Companion used to help implement it.
Configuration Attributes 9-25 Implementing Configuration Attributes for Output
Figure 9–1 Control and Data Flow at Design Time for Output
9-26 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
Figure 9–2 Control and Data Flow at Run Time for Output
9.3.1 The CZ_CONFIG_ATTRIBUTES Table The table CZ_CONFIG_ATTRIBUTES is used as the intermediate store of configuration attribute data between Oracle Configurator and the host application. The runtime Oracle Configurator writes output data to the table by means of the Functional Companion described in Section 9.3.4 on page 9-39. The data is available to a host application by means of the descriptive flexfields you define, as described in Section 9.3.2 on page 9-26. A custom procedure (which you must write) reads the data from CZ_CONFIG_ATTRIBUTES and inserts it into the tables used by a specific downstream application.
9.3.1.1 Table Layout and Description The layout of the CZ_CONFIG_ATTRIBUTES table is provided in Table 9–5.
Configuration Attributes 9-27 Implementing Configuration Attributes for Output
Table 9–5 The CZ_CONFIG_ATTRIBUTES Table Column Name Null? PK? Type Comments CONFIG_HDR_ID N Y NUMBER(9) Configuration header ID CONFIG_REV_NBR N Y NUMBER(9) Configuration revision number CONFIG_ITEM_ID N Y NUMBER(9) Configuration item ID ATTRIBUTE_CATEGORY N Y VARCHAR2(30) Name of the flexfield context ATTRIBUTE1 Y N VARCHAR2(240) Flexfield segment value for the specified context ATTRIBUTE2 Y N VARCHAR2(240) Flexfield segment value for the specified context ...... ATTRIBUTE30 Y N VARCHAR2(240) Flexfield segment value for the specified context
The columns CONFIG_HDR_ID, CONFIG_REV_NBR, CONFIG_ITEM_ID and ATTRIBUTE_CATEGORY constitute the primary key for CZ_CONFIG_ATTRIBUTES. All of the columns ATTRIBUTE1 through ATTRIBUTE30 are defined identically, and the columns between ATTRIBUTE2 and ATTRIBUTE30 have been omitted from Table 9–5 for brevity. The standard columns such as LAST_UPDATE_DATE have also been omitted for brevity. For information about the Oracle Configurator schema, see Chapter 3. For technical details about CZ_CONFIG_ATTRIBUTES and other tables, see the eTRM on Metalink, Oracle’s Customer Support Web site: http://metalink.oracle.com
9.3.2 Defining Descriptive Flexfields Configuration attributes are provided by defining descriptive flexfield segments. To define the metadata for the flexfields, log into Oracle Applications with the Oracle Application Developer responsibility. See the Oracle Applications Flexfields Guide for details on defining descriptive flexfields.
9-28 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
When you create the flexfields, use the settings shown in Table 9–6 for all contexts that you define.
Table 9–6 Flexfield Settings for All Contexts Setting Value Application Oracle Configurator Table Application Oracle Configurator Table Name CZ_CONFIG_ATTRIBUTES
When you create the flexfields, you define whatever contexts are required by the host application. Then, for each segment in a context, you need to specify the ATTRIBUTEn column in CZ_CONFIG_ATTRIBUTES in which that segment’s data will be allocated (see Table 9–5 on page 9-26 for the available column names).
Example of Flexfield Definition For a context named EAST, define that the segment named COLOR stores its data in ATTRIBUTE1 of the designated table (CZ_CONFIG_ATTRIBUTES), that a segment named WEIGHT stores its data in ATTRIBUTE2, and so on. Figure 9–3 on page 9-28 shows a summary of such segment definitions in Oracle Applications.
Configuration Attributes 9-29 Implementing Configuration Attributes for Output
Figure 9–3 Segments Summary for a Context
Guidelines If you want to replicate the attribute values as flexfields on a particular downstream application table (for example, MRP_FLOW_SCHEDULES), then it is good practice to match all the context and segment names as well as using the same column names for the CZ_CONFIG_ATTRIBUTES definitions. In other words, all flexfield definitions should be duplicated with the only difference being the Application and the Table Name.
9.3.3 Modifying the Model To use configuration attributes, you must modify your configuration model as described in this section.
9.3.3.1 Design Principles In order to write configuration rules that involve configuration attribute data, the attributes are represented in the configuration model by Features. In the solution described here, these Features are called attribute Features. The value of each configuration attribute is stored in an attribute Feature. Each attribute Feature corresponds to a descriptive flexfield segment (see Section 9.3.2, "Defining Descriptive Flexfields" on page 9-26).
9-30 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
The data types of the attribute Features must match the data types of the corresponding descriptive flexfields: an Integer Feature for an integer flexfield, an Option Feature for a LOV flexfield, and so on.
Caution: If you set the Maximum of any attribute Option Feature to a value greater than 1, then you must modify the example Functional Companion (Example B–2) to interpret the end user’s selection into a single attribute assignment.
To control the flow of configuration attribute data from the Model to the CZ_CONFIG_ATTRIBUTES table (and subsequently to the descriptive flexfields used by a downstream application), you define Properties on nodes in the Model structure:
■ To assign an attribute Feature to the corresponding descriptive flexfield segment, you must define a Property on the Feature that contains the name of the flexfield segment. This Property should be called ATTR_NAME.
■ To assign an attribute Feature to the correct flexfield context for the corresponding segment, you must define a Property on the Feature that contains the name of the flexfield context. This Property should be called ATTR_CONTEXT.
■ To assign the configuration attribute for an Item to the attribute Feature that stores the attribute’s value, you must define a Property on the Item that defines the node path to the attribute Feature in the Model. This Property should be called ATTR_n_PATH, where n is an integer that makes the name unique within the scope of the current node. You can create multiple ATTR_n_PATH Properties for the same node, with different values of n, to assign multiple attribute Features to the node. This means that you can assign multiple configuration attributes to the same Item. You can use the same ATTR_n_PATH names in different nodes without conflict.
■ To optionally propagate the value of a configuration attribute to the selected children of an Item, you can define a Property on the Item that specifies a propagation mode. This Property should be called ATTR_MODE.
■ To optionally override, for a particular Item, the default flexfield segment name, context, or mode specified by ATTR_NAME, ATTR_CONTEXT, or ATTR_MODE, you can define Properties on the Item called ATTR_n_NAME, ATTR_n_CONTEXT, or ATTR_n_MODE, respectively. In these Property names,
Configuration Attributes 9-31 Implementing Configuration Attributes for Output
n must match n in the ATTR_n_PATH Property that points to the attribute Feature whose segment name, context, or mode you are overriding. Table 9–7 on page 9-30 provides details on the Properties used for defining configuration attributes. If you need to use different names for the Properties, then you must modify the example Functional Companion, as described in Section 9.3.4 on page 9-39.
Table 9–7 Properties for Defining Configuration Attributes Property Name Type Description ATTR_NAME Text Default flexfield name that identifies the attribute Feature metadata. The value of the Property is the name of the corresponding segment in the descriptive flexfield. This Property is mandatory for the methodology to work. The ATTR_NAME values used in Example 9–6 on page 9-32 correspond to the attribute names in Example 9–4 on page 9-31. ATTR_CONTEXT Text Default flexfield context that identifies the attribute Feature metadata. The value of the Property is the flexfield context of all the corresponding segments in the descriptive flexfield. This Property is mandatory for the methodology to work. ATTR_n_PATH Text Flexfield assignment for the Item. The value of the Property is the node path to the attribute Feature that stores the configuration attribute value for the Item. The node path is relative to the Model that contains the Item. In naming this Property, use the integer indicated by n to make the name of the Property unique within the scope of the current node. You can define otherProperties with the same name in other nodes without conflict. This Property is mandatory for the methodology to work.
9-32 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
Table 9–7 (Cont.) Properties for Defining Configuration Attributes Property Name Type Description ATTR_MODE Integer Default propagation mode of the configuration attribute value. The value of the Property indicates the depth to which the value of the current Item is propagated in the Model. Propagation means that the Functional Companion writes the value of the configuration attribute for the current Item into the CZ_CONFIG_ATTRIBUTES table for all the Items specified by the propagation mode. The modes are:
■ 0 = Propagate the value only to the current Item. (This is the default mode, if this Property is omitted.)
■ 1 = Propagate the value to the current Item, and to its immediate selected children.
■ 2 = Propagate the value to the current Item, and to all its selected descendents. ATTR_n_NAME Text Overriding flexfield name. A Property with this name overrides the default value specified by ATTR_NAME. Use ATTR_n_NAME to specify a different flexfield segment for the Item to which the Property ATTR_n_PATH is attached, using the same value of n. ATTR_n_CONTEXT Text Overriding flexfield context. A Property with this name overrides the default value specified by ATTR_CONTEXT. Use ATTR_n_CONTEXT to specify a different flexfield context for the Item to which the Property ATTR_n_PATH is attached, using the same value of n. ATTR_n_MODE Integer Overriding propagation mode. A Property with this name overrides the default value specified by ATTR_MODE. Use ATTR_n_MODE to specify a different flexfield context for the Item to which the Property ATTR_n_PATH is attached, using the same value of n.
9.3.3.2 Example of Model Structure
Example Structure Assume the structure of the sample BOM Model shown in Example 9–3:
Example 9–3 Structure of Sample BOM Model BOM-ATO1-Model |__BOM-OC-VINYL | |__BOM-Item1
Configuration Attributes 9-33 Implementing Configuration Attributes for Output
| |__BOM-Item2 |__BOM-OC-WOOD | |__BOM-Item3 | |__BOM-Item4 |__BOM-OC-HANDLE |__BOM-PTO-Item5 |__BOM-PTO-Item6
Assume that you want to create the configuration attributes on that BOM Model shown in Example 9–4:
Example 9–4 Configuration Attributes for Sample BOM Model BOM-ATO1-Model COMMON-ATTR-1 COMMON-ATTR-2 BOM-OC-VINYL VINYL-ATTR-1 VINYL-ATTR-2 BOM-OC-WOOD WOOD-ATTR-1 WOOD-ATTR-2
Assume that you have defined the descriptive flexfield contexts and segments for these configuration attributes shown in Example 9–5:
Example 9–5 Flexfield Contexts and Segments for Sample BOM Model COMMON COMMON-ATTRIB1 COMMON-ATTRIB2 VINYL VINYL-ATTRIB1 VINYL-ATTRIB2 WOOD WOOD-ATTRIB1 WOOD-ATTRIB2
Given the preceding assumptions, you would use Oracle Configurator Developer to create model structure like that shown in Example 9–6:
Example 9–6 Configuration Model Structure for Sample BOM Model BOM-ATO1-Model |
9-34 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
|
Explanation of Example This explanation applies to Example 9–6 and the similar examples that follow in this section.
■ Properties of the nodes in the Model are indicated by the following convention:
Configuration Attributes 9-35 Implementing Configuration Attributes for Output
The angle brackets ( < > ) are not part of the Property name; their purpose is to visually distinguish the Properties from the other elements of the Model structure. The quotation marks around property_value are not themselves part of the value; they indicate that the type of the Property value is Text.
■ Feature1 through Feature6 are the attribute Features. These correspond to the descriptive flexfield segments that you would have defined. The ATTR_NAME values are the flexfield segment names shown in Example 9–5 on page 9-32.
■ The Properties of the attribute Features shown in Example 9–6 are described in Table 9–7 on page 9-30.
■ COMPONENT-ATTRIBUTES is a Component with Instances set to Minimum = 1 and Maximum = 1. Its purpose is to contain the attribute Features in a single location, for convenient access. This is an optional design technique.
Note: It is not necessary to group attribute Features in a Component, although that design is used in this example. The attribute Features can be located anywhere in the Model, as long as the ATTR_n_PATH Properties point to them. See Section 9.3.3.4 on page 9-37 for an explanation of the rules for placement of attribute Features.
Database Results With reference to the explanation of the table CZ_CONFIG_ATTRIBUTES given in Section 9.3.1 on page 9-25, the design in Example 9–6 on page 9-32 would produce database records like those shown in Table 9–8 on page 9-34. For the sake of compactness, the combination of the columns CONFIG_HDR_ID, CONFIG_REV_NBR, and CONFIG_ITEM_ID is represented here by the column named Item, ATTRIBUTE_CATEGORY is represented here by the column named Context, and only a few of the ATTRIBUTEn columns are shown. The ATTRIBUTEn columns contain the name of the attribute Feature that contains their value, rather than the value itself.
9-36 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
Table 9–8 Example Attribute Properties (Database Results) Item Context Attribute1 Attribute2 Attribute3 Attribute4 BOM-ATO1-Model COMMON (Feature1) (Feature2) BOM-OC-VINYL COMMON (Feature1) (Feature2) BOM-OC-VINYL VINYL (Feature3) (Feature4) BOM-Item1 VINYL (Feature3) BOM-Item2 VINYL (Feature3) BOM-OC-WOOD COMMON (Feature1) (Feature2) BOM-OC-WOOD WOOD (Feature5) (Feature6) BOM-OC-HANDLE COMMON (Feature1) (Feature2)
9.3.3.3 Alternative Modeling Strategies
Reusing an Attribute Value for Multiple Items It may be required that more than one Item needs the same configuration attribute value. You can accomplish this by making the Items point to the same instance of the attribute Feature that contains that value. You do this by setting the same value for the attribute Property ATTR_n_PATH in each Item. This strategy is shown in Example 9–7.
Example 9–7 Reusing an Attribute Value for Multiple Items ... | |__BOM-Item1 | |
In this example, both BOM-Item1 and BOM-Item2 point to Feature14, so they both define the value of ATTR_1_PATH as COMPONENT_ATTRIBUTES.Feature14.
Configuration Attributes 9-37 Implementing Configuration Attributes for Output
The result is that the same configuration attribute value is written in CZ_CONFIG_ATTRIBUTES for both of these Items.
Database Results With reference to the explanation for Table 9–8 on page 9-34, the design in Example 9–7 on page 9-35 would produce database records like those shown in Table 9–9 on page 9-35.
Table 9–9 Reusing an Attribute Value for Multiple Items (Database Results) Item Context Attribute1 Attribute2 Attribute3 Attribute4 ... BOM-Item1 VINYL (Feature14) BOM-Item2 VINYL (Feature14) ...
As an alternative, you could assign the attribute to the parent node in the Model and use the ATTR_MODE property to propagate the value to all selected children.
Reusing an Attribute Value for Multiple Contexts It may be required that the same configuration attribute value has to be written as the value of more than one descriptive flexfield segment. You can accomplish this by making the Item specify an overriding context (ATTR_n_CONTEXT) and attribute name (ATTR_n_NAME) as part of the assignment. This strategy is shown in Example 9–8.
Example 9–8 Reusing an Attribute Value for Multiple Contexts ... | |__BOM-Item1 |
9-38 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
Database Results With reference to the explanation for Table 9–8 on page 9-34, the design in Example 9–8 on page 9-36 would produce database records like those shown in Table 9–10 on page 9-36.
Table 9–10 Reusing an Attribute Value for Multiple Contexts (Database Results) Item Context Attribute1 Attribute2 Attribute3 Attribute4 ... BOM-Item1 VINYL (Feature14) BOM-Item1 SHIPPING (Feature14) ...
Using Different Contexts with Different Values Multiple contexts assigned to the same Item should be modeled as multiple attribute Features with different ATTR_CONTEXT Property values. Then, the Item will have ATTR_NAME Properties for each of those Features. This strategy is shown in Example 9–9.
Example 9–9 Using Different Contexts with Different Values ... | |__BOM-Item3 |
Configuration Attributes 9-39 Implementing Configuration Attributes for Output
Database Results With reference to the explanation for Table 9–8 on page 9-34, the design in Example 9–9 on page 9-37 would produce database records like those shown in Table 9–11 on page 9-37.
Table 9–11 Using Different Contexts with Different Values (Database Results) Item Context Attribute1 Attribute2 Attribute3 Attribute4 ... BOM-Item3 WOOD (Feature15) BOM-Item3 PRICING (Feature16) BOM-Item3 MFG (Feature17) ...
9.3.3.4 Special Considerations This section covers some important considerations that may affect your configuration model’s structure.
Referenced Models Your Model can include child Models that are connected through References (as is the case with most imported BOM Models). If this is the case, then the output Functional Companion (described in Section 9.3.4 on page 9-39) traverses the entire structure of the root Model and all other Models that it references, collecting configuration attribute data from any attribute Properties whose names conform to the conventions in Table 9–7 on page 9-30.
Location of Attribute Features You must give careful thought to where you create attribute Features. An attribute Feature can be located anywhere in a Model, providing that the location is a node path that can be specified by the Property ATTR_n_PATH. Consequently, the node path to an attribute Feature must be specified as relative to the Model that contains the Item. The output Functional Companion (described in Section 9.3.4 on page 9-39) first finds the node that is the root of the entire configuration model, and then searches from there for Properties whose names conform to the conventions in Table 9–7 on page 9-30.
9-40 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
Because the Functional Companion can find Features in child Models that are connected through References (see Referenced Models on page 9-38), it is possible to assign a configuration attribute value to an Item in a parent Model by pointing (with the Property ATTR_n_PATH) to an attribute Feature in a referenced child Model. Such a node path must include the names of any child Models between the Model that contains the Item and the attribute Feature. However, a node path that you can express as a Text Property value can only point down the tree of Models, not upwards. Consequently, it is not possible to point to an attribute Feature in a parent Model, and therefore you cannot assign a configuration attribute value from a parent Model to an Item in a child Model. To summarize: parent Models can use attribute Features defined in referenced child Models; child Models cannot use attribute Features defined in parent Models. If follows from the preceding facts that if you intend to use a referenced child Model without the parent Model, then you must ensure that it contains all the attribute Features that are employed as the configuration attributes on the Items in that Model.
Multiple Component Instances in the Node Path The node path to an attribute Feature, which is specified by the Property ATTR_n_PATH, cannot include any Components that can be instantiated multiple times. (Such a Component is one that has its Instances set to a Maximum greater than 1, so that more than one runtime instance of the Component can be created and configured.) The existence of multiple instances of a Component in a node path makes the path ambiguous. Consequently, you cannot place any attribute Features inside such a Component, because the output Functional Companion (described in Section 9.3.4 on page 9-39) cannot resolve the correct path to that attribute Feature.
Required Items Configuration attributes cannot be defined for required Items in a BOM Model, because such Items are not configurable, and consequently are not imported when you import the BOM Model into Oracle Configurator Developer to define a configuration model. (See Chapter 4 for details about importing.)
9.3.3.5 Creating Functional Companion Rules Set the Definition of the Functional Companion rule as shown in the following table:
Configuration Attributes 9-41 Implementing Configuration Attributes for Output
Rule Definition Attribute Definition Value Base Component The node from which the Functional Companion will search for configuration attribute Properties. See Section 9.3.4 on page 9-39 and Section 9.3.3.4 on page 9-37 for background. Type Event-Driven Implementation Java Program String The name of the Java class that implements the output Functional Companion. For the example, this is WriteAttributes (Example B–2 on page B-10).
For more details on defining Functional Companion rules, see the Oracle Configuration Interface Object (CIO) Developer’s Guide. For details on defining other kinds of configuration rules, see the Oracle Configurator Developer User’s Guide.
9.3.4 The Output Functional Companion The output Functional Companion performs the work of transferring the configuration attribute data from a configured runtime instance of the Model to the CZ_CONFIG_ATTRIBUTES table. A Functional Companion has been specially written to support the configuration attribute methodology described in this chapter. The source code for this Functional Companion is provided in Example B–2 on page B-10. This section describes its operation at a high level. For the Functional Companion to operate on the configuration model, you must create a configuration rule that associates the Functional Companion with the Model that contains the configuration attribute Properties, as illustrated in Example 9–6 on page 9-32, and described in Section 9.3.3 on page 9-28. The example Functional Companion does not have to be modified, if you modify your Model in the manner described in Section 9.3.3. In modifying your Model, you must follow the conventions described for naming Properties in order for the Functional Companion to be able to collect values for the attribute Features.
Note: The example Functional Companion assumes that your Model is a BOM Model. If it is not, then see Section 9.3.7.1, "Modifying the Functional Companion" on page 9-46.
9-42 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
Here is a high-level description of the operation of the output Functional Companion: 1. During a configuration session, the end user selects options that, through configuration rules, result in the entry of configuration attribute data in the attribute Features of your Model. 2. The end user terminates the session successfully by clicking the Done button, which saves the configuration. 3. The Functional Companion overrides the afterSave() method of AutoFunctionalCompanion, so it is triggered after the configuration is successfully saved. 4. The Functional Companion clears the CZ_CONFIG_ATTRIBUTES table of any configuration attribute data for the Items in the current configuration model. This prevents previously entered data from conflicting with data from the latest configuration session. 5. The Functional Companion traverses the entire configuration model, collecting the values of all the attribute Features by using the Properties described in Section 9.3.3 on page 9-28. This collection includes the names of the descriptive flexfield contexts and segment names for the flexfield data, recorded through the ATTR_NAME and ATTR_CONTEXT Properties. 6. The Functional Companion queries the descriptive flexfield tables in the Oracle Applications database for the name of each ATTRIBUTEn column in the CZ_CONFIG_ATTRIBUTES table that corresponds to the context and segment name for each configuration attribute value. 7. The Functional Companion prepares and executes a PL/SQL statement that inserts into the CZ_CONFIG_ATTRIBUTES table all of the configuration attribute data from the latest configuration session for your configuration model.
9.3.5 Using Configuration Attributes in the Downstream Application In order to use the configuration attribute data that is collected from a configuration session, you must implement some significant customizations to your downstream application. The specifics vary according to the particular application. This section begins with an explanation of how the data is stored into the CZ_CONFIG_ATTRIBUTES table (Section 9.3.5.1), and then outlines some strategies for customizing the downstream application.
Configuration Attributes 9-43 Implementing Configuration Attributes for Output
9.3.5.1 Storing Output Data for Downstream Use At the end of a configuration session, the end user closes the runtime Oracle Configurator by clicking the Done button, which saves the configuration, triggering the output Functional Companion (described in Section 9.3.4 on page 9-39). The Functional Companion writes the saved configuration attribute data into the CZ_CONFIG_ATTRIBUTES table in the following way:
■ Traverse the tree of the configuration model, visiting each configuration item.
■ For each configuration item, collect the values of all the attribute Properties that help define configuration attributes, and the values of all the configuration attributes themselves. The rules that govern how the attribute Properties point to attribute Features are described in Table 9–7 on page 9-30.
■ Obtain the identity of the current item in the configured model’s structure from the runtime configuration instance, and write these values into the columns CONFIG_HDR_ID, CONFIG_REV_NBR, CONFIG_ITEM_ID.
■ Obtain the flexfield context for the configuration attribute from the value defined for the Property ATTR_CONTEXT on the attribute Feature, and write this value into ATTRIBUTE_CATEGORY. The combination of CONFIG_HDR_ID, CONFIG_REV_NBR, CONFIG_ITEM_ID, and ATTRIBUTE_CATEGORY constitutes the primary key for the table, which uniquely identifies the configuration attribute value that applies to the given item for the given context.
■ Query the Oracle Applications flexfield tables to determine which ATTRIBUTEn column of the CZ_CONFIG_ATTRIBUTES table is associated with the value of the Property ATTR_NAME on the attribute Feature, and write the value of the Feature (that is, the value of the configuration attribute) into that ATTRIBUTEn column. This description has been somewhat simplified for clarity. For details on how the Functional Companion implements this database update, see the commented source code in Example B–2 on page B-10.
Example of Storing Output Data Assume a flexfield definition like the one shown in Figure 9–3 on page 9-28. Assume, for some configuration item, that the value of the attribute Property ATTR_CONTEXT is EAST, the value of the attribute Property ATTR_NAME is COLOR, and that the attribute Property ATTR_n_PATH points to an attribute Feature named COLOR, whose value is WHITE. The Functional Companion queries the flexfield tables, specifying the value of the flexfield context as EAST, and the value
9-44 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
of the flexfield segment (that is, the configuration attribute) as COLOR. According to the flexfield definition in Figure 9–3, the column in which to write the value of the configuration attribute is ATTRIBUTE1, so the Functional Companion writes the selected value of COLOR into ATTRIBUTE1, for the current configuration item. Example 9–10 on page 9-42 shows a PL/SQL query that displays the value of ATTRIBUTE1 for a particular configuration item (which Oracle Configurator identifies internally by a configuration header ID, revision number, and item ID), and Example 9–11 on page 9-42 shows a result of the query.
Example 9–10 Query for Value of ATTRIBUTE1 SELECT config_hdr_id, config_rev_nbr, config_item_id, attribute_category, attribute1 FROM cz_config_attributes WHERE -- a configuration item config_hdr_id = 18900 AND config_rev_nbr = 1 AND config_item_id = 34 AND -- the flexfield context attribute_category = 'EAST';
Example 9–11 Value of ATTRIBUTE1 CONFIG_HDR_ID CONFIG_REV_NBR CONFIG_ITEM_ID ATTRIBUTE_CA ATTRIBUTE1 ------18900 1 34 EAST WHITE
9.3.5.2 Using Output Data in Downstream Applications The configuration attribute output data stored in the CZ_CONFIG_ATTRIBUTES table is available for use by downstream applications. However, you must put the data into a form that your particular application can use, which probably requires some degree of customization, depending on the specific characteristics of the application. This section identifies some strategies for customization.
■ You must write a custom procedure (see Section 9.3.5.3 on page 9-43) to retrieve the data from the CZ_CONFIG_ATTRIBUTES table and insert it into the descriptive flexfields used by the downstream application.
■ You may decide to read the configuration attribute values directly from the CZ_CONFIG_ATTRIBUTES table without inserting them into the downstream application’s flexfields. However, doing so requires customizing the
Configuration Attributes 9-45 Implementing Configuration Attributes for Output
downstream application's forms to read the attributes and assigning them to the correct data.
■ For the Oracle Advanced Pricing application, the attributes must be stored as flexfields on the order lines.
■ Advanced Pricing is designed to read data from any table, and does not require special customization to do so. For other Oracle Applications the attributes must be stored in the interface table flexfields for those applications.
■ For configuration attributes to be displayed in any form that displays an auto-created final assembly (such as Flow Workstation), they need to be stored as attributes on the flow schedules.
■ If you need to define configuration attributes on required BOM items in a downstream application, then you must explicitly join them with their parents and populate them to get attribute values. The reason behind this requirement is that required items in a BOM are not configurable, and consequently cannot be imported into an Oracle Configurator configuration model. Therefore, they are not present during a configuration session, and cannot be written into the CZ_CONFIG_ATTRIBUTES table by the output Functional Companion.
9.3.5.3 Linking Configuration Attributes to Flexfields You can use the following approach in designing a custom procedure (which you must write) that links the information in a configuration attribute to a flexfield for a downstream application:
■ A line ID is passed as an argument to the custom procedure. The line ID is a primary key that points to the host application’s equivalent of a configurable line item in an order or quote.
■ The line item contains a foreign key formed from the columns CONFIG_HDR_ID, CONFIG_REV_NBR, CONFIG_ITEM_ID in CZ_CONFIG_ATTRIBUTES. This key points to the set of records in CZ_CONFIG_ATTRIBUTES associated with the selected items in the order or quote.
■ Use CZ_CONFIG_ATTRIBUTES.ATTRIBUTE_CATEGORY to provide a description of the flexfields that apply to the context for the particular component from the order or quote.
9-46 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
■ The flexfield definition contains information about the names of the columns (ATTRIBUTEn, and so on) in CZ_CONFIG_ATTRIBUTES that contain the desired configuration attributes. Alternatively, depending on your implementation, the reading code in your custom procedure could assume certain hardcoded column names for each segment in a particular context.
9.3.5.4 Downstream User Interfaces Downstream, these are the ways to use configuration attributes in an application’s user interface:
■ Using the standard Oracle Applications UI with the application flexfields (see Oracle Applications User Interface with Flexfields on page 9-44)
■ Directly feeding the configuration attribute table into a customized host application UI (see Custom Application User Interface on page 9-45) The choice of UI depends on your needs.
Oracle Applications User Interface with Flexfields The data in the populated table CZ_CONFIG_ATTRIBUTES needs to be inserted into the flexfields on the downstream application table. For that purpose you must write a custom procedure to populate those flexfields on the target records. See the information on Oracle Workflow APIs in the Oracle Workflow Guide for details. See Figure 9–4 on page 9-44.
Figure 9–4 Flow for Oracle Applications UI with Flexfields
It is also acceptable to join the configuration attribute table before populating it in the application's schema, if the resulting data is a derivation from the configuration and legacy attributes. In that case, writing to the downstream table's flexfields after calculations could be more efficient than separating the steps in different tables. See Figure 9–5 on page 9-45.
Configuration Attributes 9-47 Implementing Configuration Attributes for Output
Note: The Oracle Advanced Pricing application is designed to read data from any table, and does not require special customization to do so.
Figure 9–5 Flow for Oracle Applications UI with Flexfields with Joined Tables
Custom Application User Interface For custom-built UIs, there may be no need to populate the flexfields on the downstream application’s table. Instead, you might be able to join the application table with CZ_CONFIG_ATTRIBUTES. This is a valid approach if the data that is represented by the configuration attributes is used by the downstream application only for display purposes. See Figure 9–6 on page 9-45.
Figure 9–6 Flow for Custom Application UI
Note: Details about possible customizations depend on the downstream application and your implementation. Please refer to the relevant documentation.
9.3.6 Maintaining the Output Solution If you make any changes made to the flexfield definitions in Oracle Applications (using Oracle Application Developer responsibility), or make any changes to a BOM (in Oracle Bills of Materials) that is the basis for an imported Model, then these
9-48 Oracle Configurator Implementation Guide Implementing Configuration Attributes for Output
changes must be reflected in the Model in Oracle Configurator Developer through the refresh process. See Section 4.8 on page 4-23 for details on refreshing models. Performing a refresh of your model may result in requiring changes to the structure of Features and Properties described in Section 9.3.3, "Modifying the Model" on page 9-28.
9.3.7 Optional Flows This section describes optional tasks that you may need to perform that are not part of the flow described in Figure 9–1 on page 9-24.
Caution: If you do not follow the model design described in Section 9.3.3 on page 9-28, the output Functional Companion, as provided, will not work.
9.3.7.1 Modifying the Functional Companion The example Functional Companion provided with this methodology (Example B–2 on page B-10) does not have to be modified, if you modify your Model in the manner described in Section 9.3.3 on page 9-28, and if your Model is a BOM Model.
Note: Be sure to check the Oracle Configuration Interface Object (CIO) Developer’s Guide for a description of the Java development skills required for success with Functional Companions.
Modifying the Property Names In modifying your Model, you must follow the conventions for naming Properties described in Table 9–7 on page 9-30 in order for the Functional Companion to be able to collect values for the attribute Features. If you want to use different Property names, then you must modify certain character strings, which are typographically highlighted in Example 9–12 on page 9-46, so that they match your own Property names.
Example 9–12 Strings for Property Names in the Functional Companion ... private Map getAttributes(BomNode node) { ...
Configuration Attributes 9-49 Implementing Configuration Attributes for Output
if (name.startsWith("ATTR_")) { ... int beginningIndex = new String("ATTR_"). length(); StringTokenizer tokens = new StringTokenizer(name.substring(beginningIndex), "_", false); ... if (name.endsWith("PATH")) { ... else if (name.endsWith("MODE")) { ... else if (name.endsWith("CONTEXT")) { ... else if (name.endsWith("NAME")) { ... private class Attribute implements Comparable { ... Property prop = m_feature.getPropertyByName("ATTR_CONTEXT"); ... Property prop = m_feature.getPropertyByName("ATTR_NAME");
Using Non-BOM Models The example Functional Companion assumes that your Model is a BOM Model, like the Model in Example 9–6 on page 9-32. If your Model is a Component type, then you must modify the traverseBomTree() method of the Functional Companion to test whether the Component containing a given configuration attribute Item is a Model, so that the value of the ATTR_n_PATH Property can be resolved correctly. See the description of the ATTR_n_PATH Property described in Table 9–7 on page 9-30 for background. (For clarity, you may also wish to rename the traverseBomTree() method to indicate that it is not traversing a BOM Model.) In order to determine whether a Component is a Model (that is, the root of the configuration, or a Reference), use the following test: private void traverseBomTree(RuntimeNode node, List parentAttributes) { ... if (node.getReferringOrDatabaseID() != node.getDatabaseID() ) { // the Component is a Model, so collect its attributes ... } ... }
9-50 Oracle Configurator Implementation Guide 10 Deploying Oracle Configurator
Deployment involves making a runtime Oracle Configurator available to end users. This chapter describes activities required to complete deployment of a runtime 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 the Oracle Configurator Custom Web Deployment Guide. See Section 1.7, "Oracle Configurator Environments" on page 1-7 for an overview of possible deployment environments and architecture.
10.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. The Oracle Configurator Servlet connects the runtime 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 10-1 Calling an Embedded Oracle Configurator
10.1.1 Java Applet Requirements The requirements for the runtime 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 Runtime Oracle Configurator" on page 5-5.
10.1.2 DHTML Requirements The requirements for the runtime Oracle Configurator to use the DHTML interface are:
■ Stylesheets and JavaScript must be enabled in the browser running the DHTML runtime 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 runtime 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 Runtime Oracle Configurator" on page 5-5. Table 10–1, " Information Details Mapped to Oracle Configurator Documentation" on page 10-3 lists Oracle Configurator Documentation for more information:
10-2 Oracle Configurator Implementation Guide Deployment Strategies
Table 10–1 Information Details Mapped to Oracle Configurator Documentation 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 Using Oracle Configurator Developer Oracle Configurator Developer User’s Guide
10.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:
■ Section 10.2.1, "Architectural Considerations" on page 10-3
■ Section 10.2.2, "Server Considerations" on page 10-4
■ Section 10.2.3, "Implementing Oracle Configurator with Secure Sockets Layer" on page 10-6
■ Section 10.2.4, "Network Considerations" on page 10-10
■ Section 10.2.5, "Multiple Language Support Considerations" on page 10-11 While it is not possible to provide an exact prescription for your particular application, this section describes the principles that affect a typical Oracle Configurator deployment.
10.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 Section 10.2.2, "Server Considerations" on page 10-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. Model loading and data access depend 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:
Deploying Oracle Configurator 10-3 Deployment Strategies
■ 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)
■ 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)
10.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 Section 10.2.1, "Architectural Considerations" on page 10-3 and Section 10.3.4, "Load Balancing" on page 10-15 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 or complexity of any Functional Companions used by the application
■ The number of CPUs
10-4 Oracle Configurator Implementation Guide Deployment Strategies
■ The memory per CPU The JDK uses about 16 MB. The JVM for each JServ uses about 45 MB. Oracle Configurator uses native threads.
■ The number of JServ instances running
■ The number of connections available in the connection pool (see Section 10.2.2.1, "Connection Pooling" on page 10-5)
■ The frequency and type of database accesses caused by user actions (see Section 10.3.4, "Load Balancing" on page 10-15)
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.
10.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
Deploying Oracle Configurator 10-5 Deployment Strategies
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. 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 this parameter is not configurable.
10.2.3 Implementing Oracle Configurator with Secure Sockets Layer Secure Sockets Layer (SSL) is a protocol that creates a secure connection between a client and a server machine and enables you to safely transmit private documents over the Internet. SSL uses a public key to encrypt data that is transferred over the SSL connection. (A key is a password or table needed to decipher encoded data.) To set up Oracle Configurator to run in SSL mode, perform the following: 1. Install Internet Application Server (iAS) version 1.0.2.2 or later and configure it to run SSL. For more information, consult the Apache 1.3 User's Guide and the Apache-SSL Web site at http://www.apache-ssl.org. 2. Install Oracle Configurator version 16-38 or later. (To upgrade to version 16-38, apply patch 2102442.) See theOracle Configurator Installation Guide. 3. Edit the Oracle Configurator system parameters in jserv.properties file to use the SSL server and port. This step is required for SSL to support HTML hosting applications such as iStore. See Section 10.2.3.1, "Editing jserv.properties for Secure Sockets Layer" on page 10-7. 4. Verify that AltBatchValidateURL is present and set correctly in the ORAAPPS_ INTEGRATE section of the CZ_DB_SETTINGS table. See Section 10.2.3.2, "Verifying AltBatchValidateURL" on page 10-8.
10-6 Oracle Configurator Implementation Guide Deployment Strategies
Note: AltBatchValidateURL is not seeded in the CZ_DB_ SETTINGS table. In order to implement SSL, you must set AltBatchValidate URL. See Table 3–1, " CZ_DB_SETTINGS" on page 3-7.
5. Set the profile option BOM:Configurator URL of UI Manager to the secure URL. This option should be set at the Site level, but it can also be set at the User level. For information about setting profile options, see the Oracle Applications User’s Guide. You can test this URL using the same method described in Section 10.2.3.2, "Verifying AltBatchValidateURL" on page 10-8. 6. Set up your Web browser and Jinitiator to support SSL. See Section 10.2.3.3, "Enabling the Oracle Configurator Client for Secure Sockets Layer" on page 10-8.
10.2.3.1 Editing jserv.properties for Secure Sockets Layer To support SSL, all of the Oracle Configurator system parameters in the jserv.properties file must use the secure "https" protocol, and must include the name and port number of your secure server. (All URLs that require an SSL connection start with "https" instead of "http".) In Example 10–1, myservername is the name of the iAS server and 443 is the secure server port number.
Example 10–1 The jserv.properties File System Parameters for SSL wrapper.bin.parameters=-Dcz.uiservlet.templateURL=https://myse rvername.com:443/OA_HTML/US/czFraNS.htm wrapper.bin.parameters=-Dcz.uiservlet.URL=https://myservername .com:443/configurator/oracle.apps.cz.servlet.UiServlet wrapper.bin.parameters=-Dcz.uiservlet.proxyscript=https://myse rvername.com:443/OA_HTML/czProxy.js wrapper.bin.parameters=-Dcz.html.source.treeview=https://myser vername.com:443/OA_HTML/cztree.htm wrapper.bin.parameters=-Dcz.html.source.display=https://myserv ername.com:443/OA_HTML/czdisp.htm
Deploying Oracle Configurator 10-7 Deployment Strategies
wrapper.bin.parameters=-Dcz.uiservlet.blaftemplateURL=https:// myservername.com:443/OA_HTML/US/czBlafTemplate.htm wrapper.bin.parameters=-Dcz.uiservlet.formtemplateURL=https:// myservername.com:443/OA_HTML/US/czFormTemplate.htm wrapper.bin.parameters=-Dcz.html.source.formtreeview=https://m yservername.com:443/OA_HTML/czFormTree.htm Each parameter should be defined on a single line in jserv.properties.
10.2.3.2 Verifying AltBatchValidateURL The AltBatchValidateURL setting allows the batch validation process to bypass the URL that would normally be used for batch validation. This is needed if Oracle Configurator uses SSL. The value of AltBatchValidateURL must be your non-secure URL. Since the batch validation process communicates between the database and Web server, it is not necessary for this communication to use SSL. The batch validation process runs, for example, when booking an order in Oracle Order Management. Enter the following command in SQL*Plus to determine the value of AltBatchValidateURL: SELECT * FROM cz_db_settings WHERE setting_id = 'AltBatchValidateURL'; The value returned is the same as the Java property cz.uiservlet.url for the non-secure URL. For example: http://servername.com:8808/configurator/oracle.apps.cz.servlet .UiServlet You can test this URL by entering it in a Web browser followed by "?test=version". The result should be the build and schema version of Oracle Configurator running on the Apache server. For example: http://servername.com:8808/configurator/oracle.apps.cz.servlet .UiServlet?test=version For more information about cz.uiservlet.url, see Servlet Considerations in the Oracle Configurator Installation Guide.
10.2.3.3 Enabling the Oracle Configurator Client for Secure Sockets Layer You can run an Oracle Configurator in SSL mode using either a DHTML or a Java applet UI, but some setup is required.
10-8 Oracle Configurator Implementation Guide Deployment Strategies
10.2.3.3.1 DHTML Setup Because a DHTML UI runs in a Web browser, you must ensure that your browser supports SSL. To enable your browser to support SSL, perform the following:
■ In Netscape Navigator, choose Communicator > Tools > Security Info, then click Navigator. Select from the available options to enable SSL.
■ In Internet Explorer, choose Tools > Internet Options, then select the Advanced tab. Scroll down to view the Security section, and select the appropriate options to enable SSL.
10.2.3.3.2 Java applet Setup To use SSL with the Java applet, you must:
■ Install JInitiator version 1.1.8.3 or later (prior versions do not support SSL)
■ Set up the root certificate If you know the root certificate, go the JInitiator security directory (for example, C:\Program Files\Oracle\JInitiator 1.1.8.13\lib\security), open the file certdb.txt, and add the root certificate to the end of the file. If you do not know the root certificate, perform the following: 1. Using Internet Explorer, navigate to your secure URL. 2. Choose File > Properties. 3. Click Certificates. 4. Select the Certification Path tab, then select the top entry for the Certification path. 5. Click View Certificate. 6. Select the Details tab, then click Copy to File. 7. Click Next, then choose "Base64 encoded X.509 (.CER)". 8. Click Next, then enter a filename to export the certificate (for example, test.cer). 9. Click Next, then Finish. Close the Certificate and Properties windows by clicking OK. 10. Using a text editor, open the file you saved in step 8.. 11. Copy the certificate, then paste its contents at the end of the certdb.txt file. 12. Save your work.
Deploying Oracle Configurator 10-9 Deployment Strategies
Note: It is strongly recommended that you also have your server’s SSL certificate signed by one of the following Certificate Authorities (CAs): VeriSign Inc.; RSA Data Security Inc.; GTE Corporationl; GTE CyberTrust Solutions Inc. If your certificate is not signed by one of these CAs, you may receive errors when running the Java applet in SSL mode.
10.2.4 Network Considerations There are a number of network issues that can cause serious problems for your deployment if not handled correctly.
10.2.4.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.
10.2.4.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 runtime Oracle Configurator as DHTML) with a particular instance of the servlet engine (JServ). 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
10-10 Oracle Configurator Implementation Guide Deployment Strategies
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.
10.2.4.3 Miscellaneous Issues ■ Your application must run in an environment that resolves domain names to allow it to communicate with other servers
■ You must 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.
10.2.5 Multiple Language Support Considerations See Section 1.8.1, "Multiple Language Support" on page 1-14 for Multiple Language Support implementation.
10.2.6 Changing Development and Production Database Instances You may want to change your development and production database instances and migrate your data from one instance to another. Example 10–2, "Change Development and Production Database Instances" describes a scenario and the necessary steps for migrating the data.
Example 10–2 Change Development and Production Database Instances
■ Database instance (X) with Inventory Items, BOMs, Catalogs, descriptive elements, and CZ projects
■ Database instance (Y) that has Items, BOMs that were exported from instance x, Catalogs that have been recreated, and descriptive elements.
Deploying Oracle Configurator 10-11 Deployment Strategies
Database instance Y is now going to serve as both the development and production instance. CZ projects will be published to end users in this instance locally. Development continues in this instance. Solution: 1. After BOMs and Inventory have been duplicated in Y, you must run the Check All Models/Bills Similarity concurrent program in order to correct any mismatches that are reported by the program. See Section 1.9.1.6.3, "Check All Models/Bill Similarity" on page 1-27. 2. After you determine the configuration models in the CZ schema that are in synch with the BOM Models, you can run the Synchronize All Models concurrent program.
Note: In order to run the Synchronize all models concurrent program pointing to database instance Y, there must be a server definition for Y on X and the Import Enabled flag set to Yes for the server Y. See Table 1–2, " Oracle Configurator Concurrent Programs for Server Administration" on page 1-18.
3. Migrate CZ data from X to Y. 4. Synchronize Y locally. Before synchronizing locally, the Import Enabled flag for the Local server, for example Y, must be set to Yes in the Define Remote Server concurrent program.
Note: The local synchronization is necessary in order to set the Import source to Local since after migration the Import source for the existing models is still defined as Remote.
10.2.7 Pre-Loading the Oracle Configurator Servlet You can improve performance when initializing the Oracle Configurator Servlet by preloading your Active Models. Initializing means loading an Active Model for the first time during an OC Servlet session. When preloading Models:
■ Create a text file containing an initialization message. For details about getting the OC Servlet to process this file, see the information in the Oracle Configurator Installation Guide about the OC Servlet property cz.uiservlet.pre_load_ filename.
10-12 Oracle Configurator Implementation Guide Deployment Tasks
When composing your initialization message: 1. Omit the pricing callback parameters (pricing_package_name, configuration_session_key, price_multi_item_proc). 2. Omit the ATP callback parameters (atp_package_name, configuration_ session_key, get_atp_dates_proc, requested_date). 3. Omit the parameter config_creation_date. This will ensure that you always preload the latest published Active Model. The date will default to the system date (SYSDATE). 4. Either of the parameters alt_database_name or database_id can be used for prelodaing. If loading Models for specific languages, then database_id and the icx_ session_ticket parameter are required for the database session in that language. 1. When preloading set the OC Servlet property cz.uiserver.lazyload=false. This ensures that all the screens in your Model’s user interface are also cached at startup.
10.3 Deployment Tasks Several categories of tasks are necessary in order to system test and "go live" with a runtime Oracle Configurator.
■ Section 10.3.1, "Setting Profile Options" on page 10-13
■ Section 10.3.2, "Establishing End User Access" on page 10-14
■ Section 10.3.3, "Load Testing" on page 10-14
■ Section 10.3.4, "Load Balancing" on page 10-15
10.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 runtime Oracle Configurator. The values of these profile options may be different for deployment than they were for development. You must set up and update profile option values for users of runtime Oracle Configurators within Oracle Applications. See the Oracle Configurator Installation
Deploying Oracle Configurator 10-13 Deployment Tasks
Guide for information about profile options required for running a runtime Oracle Configurator within Oracle Applications, Release 11i.
10.3.1.1 Profile Option - Populate Decimal Quantity Flag The runtime Oracle Configurator embedded in your host application respects the type of numeric input (integer and decimal, or integer-only) you provided. If you allow input of decimal quantities for a Feature or BOM Item, then end users can enter values containing up to 9 digits after the decimal point. Otherwise, only integer quantities can be entered. Oracle Configurator validates the quantity inputs before saving a configuration, and presents error information to the end user. The same behavior applies when a host application uses the runtime Oracle Configurator for batch validation.
10.3.2 Establishing End User Access End users of the runtime 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 runtime Oracle Configurator. This action causes the calling application to initialize a runtime Oracle Configurator session with an initialization message. When an end user saves a configuration and exits a runtime Oracle Configurator session, the runtime Oracle Configurator sends the calling application a termination message to terminate the runtime Oracle Configurator session. For more information about the initialization message, see the Oracle Configurator Custom Web Deployment Guide. For more information about the behavior of the runtime Oracle Configurator as it affects end users, see the Oracle Configurator Developer User’s Guide.
10.3.3 Load Testing 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:
■ Section 10.3.3.1, "Stress Testing"
■ Section 10.3.3.2, "User Activity Testing"
10-14 Oracle Configurator Implementation Guide Deployment Tasks
10.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 recommended level.
10.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. 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 what the application will handle.
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.
10.3.4 Load Balancing See Section 10.2.2, "Server Considerations" on page 10-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 10-15 Deployment Tasks
10-16 Oracle Configurator Implementation Guide A Import Tables
A.1 Overview This appendix contains the following information:
■ Section A.2, "List of Import Tables" in the Oracle Configurator schema
■ Section A.3, "Dependencies Among Import Tables"
■ Section A.4, "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-12.
A.2 List of Import Tables The import tables below 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_LOCALIZED_TEXTS 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 these columns will eventually be desupported.
A strong dependency means a value is required to successfully import 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. The following Table A–1, " Dependencies Among Oracle Configurator Schema Import Tables" lists the dependencies.
Table A–1 Dependencies Among Oracle Configurator Schema Import Tables for Foreign Type of Import Table Name Depends on Surrogate Key dependencies 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_ CZ_IMP_PROPERTY FSK_PROPERTY STRONG NO PROPERTY_VALUE CZ_IMP_ITEM_ CZ_IMP_ITEM_ FSK_ITEMMASTER STRONG NO PROPERTY_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 (Cont.) Dependencies Among Oracle Configurator Schema Import Tables for Foreign Type of Import Table Name Depends on Surrogate Key dependencies Default 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" lists the Disposition codes that may result when required columns are queried against the source table.
Table A–2 Import Table Field Disposition Codes Code Disposition M marked for modification I marked for insertion R rejected
Table A–3, " Import Table Record Status Codes" describes the record status codes for required columns that have not resulted in a successful query.
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 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" through Table A–11, " Description of Fields in CZ_IMP_PS_NODES Import Table", describe all of the columns in the Oracle Configurator schema import tables.
Import Tables A-3 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. Table A–4, " Description of Fields in CZ_IMP_DEVL_PROJECT Import Table". This table contains data that will be imported (or rejected) by the import process.
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 from which this record is effective
A-4 Oracle Configurator Implementation Guide Import Tables
Table A–4 (Cont.) 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 of 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 (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. Null 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
Table A–5, " Description of Fields in CZ_IMP_ITEM_MASTER Import Table". This table contains data that will be imported (or rejected) by the import process.
Import Tables A-5 Import Tables
Table A–5 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 the Item (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 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. Null 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-6 Oracle Configurator Implementation Guide Import Tables
Table A–5 (Cont.) Description of Fields in CZ_IMP_ITEM_MASTER Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE DELETED_FLAG N Y CHAR (1) Indicates (1/0) whether this record has been deleted EFF_FROM N Y DATE Indicates the beginning date from 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 (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-7 Import Tables
Table A–5 (Cont.) Description of Fields in CZ_IMP_ITEM_MASTER Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE LAST_UPDATED_ N Y NUMBER Records the login name of 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 you do not use this column as it will eventually be desupported.
Table A–6, " Description of Fields in CZ_IMP_ITEM_PROPERTY_VALUE Import Table". This table contains property values for Item Master items. Data can be imported from Oracle Inventory or a legacy system.
A-8 Oracle Configurator Implementation Guide Import Tables
Table A–6 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 Oracle Configurator 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. Null 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) indicates this record has been deleted EFF_FROM N Y DATE Indicates the beginning date from 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)
Import Tables A-9 Import Tables
Table A–6 (Cont.) Description of Fields in CZ_IMP_ITEM_PROPERTY_VALUE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE 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 (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 of 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_ITEM_TYPE on USER_STR03. Note: It is recommended that you do not use this column as it will eventually be desupported.
A-10 Oracle Configurator Implementation Guide Import Tables
Table A–6 (Cont.) 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_TYPE on USER_STR03. Note: It is EXT recommended that you do not use this column as it will eventually be desupported. 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–7, " Description of Fields in CZ_IMP_ITEM_TYPE Import Table". This table contains data that will be imported (or rejected) by the import process.
Import Tables A-11 Import Tables
Table A–7 Description of Fields in CZ_IMP_ITEM_TYPE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE ITEM_TYPE_ID N Y NUMBER Designates the Oracle Configurator ID 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 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. Null 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) whether 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 matching CZ_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 from 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)
A-12 Oracle Configurator Implementation Guide Import Tables
Table A–7 (Cont.) Description of Fields in CZ_IMP_ITEM_TYPE Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE 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 (40) CREATION_DATE N Y DATE The date on which this record was created LAST_UPDATE_ N Y DATE The date on which the record was last modified DATE CREATED_BY N Y NUMBER The user that created this record LAST_UPDATED_ N Y NUMBER The login name of the user that last modified this record BY SECURITY_MASK N Y VARCHAR2 Reserved for future use in record-level access control (40)
Table A–8, " Description of Fields in CZ_IMP_ITEM_TYPE_PROPERTY Import Table". This table contains data that will be imported (or rejected) by the import process.
Import Tables A-13 Import Tables
Table A–8 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 REC_STATUS N Y VARCHAR2 Records a coded status describing the import results for (4) this record. Null 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 from 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)
A-14 Oracle Configurator Implementation Guide Import Tables
Table A–8 (Cont.) Description of Fields in CZ_IMP_ITEM_TYPE_PROPERTY Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE 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 (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 of 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
Import Tables A-15 Import Tables
Table A–8 (Cont.) Description of Fields in CZ_IMP_ITEM_TYPE_PROPERTY Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE 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_ITEM_TYPE on USER_STR03. Note: It is recommended that you do not use this column as it will eventually be desupported. 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
Table A–9, " Description of Fields in CZ_IMP_LOCALIZED_TEXTS Import Table" . This table the combined base and translations table for all texts displayed in the Configurator runtime User Interface. The table contains data that will be imported (or rejected) by the import process.
A-16 Oracle Configurator Implementation Guide Import Tables
Table A–9 Description of Fields in CZ_IMP_LOCALIZED_TEXTS Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE LAST_UPDATE_ N Y NUMBER Records the login ID under which this record was last LOGIN (15) updated LOCALE_ID N Y NUMBER (9) Associates this localized text with the locale in which it applies CREATION_DATE N Y DATE Standard field recording the date this record was created LOCALIZED_STR N Y VARCHAR2 Contains a version of an CZ_INTL_TEXTS string localized (2000) for the locale specified in LOCALE_ID INTL_TEXT_ID N Y NUMBER (9) Locale-independent identity of this text, per CZ_INTL_ TEXTS table LAST_UPDATE_ N Y DATE Standard field recording the date/time this record was DATE last updated DELETED_FLAG N Y VARCHAR2 Standard flag; 0 indicates the record is active, 1 means (1) deleted. Other values are reserved. EFF_FROM N Y DATE Currently not used EFF_TO N DATE Currently not used CREATED_BY N Y NUMBER Standard field recording the ID of the user that created (15) this record LAST_UPDATED_ N Y NUMBER Standard field recording the ID of the user that last BY (15) updated this record SECURITY_MASK N Y VARCHAR2 Reserved for future use (40) EFF_MASK N Y VARCHAR2 Reserved for future use (40) CHECKOUT_USER N Y VARCHAR2 Reserved for future use (40) LANGUAGE N Y VARCHAR2 Language code for the language to which this record (4) applies ORIG_SYS_REF N Y VARCHAR2 Contains a reference value identifying the source data (255) from which this record is imported
Import Tables A-17 Import Tables
Table A–9 (Cont.) Description of Fields in CZ_IMP_LOCALIZED_TEXTS Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE SOURCE_LANG Y VARCHAR2 Code of the actual language of the LOCALIZED_STR field (4) RUN_ID Y NUMBER Contains a number indicating the import run in which this record was loaded/processed REC_STATUS Y VARCHAR2 Records a coded status describing the import results for (4) t hi s re co rd . Nu ll i n d ic at es t he rec o rd ha s no t ye t it indicates the record has not yet been completely processed. DISPOSITION Y VARCHAR2 Indicates whether the record was inserted, updated, (1) unchanged, or rejected
Table A–10, " Description of Fields in CZ_IMP_PROPERTY Import Table". This table contains data that will be imported (or rejected) into CZ_PROPERTIES table by the import process.
Table A–10 Description of Fields in CZ_IMP_PROPERTY Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE PROPERTY_ID N Y NUMBER Contains the Oracle Configurator ID 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)
A-18 Oracle Configurator Implementation Guide Import Tables
Table A–10 (Cont.) Description of Fields in CZ_IMP_PROPERTY Import Table
COLUMN_NAME Description Required Nullable DATA_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 REC_STATUS N Y VARCHAR2 Records a coded status describing the import results for (4) this record. Null 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) whether 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 matching CZ_ 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 from 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
Import Tables A-19 Import Tables
Table A–10 (Cont.) Description of Fields in CZ_IMP_PROPERTY Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE 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 (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 of 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–11, " Description of Fields in CZ_IMP_PS_NODES Import Table". This table contains data that will be imported (or rejected) into CZ_PS_NODES table by the import process.
A-20 Oracle Configurator Implementation Guide Import Tables
Table A–11 Description of Fields in CZ_IMP_PS_NODES Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE PS_NODE_ID N Y NUMBER Designates the Oracle Configurator ID 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 Oracle Configurator 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 Oracle Configurator item ID for this record NAME N Y VARCHAR2 Contains the OC name for the Model node (for example, (255) Component, Feature, etc.) RESOURCE_FLAG N Y CHAR (1) Indicates whether this node is a Total (T) or Resource (R) 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 Oracle Configurator 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, and so on. 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 whether the node is a parent node
Import Tables A-21 Import Tables
Table A–11 (Cont.) Description of Fields in CZ_IMP_PS_NODES 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. 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 whether this record is a system node. For FLAG example, either root node or template for roots TREE_SEQ Y N NUMBER Contains the order of this child node within the parent. Disposition if null = ERR. COUNTED_ N Y CHAR (1) Indicates whether this Feature has counted Options OPTIONS_FLAG UI_OMIT N Y CHAR (1) Indicates whether the node is visible in the runtime UI UI_SECTION N Y NUMBER Indicates in which section of the UI the node is visible BOM_ N Y NUMBER Indicates how the imported node will be displayed. TREATMENT 1 = skip 2= leaf 3 = flatten 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. Null indicates the record has not yet been completely processed.
A-22 Oracle Configurator Implementation Guide Import Tables
Table A–11 (Cont.) Description of Fields in CZ_IMP_PS_NODES Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE DISPOSITION N Y CHAR (1) Indicates whether the record was inserted, updated, unchanged, or rejected DELETED_FLAG N Y CHAR (1) Indicates (1/0) whether this record has been deleted EFF_FROM N Y DATE Indicates the beginning date from 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
Import Tables A-23 Import Tables
Table A–11 (Cont.) Description of Fields in CZ_IMP_PS_NODES Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE CREATED_BY N Y NUMBER Identifies the user that created this record LAST_UPDATED_ N Y NUMBER Records the login name of 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_ITEM_TYPE on USER_STR03. Note: It is recommended that you do not use this column as it will eventually be desupported. 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_TYPE on USER_STR03. Note: It is EXT recommended that you do not use this column as it will eventually be desupported.
A-24 Oracle Configurator Implementation Guide Import Tables
Table A–11 (Cont.) Description of Fields in CZ_IMP_PS_NODES Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE 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_ITEM_TYPE on USER_STR03. Note: It is recommended that you do not use this column as it will eventually be desupported. 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_ITEM_TYPE on USER_STR03. Note: It is EXT recommended that you do not use this column as it will eventually be desupported. 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
Import Tables A-25 Import Tables
Table A–11 (Cont.) Description of Fields in CZ_IMP_PS_NODES Import Table
COLUMN_NAME Description Required Nullable DATA_TYPE BOM_ITEM_TYPE N Y NUMBER Indicates whether this node is a Model, Standard, or Option Class 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 Option Class nodes, indicates the minimum quantity SELECTED selection for its children MAXIMUM_ N Y NUMBER For Option Class 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
A-26 Oracle Configurator Implementation Guide B Code Examples
This chapter contains code examples that support other chapters of this document. These examples are fuller and longer than the examples provided in the rest of this document, which are often fragments. See the cited background sections for details.
B.1 Using Configuration Attributes for Input This example demonstrates how to use a Functional Companion to transfer configuration attribute data into a configuration model from a host application.
■ To use the example, you must modify it in accordance with the instructions in Section 9.2.4, "Modifying the Functional Companion Example" on page 9-14.
■ For details about the specific example that is supported by this code, see Section 9.2.1, "Example for Implementing Input Configuration Attributes" on page 9-7.
■ For general background, see Section 9.2, "Implementing Configuration Attributes for Input" on page 9-7.
Note: If you have installed Oracle Configurator Developer and the Oracle Configurator documentation, then the source code for Example B–1 is available as the file CfgInputExample.java, in the folder OC_Developer_installation\doc\code_ examples.
Code Examples B-1 Using Configuration Attributes for Input
Example B–1 Using Configuration Attributes for Input (CfgInputExample.java) /*======+ | Copyright (c) 2002 Oracle Corporation, Redwood Shores, CA, USA | | All rights reserved. | +======+ | FILENAME | CfgInputExample.java +======*/ import oracle.apps.cz.cio.AutoFunctionalCompanion; import oracle.apps.cz.cio.IRuntimeNode; import oracle.apps.cz.cio.IOption; import oracle.apps.cz.cio.IOptionFeature; import oracle.apps.cz.cio.IState; import oracle.apps.cz.cio.LogicalException; import oracle.apps.cz.cio.NoSuchChildException; import oracle.apps.cz.cio.TransactionException; import oracle.apps.cz.utilities.Assert; import oracle.apps.cz.utilities.CheckedToUncheckedException; import oracle.apps.cz.utilities.NameValuePairSet; import java.sql.*; import com.sun.java.util.collections.List; import com.sun.java.util.collections.Iterator;
/** * CfgInputExample provides the skeleton code needed to transfer * parameters from the database into the model. * * This Functional Companion must be attached to each model that it * is to work with. Use Oracle Configurator Developer to create the * relationship between model and companion. */
// It is strongly recommended that only input parameters be transferred // from the database to the model. That is, this companion should not // make calculations or decide validity of a configuration. The model // should use rules to perform those operations. The maintenance of the model // will be made easier if the Functional Companion is kept simple.
// This companion is written to run from Oracle Quoting. // // The model that this FC is attached to should have an Option Feature
B-2 Oracle Configurator Implementation Guide Using Configuration Attributes for Input
// named 'US_State' (case sensitive) with some, if not all, Options // that represent each state of the United States. The names of the // Options should be the uppercase two-letter postal codes for each state // (for example, CA, NY, MA, RI).
// You must extend AutoFunctionalCompanion in order to use the onNew() // and onRestore() methods. public class CfgInputExample extends AutoFunctionalCompanion {
private Long mOrderLineNumber = null; // Retrieved from the user's session private Long mApplicationId = null; // From the user session information private String mUsState = null;
public void onNew() throws LogicalException { doInputAttributeTransfer(); }
public void onRestore() throws LogicalException {
// Implementers have to decide if the transfer of // attributes needs to occur during the restoration of // a saved model. In most cases, the best practice is to // retrieve the current value from the database since // the value can be changed from the host application.
// If an attribute is truly only set once, when the configuration // is newly created, then the attribute should not be // restored. Use inititial requests, which are described in the // Oracle CIO Developer's Guide.
doInputAttributeTransfer();
}
/** * Transfers input attribute data into a configuration model. * */ private void doInputAttributeTransfer() throws LogicalException {
// The general steps in passing config attributes are: // 1. Get the session information. // 2. Use the database to get the information to be transferred into the model. // 3. Set the model values.
Code Examples B-3 Using Configuration Attributes for Input
getSessionParameters();
// If there are no parameters for this session then continue.
if (mOrderLineNumber == null) return;
// Implementers have to decide if attributes should be treated // differently, depending on which application is calling Oracle // Configurator. In this example assume that the information // should be transferred only for Oracle Quoting.
if (mApplicationId.longValue() != 697) return;
getInputAttributes(); transferInputAttributesIntoModel(); }
/** * Retrieves the session information from the configuration * and makes the information available. */ private void getSessionParameters() {
// The initialization message holds the parameters supplied by the // application when Oracle Configurator was started.
NameValuePairSet initParams = getRuntimeNode().getConfiguration().getInitParameters();
String paramValue = null;
String paramValue = (String)initParams.getValueByName("client_line");
// Each host application calling Oracle Configurator can pass this parameter // with different content. You need to cast the type of the parameter value // if the host application does not pass a string for the client_line.
if (paramValue != null) mOrderLineNumber = Long.valueOf(paramValue);
// This example only uses the client_line parameter. // To use other parameters, write additional get and set statements for them.
// The other parameters that may be useful, depending on the application, are: // client_header // client_line_detail
B-4 Oracle Configurator Implementation Guide Using Configuration Attributes for Input
// The remainder of the initialization parameters are described // in the Oracle Configurator Custom Web Deployment Guide.
// You must identify the host application that called Oracle Configurator.
paramValue = (String)initParams.getValueByName("calling_application_id"); if (paramValue != null) mApplicationId = Long.valueOf(paramValue); }
/** * Retrieves the input attributes from the database. */ private void getInputAttributes() {
Connection conn = getRuntimeNode().getConfiguration().getContext().getJDBCConnection(); PreparedStatement pStmt = null; ResultSet rs; int ret;
try {
// Define a custom query to extract the desired database value // for the configuration attribute. // In this case, get the value for the U.S. state associated // with a quote line.
try {
if (mApplicationId.longValue() == 697) {
String sql = "select p.state " + "from hz_parties p, " + " aso_quote_headers_all_v q, " + " ASO_QUOTE_LINES_ALL_V l " + "where p.party_id = q.cust_account_id " + "and l.quote_header_id = q.quote_header_id " + "and l.quote_line_id = ?";
// Prepared statements generally provide good performance.
pStmt = conn.prepareStatement(sql);
// Put the line number into the first (and only) parameter // of the PreparedStatement, for quote_line_id.
Code Examples B-5 Using Configuration Attributes for Input
pStmt.setLong(1, mOrderLineNumber.longValue());
// Execute the query, putting the results into the rows of the ResultSet.
rs = pStmt.executeQuery();
// Iterate through the ResultSet and get the first value.
try { if (rs.next()) {
// If a record exists, retrieve the value(s) and consider if // there are nulls.
// The first (and only) return value in this example is from HZ_PARTIES.STATE. // Store the value from column 1 of the ResultSet into mUsState.
mUsState = rs.getString(1);
// Check to see if the value was null. This check is critical // for integer and other data types.
if (rs.wasNull()) mUsState = null; } else {
// If no record exists in the ResultSet, raise an exception and // provide a message.
// Since this Functional Companion is being called as // part of a regular process, the FC expects that the // values of client_line and other parameters are // correct. They may not be correct, or (more likely) // the query is not accurate.
// Put as much useful information into the error message as possible.
String s = "CfgInputExample.getInputAttributes: Did not find record for " + "client_line " + mOrderLineNumber + ".\n\n" + "query = " + sql;
throw new RuntimeException(s); } } finally {
B-6 Oracle Configurator Implementation Guide Using Configuration Attributes for Input
// Make sure that all ResultSets are closed. If they are // not closed, then it is easy to use up the allotment of // database cursors.
rs.close(); } } } finally {
// Make sure that all prepared statements are closed. If they are // not closed, then it is easy to use up various database resources.
if (pStmt != null) pStmt.close(); } } catch (SQLException se) {
// Any problem with the database will // stop the session. The error will be logged.
throw new RuntimeException("CfgInputExample.getInputAttributes: " + se.toString()); } }
/** * Transfers the information from the database into the model structure. */ private void transferInputAttributesIntoModel() throws LogicalException {
// Use a method customized for the specific configuration attribute.
transferUsState(); }
/** * Specialized method to transfer attribute data * into an Option Feature with a specified name. */ private void transferUsState()throws LogicalException {
// Find the model element(s) that will be set with the // configuration attribute value.
Code Examples B-7 Using Configuration Attributes for Input
// In this example, search for a Feature named "US_State". This // feature has Options corresponding to the postal codes for some // individual states in the United States.
// This FC starts its search from the model node that the FC is // associated with, and stops when it finds the first object named // "US_State".
// If, for any reason, there is not a "US_State" then return. The model's // configuration rules or defaults will provide the value.
// If an attribute is truly only set once, when the // configuration is newly created, then use initial requests, // which are described in the Oracle CIO Developer's Guide.
if (mUsState == null) return;
IRuntimeNode rtNode = findFirstNodeByName(getRuntimeNode(), "US_State");
// Implementers have to decide whether failing to find the node // should be treated as an exception. In this example, it is not // an issue if the model lacks the model element.
if (rtNode == null) return;
// Implementers should verify that the node is what is expected. // Changes to the configuration model can lead to runtime errors, // such as ClassCastExceptions, if there is no verification.
if (rtNode.getType() != IRuntimeNode.OPTION_FEATURE) return;
// Find the option for the US State. In this example, if the option is not found // do not consider it a problem. The model's configuration rules or defaults // will decide what to do.
// Use the attribute value retrieved from the database to find the // Option with the matching name.
IOption option = (IOption)findFirstNodeByName(rtNode, mUsState); if (option == null) return;
// Set the value of the attribute Feature, by selecting the Option.
try { option.select();
B-8 Oracle Configurator Implementation Guide Using Configuration Attributes for Input
} catch(TransactionException te) {
// There should be never be a problem with CIO transactions. If one // occurs then provide as much informaiton as possible.
throw new RuntimeException("CfgInputExample.transferInputAttributesIntoModel: " + te.toString());
} }
/** * Utility method to locate the first model node with a specified name * found in a search starting from the current node. */ private IRuntimeNode findFirstNodeByName(IRuntimeNode parent, String name) {
IRuntimeNode found = null;
if (parent == null) return null; if (!parent.hasChildren()) return null;
try { found = parent.getChildByName(name); } catch (NoSuchChildException nsce) {
// Recurse through the children
Iterator it = parent.getChildren().iterator(); while (it.hasNext()) { found = findFirstNodeByName((IRuntimeNode)it.next(), name); if (found != null) return found; } } return found; } }
Code Examples B-9 Using Configuration Attributes for Output
B.2 Using Configuration Attributes for Output This example demonstrates how to use a Functional Companion to transfer configuration attribute data from a configuration model into a host application.
■ To use the example, you may modify it in accordance with the instructions in Section 9.3.4, "The Output Functional Companion" on page 9-42.
■ For general background, see Section 9.3, "Implementing Configuration Attributes for Output" on page 9-24.
Note: If you have installed Oracle Configurator Developer and the Oracle Configurator documentation, then the source code for Example B–1 is available as the file WriteAttributes.java, in the folder OC_Developer_installation\doc\code_ examples.
Example B–2 Using Configuration Attributes for Output (WriteAttributes.java)
/*======+ | Copyright (c) 2002 Oracle Corporation, Redwood Shores, CA, USA | | All rights reserved. | +======+ | FILENAME | | WriteAttributes.java | | DESCRIPTION | | | | NOTES | | | | DEPENDENCIES | | | | HISTORY | | 26-Nov-01 Anupam Miharia Created. | +======*/ import oracle.apps.fnd.common.Context; import oracle.apps.cz.cio.AutoFunctionalCompanion; import oracle.apps.cz.cio.Property; import oracle.apps.cz.cio.OptionFeatureNode; import oracle.apps.cz.cio.BooleanFeature; import oracle.apps.cz.cio.Configuration; import oracle.apps.cz.cio.CountFeature; import oracle.apps.cz.cio.IntegerNode;
B-10 Oracle Configurator Implementation Guide Using Configuration Attributes for Output
import oracle.apps.cz.cio.DecimalNode; import oracle.apps.cz.cio.ComponentSet; import oracle.apps.cz.cio.NoSuchChildException; import oracle.apps.cz.cio.BomNode; import oracle.apps.cz.cio.TextNode; import oracle.apps.cz.cio.BomModel; import oracle.apps.cz.cio.RuntimeNode; import oracle.apps.cz.cio.IRuntimeNode; import com.sun.java.util.collections.Map; import com.sun.java.util.collections.Collection; import com.sun.java.util.collections.HashMap; import com.sun.java.util.collections.ArrayList; import com.sun.java.util.collections.Iterator; import com.sun.java.util.collections.TreeSet; import com.sun.java.util.collections.List; import java.util.StringTokenizer; import java.sql.Connection; import java.sql.PreparedStatement; import java.sql.SQLException; import java.sql.ResultSet;
/** * @author Anupam Miharia * * This is a sample implementation of an afterSave Functional Companion * that is used to write the attributes associated with BOM nodes to * the CZ_CONFIG_ATTRIBUTES table. The implementation is based on the * attribute association as described in the documentation. */ public class WriteAttributes extends AutoFunctionalCompanion { public static final int ATTR_MODE_CURRENT = 0; public static final int ATTR_MODE_CURRENT_AND_IMMEDIATE_CHILDREN = 1; public static final int ATTR_MODE_CURRENT_AND_ALL_CHILDREN = 2; Configuration config = null; /** * An afterSave FC is called after saving the configuration. * This collects all the attributes from the BOM nodes and writes * them to the database. */ public void afterSave() { config = getRuntimeNode().getConfiguration(); // First, clear all attribute data for this configuration from // the CZ_CONFIG_ATTRIBUTES table. try {
Code Examples B-11 Using Configuration Attributes for Output
clearConfigAttributes(config); } catch (SQLException sqle) { throw new RuntimeException("Error in clearing the previous attribute data"); } // Starting from the root, call traverseBomTree on all top level BOM nodes. RuntimeNode root = (RuntimeNode)config.getRootComponent(); if (root instanceof BomNode) { traverseBomTree(root, new ArrayList()); } else { Iterator iter = root.getChildren().iterator(); while (iter.hasNext()) { RuntimeNode child = (RuntimeNode)iter.next(); if (child instanceof BomNode || child instanceof ComponentSet) { traverseBomTree(child, new ArrayList()); } } } }
/** * Iterates over the BOM tree and writes the attributes for each BOM node. * @param node Can either be a BomNode or a ComponentSet. * @param parentAttributes List of attributes from ancestors that is to be * applied to this node. */ private void traverseBomTree(RuntimeNode node, List parentAttributes) { List childAttribs = null;
if (!(node instanceof ComponentSet)) { BomNode bomNode = (BomNode)node;
// Write attribute data only for selected BOM nodes if (!bomNode.isSelected()) return;
// First get the attributes corresponding to this BOM node Map attributes = getAttributes(bomNode);
// Then group the attrbutes of this node with those from its ancestors // and write the combined set to the CZ_CONFIG_ATTRIBUTES table. // Also get the list of attributes that have to be applied to this // node's children. childAttribs = groupAndWriteAttributes(bomNode, attributes, parentAttributes); } else { // Pass along the parent's attributes to the children for a ComponentSet. childAttribs = parentAttributes;
B-12 Oracle Configurator Implementation Guide Using Configuration Attributes for Output
}
// Now recursively visit all the children subtrees passing along the list // of attributes that have to be applied to its children. Iterator iter = node.getChildren().iterator(); while (iter.hasNext()) { RuntimeNode child = (RuntimeNode)iter.next(); if (child instanceof BomNode || child instanceof ComponentSet) { traverseBomTree(child, childAttribs); } } }
/** * Group the attributes together by: * 1. Combining the attributes passed from the ancestors with the current set. * 2. Combining the attributes that have a commmon context in a single list. * 3. Creating a list of child Attributes to be applied to the node's children. * @param node The BOM node whose attributes are to be written * @param attributes Attributes corresponding to the given BOM node * @param parentAttributes List of attributes from ancestors that is to be * applied to the given BOM node. */ private List groupAndWriteAttributes(BomNode node, Map attributes, List parentAttributes) { // Attributes from parent go only one level deep if their mode = 1. // Set their mode = 0 here so that they don't propagate further. Iterator iter = parentAttributes.iterator(); while (iter.hasNext()) { Attribute attr = (Attribute)iter.next(); if (attr.getMode() == ATTR_MODE_CURRENT_AND_IMMEDIATE_CHILDREN) { attr.setMode(ATTR_MODE_CURRENT); } } // List of attributes from this node to be applied to children. List childAttributes = new ArrayList(); // Create an aggregate map of attributes collected by context because // we can have multiple attributes for this node having a common context. // The key of this map is the attribute context and the value is // a HashMap of attribute name and attribute value. HashMap ctxAttrsMap = new HashMap(); // Combine the list of attributes for this node with that from the parent. // Make it a Set so that all duplicate attributes are eliminated. // Look at definition of Attribute.equals(). Collection allAttributes = new TreeSet(); allAttributes.addAll(attributes.values());
Code Examples B-13 Using Configuration Attributes for Output
allAttributes.addAll(parentAttributes);
// Iterate over the combined list of attributes. iter = allAttributes.iterator(); while (iter.hasNext()) { Attribute attribute = (Attribute)iter.next();
// If the attribute mode is not CURRENT-only then add it to the // childAttributes list if (attribute.getMode() != ATTR_MODE_CURRENT) { childAttributes.add(attribute); } // We have to combine all attributes belonging to this node by context // as well, so that it can be written as a single row in the // CZ_CONFIG_ATTRIBUTES table. String ctx = attribute.getAttrContext();
HashMap values = (HashMap)ctxAttrsMap.get(ctx); if (values == null) { values = new HashMap(); ctxAttrsMap.put(ctx, values); } if (attribute.hasBooleanValue()) { values.put(attribute.getName(), new Boolean(attribute.getBooleanValue())); } else if (attribute.hasIntegerValue()) { values.put(attribute.getName(), new Integer(attribute.getIntValue())); } else if (attribute.hasDecimalValue()) { values.put(attribute.getName(), new Double(attribute.getDecimalValue())); } else if (attribute.hasStringValue()) { values.put(attribute.getName(), attribute.getStringValue()); } else { values.put(attribute.getName(), "NULL"); } }
// Write all the attributes to the database after we are done grouping // them appropriately. writeAttributes(node, ctxAttrsMap); return childAttributes; }
/** * Writes the attributes for the given node to the database. * The parameter 'attributes' is a Map where the key is the attribute context * and the value is a map of attribute name and attribute value.
B-14 Oracle Configurator Implementation Guide Using Configuration Attributes for Output
*/ private void writeAttributes(BomNode node, Map attributes) { Iterator iter = attributes.keySet().iterator(); while (iter.hasNext()) { String context = (String)iter.next(); Map nameValuePairs = (Map) attributes.get(context); insertAttributes(node, context, nameValuePairs, config.getContext()); } }
/** * Inserts the attributes belonging to a given node and context into * the CZ_CONFIG_ATTRIBUTES table. */ public int insertAttributes (BomNode node, String attrContext, Map attributes, Context ctx) { Connection conn = ctx.getJDBCConnection(ctx); PreparedStatement pStmt = null; int ret;
try { try { String insertString = " INSERT INTO CZ_CONFIG_ATTRIBUTES (CONFIG_HDR_ID, CONFIG_REV_NBR, CONFIG_ITEM_ID, ATTRIBUTE_CATEGORY"; String valueString = " VALUES(?,?,?,?";
// Build an insert string based on the attribute name for the attribute context. Collection keys = attributes.keySet(); Iterator keyIter = keys.iterator(); while (keyIter.hasNext()) { insertString = insertString + "," + getAttributeFieldName (attrContext, (String)keyIter.next(), ctx); valueString = valueString + ",?"; } insertString = insertString + ")"; valueString = valueString + ")";
String sql = insertString + valueString; pStmt = conn.prepareStatement(sql);
//Bind/set values to the parameters // Add config_hdr_id. pStmt.setLong(1,config.getConfigHeaderIdLong()); // Add config_rev_nbr. pStmt.setLong(2,config.getConfigHeaderRevisionLong()); // Add config_item_id.
Code Examples B-15 Using Configuration Attributes for Output
pStmt.setLong(3,node.getConfigItemID()); // Add flexfield context for attribute. pStmt.setString(4,attrContext );
// Iterate over attributes. int n = 5; List attrValues = new ArrayList(); attrValues.addAll(attributes.values()); Iterator iter = attrValues.iterator();
while (iter.hasNext()) { pStmt.setString(n++, iter.next().toString()); }
ret = pStmt.executeUpdate(); } finally { if(pStmt != null) pStmt.close(); } } catch (SQLException e) { throw new RuntimeException("Error Inserting into CZ_CONFIG_ATTRIBUTES table" + e); } return ret; }
/** * Return the column name in CZ_CONFIG_ATTRIBUTES to write this attribute value to, * given an attribute context name, attribute name, and database context. */ public String getAttributeFieldName (String attrContext, String attribute, Context ctx) { Connection conn = ctx.getJDBCConnection(ctx); ResultSet rs = null; PreparedStatement pStmt = null; String sql, columnName = null;
try { try { sql = "SELECT dfu.application_column_name " + "FROM FND_DESCR_FLEX_COLUMN_USAGES DFU, " + "FND_DESCRIPTIVE_FLEXS FDL , FND_APPLICATION FAN " + "WHERE fan.application_short_name = 'CZ' " + "AND dfu.application_id = fan.application_id " + "AND fdl.application_id = fan.application_id " + "AND fdl.APPLICATION_TABLE_NAME = 'CZ_CONFIG_ATTRIBUTES' " + "AND dfu.descriptive_flexfield_name = fdl.descriptive_flexfield_name " +
B-16 Oracle Configurator Implementation Guide Using Configuration Attributes for Output
"AND dfu.descriptive_flex_context_code = ? " + "AND end_user_column_name = ? ";
pStmt = conn.prepareStatement(sql); pStmt.setString(1,attrContext ); pStmt.setString(2,attribute );
rs = pStmt.executeQuery(); if (rs.next()) { columnName = rs.getString(1); } else { throw new RuntimeException("No column name found for context = " + attrContext + " and attribute = " + attribute); } } finally { // close all if (rs != null) rs.close(); if (pStmt != null) pStmt.close(); } } catch (SQLException e) { throw new RuntimeException("Error querying attribute names"); }
return columnName; }
/** * Clears all attribute data for this configuration from * the CZ_CONFIG_ATTRIBUTES table. */ public void clearConfigAttributes(Configuration config) throws SQLException { long configHdrId = config.getConfigHeaderIdLong(); long configHdrRev = config.getConfigHeaderRevisionLong(); Connection conn = config.getContext().getJDBCConnection(); PreparedStatement pStmt = null; int ret; try { String sql = "DELETE FROM CZ_CONFIG_ATTRIBUTES WHERE CONFIG_HDR_ID=? AND CONFIG_REV_NBR=?"; pStmt = conn.prepareStatement(sql); pStmt.setLong(1, configHdrId); pStmt.setLong(2, configHdrRev); ret = pStmt.executeUpdate(); } finally { if (pStmt != null) pStmt.close(); }
Code Examples B-17 Using Configuration Attributes for Output
}
/** * Returns a map of attributes associated with this BOM node by reading * its properties from the database. The map is keyed by the attribute * index and the values are Attribute objects. */ private Map getAttributes(BomNode node) { HashMap attributes = new HashMap(); int defaultMode = 0; // Iterate over the properties and see if we have any attribute properties. Iterator iter = node.getProperties().iterator(); while (iter.hasNext()) { Property prop = (Property)iter.next(); String name = prop.getName(); // All attribute properties start with "ATTR_". if (name.startsWith("ATTR_")) { // Get the index of this attribute. int index = 0; int beginningIndex = new String("ATTR_"). length(); StringTokenizer tokens = new StringTokenizer(name.substring(beginningIndex), "_", false); if (tokens.hasMoreTokens()) { try { index = Integer.parseInt(tokens.nextToken()); } catch (NumberFormatException nfe) { // This could be the default mode. if (name.endsWith("MODE")) { defaultMode = prop.getIntValue(); continue; } else { throw new RuntimeException("Attribute properties on BOM nodes should follow " + "the pattern ATTR_int_* where 'int' is an integer. "); } } } // If we do not already have an attribute with this index, create one // and put it in the map. Attribute attr = (Attribute)attributes.get(new Integer(index)); if (attr == null) { attr = new Attribute(node, index); attributes.put(new Integer(index), attr); } // Assign the appropriate property to this attribute. if (name.endsWith("PATH")) {
B-18 Oracle Configurator Implementation Guide Using Configuration Attributes for Output
attr.setPath(prop.getStringValue()); } else if (name.endsWith("MODE")) { attr.setMode(prop.getIntValue()); } else if (name.endsWith("CONTEXT")) { attr.setAttrContext(prop.getStringValue()); } else if (name.endsWith("NAME")) { attr.setName(prop.getStringValue()); } else { throw new RuntimeException("Attribute properties on BOM nodes should end up with " + "with either \"PATH\", \"MODE\", \"CONTEXT\", or \"NAME\""); } } }
// Apply the default mode on all attributes. iter = attributes.values().iterator(); while (iter.hasNext()) { Attribute attribute = (Attribute)iter.next(); if (!attribute.hasMode()) { attribute.setMode(defaultMode); } }
return attributes; }
/** * Class to represent an Attribute of a BOM node. */ private class Attribute implements com.sun.java.util.collections.Comparable { private BomNode m_node; private int m_index; private String m_path; private int m_mode; private String m_attrContext; private String m_name; private RuntimeNode m_feature; private boolean found = false;
Code Examples B-19 Using Configuration Attributes for Output
protected Attribute(BomNode node, int index) { m_node = node; m_index = index; m_path = null; m_mode = -1; m_attrContext = null; m_name = null; m_feature = null; } public String getPath() { return m_path; }
public boolean hasMode() { return (m_mode != -1); }
public int getMode() { return m_mode; }
public String getAttrContext() { if (m_attrContext == null && getFeature() != null) { Property prop = m_feature.getPropertyByName("ATTR_CONTEXT"); if (prop != null) { m_attrContext = prop.getStringValue(); } } return m_attrContext; }
public String getName() { if (m_name == null && getFeature() != null) { Property prop = m_feature.getPropertyByName("ATTR_NAME"); if (prop != null) { m_name = prop.getStringValue(); } } return m_name; } public RuntimeNode getFeature() { // If the feature has not been found previously then this method will first // try to find it. This is done as follows: // First traverse up the tree from this BomNode to find the Bom Model that
B-20 Oracle Configurator Implementation Guide Using Configuration Attributes for Output
// it belongs to. Then get each child node's name from the path (the names are // separated by ".") and do a getChildByName() to traverse down from the model // node until the feature is found at the end of the path. if (!found) findFeature(); return m_feature; }
/** * Returns the attribute's value as an integer. */ public int getIntValue() { if (hasIntegerValue()) { if (m_feature instanceof IntegerNode) { return ((IntegerNode)m_feature).getIntValue(); } else { return ((CountFeature)m_feature).getCount(); } } else { throw new RuntimeException("This attribute does not have integer value"); } }
/** * Returns the attribute's value as a string. */ public String getStringValue() { if (hasStringValue()) { if (m_feature instanceof TextNode) { return ((TextNode)m_feature).getTextValue(); } else { // Return the name of the only selected option in is this option feature return ((IRuntimeNode)(((OptionFeatureNode)m_ feature).getSelectedOptions().get(0))).getName(); } } else { throw new RuntimeException("This attribute does not have String value"); } }
/** * Returns the attribute's value as a double. */ public double getDecimalValue() { if (hasDecimalValue()) {
Code Examples B-21 Using Configuration Attributes for Output
return ((DecimalNode)m_feature).getDecimalValue(); } else { throw new RuntimeException("This attribute does not have decimal value"); } }
/** * Returns the attribute's value as a boolean. */ public boolean getBooleanValue() { if (hasBooleanValue()) { return ((BooleanFeature)m_feature).isTrue(); } else { throw new RuntimeException("This attribute does not have boolean value"); } }
/** * Returns true if attribute feature has an integer value. */ public boolean hasIntegerValue() { RuntimeNode feature = getFeature(); return (feature instanceof IntegerNode || feature instanceof CountFeature); }
/** * Returns true if attribute feature has a decimal value. */ public boolean hasDecimalValue() { RuntimeNode feature = getFeature(); return (feature instanceof DecimalNode); }
/** * Returns true if attribute feature has a boolean value. */ public boolean hasBooleanValue() { RuntimeNode feature = getFeature(); return (feature instanceof BooleanFeature); }
/** * Returns true if attribute feature has a string value.
B-22 Oracle Configurator Implementation Guide Using Configuration Attributes for Output
*/ public boolean hasStringValue() { RuntimeNode feature = getFeature(); return (feature instanceof TextNode || (feature instanceof OptionFeatureNode && ((OptionFeatureNode)feature).getSelectedOptions().size() == 1)); }
protected void setPath(String path) { m_path = path; }
protected void setMode(int mode) { m_mode = mode; }
protected void setAttrContext(String context) { m_attrContext = context; }
protected void setName(String name) { m_name = name; }
private void findFeature() { // Set the found flag to true once the path has been set // so that we do not attempt to find it again if (getPath() != null) { found = true; } else return;
RuntimeNode node = m_node; while (!(node instanceof BomModel)) { node = (RuntimeNode)node.getParent(); }
if (node instanceof BomModel) { // We found the model StringTokenizer tokenizer = new StringTokenizer(getPath(), ".", false); while (tokenizer.hasMoreTokens()) { try { node = (RuntimeNode)node.getChildByName(tokenizer.nextToken()); if (node instanceof ComponentSet) { throw new RuntimeException("Cannot refer to a multiply instantiable Component: " + node.getName() + " in the Attribute Path"); }
Code Examples B-23 Using Configuration Attributes for Output
} catch (NoSuchChildException nsce) { throw new RuntimeException("No attribute feature found in Path " + getPath() + " for Node " + m_node.getName()); } } m_feature = node; } }
public String toString() { return getAttrContext() + getName(); }
public boolean equals(Object obj) { if (obj instanceof Attribute) { String myAttr = getAttrContext(); String myName = getName(); String objAttr = ((Attribute)obj).getAttrContext(); String objName = ((Attribute)obj).getName(); if (myAttr != null && objAttr != null && myAttr.equals(objAttr) && myName != null && objName != null && myName.equals(objName)) { return true; } } return false; }
public int compareTo(Object o) { if (equals(o)) { return 0; } else { return this.toString().compareTo(o.toString()); } }
}
}
B-24 Oracle Configurator Implementation Guide Glossary of Terms and Acronyms
This glossary contains definitions that you may need while working with Oracle Configurator.
Active Model The compiled structure and rules of a configuration model that is loaded into memory on the Web server at configuration session initialization and used by the Oracle Configurator engine to validate runtime selections. The Active Model must be generated either in Oracle Configurator Developer or programmatically in order to access the configuration model at runtime.
API Application Programming Interface 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 See application architecture.
ATO Assemble to Order
Glossary of Terms and Acronyms-1 ATP Available to Promise
attribute The defining characteristic of something. Models have attributes such as Effectivity Sets and Usage. Components, Features, and Options have attributes such as Name, Description, and Effectivity.
benchmark Represents performance data collected during runtime tests under various conditions that emulate expected and extreme use of the product.
beta An external release, delivered as an installable application, and subject to acceptance, validation, and integration testing. Specially selected and prepared end users may participate in beta testing.
bill of material A list of Items associated with a parent Item, such as an assembly, and information about how each Item relates to that parent Item.
Bills of Material The application in Oracle Applications in which you define a bill of material.
BOM See bill of material.
BOM item The node imported into Oracle Configurator Developer that corresponds to an Oracle Bills of Material item. Can be a BOM Model, BOM Option Class node, or BOM Standard Item node.
BOM Model A model that you import from Oracle Bills of Material into Oracle Configurator Developer. When you import a BOM Model, effective dates, ATO rules, and other data are also imported into Configurator Developer. In Configurator Developer, you can extend the structure of the BOM Model, but you cannot modify the BOM Model itself or any of its attributes.
Glossary of Terms and Acronyms-2 BOM Model node The imported node in Oracle Configurator Developer that corresponds to a BOM Model created in Oracle Bills of Material.
BOM Option Class node The imported node in Oracle Configurator Developer that corresponds to a BOM Option Class created in Oracle Bills of Material.
BOM Standard Item node The imported node in Oracle Configurator Developer that corresponds to a BOM Standard Item created in Oracle Bills of Material.
Boolean Feature 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 program early in the project so that application implementers can unit test their latest work in the context of the entire available application.
CIO See Oracle Configuration Interface Object (CIO).
client A runtime program using a server to access functionality shared with other clients.
Comparison rule An Oracle Configurator Developer rule type that establishes a relationship to determine 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.
Glossary of Terms and Acronyms-3 Compatibility rule An Oracle Configurator Developer rule type that establishes a relationship among Features in the Model to control the allowable combinations of Options. See also, Property-based Compatibility rule.
Compatibility Table A kind of Explicit Compatibility rule. For example, a type of compatibility relationship where the allowable combination of Options are explicitly enumerated.
component A piece of something or a configurable element in a model such as a BOM Model, Model, or Component.
Component An element of the model structure, typically containing Features, that is configurable and instantiable. An Oracle Configurator Developer node type that represents a configurable element of a Model. Corresponds to one UI screen of selections in a runtime Oracle Configurator.
Component Set An element of the Model that contains a number of instantiated 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.
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 programs are stored procedures that
Glossary of Terms and Acronyms-4 perform actions such as generating reports and copying data to and from a database. 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 a runtime configurator. configuration attribute A characteristic of an item that is defined in the host application (outside of its inventory of items), in the Model, or captured during a configuration session. Configuration attributes are inputs from or outputs to the host application at initialization and termination of the configuration session, respectively.
Configuration Interface Object See Oracle Configuration Interface Object (CIO). configuration model Represents all possible configurations of the available options, and consists of model structure and rules. It also commonly includes User Interface definitions and Functional Companions. A configuration model is usually accessed in a runtime Oracle Configurator window. See also model. configuration rules The Oracle Configurator Developer Logic rules, Compatibility rules, Comparison rules, Numeric rules, and Design Charts available for defining configurations. See also rules. configuration session The time from launching or invoking to exiting Oracle Configurator, during which end users make selections to configure an orderable product. A configuration session is limited to one configuration model that is loaded when the session is initialized. configurator The part of an application that provides custom configuration capabilities. Commonly, a window that can be launched from a hosting application so end users
Glossary of Terms and Acronyms-5 can make selections resulting in valid configurations. Compare Oracle Configurator.
connectivity The connection between client and database server that allows data communication. The connection across components of a model that allows modeling such products as networks and material processing systems.
Connector The node in the model structure that enables an end user at runtime to connect the Connector node’s parent to a referenced Model.
context The surrounding text or conditions of something. Determines which context-sensitive segments of a flexfield in the Oracle Applications database are available to an application or user. Used in defining configuration attributes.
Contributes to A relation used to create a specific type of Numeric rule that accumulates a total value. See also Total.
Consumes from A relation used to create a specific type of Numeric rule that decrementing a total value, such as specifying the quantity of a Resource used.
count The number or quantity of something, such as selected options. Compare instance.
CRM See Customer Relationship Management
CTO Configure to Order
Glossary of Terms and Acronyms-6 customer The person for whom products are configured by end users of the Oracle Configurator or other ERP and CRM applications. Also the end users themselves directly accessing Oracle Configurator in a Web store or kiosk.
customer-centric extensions See customer-centric views. customer-centric views Optional extensions to core functionality that supplement configuration activities with rules for preselection, validation, and intelligent views. View capabilities include generative geometry, drawings, sketches and schematics, charts, performance analyses, and ROI calculations.
Customer Relationship Management The aspect of the enterprise that involves contact with customers, from lead generation to support services. customer requirements The needs of the customer that serve as the basis for determining the configuration of products, systems, and services. Also called needs assessment. See guided buying or selling.
CZ The product shortname for Oracle Configurator in Oracle Applications. data import Populating the Oracle Configurator schema with enterprise data from ERP or legacy systems via import tables.
Data Integration Object Also known as the DIO, the Data Integration Object is a server in the runtime application that creates and manages the interface between the client (usually a user interface) and the Oracle Configurator schema. data maintenance environment The environment in which the runtime Oracle Configurator data is maintained.
Glossary of Terms and Acronyms-7 data source A programmatic reference to a database. Referred to by a data source name (DSN).
DBMS Database Management System
default A predefined value. In a configuration, the automatic selection of an option based on the preselection rules or the selection of another option.
Defaults rule An Oracle Configurator Developer Logic rule that determines the logic state of Features or Options in a default relation to other Features and Options. For example, if A Defaults B, and you select A, B becomes Logic True (selected) if it is available (not Logic False).
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.
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 table view.
design review A technical review that focuses on application or system design.
Glossary of Terms and Acronyms-8 developer The person who uses Oracle Configurator Developer to create a configurator. See also implementer and user.
Developer The tool (Oracle Configurator Developer) used to create configuration models.
DHTML Dynamic Hypertext Markup Language
DIO See Data Integration Object. distributed computing Running various components of a system on separate machines in one network, such as the database on a database server machine and the application software on a Web server machine.
DLL Dynamically Linked Library
DSN See data source. element Any entity within a model, such as Options, Totals, Resources, UI controls, and components. end user The ultimate user of the runtime Oracle 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 a Web browser or kiosk. Compare user. enterprise The systems and resources of a business.
Glossary of Terms and Acronyms-9 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 rule An Oracle Configurator Developer Logic rule determines the logic state of Features or Options in an excluding relation to other Features and Options. For example, if A Excludes B, and if you select A, B becomes Logic False, since it is not allowed when A is true (either User or Logic True). If you deselect A (set to User False), there is no effect on B, meaning it could be User or Logic True, User or Logic False, or Unknown. See Negates rule.
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 A characteristic of something, or a configurable element of a component at runtime.
Feature An element of the model structure. Features can either have a value (numeric or Boolean) or enumerated Options.
Functional Companion An extension to the configuration model beyond what can be implemented in Configurator Developer. 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.
Glossary of Terms and Acronyms-10 guided buying or selling Needs assessment questions in the runtime UI to guide and facilitate the configuration process. Also, the model structure that defines these questions. Typically, guided selling questions trigger configuration rules that automatically select some product options and exclude others based on the end user’s responses. host application An application within which Oracle Configurator is embedded as integrated functionality, such as Order Management or iStore.
HTML Hypertext Markup Language
ICX Inter-Cartridge Exchange implementation The stage in a project between defining the problem by selecting a configuration technology vendor, such as Oracle, and deploying the completed configuration application. The implementation stage includes gathering requirements, defining test cases, designing the application, constructing and testing the application, and delivering it to end users. See also developer and user. implementer The person who uses Oracle Configurator Developer to build the model structure, rules, and UI customizations that make up a runtime Oracle Configurator. Commonly also responsible for enabling the integration of Oracle Configurator in a host application.
Implies rule An Oracle Configurator Developer Logic rule that determines the logic state of Features or Options in an implied relation to other Features and Options. For example, if A Implies B, and you select A, B becomes Logic True. If you deselect A (set to User False), there is no effect on B, meaning it could be User or Logic True, User or Logic False, or Unknown. See Requires rule. import server A database instance that serves as a source of data for Oracle Configurator’s Populate, Refresh, and Synchronization concurrent processes. The import server is sometimes referred to as the remote server.
Glossary of Terms and Acronyms-11 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’s Item Master. Import tables also store extractions from Oracle Applications or legacy data that create, update, or delete records in the Oracle Configurator schema Item Master.
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.
install program Software that sets up the local machine and installs the application for testing and use.
Instance An Oracle Configurator Developer attribute of a component’s node that specifies a minimum and maximum value. See also instance.
instance A runtime occurrence of a component in a configuration. See also instantiate. Compare count. Also, the memory and processes of a database.
instantiate To create an instance of something. Commonly, to create an instance of a component in the runtime user interface of a configuration model.
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. Compare unit test.
Glossary of Terms and Acronyms-12 intelligent views Configuration output, such as reports, graphs, schematics, and diagrams, that help to illustrate the value proposition of what is being sold.
IS Information Services item A product or part of a product that is in inventory and can be delivered to customers.
Item A Model or part of a Model that is defined in the Item Master. Also data defined in Oracle Inventory.
Item Master Data stored to structure the Model. Data in the Item Master is either entered manually in Oracle Configurator Developer or imported from Oracle Applications or a legacy system.
Item Type Data used to classify the Items in the Item Master. Item Catalogs imported from Oracle Inventory are Item Types in Oracle Configurator Developer.
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.
LAN Local Area Network
LCE Logical Configuration Engine. Compare Active Model.
legacy data Data that cannot be imported without creating custom extraction programs.
Glossary of Terms and Acronyms-13 load Storing the configuration model data in the Oracle Configurator Servlet on the Web server. Also, the time it takes to initialize and display a configuration model if it is not preloaded. The burden of transactions on a system, commonly caused by the ratio of user connections to CPUs or available memory.
log file A file containing errors, warnings, and other information that is output by the running application.
Logic rules Logic rules directly or indirectly set the logical state (User or Logic True, User or Logic False, or Unknown) of Features and Options in the Model. There are four primary Logic rule relations: Implies, Requires, Excludes, and Negates. Each of these rules takes a list of Features or Options as operands. See also Implies rule, Requires rule, Excludes rule, and Negates rule.
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 defect fixes, procedure changes, infrastructure adjustments, data replication schedules, and so on.
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. Includes both imported BOM Models and Models created in Configurator Developer. May consist of BOM Option Classes and BOM Standard Items.
model A generic term for data representing products. A model contains elements that correspond to items. Elements may be components of other objects used to define
Glossary of Terms and Acronyms-14 products. A configuration model is a specific kind of model whose elements can be configured by accessing an Oracle Configurator window. model-driven UI The graphical views of the model structure and rules generated by Oracle Configurator Developer to present end users with interactive product selection based on configuration models. model structure Hierarchical "tree" view of data composed of elements (Models, Components, Features, Options, BOM Models, BOM Option Class nodees, BOM Standard Item nodes, Resources, and Totals). May include reusable components (References).
MS Microsoft Corporation
Negates rule A type of Oracle Configurator Developer Logic rule that determines the logic state of Features or Options in a negating relation to other Features and Options. For example, if one option in the relationship is selected, the other option must be Logic False (not selected). Similarly, if you deselect one option in the relationship, the other option must be Logic True (selected). See Excludes rule.
node The icon or location in a Model tree in Oracle Configurator Developer that represents a Component, Feature, Option or variable (Total or Resource), Connector, Reference, BOM Model, BOM Option Class node, or BOM Standard Item node.
Numeric rule An Oracle Configurator Developer rule type that express constraint among model elements in terms of numeric relationships. See also, Contributes to and Consumes from.
OC See Oracle Configurator.
ODBC Open Database Connectivity. A database access method that uses drivers to translate an application’s data queries into DBMS commands.
Glossary of Terms and Acronyms-15 OCD See Oracle Configurator Developer.
opportunity The workspace in Oracle Sales Online in which products, systems, and services are configured, quotes and proposals are generated, and orders are submitted.
option A logical selection made by the end user when configuring a component.
Option An element of the Model. A choice for the value of an enumerated Feature.
Oracle Configuration Interface Object (CIO) A server in the runtime application that creates and manages the interface between the client (usually a user interface) and the underlying representation of model structure and rules in the Active Model. The CIO is the API that supports creating and navigating the Model, querying and modifying selection states, and saving and restoring configurations.
Oracle Configurator The product consisting of development tools and runtime applications such as the Oracle Configurator schema, Oracle Configurator Developer, and runtime Oracle Configurator. Also the runtime Oracle Configurator variously packaged for use in networked or Web deployments.
Oracle Configurator architecture The three-tier runtime architecture consists of the User Interface, the Active Model, and the Oracle Configurator schema. The application development architecture consists of Oracle Configurator Developer and the Oracle Configurator schema, with test instances of a runtime Oracle Configurator.
Oracle Configurator Developer The suite of tools in the Oracle Configurator product for constructing and maintaining configurators.
Oracle Configurator engine Also LCE. Compare Active Model.
Glossary of Terms and Acronyms-16 Oracle Configurator schema The implementation version of the standard runtime Oracle Configurator data-warehousing schema that manages data for the configuration model. The implementation schema includes all the data required for the runtime system, as well as specific tables used during the construction of the configurator.
Oracle Configurator Servlet Vehicle for Oracle Configurator containing the UI Server.
Oracle Configurator window The user interface that is launched by accessing a configuration model and used by end users to make the selections of a configuration.
Oracle SellingPoint Application No longer available or supported. output The output generated by a configurator, such as quotes, proposals, and customer-centric views. performance The operation of a product, measured in throughput and other data.
Populator An entity in Oracle Configurator Developer that creates Component, Feature, and Option nodes from information in the Item Master. preselection 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.
product Whatever is ordered and delivered to customers, such as the output of having configured something based on a model. Products include intangible entities such as services or contracts.
Glossary of Terms and Acronyms-17 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 a node in the Model or the Item Master. A set of Properties may be associated with an Item Type. After importing a BOM Model, Oracle Inventory Catalog Descriptive Elements are Properties in Oracle Configurator Developer.
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, prove feasibility, or examine other implementation issues.
PTO Pick to Order
publication A unique deployment of a configuration model (and optionally a user interface) that enables a developer to control its availability from hosting applications such as Oracle Order Management or iStore. Multiple publications can exist for the same configuration model, but each publication corresponds to only one Model and User Interface.
publishing The process of creating a publication record in Oracle Configurator Developer, which includes specifying applicability parameters to control runtime availability and running an Oracle Applications concurrent process to copy data to a specific database.
Glossary of Terms and Acronyms-18 QA Quality Assurance
RAD Rapid Application Development
RDBMS Relational Database Management System reference The ability to reuse an existing Model or Component within the structure of another Model (for example, as a subassembly).
Reference An Oracle Configurator Developer node type that denotes a reference to another Model.
regression test An automated test that ensures the newest build still meets previously tested requirements and functionality. See also incremental construction.
Requires rule An Oracle Configurator Developer Logic rule that determines the logic state of Features or Options in a requirement relation to other Features and Options. For example, if A Requires B, and if you select A, B is set to Logic True (selected). Similarly, if you deselect A, B is set to Logic False (deselected). See Implies rule.
resource Staff or equipment available or needed within an enterprise.
Resource A variable in the Model used to keep track of a quantity or supply, such as the amount of memory in a computer. The value of a Resource can be positive or zero, and can have an Initial Value setting. An error message appears at runtime when the value of a Resource becomes negative, which indicates it has been over-consumed. Use Numeric rules to contribute to and consume from a Resource. Also a specific node type in Oracle Configurator Developer. See also node.
Glossary of Terms and Acronyms-19 reusable component See reference and model structure.
reusability The extent to and ease with which parts of a system can be put to use in other systems.
RFQ Request for Quote
ROI Return on Investment
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 provide preselection and validation capability in Oracle Configurator. See also Comparison rule, Compatibility rule, Design Chart, Logic rules and Numeric rule.
runtime The environment and context in which applications are run, tested, or used, rather than developed. The environment in which an implementer (tester), end user, or customer configures a product whose model was developed in Oracle Configurator Developer. See also configuration session.
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 customer requirements and product configuration.
schema The tables and objects of a data model that serve a particular product or business process. See Oracle Configurator schema.
Glossary of Terms and Acronyms-20 SCM Supply Chain Management server Centrally located software processes or hardware, shared by clients.
servlet A Java application running inside a Web server. See also Java, applet, and Oracle Configurator Servlet.
SFA Sales Force Automation solution The deployed system as a response to a problem or problems.
SQA Software Quality Assurance
SQL Structured Query Language 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 that are created to determine 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. Also a specific node type in Oracle Configurator Developer. See also node.
UI See User Interface.
Glossary of Terms and Acronyms-21 Unknown The logic state that is neither true nor false, but unknown at the time a configuration session begins or when a Logic rule is executed. This logic state is also referred to as Available, especially when considered from the point of view of the runtime Oracle Configurator end user.
unit test Execution of individual routines and modules by the application implementer or by an independent test consultant to find and resolve defects in the application. Compare integration testing.
update Moving to a new version of something, independent of software release. For instance, moving a production configurator to a new version of a configuration model, or changing a configuration independent of a model update.
upgrade Moving to a new release of Oracle Configurator or Oracle Configurator Developer.
user The person using a product or system. Used to describe the person using Oracle Configurator Developer tools and methods to build a runtime Oracle Configurator. Compare end user.
User Interface The part of Oracle Configurator architecture runtime architecture that is generated from the model structure and provides the graphical views necessary to create configurations interactively. Interacts with the Active Model and data to give end users access to customer requirements gathering, product selection, and customer-centric views.
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. Not necessarily generated in Oracle Configurator Developer.
user requirements A description of what the configurator is expected to do from the end user's perspective.
Glossary of Terms and Acronyms-22 user's guide Documentation on using the application or configurator to solve the intended problem. validation Tests that ensure that configured components will meet specific criteria set by an enterprise, such as that the components can be ordered or manufactured.
Validation A type of Functional Companion that is implemented to ensure that the configured components will meet specific criteria.
VAR Value-Added Reseller variable Parts of the Model that are represented by Totals, Resources, or numeric Features.
VB Microsoft Visual Basic. Programming language in which portions of Oracle Configurator Developer are written. verification Tests that check whether the result agrees with the specification.
WAN Wide Area Network
Web The portion of the Internet that is the World Wide Web.
WIP Work In Progress
Glossary of Terms and Acronyms-23 Glossary of Terms and Acronyms-24 Index
Numerics disposition codes, 3–15 batch validation 10.7, 4–15 AltBatchValidateURL, 10–8 11.0, 4–15 BatchSize CZ_DB_SETTING for SCHEMA, 3–12 A BILL_REVISION_DATE in CZ_XFR_PROJECT_BILLS, 4–10 Active Model BOM definition, 1–13 configure directly, 1–4 upgrade, 1–13 import root, 4–13 Administative tables imported, 1–4 Oracle Configurator ADMN subschema, 3–2 imported data, 4–13 AltBatchValidateURL, 10–8 BOM Synchronization, 1–25, 1–26, 6–10 AOL (Applications Object Library), 10–5 concurrent programs, 1–27, 4–22 AOL/J, 10–5 import server, 4–14 API version numbers, 8–7 lost publications, 6–16 applet, 10–1 synchronized fields, 1–25 applicability parameters, 7–6 validation criteria, 1–24 application BOM Synchronized fields publication applicability parameter, 6–7 COMPONEN_ITEM_ID, 4–9 application id COMPONENT_ITEM_ID, 1–26 applid, 2–7 COMPONENT_SEQUENCE_ID, 1–26 applications COMPONENT_SEQUENCE_PATH, 1–26 state, 10–10 ORGANIZATION_ID, 1–25, 4–9 applid ORIG_SYS_REF, 1–25 parameter in spx.ini, 2–7 PRODUCT_KEY, 1–25 attribute Features SOURCE_SERVER, 1–26, 4–10 definition of, 9–30 TOP_ITEM_ID, 1–25, 1–26, 4–10 BOM: Configurator URL of UI Manager B profile option, 10–1 BadItemPropertyValue BOM_EXPLOSIONS CZ_DB_SETTING for import, 3–15 BOM_BILL_OF_MATERIAL, 4–11 description, 3–15 BOM_INVENTORY_COMPONENTS, 4–11 data refresh, 3–14
Index-1 data transfer source, 4–12 4–23 DESCRIPTION field in CZ_INTL_TEXTS, 4–11 Refresh All Imported Configuraqtion source field from, 3–13 Models, 4–17 BOM_REVISION Refresh All Previously Imported Models, 4–23 CZ_DB_SETTING for Oracle Applications running Server Administration programs, 1–21 integration, 3–13 Select Tables to be Imported, 4–32, 4–37 browser Show Tables to be Imported, 4–33 requirements for DHTML configurator, 10–2 Synchronization of Models, 4–22 Synchronize All Models, 10–12 C View Configurator Parameters, 3–16 View Servers, 1–20 Catalog Descriptive Element view status of, 1–21 imported property, 4–14 view submitted requests, 1–21 Catalog Descriptive Element value CONFIG_MODEL_FOR_ITEM, 7–13 imported property, 4–14 CONFIG_MODEL_FOR_PRODUCT, 7–17 CfgInputExample.java, B–2 CONFIG_MODELS_FOR_ITEMS, 7–15 CIO, 1–14 CONFIG_MODELS_FOR_PRODUCTS, 7–19 client/server environment CONFIG_UI_FOR_ITEM, 7–21 deployment CONFIG_UI_FOR_ITEM_LF, 7–24 collections, 7–7 CONFIG_UI_FOR_PRODUCT, 7–27 CommitSize CONFIG_UIS_FOR_ITEMS, 7–29 CZ_DB_SETTING for direct import, 3–15 CONFIG_UIS_FOR_PRODUCTS, 7–31 COMMON_BILL_FOR_ITEM, 7–11 Configuration COMPONENT_ITEM_ID Oracle Configurator CF subschema, 3–2 in CZ_XFR_PROJECT_BILLS, 4–9 configuration attributes concurrent programs CZ_CONFIG_ATTRIBUTES table, 9–27 Check All Models/Bills Similarity, 1–27, 10–12 defined, 9–1 Check Model/Bill Similarity, 1–27 descriptive flexfields, 9–28 Define Remote Server, 10–12 Functional Companions, 9–14, 9–42 Define Servers, 1–18 input, 9–3, 9–7 Enable Remote Server, 1–19, 4–21 output, 9–3, 9–24 Enable/Disable Refresh of a Configuration Configuration Interface Object, see CIO Model, 4–18, 4–23 Configurator for editing Oracle Configurator settings, 3–16 see also DHTML configurator for import, 4–17 see also Java applet configurator for publication, 6–11 see also Oracle Configurator window for server administration, 1–17 architecture, 1–13 Modify Configurator Parameters, 3–16 installations, 1–7 Modify Server Definition, 1–20, 4–19, 4–22 parameters Populate Configuration Models, 4–17, 4–21 modifying, 3–17 Process a Single Publication, 6–11 viewing, 3–17 Process Pending Publications, 6–12 requirements for installation, 1–7 Purge Configurator Tables, 3–23 see also query registered processes, 1–22 Configure Refresh a Single Configuration Model, 4–17, button, 5–2, 10–14
Index-2 connection cache, 10–6 for SCHEMA, 3–12 control tables FREEZE_REVISION, 3–8 see CZ_XFR control tables GenerateGatedCombo, 3–8 cookies MAJOR_VERSION, 1–23, 3–8 DHTML configurator requirement, 10–2 MaximumErrors, 3–8 COPY_ADDL_CHILD_MODELS MINOR_VERSION, 1–23, 3–8 in CZ_XFR_PROJECT_BILLS, 4–11 MULTISESSION, 3–9 COPY_CONFIGURATION, 7–33 PsNodeName, 3–9 COPY_CONFIGURATION_AUTO, 7–35 PublicationLogging, 3–9 CREATE_UI, 8–10 PublishingCopyRules, 3–9 customization RefPartNbr, 3–9 custom procedures ResolvePropertyDataType, 3–10, 4–14 configuration attributes, 9–47 Revison Date/User, 3–10 CZ__XFR_PROJECT_BILLS RUN_BILL_EXPLODER, 3–11 Table in CZ schema, 1–26 SuppressSuccessMessage, 3–11 CZ_ATP_REQUESTS table in CZ schema - ADMN subschema, 3–2 table in CZ schema - CNFG subschema, 3–2 UI_NODE_NAME_CONCAT_CHARS, 3–11 CZ_CF_API package, 7–1 CZ_DB_SETTINGS table, 1–8, 3–6 reference, 7–8 export settings, 3–14 CZ_COMBO_FEATURES schema version, 1–23 refreshing, 4–24 CZ_DES_CHART_CELLS table in CZ schema - Rule subschema, 3–3 refreshing, 4–24 CZ_CONFIG_ATTRIBUTES, 3–2 table in CZ schema - Rule subschema, 3–3 Table in CZ schema, 9–27 CZ_DES_CHART_COLUMNS CZ_CONFIG_DETAILS_V, 3–2 table in CZ schema - Rule subschema, 3–3 CZ_CONFIG_HDRS CZ_DES_CHART_FEATURES table in CZ schema - CNFG subschema, 3–2 table in CZ schema - Rule subschema, 3–3 CZ_CONFIG_INPUTS CZ_DEV_PROJECTS table in CZ schema - CNFG subschema, 3–2 transferred data, 4–12 CZ_CONFIG_ITEMS CZ_DEVL_PROJECTS table in CZ schema - CNFG subschema, 3–2 description translation, 3–18 CZ_CONFIG_MESSAGES project ID query, 3–18 table in CZ schema - CNFG subschema, 3–2 refreshing, 4–24 CZ_DB_LOGS synchronized fields, 1–25 table in cz SCHEMA - ADMN subschema, 3–2 Table in CZ schema, 1–25 CZ_DB_SETTINGS table in CZ schema - PS subschema, 3–3 AltBatchValidateURL, 3–7, 10–7, 10–8 transferred data, 4–12 APPS_PREFER_UI_0, 3–7 CZ_EFFECTIVITY_SETS APPS_PREFER_UI_3, 3–7 table in CZ schema - PB subschema, 3–3 BadItemPropertyValue, 3–7 CZ_EXPRESSION_NODES Batchsize, 3–7 refreshing, 4–24 BOM_REVISION, 3–8 table in CZ schema -Rule subschema, 3–3 CommitSize, 3–8 CZ_EXPRESSIONS for IMPORT, 3–14 refreshing, 4–24 for ORAAPPS_INTEGRATE, 3–12 table in CZ schema - PS subschema, 3–3
Index-3 CZ_EXT_APPLICATIONS_V refreshing, 4–24 table in CZ schema - PB subschema, 3–3 synchronized fields, 1–25 CZ_FILTER_SETS Table in CZ schema, 1–25 refreshing, 4–24 table in CZ schema - IM subschema, 3–2 table in CZ schema - Rule subschema, 3–3 transferred data, 4–12 CZ_FUNC_COMP_SPECS CZ_ITEM_PROPERTY_VALUES refreshing, 4–24 refreshing, 4–24 table in CZ schema - Rule subschema, 3–3 Table in CZ schema, 1–26 CZ_GRID_CELLS table in CZ schema - IM subschema, 3–2 refreshing, 4–24 transferred data, 4–12 table in CZ schema - Rule subschema, 3–4 CZ_ITEM_TYPE_PROPERTIES CZ_GRID_COLS refreshing, 4–24 refreshing, 4–24 Table in CZ schema, 1–26 table in CZ schema - PS subschema, 3–4 table in CZ schema - IM subschema, 3–3 CZ_GRID_DEFS CZ_ITEM_TYPES refreshing, 4–24 refreshing, 4–24 table in CZ schema - Rule subschema, 3–4 synchronized fields, 1–25 CZ_IMP_DECIMAL_QTY_FLAG, 4–16 Table in CZ schema, 1–25 CZ_IMP_DEVL_PROJECTS table in CZ schema - IM subschema, 3–2 table in CZ schema - PS subschema, 3–3 transferred data, 4–12 CZ_IMP_INTL_TEXT CZ_LCE_HEADERS table in CZ schema - UI subschema, 3–4 refreshing, 4–24 CZ_IMP_ITEM_MASTER table in CZ schema - LC subschema, 3–3 table in CZ schema - IM subschema, 3–2 CZ_LCE_TEXTS CZ_IMP_ITEM_PROPERTY_VALUE refreshing, 4–24 table in CZ schema - IM subschema, 3–2 table in CZ schema - LC subschema, 3–3 CZ_IMP_ITEM_TYPE CZ_LOCALIZED_TEXTS table in CZ schema - IM subschema, 3–2 string translation query, 3–19 CZ_IMP_ITEM_TYPE_PROPERTY synchronized fields, 1–25 table in CZ schema - IM subschema, 3–2 table in CZ schema - PS subschema, 3–4 CZ_IMP_LOCALIZED_TEXTS tooltip translations, 4–4 table in CZ schema - UI subschema, 3–4 translation strings, 4–4 CZ_IMP_MODEL_REF_EXPLS CZ_LOCALIZED_TEXTS_VL table in CZ schema - PS subschema, 3–3 table in CZ schema - PS subschema, 3–4 CZ_IMP_PROPERTY CZ_MODEL_APPLICABILITIES_V table in CZ schema - IM subschema, 3–2 Publishing, 6–8 CZ_IMP_PS_NODES table in CZ schema - PB subschema, 3–3 table in CZ schema - PS subschema, 3–3 CZ_MODEL_PUBLICATIONS CZ_INTL_TEXTS, 4–11 publications tables, 6–13 refreshing, 4–24 synchronized fields, 1–25 table in CZ schema - UI subschema, 3–4 table in CZ schema - PB subschema, 3–3 transferred data, 4–12 CZ_MODEL_REF_EXPLS CZ_ITEM_MASTERS table in CZ schema - PS subschema, 3–3 BOM Synchronization, 1–24 CZ_MODEL_USAGES DECIMAL_QTY_FLAG, 4–16 publications tables, 6–13
Index-4 table in CZ schema - PB subschema, 3–3 CZ_RP_ENTRIES CZ_modelOperations_pub package, 8–1 table in CZ schema - RP subschema, 3–4 reference, 8–6 CZ_RULE_FOLDERS CZ_PB_CLIENT_APPS table in CZ schema - Rule subschema, 3–4 publications tables, 6–13 CZ_RULES table in CZ schema - PB subschema, 3–3 refreshing, 4–24 CZ_PB_LANGUAGES rule not satisfied translation, 3–18 table in CZ schema - PB subschema, 3–3 rule violation translation, 3–18 CZ_PB_MODEL_EXPORTS table in CZ schema - Rule subschema, 3–4 publications tables, 6–13 CZ_RULES_FOLDERS table in CZ schema - PB subschema, 3–3 refreshing, 4–24 CZ_POPULATOR_MAPS CZ_SERVERS refreshing, 4–24 table in CZ schema - RP subschema, 3–4 CZ_POPULATORS CZ_SUB_CON_SETS refreshing, 4–24 refreshing, 4–24 table in CZ schema - PS subschema, 3–3 CZ_TERMINATE_MSGS CZ_PRICING_STRUCTURES, 5–3 table in CZ schema - CNFG subschema, 3–2 table in CZ schema - CNFG subschema, 3–2 CZ_UI_DEFS CZ_PROPERTIES refreshing, 4–24 refreshing, 4–24 table in CZ schema - UI subschema, 3–4 table in CZ schema - IM subschema, 3–3 updating UI node translation, 3–20 transferred data, 4–12 CZ_UI_NODE_PROPS CZ_PS_NODES, 3–13 refreshing, 4–25 BOM Synchronization, 1–24 table in CZ schema - UI subschema, 3–4 custom import flag, 4–35 CZ_UI_NODES DECIMAL_QTY_FLAG, 4–16 refreshing, 4–25 refreshing, 4–24 table in CZ schema - UI subschema, 3–4 synchronized fields, 1–25 tool tip translation, 3–18 Table in CZ schema, 1–25 CZ_UI_PROPERTIES table in CZ schema - PS subschema, 3–3 refreshing, 4–25 transferred data, 4–12 table in CZ schema - UI subschema, 3–4 translation query,INTL_TEXT_ID, 3–18 CZ_XFR control tables violation message translation, 3–18 Oracle Configurator XF subschema CZ_PS_PROP_VALS use with scripts and concurrent programs, 4–11 refreshing, 4–24 CZ_XFR_FIELDS, 4–8, 4–11 table in CZ schema - PS subschema, 3–3 table in CZ schema - XF subschema, 3–4 CZ_PUBLICATION_USAGES CZ_XFR_PROJECT_BILLS, 3–14, 4–9, 4–11 publications tables, 6–13 synchronized fields, 1–25, 1–26 table in CZ schema - PB subschema, 3–3 table in CZ schema - XF subschema, 3–4 CZ_REL_TYPES CZ_XFR_RUN_INFOS refreshing, 4–24 table in CZ schema - XF subschema, 3–4 CZ_REPOS_TREE_V CZ_XFR_RUN_RESULTS table in CZ schema - RP subschema, 3–4 table in CZ schema - XF subschema, 3–4 CZ_RP_DIRECTORY_V CZ_XFR_STATUS_CODES table in CZ schema - RP subschema, 3–4 table in CZ schema - XF subschema, 3–4
Index-5 CZ_XFR_TABLES, 4–7 in CZ_XFR_PROJECT_BILLS, 4–10 table in CZ schema - XFR subschema, 3–4 deployment cz.activemodel, 5–5, 5–8 client/server, 1–11 cz.activemodel.lazyloadlistprice, 5–5 DHTML, 10–2 cz.uiservlet.pre_load_filename, 10–12 Java applet, 10–2 requirements for web, 10–1 D web, 1–11, 10–1 DESCRIPTION data extraction in CZ_XFR_PROJECT_BILLS, 4–9 setup, 4–35 descriptive flexfields, 9–28 data import, 4–15 used for configuration attributes, 9–3 data transfer Design Chart file for generic import, 4–36 section in the spx.ini file, 2–8 file format, 4–36 settings, 2–8 database instance Developer connect to, 1–22 spx.ini parameters, 2–4 definition, 1–6 DHTML (Dynamic HTML), 10–1 database linking, 1–18, 1–19 DHTML configurator changing servers, 4–19 browser requirements, 10–2 Define and Enable Remote Servers, 1–10 cookies, 10–2 development environment, 1–10 deployment of, 10–2 enabling a remote server, 4–18 essential components, 10–2 import, 4–18 recommended screen resolution, 10–2 Modify Server Definition, 4–19 Disable/Enable Refresh of a Configuration production environment, 1–11 Model, 4–25 publishing, 6–5 disposition codes database owner BadItemPropertyValue, 3–15 see also DBOwner import tables, A–3 definition, 1–6 due to failed target database, 1–24 date range publication applicability parameter, 6–8 DB_SETTINGS, see CZ_DB_SETTINGS E DBC file, 10–6 EFF_FROM DBOwner in CZ_XFR_PROJECT_BILLS, 4–10 definition, 1–6 EFF_TO in spx.ini, 2–3 in CZ_XFR_PROJECT_BILLS, 4–11 parameter in spx.ini, 2–4, 2–6 effectivity Decimal Quantity and publishing, 6–14 profile option, 4–16 effectivity date Standard Item, 4–15 for planning publications, 6–2 DEEP_MODEL_COPY, 8–13 effectivity sets DEFAULT_NEW_CFG_DATES, 7–37 for planning publications, 6–2 DEFAULT_RESTORED_CFG_DATES, 7–39 end user DELETE_CONFIGURATION, 7–41 definition, 1–6 DELETED_FLAG EXECUTE_POPULATOR, 8–15
Index-6 EXPLOSION_TYPE base language, 4–3 in CZ_XFR_PROJECT_BILLS, 4–10 changing servers, 4–19 extending Common Bill, 4–30 Java classes, 9–15 control tables, 4–3 custom, 4–2, 4–33 F custom flag, 4–35 dependencies among tables, A–2 feature enabling a remote server, 4–18 symbol in Design Chart, 2–8 execution, 3–14 field disposition codes, A–3 explode BOM Model, 4–18 firewalls from Oracle Applications 10.7 or 11.0, 1–3 effect on servlet connections, 10–10 generic, 4–34, 4–37 interference with application, 10–10 Modify Server Definition, 4–19 flexfields Multiple Language Support, 4–3 used for configuration attributes, 9–3 online tables, 3–1 FND_APPLICATIONS order of, 1–10, A–1 publications tables, 6–13 Populate Configuration Models, 4–18 FND_JDBC_MAX_WAIT_TIME, 10–6 properties from Oracle Inventory, 4–13 FND_MAX_JDBC_CONNECTIONS, 10–6 schedule during deployment, 1–12 Foreign Surrogate Key, A–2 schedule during development, 1–10 FREEZE_REVISION setup for generic, 4–34 CZ_DB_SETTING for SCHEMA, 3–12 setup process, 4–14 Functional Companions single tables, A–2 for input configuration attributes, 9–14 source language, 4–4 for output configuration attributes, 9–42 Standard Items, 4–15 synchronization, 4–18 G import control fields DISPOSITION, 4–6 gateway username REC_NBR, 4–5 gwyuid, 2–6 REC_STATUS, 4–6 Generate Active Model RUN_ID, 4–5 after schema upgrade, 1–13 import server GENERATE_LOGIC, 8–17 Define Servers, 1–18 generic import, see import definition, 1–6 gwypass Enable Remote Server, 1–19 parameter in spx.ini, 2–6 import tables gwyuid clearing, 4–3 parameter in spx.ini, 2–6 definition, 3–1 field disposition codes, A–3 I record status codes, A–3 RUN_ID, 4–9 ICX_SESSION_TICKET, 7–43 IMPORT_SINGLE_BILL, 8–19 IMPORT Imported Property CZ_DB_SETTINGS, 3–6 Catalog Descriptive Element, 4–14 import Catalog Descriptive Element value, 4–14
Index-7 Item Catalog Group, 4–14 L importing refreshing BOMs with submodels, 4–27 LAST_IMPORT_DATE in CZ_XFR_PROJECT_BILLS, 4–9 index-by tables, 7–7 LAST_IMPORT_RUN_ID InitCodeBaseUrl parameter in the spx.ini file, 2–7 in CZ_XFR_PROJECT_BILLS, 4–9 Launch initial requests, 9–16 parameter in the spx.ini file, 2–7 for configuration attributes, 9–16 initialization message Logic for Configuration, see Active Model LogicGen for preloading, 10–12 CZ_DB_SETTINGS, 3–6 init.ora file, 10–6 InitServletURL lost publications due to failed source database, 1–24, 6–16 parameter in the spx.ini file, 2–7 due to failed target database, 6–16 installations deployment, 1–11 due to instance failure, 6–16 development, 1–8 maintenance, 1–12 M scenarios, 1–8 maintenance test, 1–10 PURGE, 3–23 types of, 1–7 REDO_SEQUENCES, 3–24 instance MAJOR_VERSION definition, 1–6 CZ_DB_SETTING for SCHEMA, 3–12 Integer Quantity MaximumErrors Standard Item, 4–15 CZ_DB_SETTING for direct import, 3–15 Internet Explorer, 10–2 Merlin Item Catalog Group see Developer imported property, 4–14 section in the spx.ini file, 2–1, 2–2 Item-Master Microsoft, 10–2 Oracle Configurator IM subschema, 3–2 MINOR_VERSION CZ_DB_SETTING for SCHEMA, 3–12 J MLS definition, 1–14 Java publishing language, 1–14 applet, 10–1 classes Source language, 4–4 model data extending, 9–15 see also configuration attributes Java applet deployment of, 10–2 MODEL_FOR_ITEM, 7–44 MODEL_FOR_PUBLICATION_ID, 7–46 JavaScript MODEL_PS_NODE_ID enabled for DHTML configurator, 10–2 JDBC, 10–6 in CZ_XFR_PROJECT_BILLS, 4–11 MTL_DESCR_ELEMENT_VALUES JdbcUrl data transfer source, 4–12 parameter in spx.ini, 2–4, 2–6 jserv.properties MTL_DESCRIPTIVE_ELEMENTS data transfer source, 4–12 editing for Secure Sockets Layer (SSL), 10–7 MTL_ITEM_CATALOG_GROUPS
Index-8 data transfer source, 4–12 deployment upgrades, 1–12 MTL_SYSTEM_ITEMS Oracle Order Management BOM Synchronization, 1–24 integrated with an Oracle runtime data transfer source, 4–12 Configurator, 1–4 translation strings, 4–3, 4–4 Oracle Quoting, 9–24 MULTISESSION OracleSequenceIncr CZ_DB_SETTING for direct import, 3–15 CZ_DB_SETTING for SCHEMA, 3–12 ORG_ORGANIZATION_DEFINITIONS N BOM Synchronization, 1–26 ORGANIZATION_ID, 4–11 Netscape Navigator, 10–2 in CZ_XFR_PROJECT_BILLS, 4–9 networked environment, see client/server environment P O packages CZ_CF_API, 7–1 online tables, 3–1 CZ_modelOperations_pub, 8–1 Options Selection window, 5–2 performance ORAAPPS_INTEGRATE pricing interface package, 5–3 CZ_DB_SETTINGS, 3–6 performance improvement Oracle Applications preloading, 10–12 10.7, 1–3 prices_calculated_flag, 5–4 11.0, 1–3 pricing data import, 4–15 adjustments, 5–3 Oracle applications architecture, 5–3 short names for, 9–19 CZ_PRICING_STRUCTURES table, 5–3 Oracle Configurator discounts, 5–3 see also Configurator editing, 5–3 integration in Oracle Applications, 1–4, 1–8 in an Oracle Configurator window, 5–1 release upgrade, 1–13 interface package Oracle Configurator Developer definition of, 5–2 starting, 2–10 performance impacts, 5–8 Oracle Configurator schema, A–2 types of, 5–2 characteristics, 3–1 Pricing Display publishing a production version, 4–24 setting attribute with Oracle Configurator purging, 1–11, 3–23 Developer, 5–5, 5–7, 5–8 redoing sequences, 3–24 procedures settings, see CZ_DB_SETTINGS custom subschemas, 3–1 configuration attributes, 9–47 synonyms, 3–1 Product Support, xxvii tables to refresh for publication, 4–24 profile options updates, 4–24 BOM: Configurator URL of UI Manager, 10–1 verifying version, 1–23 CZ Publication Lookup Mode, 6–7 Oracle Configurator window Populate Decimal Quantity Flags, 4–16 architecture, 1–13 Project Structure
Index-9 Oracle Configurator PS subschema, 3–3 PUBLISH_MODEL, 8–20 PsNodeName publishing CZ_DB_SETTING for Oracle Applications configuration models, 6–1 integration, 3–13 planning, 6–1 Publication profile option, 6–7 Oracle Configurator PB subschema, 3–3 publishing language, 1–14 publication synchronization, 6–10, 6–16 creating, 6–11 PURGE database linking, 6–5 concurrent programs, 3–23 defining, 6–4 DB maintenance package, 3–23 language translations, 1–14 planning, 6–1 Q process, 6–2 tables used for, 6–12 QUOTEABLE_FLAG UI_DEF_ID, 6–15 custom import flag, 4–35 publication applicability parameters, 6–6 application, 6–4, 6–7 R date range, 6–4, 6–8 publication mode, 6–4, 6–6 record status codes, A–3 usages, 6–4, 6–8 import tables, A–3 publication attributes REDO_SEQUENCES database instance, 6–4, 6–5 DB maintenance package, 3–24 model, 6–4, 6–5 invoked by scripts, 3–24 product, 6–4 REF_PART_NBR, 4–11 UI definition, 6–4, 6–6 referenced BOMs, 4–30 publication mode references language applicability parameter, 1–14 with output configuration attributes, 9–40, 9–41 publication applicability parameter, 6–6 referencing PUBLICATION_FOR_ITEM, 7–47 and publishing, 6–14 PUBLICATION_FOR_PRODUCT, 7–49 RefPartNbr PUBLICATION_FOR_SAVED_CONFIG, 7–51 CZ_DB_SETTING for Oracle Applications publications integration, 3–13 deleting, 6–15 refresh disabling, 6–15 list of tables, 4–24 editing, 6–15 production Oracle Configurator schema, 4–24 lost, 6–16 Refresh a Single Configuration Model, 4–26 of configuration models, 6–1 Refresh All Previously Imported Models, 4–26 re-enabling, 6–15 REFRESH_SINGLE_MODEL, 8–21 updating, 6–14 REFRESH_UI, 8–22 publications tables, 6–12 refreshing publish instantiable models, 4–27 across applications, 6–7 models with references, 4–27 description translation, 4–4 Release 11i, 4–15 list of tables, 4–24 remote server production Oracle Configurator schema, 4–24 define, enable, or modify, 1–17
Index-10 REPOPULATE, 8–24 example, 2–1 Repository parameters for development and testing, 2–3 Oracle Configurator RP subschema, 3–4 stateful application, 10–10 ResolvePropertyDataType, 3–10 stickiness CZ_DB_SETTING for property import, 3–14 effect on servlet connections, 10–11 respid router property, 10–10 parameter in spx.ini, 2–7 Stylesheets responsibility id enabled for DHTML configurator, 10–2 respid, 2–7 Summary button, 5–2 Revision Date/User Support, xxvii CZ_DB_SETTING for SCHEMA, 3–12 surrogate key fields rollback segment, 3–12 foreign surrogate key, 4–6 Rule surrogate primary key, 4–6 Oracle Configurator RP subschema, 3–3 Synchronization RUN_BILL_EXPLODER lost publications, 6–16 CZ_DB_SETTING for direct import, 3–14 publishing to another database, 6–10 data refresh, 3–14 synchronization import, 4–18 S T SCHEMA CZ_DB_SETTINGS, 3–6 TCP/IP schema time limit, 10–10 definition, 1–6 timeouts subschemas, 3–1 database connection, 10–10 verifying version, 1–23 JServ secure default, 10–10 implementing Secure Sockets Layer, 10–6 router, 10–11 Secure Sockets Layer TOP_ITEM_ID, 4–11 editing jserv.properties, 10–7 in CZ_XFR_PROJECT_BILLS, 4–10 Secure Sockets Layer (SSL), 10–3 Transfer specifications, see CZ_XFR control tables setting up Oracle Configurator, 10–6 verifying AltBatchValidateURL, 10–8 U Selected Items window, 5–2 sequences UI Servlet reset increments, 3–24 properties, 5–5, 5–8 server UI_FOR_ITEM, 7–53 definition, 1–6 UI_FOR_PUBLICATION_ID, 7–55 short names UISERVER for Oracle applications, 9–19 CZ_DB_SETTINGS, 3–6 SOURCE_BILL_DELETED UOM in CZ_XFR_PROJECT_BILLS, 4–10 unit of measurement, 9–1 SOURCE_SERVER update in CZ_XFR_PROJECT_BILLS, 4–10 list of tables to, 4–24 spx.ini file production Oracle Configurator schema, 4–24
Index-11 UI node translations, 3–20 Update Prices button, 5–2 upgrade Oracle Configurator release, 1–13 regenerate Active Model to, 1–13 URL see also InitServletURL, 2–7 runtime Oracle Configurator requirement, 2–7 usages and initialization message, 6–9 defining, 6–9 for planning publications, 6–2 publication applicability parameter, 6–8 user see also end user definition, 1–6 User Interface Oracle Configurator UI subschema, 3–4
V VALIDATE, 7–57 validation AltBatchValidateURL, 10–8 validation failures, 9–22 verify data import, 4–22 schema version, 1–23
W web deployment, 1–11, 10–1 WriteAttributes.java, B–10
X XFR_ control tables, see CZ_XFR control tables
Index-12