[rules-users] Looking for guidance / approach to porting a question graph to Drools

[Wolfgang Laun]

See below.

On Fri, Aug 28, 2009 at 12:49 AM, tim fulcher <
against.entropy at googlemail.com> wrote:

> Hi
>
> Making no bones about it, this is a broad topic request and I've got
> little hands-on Drools experience, just looking for some pointers on a
> potential Drools approach, feedback appreciated.
>
> Background:
> We have a system which asks online users questions to diagnose an
> issue (the problem domain isn't important right now).
> The questions are structured in a tree/graph such that one question
> leads to another until a conclusion - not exactly rocketscience to
> this list I suspect! Any question will have n outputs (defined in
> configuration); each output is mapped to an option in an HTML
> select/radio button.
>
> The key issue though is that this question flow is all running in the
> browser, by reading in an XML configuration and parsing this in
> javascript. Instead I need this executing server side, i.e. in a rule
> engine. One reason is that increasingly questions are being automated
> - currently we make an ajax call which decides upon the outcome to
> select and therefore move onto the next. This is however a little
> clunky at present.
>
> I see Drools as a potential execution engine for our reworked system,
> running rules until needing a manual question to be asked, and
> triggering question display in a page. Upon the answer the flow
> continues in that fashion until a conclusion is reached.
>
> Specific queries:
>
> We have a legacy stack of question flows, how to adapt them into a
> syntax amenable to Drools? Can I do this at runtime?
> ( Our question graphs could be accessed via database access or in an
> XML format )

For modeling and processing the questions as fact objects, XML is
well suited. If the XML schema is well designed, you may unmarshal
(using JAXB) to objects which are ready to be inserted as facts.



> Given many questions have >2 outcomes, I assume each question-answer
> permutation would be a rule?

This would depend on whether distinct activities other than storing the
answer and proceeding to the next question as a function of the current
answer is required. A generic QA handling would be

when
  $i : Issue( $a : answers )
  $q: Question( $next : next )
  Answer( issue == $i, question == $q, $v : $value )
then
  mouth.ask( $next.get( $v ) );  // global service
  $a.put( $q, $v );
end

>
>
> Does every question have to be mapped to a bean to become a fact to
> operate on? Given our questions are of a few broad types
> (boolean,numeric,select one) is that all I need to model?


It's possible that you can have your questions as data in a map, not as
individual facts. The rule engine would then just handle the "abstract
QA algorithm", asking Qs, registering As, pursuing the issue, going
back to previous answers, etc. If this isn't feasible or practical, you
would indeed have all Qs as facts. Presumably a small hierarchy of
classes (AbstractQ, BooleanQ, NumericQ, EnumQ ) is sufficient.


>
> In our current setup a user could decide to re-answer an earlier
> question and therefore take an alternate route. What would be the
> equivalent in Drools?


Easy: There would be a rule determining that A(Q) is already there;
the fact representing the Q might determine whether this is permitted
etc.

>
> If this is viable, will I need 1 rule outcome to pose a question and
> another to operate on the outcome, i.e. will the rules fire up
> to/including the decision to ask a question, then when an answer fact
> is injected into working memory the rules will fire from that point
> onwards?
>

In such a scenario a session might "run until halt", possibly with one
set of rules being conditioned to fire when there is an unhandled anwer,
and another set prepared to fire when there is no open question in
the WM.

HTH
-W

>
>
> Thanks
>
> A:E
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090828/4b24a6c9/attachment.html