The Jare Ruleengine comes with a lot of predefined checks. They check a certain condition like "is smaller than", "is not null", "starts with", "check matches", "list has member" etc.

And there are also several predefined actions. They are applied based on the results of the rules (or more correctly the result of a rule group). There are actions like "set value", "concat field values", "append value", "substring", "sum" etc.

Both checks and actions can be easily extended to create new ones. So if you have a situation where writing the rule logic is very cumbersome or you can't easily achieve what you need to define, then you could think of writing a check that helps you get the job done more easily.

Same for the actions. If you want or need a specifiy handling after a group of rules passes or failed the tests, then you could write an action, that does the job. E.g. log entries, sending messages, trigger another process, etc.

Both checks and actions are easy to extend, so over time you could build up a library of them, if the basic, already existing checks are not sufficient.

And it would be nice of course, if you can share your extensions with the rest of the community.

I created a video, showing how to calculate discount using Pentaho PDI and the Business Rules Maintenance Tool.

Again, the idea is to externalize the rules and to not have the rule logic inside the transformation. This way - if the rules change - the transformation does NOT need to change. It's also a clear devision of responsibilities: IT cares for the transformation and the business about the rules.

Have fun.

More things to do....

When using the API to load and use a Pentaho PDI transformation, there is more to do than one would think at the beginning:

I really only want to find out, which input fields are used by the Rule Engine step. That sounds easy enough, but it's not: The API loads the transformation and has to evaluate all steps prior to the Rule Engine step to find out what fields are used.

If the transformation uses non-standard steps, then the web server serving the Rule Maintenance Tool needs to have those steps also installed.

If the transformation uses parameters - and e.g. those parameters are used in a SQL query - then the parameters have to be specified to successfully use the API.

If the Rule Maintenance Web App runs on a seperate server - where no PDI instance is available - then I end up in a situation where the webapp has to have the core Kettle/PDI jar files and the plugins. That is a lot of work for the people setting up the web app. Also, it makes the web app much more complex and in case there is a new PDI version or new versions of steps/plugins, then there is also some work to be done so that the web app works properly.

I wish PDI had a way to cache fields - names and types. So that it would be easy to retrieve fieldnames for a step without the requirement to have half of the PDI tool available.

But for the moment I will stop at the point where I am and think if there is maybe a different way of how to implement a similar functionality: all I need is the field names and types to make it easier for the user to write rules based on these fields.﻿﻿﻿