Oracle configurator
Download as DOCX, PDF•1 like•219 views
Oracle Configurator is a tool for configuring products and services that enables end users to select components and view configurations. Oracle Configurator Developer (OCD) provides a drag-and-drop interface to rapidly develop configuration models. The development process involves building model structures and rules, testing models, managing models in a repository, and publishing models for system testing.
Oracle configurator
- 1. Oracle Configurator Introduction: Configurator is a tool for configuring products and services. The configuration process can include assessing customer needs, selecting product and service components, and viewing configurations. Configurator enables end users to access the parts that make up the product and the rules that govern how those parts fit together. With a configurator, end users can generate any custom product configuration that the rules allow. A Configurator brings the expertise of enterprise to the point of sale, dramatically changing and improving the way you sell products and services. Oracle Configurator Developer (OCD) is the development tool in the Oracle Configurator family of products. It provides a convenient drag-and-drop interface that enables you to rapidly develop a configurator. Oracle Configurator Schema Life cycle of Configuration Model: Configuration model development using OCD is iterative process, which has four distinct steps v Building model structures, rules and GUI using Model Window. v Perform unit testing using Test/Debug Module. v Managing models using Repository Window. v Publishing models for system testing These steps are represented in flow diagram as follows:
- 2. CZ Flow Building Model Structure (Using Model Window): Model structure is built using Model window component. It in turn uses Item master, properties and imported data to create model structure. Item master is a subschema in CZ schema for storing product data. OCD uses data in Item Master to create configuration models. The items in Item Master are either created from scratch in Configurator Developer or are imported from legacy product data (e.g.: Bills of Material or Pricing information). Model Structure is a hierarchical tree representation of the Model. Model Structure consists of nodes of different types at different level. Following is the list of different node types. Node Type Description Model The highest level of structure. A Model can contain Components and References to other Models. Component A configurable part of a Model. A Component can contain Components, Features, Resources, and Totals. Connector Enables an end user to link two components at runtime by selecting from a list of instantiated Models. A Model can have one or more Connectors. Feature A Feature can be a List of Options, an Integer Number, a Decimal Number, a True or False value, or a Text value. A Feature of type List of Options can contain Options. Option An Option is part of a List of Options in a Feature. It is often an object represented by an Item in the Item Master. Total A Total keeps track of a quantity. A Total can have a positive or negative value. Use Numeric Rules to contribute to and consume from Totals. Resource A Resource also keeps track of a quantity. The value of a Resource can be positive or zero, but a Resource is violated if its value becomes negative at runtime (that is, it is over-consumed). Use Numeric Rules to contribute to and consume from a Resource. BOM Model Equivalent to a Component in Configurator Developer. Can be either an assemble to order (ATO) or pick to order (PTO) Model created in Oracle Bills of Material and may include other BOM Models.
- 3. Typically contains BOM Option Classes, which include BOM Standard Items. BOM Option Class A group of related BOM Standard Items. BOM Standard Items are imported with the BOM from Oracle Bills of Material, and are Equivalent to a Feature Option in Configurator Developer. BOM Standard Item Any Oracle Inventory Item that can be a component on a bill, including purchased items, subassemblies, and finished products. Equivalent to a Option in Configurator Developer. Building Rules and Constraints (Using Configurator Rules Module): One of the most critical activities in constructing configuration model is to design and construct the rules that govern what the end user can select to make a valid configuration. Rules express relations among the Components, Features, Options, BOM Option Classes, and BOM Standard Items of your Model. At runtime, the Configurator accesses your rules to determine the state of each option before and after the end user makes a selection. The rules alert the end user when an invalid selection is made and selects or deselects other options to ensure a valid configuration is created. OCD allows to create 8 different types of rules which are as listed below Rule Type Description Logic Rules Define logical relationships between Features, Options, BOM Option Classes, and BOM Standard Items using logic relations.The logic relations available are: Requires, Implies, Excludes, Negates, and Defaults. Numeric Rules Perform a numeric operation on one or more numeric Features, Option counts, or Totals placing the result in a numeric Feature, Option count, Total, or Resource.The rules available are: Contributes to and Consumes from, each with a variety of ways in which to specify the numeric operation. Comparison Rules Perform a comparison between the value of a Property of one or more Features and the value of another such Property, or some constant value. Property-based Compatibilities Specify matches between the Options of one or more Features that have a common Property. Explicit Compatibilities Specify matches between the Options of one or more Features in explicit tabular form. Design Charts Specify compatibility matches between one Primary Feature’s Options and multiple
- 4. Secondary Feature’s Options in explicit tabular form. Rule Sequences Specify an ordered set of rules whose effectivity dates are set so that a rule in the sequence becomes effective at the same time its predecessor ceases to be effective. Configurator Extension Write java code to perform pre-selection or validation functions that go beyond Oracle Configurator Developer’s supplied functionality. Building User Interface (Using UI Module): User Interface is basically used for testing the Model or part of Model and is also provides interface to end users while configuration using the Active Model. OCD can automatically generate a User Interface derived directly from the Model. This generated UI reflects the structure of Model and provides all the UI elements for implementing a runtime Oracle Configurator. OCD takes advantage of the Oracle Configurator architecture by storing the complete definition of the User interface in the CZ schema, where it is available to the Oracle Configurator Developer and the Active Model in a runtime Oracle Configurator. A User Interface is based on a single Model, which can contain sub-Models. Sub-Models can have their own UI or be included in a UI based on their parent Model (for example, if a Model is referenced by another Model). Models, sub-Models, BOM Models, BOM Option Classes, and Component nodes are represented by individual screens in the runtime UI, and OCD creates a separate node for each in the UI tree. Each Feature of a Component or Model node appears as a separate control within its parent UI screen. The same is true for BOM Standard Items, which appear within the same UI screen as their parent BOM Option Class. One can modify the type of Feature control created for Feature nodes (Dropdown List or Selection List), but BOM Option Classes generate selection lists and the control type is read-only. Publishing: Publishing is a process that creates a copy of a configuration model’s structure, rules, and UI on a specific database to make it available for testing or production use from different hosting applications. Publishing is typically the final phase of the configuration model development process. When a configuration model is created in OCD, it must under go unit testing, modification if any, and retest it before making it available to users in either a system testing or production environment. A publication is a unique deployment of a configuration model that enables to control its availability when invoked by a hosting application and the UI that is displayed to the end user. A configuration model can have multiple User Interfaces and you can create many publications for the same Model. However, a publication corresponds to only one configuration model and User Interface. Full Cycle of Oracle Configurator. Create Items in Inventory Responsibility. Create Hierarchy in Bills of Materials Responsibility.
- 5. Run Concurrent Program: Populate Configuration Models in Oracle Configurator Developer (OCD) Responsibility. The models appear in the Repository tab of OCD. Click on the Lock icon beside the Models appearing in the Repository, so that further changes can be made to the Models. Now the edit icons will be enabled besides the models. Click on Edit to enter the model workbench. In the workbench tab there are 4 sub tabs: General, Structure, Rules & User Interface. We can create the Non-BOM items in the Model as per our design in the Structure tab. Non-BOM items can be as follows: Option Feature, Boolean feature, Text Feature, Integer Feature, Decimal Feature, Total, Resource, Component sets, etc. In the Rules tab we can create the Rules required to achieve the business scenarios. In the User Interface tab we create the User Interface and align it as per it needs to be visible when we launch the Oracle Configurator Runtime. We need to Publish the Model to be visible in the Run-time. This is done in the Publication sub tab inside the Repository Tab of OCD. After doing this we have to Run a Concurrent Program named “Publish a Single Publication“. To Be Continued…….