Drools Concept

The migration of Adempiere modules to iDempiere

Drools Concept

Postby red1 » Mon Jun 20, 2016 8:31 am

Some time ago i announced that Hiep has helped me to make a Drools plugin proof of concept here http://groups.google.com/forum/#!topic/ ... G8pM4_7tPE

We want it to be a real next big killer in ERP, because:
1. Excel type decision table is an accountant's killer tool or just basically anyone working in the office. So it is very ubiquitous and universally known. The users are trained to be friendly enough with it instead of other type of application.
2. The users just want to define their specs data for many things in a table format and let the ERP access it for the results.
3. Drools Decision Table (which Hiep finally stitched in our POC) can be accessed by a standalone iDempiere plugin, to look up a Rule and return its Result.

So we been thinking (while driving from North to South Vietnam and at this point the southernmost tip at Cà Mau) of what is the next big step:
1. An abstract generic plugin that takes away all the configuring work by the user for any model to look up a decision table for a result!
2. The request from plugin for a rule need not be hard coded in the plugin or even need for a plugin!
3. It will be a push from the Drools side, where a model is defined, the plugin (Drools abstract) will sense and match the active model automatically to check if 'is there any changes for me?'.
4. If so, the associated rule-model will requests for the set of arguments from the model that the table is interested in, process it, returning a result.

The immediate coding challenge to me is:
a. How would the rule in the table match? Well, simple: just define the rule to be easily abstract: i.e. C_Order which will be the iDempiere side speak. PO<?>
b. How would the rule act upon specific actions in an event? Again perhaps simple too: i.e. C_Order.AfterSave
c. How to pass the desired arguments as conditions? As in Rule <condition,condition,result>
d. How to enact DB changes <result> from the Table side without passing back to the iDempiere plugin because it is meant to be abstract with no coding but just work solely in tables?

This last one maybe stupid in design as the Table side is not meant to do any processing work which is left to the ERP side. Perhaps the result ask the ERP to do it, but then what if there is recursive issues? i.e. The result ask to change another model, but that model also has a rule? (I read somewhere that Drools has a safe mechanism against recursive back to same rule. If so, phew!)
Site Admin
Posts: 2762
Joined: Tue Jul 06, 2004 3:01 pm
Location: Kuala Lumpur, Malaysia

Return to iDempiere

Who is online

Users browsing this forum: No registered users and 0 guests