我们有一个决策表,除非我们的事实对象之一的字段值与(可能长的)查找值列表中的一个字段值匹配,否则不应执行该决策表。决策表的内容由非技术用户管理,我们正在寻找一种方法,以允许那些相同的非技术用户管理查找值列表。
这里是对我们已经使用Drools Workbench以及外部集成(如果需要)与正反两方面确定的各种方法的评估。我们想知道是否有更优雅的方法。
仅当字段值与一长串潜在查询值(hts代码)匹配时,才限制决策表触发:
-
要与条件列中的决策电子表格中的每一行匹配的hts代码的硬编码列表
- 优点:
- 缺点:
- 电子表格每行上的冗余信息
- 麻烦的是在电子表格单元格中管理用长逗号分隔的匹配值列表
-
规则电子表格的条件列中使用的Drools工作台中的HTS代码的托管枚举
- 优点:
- 在Drools Workbench中管理HTS列表,枚举易于管理
- 缺点:
- 与管理其他规则条件(上载电子表格中的所有其他内容,直接在工作台中管理HTS列表)相比,用于管理HTS列表的机制不同(不太方便?)
-
受束缚的决策表:1个决策表包含规则的hts代码列表,并设置标志tat导致规则表启动
- 优点:
- 在电子表格中管理HTS列表与其余规则相同-一致管理
- 缺点:
- 每个规则有两个电子表格,带有HTS /产品类别过滤器
-
存储在数据库中并在数据库中管理的HTS代码列表,可作为枚举或通过数据对象,电子表格中的规则动态加载
- 优点:
- 与当前的自定义方法一致-将hts电子表格上传到自定义ui,并将其加载到drools规则电子表格中引用的枚举中
- 缺点:
- 用于加载枚举电子表格和主规则表的单独界面
- 工作台外部的自定义UI
-
规则模板而不是决策表,所有规则数据都存储在数据库中
- 优点:
- 引用与现有规则引擎一致的参考数据,上传工作表,管理工作表到自定义用户界面
- 所有参考数据的管理方式相同(存储在数据库中,通过UI上传)
- 缺点:
- 在与参考数据不同的界面中管理规则(次要?)
- 规则逻辑将输入映射到与实际bin和系数数据不同的bin或系数(较小?)