1. 项目概述1.1 为什么2025年还有人写JRules先交代一下背景。WebSphere ILOG JRules老牌商业规则引擎后来被IBM收编改名叫IBM Operational Decision Manager也就是ODM。这套东西在银行、保险、电信这些行业的遗留系统里存量极大尤其在国内很多核心交易系统的风控、定价、核保规则跑在上面一跑就是十几年。你要是刚接手这类项目第一反应大概率是崩溃——商业产品文档要上IBM官网翻社区讨论少得可怜网上搜到的资料全是英文PDF版本还都对不上。我自己当年从零开始摸这个玩意儿光是搭环境就折腾了好几天期间无数次想摔键盘。这篇是连载第三篇前两篇分别讲了规则引擎的基本概念、JRules的体系架构没看过的回头翻一下。这篇聚焦一个最基础也最绕不开的操作在JRules里新建一个规则项目。别小看这一步项目结构建不对、资源库连不上、运行环境没配好后面写规则、调试、部署全是坑。适合谁看刚接触JRules的Java开发、从Drools等开源规则引擎转过来的同学以及那些被派去维护老系统、需要快速上手的“救火队员”。这篇会把我踩过的坑、摸索出来的经验全部写出来按着做能少走很多弯路。1.2 新建规则项目到底在解决什么问题先说个本质问题JRules里说的“规则项目”跟Eclipse里普通的Java项目有什么区别区别大了。普通Java项目你只管写代码编译、打包、运行一套标准流程。但规则项目是跑在JRules的规则引擎上的它需要承载的东西远不止Java代码规则本身用BAL语言写后面细说业务对象模型BOM和技术对象模型XOM之间的映射规则集Ruleset以及规则集打包后的二进制文件规则流Ruleflow——控制规则执行顺序的流程图决策表、决策树这类可视化规则的存储版本管理和部署配置信息关联的测试用例、模拟数据这些内容如果散落在普通Java工程里管理起来就是灾难。JRules通过“规则项目”这个统一载体把规则开发、测试、版本管理、部署打包整个生命周期串起来。新建项目的操作看似简单——不就是File New Project吗——但背后涉及的资源库连接、依赖配置、运行环境准备每一步都有讲究。说白了新建规则项目就是你整个规则应用的第一块地基。地基打歪了后面盖的楼越高越危险。2. 前期准备与环境认知2.1 三种开发模式别搞混JRules的开发工具不是只有一个视图它有三种模式新手最容易在这上面迷失。业务模式Business Mode面向业务人员界面极简只能操作决策表、规则流这类面向业务的可视化元素看不到底层的规则语言和Java代码。这个模式对开发人员没什么用但对业务分析师很友好。技术模式Technical Mode开发人员的主力模式。可以写BAL规则、操作BOM/XOM、配置规则集、打规则包。所有规则相关的技术资产都在这个模式下管理。企业模式Enterprise Mode涉及团队协作、版本控制、与企业存储库关联的开发模式。如果你在团队里开发、需要共享规则资产必须切换到企业模式。刚上手的人容易犯的错是装完JRules打开Rule Designer发现界面上这也没有那也没有急得不行。其实大概率只是没切到正确的模式。在Window Open Perspective里选择对应的视图Rule Team Perspective是业务模式Rule Developer Perspective是技术模式企业模式则是配置了资源库之后自动启用的。当前这篇讲的是单个开发者的规则项目创建流程所以默认使用技术模式。等到后面讲团队协作和版本控制再单独展开企业模式。2.2 资源库规则项目的“大本营”JRules有一个概念叫“资源库”Repository这是很多从开源规则引擎转过来的人不太适应的点。Drools你建个项目就是本地文件系统跟Git关联一下就完事。但JRules的设计哲学是规则资产必须集中存储统一管理才能支持多人协作、版本追溯、权限控制。所以它搞了一个基于数据库的资源库JRBRMSJava Rule Builder Repository Management System默认支持Derby生产环境一般用Oracle或DB2。所有规则项目的元数据、规则定义、规则集配置都存在这个库里。本地开发和测试阶段你需要先启动一个资源库实例然后在Rule Designer里配置数据源连接。我第一次搞的时候就是不知道这个流程直接File New Project填了名字点Finish提示创建成功但列表里根本看不到项目一脸懵。后来才明白新建项目之前必须先确保资源库连接是通的。资源库连接不上项目建了也白建。2.3 开发环境版本匹配血泪教训JRules版本众多7.0、7.1、8.x到了IBM手里又出了ODM 8.5、8.6、8.7、8.10等等。不同版本依赖不同的JDK和Eclipse版本配错了启动都启动不了。我自己遇到过最无语的一次项目用的是JRules 7.1配套的Rule Designer基于Eclipse 3.4JDK必须用1.6结果机器上装了JDK 8启动时报了个莫名其妙的UnsupportedClassVersionError排查了半天才定位到是JDK版本问题。还有一次规则项目里的Java类引用了外部Jar包这些Jar是JDK 8编译的但JRules引擎运行在JDK 6环境里一加载就报NoSuchMethodError追了很久才发现是编译版本冲突。所以新建规则项目之前先把版本矩阵理清楚组件版本要求说明JDK与JRules版本匹配如7.1用JDK 1.68.x可能用JDK 1.7/1.8建议安装多个JDK用环境变量切换Eclipse由Rule Designer自带不要手动升级手动升级Eclipse极易导致插件不兼容资源库默认Derby即可团队生产环境建议Oracle/DB2本地开发不必追求生产级配置应用服务器按需配置WebSphere、Tomcat等本地调试可以先不配用内置执行服务器这里强调一句版本匹配是硬规矩不要挑战不要侥幸。你花一小时升级了一个“看起来挺好”的新版JDK可能换来一整天的环境排错。老老实实按官方兼容矩阵来烦恼少一大半。3. 新建规则项目的完整步骤3.1 启动资源库并准备开发环境先装好Rule Designer这一步踩过坑的都懂我直接给标准操作流程第一启动Rule Designer选择Workspace目录。建议单独建一个目录不要跟其他Java项目的Workspace混在一起规则项目和其他项目的构建路径、依赖关系容易互相干扰。第二配置资源库连接。在Rule Designer中执行以下操作打开Window Preferences找到Rule Projects分类下的Repository连接配置项添加一个新的Repository连接默认使用本地Derby数据库连接URL类似jdbc:derby://localhost:1527/rulemgmt填写用户名和密码默认一般是rtsadmin/rtsadmin如果记不清了装的时候注意看一下安装日志第三测试连接成功。连接失败时先检查Derby服务是否启动。JRules安装目录下有启动脚本start_server.bat或start_server.sh手动启动一次再回Rule Designer里重试。第四启动本地执行服务器。本地调试规则集时需要一个执行环境JRules自带了一个基于Tomcat的执行服务器RESRule Execution Server。确保它能正常启动规则跑起来才有地方。3.2 新建项目向导关键配置项逐字段说明资源库通了开发环境正常下一步就是真正的新建项目。在Rule Designer中执行File New Rule Project弹出新建向导。这里有几个关键配置项一个个说Project name项目名称命名规则跟Java项目类似建议用有业务含义的名字比如PremiumCalcRules、CreditCheckRules。别起test1、newproject这种名字规则项目维护周期长达数年项目名会出现在部署包、资源库目录、日志里取个好名字能省很多事。Project location项目在本地文件系统中的存放路径。默认会在Workspace下生成同名目录。如果你有特殊的目录规划可以自定义但不建议放在含有中文或空格的路径下某些版本在解析路径时会有兼容性问题。Rule project typeJRules的项目类型选择。这个要重点讲它决定了项目的基础能力。项目类型说明适用场景Rule Project基础规则项目可以创建规则、决策表、规则流、规则集大多数规则应用的默认选择Java Project普通Java项目可以引用已有的规则项目需要把规则项目打包发布为普通Java程序的场景实际开发中还有一个常见的组合先用Rule Project建规则资产同时建一个Java Project作为规则应用宿主通过RuleApp API加载并执行规则集。如果你用的是新版ODM项目类型里还会出现Business Rule Project、Decision Service Project之类的细分类型本质上是把之前的规则资产和部署配置进一步区分开了。Use a specific rule runtime version是否指定规则引擎的目标版本。一般选择与当前安装的Rule Designer版本一致即可。这里要注意如果你的规则项目最终要部署到生产环境的JRules服务器上目标运行版本必须和生产环境一致不然部署后运行行为可能会有差异。配置完成点Finish项目就建出来了。3.3 项目创建后的默认结构和使用方式项目建好后Rule Designer左侧的Project Explorer里能看到一堆文件和目录。刚建完时别急着写规则先把目录结构和各自用途搞清楚。做一个简单的“规则项目导航”MyRuleProject/ ├── src/main/java // Java类源码XOM层代码通常放这里 ├── src/main/resources // 资源文件 ├── src/test/java // 测试代码 ├── brms // 规则资产目录重点 │ ├── mypackage // 规则包Rule Package │ │ ├── .brm // 规则集配置文件 │ │ ├── balance.bal // 规则文件BAL语言写的规则 │ │ └── decisiontable.dtable.xml // 决策表文件 ├── itm // 技术模型目录XOM定义、BOM映射关系等 │ ├── model │ └── pom.xml ├── pom.xml └── build.properties这个结构并不绝对不同版本可能略有差异但brms和itm两个核心目录是固定的。brms下存的是规则资产——你写给业务看的规则itm下存的是实现资产——规则和Java之间的桥接层。了解这个结构有实际意义你在写规则时规则文件里引用的业务对象比如Order、Customer、Premium并不是直接从Java类里取的而是通过itm目录下的BOMBusiness Object Model映射过来的。JRules有一个巧妙的抽象业务人员看到的是业务友好的对象模型BOM技术人员维护的是底层Java对象模型XOM两者通过映射配置关联。新建项目的时候这个映射关系是空的所以你得先定义BOM规则里才能引用业务对象。3.4 配置项目构建路径和依赖项目建好不代表万事大吉。很多新手在建完项目后直接开始写第一条规则结果发现规则里引用不了任何Java类或者编译直接报错。原因是漏了关键一步配置项目的构建路径把规则引擎的API和依赖库加进去。在项目上右键 Properties Java Build Path Libraries需要确认以下几类依赖是否齐全JRules引擎的核心库通常位于JRules安装目录的lib文件夹下如jrules-res-execution.jar、jrules-engine.jar等规则项目引用的外部业务库比如你的规则要使用的领域对象、服务类的Jar包应用服务器运行时的依赖如果规则集要部署到WebSphere等服务器可能需要引入对应的J2EE API另外在Rule Project的Properties里还需要检查“Rule Project”相关的设置确认资源库连接、项目依赖关系等配置正确。之所以强调这一步是因为JRules编译规则集时底层会调用Java编译器把BAL规则翻译成Java代码再编译。构建路径不全翻译出来的代码引不到类直接编译失败。4. 规则编写的核心概念与第一个规则4.1 规则集、规则引擎与执行流程项目建好了紧接着就是写第一条规则。但要写出像样的规则先得把几个基本概念搞清楚。规则集Rule Set是JRules中的核心概念之一。它是一组规则的集合这些规则可能在同一个业务域里比如“保费计算规则集”包含正常费率规则、折扣规则、加费规则等等。规则集是部署和执行的最小单位。规则引擎Rule Engine是执行规则集的基础设施。它有一个工作区Working Memory规则执行时引擎从工作区读取事实对象Fact不断匹配规则条件、执行规则动作直到没有可触发的规则为止。这个过程被称为“推理循环”Inference Loop。生活化类比一下把规则引擎想象成一支装修队事实对象就是房子的现状规则集就是装修标准手册。装修队引擎先观察房子匹配条件然后按手册执行操作执行动作房子变了规则动作修改了事实对象再重新观察、再执行直到房子达到所有条款的要求。BAL规则是JRules提供的一种接近自然语言的规则书写语言。看起来像英文句子比如if the order is urgent then increase the shipping cost by 20%;这里的the order is urgent是条件部分increase the shipping cost by 20%是动作部分。BAL的优雅之处在于它屏蔽了Java的语法噪音业务人员也能读懂。但BAL并不是纯文本随意写的它在Rule Designer里有专门的编辑器带语法提示、自动补全编译时还会做语义检查。你写规则时编辑器会自动识别order、shipping cost这些词汇——前提是这些词汇已经在BOM里定义好了。4.2 创建BOM与词汇表规则是面向业务词汇的但底层Java代码不认识“order”和“shipping cost”这些词。这中间的桥梁就是BOM。BOM的本质是一张映射表把Java类、Java方法、Java属性映射成业务友好的词汇和逻辑表达。比如Java类com.example.Order映射成“order”getAmount()方法映射成“amount”isUrgent()方法映射成“urgent”。在JRules的实际操作中BOM有“技术BOM”XOM和“词汇表”Vocabulary两个层次XOMeXecution Object Model真实执行的Java对象模型就是普通的Java类BOMBusiness Object Model面向业务的模型规则里写的业务词汇对应的就是这个词汇表VocabularyBOM中属性、方法、条件、动作所使用的业务术语定义即规则语言中业务词汇的字典新建规则项目后如果要写规则先确认XOM类是否存在然后通过Rule Designer的BOM编辑器把XOM类导入到项目并映射为BOM再定义词汇表为BOM中的元素指定业务词汇——比如方法getOrderAmount()在规则语言中显示为“the order amount”。这套映射配置完成后规则编辑器就认识业务词汇了。坦白说第一次接触这个体系的人会觉得很绕Java写得好好的为什么要多一层BOM和词汇映射原因是规则不是给机器看的一等公民它要给业务人员阅读、审核、维护。业务人员不关心OrderVO.getShippingFee()这种表达他们说的是“加急订单加收20%运费”。BOM和词汇表就是把这句人话翻译成机器语言的“词典”。4.3 手动创建第一条规则理论说了一堆来一条实在的。场景一个订单运费计算需求要求当订单加急时运费上浮20%。第一步创建XOM类。在项目的src/main/java下新建一个Order类package com.example.rules.model; public class Order { private String orderId; private double amount; private double shippingCost; private boolean urgent; public Order(String orderId, double amount, double shippingCost, boolean urgent) { this.orderId orderId; this.amount amount; this.shippingCost shippingCost; this.urgent urgent; } // getters and setters public String getOrderId() { return orderId; } public void setOrderId(String orderId) { this.orderId orderId; } public double getAmount() { return amount; } public void setAmount(double amount) { this.amount amount; } public double getShippingCost() { return shippingCost; } public void setShippingCost(double shippingCost) { this.shippingCost shippingCost; } public boolean isUrgent() { return urgent; } public void setUrgent(boolean urgent) { this.urgent urgent; } }第二步定义BOM映射。在Rule Perspective中执行“Insert Business Object Model”选择从现有Java类导入XOM选中Order类生成对应的BOM。生成后可以修改部分元素的业务名称orderId→订单编号amount→订单金额shippingCost→运费urgent→加急第三步写规则。在brms下新建一个规则包为规则包新建规则集然后为规则集添加规则。编辑器里写if the Order is urgent then set the Order shippingCost to the Order shippingCost plus (the Order shippingCost * 0.2);如果BOM映射正确规则编辑器里the Order后面会自动补全is urgentthen后面自动补全shippingCost相关操作。写完后可以点编辑器上的执行按钮或通过执行服务器模拟运行把创建好的Order实例作为事实传入观察执行结果。4.4 规则集和规则包的工程化理解写第一条规则时容易忽略的一个点是“规则集”和“规则包”的角色分工。规则包Rule Package是规则的组织单元。它承载了一组规则文件可选的数据模型定义BOM可选的决策表、决策树等规则文件规则的变量和全局信息规则集Rule Set则是在规则包基础上的可执行配置。它指定了该规则集包含哪些规则包中的规则规则执行时需要的输入/输出类规则执行的路径Ruleflow和决策表生成二进制规则集文件时的参数打个比方规则包是“规则的文件柜”里面分门别类放着规则规则集是“用哪些规则来处理哪类业务问题的手册”。同一个规则包可以配置出多个规则集应对不同的业务场景这是JRules在工程上比较灵活的地方。我实际建项目时的习惯是每个业务模块建一个规则项目项目下按业务子域划分规则包比如premium.base、premium.discount、premium.risk再为每个对外功能点配置一个规则集比如premium.calculate。这样后期排查问题时定位到具体规则包和规则集非常快。5. 常见问题与排查技巧实录5.1 资源库连接失败项目无法创建这是新建项目阶段出现频率最高的问题没有之一。现象配置资源库连接后点Test Connection提示失败或者新建项目向导走到最后一步报错“Cannot connect to repository”。排查步骤检查Derby进程是否启动。JRules安装目录下执行start_server.bat看控制台是否正常输出启动日志。注意Derby启动到就绪需要一点时间看到Startup successful字样再继续。检查端口是否被占用。Derby默认监听1527端口被占用时换个端口或结束占用进程。检查连接URL是否写对。新版JRules的默认URL末尾可能要加;createtrue参数表示自动创建数据库不同版本略有差异。检查用户名密码。安装时的默认账号和后续修改过的账号容易混建议在安装文档里确认后再填。经验之谈我遇到过一次非常隐蔽的问题——Rule Designer和Derby的JVM位数不一致一个是32位一个是64位数据库连接直接报错。后来统一了JDK位数才解决。Windows下尤其容易碰到这种问题建议开发机统一用64位JDK64位Derby64位Rule Designer。5.2 规则编辑器不识别业务词汇现象规则编辑器里输入if the Order is urgent后urgent没有高亮回车后直接红叉编译报错。原因BOM映射里没有把Order.isUrgent()方法映射到业务词汇“urgent”或者映射的类型不对。解决检查BOM编辑器里是否成功导入了Order类isUrgent()方法是否出现在方法列表里检查词汇表定义中“urgent”是布尔类型还是字符串类型必须与Java方法的返回类型匹配确认规则中使用的业务词汇前缀是否正确JRules里通常用“the”作为变量的冠词比如the Order表示一个Order类型的对象引用如果BOM映射没问题但编辑器还是报错把规则集里的“执行对象模型”刷新一下有时候是编译缓存的问题。5.3 规则集编译通过运行时找不到类这是最让人抓狂的问题规则在Rule Designer里测试正常部署到服务器或者用Java程序调用时报ClassNotFoundException。原因几乎所有这类问题都出在“XOM类没有打进规则集部署包”上。规则集部署时需要同时携带两类字节码规则集本身的二进制文件.jar规则引用的XOM类也就是Order这些Java类的字节码JRules在打包规则集时默认不会把所有引用的Java类都打包进去需要管理员在构建规则集时把XOM依赖加入到规则集Jar中或作为应用的一部分部署上去。很多新手项目在本地测试没问题——因为本地类路径里能找到这些类——但部署到服务器后就炸了。解决在生成规则集项目.jar时检查构建选项“Add the project to the RuleApp”或“Include XOM in RuleApp”等选项确认规则引用的XOM已被包含。如果XOM由其他团队维护则以外部依赖形式发布到目标环境。5.4 规则执行结果与预期不符排除部署和编译问题后最常见的业务逻辑问题是规则触发了但结果不对。举例我原来写过一个折扣规则预期是“订单金额满1000元打9折”实际执行却发现满500元就打了9折。排查之后发现是BOM映射里约定的词汇有歧义业务人员理解的“订单金额”是订单实付金额而Java类里的getAmount()返回的却是商品总额含运费两个概念对不上。排查思路先看规则条件里引用的每个属性确认它在BOM词汇表中到底映射的是哪个Java方法再确认Java方法的返回值是否符合业务预期利用Rule Execution Server的Trace功能打开规则执行追踪查看每次规则触发的条件匹配结果、变量取值变化JRules自带执行追踪功能运行时可以打开能记录每条规则的触发顺序和结果。排查复杂规则问题时这是最有力的工具没有之一。5.5 新手最容易忽视的三个工程习惯最后分享几个新建规则项目阶段就应该建立的工程习惯不然后面维护老项目时会想穿越回去打自己。第一规则命名要有业务含义。规则在运行时出问题日志里会打出规则名。叫rule_001的规则和叫UrgentOrderShippingMarkup的规则出问题时排查效率完全不是一个级别。第二规则集和规则包要分清楚。一个项目里可以有很多规则包但规则集一定要和对外业务功能一一对应。一个规则集对应一个业务场景不要图省事把所有规则都塞进一个规则集。第三版本和变更记录必须维护。JRules的资源库本身有版本能力但很多开发团队根本不使用导致上线后出了问题无法回退。建议从第一天起就养成习惯规则集每次修改后都打一个新版本保留历史版本记录。6. 总结与后续规划走到这里一个新的JRules规则项目已经从无到有搭起来了资源库连接、项目创建、构建路径配置、BOM映射、第一条规则编写、常见问题排查一条线全走通。我个人在实际操作中最深的体会是JRules是一个“概念先行”的系统。它不像Drools那样给你一个相对自由的规则书写环境而是先逼你建立起XOM、BOM、词汇表、规则包、规则集这一整套心智模型。这套模型虽然初学阶段繁琐但一旦理解并习惯它的工程化能力——多人协作、版本管理、业务人员参与规则维护——确实比开源框架成熟得多。下一篇继续聊规则集的具体配置和部署重点讲RuleApp打包、Rule Execution Server发布以及不同部署方式本地RES、远程服务器、嵌入应用的实操区别。如果你正在接触JRules可以先把这篇里的步骤亲手走一遍卡在哪一步基本都能对照常见问题找到答案。规则引擎这个领域理论再多都是虚的真正上手建一个项目、写一条规则、部署一次跑通你对它的理解才算是入了门。