[发明专利]一种规则引擎及其建模方法、建模装置及指令处理方法

说明书

本申请公开了一种规则引擎及其建模方法、建模装置及指令处理方法，建模方法包括：逐条分解规则，获得规则要素；根据规则要素确定规则间的依赖关系；根据依赖关系获得规则流。本申请将规则细化成规则要素及规则要素构成的关系式，以此为基础确定不同的规则之间的依赖关系，进而形成粒度很小的规则流，为多条指令的并行处理提供基础，大大提高了业务系统的并行处理能力，时效性大大提升，实现了纳秒量级的处理速度，实现了各类规则的实时检查、实时定价估值、实时清算结算等各种业务处理，业务处理速度的提升使得各种事后处理的过程移到事前或事中处理，实现了全业务流平行实时端到端事务处理。

技术领域

本申请涉及规则管理技术领域，具体涉及一种规则引擎及其建模方法、建模装置及指令处理方法。

背景技术

金融业务处理包含了大量业务规则，从国家宪法、监管部门制订的行业规则、公司制定的业务实施规则等，到日常金融业务中的每一笔业务的处理，都包含了大量规则的定义、执行、相关的数据的管理及其与很多周围系统的集成。

以交易业务处理为例，通常分为前台、中台、后台等各个不同的阶段，交易业务的前台主要包括客户订单管理、合规检查和风险管理等交易前的各项检查、交易策略管理、订单路由和执行管理。交易中台的业务处理主要包括获取成交回报、完善、丰富和标准化成交回报记录中的各项内容，定价和估值、风险管控等。交易后台的业务处理主要包括清算结算、交收管理等。目前前台、中台、后台各个层面的大量规则都用软件方法实现，对中台、后台而言，处理容量大，一致性非常重要，表面上时效性似乎不是关键，但实际上是制约处理过程完整性的非常重要的因素之一。对于前台而言，交易的每一步的处理时效更为关键。目前，金融业务处理系统的并行能力不足，交易的时效性难以得到保障。

另外，目前金融业务中大量规则化处理，对日常业务和运营操作十分重要，然而现在的软件技术系统在开发和升级过程中通常会面临很多难题：

1、需求响应时间长：当前采购科技公司的平台产品，业务逻辑和算法基本集成在代码中，核心能力掌控在科技公司手里，新业务或新需求需要业务人员先和科技公司开发人员普及业务知识、讲透功能需求，甚至很多场合，技术团队为了避免业务人员经常修改需求，会要求提供白纸黑字的需求说明书才开始着手开发流程，这违背了很多金融业务随市场多变的行业规律。

2、难以实现定制化：科技公司产品一般提供标准的、通用的批量产品，从开发成本、提高绩效、实施标准化维护达到其自身运维的便利性出发，科技公司更愿意综合多个用户需求，选择一个折中的落地方案实施，金融行业中的各个机构很难得到最适合自己的规则引擎。

3、费用压力大：商用金融业务规则引擎一般初始引入费用较合理，但后期新业务需求或功能变更，时常引起微小增量功能的完善导致大幅成本，造成持续运营成本压力。因为商用系统产品一般小而全，功能冗余，有时候为了小部分业务必需的差异功能需要购买功能稍有差异的多个系统，大量重复功能被浪费了。

4、版本质量不高：现有的系统平台开发模式下，开发人员虽说要求既懂技术又懂业务，但主要还是在技术领域，一些行业经验不足的开发人员在把业务逻辑融入代码时往往顾此失彼，对所开发业务的人、机、物、法、环境理解不透，版本质量低、返工多；

5、依赖外部采购：金融业务用户通常会与科技公司有长期深度的合作，科技公司自己的治理水平和发展对金融业务用户的稳定运营有极大影响。科技公司人员的流动经常会导致响应时间延长、服务质量下降情况。

综上，由于规则化处理依赖于外部技术开发人员的软件编程来完成，对外部技术开发人员的依赖性很强，随之带来了很多问题。

发明内容

本申请的目的在于提供一种规则引擎及其建模方法、建模装置及指令处理方法，大大提高了业务系统的并行处理能力，时效性大大提升。

本申请提供了一种规则引擎的建模方法，包括：逐条分解规则，获得规则要素；根据规则要素确定规则间的依赖关系；根据依赖关系获得规则流。