The problem

A customer asked us to develop a system to enable its B2B customers to configure the product before putting it in order .

The purchased products are divided into several families and , since the products are controllers of the flow of GAS , the selection criteria depend on physical and chemical complex formulas.

Moreover, the number of options the user requests vary widely from product to product.

Skills for configuration are derived from years of experience of a few people in the customer's staff .

The configurations can change over time and refine as tests on regulators as performed.

STANDARD APPROACH

A beautifull flowchart for any product to be configurated?

A beautifull flowchart for any product to be configurated?

Procedural development of a tree of configurations for each product. Creation of a tailored user interface. 

Pros: strong customization for each product configurator.

Cons:

  • Lack of flexibility: the change of a sequence of options can invalidate what has been developed .
  • Development time is linear with the number of products to be configured: (customer developer analysis hypothesized 2 months for any configurator )
  • No autonomy from developer staff
  • Code little modular: each configurator is self defined and changes of general policies involve the transmission of all mods to all configurators .
  • Long analysis time: the developers of the application , external to the staff of the customer (us) have zero skills in the context of the client's products .

COOL APPROACH!

A beautiful web application that auto-configures talking to a rules engine.

What is a rules engine: Here it is wikipedia

Pro:

  • Strong flexibility: a rules engine is declarative, it is so simple to add rules that alter the flow of the questions in any point of running without losing coherence 
  • Customer's Autonomy, after training on the rules engine
  • Business rules are much more closer to the human logic  than to programming view
  • An application such as the one drawn opens the possibility of extending complex logic also on different platforms with an effort of development thet is not linear with the number and complexity of the configured products

Cons:

  • Standard Interface: The interface of the configurator must be made standard, you need a usability studies that accurately applies to all interactions necessary to configure different models

Well, if I had persuade the customer to follow the first road we would work for years. I have not convinced  him ;)

HOW WE HAVE IMPLEMENTED THE APPLICATION

Technological choices:

We chose the Drools Rule Engine of the Jboss community

Why?

  • It' s open source
  • It has an interface for the designers of the rules that as ugly and not entirely solid as best than teach business people to read XML or java
  • It allows the use rules also in WorkFlow systems such as Jboss JBPM or Bonita
  • Java . It is the language we know best

STRUCTURE OF THE PROJECT

A JAVA application that contains the Drools engine, take care to drive the execution of different sets of rules depending on the product to configure.

Opzione= Option of the question, Variabile= Variable = Value Answered

Opzione= Option of the question, Variabile= Variable = Value Answered

Each Drools model must define a set of objects and must be instantiated ( Asserted ) from the Drools rules so that the JAVA application can list them and then configure itself .

The object types that we have defined as standard are :

  • options
  • variables
  • messages 

The Drools model generates the options that should be displayed to the user, the Java application converts them into user interface requests ( Single choice , input field etc. )

Whenever an option is chosen , Java generates a Variable in the memory area of Drools so that rules can fire and create other  answers with other options .

In then Figure we show a DECISION table rule that specifies all the necessary options for the first configuration . In this figure there are only single-choice questions.

In the following we show some input-box options

In this we see that for a TEXTBOX type we can also define Default values that will be processed by the application to be proposed in the text field 

ERROR HANDLING

Let's assume that one of the textbox requires the date of birth .

Drools generates an object Opzione( name : " date of birth " , type : " textbox " )

The java application reads and displays a form with a field like 

 

date of birth: ____________

 

posting  the form,  the app writes in Drools an object Variable ( name : " date of birth " value " 11/31/2024 " )

At this point a rule says

If there is an object variable $ v = ( name = " date of birth " , value > today )

then

insert   Messaggio ( text : " The birth date must be earlier then today " )
retract ( $ v ).

As simple as that .

an example of this rule in this picture.

FIRST APPLICATION DRAFT

EDIT 20-11-2014

If interested in seeing other evolutions of the application here's another post on the topic "Managing a rules engine in a human way "