Thank you, Steve,

I looked at KnowledgeAgent and KieScanner documentation and looks like this is something that can help in hot deployment, but not so much in safe proofing.

Here are some basic facts (or misconceptions) that I have gathered so far:

1. KnowledgeAgent and KieScanner are able to dynamically detect changes in the rules (and other resources) and hot-deploy them to running Drools installation;

2. KnowledgeAgent belongs to Drools 5.X. In 6.X it is deprecated in favor of KieScanner (which is available starting 6.0.X);

3. KnowledgeAgent transmits changes through monitoring file system for .DRL files or via HTTP connection to a running Guvnor instance;

4. KieScanner transmits changes through monitoring Maven repository. It appears like old KnowledgeAgent’s ability to transmit individual .DRL files is deprecated;

5. Neither KnowledgeAgent nor KieScanner have a built-in mechanism for error handling, at least not a sophisticated one. There is no way to perform a rollback if at some point it becomes clear that a new update is a bad one.

Thanks,

Alex

> 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