这是规则引擎连载的第三篇。前两篇我们聊的是规则引擎的基本概念和常见选型今天这篇落到具体开发用 WebSphere ILOG JRules 新建一个规则项目。很多朋友第一次接触 JRules面对的是厚重的商业套件、一堆抽象概念连怎么把第一个规则项目建起来都要折腾半天。这篇文章我就把从环境准备、项目创建到跑通一条简单规则的完整过程整理出来给准备上手、或者正在用 JRules 做二次开发的同学一个能直接照做的参考。不管前两篇有没有看过这篇都可以独立阅读。1. 建项目之前先把 JRules 的几个核心概念理清楚网上搜“java规则引擎哪个好”的时候各种开源框架的讨论占了大半屏JRules 这样的商业产品反而容易被忽略。但真正进过银行、保险、电信这类企业级项目的人都知道JRules 这套东西在传统行业里的存量非常大。在动手新建项目之前我建议先把几个核心概念搞清楚否则后面操作起来会一直处于“照着点但不知道为什么”的状态。1.1 规则引擎解决的不只是“把 if-else 抽出来”很多人对规则引擎的第一印象是“把代码里的 if-else 搬出来”这个说法对但过于简单。规则引擎解决的问题本质上是把“业务判断逻辑”从应用代码中剥离出来让它可以独立维护、独立部署、独立变更。业务判断逻辑是什么比如电商促销里的满减优惠什么商品参与、满多少减多少、能不能叠加比如信用卡风控里的交易拦截单笔金额、商户类别、频次阈值再比如保险公司核保年龄、职业、既往病史每一条都是一条规则。这些规则今天定完明天可能就要改每次调整都要改代码、测试、上线周期长风险也高。JRules 这类规则引擎做的事情就是把这些判断从代码里搬出来用专门的规则语言和工具管理。业务规则可以交给业务人员维护也可以由开发人员配置改完规则不用重新编译整个应用部署一个规则集就够了。这个思路在规则不多的时候看不出优势一旦规则量到了几百上千条规则引擎带来的维护效率提升是肉眼可见的。1.2 “Java规则引擎哪个好”JRules 和开源方案差在哪说到选型先给一张我自己的对比结论。这些年我接触过的规则引擎主要有 Drools、Easy Rules、Aviator、URule以及 JRules现在叫 IBM Operational Decision Manager下面还是按习惯叫 JRules。引擎/框架类型核心优势主要局限适合场景Drools开源规则引擎社区活跃、生态完整、DRL 规则语法成熟学习曲线陡、规则量大时调优需要功底有一定预算控制要求的 Java 项目Easy Rules轻量 Java 规则框架上手快、API 轻、适合嵌入复杂规则和动态变更能力弱简单判断、原型验证Aviator高性能表达式引擎性能极好、语法简单更偏表达式计算不算完整规则引擎公式计算、快速动态条件URule国产开源规则引擎中文支持好、可视化程度高社区规模相对小、复杂场景资料少国内中小规模业务规则JRules/ODM商业级 BRMS面向业务人员的词表、规则治理、版本管理授权成本高、部署较重大型企业、业务人员深度参与维护规则选型这事没有标准答案。如果你只是想在一个 Java 服务里快速跑一些规则JRules 大概率不是最优解但如果企业已经有多套业务系统规则需要集中管理、需要审批流、需要和外围系统做规则版本集成那商业 BRMS 的价值就体现出来了。JRules 最擅长的地方在于它把规则当作一种可以与业务人员对话的资产来管理而不是纯技术人员手里的代码。1.3 JRules 里的“项目”到底包含哪些东西JRules 的规则项目和普通 Java 项目不一样它不是一个只放代码的文件夹而是一个完整的规则资产工程。最核心的几个组成概念我列一张表概念一句话理解类比规则项目 Rule Project规则相关所有文件的组织单元Maven 工程里的一个 moduleBOM业务对象模型规则能识别的业务对象项目里的 DTO/VOXOM可执行对象模型真正的 Java 类底层实现类词汇表 Vocabulary把 BOM 属性动词化变成业务人员能读的语言业务术语表规则集 Ruleset一组规则的打包部署单位可部署的 jar执行单元 Execution Unit规则集的入口和边界main 函数Ruleflow控制规则的执行先后工作流定义这些概念之间有一条完整链路规则作者用“词汇表”里的自然语言编写规则规则里的对象来自“BOM”BOM 通过映射关系对应到底层“XOM”的 Java 类多条规则组成“规则集”规则集通过“执行单元”作为入口部署到 Rule Execution Server 上运行。你在新建一个规则项目时实际上就是在搭建这条链路的地基。2. 环境准备装对版本少走一半弯路很多新手在新建规则项目之前往往卡在环境上。JRules 的产品线经历过改名重组网上教程新旧混杂照着老教程操作经常对不上。这一节先把环境相关的关键点理清楚。2.1 从 Rule Studio 到 Rule Designer版本别搞混WebSphere ILOG JRules 这个名字带有很强的时代感。它是 IBM 收购 ILOG 之后的产品线名称后面产品又改名叫 IBM Operational Decision Manager简称 ODM。对应地开发工具在老版本里叫 Rule Studio新版本里改叫 Rule Designer。现在很多老项目文档里还写着 Rule Studio实际上你装的新版本环境里叫 Rule Designer本质是同一个东西。版本差异带来的最大影响是安装包和界面差异。早期 JRules 7.x 时代开发工具通常作为 Eclipse 插件单独安装到了 ODM 8.x 之后Rule Designer 有了独立安装包部署结构也更统一。我给大家的建议是公司用什么版本就严格按照那个版本的官方文档来装别拿新版本教程去套老版本环境。因为老版本里很多菜单路径、选项名称和新版本差异不小照着操作容易怀疑人生。2.2 工作空间与 JDK新手最容易忽略的两件事安装完 Rule Designer 后第一次启动会让你选 workspace。我建议在工作区根目录上多花十秒钟不要放中文路径也不要有空格。比如D:\rule_workspace就比D:\我的文档\rule space稳得多。规则项目里会生成很多与路径相关的配置中文和空格在构建时经常引发奇怪的问题这种坑排查起来非常耗时间。再一个就是 JDK 版本。Rule Designer 是基于 Eclipse 的 IDE启动脚本会用系统默认的 JRE 来跑。如果你只装了 JREEclipse 能启动但 Rule Designer 里很多功能不能用尤其是新建规则项目和 BOM 映射的时候。最简单的解决办法是修改eclipse.ini指定-vm参数到 JDK 的javaw.exe路径。不同版本的 JRules 对 JDK 版本要求不一样7.x 时代常见的是 JDK 1.6/1.7ODM 8.x 之后基本要 JDK 8 起步具体以你的产品版本说明为准。2.3 先在本地把运行环境跑起来再考虑 Team ServerJRules 产品的完整链路里有两个服务端经常被混淆。Rule Team ServerRTS是给业务人员管理规则的系统带 Web 界面和规则审批流程Rule Execution ServerRES是规则集运行的服务端负责执行部署上来的规则。单机开发时你完全可以先不装 RTS但 RES 尽量在本地跑起来因为你要验证规则集能不能正常执行。RES 的部署方式在各个版本里也有差异有的是 war 包扔到 WebSphere 或 Tomcat有的是独立安装服务。本地开发阶段我通常的做法是先用自带的内嵌运行环境或者轻量部署方式把 RES 起起来注册到 Rule Designer 中后面构建完规则集直接部署验证。这样比每次都连开发测试环境的 RES 要快得多也能避免把不相干的调试内容弄到公共环境里。3. 新建规则项目从空项目到跑通一条规则环境准备好之后下面进入正题新建规则项目。这一节是全文最核心的实操部分我会把步骤拆开讲清楚每一步在干什么以及为什么要这么干。3.1 在 Rule Designer 里创建规则项目的完整步骤第一步启动 Rule Designer选择工作区。建议给规则项目单独建一个工作区不要和普通 Java 项目混在一起因为规则项目有自己的一套构建和部署流程混在一起容易产生环境冲突。第二步菜单栏点击 File → New → Other。在弹出的窗口搜索框里输入 Rule Project选择它点击 Next。这一步和 Eclipse 里新建普通 Java 项目很像但搜索关键词一定要输对很多人找不到入口就是因为搜的是 Project 而不是 Rule Project。第三步填写项目名称。比如我这里建一个LoyaltyRules用于演示会员积分和折扣计算。项目名称建议遵循团队命名规范最好带业务含义别起test1、demo2这种名字。项目存放路径默认就好如果你团队用 Git/SVN注意本地路径要和代码仓库的结构对应。第四步选择模板。Rule Designer 会提供一些示例模板新手可以通过模板生成一个最简规则集看看官方默认的项目结构长什么样。如果只是练习结构选 Blank 空白模板也可以。第五步配置 Java 执行环境和执行单元。这一步新手直接用默认就行。执行环境会关联你本机安装的 JDK执行单元默认生成一个后面部署和运行时会用到。第六步点击 Finish。项目创建完成后你会看到 Rule Designer 的项目树里多了一个带规则项目图标的工程。到这一步一个空的规则项目就建好了。3.2 新项目生成后每个目录是干什么的新建完成后Rule Designer 会生成一套目录结构。不同小版本生成的目录名称略有差异但核心的几个组成部分是一样的src或src/main/java放 Java 辅助源码比如自定义的规则执行辅助类、领域对象等。这个目录不是必须的但通常会有。resources放资源文件包括配置文件等。rules或类似的规则目录存放规则文件、决策表、决策树和 Ruleflow。BOM 和词汇表在项目树里有单独的入口节点通常是.bom文件和词汇表文件。这里有一个重点不同文件夹的职责是严格区分的。规则文件如果放进 Java 文件夹构建规则集时可能找不到Java 类如果放到规则目录BOM 映射时也会出问题。很多新手拿到一个别人建好的规则项目第一件事就是到处找哪个文件是规则其实就是把这些目录结构搞清了规则文件一眼就能找到。规则文件本身是文本文件可以直接打开看内容但日常开发应该通过 Rule Designer 的规则编辑器来维护不要手动改文件格式否则很容易把结构改坏。3.3 把 Java 对象变成规则能感知的业务模型规则项目里写规则时你操作的并不是原始 Java 对象而是 BOM业务对象模型。所以要做的第一件事是建立 BOM并把 BOM 和底层 Java 类关联起来。比如我有一个会员实体类package com.demo.model; public class Member { private int age; private String name; private String level; private double discount; public int getAge() { return age; } public void setAge(int age) { this.age age; } // 其他 getter/setter 省略 }在规则项目中我可以把这个类放到src目录下或者打成 jar 引入到项目依赖里。然后右键项目选择 New → Business Object Model创建 BOM 文件。在 BOM 编辑器里通过 Add 操作导入 Java 类选中Member类BOM 会自动提取类的属性和方法生成对应的业务对象。保存后规则编辑器里就能看到 Member 对应的业务对象了。有人可能会问为什么不直接在规则里用 Java 类因为 BOM 层做了一层隔离。Java 类可以随意重构只要 BOM 的词汇不变业务规则文本就不用改。这个解耦的价值在大型项目里非常明显特别是当规则数量成百上千时底层对象结构调整不可能逐条去改规则。3.4 配置词表让规则语言变成业务语言BOM 建好后下一步是配置词汇表。词汇表是 JRules 的灵魂没有它JRules 和普通 Java 规则引擎就没多大区别了。创建词汇表的入口是右键项目 → New → Vocabulary选择刚建好的 BOM。打开词汇表编辑器后你会看到 BOM 里的类、属性和方法都可以配置“词条”。比如把 Member 这个词条配置成中文的“会员”把 getAge() 配置成“的年龄”把比较运算符配置成“低于”。保存之后再写规则时你看到的不是member.getAge() 18这种代码而是“会员的年龄低于 18”这种自然语言表达。这里要注意词汇表不是只给业务人员看的装饰品。在 JRules 中规则文本本身是以词汇表为基础存储的底层语法会被自动映射到规则引擎可执行的 IRL 语言。所以词表配置得好不好直接决定了规则可维护性。我见过太多项目词表配置得乱七八糟规则文本读起来像加密代码最后只能由少数开发人员维护。项目启动时多花点时间把词表规范好后面绝对值得。4. 关键配置与参数规则集、执行单元与本地验证项目能建起来只是第一步真正让规则跑起来还需要理解几个关键配置。这一节讲执行单元、规则集构建和本地验证把项目的运行链路打通。4.1 执行单元决定了规则集的入口和边界执行单元Execution Unit这个概念新手经常搞不明白。简单理解执行单元就是规则集的入口和边界规则的执行从这里开始也在这里结束。一条规则集合了几百条规则但运行时究竟执行哪些规则、从哪条开始都是由执行单元上下文控制的。在新建项目时Rule Designer 一般会自动帮你生成一个默认执行单元。如果项目里有多组互不相关的规则比如一组是会员折扣一组是库存预警那么建议拆成多个执行单元每个执行单元对应一个业务场景。这样部署时按场景独立发布不会出现改一条规则把另一组规则也带着重新部署的情况。执行单元的配置里通常可以设置规则优先级、规则流等。如果规则之间没有严格的先后依赖可以让引擎自行处理如果业务上有明显的先后顺序比如先做准入校验再做授信计算这种情况下要用 Ruleflow 控制规则执行顺序。新建好执行单元后在项目视图里可以看到它下面引用的规则集右键可以查看属性比如输入输出参数的绑定。4.2 构建规则集时的输出配置和调试开关规则写好之后要把它变成可运行、可部署的产物这个动作叫“构建规则集”。项目上右键 → Build Ruleset弹出的对话框里选择你要构建的执行单元确认后 Rule Designer 会开始编译。构建规则集本质上是在做三件事校验规则语法、把规则文本编译成引擎可执行的中间表示、把关联的 BOM、XOM 和规则打包成一个部署单元。构建过程中如果规则有语法错误会直接报错需要回到规则编辑器里修正。构建成功后在输出目录会生成一个规则集部署包不同版本的产物格式不太一样有的场景是一个 jar有的是一个独立文件夹但用途相同——拿到 Rule Execution Server 上去部署。构建规则集有一个开关我强烈建议打开生成调试信息Trace/Rule Tracing。第一次调试规则时打开这个开关可以在规则执行时输出每条规则的命中情况。这功能就像 SQL 的执行计划没有它规则执行结果不对的时候基本只能靠猜。4.3 本地写一条简单 BAL 规则并跑出结果理论知识讲再多不如亲手跑通一条规则。我用一个非常简单的会员折扣场景来演示。假设规则是年龄低于 18 岁的会员不参与本次折扣活动。打开规则编辑器新建一条 Rule选择词汇表后规则文本大致写成这样rule 未成年人不参与折扣 when { 会员的年龄 18; } then { 会员的折扣 0.0; }这里语法是示意写法实际操作时不是手敲这些文字而是在规则编辑器里通过词汇表下拉组件组合出来的但表达的意思是一样的。写完规则后保存静态验证通过后构建规则集然后部署到本地 RES。在 RES 的测试页面里构造一个年龄为 16 的会员对象执行规则集观察输出可以看到该会员的折扣被设置为 0规则正常命中。到这里一个规则项目就完整跑通了从建项目、建 BOM、配词表到写规则、构建规则集、部署运行整条链路都通了。后面你再增加规则、增加场景无非是在这条链路上做扩展。5. 新手最容易踩的坑以及排查思路规则引擎开发里环境问题、版本问题、BOM 映射问题是最容易折磨新手的。这一节我把自己和团队成员踩过的一些典型问题整理出来做成一个速查表希望对大家有帮助。5.1 建项目与部署阶段的高频报错速查报错/现象最可能的原因解决思路新建项目时找不到 Rule Project 入口装的是普通 Eclipse不是 Rule Designer确认使用 Rule Designer/带规则插件的 IDE项目能建但一直有红叉无法构建JDK 版本与 Rule Designer 要求的编译级别不匹配检查项目属性里的 Java Compiler改成对应版本规则里看不到 BOM 对象还没有建 BOM或者 BOM 没有保存找到项目的 BOM 文件确认对象已生成写规则时词汇表选项不全词表没有关联 BOM或属性没有配置词条打开词汇表编辑器补全词条配置构建规则集报 Class not foundXOM 的 Java 类不在项目 classpath 中把 jar 引入项目依赖或把源码放对目录部署后 RES 找不到规则集执行单元没有选对或部署包上传路径不对确认执行单元核查 RES 部署配置规则不命中执行单元上下文对象类型与 BOM 不一致检查输入参数类型与实际传入对象这些问题的共同特点是一开始不好定位报错信息不直观。排查时我习惯按照“项目结构先检查 → BOM/词表再检查 → 构建部署最后检查”的顺序来一次只改一个变量别同时调好几个地方否则出了问题根本不知道是哪个改动引起的。5.2 那些看起来很省事、后续很痛苦的坏习惯最后再分享几个我真实踩过、也看别人踩过的操作习惯。这些习惯短期看省事长期看都是坑。第一个习惯是直接改底层 IRL 代码而不配词表。IRL 是 JRules 的底层规则语言规则编辑器背后就是它。早期版本灵活性不够的时候熟练的开发人员确实会直接编辑 IRL 来实现复杂逻辑。但代价是业务人员完全没法阅读规则的可维护性直线下降。等到规则要移交业务团队评审时全队只能干瞪眼。我的建议是凡是经过词表能表达的逻辑一律用词表写只有词表实在表达不了的场景才考虑在规则里嵌入自定义 Java 方法。第二个习惯是规则命名随意。你可以从rule_001写到rule_200但三个月之后你根本记不住rule_087是干什么的。规则名要尽量表达业务意图比如rule_未成年人拒绝授信_v1就比rule_087可读性强得多。规则项目里的文件、执行单元、规则集命名也是同一个道理。第三个习惯是不做版本说明。规则引擎里的规则变更非常频繁每次更新规则集最好在规则集信息里记录版本号、变更内容、修改人等。否则生产环境出了一个问题想回退到上一个规则版本结果发现根本不知道哪个包是哪一版那才是真正的灾难现场。还有一个习惯是对规则追踪不重视。规则执行结果是错的第一反应是用 System.out 打日志在规则引擎里调试最有效的工具是打开 Trace 功能看每条规则是否被命中、命中顺序如何。Trace 输出就是规则引擎的黑匣子比任何日志都直观。最后多说一句规则引擎能不能在一个项目里成功落地很多时候不取决于引擎本身的性能而取决于一开始怎么组织规则资产。我见过太多项目规则写得飞起但没人维护词表、没人管规则命名、没人记录版本半年之后业务人员根本不敢碰规则。所以这篇连载虽然是在讲怎么新建一个规则项目但真正希望大家带走的是从第一条规则开始就把项目结构、BOM、词表、执行单元这些基础规划好后面的路才会越走越顺。这是我在多个项目里踩坑踩出来的体会也是我认为“新建项目”这件事真正的门槛所在。