Hi everyone! This week, I had the chance to participate in my first yearly Code Camp in the beautiful mountain scenery of Engelberg.
I had the chance to team up with @Elio Di Puma and work on the Rule Editor, gathering experience designing an Axon Ivy editor for the first time. While Elio was focussed on the backend functionality, I took the chance to design a prototype for the new Rule Editor UI.
Context
The Rule Editor and its underlying Rule Engine are features that have existed in the Axon Ivy engine for quite a while. The editor allows users to specify repeating business decisions into a set of understandable rules. The usage is simple enough to be used by business users without in depth technical knowhow.
With the current move to VS Code, the rule editor has not been a priority in the upcoming release and has therefore been neglected. The code camp week was the perfect opportunity to clean up technical debt and update the backend and the frontend to the new changed tech stack.
Goal
Our goal was to design a first prototype in order to give customers an insight into what the new Rule Editor could look like. This means a new design for the Rule Editor that highlights simplicity and clarity, as well as a new, simple data model and JSON structure in which the rules are defined. While defining the new structure, we also kept in mind our long-term goal of being able to convert existing rule files into the new format. Finally, we wanted to create a dedicated new native Rule process element that makes it easy to integrate rules into a process and define which data is passed into the rule.
Result
In the beginning, we sketched out some ideas and the basic functionality. The idea is a set of rules that is made up of one or more Rules.
The editor receives a JSON file made up of rules (here called rule/DiscountCalc.r.json) as well as an existing data class that is used as an input to the rules.
The editor then displays each defined Rule in a row, where each row is made up of an arbitrary number of Conditions and Results (that are applied, if the Conditions hold)
On the process side, we also created a new native Rule process element that allows a rule file and the corresponding data class to be configured. Similar to the old solution, all .r.jsonrule files are kept in a root rule folder within their defined namespace.
We managed to get the individual pieces more or less up and running, but there is still some work to do to make them fully work together and properly integrate the new editor. Both the Rule Editor and the process element need some more love and fine-tuning before they are ready for production. Nevertheless, this was a first important step for us and gave us a lot of new insights and learnings along the way.
