Release 12.1 for
Part Number E14322-03
Contents
Previous
Next
| Oracle Configurator Implementation Guide Release 12.1 for Part Number E14322-03 | Contents | Previous | Next |
This chapter describes the elements of the Oracle Configurator product and how they fit together.
This chapter covers the following topics:
This chapter presents the elements of the Oracle Configurator product and how they fit together, including information about:
Oracle Configurator Developer is both a development and maintenance environment used to create, modify, and unit test configuration models and custom Oracle runtime configurator pages. The runtime Oracle Configurator, Oracle Configurator Developer, and CZ schema run as part of the Oracle Applications eBusiness Suite in a multi-tier architecture.
Oracle Configurator Developer is a thin client development environment that connects directly to the CZ schema.
Both the runtime Oracle Configurator and Oracle Configurator Developer run 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.
The runtime Oracle Configurator and Oracle Configurator Developer:
Are HTML based
Operate within the Oracle Applications (OA) Framework
Are Self Service Web applications
Oracle Configurator consists of the following elements:
Oracle Configurator Developer
CZ schema within the Oracle Applications database
Runtime Oracle Configurator
Oracle Configurator Developer includes the following OA Framework features:
Based on J2EE standards
Facilitates access by the disabled community
Multiple Language Support (MLS)
Multi-currency support
Reusable UI components
Additionally, Oracle Configurator Developer leverages the latest Oracle Application Server technology, such as:
Caching
Event Handling
Security
State Management
XML Based Declarative UIs
Optimized HTML UI rendering
Presentation is separate from business logic
Business Components for Java (BC4J)
Business logic encapsulation
Optimized DB interaction
Scalability and performance
Message-service EJB Architecture
Full support for transactions, fail-over and multi-tier deployment
Minimizes inter-tier traffic
The runtime Oracle Configurator, Configurator Developer, and the CZ schema are installed with Oracle Applications Release 12 by running Oracle Rapid Install.
The runtime Oracle Configurator enables end users to select options interactively in a Web browser.
It is also possible to run Oracle Configurator as a programmatic background process, such as when an end user changes the quantity of a configured item. The background process validates the configuration without requiring further end-user interaction.
End users access the runtime Oracle Configurator by logging into an application that hosts Oracle Configurator. When the user requests that the host application configure something, the host application invokes Oracle Configurator, which then becomes the foreground application during a configuration session. At the end of a configuration session, the Oracle Application dialog page is displayed before the host application returns to the foreground.
There are several factors that affect the way that you can enable users to access the runtime Oracle Configurator:
These factors are described in the following sections.
The host application for the runtime Oracle Configurator can be one of the following:
An application that is part of Oracle Applications, which you reach through the E-Business Suite home page. Examples are: Oracle Order Management, iStore, and Oracle Contracts. Oracle Configurator Developer is also a host application. .
A custom application that provides its own user interface, and at runtime communicates with the Oracle Configurator engine through the Configuration Interface Object (CIO).
End users of the host application can log in by one of the following methods:
If the host application is part of Oracle Applications, then users log in to the E-Business Suite home page with a user ID and password that are authenticated by Oracle Applications. This process generates an ICX session ticket, which contains the session authentication information that is used by the runtime Oracle Configurator.
If the host application is not part of Oracle Applications, then after a user logs in to the host application, that application must specify user ID, password, and database identification when it invokes the runtime Oracle Configurator.
All host applications send an initialization message to start the runtime Oracle Configurator, and specify parameters of the message to control the initial state of the runtime Oracle Configurator. Oracle Configurator processes the initialization message in the following way:
The host application sends the initialization message, which is in XML, to the URL of the Oracle Configurator Servlet. The host application obtains this URL from the profile option BOM: Configurator URL of UI Manager. See the Oracle Configurator Installation Guide for details about setting profile options. The Oracle Configurator Servlet is described in Oracle Configurator Servlet .
Oracle Configurator can be invoked programmatically by the host application, without user interaction. This is called batch validation, which is described in Batch Validation.
If the initialization message is wrapped in the <batch_validate> element, then the Oracle Configurator Servlet runs Oracle Configurator in a batch validation session.
If the initialization message is not intended for batch validation, then Oracle Configurator determines which type of user interface to render, based on the value of the initialization parameter ui_type.
The user interface for the runtime Oracle Configurator can use one of the styles described in Runtime UI Types. It can also use a completely custom UI, if the host application provides its own user interface, and its own code to communicate with the Oracle Configurator engine directly, through the Oracle Configuration Interface Object (CIO).
Oracle Configurator processes the parameters in the initialization message, and begins a configuration session, rendering the specified runtime Oracle Configurator. The parameters determine the initial state of the configuration session, specifying which model to configure and a variety of other configuration data. The particular selection of parameters and values depends on the requirements of the host application. See Session Initialization for details.
Invocation results in the host application incorporating the user interface for the runtime Oracle Configurator into its own user interface in one of the following ways:
Standalone page: Oracle Configurator occupies all of a standalone page, in a page separate from that used by the host application. Examples: Oracle Order Management and Oracle Configurator Developer.
Frame: Oracle Configurator occupies a frame that is embedded in the page used by the host application. Example: Oracle iStore.
Region: Oracle Configurator occupies a region that is embedded in a page used by the host application. Only possible if the host application is a member of Oracle Applications that is constructed with the Oracle Applications Framework. For more information about the Oracle Applications Framework, see the Oracle Application Framework Documentation Resources, Release 12, on MetaLink.
Custom container: Oracle Configurator occupies a JavaServer Page that you specify when you publish your Model.
For information and recommendations on preparing the deployment of Oracle Configurator on publicly accessible Web servers, see Deployment Considerations.
Depending on your runtime UI requirements, you can deploy the following types of runtime Oracle Configurators:
User Interfaces that are based on the OA Framework, deployed as part of the E-Business Suite, and launched from other Oracle Applications. For a list of Oracle Applications that integrate with Oracle Configurator, contact your Oracle representative. For details about creating generated UIs, see the Oracle Configurator Developer User’s Guide.
Legacy Configurator User Interfaces (Java applet) from previous releases of Oracle Configurator. These legacy UIs cannot be edited using the HTML-based Oracle Configurator Developer. For details, see the Oracle Configurator documentation from previous releases and the Oracle Configurator Installation Guide.
The Oracle Configurator Servlet contains the machinery used to support:
Batch validation
Legacy Configurator user interfaces
Note: The inclusion of the Oracle Configurator Servlet in this release provides compatibility for host applications that were already integrated with Oracle Configurator before the adoption of the Oracle Applications Framework. See Invocation of Oracle Configurator by Host Application for an example of this integration. All other areas of Oracle Configurator provide integration through the Oracle Applications Framework, as described elsewhere in this chapter. For more information on the Oracle Applications Framework, see the Oracle Application Framework Documentation Resources, Release 12, on MetaLink.
The Oracle Configurator Servlet is responsible for rendering legacy Configurator user interfaces and brokering communication between the configuration model, the database, and the client browser.
The OC Servlet consists of the following elements:
The OC Servlet runs on Oracle Application Server, which includes the Apache Web Server. The behavior of the OC Servlet can be customized by setting servlet properties. The properties of the OC Servlet are described in the Oracle Configurator Installation Guide. Information about setting servlet properties is presented in the Oracle Configurator Performance Guide.
The UI Server is an element of the OC Servlet that is not used by Oracle Configurator when it renders a user interface in the Oracle Applications Framework.
The UI Server that processes user input from a client user interface and renders back the UI for display to the end user based on information received from the Oracle Configurator engine. The UI Server provides a common level of support for user interfaces (Java applet) that are not created by the HTML-based Oracle Configurator Developer.
The CIO is an API layer that handles communication between the Oracle Configurator engine and the UI. The API methods of the CIO can be used to access the configuration model and Oracle Configurator behaviors. Configurator Extensions and custom UIs communicate with the Oracle Configurator engine through the CIO.
For more information see the Oracle Configurator Extensions and Interface Object Developer’s Guide.
The Oracle Configurator engine validates user selections and provides results based on the compiled structure and rules of a configuration model.
The Oracle Configurator engine has no public API and cannot be modified.
The CZ schema consists of Configurator (CZ) tables in the Oracle Applications Release 12 database that are accessed by both the runtime Oracle Configurator and Oracle Configurator Developer.
The CZ schema is organized into subschemas that store:
Imported data from other Oracle Applications database tables
Settings that control the behavior of Configurator processes
Data that defines the Model structure, rules, and UI of configuration models
Saved configurations
Oracle Configurator Developer stores the complete definition of the User Interface in the CZ schema, where it is available to both Oracle Configurator Developer and a runtime Oracle Configurator.
See CZ Subschemas for a listing of the tables that are in each of the subschemas. For more information about the CZ schema data model, see the CZ eTRM on MetaLink, Oracle’s technical support Web site.
Oracle Configurator Developer:
Allows creating, organizing, managing, and publishing Models
Includes tools for generating runtime Configurator User Interfaces
Allows users to define configuration rules
Users access Configurator Developer by logging into Oracle Applications and selecting the appropriate responsibility. The following responsibilities are predefined and available with initial installation:
Oracle Configurator Developer
Oracle Configurator Administrator
Oracle Configurator Viewer
For more information on accessing Configurator Developer, see Controlling the Development Environment.
Users of Configurator Developer can create a configuration model using only the structural elements (Model, Components, Features, Options) available in Configurator Developer. This is called a Developer Model and might be used to create a standalone or prototype configuration.
If the configuration model is based on an imported ATO or PTO BOM Model, then users of Configurator Developer can extend the imported Model with Configurator Developer structure to create guided buying or selling questions, and additional internal structure to support rule definition.
Users of Configurator Developer can also extend the behavior of configuration models beyond what can be implemented in Oracle Configurator Developer by creating Configurator Extensions. Configurator Extensions are built with custom or provided Java code that uses the fully supported, fully documented Java API methods of the CIO. Implementers create Configurator Extensions and then connect them to configuration models in Configurator Developer.
To unit test a configuration model, you can access the runtime Configurator UI as a test environment directly from Configurator Developer to create configurations. You can also use the Model Debugger in Configurator Developer to unit test new configurations or restore saved configurations. Testing uses the same application architecture as a deployed runtime Configurator.
When unit testing, you can:
Specify testing session parameters, such as Effectivity dates and a Usage
Save and restore configurations
Run Configurator Extensions
Display pricing and ATP information
Testing from Configurator Developer through Oracle Applications does not involve running the host application where your configuration models are deployed, such as Order Management. For more testing information, see the Oracle Configurator Developer User’s Guide.
Oracle Applications architecture is a framework for multitiered, distributed computing. Oracle Application Framework fits into a three-tier architecture. The three tiers are:
Application
Client
Database
Oracle Application Framework also fits into a four-tier architecture.
The four tiers are:
Application
Client
Database
Web
For more information about the Oracle Application Architecture, see the Oracle E-Business Suite Concepts documentation and the Oracle Application Framework Documentation Resources, Release 12, on MetaLink.
The elements of a runtime Oracle Configurator that span the four tiers are shown in Four tier Architectural Overview of a Runtime Oracle Configurator.
The following table shows the two way communication between the Client tier and the Web tier. The Web tier contains custom Java Server Pages and the OA Framework that contains the Generated Configurator UIs. The Web tier sends requests to the Application tier that consists of the Configurator Message Service, the CIO, and the Engine. The Application tier then sends responses back to the Web tier. There is two way communication between the Application tier and the Data tier. The Data tier is the Oracle Database.
Four tier Architectural Overview of a Runtime Oracle Configurator
During an interactive runtime session, the Web tier contains the displayed UI. The Configurator Messaging service in the Applications tier uses Enterprise Java Beans to handle requests from the displayed page on the Web tier.
The elements of a runtime Oracle Configurator that span the three tiers are shown in Three tier Architectural Overview of a Runtime Oracle Configurator.
Three tier Architectural Overview of a Runtime Oracle Configurator illustrates the two way communication between the Client tier and the Java Middle tier. The Java Middle tier is made up of the UI Server, the Generated Configurator UIs, the DIO, the CIO and the Engine. It also illustrates the two way communication between the Java Middle tier and the Data tier via JDBC. The Data tier is the Oracle database
Three tier Architectural Overview of a Runtime Oracle Configurator
During development, Configurator Developer runs on a three-tier architecture, with the thick web tier accessing the database as shown in Three tier Architectural Overview of Oracle Configurator Developer.
Three tier Architectural Overview of Oracle Configurator Developer illustrates the two way communication between the Client tier and the Middle tier. The Client tier is the Web browser. The Middle tier consists of the OA Framework, and the Configurator Developer UI. There is two way communication between the Middle tier and the Data tier via JDBC. The Data tier is the Oracle database.
Three tier Architectural Overview of Oracle Configurator Developer
Configurator Developer is a thin-client development environment that connects directly to the CZ schema. Configurator Developer is built on the Oracle Applications Framework and leverages the latest Oracle Application Server technology that allows for XML Based Declarative UIs, Business Components for Java (BC4J), and Message-Service EJB architecture.
Copyright © 1999, 2010, Oracle and/or its affiliates. All rights reserved.