You could do the second rule many different ways. One that springs to mind
is to assert a Transaction object at the start of a transaction and use
c: Customer (status == "suspended")
Transaction(transactionType == TransactionType.NEW_ORDER, customer == c)
Something along those lines - basically just think about what information
you have at the instigation of the transaction that would allow you to
determine the type of the transaction and the customer and assert them. If
you are only asserting one customer into the WM then you could do away with
needing a customer property on the Transaction object as you could assume
On 2/23/07, Scott Finnie <scott.finnie(a)virgin.net> wrote:
rule 2 should of course read
"A suspended customer may /not/ place any orders"
Scott Finnie wrote:
> Apologies if this has been covered somewhere, couldn't find it in the
> I'm wondering about ability / sensibility of above. For example, say I
> want to model the following rules:
> 1. A customer must be suspended if they default on a payment
> 2. A suspended customer may place any orders
> Now the first one I can readily map to the when/then format of
> production rules. But I can't see how to elegantly represent the second
> one - at least not in a transactionally clean manner. I could write:
> c: Customer (status == "suspended")
> o: Order ( customer == c)
> o.reject() #etc.
> But that's not really what I want to achieve. Rather, I'd like the
> check enforced before the order was created, not after.
> Or maybe I'm just thinking wrong? Main influence is RDBMS, where I'd
> write a trigger that would stop the transaction completing if violated.
> Hope that makes sense, and thanks in advance.
> - Scoot.
> rules-users mailing list
rules-users mailing list
Office: 8615 4500 Mob: 0439 898 668 Fax: 8615 4501
consulting | development | training | support
our experience makes the difference