I’ve published an article over at the RealRules Blogzine on programmatic generation of rules, i.e. why and under what circumstances this makes sense. Check it out.
I’ve published an article over at the RealRules Blogzine on programmatic generation of rules, i.e. why and under what circumstances this makes sense. Check it out.
I posted a reply on RealRules but I wanted to comment here also. I don’t think any vendor of a modern business rules management system expects non-technical users to use the IDE. This is why they all allow the generation of rule maintenance applications in some way. Suggesting that programmatic generation is needed to avoid using the IDE seems off-base to me.
Check out http://edmblog.fairisaac.com/weblog/2005/09/how_do_business.html or http://www.ebizq.net/blogs/decision_management/2006/04/concurrent_business_engineerin.php for instance.
James,
you make an excellent point. Yes, if at all possible, it’s preferrable to work with a rule maintenance app so you can avoid mucking about with some internal rule representation. There are two cases, at least however, where that approach won’t work.
First, if your vendor doesn’t provide you with the functionality to support a rule maintenance app, then your only option may be generating rules directly.
The other case is where rules are parameterized for simplicity. You might have a wizard that takes in four parameters but generates a dozen rules behind the scenes. I’ve seen this requirement quite a bit in medical apps, where the need for a non-shortcircuited OR forces you to generate multiple rules.