具体实施方式
为了使本技术领域的人员更好地理解本说明书一个或多个实施例中的技术方案,下面将结合本说明书一个或多个实施例中的附图,对本说明书一个或多个实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本说明书一部分实施例,而不是全部的实施例。基于本说明书一个或多个实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本公开保护的范围。
规则引擎可以嵌入在业务系统中,当业务系统采集到一个发生的业务事件后,可以将该业务事件传送到规则引擎中,规则引擎中包括用户预先配置的业务规则,可以由规则引擎根据业务规则来判断当前的业务事件匹配的策略,返回给业务系统继续处理。
举例来说,假设用户登录了业务系统要下载一个合同模板,对于该业务系统来说,不同类型的用户对应采用不同的合同模板。例如,如果用户是个人,采用合同模板1;如果用户是企业,采用合同模板2。
那么,业务系统可以将“根据不同的用户,找到对应该用户的合同模板”这件事情交给规则引擎来做,这样可以使得对于模板确定的规则管理更加方便,例如,如果后续要更改模板规则,只要在规则引擎更改规则即可,不用修改业务系统,解耦了业务系统和业务规则。
如下以合同模板的决策为例,来说明本说明书至少一个实施例中的规则引擎是如何进行业务决策的。其中,要实现业务决策,可以包括两个方面,一个方面是注册规则,即用户在规则引擎中去注册要使用的业务规则;另一个方面是根据注册的业务规则,由规则引擎来执行业务决策的流程。
1、在规则引擎注册业务规则
仍以合同模板的例子来说,假设业务系统在最初是所有的用户使用同一个合同模板,后来有了新的关于合同模板的业务规则,规定不同类型的用户对应采用不同的合同模板。例如,如果用户是个人,采用合同模板1;如果用户是企业,采用合同模板2。此时,用户就需要在规则引擎中注册该规则。
图1示例了本说明书至少一个实施例中的规则引擎的结构框架,如图1所示,在进行规则配置时,可以包括如下几个方面的配置:
1.1、注册事件
可以注册使用规则的业务事件,以事件的维度定义后续的多种模型。
例如,对于业务事件A,可以定义一套模型,包括:规则模型、数据计算服务模型、输入模型、输出模型等,即本次配置的这些模型都是与业务事件A的业务决策有关。对于业务事件B,可以定义另一套模型。
当业务系统发生了业务事件A时,规则引擎可以找到对应该业务事件A的一套模型,依据这套模型可以得到业务事件A的决策策略,返回至业务系统。当业务系统发生了业务事件B时,规则引擎可以找到预配置的对应该业务事件B的一套模型,依据这套模型可以得到业务事件B的决策策略。
例如,在注册事件时,可以定义一个事件码12041000,接着可以定义该事件码对应的一系列模型。业务系统在发生事件后调用规则引擎时,可以传入事件码,规则引擎就可以据此找到对应的模型进行业务决策。
1.2、输入模型
输入模型可以用于定义业务系统在请求规则引擎进行业务决策时,需要输入哪些参数,这些参数可以称为决策要素。
例如,该决策要素可以包括上述的事件码,还可以包括其他跟业务有关的业务决策因子。以合同模板的例子来说,由于不同的用户可以采用不同的合同模板,因此,规则引擎在进行合同模板的决策时,需要依据用户标识,可以将用户标识(USER_ID)作为其中一个业务决策因子。在其他的例子中,决策要素包括的业务决策因子可以根据业务实际情况确定。
用户在规则引擎中可以通过配置输入模型,对业务系统向规则引擎输入的参数进行定义,使得规则引擎可以知道根据哪些参数进行业务决策。有些情况下,规则引擎可以根据输入模型中包括的决策要素确定要使用的业务规则。例如,可以根据事件码和用户标识确定本次决策使用的规则。
1.3、规则模型
这里的规则模型可以包括两种:规则表和策略表。该规则模型可以反映业务决策时的具体的决策逻辑。用户可以预先配置规则模型。
其中,规则表用于定义决策要素的取值结果。策略表用于定义规则表中的至少一条规则与策略的匹配关系。通过将规则表中的规则与策略表中的策略进行解耦,使得规则和策略易扩展、更灵活。
如下通过两个表格,示例一下规则表和策略表:
表1规则表
规则 |
变量 |
操作符 |
目标值 |
1 |
产品码 |
= |
010210000100170 |
2 |
事件码 |
= |
12041000 |
表2策略表
规则 |
策略1 |
策略2 |
策略3 |
1 |
√□ |
√□ |
□ |
2 |
√□ |
□ |
□ |
结果 |
A |
B |
C |
优先级 |
1 |
2 |
3 |
如上述的表1和表2所示例,其中,规则表可以是包括多条规则的规则列表,每条规则用于定义决策要素的取值结果,规则表中的每条规则可以包括:规则编号、参与变量、操作符号和目标值。其中,所述的参与变量可以是决策要素,所述的取值结果可以包括多种操作符号限定的取值,可以是参与变量等于某个数值,或者大于某个数值,等。
例如,表1中的规则1中,规则编号是“1”,参与变量是“产品码”,操作符号是“=”,目标值是“010210000100170”。其中的参与变量、操作符号和目标值都可以由用户配置,可以变化。其中的操作符合可以包括大于、小于等基本运算符,还可以是“包括”、“不包括”等关系符号,也可以是用户自定义的符号。
其中,策略表可以是包括多条策略的策略列表,用于定义规则表中的至少一条规则与策略的匹配关系。策略表中的每条策略可以包括:策略关联的规则、是否满足该规则、以及输出结果。
例如,表2中的策略1中,该策略1关联的规则是“规则1和规则2”,“是否满足该规则”是指的当前获取的业务数据是否使得规则成立,比如,如果产品码=010210000100170,且事件码等于12041000,则规则1和规则2都满足;输出结果是A,该策略1的意思是“如果满足规则1和规则2,则输出结果A”。同理,策略2的意思是“如果满足规则1,但是规则2不满足,则输出结果B”。
此外,涉及规则1和规则2的策略有多条时,还可以设置策略的优先级,当多个策略都满足时,可以优先选择优先级高的策略的结果进行输出。
上述的规则表和策略表,可以是由用户在规则引擎的配置界面指定了上述的参与变量、操作符号、目标值等规则元素,并由规则引擎根据用户指定的规则元素封装成规则;或者,由用户在规则引擎的配置界面指定策略关联的规则、规则是否满足、输出结果等策略元素,并由规则引擎据此封装成策略。
规则表和策略表的存储位置可以有多种,例如,可以支持数据库、参数中心、xml文件等多种存储形式。如果规则表和策略表的内容基本不改动,或者说伴随发布才会有需要改动,比较稳定,能够长时间一直使用,则可以用xml形式存储;如果规则表和策略表涉及经常变动,也可以用数据库或参数中心存储。对于参数中心、数据库的存储形式,通常会有后台界面管理,支持实时动态调整。比如,可以通过后台管理界面进行在线规则的调整,以使得规则或策略的调整更加灵活,快速支持业务。而参数中心是利用了参数中心的现有能力、现有数据结果、以及封装的近端缓存等,提高了使用便利性。
其中,规则引擎在实际的决策过程中,可以先判断匹配了哪些规则,再根据匹配的规则去获取关联该规则的策略,进而得到策略的输出结果。并且,将规则表和策略表分开配置,有助于使得策略和规则的匹配关系的设置更加灵活。例如,假设相同的规则可以对应多条策略,如果将规则和策略设置在同一条,那么将导致业务规则的在对应不同策略时的重复编写。
此外,规则表和策略表能够动态编译规则,不全量重新计算。其中,有些规则表和策略表是以脚本实现的,这些脚本需要编译,然后再使用,通常实现手段可以把这些设定在使用前先编译,然后存起来,以后再用就可以读出来,免得每次编译消耗资源。但这些规则也是动态可调整的,动态调整后会先编译,然后同样存起来,支持在线的规则调整。
1.4、输出模型
用户可以通过输出模型定义输出结果的形式,将决策得到的输出结果进行标准化,以将输出结果以标准化形式返回至业务系统。例如,所述标准化形式包括如下任一种:文本、列表数据、JSON、脚本引擎、布尔值、计算引擎。
其中,当输出结果是脚本引擎时,可以是GROOVY(Groovy是一种基于JVM的敏捷开发语言)脚本计算,GROOVY可以自定义结果模型,达到实时计算的效果。当输出结果是计算引擎时,可以是CALC(再计算,即将上次决策的输出结果作为下一次决策时规则的输入)模式的计算引擎,CALC模式可以支持根据数据计算服务计算的结果,动态决策是否需要依赖其他数据计算服务循环计算目标结果,将该计算引擎得到的结果作为另一次业务决策的开始。
例如,规则表中的业务规则的形成,需要定义参与变量,该参与变量可以包括:由业务系统得到的输入变量,还可以是上一次业务决策的输出变量,或者是作为上一次业务决策的输出结果的计算引擎。
1.5、数据计算服务
该数据计算服务可以是在整个决策推理的过程中都会涉及到的计算,包括规则的匹配计算、以及策略的输出结果的计算。例如,在规则的匹配计算中,可以判断一个决策要素的取值是否满足规则中设置的决策要素和目标值之间的关系。又例如,在策略的结果计算中,脚本引擎也属于一种数据计算服务,通过由规则引擎将用户配置的服务规则封装成数据计算服务,由规则引擎进行计算,这些计算服务不需要业务系统自己计算。
通过将决策推理过程中的计算性条件封装成数据计算服务,可以对这些计算进行实时处理,加快处理速度。
此外,用户还可以在配置中心进行其他的配置。
例如,可以选择在决策前做一些前置处理,比如一些校验逻辑,比如,客户状态校验、合约状态校验、账户等级校验等。或者,还可以选择在决策后做一些后置处理,比如一些邮件、短信等沟通动作。可以由工具组件提供上述的前置处理或后置处理中可能用到的工具,包括校验、沟通及其他。用户还可以对业务决策中涉及到的一些业务规则、数据计算服务、策略进行基本定义。
此外,规则引擎还可以通过数据组件,对各种数据源提供的基础能力进行封装,例如对云平台的合约中心、产品工厂、客户平台等基础能力组装,可以向规则计算提供业务数据来源。
通过上述模型的配置,用户已经在规则引擎配置了一个业务事件对应的一套模型,定义了业务系统向规则引擎传入的参数,也定义了规则引擎向业务系统反馈的输出结果的不同形式,并且用户还在规则引擎配置了规则表、策略表、数据服务等模型。当需要变更规则和策略等内容时,用户只需要在规则引擎的配置中心修改一下规则表和策略表即可。
2、规则引擎根据预配置的规则进行业务决策
在完成了业务决策的相关信息的配置后,规则引擎就可以根据用户完成的配置进行后续的业务决策流程。
图2是本说明书至少一个实施例提供的业务决策方法的流程,该流程可以由业务系统发起,当业务系统中发生了一个业务事件时,业务系统可以请求规则引擎对该业务事件进行决策,并将决策策略返回给业务系统。
如图2所示,该方法以合同模板的决策为例,描述该业务决策方法,该方法可以由规则引擎执行,可以包括如下处理。
其中,在描述业务决策的流程前,首先说明在用户配置该合同模板决策事件时,配置的相关信息如下,基于如下配置信息执行决策流程:
决策要素:事件码是CONTRACT_DECIDE,用户标识USER_ID。
规则表可以是如下的表3,策略表可以是如下的表4。
表3合同模板实例的规则表
规则 |
变量 |
操作符 |
目标值(用户类型) |
1 |
USER_ID |
= |
个人 |
2 |
事件码 |
= |
CONTRACT_DECIDE |
3 |
USER_ID |
= |
企业 |
表4合同模板实例的策略表
规则 |
策略1 |
策略2 |
1 |
√□ |
□ |
2 |
√□ |
√□ |
3 |
□ |
√□ |
结果 |
合同模板1 |
合同模板2 |
在步骤200中,规则引擎接收业务系统发送的业务决策请求,所述业务决策请求用于请求规则引擎根据目标业务事件的业务数据确定决策策略。
本步骤中,业务系统中发生了一个业务事件,可以称为目标业务事件。
例如,该目标业务事件可以是,用户要请求生成合同模板。
业务系统调用规则引擎,相当于向业务系统发送业务决策请求,请求规则引擎根据目标业务事件的业务数据确定决策策略。其中,在发送业务决策请求时,可以在请求中携带目标业务事件的决策要素,例如,该决策要素可以包括:事件码和业务决策因子。假设在请求生成合同模板的例子中,事件码可以是CONTRACT_DECIDE,业务决策因子可以是用户标识USER_ID。
所述的目标业务事件的业务数据,可以是根据决策要素获取的数据。例如,决策要素中包括用户标识USER_ID,则规则引擎可以据此去客户平台查找该USER_ID对应的用户类型,是个人还是企业。所述的根据业务数据确定决策策略,可以是根据用户类型确定是采用哪种合同模板。
在步骤202中,规则引擎根据决策要素,加载用户预先配置的规则表,所述规则表用于定义决策要素的取值结果。
本步骤中,规则引擎可以根据决策要素,加载与该决策要素相关联的规则表。例如,规则表中可以包括多条规则,可以从中找出规则中的参与变量包括所述决策要素的规则。以合同模板例子来说,涉及的决策要素包括事件码和用户标识USER_ID,那么,如果一个规则中包括事件码或者USER_ID,就是本次决策中要使用到的规则。
在找到的包含决策要素的规则中,该规则定义了决策要素的取值结果。例如,在上述的表3中,规则1定义了USER_ID的取值结果是个人,规则3中定义了USER_ID的取值结果是企业。
在步骤204中,规则引擎通过数据计算服务获取所述决策要素对应的业务数据,并根据所述业务数据确定所匹配的目标业务规则。
例如,决策要素可以包括用户标识USER_ID,规则引擎可以通过数据计算服务,去客户平台查找USER_ID对应的用户类型,该用户类型即所述的决策要素对应的业务数据。假设业务系统传输的决策要素USER_ID对应的用户是一个个人,则规则引擎获取的对应业务数据是“个人”。规则引擎可以判断出匹配的规则是表3中的规则1,假设规则2也满足,那就是本次决策的业务事件满足的规则包括“规则1+规则2”。业务数据匹配的业务规则可以称为目标业务规则。
其中,该规则引擎接入了业务系统数据源,以使得业务系统的业务数据可以方便快速的获取。例如,以业务系统是网商银行的云平台为例,其数据源可以包括基础产品工厂、合约中心、参数中心、客户平台等一系列基础数据或服务性的平台产品。可以将该多种数据源都接入规则引擎,由规则引擎根据规则匹配计算的需要,由不同的数据源处获取对应的业务数据。可以参见图1所示,用户只管定义自己的输入模型即可,规则引擎可以由源Y1至Y4的多种数据源获取业务数据来进行规则匹配。
此外,规则引擎还可以根据用户配置的服务规则,封装得到数据计算服务。例如,在其他例子中,业务规则的运算符可以是大于、小于等关系符号,还可以是其他自定义的运算符号,在判断业务数据是否满足一个业务规则时,用户可以定义如何进行计算的规则,由规则引擎封装成数据计算服务。或者,在策略的输出结果时,也可以是一个计算性条件,由规则引擎封装成数据计算服务,在规则引擎侧进行实时的计算处理。
在步骤206中,规则引擎根据所述目标业务规则,由用户预先配置的策略表中获取与所述目标业务规则匹配的决策策略。
其中,所述策略表用于定义规则表中的至少一条规则与策略的匹配关系。
本步骤中,规则引擎在确定了目标业务规则,可以在策略表查找与该目标业务规则关联的至少一条策略,并得到与目标业务规则匹配的决策策略。
例如,以表4为例来说,当业务数据使得规则1和规则2同时满足时,对应的输出结果是合同模板1;当业务数据使得规则2和规则3同时满足时,对应的输出结果是合同模板2。
在步骤208中,规则引擎将决策策略的输出结果返回至业务系统。
例如,当用户是个人时,匹配的策略的输出结果是合同模板1,规则引擎可以将合同模板1返回至业务系统。输出结果可以按照预定义的标准化形式进行封装,比如,文本、列表等。
本例子的基于规则引擎的业务决策方法,通过使得规则表、策略表可以分别配置,并设置了能够让用户自定义配置数据计算服务的功能,提高了用户对一次业务决策的相关功能的定制化能力。
图3示例了本说明书至少一个实施例提供的业务决策方法的流程,该流程在决策过程的不同阶段,设置了多级缓存,以提升决策效率。如图3所示,该流程可以包括如下处理:
在步骤300中,规则引擎接收业务系统发送的业务决策请求,所述业务决策请求用于请求规则引擎根据目标业务事件的业务数据确定决策策略。
本步骤中,业务系统中发生了一个业务事件,可以称为目标业务事件。
例如,该目标业务事件可以是,用户要请求生成合同模板。
其中,在发送业务决策请求时,可以在请求中携带目标业务事件的决策要素,例如,该决策要素可以包括:事件码和业务决策因子。假设在请求生成合同模板的例子中,事件码可以是CONTRACT_DECIDE,业务决策因子可以是用户标识USER_ID。
在步骤302中,规则引擎根据决策要素,判断缓存中是否存在与决策要素对应的规则表。
例如,本步骤可以优先查看缓存中是否存在决策要素对应的规则表,如果存在,那就是这些规则表的规则中的变量包括所述决策要素,则继续执行步骤304;否则,可以先检验一下缓存的规则版本是否是最新版本,若是最新版本,则缓存中的这些规则表可以用来继续后续的304。
其中,上述的“版本”可以对应一个业务事件,用户针对一个业务事件在规则引擎中所进行的各种配置的整体,可以针对该整体数据生成一个版本号,包括上述的规则表、策略表、数据计算服务等,其中的部分数据变更时可以更新版本号。每次在对该业务事件进行决策之前,可以预查询一下该业务事件对应的数据版本,然后和缓存中的数据版本进行对比,如果版本一致,则使用缓存中的数据,否则,可以获取最新版本的数据并更新缓存。
如果缓存中不存在缓存的规则表,或者缓存的规则版本不是最新版本,则根据规则表的存储位置(例如,数据库、xml等),去存储位置加载获取最新的规则表。并继续执行步骤304。加载的规则表可以缓存,以备后用。
在步骤304中,规则引擎由规则表中遍历各条规则,解析规则语义。
在步骤306中,规则引擎在规则计算中,判断是否有缓存中是否存在数据计算服务的服务结果。
本步骤是在规则计算的步骤,也优先查看是否缓存了规则计算中的数据计算服务的服务结果。例如,仍以合同模板的例子来说,数据计算服务可以是根据用户标识USER_ID去客户平台查找这个用户的用户类型,假设得到的结果是“个人”。那么,如果每次规则引擎都要重新去客户平台查找用户类型,会导致一定程度的浪费资源,因此可以将“USER_ID”与“用户类型-个人”的对应关系缓存起来,可以称为缓存的服务结果,这样下次规则引擎就可以由缓存中得到该用户的类型是“个人”,不用再去客户平台重新查找,从而节省资源也提高了效率。
若缓存中存储,则使用缓存的所述服务结果,即得到业务数据。继续执行步骤308。
若缓存中未存储,则使用用户注册的数据计算服务进行计算得到服务结果,即获得了决策要素对应的业务数据。继续执行步骤308。
在步骤308中,规则引擎根据业务数据确定所匹配的目标业务规则。
例如,假设业务系统传输的决策要素USER_ID对应的用户是一个个人,则规则引擎获取的对应业务数据是“个人”。规则引擎可以判断出匹配的规则是表3中的规则1,假设规则2也满足,那就是本次决策的业务事件满足的目标业务规则包括“规则1+规则2”。
在步骤310中,规则引擎根据所述目标业务规则,由用户预先配置的策略表中获取与所述目标业务规则匹配的决策策略。
例如,以表4为例来说,当业务数据使得规则1和规则2同时满足时,对应的输出结果是合同模板1;当业务数据使得规则2和规则3同时满足时,对应的输出结果是合同模板2。
在合同模板的例子中,决策策略的输出结果较为简单。在其他的决策场景中,有时输出结果可以是脚本引擎或者计算引擎,需要进行一定的数据计算。此时可以继续执行步骤312。在合同模板的例子中,本步骤可以转至314。
在步骤312中,规则引擎判断是否有缓存的输出结果。
若缓存了结果,则直接进行步骤314,否则,可以缓存决策策略的输出结果,例如,可以使用脚本引擎或者计算引擎执行计算得到的输出结果。
在步骤314中,规则引擎将决策策略的输出结果返回至业务系统。
本例子的基于规则引擎的业务决策方法,通过使得规则表、策略表可以分别配置,并设置了能够让用户自定义配置数据计算服务的功能,提高了用户对一次业务决策的相关功能的定制化能力;并且,通过设置了多级缓存,减少了捞数和计算等耗时,大大提升了决策的效率。
此外,本例子的业务决策方法,提供了一种垂直化的配置解决思路,规则引擎接入了业务的各个数据源,并且从配置、规则、计算、决策四个方面进行了改进,对整套配置决策链路进行包装。其中,在配置上用户可以通过数据组件定义业务模型,在各种数据源提供的业务数据的基础上进行业务属性的封装,使得规则引擎可以理解这些模型,面向业务,用户可以基于这些模型去做配置,不会过于繁琐。例如,融资平台是建立在金融云上的,可以利用金融云现有的能力,增强规则引擎的易用性,用户可以定义合约、产品模型等云资产定义的模型,用户基于这些模型可以在规则引擎的输入参数上直接配置所需的业务参数。在规则、计算和决策上,可以使用多级缓存,以提升服务的效率。
为了实现上述方法,本说明书至少一个实施例还提供了一种基于规则引擎的业务决策装置,如图4所示,该装置可以包括:请求接收模块41、规则处理模块42、策略处理模块43和结果反馈模块44。
请求接收模块41,用于接收业务系统发送的业务决策请求,所述业务决策请求用于请求规则引擎根据目标业务事件的业务数据确定决策策略;
规则处理模块42,用于根据所述业务决策请求中携带的目标业务事件的决策要素,加载用户预先配置的规则表,所述规则表用于定义决策要素的取值结果;通过数据计算服务获取所述决策要素对应的业务数据,并根据所述业务数据确定所匹配的目标业务规则;其中,所述数据计算服务由规则引擎根据用户配置的服务规则封装,所述业务数据来自接入所述规则引擎的业务系统数据源;
策略处理模块43,用于根据所述目标业务规则,由用户预先配置的策略表中获取与所述目标业务规则关联的决策策略,所述策略表用于定义规则表中的至少一条规则与策略的匹配关系;
结果反馈模块44,用于将所述决策策略的输出结果返回至所述业务系统。
在一个例子中,规则处理模块42,还用于根据用户配置的规则元素,封装所述规则表中的规则,所述规则元素包括:参与变量、操作符号和目标值;
所述策略处理模块43,还用于根据用户配置的策略元素,封装所述策略表中的策略,所述策略元素包括:所述策略关联的规则、规则是否满足以及对应的输出结果。
在一个例子中,如图5所示,该装置还可以包括:规则缓存模块45和服务缓存模块46。
规则缓存模块45,用于判断缓存中是否存在与决策要素对应的规则表;若缓存中存储,校验缓存规则表的规则版本是否是最新版本;若缓存中未存储或者缓存的规则版本不是最新版本,由规则表的存储位置获取最新版本的规则表。
服务缓存模块46,用于判断缓存中是否存在目标业务事件对应的数据计算服务的服务结果;若缓存中存储,则使用缓存的所述服务结果;若缓存中未存储,则使用用户注册的数据计算服务进行计算得到服务结果。
上述实施例阐明的装置或模块,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
为了描述的方便,描述以上装置时以功能分为各种模块分别描述。当然,在实施本说明书一个或多个实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现。
上述图中所示流程中的各个步骤,其执行顺序不限制于流程图中的顺序。此外,各个步骤的描述,可以实现为软件、硬件或者其结合的形式,例如,本领域技术人员可以将其实现为软件代码的形式,可以为能够实现所述步骤对应的逻辑功能的计算机可执行指令。当其以软件的方式实现时,所述的可执行指令可以存储在存储器中,并被设备中的处理器执行。
例如,对应于上述方法,本说明书一个或多个实施例同时提供一种基于规则引擎的业务决策设备。该设备可以包括处理器、存储器、以及存储在存储器上并可在处理器上运行的计算机指令,所述处理器通过执行所述指令,用于实现如下步骤:
接收业务系统发送的业务决策请求,所述业务决策请求用于请求规则引擎根据目标业务事件的业务数据确定决策策略;
根据所述业务决策请求中携带的目标业务事件的决策要素,加载用户预先配置的规则表,所述规则表用于定义决策要素的取值结果;
通过数据计算服务获取所述决策要素对应的业务数据,并根据所述业务数据确定所匹配的目标业务规则;其中,所述数据计算服务由规则引擎根据用户配置的服务规则封装,所述业务数据来自接入所述规则引擎的业务系统数据源;
根据所述目标业务规则,由用户预先配置的策略表中获取与所述目标业务规则关联的决策策略,所述策略表用于定义规则表中的至少一条规则与策略的匹配关系;
将所述决策策略的输出结果返回至所述业务系统。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此,本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书一个或多个实施例,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于数据处理设备实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。