Good advice. I further advocate that the real business logic should
happen in methods outside of the consequence, the consequence is just
the minimal plumbing to call methods to get the job done. A consequence
is declaring what you want done, not how you want it done - although
thats just a guide line.
Mark
Chalakanth Reddy wrote:
Our team is new to Drools too and we are in the process of figuring out
coding guidelines for the rules.
We decided never use a logger inside the consequence.
The consequence must express business rules only and there should be no
extra "plumbing" type code.
Something like this ....
<rule>
<condition>order.isCompleted()</condition>
<consequence>workflow.archiveOrder(order)</consequence>
</rule>
The logs from a WorkingMemoryEventListener, and the logs from the Java
classes that actually implements the business rule statements should give
us all the information we need. Or so we hope.
Does this make sense?
This communication, including any attachments, may contain privileged or
confidential information. It is intended for a specific individual and
purpose and is protected by law. If you have received this communication
in error, please immediately notify me and destroy the communication. Any
wrongful interception, disclosure, copying or distribution of this
communication, or the taking of any action based on this communication by
anyone other than the intended recipient is strictly prohibited and
punishable under federal law.
