[rules-users] Web decision tables (Guvnor)

[Wolfgang Laun]

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 at 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
>
>