Another technique to prevent non-programmers to wreak havoc is to put them on the leash of a domain specific language (DSL). But developing a non-trivial DSL is hard work, and you might find that you just spend your money in a different way. Moreover, anything that's not too restrictive must, by definition, provide enough leeway to enable the non-programmers to program nonsense: this won't crash the system but it sure will annoy the users.
The claim that "our business users write rules" is very frequently based on them typing, into a spreadsheet or similar, parameters for a small, limited number of rule templates, which are then replicated by filling in constant values... -W On 22/04/2014, Stephen Masters <stephen.mast...@me.com> wrote: > If you want to hot-deploy rule changes, just take a look at the > documentation on knowledge agents or KieScanner (v6). It's also easy enough > to code a knowledge base reload yourself. > > However, you say: > > Ideally we would like business users to add or modify rules in > Production > without risk of crashing entire rules engine. > > Rules and facts are code, so changes could crash your system if written > poorly. Supporting hot deployment does not mean that you don't need to > regression test your changes. All it means is that you can break your system > much more quickly than before. > > The only way to get around this is to write your own UI, which prevents > users from making any rules or fact changes that 'break' your system. How > you achieve that is very much dependent on what you want users to change and > how much time you are prepared to spend writing automated tests to prevent > breaking changes from being deployed. > > Steve > > > On 21 Apr 2014, at 16:21, Pykhtin, Alex <apykh...@ebay.com> wrote: > >> Anyone can tell if Drools supports hot deployment of rules and fact >> types? >> >> We are using Drools rules (No Guvnor/Workbench), and the whole cycle >> Development-Test-Production takes a very long time. Ideally we would like >> business users to add or modify rules in Production without risk of >> crashing entire rules engine. But as of today, any rule or fact type >> change is subject to full regression testing, as any other of our Java >> code. I tried to experiment with Drools Workbench, but so far it doesn't >> look like it can help much with hot deployment. Workbench can greatly >> streamline the development and deployment process, but generally speaking, >> since all Drools boils down to Java, it is essentially another jar >> deployment. So, it looks like if we would want to simplify our production >> deployments, the only option is to abolish the QA cycle for Drools jars >> (which our QA will probably never agree to). >> >> Any ideas? >> >> Thanks, >> Alex >> _______________________________________________ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
