[rules-users] Use of Drools for a product catalog retrieval in a best effort fashon

Greg Barton greg_barton at yahoo.com
Tue Mar 24 14:40:19 EDT 2009


What you need here is to use a control object, probably something called "Search".  Basically a Search object would record how many query attempts have been made, the one(s) that succeeded, and the results of the successful search(es).

Basic properties for the Search object could be:

String category;
String product;
int attempts; //How many times the DB has been queried

Using this control object, you can create rules that manage the search process, from the most general to the most specific. 

These rules assume that a Search object is retracted from working memory when it's sent to a query processor, and asserted again (with attempts and failures incremented accordingly) after the query is done.  Search objects would only be asserted again after success if you want to do something complex with them at that point. (i.e. not just reporting raw results)

Here are some sample rules for managing all Searches

rule "MaxAttempts"
when
  s: Search(attempts > MAX_ATTEMPTS)
then
  //EPIC FAIL!
  retract(s);
  processEpicFail(s);
end

rule "Send search"
salience <lower priority than anything else>
when
  //Just matches automatically once higher priority rules finish
  s: Search(); 
then
  retract(s);
  processSearch(s);
end

For handling specific types of search, you could have subclasses of the Search object, with getters and setters for specific search criteria.  The Search superclass itself should return these criteria in a generic way so the search engine can create a query for them.  Some examples for a WidgetSearch subclass:

rule "WidgetAttempt3"
when
  s: WidgetSearch(attempt >= 3)
then
  //widen length property search by [-1,+1]
end

rule "WidgetAttempt7"
when
  s: WidgetSearch(attempt >= 7)
then
  //widen width property search by [-1,+1]
end

Note that on the 7th and later attempts, both WidgetAttempt3 and WidgetAttempt7 rules will fire.  

In addition, you could have Search subclasses implement interfaces that classify the type of search, and have rules that handle them similarly across the board.  For example, take interface EncryptedThing with method "Set<String> getEncryptionCriteria()":

rule "AddDES"
when
  s: EncryptedThing(attempt >= 2) 
then
  s.getEncryptionCriteria().add("DES");
end

So all searches on encrypted things will include DES after the 3rd attempt.

Each Search altering rule can be as specific or general as you like.  You don't need a seperate rule for each combination of type/attempt/whatever so this prevents any combinatorial explosion of rules.  And the above example doesn't examine existing Search contents to decide what to search next, which is also a (more complex) option.  However those avenues of complexity are available to you.  You could even continue search if some attempts are successful, and only halt when the results match some criteria. 

--- On Tue, 3/24/09, Alessandro Terrinoni <aleterrinoni at hotmail.com> wrote:

> From: Alessandro Terrinoni <aleterrinoni at hotmail.com>
> Subject: [rules-users] Use of Drools for a product catalog retrieval in a best effort fashon
> To: rules-users at lists.jboss.org
> Date: Tuesday, March 24, 2009, 10:50 AM
> Hello.
> 
>  
> 
> I'm working on a project about a product catalog, which
> involves the use of Drools for fetching from the database
> layer a set of products that support a list of
> characteristics in a best-effort fashon
> 
>  
> 
> In detail the database is constructed with the use of
> dynamic characteristics, i.e. all attributes, like
> dimensions or weight, are not included as fields in the
> table cointaining the definition of the product but they are
> stored in a different table; then the linkage
> product-characteristic is stored in a third table cointaning
> the product id, the characteristic id and the value
> associated and other necessary fields.
> 
>  
> 
> Now i would use drools for getting a limited number
> (let's say fixed - i.e. everytime max 10) products which
> has a variable number of characteristic (supplied by the
> user) in a best-effort style. For example if i search a
> router with 5 ports i could retrieve also routers with 6 or
> 4 ports if no router with 10 ports are in the database or
> there are less then 10, and so on until i get 10 (or until
> there are no more routers - obviusly i cant get 10 if in the
> db there are just 7). Now this is a really simple scenario,
> but you can imagine one user specifing several desired
> characteristics. 
> 
>  
> 
> I tought about recursive use of business rules, i mean i
> look first for routers with X ports, then X+1 or X-1 ports,
> then X-2 or X+2 ports etc. but this would lead to a monster
> number of business rules, since the characteristics are
> many. Moreover, this works fine with characteristics that
> takes on numeric values, but what about those which takes on
> Strings? I.E. encription support can be AES, DES, 3DES etc.
> In this case I should specify one rule for each desired
> request and for each step, i.e. if the user wants AES
> support then look for AES first, then 3DES, then DES etc. OR
> if he wants 3DES then 3DES first, then AES etc. (just a dumb
> example but i hope you get the point). 
> 
>  
> 
> I see this is quite a lot of rules handling.. maybe someone
> has a suggestion for another approach which would simplify
> the process? Or maybe someone had to solve something similar
> and would share some knowledge with me?
> 
>  
> 
> Thanks for the attention :)
> 
>  
> 
> Cheers
> 
> Alessandro Terrinoni
> 
> _________________________________________________________________
> Scopri le keyword più cercate della settimana!
> http://clk.atdmt.com/GBL/go/136430524/direct/01/_______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users


      




More information about the rules-users mailing list