如何在Drools 6中重写规则和决策表

Question

有一个场景，我们有一组主规则。其中一个规则类似于下面的规则:

rule "Check Eligibility"
when 
    $response(type=="rest",age== 25)
then 
   $response.setSendLetter("Y");
   $response.setUpdateStatus("eligible");
end

这些规则将对客户可用。我们希望我们的客户能够自定义规则。如果决定不定制，那么规则应该适用于他们。定制可以在"when"中添加额外的条件，也可以覆盖现有的条件，并添加或修改"when"部分。他们也可以添加到规则的"then"部分。

类似:

rule "Check Eligibility"
when 
   $response(type=="rest",age== 27, state="IL")
then 
   $response.setSendLetter("N");
   $response.setUpdateStatus("eligible");
   $response.setSendEmail("Y");
end

我们也有一些决策表需要类似的定制。

根据规则，最初建议使用"extends"，但据我所知，"extends"作为"AND"工作，它将检查父级和子级的条件，如果两者都为真，它将执行"then"部分。

我能想到的可能的解决方案是为每个客户克隆主存储库，然后每当主存储库规则发生变化时，我们就拉入客户存储库。可能的问题可能是偶尔的合并冲突，可能必须手动解决。

克隆解决方案还没有被团队接受，所以想知道对于规则和决策表实现"覆盖"的可能解决方案是什么?

Answer 1

这是一个技术问题和一个管理问题。

如果你的管理层决定让客户乱搞规则，他们必须意识到后果。显然，不会让客户独自遵守他们的规则，但您的组织将继续对整个应用程序的完美功能负责。你不可能免费做到这一点，客户的回旋余地越大，成本就会越高。

对此没有令人满意的技术解决方案。扩展不适用于您所描述的那种修改:规则必须被替换。

1. 您可以(正如您所写的)复制DRL文件(在您的CM系统中创建分支)并让客户编辑。这是一种干净的方法;您可以使用额外的测试(要分支的另一个配置管理项目)测试客户的基线，并使用众所周知的配置管理技术进行部署。
2. 另一种选择是让客户编写另一个包含需要更改的规则的DRL文件。但是，您不能将此DRL文件与原始文件一起编译;不允许重复规则。有一些解决方法，例如，通过替换已编译的kieppackages中的规则，或禁用KieBase中覆盖的规则，但它们都有要求使用不稳定的内部API的令人讨厌的暗示。
3. 您可以尝试定义允许客户使用的DRL语言的一个子集，并允许使用基于该子集的某些DSL(可能是XML或类似的)编写和覆盖规则。然后，生成器可以检查数据并创建DRL文本。使用这种方法，重写是一个简单的功能，由生成器处理。但是还需要大量的开发工作。

至于在Excel文件上写成电子表格的决策表，你无论如何都需要克隆。