Externalized Rules Using a BDSL

[Clayton7510]

I'm thinking that it would be cool to be able to have rules stored outside of the application (and the JVM) and have RuleBook be able to point to those rules and use them.

Supported languages and format is currently TBD. Maybe Groovy?

[ksmithorn97]

Your format seems to fairly well match Gherkin. You could use the gherkin parser to auto generate the structure of the code and then fill in the programmatic details from there. This seems to be fairly common in the cucumber world.

[Clayton7510]

@ksmithorn97, that's not a bad idea. The inspiration for the existing Camel-style chained method DSL was Cucumber and Spock. I also like how Gherkin is intended to be just text (as opposed to Java, which is compiled into byte-code).

[Clayton7510]

Looking into Gherkin, it gives me a few things that I really like.

1. A nice, well established BDSL
2. I can leverage an existing library
3. The code is text, so storing and using it as text is not only possible, but expected
4. Gherkin has support in popular IDEs

But then there are a few things I don't like

1. Gherkin is very Cucumber specific and that bleeds into the language. It uses language like 'feature' and I want to use language like 'rule'.
2. It's a 2 step thing as stated above: .features are mapped to code, which IMO is a little more cumbersome that I would like

So, I think both Groovy and Gherkin are in the running - Groovy because it's practically made for creating nice tailor fitted BDSLs, and Gherkin, because it already has one that's close, but not exactly what I want.

[imavroukakis]

How is this coming along?

[Clayton7510]

I have pushed this back this enhancement until after the refactoring + DSL updates. However, those updates should be completed this week - most of them are already done, updates for Spring support are pending. So, the Java (internal) BDSL is becoming pretty solid, which I feel needed to happen before more of an external BDSL could happen.

Another important thing that the pending release (currently in the develop branch) brought in was the abstraction of the DSL from the model. This also paved the way for additional or custom DSLs without them having to rely on the approach implemented in Java and currently packaged with the core RuleBook functionality.

Next up is adding a high performance the rule chaining algorithm to hush the CoR rule chaining haters (if that's even possible) Issue #25 and live/dynamic rules versioning Issue #20. A Groovy or other BDSL will be coming after that - maybe 6-8mo out if I had to estimate.

In the meantime, check out the Java DSL updates for RuleBook in the develop branch. The Java DSL has come a long way in a short time and I think you will find it pretty intuitive and flexible.

[ivanbportugal]

The most interesting part of this feature is to be able to store the rules outside of the code itself. I could care less about using text vs your existing DSL as a developer, but consider the opportunity it presents for a business user to create and edit their own custom rules in a web UI.

[Clayton7510]

I agree, that is a huge benefit and a wider use case. It will get there. The expectation is that this feature will be part of the 1.0 release. Prior to this is enhanced Groovy support (since the current path is to use Groovy scripts for external rules) and Rules Auditing (currently under development).

[tuscland]

Would really love to have this feature! Is there a flexible workaround at the moment? We would prefer not hard-code the rules in our application right now.

[Clayton7510]

@tuscland I think at the moment, the flexible workaround would be to have rules contained in a separate module, or better yet, have them executed within a specific context in an independently deployable service. So, the service, could change (with new/updated) rules, but the application that's dependent on the service would remain the same since it would invoke those rules through a well-defined interface (i.e. a service contract).

[tuscland]

Thanks Clayton, sounds good.