业务资格认证方法、装置、系统、计算机设备和存储介质与流程

本申请涉及数据处理领域，尤其涉及一种业务资格认证方法、装置、系统、计算机设备和存储介质。

背景技术：

广义的业务，指的是由目的、动机、动作和共同性构成，具有完整的结构系统，具体在互联网领域，业务可以是一次促销、一次抽奖等。

目前大部分业务开发主要是单独开发，每个业务需要一套开发流程，而且需要较为专业的业务开发人员来进行。而专业人员开发业务时，没有统一的交互标准，前后端联调复杂，导致业务的开发时间长，上线周期长，成本高。

技术实现要素：

为了解决上述技术问题或者至少部分地解决上述技术问题，本申请提供了一种业务资格认证方法、装置、系统、计算机设备和存储介质。

本申请实施例提供了一种业务资格认证方法，包括：接收用户端发送的资格认证请求，所述资格认证请求包括待认证资格的信息，所述待认证资格信息包括全局规则和等级规则；

根据所述待认证资格的信息，生成待认证表达式，所述待认证表达式包括全局规则表达式和等级规则表达式；

在待选业务数据库中，获取满足所述全局规则表达式的所有待选业务；

在所述所有待选业务中，获取满足所述等级规则表达式的待选业务作为目标业务；

若所述目标业务存在，则确认所述资格认证请求通过资格认证。

本申请实施例提供了一种业务资格认证装置，应用于服务器，所述装置包括：

图形化界面单元，用于接收用户端发送的资格认证请求，所述资格认证请求包括待认证资格的信息，所述待认证资格信息包括全局规则和等级规则；

表达式生成单元，用于根据所述待认证资格的信息，生成所述待认证表达式，所述待认证表达式包括全局规则表达式和等级规则表达式；

业务筛选单元，用于在待选业务数据库中，获取满足所述全局规则表达式的所有待选业务；

所述业务筛选单元还用于在所述所有待选业务中，获取满足所述等级规则表达式的待选业务作为目标业务；

认证单元，用于若所述目标业务存在，则确认所述资格认证请求通过资格认证。

本申请实施例提供给了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述方法的步骤。

本申请实施例提供给了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述方法的步骤。

本申请实施例提供了一种业务资格认证系统，所述系统包括：业务配置平台，用于提供图像化界面，所述图形化界面用于接收资格认证请求，所述业务配置平台还用于将所述资格认证请求发送至资格认证平台；

所述资格认证平台，用于执行上述任一项所述的业务资格认证方法；

业务发放平台，用于发放通过资格认证的所述资格认证请求对应的业务；

外部服务平台，用于给所述业务资格认证系统提供资源支持。

上述业务资格认证方法、装置、系统、计算机设备和存储介质，所述方法包括：接收用户端发送的资格认证请求，所述资格认证请求包括待认证资格的信息，所述待认证资格信息包括全局规则和等级规则；根据所述待认证资格的信息，生成所述待认证表达式，所述待认证表达式包括全局规则表达式和等级规则表达式；在待选业务数据库中，获取满足所述全局规则表达式的所有待选业务；在所述所有待选业务中，获取满足所述等级规则表达式的待选业务作为目标业务；若所述目标业务存在，则确认所述资格认证请求通过资格认证。本申请实施例中，接收到用户的资格认证请求后，会根据待认证资格的信息，生成待认证表达式，并根据认证表达式，确认是否有满足认证表达式的目标业务的存在，如果存在目标业务，则确认资格认证请求通过资格认证。本申请上述方法中，会根据用户的资格认证请求自动生成待认证表达式，通过对业务的验证，来确认资格认证请求是否通过认证，即对业务进行验证，使得业务开发有统一的标准，可以减少业务的开发时长，提高业务开发的效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例中业务资格认证方法的应用环境图；

图2为本申请实施例中业务资格认证方法的流程示意图；

图3为本申请实施例的图形化界面的示意图；

图4为本申请实施例的图形化界面的示意；

图5为本申请实施例的业务资格认证的示意图；

图6为本申请实施例的业务资格认证装置的示意图；

图7为本申请实施例的业务资格认证方法的流程图；

图8为本申请实施例中计算机设备的内部结构图；

图9为本申请实施例中资格认证系统的示意图。

具体实施方式

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

图1为一个实施例中业务资格认证方法的应用环境图。参照图1，该业务资格认证方法应用于业务资格认证系统。该业务资格认证系统包括终端110和服务器120。终端110和服务器120通过网络连接。终端110具体可以是台式终端或移动终端，移动终端具体可以手机、平板电脑、笔记本电脑等中的至少一种。服务器120可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

如图2所示，在一个实施例中，提供了一种业务资格认证方法。本实施例主要以该方法应用于上述图1中的服务器120来举例说明。参照图2，该业务资格认证方法具体包括：

步骤210，接收用户端发送的资格认证请求，所述资格认证请求包括待认证资格的信息，所述待认证资格信息包括全局规则和等级规则。

本申请实施例中，用户端发送的资格认证请求指的是用户端创建业务的请求，而待认证资格信息包括全局规则和等级规则指的是用户端对所创建业务的需求。

用户端想要创建业务，并对此业务作出各种需求，这些需求限定的业务是否具有可行性，是否具有边界，是否为系统可以提供或是系统资源可以支持的，就需要对此进行资格认证。资格认证请求通过，说明该业务是可行的，或是具有边界的，或是系统资源可以支持的，或是该业务满足其他需求，在此不再赘述。

系统对外暴露通用的接口供用户端调用。接口字段含事件(待认证资格的信息)、业务标识(可选)、唯一用户标识等公共信息。

任意有权限的用户端发起资格认证请求，并按接口需求传入公共参数，服务器以获取到待认证资格的信息。可以理解地，当用户端发送资格认证请求之前，还需进行权限认证，在用户端有权限的情况下，执行步骤210。

本申请实施例中，步骤210中，用户端发送的资格认证请求，可以是通过图形化界面发送的。图3所示为本申请实施例的图形化界面的示意图，如图3所示，图形化界面上可以包括多个页面，如图3中1、配置活动基本信息；2、配置虚拟资源；3、配置活动规则；4、配置活动资源。配置活动基本信息可以是活动名称、活动开始时间等；配置虚拟资源可以是设置礼品、礼品数量、奖励积分、红包等；配置活动规则页面上，可以有多种形式的规则供用户选择，用户可以根据需求选择全局规则和等级规则。

图3所示的实施例中，全局规则和等级规则是系统已经定义好的，供用户选择，在本申请其他实施例中，各种规则可以是用户根据多种关键词自行建立的。

如图4所示，系统提供的关键词可以是：注册时间、注册渠道、邀请注册数量等，用户选择的规则可以是：注册时间早于2020年1月31日，注册渠道是手机app注册，邀请注册数量大于10。

配置活动资源，是对具体活动的资源配置，可以是配置礼品的总数，奖励积分的总数，每个用户最多奖励的积分数等。

本申请实施例中，通过图形化界面的配置方式，既能提高运营人员的参与度，可以让业务的开发更加独立、方便、快捷。

步骤220，根据待认证资格的信息，生成待认证表达式，所述待认证表达式包括全局规则表达式和等级规则表达式。

服务器在获取到待认证资格的信息后，通过表达式引擎生成待认证表达式，该表达式引擎包括aviator、fastexpressionlanguage、ikexpression等。

步骤230，在待选业务数据库中，获取满足所述全局规则表达式的所有待选业务。

待选业务数据库中存储所有有效业务配置信息以及订阅所有有效业务策略的增删改等变更信息，当业务策略有变更时，可通过rpc或mq或zookeeper等中间服务接收变更通知，使得待选业务数据库中保存的待选业务为最新数据。

步骤240，在所述所有待选业务中，获取满足所述等级规则表达式的待选业务作为目标业务。

步骤250，若所述目标业务存在，则确认所述资格认证请求通过资格认证。

本申请实施例中，接收到用户的资格认证请求后，会根据待认证资格的信息，生成待认证表达式，并根据认证表达式，确认是否有满足认证表达式的目标业务的存在，如果存在目标业务，则确认资格认证请求通过资格认证。本申请上述方法中，会根据用户的资格认证请求自动生成待认证表达式，通过对业务的验证，来确认资格认证请求是否通过认证，即对业务进行验证，使得业务开发有统一的标准，可以减少业务的开发时长，提高业务开发的效率。

本申请实施例中，步骤220中，所述根据待认证资格的信息，生成待认证表达式，包括：

根据所述待认证资格的信息，将将所述待认证资格分割为多个待认证子资格；

获取每一个所述待认证子资格对应的规则组，所述每一个待认证子资格对应一个规则组，一个规则组包括至少一个全局规则和至少一个等级规则；

生成所述全局规则对应的全局规则表达式；

生成所述等级规则对应的等级规则表达式；

根据所述全局规则表达式和等级规则表达式，生成所述待认证表达式。

对于待认证资格的分割，可以根据待认证资格的信息来进行，待认证资格的信息包括全局规则和等级规则，可以将同一个全局规则对应的待认证资格划分为一个子资格。

待认证资格的信息包括的全局规则和等级规则可以体现为资格的基本属性，因此待认证资格的分割，可以根据基本属性来进行，资本的基本属性包括但不限于：资格编码、资格名称、资格状态、资格优先级、资格分类等。基本属性可以是全局规则和等级规则的体现，例如资格编码可以对应为一个全局规则：资格编码大于等于a，或等级规则：资格编码大于等于a，资格编码小于等于b，资格编码小于a且大于b。

具体来说，资格可以如表1所示：

表1资格示例

上述每一项资格可以体现出一项或多项资格的基本属性，例如注册资格可以体现出资格编码和资格名称；投资资格可以体现出资格状态、资格优先级等；邀请资格可以体现出资格状态、资格优先级及资格分类等，在此不再赘述。

对于表1所示的资格作为待认证资格，分割可以按照第一列所示的资格进行，或可以按照体现出的资格的基本属性来分割，例如可以体现出资格优先级的资格分为一个待认证子资格。或可以根据等级规则来分割，例如待认证资格中包括等级规则1、等级规则2和等级规则3，按照3个等级规则把待认证资格分割为3个待认证子资格。

对待认证资格的信息进行分割可以有多种方法，其目的主要是为了后续较为便利的生成待认证表达式，其他具体分割方式在此不再赘述。

本申请实施例中，若所述规则组包括至少两个全局规则，则所述生成全局规则对应的全局规则表达式，包括：

生成所述规则组中每一个全局规则对应的参考全局规则表达式；

将多个所述参考全局规则表达式按照逻辑与的关系，生成所述全局规则对应的全局规则表达式。

本申请实施例中，全局规则是指业务必须满足的规则。一个业务可以同时满足多个全局规则，所以多个全局规则之间是逻辑与的关系，例如全局规则a、b、c，业务必须即满足全局规则a，又满足全局规则b，还满足全局规则的c。如果一个全局规则是：注册时间大约等于365天，那么满足该全局规则的业务中，注册时间必须大于等于365天。

本申请实施例中，根据所述全局规则表达式和等级规则表达式，生成所述待认证表达式，包括：

全局规则表达式与等级规则表达式，按照逻辑与的关系，生成所述待认证表达式。

由于全局规则是对应的待认证资格必须满足的规则，所以多个全局规则之间是逻辑与的关系，即必须满足每一个全局规则。例如一个全局规则包括：全局规则1：注册时间在2020年1月1日之前；全局规则2：登录次数大于10次；全局规则3：分享次数大于10次；对应的参考全局规则表达式分别为：expression1、expression2、expression3。

该全局规则对应的全局规则表达式为：全局规则1&全局规则2&全局规则3，或是写作：$expression1&&expression2&&expression3，其中“$”用来在数据库中指示上述为一个表达式，在本申请下述实施例中，为了简洁，若已明确指出表达式时，不再以“$”标识表达式。对于不同的操作系统、数据处理系统或不同的架构，表达式的形式可以不同，用来指示表达式的符号也不同，上述表达式只是示例，还可以有其他多种方式，在此不再赘述。

本申请实施例中，所述生成等级规则对应的等级规则表达式，包括：

生成所述规则组中每一个等级规则对应的参考等级规则表达式；

获取每一个等级规则对应的优先级；

获取所述规则组中的多个所述参考等级规则之间的逻辑关系；

根据所述优先级及多个所述参考等级规则表达式之间的逻辑关系，生成所述等级规则对应的等级规则表达式，所述逻辑关系包括逻辑与和逻辑或。

本申请实施例中，等级规则指的是业务选择性满足的规则，业务可以满足哪些等级规则、可以不满足哪些等级规则，即等级规则表达式中采用“逻辑与”还是“逻辑或”，可以是用户通过图形化界面设定的，或可以是系统通过图形化界面提供给用户选择的。

用户可以通过图形化界面来选择等级规则，并且定义等级规则之间的逻辑关系。简单说，如果业务需要同时满足等级规则1和等级规则2，则两个等级规则之间是“逻辑与”，如果业务只需要满足等级规则1和等级规则2中的任一个，则两个等级规则之间是“逻辑或”。

例如等级规则1：注册时间大于十天；等级规则2：注册时间小于等于十天；等级规则3：分享次数大于三次；等级规则4：分享次数小于等于三次。其中，等级规则1和等级规则2之间是互斥的，所以关系只能是逻辑或；等级规则3和等级规则4之间也是互斥的，所以关系只能是逻辑或；等级规则1与等级规则3、等级规则4之间可以是逻辑与的关系，也可以是逻辑或的关系，视用户的需求或实际情况进行设定；同理，等级规则1与等级规则3、等级规则4之间可以是逻辑与的关系，也可以是逻辑或的关系。

等级规则之间也是有优先级的，资格认证时会从优先级高的等级规则先验证，直到优先级最低的等级规则。优先级高的等级规则的认证不通过，就不需要再认证优先级低的等级规则。本申请实施例中，等级规则的优先级可以是用户通过图形化界面设置的，或可以是系统通过图形化界面提供给用户选择的。

由于根据等级规则表达式筛选业务是从优先级高的等级规则到优先级低的等级规则依次验证的，且上一优先级等级规则验证不通过，就不需要在验证下一优先级的等级规则了，因此合理设置等级规则的优先级可以降低业务筛选需要处理的数据量，包括，将只需要筛选数字的等级规则的优先级设置为最高，或将需要处理的数据量最小的等级规则设置为最高。

例如一个等级规则表达式为expression1&&expression2，该等级规则表达式中的两个等级规则是逻辑或的关系，即业务只需要在满足expression1和expression2中的一个。一个等级规则表达式是expression3||expression4，该表达式中的两个等级规则是逻辑与的关系，即业务需要同时满足expression4和expression4。

系统可以根据用户的选择来生成对应的等级规则表达式，系统也可以根据预设的规则，来校验用户的选择是否正确。例如用户设定两个等级规则，等级规则1：注册时间大于等于365天；等级规则2：注册时间小于300天；如果用户选择的逻辑关系是“逻辑与”，系统根据预设规则判断，是没有业务可以同时满足这两个等级规则，因此系统校验不通过，会发出告警，提示用户更改等级规则或更改等级规则之间的逻辑关系。

等级规则之间的逻辑关系和等级规则之间的优先级，可以通过等级规则表达式体现。等级规则表达式中，等级标识指示的等级规则的优先级高于无等级标识指示的等级规则，等级标识可以是特定符号，如括号。

等级规则表达式中，如果有“括号”，那么通常有“括号”的优先级更高。一个典型的等级规则表达式可以是：

expression1&&(expression2&&expression3)。

由于括号的存在，所以(expression2&&expression3)的优先级是高于expression1的优先级的；expression2和expression3的优先级相同。上述等级规则表达式中，先将expression2和expression3做逻辑与，然后将逻辑与的结果与expression1做逻辑与。

本申请实施例中，根据所述全局规则表达式和等级规则表达式，生成所述待认证表达式，包括：

全局规则表达式与等级规则表达式，按照逻辑与的关系，生成所述待认证表达式。

由于全局规则表达式是业务必须满足的全局规则对应的表达式，所以全局规则表达式与等级规则表达式之间的关系是逻辑与。

本申请实施例中，所述在所述所有待选业务中，获取满足所述等级规则表达式的待选业务作为目标业务，包括：

获取所述等级规则表达式中的各个所述等级规则的优先级；

根据所述等级规则表达式中各个所述等级规则的优先级顺序，按照优先级从高至低依次验证所述待选业务是否满足所述等级规则表达式；

其中，所述获取所述等级规则表达式中各个所述等级规则的优先级，包括：

获取所述等级规则表达式中的等级标识，所述包含等级标识的等级规则的优先级高于不包含等级标识的等级规则，

根据所述等级标识，获取各个等级规则的优先级。

如下所述的等级规则表达式：

(expression1&&expression2)&&((expression4&&expression5)||(expression6&&expression7))。

在验证待选业务是否满足等级规则时，先获取等级规则表达式中的等级标识，即先获取等级规则表达式中的括号，根据括号获取各个等级规则的优先级。上述等级规则表达式中有4个括号，其中，有3个括号是嵌套的，为便于描述，此处将上述表达式简写为(a)&((b)||(c))，其中，a有括号，b有括号，c有括号，b和c逻辑或的结果有括号，那么包含括号的(a)和((b)||(c))的优先级相同，在((b)||(c))中，(b)和(c)的优先级相同。因此，在上述表达式中，先获得a的结果以及b和c的逻辑或的结果bc，最后获取a与bc的结果。

优先级相同的等级规则表达式，可通过表达式排列顺序，如可以从左到右依次验证，或可以任选一个先验证，或可以同时分别验证，例如上述(b)||(c)，可以从左至右先验证是否满足b，如果不满足再验证是否满足c；或可以随机验证是否满足b或c中的一个，如果不满足再验证是否满足另一个；或可以同时分别验证是否满足b或c。

如果是a&d，那么可以从左至右先验证是否满足a，如果满足再验证是否满足d；或是先验证是否满足a或d中任一个，如果满足再验证是否满足另一个；或可以同时分别验证是否满足b和c。

具体来说，可以先验证是否满足expression4&&expression5或expression6&&expression7中的任意一个，如果满足任意一个，再验证是否满足expression1&&expression2。

或是先验证是否满足expression1&&expression2，再验证是否满足expression4&&expression5，或expression4&&expression5中的任意一个。

或是同时验证是否满足expression4&&expression5或expression6&&expression7中的任意一个，以及expression1&&expression2。

本申请实施例中，所述资格认证请求中还包括用户端标识，

确认所述资格认证请求通过资格认证之后，所述方法还包括：

将所述目标业务发放至所述用户端标识对应的用户端。

发放目标业务至用户端的同时，可能还需要调用多个平台的资源支持，可能还需要再次验证。

本申请实施例中，用户端标识可以是用户端id，用户端mac地址，用户账号等任何可以用来识别、区分用户身份的标识。

本申请实施例中，调用多个平台的资源支持，可以是风控平台的风险控制资源，或者是外部服务平台的财务系统、操作系统、供应商系统或者数据仓库的资源支持，或者可以是业务发放平台的业务状态同步模块、资源管理模块、库存管控/预警模块的支持等，在此不再赘述。

本申请实施例中，可能还需要再次验证，可以是风控平台的再次验证，或可以是业务发放平台的库存管控/预警模块的再次验证，或可以是外部服务平台的财务系统的再次验证，在此不再赘述。

在本申请实施例中，统一定义了全局规则和等级规则，根据全局规则和等级规则，自动生成全局规则表达式和等级规则表达式，并根据全局规则表达式和等级规则表达式生成待认证表达式后进行认证，效率高，业务上线周期短，同时本申请也解绑了用户端和服务器，用户仅需要提出需求，服务器进行开发，用户端无需专业人员即可配置业务，成本低。由于本申请实施例中，把业务归结为各种规则，所以各个业务的内在可以有联系，各种业务可以服用，需要投入的开发资源较少。

图5所示为本申请实施例的业务资格认证的示意图，如图5所示，接收到资格认证请求，根据资格认证请求中的待认证资格的信息，生成待认证表达式，待认证表达式包括全局规则表达式和等级规则表达式。从待选业务数据库中筛选出所有符合全局规则表达式的待选业务，包括业务a、业务b、业务c，然后判断业务a、业务b、业务c是否满足等级规则表达式。

等级规则表达式可以是：条件(1)与条件(2)或条件(3)。经验证，业务a满足上述等级规则表达式，而业务b、业务c不满足等级规则表达式。

满足全局规则表达式，又满足等级规则表达式的业务是存在的，即业务a，因此本实施例的资格认证请求通过资格认证。

通过资格认证之后，系统发布业务a。

图2为一个实施例中业务资格认证方法的流程示意图。应该理解的是，虽然图2的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图6所示，提供了一种业务资格认证装置，包括：

图形化界面单元610，用于接收用户端发送的资格认证请求，所述资格认证请求包括待认证资格的信息，所述待认证资格信息包括全局规则和等级规则；

表达式生成单元620，用于根据所述待认证资格的信息，生成所述待认证表达式，所述待认证表达式包括全局规则表达式和等级规则表达式；

业务筛选单元630，用于在待选业务数据库中，获取满足所述全局规则表达式的所有待选业务；

所述业务筛选单元630还用于在所述所有待选业务中，获取满足所述等级规则表达式的待选业务作为目标业务；

认证单元640，用于若所述目标业务存在，则确认所述资格认证请求通过资格认证。

本申请实施例中，表达式生成单元620还用于：

根据所述待认证资格的信息，将将所述待认证资格分割为多个待认证子资格；

获取每一个所述待认证子资格对应的规则组，所述每一个待认证子资格对应一个规则组，一个规则组包括至少一个全局规则和至少一个等级规则；

生成所述全局规则对应的全局规则表达式；

生成所述等级规则对应的等级规则表达式；

根据所述全局规则表达式和等级规则表达式，生成所述待认证表达式。

本申请实施例中，若所述规则组包括至少两个全局规则，表达式生成单元620还用于：

生成所述规则组中每一个全局规则对应的参考全局规则表达式；

将多个所述参考全局规则表达式按照逻辑与的关系，生成所述全局规则对应的全局规则表达式。

本申请实施例中，表达式生成单元620还用于：

生成所述规则组中每一个等级规则对应的参考等级规则表达式；

获取每一个等级规则对应的优先级；

获取所述规则组中的多个所述参考等级规则之间的逻辑关系；

根据所述优先级及多个所述参考等级规则表达式之间的逻辑关系，生成所述等级规则对应的等级规则表达式，所述逻辑关系包括逻辑与和逻辑或。

本申请实施例中，表达式生成单元620还用于：

全局规则表达式与等级规则表达式，按照逻辑与的关系，生成所述待认证表达式。

本申请实施例中，认证单元640还用于：

获取所述等级规则表达式中的各个所述等级规则的优先级；

根据所述等级规则表达式中各个所述等级规则的优先级顺序，按照优先级从高至低依次验证所述待选业务是否满足所述等级规则表达式；

其中，所述获取所述等级规则表达式中各个所述等级规则的优先级，包括：

获取所述等级规则表达式中的等级标识，所述包含等级标识的等级规则的优先级高于不包含等级标识的等级规则，

根据所述等级标识，获取各个等级规则的优先级。

本申请实施例中，所述资格认证请求中还包括用户端标识，

所述装置还包括发放单元，用于将所述目标业务发放至所述用户端标识对应的用户端。

本申请实施例还提供了一种业务资格认证方法，如图7所示，所述方法包括：

步骤700，用户通过用户端提供的图形化界面按照需求进行配置。

用户的配置可以是全局规则、等级规则，以及等级规则的优先级、等级规则之间的逻辑关系。

图形化界面或可以提供各种选择给用户，选择包括预设的各种配置，使用户可以按照需求进行选择。

步骤710，终端根据用户配置生成资格认证请求。

步骤720，用户将资格认证请求发送至服务器。

步骤730，服务器接收用户端发送的资格认证请求。

资格认证请求包括待认证资格的信息，所述待认证资格信息包括全局规则和等级规则等。

步骤740，服务器根据待认证资格的信息，生成待认证表达式，所述待认证表达式包括全局规则表达式和等级规则表达式。

步骤750，在待选业务数据库中，获取满足所述全局规则表达式的所有待选业务。

步骤760，在所述所有待选业务中，获取满足所述等级规则表达式的待选业务作为目标业务。

步骤770，如果所述目标业务存在，即同时满足全局规则表达式和登记规则表达式的活动存在，则确认终端发送的资格认证请求通过资格认证。

步骤780，按照用户需求，发布通过资格认证的资格认证请求对应的业务。

本申请实施例的方法，可以减少业务的开发时长，提高业务开发的效率。

图8示出了一个实施例中计算机设备的内部结构图。该计算机设备具体可以是图1中的终端110(或服务器120)。如图8所示，该计算机设备包括该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、输入装置和显示屏。其中，存储器包括非易失性存储介质和内存储器。该计算机设备的非易失性存储介质存储有操作系统，还可存储有计算机程序，该计算机程序被处理器执行时，可使得处理器实现业务资格认证方法。该内存储器中也可储存有计算机程序，该计算机程序被处理器执行时，可使得处理器执行业务资格认证方法。计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图8中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：

接收用户端发送的资格认证请求，所述资格认证请求包括待认证资格的信息，所述待认证资格信息包括全局规则和等级规则；根据所述待认证资格的信息，生成所述待认证表达式，所述待认证表达式包括全局规则表达式和等级规则表达式；在待选业务数据库中，获取满足所述全局规则表达式的所有待选业务；在所述所有待选业务中，获取满足所述等级规则表达式的待选业务作为目标业务；若所述目标业务存在，则确认所述资格认证请求通过资格认证。

在一个实施例中，处理器执行计算机程序时还实现上述方法的步骤，在此不再赘述。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

接收用户端发送的资格认证请求，所述资格认证请求包括待认证资格的信息，所述待认证资格信息包括全局规则和等级规则；根据所述待认证资格的信息，生成所述待认证表达式，所述待认证表达式包括全局规则表达式和等级规则表达式；在待选业务数据库中，获取满足所述全局规则表达式的所有待选业务；在所述所有待选业务中，获取满足所述等级规则表达式的待选业务作为目标业务；若所述目标业务存在，则确认所述资格认证请求通过资格认证。

在一个实施例中，计算机程序被处理器执行时还实现上述方法的步骤，在此不再赘述。

在一个实施例中，提供了一种计算机程序产品或计算机程序，所述计算机程序产品或计算机程序包括计算机指令，所述计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行以下步骤：

接收用户端发送的资格认证请求，所述资格认证请求包括待认证资格的信息，所述待认证资格信息包括全局规则和等级规则；根据所述待认证资格的信息，生成所述待认证表达式，所述待认证表达式包括全局规则表达式和等级规则表达式；在待选业务数据库中，获取满足所述全局规则表达式的所有待选业务；在所述所有待选业务中，获取满足所述等级规则表达式的待选业务作为目标业务；若所述目标业务存在，则确认所述资格认证请求通过资格认证。

在一个实施例中，计算机程序产品或计算机程序执行时还实现上述方法的步骤，在此不再赘述。

本申请实施例还提供了一种业务资格认证系统，所述系统包括业务配置平台、资格认证平台、风控平台、业务发放平台以及外部系统平台，如图9所示。

业务配置平台，用于给用户提供图像化界面，所述图形化界面用于接收资格认证请求，所述业务配置平台还用于将所述资格认证请求发送至资格认证平台。

图形化界面可以如图3及图4所示，用户可以通过图形化界面设置全局规则、等级规则，以及等级规则之间的优先级和逻辑关系等，或者系统会提供各种选择给用户，使得用户可以通过图像化进行选择性配置。用户还可以通过图形化界面进行其他配置，例如业务名称、业务上线时间等，在此不再赘述。用户通过根据图形化界面的配置，生成资格认证请求，将资格认证请求发送至资格认证平台。

图形化界面可以包括规则配置模块、配置数据库等，还可以包括数据收集模块、业务统计模块等。

资格认证平台，用于执行上述业务资格认证方法中的各步骤。

资格认证平台可以包括资格认证请求接收模块、规则定义模块、表达式生成模块、业务筛选模块、认证数据库等，还可以包括业务状态同步模块。

业务发放平台，用于发放通过资格认证的资格认证请求对应的业务。

业务发放平台可以包括业务状态同步模块、业务发放结果同步模块、资源管理模块、资源发放模块、库存管控/预警模块等。

上述资格认证平台中的业务状态同步模块可以与业务发放平台中的业务状态同步模块相对接，保证业务在多个平台之间可以同步。

外部系统平台，用于给业务资格认证系统提供资源支持。

外部服务平台可以包括操作系统、财务系统、供应商系统以及数据仓库等。

风控平台，用于对通过资格认证的资格认证请求进行风控验证。

若业务资格认证系统中包括风控平台，则业务发放平台发放业务之前，可以由风控平台进行风控验证。

本申请实施例的业务资格认证系统，给用户提供了图像化、可视化界面，用户可以通过图形化界面实现业务的快速创建。用户根据需求，创建了业务之后，本申请实施例的资格认证系统，可以根据用户设置或选择的全局规则、等级规则等，自动从业务库中进行筛选，如果筛选出满足用户需求的业务即说明书用户的业务资格认证通过。业务资格认证通过后，本申请实施例的系统，还可以按照用户设定的业务名称、业务上线时间等自动发布业务，实现了在终端进行业务配置，在服务器进行业务资格认证，前台和后台的分离，可以减少业务的开发时长，提高业务开发的效率。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。

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

以上所述仅是本申请的具体实施方式，使本领域技术人员能够理解或实现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。