Back in July, we delivered a webinar entitled, "Driving Dynamic Questionnaires with JBoss BRMS: An Insurance Use Case," and a follow-up blog post. Since that webinar we've continued to enhance and improve the demo application to reflect real life rule applications. Please feel free to download the updated source code and rules, and let us know what you think, or if you have questions. You can view the originial, recorded version of the webinar here.
Here are the new things we've improved on:
- Updated the domain model used to communicate with the BRMS rules-engine and the front-end GUI/client app.
- Enhanced the AngularJS front-end GUI look & feel.
- Looked at nested questions and questions with multiple answers
- Improved the performance by caching the Kie Session.
- Implemented a new BRMS feature, the Scorecard to calculate a quote risk factor.
Domain Model - Improving Performance
Image 1 - Domain Model changes
As described before, it is important to have a well defined domain model to be consumed by the BRMS rules-engine. The more specific and detailed is always preferred, however in this demo/example of an insurance application it will become clear very early on that a lot of data needs to be transferred to and from the BRMS rules-engine. This can generate a lot of traffic on the wire, and can become a performance challenge as the project matures and more attributes are added to the domain models that needs to be transferred to the front-end client.
To avoid any future performance impacts we updated the domain model by adding the Answer model and a few changes to the Question model as can be seen in Image 1 above. The focus was on question/answer combination, where only questions are sent to the front-end and only answers are returned back to the rules-engine. By focusing only on questions for which answers were changed, we are significantly reducing the amount of data that is sent back to the rules-engine. So instead of returning a Property model with a lot of attributes linked to multiple questions to the rules-engine, we only return the answer(s) of the questions that were modified. This did have an impact on the rules defined in the rules-engine, and most of the rules were updated to use the new domain model.
A More Dynamic GUI
Apart from giving the user interface a fresh look and feel, we also integrated the updated domain model into the front-end, which allowed us to design a more dynamic GUI with more generic components allowing the re-use of components setting us up to have a more dynamic front-end that can react to data changes without having to update the front-end whenever new questions are added. A future update will be to replace front-end HTML components with AngularJS directives and services. So lookout for our next post for demo 3.0 if you are interested in AngularJS and custom directives.
Nested Questions and Questions with Multiple Answers
Now the moment you start to to play with questions and answers you will find that there are questions that can have more than one answer. Take for instance the question: "Do you own any dogs?" So if you have one Yorkie and say two Rottweilers you have to supply the type of dog and the count of how many of each. In demo 2.0 we demonstrated how to handle this case of multiple answers and potentially nested questions.
Caching the Kie Session
Another useful update was to cache the BRMS Kie Session. In the original demo we just re-created the session and re-initialize the rules-engine with the domain model changes. As noted in the demo, this was still extremely fast and no noticeable impact on the front-end client's performance. However with an enterprise insurance application that may have to handle hundreds of sessions per minute it would not be effective to re-create the Kie session every time a user updates an answer to a question, so by caching the session, it reduces a lot of setup work in the back-end and produce a faster response time to the client. Currently the Kie session was only cached using an in memory concurrent hash map, but can be expanded using the build in marshaller from the BRMS Kie services to marshall it to a byte array and persist it using an in memory data grid like Infinispan or data structure store like Redis just to mention two examples.
Scorecards - a new feature in JBoss BRMS 6.1.0
With the new release of BRMS 6.1.0 Redhat introduced a new feature called Guided Scorecards. A guided scorecard is a Risk Management tool, which is a graphical representation of a formula used to calculate an overall score. A scorecard can be used to predict the likelihood or probability of a certain outcome. In the demo we decided to calculate the risk associated with a particular insurance quote, so the Scorecard was the perfect candidate for that. There are still a few issues with the Scorecard, but in the demo we created an interface object (ScoreCardInput) in the domain model to overcome most of the issues. We used the ScoreCardInput to interact with the Scorecard and to mask all the potential answers that could impact the risk of a given quote. Any attribute on any domain model can be used as an input to the scorecard. In our case we used answers to questions like: "Have you ever been convicted of fraud?" or "When was the home built?".
Image 2 - Scorecard Characteristic
As you can see in Image 2, we took the age of the property and generated a partial score which was then used as input together with other property attributes to calculate a risk factor.
So now that you had a short run through of all the changes and updated that was made to our insurance demo, please go and checkout the source code and rules, which are both located on GitHub and free to download.
We designed this demonstration to be a fairly simple example of a practical yet powerful use case of a rules engine. Our expertise and experience goes much further, however, and we'd love to hear from you if are considering, planning, or need assistance with an implementation of JBoss BRMS.