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.
Procedural development of a tree of configurations for each product. Creation of a tailored user interface.
Pros: strong customization for each product configurator.
- 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 .
A beautiful web application that auto-configures talking to a rules engine.
What is a rules engine: Here it is wikipedia
- 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
- 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
We chose the Drools Rule Engine of the Jboss community
- 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.
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 :
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
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 )
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
If interested in seeing other evolutions of the application here's another post on the topic "Managing a rules engine in a human way "