CN115328760A - 一种基于注入的规则处理方法 - Google Patents

Abstract

本发明提供一种基于注入的规则处理方法，涉及电信业务技术领域，包括：编写业务过滤接口，定义业务规则校验规范；编写各业务规则的实现类，实现业务过滤接口中的业务规则校验规范；根据调用的各外部能力API规范分别编写服务过滤接口；将所有业务规则的实现类注入应用程序，根据权益组合中包含的多个业务规则对应的实现类形成配置类添加到过滤器中；过滤器遍历执行各业务规则的实现类，通过服务过滤接口连接外部能力API，完成权益组合中业务规则的校验。本发明针对每个业务规则配置独立的实现类，是独立的模块，在权益组合校验时，只需组合该权益组合中包含的业务规则的实现类，配置方便，避免相同业务规则的重复校验，提高校验效率。

Description

一种基于注入的规则处理方法

技术领域

本发明涉及电信业务支撑技术领域，尤其是涉及一种基于注入的规则处理方法。

背景技术

随着权益中心的多向发展，系统内接入自有权益、互联网权益、异业权益等多种权益，同时会开展各种权益的组合打包活动。

一般情况，用户通过权益中心参与某权益的领取兑换时，都涉及对事先制定的该权益的通用规则、个性规则进行校验，满足条件才能对该权益进行订购、领取、使用等操作。

在权益组合打包活动中，目前，由于各种权益规则的校验是相对独立的，使得权益组合打包后对权益规则进行校验时过程十分复杂，且容易重复，校验时间长，效率相对低下。

发明内容

针对上述问题，本发明提供了一种基于注入的规则处理方法，针对每个业务规则配置独立的实现类，注入应用程序中，在权益组合校验时，只需组合该权益组合中包含的业务规则的实现类，避免了相同业务规则的重复校验，提高校验效率。

为实现上述目的，本发明公开了一种基于注入的规则处理方法，包括：

编写业务过滤接口，定义业务规则校验规范；

编写各业务规则的实现类，实现所述业务过滤接口中的所述业务规则校验规范；

根据调用的各外部能力API规范分别编写服务过滤接口；

将所有业务规则的实现类注入应用程序，根据权益组合中包含的多个业务规则对应的所述实现类形成配置类添加到过滤器中；

所述过滤器遍历执行各所述业务规则的实现类，通过所述服务过滤接口连接外部能力API获取用户数据，完成权益组合中业务规则的校验。

作为本发明的进一步改进，所述业务规则校验规范包括：

业务规则校验前、业务规则校验中及业务规则校验后的执行方法。

作为本发明的进一步改进，创建业务规则列表，记录注入的所有实现类对应的业务规则。

作为本发明的进一步改进，所述业务规则的实现类通过spring注入方式配置到应用程序中。

作为本发明的进一步改进，根据权益组合中包含的多个业务规则，在所述业务规则列表中获取各业务规则的所述实现类，添加到所述过滤器中。

作为本发明的进一步改进，所述实现类包括业务规则的校验逻辑，所述业务规则的校验逻辑包括：

依次校验一个或多个校验条件；

若当前校验条件校验不通过，则校验失败，进入业务规则校验后的执行方法；

若当前校验条件检验通过，则校验成功，继续校验下一个校验条件，直至校验失败或检验完成，根据业务规则校验规范，进入业务规则校验后的执行方法。

作为本发明的进一步改进，所述校验后的执行方法，包括：向用户发送结果提示信息、报错信息或数据回滚。

作为本发明的进一步改进，所述过滤器执行所述业务规则的实现类，通过所述服务过滤接口连接外部能力API获取用户数据，包括：

通过所述服务过滤接口获取外部能力API的参数进行解析，与第三方渠道或外围渠道建立连接；

根据校验条件向第三方或外围渠道查询对应的用户数据；

判断所述用户数据是否满足校验条件。

与现有技术相比，本发明的有益效果为：

本发明针对每个业务规则配置独立的实现类，相当于独立的模块，在权益组合校验时，只需组合该权益组合中包含的业务规则，配置方便，也避免了相同业务规则的重复校验，提高校验效率。

本发明在应用程序中创建业务规则列表，在新增业务规则时只需要新增该业务规则的实现类，通过spring注入方式进行配置，并加入业务规则列表中即可，业务规则的下线也只需要在业务规则列表中进行注释即可，不会影响到其他规则，实现了规则的新增注入和下线配置。

附图说明

图1为本发明一种实施例公开的基于注入的规则处理方法流程图；

图2为本发明一种实施例公开的基于注入的规则配置流程图。

图3为本发明一种实施例公开的基于注入的规则校验流程图；

图4为本发明一种实施例公开的编写业务过滤接口示意图；

图5为本发明一种实施例公开的编写业务规则的实现类示意图；

图6为本发明一种实施例公开的编写服务过滤接口示意图；

图7为本发明一种实施例公开的服务过滤接口的功能实现示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

下面结合附图对本发明做进一步的详细描述：

目前，各类业务规则的校验是相对独立的，每个权益对应的业务规则繁多，如：支持领取规则包括：指定消费对象范围、领取总量、领取时间范围、领取周期类型；支持使用规则包括：对权益使用次数限制、使用周期限制、每周期使用次数限制、时间限制类型、固定时段、固定时长、使用方式、叠加使用标志、混合使用标志、抵扣规则描述、额度；支持生失效规则包括：对权益有效期时长、有效期时间单位；支持订购规则包括：订购依赖资费、用户余额、用户状态、用户等级等。权益组合后若仍对各权益的业务规则进行校验，会存在重复校验，使校验效率降低，

如图1所示，本发明提供的一种基于注入的规则处理方法，包括：

S1、如图4所示，编写业务过滤接口，定义业务规则校验规范；

其中，

业务规则校验规范包括：

业务规则校验前、业务规则校验中及业务规则校验后的执行方法。

S2、如图5所示，编写各业务规则的实现类，实现业务过滤接口中的业务规则校验规范；

其中，

实现类包括业务规则的校验逻辑，业务规则的校验逻辑包括：

依次校验一个或多个校验条件；

若当前校验条件校验不通过，则校验失败，进入业务规则校验后的执行方法；

若当前校验条件检验通过，则校验成功，继续校验下一个校验条件，直至校验失败或检验完成，根据业务规则校验规范，进入业务规则校验后的执行方法。

校验后的执行方法包括：向用户发送结果提示信息、报错信息或数据回滚。

进一步的，

业务规则的实现类通过spring注入方式配置到应用程序中。

另外，

创建业务规则列表，记录注入的所有实现类对应的业务规则。

S3、如图6所示，根据调用的各外部能力API规范分别编写服务过滤接口；

其中，

通过服务过滤接口获取外部能力API的参数进行解析，与第三方渠道或外围渠道建立连接。

S4、将所有业务规则的实现类注入应用程序，根据权益组合中包含的多个业务规则对应的实现类形成配置类添加到过滤器中；

其中，

根据权益组合中包含的多个业务规则，在业务规则列表中获取各业务规则的实现类，添加到过滤器中。

S5、过滤器遍历执行各业务规则的实现类，通过服务过滤接口连接外部能力API获取用户数据(如图7所示)，完成权益组合中业务规则的校验。

其中，

通过服务过滤接口获取外部能力API的参数进行解析，与第三方渠道或外围渠道建立连接；

根据校验条件向第三方或外围渠道查询对应的用户数据；

判断用户数据是否满足校验条件。

如图2所示，本发明还公开了规则配置流程，登录运营平台管理后台，电机“规则管理”标签，可以新建规则、查询规则、修改规则；

其中，

新建规则包括：点击“添加”，进入规则管理页面，选择规则类型，输入规则名称，选择有效表示，录入限制内容，提交入库，数据库中通过数据字段表、权益规则限制表、权益规则表保存新建规则，返回结果。

查询规则包括：根据规则属性查询规则信息，数据库通过数据字段表、权益规则限制表、权益规则表查询该规则，返回规则信息。

修改规则包括：查询规则后，根据展示的字段信息进行修改，数据库通过数据字段表、权益规则限制表、权益规则表保存该规则的修改，返回修改结果。

如图3所示，本发明还公开了校验流程，包括：依次校验参数非空(如：手机号、权益批次ID、领取渠道、领取方式、省份编号、流水、用户类型等)、初始化入参信息(包括权益批次信息、权益信息、权益规则信息)、权益批次校验(包括权益批次信息校验、批次派发、领取时间校验)、权益校验(包括权益时间校验)、规则校验(目标号码校验、黑名单校验、积分限制校验、花费限制校验、入网时长限制校验、星级校验、库存数量校验、但yoghurt领取次数校验)；

其中，

权益批次信息校验的重点在于：(1)权益批次ID是否合法；(2)领取渠道是否匹配；(3)领取方式是否正确；(4)开展省份是否一致；(5)批次状态是否为3；

批次派发、领取时间检验的重点在于：(1)派发开始时间<当前时间<派发结束时间；(2)当前时间点是否在领取时间段内；(3)当前时间是否小于下线时间；

库存数量校验包括：

(1)总领取量<总库存量；(2)当天已领取量<当天最大领取量；

单用户领取次数限制包括：

(1)单人已领取次数<单人限制领取次数；(2)单用户(类型：天、周、月)已领取次数<单用户领取库存量。

本发明的优点：

本发明针对每个业务规则配置独立的实现类，相当于独立的模块，在权益组合校验时，只需组合该权益组合中包含的业务规则，配置方便，也避免了相同业务规则的重复校验，提高校验效率。

本发明在应用程序中创建业务规则列表，在新增业务规则时只需要新增该业务规则的实现类，通过spring注入方式进行配置，并加入业务规则列表中即可，业务规则的下线也只需要在业务规则列表中进行注释即可，不会影响到其他规则，实现了规则的新增注入和下线配置。

以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种基于注入的规则处理方法，其特征在于，包括：

编写业务过滤接口，定义业务规则校验规范；

编写各业务规则的实现类，实现所述业务过滤接口中的所述业务规则校验规范；

根据调用的各外部能力API规范分别编写服务过滤接口；

将所有业务规则的实现类注入应用程序，根据权益组合中包含的多个业务规则对应的所述实现类形成配置类添加到过滤器中；

所述过滤器遍历执行各所述业务规则的实现类，通过所述服务过滤接口连接外部能力API获取用户数据，完成权益组合中业务规则的校验。

2.根据权利要求1所述的规则处理方法，其特征在于：所述业务规则校验规范包括：

业务规则校验前、业务规则校验中及业务规则校验后的执行方法。

3.根据权利要求1所述的规则处理方法，其特征在于：创建业务规则列表，记录注入的所有实现类对应的业务规则。

4.根据权利要求1所述的规则处理方法，其特征在于：所述业务规则的实现类通过spring注入方式配置到应用程序中。

5.根据权利要求3所述的规则处理方法，其特征在于：根据权益组合中包含的多个业务规则，在所述业务规则列表中获取各业务规则的所述实现类，添加到所述过滤器中。

6.根据权利要求1所述的规则处理方法，其特征在于：所述实现类包括业务规则的校验逻辑，所述业务规则的校验逻辑包括：

依次校验一个或多个校验条件；

若当前校验条件校验不通过，则校验失败，进入业务规则校验后的执行方法；

若当前校验条件检验通过，则校验成功，继续校验下一个校验条件，直至校验失败或检验完成，根据业务规则校验规范，进入业务规则校验后的执行方法。

7.根据权利要求6所述的规则处理方法，其特征在于：所述校验后的执行方法，包括：向用户发送结果提示信息、报错信息或数据回滚。

8.根据权利要求1所述的规则处理方法，其特征在于：所述过滤器执行所述业务规则的实现类，通过所述服务过滤接口连接外部能力API获取用户数据，包括：

通过所述服务过滤接口获取外部能力API的参数进行解析，与第三方渠道或外围渠道建立连接；

根据校验条件向第三方或外围渠道查询对应的用户数据；

判断所述用户数据是否满足校验条件。

Images