eSales
Configurator for Building and Maintaining
Knowledge-based Configuration Applications
What is Product & Document Configuration?
Product Configuration is the process of matching product modules,
components, features, options, etc., to customer requirements. Typically,
this covers two different types of knowledge-rich processes; requirement
capture, which deals in "customer speak", and product generation,
which deals in "product expert speak".
Typically, the process of requirement capture combines “needs
analysis” with user-driven “data capture”. A customer-focused
requirement capture process must therefore provide effective decision
flow, maximise customer choice and minimising data errors, resulting
in a complete and unambiguous description of customer requirements.
The product generation process uses the captured requirement data
to derive the selection of modules, components, features and options
in a product to best match each customer's individual needs, resulting
in a complete description of the configured product down to the
lowest configurable level. Examples of this are "bill of materials"
of assembled to order products and the sections/paragraphs in a
contract document.
The decision of whether to start the design of a configuration
application with the requirement capture process, or with the product
generation process will often depend on the knowledge source. For
example, the prior availability of domain experts and the existence
of documented data and knowledge for each process. Normally, the
application developer is advised to start by capturing the product
generation knowledge before moving on to the requirement capture
knowledge. This implies defining the "output" first, and
then working backward to specify the "input" and the "knowledge"
needed for such a mapping.
The Product Generation Process
A good starting point for the design and implementation of configuration
applications is the product generation process, which typically
covers two main types of product knowledge: Product Hierarchy and
Component Selection.
Product Hierarchy
Most products, be they physical such as a Personnel Computer, or
logical such as an Insurance Policy, can be represented by a hierarchy
of modules and components which, when assembled, makeup the configured
product. A configurable product is where a choice exists for different
modules and components to be selected. A product hierarchy includes
all the possible combinations of modules and components, down to
the lowest configurable component, in a single hierarchical structure.
This is sometimes referred to as the “generic bill of materials”
for the product.
XpertRule Knowledge Builder supports a special “Hierarchy”
Class option for defining the relationship between Objects representing
all the possible modules and components in a product family.
Component Selection
Each object in the Product Hierarchy represents a module, sub-module
or a list of possible components, from which a selection is made.
Therefore, for each object in the Hierarchy, a decision must be
made on (a) whether to include this Object in the configured product
and (b) if so, which (where a choice is available). Typically if
an Object is not included then all Objects below it in the hierarchy
are automatically excluded form the configured product.
The knowledge for this selection process depends on the user requirements,
either directly through the captured requirement, or indirectly
through the selection of other components in the Hierarchy.
XpertRule Knowledge Builder provides for two types of selection
knowledge for mapping the requirement capture to the required components:
(a) through Decision based inference, using Decision inference (Trees,
Cases and Procedures) and (b) through a Patten Matching inference
option using Constraint inference (Trees, Cases, Procedures &
Properties).
Example of a Decision Selection Tree
The Requirement Capture Process
The aim of this process is to analyse the customer’s needs,
maximise customer choice to satisfy those needs and without compromising
the integrity of the configured product.
Having identified the input data required to generate the Product
Hierarchy, the source of each required data item must be identified.
Those data items that need to be supplied by the customer, forming
part of the user interface for such a system, and the relationship
between them must be clearly defined. Those resulting choices should
be presented to the customer in such a way as to minimise mandatory
data entry and provide maximum choice without permitting undesirable
choice combinations to be made.
The Requirement Capture process typically covers two main types
of knowledge: Decision Flow and Constraint-based Data Capture.
Decision Flow
The grouping of input data items for capture and deciding if, and
when, to present them to the end user, plays a crucial role determining
the effectiveness of the requirement capture process.
XpertRule Knowledge Builder Decision Trees are an ideal representation
of such knowledge as they allow different “Dialogs”
to be embedded in different decision paths.
Example of Decision Control Tree
Constraint-based Data Capture
To prevent undesirable customer choice combinations from being made,
the choices presented to the customers have to be constrained by
what is known at any given point in time. For example if the customer
had selected a Unix operating system, their choice of Word processors
should not include MS-Word.
This requires technical knowledge of the relationship between different
options in the product to be defined.
XpertRule Knowledge Builder’s Constraints Inference option
allows the Trees, Cases, Procedures & the item’s own Properties
to be used to define this knowledge.
Example of a Constraint Tree
Example of Cases used as an “inclusion/exclusion” Table
Example of Properties used to Constrain Component Selection 
Deploying Configuration Application
Once captured and tested, the decision-making knowledge captured within
Knowledge Builder can be deployed in a number of platforms and configurations:
Running Knowledge on a stand alone or networked PC client
An inference engine is used for running knowledge applications on
a PC client. This configuration is typically used to run knowledge
applications on stand alone or networked PC's.
Running Knowledge on a Windows NT / 2000 Server
A COM+ inference engine is used to run knowledge applications on Windows
NT / 2000 servers. The COM+ engine uses XML to exchange data with
other applications (receiving attribute data and returning decisions).
This engine is highly performant and scalable.
The COM+ inference engine can be used either as an embedded knowledge
server for other applications or it can be used in conjunction with
the Knowledge Builder ISAPI filter to develop a thin client interactive
(e.g. Q&A) Expert System application.
Running Knowledge in a Web Browser
Ajax deployment
Ajax is a thin-client web-based application deployment technique,
which utilises the browser’s ability to execute JavaScript
code to generate/update the HTML user interface and synchronise
it with its application server. This is in contrast with conventional
thin-client deployment methods where, the server delivers complete
HTML pages to be simply rendered by the client browser.
Benefits of Ajax deployment
By not requiring the server to deliver a new HTML page each time
the user makes a change, the load on the application server is
greatly reduced, thus enabling significantly higher performance
/ load to be obtained from the same application server. This
benefit is maximised where a single web page performs many functions
and requires many interactions with the user.
Use of the Ajax technique by Knowledge Builder
Each Knowledge Builder Dialog Object is generated as a single HTML
page with embedded JavaScript code (which is posted by the server
once when the Dialog is encountered during inference). Until
this Dialog is exited, any changes the user makes effecting the
display of the web page, are performed by the client’s
browser, which also posts messages back to the application server
to updates the session data and perform any required inferences
(Constraints, Macros, Events, etc). Where possible, the WYSIWYG
dialog design is faithfully reproduced (in HTML) by the Ajax
JavaScript.
Server platforms supported by Knowledge Builder’s
Ajax deployment
The current Knowledge Builder has 3 Ajax deployment options:
- COM Engine for Microsoft IIS server deployment
- J# Engine for Microsoft .net server deployment
- Java Engine for J2EE server deployment
The Java and J# Engine options are also available as a ‘generated’ sub-option,
where the application runtime (engine and knowledge-base) are automatically
combined and generated into Java/J# source code which can then
be complied for maximum execution speed. This option requires new ‘source’ to
be re-generated and complied each time the knowledge-base is changed.
It is primarily suitable for low (design-time) knowledge maintenance
/ high (runtime) transaction throughput.
Live Web Demo
For a live web demonstration of a deployed Configuration Application
click here.
|
