3:23 p.m.
Agenda groups seems to fit. They are used to specify what mode of processing you're
in and what rules fit that mode. The "{handwave handwave}" in that case is not
arcane, it's a setFocus() call on the agenda. :) And there's only two ways the
system can know what mode it must be in: 1) There's some detectable condition that
triggers said mode (as in the example you linked to) or, 2) you tell it explicitly. (As in
a setFocus() call before you fire the rules.)
And yes, you'd no doubt have to hide the syntax from the business user with a DSL,
unless you want them learning drools syntax.
Also, you've mentioned some alternatives and how they don't feel right to you.
What would be the structure of a solution that would feel right?
There is another alternative: use control facts. This approach is useful if you want to
process many modes at the same time. Rules would look like this:
rule "Foo"
when
Mode(name="pricing", t : target)
$product: Product(this == t)
...other conditions...
then
...stuff...
end
The Mode would be a class with String name and Object target members. When inserting the
Product working memory you'd also insert a Mode with name "pricing" that
pointed to the Product. So the Mode object is a fact that is used solely for control of
rule flow.
The DSL for rules could look like this
We're in Pricing Mode (translates to "Mode(name="pricing", t :
target)")
There's a Product (translates to "$product: Product(this == t)")
...etc, etc, etc...
This is an old school method that was used before such conveniences as agenda groups came
to be and I still prefer it in some cases.
--- On Fri, 2/19/10, Laird Nelson <ljnelson(a)gmail.com> wrote:
From: Laird Nelson <ljnelson(a)gmail.com>
Subject: [rules-users] How many KnowledgeBases?
To: rules-users(a)lists.jboss.org
Date: Friday, February 19, 2010, 1:01 PM
Forgive me for what I suspect is an
elementary question. That said, I did not see it explained
in newcomer-friendly language in the documentation, if at
all. And I'm a newcomer!
I'm working on a system for--among other
things--pricing things. Drools Expert is a great fit for
this.
The system also has to do other things that have nothing to
do with pricing (let's say shipping, to keep it
simple). There are places where Drools Expert is a great
fit for this as well.
In both cases, let's assume I might insert a given
product into the engine, turn the crank, and collect my
results. But the kinds of results I'm looking for--and
the kinds of calculations I would expect to be
performed--are quite different in each case.
So, let's assume that--naively speaking here--when I
insert the product and {handwave handwave} I
"know" I'm doing pricing work, then I only
need pricing-related rules to fire (I don't need the,
say, product-color-determining rules to fire, or the
can-the-product-be-shipped-to-Abu-Dhabi rules to fire, or
the how-many-people-liked-this-product rules to fire,
etc.).
And when I insert the product and {handwave handwave} I
"know" I'm doing--whatever--shipping work,
then I don't need the pricing rules to even be
considered.
I found this (http://n3.nabble.com/Grouping-rules-td55531.html#a55531)
as perhaps one way of creating different sets of rules to be
evaluated in different contexts. This smelled very arcane
to me for this purpose, but...? perhaps it's the way to
go?
Another is obviously to create n KnowledgeBases, each with its own set of
rules, where n is the number of contexts or
activities or types of activities that I'm performing.
Then I'd look up the (pre-created) KnowledgeBase
appropriate for the particular calculation I need
performed. That seems like solving the problem with a
crowbar, a length of iron pipe and a blowtorch. Ick.
Is there an accepted/preferred way to handle this sort of
thing? Agenda-groups seem...well, perhaps they'd work,
but it seems awfully arcane for something that I was hoping
would be a little more end-user friendly. Quoting the
Expert manual:
When Should You Use A Rule Engine?
[...]
Domain experts often possess
a wealth of knowledge about
business
rules and processes. They typically are
nontechnical, but can
be
very logical. Rules can allow them to express the
logic in
their own
terms. Of course, they still have to think
critically and be
capable
of logical thinking.
My domain users would almost certainly not think in terms
of agenda groups. Perhaps I could hide this in a DSL or
something, but it seems to me there must be some facility
built into Drools for separating collections of rules into
channels, or groups, or partitions, or.... Is there?
Best,
Laird
-----Inline Attachment Follows-----
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users