掌桥专利:专业的专利平台
掌桥专利
首页

业务处理方法、装置及设备

文献发布时间:2023-06-19 12:18:04


业务处理方法、装置及设备

技术领域

本申请实施例涉及计算机技术领域,尤其涉及一种业务处理方法、装置及设备。

背景技术

对于部分业务,在用户请求业务处理时,在验证用户的用户特征满足业务需求时,才能进行业务处理。例如,用户在购买理财产品时,只有该用户的用户特征满足该理财产品的需求时,用户才可以购买。

在相关技术中,在进行业务处理之前,需要根据业务需求设计该业务对应的验证逻辑,并根据该验证逻辑对用户的用户特征进行验证处理,其中,业务需求中包括多个用户特征和用户特征需要满足的条件。然而,在实际应用过程中,若业务需求发生变化(例如,业务需求中的用户特征发生变化或者用户特征需要满足的条件发生变化),则需要修改业务对应的验证逻辑。在上述过程中,由于采用验证逻辑对用户特征进行验证,因此,需要维护业务对应的验证逻辑,由于验证逻辑修改的复杂程度较高,导致业务维护的复杂度较高。

发明内容

本申请实施例提供一种业务处理方法、装置及设备,降低了业务维护的复杂度。

第一方面,本申请实施例提供一种业务处理方法,包括:

接收业务处理请求,所述业务处理请求中包括待请求业务的标识和多个用户特征;

在所述多个用户特征中确定M个第一用户特征和N个第二用户特征,所述第一用户特征与其它用户特征之间不存在依赖关系,所述N个第二用户特征之间存在依赖关系,所述M为整数,所述N为正整数;

根据所述待请求业务的业务需求信息,分别对所述M个第一用户特征进行验证处理,得到每个第一用户特征的验证结果;

根据所述待请求业务的业务需求信息,对所述N个第二用户特征进行验证处理,得到所述N个第二用户特征中至少一个第三用户特征的验证结果,所述第三用户特征依赖于所述第二用户特征中的其它用户特征,且所述第三用户特征未被所述第二用户特征中的其它用户特征依赖;

根据所述M个第一用户特征的验证结果和所述至少一个第三用户特征的验证结果,对所述待请求业务进行业务处理。

在一种可能的实施方式中,根据所述待请求业务的业务需求信息,对所述N个第二用户特征进行验证处理,包括:

根据所述N个第二用户特征之间的依赖关系,确定至少一条依赖链,所述依赖链中包括至少两个具有依赖关系的用户特征,所述依赖链中的前一个用户特征依赖于后一个用户特征;

根据所述待请求业务的业务需求信息,分别对每条依赖链中的第二用户特征进行验证处理。

在一种可能的实施方式中,针对任意一条依赖链,根据所述待请求业务的业务需求信息,对所述依赖链中的第二用户特征进行验证处理,包括:

根据所述依赖链中各第二用户特征之间的依赖关系,确定所述依赖链中每个第二用户特征的依赖深度K,所述第二用户特征被K个依赖深度不同的用户特征依赖,所述K为大于或等于0的整数;

根据所述依赖链中每个第二用户特征的依赖深度K和所述待请求业务的业务需求信息,对所述依赖链中的第二用户特征进行验证处理。

在一种可能的实施方式中,确定所述依赖链中每个第二用户特征的依赖深度K,包括:

初始化每个第二用户特征对应的依赖深度;

确定所述依赖链中第i个第二用户特征的依赖用户特征,将所述依赖用户特征对应的依赖深度更新为所述第i个第二用户特征的依赖深度加1,将所述依赖用户特征确定为第i+1个第二用户特征,所述依赖链中的第一个用户特征为所述依赖链中的第三用户特征;

其中,所述i取1、2、……、X-1,所述X为所述依赖链中包括的第二用户特征的数量。

在一种可能的实施方式中,确定所述依赖链中每个第二用户特征的依赖深度K,包括:

确定所述依赖链中第i个第二用户特征对应的依赖深度为i-1,其中,所述i为大于或等于1,并且小于或等于X的整数,所述X为所述依赖链中包括的第二用户特征的数量。

在一种可能的实施方式中,根据所述依赖链中每个第二用户特征的依赖深度K和所述待请求业务的业务需求信息,对所述依赖链中的第二用户特征进行验证处理,包括:

按照依赖深度从高到低的顺序,根据所述待请求业务的业务需求信息,依次对所述依赖链中的第二用户特征进行验证处理。

在一种可能的实施方式中,根据所述M个第一用户特征的验证结果和所述至少一个第三用户特征的验证结果,对所述待请求业务进行业务处理,包括:

若所述M个第一用户特征的验证结果为验证成功,并且所述至少一个第三用户特征的验证结果为验证成功,则根据所述至少一个用户特征对所述待请求业务进行处理;

若所述M个第一用户特征中存在第一用户特征的验证结果为验证失败,或者所述至少一个第三用户特征中存在第三用户特征的验证结果为验证失败,则拒绝对所述待请求业务进行处理。

第二方面,本申请实施例提供一种业务处理装置,包括:接收模块、确定模块、验证模块和处理模块,其中,

所述接收模块用于,接收业务处理请求,所述业务处理请求中包括待请求业务的标识和多个用户特征;

所述确定模块用于,在所述多个用户特征中确定M个第一用户特征和N个第二用户特征,所述第一用户特征与其它用户特征之间不存在依赖关系,所述N个第二用户特征之间存在依赖关系,所述M为整数,所述N为正整数;

所述验证模块用于,根据所述待请求业务的业务需求信息,分别对所述M个第一用户特征进行验证处理,得到每个第一用户特征的验证结果;

所述验证模块还用于,根据所述待请求业务的业务需求信息,对所述N个第二用户特征进行验证处理,得到所述N个第二用户特征中至少一个第三用户特征的验证结果,所述第三用户特征依赖于所述第二用户特征中的其它用户特征,且所述第三用户特征未被所述第二用户特征中的其它用户特征依赖;

所述处理模块用于,根据所述M个第一用户特征的验证结果和所述至少一个第三用户特征的验证结果,对所述待请求业务进行业务处理。

在一种可能的实施方式中,所述验证模块具体用于:

根据所述N个第二用户特征之间的依赖关系,确定至少一条依赖链,所述依赖链中包括至少两个具有依赖关系的用户特征,所述依赖链中的前一个用户特征依赖于后一个用户特征;

根据所述待请求业务的业务需求信息,分别对每条依赖链中的第二用户特征进行验证处理。

在一种可能的实施方式中,所述验证模块具体用于:

针对任意一条依赖链,根据所述依赖链中各第二用户特征之间的依赖关系,确定所述依赖链中每个第二用户特征的依赖深度K,所述第二用户特征被K个依赖深度不同的用户特征依赖,所述K为大于或等于0的整数;

根据所述依赖链中每个第二用户特征的依赖深度K和所述待请求业务的业务需求信息,对所述依赖链中的第二用户特征进行验证处理。

在一种可能的实施方式中,所述验证模块具体用于:

初始化每个第二用户特征对应的依赖深度;

确定所述依赖链中第i个第二用户特征的依赖用户特征,将所述依赖用户特征对应的依赖深度更新为所述第i个第二用户特征的依赖深度加1,将所述依赖用户特征确定为第i+1个第二用户特征,所述依赖链中的第一个用户特征为所述依赖链中的第三用户特征;

其中,所述i取1、2、……、X-1,所述X为所述依赖链中包括的第二用户特征的数量。

在一种可能的实施方式中,所述验证模块具体用于:

确定所述依赖链中第i个第二用户特征对应的依赖深度为i-1,其中,所述i为大于或等于1,并且小于或等于X的整数,所述X为所述依赖链中包括的第二用户特征的数量。

在一种可能的实施方式中,所述验证模块具体用于:

按照依赖深度从高到低的顺序,根据所述待请求业务的业务需求信息,依次对所述依赖链中的第二用户特征进行验证处理。

在一种可能的实施方式中,所述处理模块具体用于:

若所述M个第一用户特征的验证结果为验证成功,并且所述至少一个第三用户特征的验证结果为验证成功,则根据所述至少一个用户特征对所述待请求业务进行处理;

若所述M个第一用户特征中存在第一用户特征的验证结果为验证失败,或者所述至少一个第三用户特征中存在第三用户特征的验证结果为验证失败,则拒绝对所述待请求业务进行处理。

第三方面,本申请实施例提供一种业务处理设备,包括:处理器、存储器;

所述存储器存储计算机执行指令;

所述处理器执行所述存储器存储的计算机执行指令,使得所述处理器执行如第一方面任一项所述的业务处理方法。

第四方面,本申请实施例提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当所述计算机执行指令被处理器执行时用于实现第一方面任一项所述的业务处理方法。

第五方面,本申请实施例提供一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现第一方面任一项所示的业务处理方法。

本申请实施例提供的业务处理方法,在接收到用户的业务处理请求之后,获取用户的多个用户特征,在该多个用户特征中确定M个第一用户特征和N个第二用户特征,第一用户特征与其它用户特征之间不存在依赖关系,N个第二用户特征之间存在依赖关系。根据待请求业务的业务需求信息分别对M个第一用户特征和N个第二用户特征进行验证处理,并根据验证结果对待请求业务进行业务处理。在上述过程中,无需提前设计业务的验证逻辑,更无需对验证逻辑进行维护处理,进而降低了对业务进行维护的复杂度。

附图说明

图1为本申请实施例提供的应用场景的架构图;

图2为本申请实施例提供的一种业务处理方法的流程示意图;

图3为本申请实施例提供的另一种业务处理方法的流程示意图;

图4为本申请实施例提供的分链处理的流程示意图;

图5为本申请实施例提供的一种业务处理装置的结构示意图;

图6为本申请实施例提供的一种业务处理设备的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

为了便于理解,首先结合图1,对本申请实施例所适用的应用场景进行说明。

图1为本申请实施例提供的应用场景的架构图。请参见图1,包括电子设备,电子设备可以进行业务处理。电子设备可以获取用户的多个用户特征,并对多个用户特征进行验证,在验证通过之后,电子设备可以对用户所请求的业务进行处理。例如,用户特征为可以包括:用户的姓名、年龄、职业、所在城市、用户类型等。

多个用户特征中包括相互独立的用户特征、以及具有依赖关系的用户特征。相互独立的用户特征是指:对该特征的验证不需要依赖于其它用户特征的验证结果,并且对其它用户特征的验证也不需要依赖于该用户特征的验证结果。具有依赖关系的用户特征是指:对该特征的验证需要依赖于其它用户特征的验证结果,和/或,对其它用户特征的验证需要依赖于该用户特征的验证结果。例如,对于用户特征:名字和职业,只有在验证名字位于白名单时,才对职业进行验证,在该种情况下,职业依赖于对名字的验证结果。

例如,请参见图1,假设用户特征包括:A、B、C、D、E、F、G、H、I,其中,用户特征A和用户特征B为独立的用户特征;用户特征C依赖于用户特征D,且用户特征D依赖于用户特征E;用户特征F依赖于用户特征G和用户特征H,且用户特征G和用户特征H依赖于用户特征I。其中,用户特征C-用户特征E可以称为一条依赖链,用户特征F-用户特征I可以称为一条依赖链。

在相关技术中,需要根据业务需求设计业务对应的验证逻辑,并且对验证逻辑进行维护。当业务需求发生变化时,需要对验证逻辑进行适应修改。例如,请参见图1,假设业务需求中不再需要对用户特征G进行验证,则需要对该业务对应的业务逻辑进行修改,对业务逻辑修改的复杂度较高,导致对业务维护的复杂度较高。

为了解决上述技术问题,在本申请实施例中,在接收到业务处理请求之后,获取用户的多个用户特征、以及用户特征之间的依赖关系,并根据多个用户特征之间的依赖关系,对用户特征进行验证处理,无需提前设计业务的验证逻辑,更无需对验证逻辑进行维护处理,进而降低了对业务进行维护的复杂度。

下面,通过具体实施例对本申请所示的技术方案进行详细说明。需要说明的是,下面几个实施例可以独立存在,也可以相互结合,对于相同或相似的内容,在不同的实施例中不再重复说明。

图2为本申请实施例提供的一种业务处理方法的流程示意图。请参见图2,该方法可以包括:

S201、接收业务处理请求。

本申请实施例的执行主体可以为电子设备,也可以为设置在电子设备中的业务处理装置。业务处理装置可以通过软件实现,也可以通过软件和硬件的结合实现。

业务处理请求用于请求对待请求业务进行处理。业务处理请求中可以包括待请求业务的标识和多个用户特征。

待请求业务可以为用户请求购买预设对象,例如,预设对象可以为商品、理财产品等。

用户特征是指请求待请求业务的用户的特征。例如,用户特征可以包括用户的年龄、职业、性别、健康状况等。

可选的,电子设备可以接收客户端发送的业务处理请求,或者接收业务人员在电子设备中输入的业务处理请求。

S202、在多个用户特征中确定M个第一用户特征和N个第二用户特征。

其中,M为整数,N为正整数。即,M为大于或等于0的整数,N为大于或等于1的整数。

第一用户特征与其它用户特征之间不存在依赖关系,即,第一用户特征不依赖于其它用户特征(对第一用户特征的验证不需要依赖于其它用户特征的验证结果),其它用户特征也不依赖于第一用户特征(对其它用户特征的验证不需要依赖于第一用户特征的验证结果)。

N个第二用户特征之间存在依赖关系,例如,N个第二用户特征中存在一条或者多条依赖链。

可以预先设置待请求业务对应的配置信息,配置信息中包括待请求业务对应的多个用户特征之间的依赖关系,相应的,可以根据该依赖关系在多个用户特征中确定M个第一用户特征和N个第二用户特征。

S203、根据待请求业务的业务需求信息,分别对M个第一用户特征进行验证处理,得到每个第一用户特征的验证结果。

业务需求信息中包括每个第一用户特征对应的验证条件。针对任意一个第一用户特征,若该第一用户特征满足其对应的验证条件,则确定该第一用户特征对应的验证结果为验证成功;若该第一用户特征不满足其对应的验证条件,则确定该第一用户特征对应的验证结果为验证失败。

S204、根据待请求业务的业务需求信息,对N个第二用户特征进行验证处理,得到N个第二用户特征中至少一个第三用户特征的验证结果。

第三用户特征依赖于第二用户特征中的其它用户特征,且第三用户特征未被第二用户特征中的其它用户特征依赖。即,第三用户特征为依赖链中的首个用户特征。例如,请参见图1,对于依赖链(包括用户特征C-用户特征E),第三用户特征为用户特征C,对于依赖链(包括用户特征F-用户特征I),第三用户特征为用户特征F。

可以通过如下方式对N个第二用户特征进行验证处理:根据N个第二用户特征之间的依赖关系,确定至少一条依赖链,根据待请求业务的业务需求信息,分别对每条依赖链中的第二用户特征进行验证处理。依赖链中包括至少两个具有依赖关系的用户特征,依赖链中的前一个用户特征依赖于后一个用户特征。

针对每条依赖链,分别对每条依赖链中的第二用户特征进行验证,可以得到该条依赖链中的第三用户特征的验证结果,其中,第三用户特征为该条依赖链中的首个用户特征。

S205、根据M个第一用户特征的验证结果和至少一个第三用户特征的验证结果,对待请求业务进行业务处理。

若M个第一用户特征的验证结果为验证成功,并且至少一个第三用户特征的验证结果为验证成功,则确定对用户的用户特征验证成功。在该种情况下,可以根据至少一个用户特征对待请求业务进行处理。

若M个第一用户特征中存在第一用户特征的验证结果为验证失败,或者至少一个第三用户特征中存在第三用户特征的验证结果为验证失败,则确定对用户的用户特征验证失败。在该种情况下,可以拒绝对待请求业务进行处理。

本申请实施例提供的业务处理方法,在接收到用户的业务处理请求之后,获取用户的多个用户特征,在该多个用户特征中确定M个第一用户特征和N个第二用户特征,第一用户特征与其它用户特征之间不存在依赖关系,N个第二用户特征之间存在依赖关系。根据待请求业务的业务需求信息分别对M个第一用户特征和N个第二用户特征进行验证处理,并根据验证结果对待请求业务进行业务处理。在上述过程中,无需提前设计业务的验证逻辑,更无需对验证逻辑进行维护处理,进而降低了对业务进行维护的复杂度。

在上述任意一个实施例的基础上,下面,结合图3,对上述业务处理方法进行详细说明。

图3为本申请实施例提供的另一种业务处理方法的流程示意图。请参见图3,该方法可以包括:

S301、接收业务处理请求。

S302、在多个用户特征中确定M个第一用户特征和N个第二用户特征。

需要说明的是,S301-S302的执行过程可以参见S201的执行过程,此处不再进行赘述。

S303、根据N个第二用户特征之间的依赖关系,确定至少一条依赖链。

依赖链中包括至少两个具有依赖关系的用户特征,依赖链中的前一个用户特征依赖于后一个用户特征。

可以根据N个第二用户特征之间的依赖关系,对N个第二用户特征进行分链处理,以实现将具有依赖关系的第二用户特征分配至同一依赖链中。

下面,结合图4,对分链处理进行说明。

图4为本申请实施例提供的分链处理的流程示意图。请参见图4,初始时,N个第二用户特征中包括用户特征A、用户特征B、用户特征C、用户特征D、用户特征E、用户特征F,依赖链为空。

在N个第二用户特征中取出任意的用户特征A,并确定用户特征A依赖的用户特征为用户特征B,则可以据此形成依赖链1:用户特征A依赖用户特征B,再在N个用户特征中确定用户特征B依赖的用户特征为用户特征D,并据此更新依赖链1:用户特征A依赖用户特征B,用户特征B依赖用户特征D,由于用户特征D没有依赖的用户特征,则对依赖链1更新完成。

在N个第二用户特征中取出任意的用户特征F,并确定用户特征F依赖的用户特征为用户特征E,则可以据此形成依赖链2:用户特征F依赖用户特征E,再在N个用户特征中查找用户特征E依赖的用户特征,假设用户特征E不依赖于任何用户特征,则确定N个第二用户特征中剩余的用户特征C依赖用户特征E,则可以据此更新依赖链2:用户特征C依赖用户特征E,用户特征E依赖用户特征F。

在确定得到至少一条依赖链之后,对每条依赖链的处理过程相同,在如下的S304-S305中,以对任意一条依赖链的处理过程为例进行说明。

S304、根据依赖链中各第二用户特征之间的依赖关系,确定依赖链中每个第二用户特征的依赖深度K。

第二用户特征对应依赖深度K,还可以理解为:第二用户特征被K个依赖深度不同的用户特征依赖。在第一条依赖链中,假设前一个用户特征依赖于后一个用户特征,则第二用户特征对应的依赖深度K是指,第二用户特征在依赖链中的位置K(第二用户特征为依赖链中的第K个用户特征)。例如,请参见图1,对于依赖链(包括用户特征C-用户特征E),用户特征C的依赖深度为0,用户特征D的依赖深度为1,用户特征E的依赖深度为2。对于依赖链(包括用户特征F-用户特征I),用户特征F的依赖深度为0,用户特征G和用户特征H的依赖深度为1,用户特征I的依赖深度为2。

可选的,可以通过如下至少两种方式确定依赖链中每个第二用户特征的依赖深度:

第一种方式:

初始化每个第二用户特征对应的依赖深度,并确定依赖链中第i个第二用户特征的依赖用户特征,将依赖用户特征对应的依赖深度更新为第i个第二用户特征的依赖深度加1,将依赖用户特征确定为第i+1个第二用户特征。其中,i取1、2、……、X-1,X为依赖链中包括的第二用户特征的数量。依赖链中的第一个用户特征为依赖链中的第三用户特征。

可以先将依赖链中的每个第二用户特征对应的依赖深度初始化为0,并在该依赖链中确定第1个第二用户特征,第1个第二用户特征未被其它的用户特征所依赖。确定第1个第二用户特征的依赖用户特征,并将该依赖用户特征的依赖深度更新了第1个第二用户特征对应的依赖深度加1。将第1个第二用户的依赖用户特征确定为第2个第二用户特征,并确定第2个第二用户特征的依赖用户特征,将第2个第二用户特征的依赖用户特征的依赖深度更新为第2个第二用户特征的依赖深度加1,重复上述过程,直至i为X。

例如,请参见图1,假设依赖链为:用户特征C依赖用户特征D,用户特征D依赖用户特征E。则可以先将用户特征C、用户特征D和用户特征E的依赖深度分别初始化为0,并在该依赖链中确定第1个第二用户特征为用户特征C,则在依赖链中确定用户特征C的依赖用户特征为用户特征D,则将用户特征D的依赖深度更新为用户特征C的依赖深度加1,由于用户特征C的依赖深度为0,因此,更新后的用户特征D的依赖深度为1。再将用户特征D确定为第2个用户特征,并确定用户特征D的依赖用户特征为用户特征E,则将用户特征E的依赖深度更新为用户特征D的依赖深度加1,由于用户特征D的依赖深度为1,则更新后的用户特征E的依赖深度为2。即,用户特征C的依赖深度为0,用户特征D的依赖深度为1,用户特征E的依赖深度为2。

第二种方式:

确定依赖链中第i个第二用户特征对应的依赖深度为i-1,其中,i为大于或等于1,并且小于或等于X的整数,所述X为所述依赖链中包括的第二用户特征的数量。

在该种方式中,可以确定依赖链中每个第二用户特征的序号(位置)i,并将该第i个第二用户特征对应的依赖深度确定为i-1。

例如,请参见图1,假设依赖链为:用户特征C依赖用户特征D,用户特征D依赖用户特征E。可以确定该依赖链中用户特征C的序号为1,用户特征D的序号为2,用户特征E的序号为3,则可以确定用户特征C的依赖深度为0,用户特征D的依赖深度为1,用户特征E的依赖深度为2。

在该种方式中,根据用户特征的序号即可确定得到用户特征的依赖深度,使得确定用户特征的依赖深度的效率较高。

S305、根据依赖链中每个第二用户特征的依赖深度K和待请求业务的业务需求信息,对依赖链中的第二用户特征进行验证处理,得到该依赖链中的第三用户特征的验证结果。

依赖链中的第三用户特征是指依赖链中的第一个用户特征。即,第三用户特征为该依赖链中依赖深度为0的用户特征。

可以通过如下方式对依赖链中的第二用户特征进行验证处理:按照依赖深度从高到低的顺序,根据待请求业务的业务需求信息,依次对依赖链中的第二用户特征进行验证处理。

依赖链中包括尾端第二用户特征和非尾端第二用户特征,尾端第二用户特征是指依赖链中的最后一个第二用户特征,最后一个第二用户特征未依赖该依赖链中的其它用户特征依赖。对尾端第二用户特征和非尾端第二用户特征的验证过程不同,下面,分别对该两种类型的第二用户特征的验证过程进行说明。

针对尾端第二用户特征,可以在业务需求信息中获取该尾端第二用户特征对应的验证条件,并根据该验证条件对尾端第二用户特征进行验证处理。例如,判断尾端第二用户特征是否满足验证条件,若是,则对尾端第二用户特征验证通过,若否,则对尾端第二用户特征验证失败。

针对非尾端第二用户特征,可以确定非尾端第二用户特征的依赖用户特征,获取该依赖用户特征对应的验证结果;还在业务需求信息中获取非尾端第二用户特征对应的验证条件,并根据依赖用户特征对应的验证结果和非尾端第二用户特征对应的验证条件,对非尾端第二用户特征进行验证处理。具体的,可以包括如下两种可能的实现方式:

在一种可能的实现方式中,若依赖用户特征对应的验证结果为验证成功,则根据非尾端第二用户特征对应的验证条件对该非尾端第二用户特征进行验证处理;若依赖用户特征对应的验证结果为验证失败,则确定该非尾端第二用户特征对应的验证结果也为验证失败。

在另一种可能的实现方式中,若依赖用户特征对应的验证结果为验证成功,则获取验证成功结果对应的验证条件,并通过该验证条件对非尾端第二用户特征进行验证处理;若依赖用户特征对应的验证结果为验证失败,则获取验证失败结果对应的验证条件,并通过该验证条件对非尾端第二用户特征进行验证处理。

例如,请参见图1,假设依赖链为:用户特征C依赖用户特征D,用户特征D依赖用户特征E。则可以先根据用户特征E对应的验证条件对用户特征E进行验证处理,得到用户特征E的验证结果1。再根据验证结果1和用户特征D对应的验证条件对用户特征D进行验证处理,得到用户特征D的验证结果2。再根据验证结果2和用户特征E对应的验证条件对用户特征E进行验证处理,得到用户特征E的验证结果3。用户特征E即为该依赖链中的第三用户特征。

通过上述S304-S305,可以获取每个依赖链中的第三用户特征的验证结果。

S306、根据所述待请求业务的业务需求信息,分别对所述M个第一用户特征进行验证处理,得到每个第一用户特征的验证结果。

需要说明的是,S306的执行过程可以参见S203的执行过程,此处不再进行赘述。

S307、根据M个第一用户特征的验证结果和至少一个第三用户特征的验证结果,对待请求业务进行业务处理。

需要说明的是,S307的执行过程可以参见S205的执行过程,此处不再进行赘述。

本申请实施例提供的业务处理方法,在接收到用户的业务处理请求之后,获取用户的多个用户特征,在该多个用户特征中确定M个第一用户特征和N个第二用户特征,第一用户特征与其它用户特征之间不存在依赖关系,N个第二用户特征之间存在依赖关系。在N个第二用户特征中确定至少一条依赖链,根据待请求业务的业务需求信息分别对M个第一用户特征、以及每条依赖链中的用户特征进行验证处理,并根据验证结果对待请求业务进行业务处理。在上述过程中,无需提前设计业务的验证逻辑,更无需对验证逻辑进行维护处理,进而降低了对业务进行维护的复杂度。

图5为本申请实施例提供的一种业务处理装置的结构示意图。请参见图5,该业务处理装置10可以包括:接收模块11、确定模块12、验证模块13和处理模块14,其中,

所述接收模块11用于,接收业务处理请求,所述业务处理请求中包括待请求业务的标识和多个用户特征;

所述确定模块12用于,在所述多个用户特征中确定M个第一用户特征和N个第二用户特征,所述第一用户特征与其它用户特征之间不存在依赖关系,所述N个第二用户特征之间存在依赖关系,所述M为整数,所述N为正整数;

所述验证模块13用于,根据所述待请求业务的业务需求信息,分别对所述M个第一用户特征进行验证处理,得到每个第一用户特征的验证结果;

所述验证模块13还用于,根据所述待请求业务的业务需求信息,对所述N个第二用户特征进行验证处理,得到所述N个第二用户特征中至少一个第三用户特征的验证结果,所述第三用户特征依赖于所述第二用户特征中的其它用户特征,且所述第三用户特征未被所述第二用户特征中的其它用户特征依赖;

所述处理模块14用于,根据所述M个第一用户特征的验证结果和所述至少一个第三用户特征的验证结果,对所述待请求业务进行业务处理。

本申请实施例所示的业务处理装置10可以执行上述方法实施例所示的技术方案,其实现原理以及有益效果类似,此处不再进行赘述。

在一种可能的实施方式中,所述验证模块13具体用于:

根据所述N个第二用户特征之间的依赖关系,确定至少一条依赖链,所述依赖链中包括至少两个具有依赖关系的用户特征,所述依赖链中的前一个用户特征依赖于后一个用户特征;

根据所述待请求业务的业务需求信息,分别对每条依赖链中的第二用户特征进行验证处理。

在一种可能的实施方式中,所述验证模块13具体用于:

针对任意一条依赖链,根据所述依赖链中各第二用户特征之间的依赖关系,确定所述依赖链中每个第二用户特征的依赖深度K,所述第二用户特征被K个依赖深度不同的用户特征依赖,所述K为大于或等于0的整数;

根据所述依赖链中每个第二用户特征的依赖深度K和所述待请求业务的业务需求信息,对所述依赖链中的第二用户特征进行验证处理。

在一种可能的实施方式中,所述验证模块13具体用于:

初始化每个第二用户特征对应的依赖深度;

确定所述依赖链中第i个第二用户特征的依赖用户特征,将所述依赖用户特征对应的依赖深度更新为所述第i个第二用户特征的依赖深度加1,将所述依赖用户特征确定为第i+1个第二用户特征,所述依赖链中的第一个用户特征为所述依赖链中的第三用户特征;

其中,所述i取1、2、……、X-1,所述X为所述依赖链中包括的第二用户特征的数量。

在一种可能的实施方式中,所述验证模块13具体用于:

确定所述依赖链中第i个第二用户特征对应的依赖深度为i-1,其中,所述i为大于或等于1,并且小于或等于X的整数,所述X为所述依赖链中包括的第二用户特征的数量。

在一种可能的实施方式中,所述验证模块13具体用于:

按照依赖深度从高到低的顺序,根据所述待请求业务的业务需求信息,依次对所述依赖链中的第二用户特征进行验证处理。

在一种可能的实施方式中,所述处理模块14具体用于:

若所述M个第一用户特征的验证结果为验证成功,并且所述至少一个第三用户特征的验证结果为验证成功,则根据所述至少一个用户特征对所述待请求业务进行处理;

若所述M个第一用户特征中存在第一用户特征的验证结果为验证失败,或者所述至少一个第三用户特征中存在第三用户特征的验证结果为验证失败,则拒绝对所述待请求业务进行处理。

本申请实施例所示的业务处理装置10可以执行上述方法实施例所示的技术方案,其实现原理以及有益效果类似,此处不再进行赘述。

图6为本申请实施例提供的一种业务处理设备的结构示意图。请参见图6,业务处理设备20可以包括:存储器21、处理器22。示例性地,存储器21、处理器22,各部分之间通过总线23相互连接。

存储器21用于存储程序指令;

处理器22用于执行该存储器所存储的程序指令,用以使得业务处理设备20执行上述任一所示的业务处理方法。

图6实施例所示的业务处理设备可以执行上述方法实施例所示的技术方案,其实现原理以及有益效果类似,此处不再进行赘述。

本申请实施例提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当所述计算机执行指令被处理器执行时用于实现上述业务处理方法。

本申请实施例还可提供一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时,可实现上述业务处理方法。

实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一可读取存储器中。该程序在执行时,执行包括上述各方法实施例的步骤;而前述的存储器(存储介质)包括:只读存储器(英文:read-only memory,缩写:ROM)、RAM、快闪存储器、硬盘、固态硬盘、磁带(英文:magnetic tape)、软盘(英文:floppydisk)、光盘(英文:optical disc)及其任意组合。

本申请实施例是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理单元以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理单元执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然,本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

在本申请中,术语“包括”及其变形可以指非限制性的包括;术语“或”及其变形可以指“和/或”。本本申请中术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。本申请中,“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

相关技术
  • 基于区块链的业务处理方法、业务处理方法、装置及设备
  • 基于区块链的业务处理方法、业务处理方法、装置及设备
技术分类

06120113239485