Configurator Architecture

This chapter describes the elements of the Oracle Configurator product and how they fit together.

This chapter covers the following topics:

Overview

This chapter presents the elements of the Oracle Configurator product and how they fit together, including information about:

Introduction

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:

Oracle Configurator consists of the following elements:

Oracle Configurator Developer includes the following OA Framework features:

Additionally, Oracle Configurator Developer leverages the latest Oracle Application Server technology, such as:

The runtime Oracle Configurator, Configurator Developer, and the CZ schema are installed with Oracle Applications Release 12 by running Oracle Rapid Install.

Runtime Oracle Configurator

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.

Access

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.

Type of Host Application

The host application for the runtime Oracle Configurator can be one of the following:

Login to Host Application

End users of the host application can log in by one of the following methods:

Invocation of Oracle Configurator by Host Application

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:

  1. 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.

    1. If the initialization message is wrapped in the <batch_validate> element, then the Oracle Configurator Servlet runs Oracle Configurator in a batch validation session.

    2. 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).

  2. 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.

Incorporation of Oracle Configurator in the Host Application’s UI

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:

Oracle Configurator Security on Publicly Accessible Web Servers

For information and recommendations on preparing the deployment of Oracle Configurator on publicly accessible Web servers, see Deployment Considerations.

Runtime UI Types

Depending on your runtime UI requirements, you can deploy the following types of runtime Oracle Configurators:

Oracle Configurator Servlet

The Oracle Configurator Servlet contains the machinery used to support:

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.

UI Server

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.

Configuration Interface Object (CIO)

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.

Oracle Configurator Engine

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.

Oracle CZ Schema

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:

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

Oracle Configurator Developer:

Access

Users access Configurator Developer by logging into Oracle Applications and selecting the appropriate responsibility. The following responsibilities are predefined and available with initial installation:

For more information on accessing Configurator Developer, see Controlling the Development Environment.

Types of Configuration Models

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.

Unit Testing

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:

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.

Multi-Tier Architecture

Oracle Applications architecture is a framework for multitiered, distributed computing. Oracle Application Framework fits into a three-tier architecture. The three tiers are:

Oracle Application Framework also fits into a four-tier architecture.

The four tiers are:

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.

Runtime Oracle Configurator

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

the picture is described in the document text

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

the picture is described in the document text

Oracle Configurator Developer Three Tiers

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

the picture is described in the document text

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.