Re: [rules-users] Web decision tables (Guvnor)
Thanks for the feedback chaps.
Wolfgang / Vincent - The real application is evaluating what products (FX swaps, options,
forwards, etc) a particular account is permitted to trade with different banks. The
example provided was rather simplified, just to demonstrate the workings of a decision
table and what I was hoping to do with it. The way the system is designed, there should
always be a rule within that table, firing and inserting a new fact into working memory.
The system collates responses from a variety of rules in order to provide detailed
responses on why a particular transaction is permitted or not.
My thinking for now is that I'll break it into separate tables, which as per
Mike's response will at least get the 'otherwise' working in a more readable
manner. An added benefit is that this particular decision table had hit a few hundred
rows, and it's looking like a table-per-account approach will be more manageable.
Somewhat like Wolfgang's idea, I think I may handle the potential of these rules not
firing through a separate technical rule which looks to see whether a rule response fact
has been inserted by one of these rules. It's not too tricky to do, but I had hoped
there might be a neater way to do it within the decision tables. Where possible I like to
keep my rules nicely encapsulated so that future developers won't be caught out by
'hidden' technical rules, which are tightly coupled to rules which are managed by
the business within Guvnor.
Mike - I'll have a think on wording a Jira enhancement request. I think it would be
useful, so if it's in Jira, then at least it might get built at some point in the
future in the unlikely case that you find yourself with some time to kill. ;)
Many thanks all,
Steve
On 10 Aug 2012, at 17:00, Wolfgang Laun wrote:
If any of the "positive" rules for a Trade (account==N,
currency=="XYZ") were to modify or retract the fact a single
low-salience technical rule triggering on the modified or remaining
fact would be sufficient to implement an "otherwise" for everything.
Which account and which currency is available from the fact itself.
If modifying or retracting is out, consider inserting a "Done" fact
referring to the Trade, and the low-salience rule is almost as simple.
-W
On 10/08/2012, Stephen Masters <stephen.masters(a)me.com> wrote:
> Hi folks,
>
> Given a decision table a bit like this (hopefully the monospaced font lays
> it out ok!):
>
> Account Currency CanTrade
> 1 EUR Y
> 1 USD Y
> 1 IDR Y
> 1 Otherwise N
> 2 EUR Y
> 2 USD Y
> 2 Otherwise N
>
> LHS conditions are generated a bit like this:
> account == 1, currency == 'EUR'
> account == 1, currency == 'USD'
> account == 1, currency == 'IDR'
> account == 1, currency not in ('EUR', 'USD', 'IDR')
> account == 2, currency == 'EUR'
> account == 2, currency == 'USD'
> account == 2, currency not in ('EUR', 'USD', 'IDR')
>
> … which has the effect that for account 2, currency IDR, the rule does not
> fire. For the business analysts building the rules, this does't make a lot
> of sense, as they're expecting it to mean:
> account == 2, currency not in ('EUR', 'USD')
>
> Unfortunately this means that if a currency is permitted for one account,
> then a row must be added for every other account, indicating that the
> currency is not permitted.
>
> I'm trying to achieve a sensible default (fire the rule to reject the trade)
> unless the currency is explicitly permitted.
>
> Is there a decent mechanism for achieving this in a decision table?
>
> One alternative I can think of is to create a technical rule which logically
> inserts a rejection which exists as long as this rule hash't fired. But I
> would really prefer to avoid doing anything like that, as I reckon it would
> be something of a maintenance nightmare.
>
> Any thoughts?
>
> Cheers,
>
> Steve
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users