使用UI编写JBoss Drools规则(Authoring JBoss Drools rules using UI)

我们正在使用JBoss Drools将一些特别容易在我们正在构建的服务中改变业务逻辑的外部化。

这些规则可以由我们的开发人员创建和维护，这非常有效，我们拥有良好的集成和集成工作流程。

我们希望将其用途扩展到需要非常高级别定制的新服务。 基本上，“专家用户”需要能够设置两种不同的规则：

“标准”规则 - 这些是我们知道的常见要求的几乎隐含的规则，我们可以构建用于设置的UI，例如仅允许在两个日期之间进行某些操作等。

“自定义”规则 - 完全脱离墙要求尽管我们可以尝试并期待我们宁愿让人们编写并测试他们自己的规则:)

我的问题是，对于1和2使用Drools是否可能（实际上还有什么可以作为例子）？ 基本上，要有一个固定的UI应用程序作者Drools规则有效并且在我们的UI中嵌入了“自由文本”规则编辑器？

任何建议赞赏！

We're using JBoss Drools to externalise some particularly prone to change business logic in some services we are building.

Where these rules can be created and maintained by our developers this is working very well and we have a good level of integration and integrated workflow.

We are looking to expand its use to a new service that has a very high level of customisation required. Essentially an "expert user" needs to be able to setup rules of two different kinds:

"standard" rules - these are almost implicit rules that we know are common requirements and which we could build UI for to set e.g. only allowing certain operati to take place between two dates etc.

"custom" rules - completely off the wall requests that whilst we could try and anticipate we'd rather just let people write and test their own rules against :)

My question is, is it possible (and indeed is there anything out there as an example) of using Drools for both 1 & 2? Basically, to have a fixed UI application author Drools rules effectively AD have a "free text" rule editor embedded in our UI?

Any suggesti appreciated!

最满意答案

你有几个选择。

对于（2），您可以简单地将Guvnor中的规则编辑器嵌入到Web应用程序中。 Guvnor中的所有编辑器都是可嵌入的组件，因此您可以选择要使用的内容和不使用的内容。 我在这种方法中看到的问题是你可能给用户太多的权力:)。 换句话说，基于模型编写任何规则的能力需要通常仅为技术用户所知的规则。 例如，编写测试来验证规则。 一些商业用户有足够的技术知识，但我想说这可能是例外，而不是规则。

大多数时候我更喜欢和推荐的是开发自己的特定于域的GUI，它使用/公开业务用户熟悉的概念和术语，以及编写对他们的特定工作“有意义”的规则的方法。 有时，他们甚至不知道他们正在写“规则”，但他们会。 在幕后，您的应用程序从域特定GUI获取输入并使用drools API或基于字符串的模板动态生成规则。 这解决了你的（1）要求，但也可能足以解决（2）。

You have a few opti.

For (2), you can simply embed the rules editor from Guvnor in your web application. All editors in Guvnor are embeddable components, so you can choose what you want to use and what you don't. The problem that I see in this approach is that you might be giving too much power to the users :). In other words, the ability to write any rules based on the model requires disciplines that are typically only known to technical users. For instance, writing tests to validate the rules. Some business users have enough technical knowledge for that, but I would say it is probably the exception, not the rule.

What I prefer and recommend most of the time is to develop your own domain specific GUI, that uses/exposes concepts and terminology that are familiar to the business users and a way to write rules that "makes sense" for their specific job. Sometimes, they will not even know they are writing "rules", but they will. Behind the scenes, your application takes the input from the Domain Specific GUI and generates the rules dynamically, either using the drools API or a string based template. This solves your (1) requirement, but might be powerful enough to solve (2) as well.