我们有一个在 XML 中存储规则的自定义业务规则引擎。XML 目前由相当技术人员编辑和理解。
围绕这些业务规则的管理正在持续开发几个用例:
以图表方式表示现有的业务规则,从而对现有规则有更广泛的理解;
构建允许业务用户使用图表工具创建这些规则的功能
我们正在考虑探索 Visio 2010 (BPMN 2.0 Notation) 的路径,以使用可能的 xml 转换层绘制图表。
欢迎任何想法。
我们有一个在 XML 中存储规则的自定义业务规则引擎。XML 目前由相当技术人员编辑和理解。
围绕这些业务规则的管理正在持续开发几个用例:
以图表方式表示现有的业务规则,从而对现有规则有更广泛的理解;
构建允许业务用户使用图表工具创建这些规则的功能
我们正在考虑探索 Visio 2010 (BPMN 2.0 Notation) 的路径,以使用可能的 xml 转换层绘制图表。
欢迎任何想法。
之前已经说过很多次了,但我要再说一遍,因为我在业务规则行业(大学,而不是供应商),业务规则正在迅速成为任何 IT 开发中非常重要的一部分。
您的团队很可能会花费大量金钱、时间和精力来重新发明轮子。创建可以评估您的规则的代码通常不是问题。而且您似乎已经解决了。现在您正面临其中最具挑战性的部分:UI。
尽管所有书籍都说业务规则最重要的一点是业务逻辑与主系统的分离,但实际上拥有业务规则引擎最重要的一点是让业务人员能够自己创建这些规则,不打扰程序员。这意味着一个坚实的用户界面。
有一些具有出色用户界面的业务规则引擎可以完成您需要的一切,而且它们可以以更少的钱更有效地完成这些工作。其中一些是免费的或有免费选项。
以Drools为例。这是一个超级表演者。但它只对程序员有用,除非您将Guvnor添加到图片中。在 Guvnor 之前,Drools 只在那些更关心评估性能而不是可用性的大公司中流行。
因此,在您自己进行如此庞大的构建规则 UI 的项目之前,至少先看看其中的一些。如果您在 Java 平台上,请考虑使用 Drools。您还可以查找位于 MS Workflow Foundation 中内置的规则引擎之上的商业 UI 组件。所有这些引擎都以 XML 格式保存它们的规则,它们都有很棒的 UI(或 UI 组件),而且都是免费的或相对便宜的(可能除了 InRule 和 BizTalk。)
我确实希望这可以帮助您节省您的团队将要经历的所有麻烦和费用:)