Well, actually my previous rule will fire a false positive if any lab
event has more than one 1 result greater than 1.8. Lets try it again:
Number( intValue > 1 ) from accumulate(
LabEvent( eval( dateWithinLastMonths(effectiveTime,1)), results :
laboratoryResult ) and
exists( LabResult( value > 1.8 ) from results ),
count( 1 ) )
Now I think it is right, but my mistake only adds to the point that it is
not trivial to write rules like that correctly on the first try, specially
for those not used to relational schemas or the rule language.
But talking about complexity, If you look for instance at SQL (I like to
make comparisons with SQL that is a well known relational query language),
you will see that it is not much different in structure, but some may say
that the syntax is still a bit more complex because of the join with an
select count(*) from (
select * from LabEvent e,
( select distinct labEventId from LabResult r
where r.result > 1.8 ) r2
where e.labEventId=r2.labEventId and
Now, hehe, think about the options. Would teaching Java for business
users be any better? :)
My point is that Business Users do not know development processes. They
do not know how to make automated unit tests and integration tests. Some
know about how to make acceptance tests though and obviously, they are the
ones that know the rules. So, developing rules must still be a joint effort
by Business Users and the technical team. In that joint effort, how much
will be placed in the hands of business users is a case by case analysis.
Will your company invest in training business users to write DRL? or will
your company invest in developing DSLs? or will your company pair business
and technical users? These are also case by case answers. In any case, IT
people must be involved anyway.
In the case of DSLs, yes, it is hard to create reusable DSL sentence
fragments for accumulate, but on some cases it is possible. Is your case one
Sorry for not giving you a more positive, out of the box, solution. But
at least I know you are on the right path, thinking about the
operationalization of the solution. :)
2008/7/30 Yoni Mazar <y.mazar(a)gmail.com>
Yes, your proposed solution does work.
Unfortunately, the accumulate-count function is not well described in the
In addition, I still have a concern. The required business functionality is
simple, but the implementing rule is very technical and not trivial. I can
hardly expect a business user to write such a rule. Providing a DSL for
accumulate looks (at least to my eyes) impossible.
Will it help to assert the LabResults to the working memory (in addition to
the LabEvents)? Will it help to split this logic to two rules (one filters
the LabEvents into a temporary collection, and one count this collection).
Thanks for the help, Yoni
Edson Tirelli-3 wrote:
> What about:
> Number( intValue > 1 ) from accumulate(
> LabEvent( eval( dateWithinLastMonths(effectiveTime,1)), results :
> laboratoryResult ) and
> LabResult( value > 1.8 ) from results,
> count( 1 ) )
> Accumulate supports multiple patterns and has the count() function.
> Try it out and let us know.
> 2008/7/29 Yoni Mazar <y.mazar(a)gmail.com>
>> Hi all,
>> Our object deals with the clinical domain. We have a class LabEvent that
>> represents a visit in the laboratory. Each event is associated (using
>> laboratoryResult association) with one or more LabResult objects
>> each represents the results of a particular test.
>> in the rule LHS we want to express the following condition:
>> "At least two LabEvents in the last month, with a LabResult with value
>> greater than 1.8"
>> of note, the application asserts the LabEvent objects to the
>> in DRL we tried to write it as:
>> ArrayList(size>1) from collect(
>> LabEvent(eval( dateWithinLastMonths(effectiveTime,1)),
>> LabResult( value >1.8) from results)
>> Of course, the problem is that collect expects a single pattern...
>> Does anyone has a simple idea how to express this business logic?
>> Thanks, Yoni
>> View this message in context:
>> Sent from the drools - user mailing list archive at Nabble.com
>> rules-users mailing list
> Edson Tirelli
> JBoss Drools Core Development
> JBoss, a division of Red Hat @ www.jboss.com
> rules-users mailing list
View this message in context:
Sent from the drools - user mailing list archive at Nabble.com
rules-users mailing list
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com