Conceptual hierarchy in Rulette Server
Since a single Rulette server instance can load many rule systems from many places, it is important to provide some sort of isolation so that rule system name clashes do not happen.
The topmost level in the Rulette server data hierarchy is Providers. Each Provider provides access to multiple rule systems. All rule systems exposed by a Provider are implicitly grouped under it and cannot be accessed directly (without specifying the provider name). Rules and rule inputs of these rule systems live under a two level hierarchy – we must specify both the provider name and the rule system name to access them.
This namespace concept informs the design of the REST API and UI as we will see in the following sections.
REST API
Rulette server’s REST API align very closely with the Rulette SDK API since the server itself is a only a thin wrapper over the functionality offered by the SDK. The main difference is that the API cannot return the complete RuleSystem or IDataProvider objects to us – it can only expose the metadata or the functionality attached to these objects. So instead of working with the Java objects, API clients have to work with named references. All Providers in rulette server have names, as do rule system and rule inputs. We use these names to navigate the different levels of namespaces in the REST API.
E.g. to delete a rule from a rule system, the REST API looks like this:
[Method=DELETE] http://server:port/provider/{providerName}/rulesystem/{ruleSystemName}/rule/{ruleId}
Notice the nested naming structure which allows Rulette server to locate the actual RuleSystem objects in its memory and use them to perform the requested operations.
Documentation
Rulette server API is documented in the OpenAPI (aka Swagger) format on SwaggerHub. If you are running an instance of the server, then you can access the swagger UI at http://localhost:8081/swagger-ui.html
UI
Rulette server also comes with a simple UI (built using the Thymeleaf framework) which allows users to perform pretty much all the operations that can be done using the SDK or the API. It provides a convenient way of working with rules and rule systems.
Users can view all loaded rule systems, their rules, and the metadata of Providers and rule inputs. They can create/delete rule systems and rule inputs, add/delete/modify rules of any rule system, and even evaluate what would be the output of any rule system when presented with a certain set of inputs.
Here’s a quick walkthrough of the screens in the UI.
View all rule systems
This is the homepage of the Rulette server UI. Here you can see all rule systems exposed by all the providers. You can reload and delete a rule system from here. The delete operation removes the rule system metadata from the rule_system and rule_input tables but does not delete the main rule data.
Create a new rule system
You can add a new rule system from this screen. Note that this only creates the rule system mappings in the rule_system and rule_input tables. You still have to populate the main rules data on your own.
View rule input details
Clicking on any rule input on the rule system screen will show all its details in a pop-up. You can also delete an input from here – you will have to reload the rule system after deleting input for the changes to take effect.
Add new rule input
View all rules of a rule system
Clicking on the view rules link of a rule system lists all the rules of that rule system in a paginated manner. You can delete a rule from here. Clicking on the edit button opens the next screen.
Edit a rule
You can modify values of a rule on this screen. Saving a modified rule will throw an error if the modified rule conflicts with an existing rule.
Add a rule
Evaluate output of some inputs to a rule system
Clicking on the evaluate inputs link on the rules page (almost top left) will open this screen. You can enter different values for the rule inputs to see which rule is applicable for what combination. This can be a good tool for debugging and analyzing your rule data.
