CN111752541A - 一种基于Rete算法的支付路由方法 - Google Patents

Abstract

本发明涉及信息技术领域，提供了一种基于Rete算法的支付路由方法。目的在于解决传统的支付路由方法大多通过硬编码方式编写业务逻辑，当业务逻辑数量到达一定程度后，程序的维护将变得异常困难的问题。主要方案包括步骤1、根据支付路由业务的业务需求抽象包含客户信息、交易信息的支付路由业务模型；步骤2、根据业务模型进行业务Fact对象开发，系统通过自动发现机制判断Fact对象是否存在变更；步骤3：根据业务需要调整规则相关阈值，并进行规则集发布；步骤4：支付路由系统加载最近发布的规则集后，执行规则集，并输出规则执行结果。

Description

一种基于Rete算法的支付路由方法

技术领域

本发明涉及信息技术领域，提供了一种基于Rete算法的支付路由方法。

背景技术

在日常的支付业务处理过程中，受监管、风险、成本等多维度因素影响，支付路由业务规则多变，某些统计类业务规则异常复杂，业务需要经常动态改更业务规则阈值或通过动态组合生成新的业务规则。

传统的硬编码方式无力应对如此复杂的业务场景，IT人员使用硬编码方式也无法快速响应如此复杂的业务需求，稍有不慎将对线上业务带来不可预估的风险。

Rete匹配算法是一种进行大量模式集合和大量对象集合间比较的高效方法，通过这种方法找出所有匹配各个模式的对象。通过商业决策逻辑和应用研发决策的分离，从而可以动态修改或管理业务规则，最大程度地为业务提供了适应性。

发明内容

本发明的目的在于解决传统的支付路由方法大多通过硬编码方式编写业务逻辑，当业务逻辑数量到达一定程度后，程序的维护将变得异常困难的问题。

为解决上述技术问题，本发明采用以下技术方案：

一种基于Rete算法的支付路由方法，其特征在于，包括以下步骤：

步骤1、根据支付路由业务的业务需求抽象包含客户信息、交易信息的支付路由业务模型；

步骤2、根据业务模型进行Fact对象开发，系统通过自动发现机制判断Fact对象是否存在变更；

步骤3：根据业务需要调整规则相关阈值，并进行规则集发布；

步骤4：支付路由系统加载最近发布的规则集后，执行规则集，并输出规则执行结果。

上述技术方案中，步骤1具体包括：

步骤1.1：根据行内现有业务及未来可能发生的业务生成包含客户信息、交易信息、计算因子的业务模型；

步骤1.2：输出包括客户信息，交易信息、计算因子的业务模型。

示例业务需求：

客户进行消费时，使用可以支持该笔交易金额的支付通道且费率最低的支付通道进行交易；

客户进行转账时，使用可以支持该笔交易金额的支付通道且到账效率最高的支付通道进行交易。

根据以上业务需求可创建以下业务模型：

交易信息	计算因子
		交易金额	支付通道交易费率
交易类型	支付通道到账时效

上述技术方案中，步骤2具体包括：

步骤2.1：开发注解@Model，用于描述Fact对象；

开发注解@Field，用于描述对象属性；

开发注解@Function，用于描述对象方法；

步骤2.2：开发ModelAnnotationAnalyzing用于解析@Model注解，获取对象信息；开发FieldAnnotationAnalyzing用于解析@Field注解，获取对象属性信息；开发FunctionAnnoationAnalyzing用于解析@Function注解，获取对象方法信息；

步骤2.3：开发BusinessModel接口，用于定义所有Fact对象父类；

步骤2.4：根据步骤1中的业务模型进行Fact对象开发，同时实现BussinessModel接口，并使用步骤2.1中的开发的注解对Fact对象分别进行定义；

步骤2.4：程序启动时，加载BussinessModel接口实现类；

步骤2.5：使用步骤2.2中开发的注解解析类，对BussinessModel的所有实现类进行解析，获取通过@Model，@Field，@Function定义的Fact对象数据，分别计算hash值；

步骤2.6：获取Redis缓存中的最新Fact对象数据，若不存在，则向Redis中插入步骤2.5中获取的Fact对象数据；若存在，则计算其hash值，并与步骤2.5中的的hash值进行比较，若hash值相等，则说明Fact对象未发生变更；若hash值不一致，则向Redis插入已更新的Fact对象数据；

步骤2.7：若步骤2.6数据发生变更，则同步插入数据至数据库。

上述技术方案中，步骤3具体包括：

步骤3.1：规则管理台从Redis缓存中加载步骤2中Fact对象数据；

步骤3.2：根据业务需求在规则管理台中配置规则集/决策表/决策树，并修改相关阈值；

步骤3.3：配置完成后，进行规则集/决策表/决策树发布，生成DRL文件，并保存DRL数据至Redis缓存及数据库。

示例配置：

规则A：

若当前交易信息的交易类型为消费

则：

设置当前交易的支付通道为交易费率最低的支付通道.

规则B：

若当前交易信息的交易类型为转账

则：

设置当前交易的支付通道为到账时效最高的支付通道.

上述技术方案中，步骤4具体包括：

步骤4.1：程序收到客户发起的支付指令后，从Redis缓存中加载步骤3产生的最新DRL数据；

步骤4.2：通过Drools执行引擎将当前交易数据与DRL数据进行匹配；

步骤4.3：保存Drools规则引擎匹配结果，并选择匹配结果对应的支付通道进行支付交易。

因为本发明采用上述技术方案，所以具备以下有益效果：

一、传统的支付路由方法大多通过硬编码方式编写业务逻辑，当业务逻辑数量到达一定程度后，程序的维护将变得异常困难，如业务逻辑要求将多个简单逻辑自由组合成复杂逻辑或者需要临时调整业务逻辑间的优先级等等，这些都将给业务和技术带来巨大的挑战。通过规则引擎分离商业逻辑和研发逻辑，为业务与研发都带来了便利。

二、部分使用规则引擎的支付路由产品无法实现业务模型版本的自动发现，通过手工方式对业务模型版本进行管理，操作复杂，研发风险较高。本技术方案通过自动加载机制自动对业务模型进行加载，提升了研发效率，降低了研发风险。

附图说明

图1为本发明框架图；

图2为本发明业务模型示意图；

图3为步骤2示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明，即所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，术语“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本发明提供了一种基于Rete算法的支付路由方法，其特征在于，包括以下步骤：

一种基于Rete算法的支付路由方法，包括以下步骤：

步骤1、根据支付路由业务的业务需求抽象包含客户信息、交易信息的支付路由业务模型；

步骤2、根据业务模型进行业务Fact对象开发，系统通过自动发现机制判断Fact对象是否存在变更；

步骤3：根据业务需要调整规则相关阈值，并进行规则集发布；

步骤4：支付路由系统加载最近发布的规则集后，执行规则集，并输出规则执行结果。

上述技术方案中，步骤1具体包括：

步骤1.1：根据行内现有业务及未来可能发生的业务进行业务生成包含客户信息和交易信息的业务模型；

步骤1.2：输出包括用户信息，交易信息的业务模型。

上述技术方案中，步骤2具体包括：

步骤2.1：开发注解@Model，用于描述Fact对象；

开发注解@Field，用于描述对象属性；

开发注解@Function，用于描述对象方法；

步骤2.2：开发ModelAnnotationAnalyzing用于解析@Model注解，获取对象信息；开发FieldAnnotationAnalyzing用于解析@Field注解，获取对象属性信息；开发FunctionAnnoationAnalyzing用于解析@Function注解，获取对象方法信息；

步骤2.3：开发BusinessModel接口，用于定义所有Fact对象父类；

步骤2.4：根据步骤1中的业务模型进行Fact对象开发，同时实现BussinessModel接口，并使用步骤2.1中的开发的注解对Fact对象分别进行定义；

步骤2.4：程序启动时，加载BussinessModel接口实现类；

步骤2.5：使用步骤2.2中开发的注解解析类，对Buss inessModel的所有实现类进行解析，获取通过@Model，@Field，@Function定义的Fact对象数据，分别计算hash值；

步骤2.6：获取Redis缓存中的最新Fact对象数据，若不存在，则向Redis中插入步骤2.5中获取的Fact对象数据；若存在，则计算其hash值，并与步骤2.5中的的hash值进行比较，若hash值相等，则说明Fact对象未发生变更；若hash值不一致，则向Redis插入已更新的Fact对象数据；

步骤2.7：若步骤2.6数据发生变更，则同步插入数据至数据库。

上述技术方案中，步骤3具体包括：

步骤3.1：程序加载步骤3中Fact对象数据；

步骤3.2：根据业务需求配置规则集/决策表/决策树，管理页面实现了Drools所提供的各类连接符，如与、或、非、大小、小于、等于、包含、不包含、匹配、不匹配等。

步骤3.3：配置完成后，进行规则集/决策表/决策树发布，生成DRL文件(Drool规则文件)，并保存DRL数据至Redis缓存及数据库。

上述技术方案中，步骤4具体包括：

步骤4.1：程序从Redis中加载最新版本DRL数据；

步骤4.2：通过Drools执行引擎将当前交易数据与DRL数据进行匹配；

步骤4.3：保存Drools规则引擎匹配结果，并返回规则引擎执行结果给调用方。

Claims (5)

1.一种基于Rete算法的支付路由方法，其特征在于，包括以下步骤：

步骤1、根据支付路由业务的业务需求抽象包含客户信息、交易信息的支付路由业务模型；

步骤2、根据业务模型进行Fact对象开发，系统通过自动发现机制判断Fact对象是否存在变更；

步骤3：根据业务需要调整规则相关阈值，并进行规则集发布；

步骤4：支付路由系统加载最近发布的规则集后，执行规则集，并输出规则执行结果。

2.根据权利要求1所述的一种基于Rete算法的支付路由方法，其特征在于，步骤1具体包括：

步骤1.1：根据行内现有业务及未来可能发生的业务生成包含客户信息、交易信息、计算因子的业务模型；

步骤1.2：输出包括客户信息，交易信息、计算因子的业务模型。

3.根据权利要求1所述的一种基于Rete算法的支付路由方法，其特征在于，步骤2具体包括：

步骤2.1：开发注解@Model，用于描述Fact对象；

开发注解@Field，用于描述对象属性；

开发注解@Function，用于描述对象方法；

步骤2.2：开发ModelAnnotationAnalyzing用于解析@Model注解，获取对象信息；开发FieldAnnotationAnalyzing用于解析@Field注解，获取对象属性信息；开发FunctionAnnoationAnalyzing用于解析@Function注解，获取对象方法信息；

步骤2.3：开发BusinessModel接口，用于定义所有Fact对象父类；

步骤2.4：根据步骤1中的业务模型进行Fact对象开发，同时实现BussinessModel接口，并使用步骤2.1中的开发的注解对Fact对象分别进行定义；

步骤2.4：程序启动时，加载BussinessModel接口实现类；

步骤2.5：使用步骤2.2中开发的注解解析类，对BussinessModel的所有实现类进行解析，获取通过@Model，@Field，@Function定义的Fact对象数据，分别计算hash值；

步骤2.6：获取Redis缓存中的最新Fact对象数据，若不存在，则向Redis中插入步骤2.5中获取的Fact对象数据；若存在，则计算其hash值，并与步骤2.5中的的hash值进行比较，若hash值相等，则说明Fact对象未发生变更；若hash值不一致，则向Redis插入已更新的Fact对象数据；

步骤2.7：若步骤2.6数据发生变更，则同步插入数据至数据库。

4.根据权利要求1所述的一种基于Rete算法的支付路由方法，其特征在于，步骤3具体包括：

步骤3.1：规则管理台从Redis缓存中加载步骤2中Fact对象数据；

步骤3.2：根据业务需求在规则管理台中配置规则集/决策表/决策树，并修改相关阈值；

步骤3.3：配置完成后，进行规则集/决策表/决策树发布，生成DRL文件，并保存DRL数据至Redis缓存及数据库。

5.根据权利要求1所述的一种基于Rete算法的支付路由方法，其特征在于，步骤4具体包括：

步骤4.1：程序收到客户发起的支付指令后，从Redis缓存中加载步骤3产生的最新DRL数据；

步骤4.2：通过Drools执行引擎将当前交易数据与DRL数据进行匹配；

步骤4.3：保存Drools规则引擎匹配结果，并选择匹配结果对应的支付通道进行支付交易。

Images