I have a question about rule storage and referencing with the JBRMS.
Mostly this is directed to Michael Neale (since I believe this is his
baby), but since I cant catch him on IRC I'll post it to here to see if
others have this similar concern.
A little history before I get to the question. We have been using drools
since 2.x (still on 2.x) and have developed much around the core engine.
The way we currently store rules is in a database, at runtime we pull
them out and write an xml file. What this allows is rule referencing
back to the authoring source. We translate from DB->XML so the "then"
returns the ID. We also use it to create unique names for rules. In our
editor we have notes, versions and the complete rule code, similar to
the new JBRMS. When a rule fires in our system the purpose may be to
show an error or change a price. Either way sometimes people ask why did
this fire, or further, they dispute the rule all together. So in each
message or price change we track the ID of the rule being fired/applied.
From that we have developed 2 tools, one to lookup a rule and see a
great deal of info about that rule (whats/whys), the other is an
Override tool that allows you, given authority, to associate a rule ID
to a transaction and have coded so when the engine fires this rule, it
will be ignored by the system. Obviously how we override is not
something I expect you to solve, but giving me the ability by having a
unique ID would be.
I would think the desire to "Track" and "Override" a rule is pretty
high
for most people using a rule system in an enterprise. What makes this
possible is exposing a unique identifier in the storage of rules (think
database and editor) as well as the execution of rules (as they fire). I
setup the MR2 of the JBRMS and tried to look at the storage system to
see if a rule had some unique identifier that we could use, and found
none. Seems like a rulebase is a blob, though maybe I'm just looking at
it wrong.
So my question and/or request is there a way to have each rule have a
unique identifier (by version is fine) in the JBRMS storage system. I
think this is the first step, the second is harder but make the system
associate the ID to a rule at execution ("then"). Similar to the option
of expiring a rule at X date.
While this may not seem huge, and is definitely not as cool as changing
semantics in MVEL, it is a huge barrier of adopting this new very
feature rich JBRMS.
Thanks,
Michael Rhoden