On 31.10.20 04:32, Winnebeck, Jason wrote:
Yep, in this case, it is true. We used to use a rules engine, IBM
JRules, we retired it years ago and converted all of the rules into
Groovy. It cost 6-figures annual support, forced us to use Oracle
Weblogic, was extremely slow, took a huge effort to map the data model
into it so you could write “English-like statements with it” and the
whole “point” of it is that non-developers could theoretically update
it. Except programming is not hard because learning Java/Groovy syntax
is hard. The hard part is figuring out what to do, regression testing,
making it perform well, etc. So ultimately the business farmed all of
the edits out to the programmers, so instead of programming in code, we
program in some drag and drop interface with a proprietary Eclipse
plugin that only ran in an obsolete version of Eclipse and it took 30
minutes to “compile”. It’s been a few years, but when I looked at things
like Drools, which looks closest to JRules I didn’t see a drastic
difference to the architecture. In fact, that was the reason why we
introduced Groovy into the engine, now we have 1000s of Groovy files
using STC for performance and now rule engine times are in milliseconds
instead of seconds execution times. And we have a DSL syntax created
that emulated the same structure of the rules so we could largely
copy/paste the code or generated code into when {} then {} clauses.
Except now it’s all “real” code meaning we get compile-time safety, find
usages in IDE, refactoring, debugger, etc.
in one project I used the mvel dialect to have drools conditions in
"normal" drools but the consequences in Groovy code. Back then I did
look at the Eclipse Drools stuff for testing, debugging, but since the
goal was to at least have the conditions written by business users it
was too much for them. Instead it was easier "in this project, other
projects have other conditions) to let them enter data into a test
system and then check the rule against the test data in there, before it
is considered as "fixed" and included for production. The users where
able to insert only the conditions and consequences, nothing else. Which
meant they could for example not use salt or du any kind of ordering -
but that was not actually a real requirement. Using Groovy scripts for
the consequence did mean I could help writing them by providing some
easy DSLs and custom objects to interact for example with the database
if requirement.... Similar extension I had to write for the conditions
as well - for example a function that tells me if country x is an
country of the EU, or if the country is on a blacklist. You want those
configurable of course (even before the brexit).
For me that unified two worlds in which I was able to use Drools and its
way post Rete way of analysing conditions and evaluating which one to
fire, together with some easy DSLs. It did mean the business users had
to learn how to write conditions. And in most cases it was enough to
tell them how to get through the different branches of our main domain
object, which was developed together with them (and totally bloated
because of that)
I think if there would have been more time for the project, they would
not have been forced to write and test the rules themselves and instead
let me do that ;) But it worked out, and I only had to help in some
complicated cases.
And writing those conditions I noticed actually that programmers did
tend to have more difficulties with that, than non-programmers. Because
of the set approach here, which has nothing to do with procedural
programming.
In Retrospect I think I did make it quite a bit more difficult then I
really had to. Paul's groovy-rules goes in a similar direction regarding
using mvel to write code in Groovy (not the other constraints). But in
my case I did not produce a rule, that contained Groovy code.
You have to deal with problems like "what happens if the consequence
produces an exception". For example we still wanted to know which other
rules would fire, even if the consequence of one rule would cause problems.
Well and that resulted in a multi-layer-system so to say. First we did
let drools do the matching and record the matches (with troubles
sometimes, when it comes to the actual matches and their values), then
we executed the scripts, but they did not write into the session.
Instead the session is considered immutable, and all the database writes
are then done in a transaction together. So if one fails, all fail and
there is no trace of the failed execution left.
I am pretty sure there are much better solutions, but you know... unless
you find the right people it used to be quite a pain back then to find
somebody knowing the internals of Drools. And while the documentation is
not bad for normal cases, it is a totally different matter for
internals. It is like you would use the Groovy syntax guide to
understand how the static Groovy compiler processes generics (and has a
lot of bugs in that)
But, in the end, we still needed to have some data tables outside of the
structure, that the non-technical business stakeholders can and do
maintain.
That is the most easy for them.. just some excel you import... we had
been able to do without - but cases vary of course.
But there is some idea to be able to add simple expressions to
that. Not to go as far as a Drools decision table. But maybe. Even if we
end up “re-inventing the wheel” a little bit, we’re still in a much
better place.
sounds fine to me.
I have had the thought of going all out and being able to upload entire
Groovy files as rules, then it really is like a rules engine. But it
comes back to the same problem – who is going to be editing this code,
and this code is not going to be in the IDE environment, using version
control, etc. So, I expect this still to be quite simple. Hence the
choice of SPEL as alternative.
You want a business user to use something like git? That was a failure
in our case. But actually I do not see an advantage of SPEL here really ;)
But Groovy has option of getting
arbitrary complex, if we wish. I especially like creating DSLs meant to
be used with command chains and it would be a good ability. Based on
several responses here and no explicit warning from Jochen, it sounds
like we’re not “abusing” Groovy to compile perhaps 100s of very small
scripts.
Surely not, did that myself in that project... it was really hundreds of
rules, each consequence was a small Groovy script, most often only a
single line. If the consequence began to become more complex we provided
a simpler version for them.
While they can change on demand, it’s likely not more than once
a week. So compilation time is not a concern. It’s only a concern of
metaspace overhead (we are still on Java 8… but we do have a big heap)
and execution performance.
I would not be worried about a few thousand mini classes in Groovy.
bye Jochen
