CN117132100A - 基于签约流程的数据处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种基于签约流程的数据处理方法、装置、设备及存储介质，涉及数据处理技术领域，该方法包括：接收节点服务请求，根据节点服务请求中携带的场景参数，匹配目标服务功能对应的服务场景，并根据服务场景对应的场景配置文件，从节点服务请求中，提取请求参数集合；根据服务场景对应的服务逻辑文件，对目标服务功能进行服务编排，获得执行目标服务功能所需调用的基础服务序列；依次调用基础服务序列中的各个基础服务，其中调用每个基础服务时，从请求参数集合中获得每个基础服务对应的至少一个请求参数，并基于至少一个请求参数发起每个基础服务的服务调用；在基础服务序列调用完成时，获得节点服务请求对应的服务响应。

Description

基于签约流程的数据处理方法、装置、设备及存储介质

技术领域

本申请涉及数据处理技术领域，提供一种基于签约流程的数据处理方法、装置、设备及存储介质。

背景技术

银行等金融机构办理业务的过程中通常会涉及到签约过程，为了提升业务办理效率，提供了线上签约的方式。不同的业务涉及到不同的签约流程，不同的签约流程对应着不同的签约服务功能，例如签约身份合法性检查、风险评估测试、签约信息检查以及签约执行等功能，在不同的签约场景中需要使用各自不同的签约服务功能。

因此，对于不同的签约服务功能而言，其所请求的基础服务不同，请求的基础服务的顺序也不同，因此当需要新增一个签约服务功能时，则需要针对该签约场景定制化开发相应的签约服务功能，开发过程较为繁琐，业务实现周期较长，使得业务实现效率低。

发明内容

本申请实施例提供一种基于签约流程的数据处理方法、装置、设备及存储介质，用于降低签约服务功能的繁琐程度，提升业务实现效率。

一方面，提供一种基于签约流程的数据处理方法，该方法包括：

接收节点服务请求，所述节点服务请求用于请求执行目标签约流程中目标操作节点的目标服务功能；

根据所述节点服务请求中携带的场景参数，匹配所述目标服务功能对应的服务场景，并根据所述服务场景对应的场景配置文件，从所述节点服务请求中，提取请求参数集合；

根据所述服务场景对应的服务逻辑文件，对所述目标服务功能进行服务编排，获得执行所述目标服务功能所需调用的基础服务序列；

依次调用所述基础服务序列中的各个基础服务，其中调用每个基础服务时，从所述请求参数集合中获得所述每个基础服务对应的至少一个请求参数，并基于所述至少一个请求参数发起所述每个基础服务的服务调用；

在所述基础服务序列调用完成时，获得所述节点服务请求对应的服务响应。

一方面，提供一种基于签约流程的数据处理装置，该装置包括：

接收单元，用于接收节点服务请求，所述节点服务请求用于请求执行目标签约流程中目标操作节点的目标服务功能；

场景匹配单元，用于根据所述节点服务请求中携带的场景参数，匹配所述目标服务功能对应的服务场景，并根据所述服务场景对应的场景配置文件，从所述节点服务请求中，提取请求参数集合；

服务编排单元，用于根据所述服务场景对应的服务逻辑文件，对所述目标服务功能进行服务编排，获得执行所述目标服务功能所需调用的基础服务序列；

服务调用单元，用于依次调用所述基础服务序列中的各个基础服务，其中调用每个基础服务时，从所述请求参数集合中获得所述每个基础服务对应的至少一个请求参数，并基于所述至少一个请求参数发起所述每个基础服务的服务调用；

响应获得单元，用于在所述基础服务序列调用完成时，获得所述节点服务请求对应的服务响应。

在一种可能的实施方式中，该装置还包括转换单元，用于：

根据场景配置文件中配置的数据标准化方式，对请求参数集合中各个请求参数进行数据标准化操作，获得标准原子数据项集合；

则服务调用单元，具体用于：从标准原子数据项集合中，获得每个基础服务对应的至少一个标准原子数据项，至少一个标准原子数据项是对至少一个请求参数标准化操作得到的；以及，将至少一个标准原子数据项转换为每个基础服务对应的请求参数子集，并基于请求参数子集发起一个基础服务的服务调用。

在一种可能的实施方式中，转换单元，具体用于：

针对请求参数集合中每个请求参数，分别执行如下操作：

确定每个请求参数是否为原子类型参数，原子类型参数具有不可拆分特性；

若每个请求参数为原子类型参数，则根据数据标准化方式，对每个请求参数进行数据标准化操作，获得每个请求参数对应的标准原子数据项；

若每个请求参数为非原子类型参数，对每个请求参数进行拆分，获得多个请求子参数，并分别对多个请求子参数进行数据标准化操作，获得多个请求子参数各自对应的标准原子数据项。

在一种可能的实施方式中，场景配置文件包括原子类型参数与原子数据项标识之间的第一对应关系；则转换单元，具体用于：

若每个请求参数为原子类型参数，根据第一对应关系，确定将每个请求参数的目标关键字所对应的目标原子数据项标识；

基于服务场景的场景标识、目标原子数据项标识以及每个请求参数的参数值，获得每个请求参数对应的标准原子数据项。

在一种可能的实施方式中，场景配置文件包括非原子类型参数拆分后的各个请求子参数与原子数据项标识集合之间的第二对应关系；则转换单元，具体用于：

针对多个请求子参数中每个请求子参数，分别执行如下操作：

根据第二对应关系，确定将每个请求子参数的目标关键字所对应的目标原子数据项标识；

基于服务场景的场景标识、目标原子数据项标识以及每个请求子参数的参数值，获得每个请求子参数对应的标准原子数据项。

在一种可能的实施方式中，服务调用单元，具体用于：

针对至少一个标准原子数据项中每个标准原子数据项，分别执行如下操作，以获得请求参数子集：

确定每个标准原子数据项是否为组装类型数据项，组装类型数据项的标准原子数据项对应的请求参数为非原子类型参数；

若每个标准原子数据项为组装类型数据项，则将每个标准原子数据项转换为相应的请求子参数，进而对关联的请求子参数进行组装，获得相应的请求参数；

若每个标准原子数据项为非组装类型数据项，则将每个标准原子数据项转换为相应的请求参数。

在一种可能的实施方式中，该装置还包括配置单元，用于：

接收目标签约流程的流程创建请求，流程创建请求携带目标签约流程的流程配置文件，以及目标签约流程包括的各个操作节点各自对应的场景配置文件以及服务逻辑文件，其中，各个操作节点为均与操作节点库中的操作节点不同；

将流程配置文件配置至签约流程库中，并建立流程配置文件与目标签约流程之间的关联关系；

分别将各个操作节点各自对应的场景配置文件配置至场景配置库中，并建立场景配置文件与相应的操作节点之间的关联关系；

分别将各个操作节点各自对应的服务逻辑文件配置至服务逻辑库中，并建立服务逻辑文件与相应的操作节点之间的关联关系。

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

一方面，提供一种计算机存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任一种方法的步骤。

一方面，提供一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机程序，处理器执行该计算机程序，使得该计算机设备执行上述任一种方法的步骤。

本申请实施例提供了一种基于签约流程的数据处理方法，该方法在接收请求执行目标签约流程中目标操作节点的目标服务功能的节点服务请求后，则根据节点服务请求中携带的场景参数，匹配目标服务功能对应的服务场景，并根据服务场景对应的场景配置文件，从节点服务请求中，提取请求参数集合，进而根据服务场景对应的服务逻辑文件，对目标服务功能进行服务编排，获得执行目标服务功能所需调用的基础服务序列，并依次调用基础服务序列中的各个基础服务，其中调用每个基础服务时，从请求参数集合中获得每个基础服务对应的至少一个请求参数，并基于至少一个请求参数发起每个基础服务的服务调用，最终在基础服务序列调用完成时，获得节点服务请求对应的服务响应。

因此，对于一个签约流程而言，可以实现自动根据场景配置文件匹配服务场景，以及根据服务逻辑文件自动按序调用相关的基础服务，以实现该目标操作节点的目标服务功能，因而在新增一个签约流程，则只需要配置该签约流程的相关配置文件即可，例如场景配置文件以及服务逻辑文件等，则可以通过上述的数据处理方法来实现相应功能，而无需重新开发该签约流程，降低了签约服务功能的繁琐程度，提升业务实现效率。

附图说明

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

图1为相关技术中的签约服务模型；

图2为本申请实施例提供的应用场景示意图；

图3A为本申请实施例提供的签约流程示意图；

图3B为本申请实施例提供的交易引擎的架构示意图；

图4为本申请实施例提供的流程创建过程的流程示意图；

图5为本申请实施例提供的可能的创建签约流程页面的示意图；

图6为本申请实施例提供的基于签约流程的数据处理方法的流程示意图；

图7为本申请实施例提供的请求参数转换为标准原子数据项的流程示意图；

图8为本申请实施例提供的标准原子数据转换为请求参数或者响应参数的流程示意图；

图9为本申请实施例提供的基于签约流程的数据处理装置的一种结构示意图；

图10为本申请实施例提供的计算机设备的组成结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

可以理解的是，当本申请的各实施例运用到具体产品或技术中时，需要获得相关许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

为便于理解本申请实施例提供的技术方案，这里先对本申请实施例使用的一些关键名词进行解释：

服务请求：用于请求完成某个服务，例如请求完成签约身份合法性检查服务、风险评估测试服务、签约信息检查服务、签约服务等。

服务编排：因为服务编排是基于节点服务请求所触发的，因此也可以称为请求编排。一个服务或者请求的完成通常是由多个原子操作组成的，为了正确完成服务或者请求的意图，需要有序地执行各个原子操作，这个确定需要执行的原子操作以及排序的过程即为服务编排。例如，对于一个目标服务功能的实现，需要按序执行原子操作1～5，那么服务编排的过程则是针对目标服务功能从所有可选的原子操作中选取出原子操作1～5，并对其进行排序，生成目标服务功能的原子操作序列，后续按照该原子操作序列进行调度即可实现目标服务功能。

原子操作重排：原子操作经过不同的组合顺序，可以完成不同的目的，当需要实现新的服务功能时，则需要进行原子操作重排。

请求自动路由：在处理某个服务请求时，往往需要请求外部系统或者内部模块，请求自动路由则是指能够自动地将请求正确地转发到对应的外部系统或内部模块。对于一个服务功能而言，可能需要执行多个原子操作，一个原子操作可能为调用一次基础服务，那么一次基础服务的调用也可以认为是一个子请求，则请求自动路由也可以包括在调用基础服务时，将相应的子请求自动的转发到正确的基础服务所在的实体上。

原子数据：每个原子数据可以包括简单值数据类型，例如字符、字符串、数字等类型，也可以包括复杂数据类型，例如列表、数组、树形、图等结构。

标准原子数据项：一个标准原子数据项为系统中可复用的最小数据粒度，例如姓名、地址、身份证号等均可以作为一个标准原子数据项。

下面，对本申请实施例的技术思想进行简述。

相关技术中，在需要业务合同签订时，往往会涉及到签约流程，签约流程中的操作节点例如可以包括签约身份合法性检查、风险评估测试、签约信息检查、签约等，当然不同的业务涉及到的签约流程不同，则签约流程中涉及到的操作节点不同，且操作节点的实现过程也可能不同，因此目前在需要增加新的签约流程或者操作节点时，通常采用的方式是定制化开发的方式，显然这种方式过程较为繁琐，业务实现周期较长，使得业务实现效率低。

参见图1所示，为相关技术中的签约服务模型，请求方即为客户端，客户端请求聚合签约服务，聚合签约服务种提供许多功能，然后再由聚合签约服务调用基础服务，达到完成某个产品的功能。可以看到，由于不同的功能请求的基础服务不一样，请求基础服务的顺序也可能不一样，故新增一个功能，往往需要重新设计和建设聚合签约服务中的功能，也就是需要定制化设计和建设产品请求、聚合服务功能和聚合服务功能请求，从而存在重复建设、无法复用、搭建服务效率低、容错性差等问题。

因此，为了解决上述问题，本申请人基于相关技术的方案，发现为了正确完成产品所提供的功能，需要解决如下几个不同：

(1)请求路由不同：包括两个方面，第一是产品请求路由到聚合服务功能，不同的产品路由不同；第二是聚合服务种功能的请求路由到基础服务，不同功能路由到的基础服务不同。

(2)请求编排不同：不同的功能之间的区别可抽象为两点，第一是请求的基础服务类型不同，第二是请求基础服务的顺序不同。

(3)数据传递不同：不同产品的请求的数据不同，不同功能的请求的数据不同。

基于上述的考量，本申请实施例提供了一种基于签约流程的数据处理方法，在该方法中，在接收请求执行目标签约流程中目标操作节点的目标服务功能的节点服务请求后，则根据节点服务请求中携带的场景参数，匹配目标服务功能对应的服务场景，并根据服务场景对应的场景配置文件，从节点服务请求中，提取请求参数集合，进而根据服务场景对应的服务逻辑文件，对目标服务功能进行服务编排，获得执行目标服务功能所需调用的基础服务序列，并依次调用基础服务序列中的各个基础服务，其中调用每个基础服务时，从请求参数集合中获得每个基础服务对应的至少一个请求参数，并基于至少一个请求参数发起每个基础服务的服务调用，最终在基础服务序列调用完成时，获得节点服务请求对应的服务响应。

因此，对于一个签约流程而言，可以实现自动根据场景配置文件匹配服务场景，以及根据服务逻辑文件自动按序调用相关的基础服务，以实现该目标操作节点的目标服务功能，因而在新增一个签约流程，则只需要配置该签约流程的相关配置文件即可，例如场景配置文件以及服务逻辑文件等，则可以通过上述的数据处理方法来实现相应功能，而无需重新开发该签约流程，降低了签约服务功能的繁琐程度，提升业务实现效率。

下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

本申请实施例提供的方案可以适用于签约服务场景中，比如适用于银行等金融机构的产品签约场景中。如图2所示，为本申请实施例提供的一种应用场景示意图，在该场景中，可以包括终端设备201和服务器202。

终端设备201例如可以为手机、平板电脑(PAD)、笔记本电脑、台式电脑、智能电视、智能车载设备、智能可穿戴设备、智能电视以及飞行器等任意可以发起签约服务的设备。终端设备201可以安装有目标应用，目标应用具备发起签约流程的功能，例如可以为银行应用、购物应用、视频应用以及短视频应用等。本申请实施例涉及的应用可以是软件客户端，也可以是网页、小程序等客户端，服务器202则是与软件或是网页、小程序等相对应的服务器，不限制客户端的具体类型。服务器202例如可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、即内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云端服务器，但并不局限于此。

其中，服务器202可以包括一个或多个处理器、存储器以及与交互I/O接口等。此外，服务器202还可以配置数据库，可以用于存储实现签约流程所需的配置文件等。其中，服务器202的存储器中还可以存储本申请实施例提供的基于签约流程的数据处理方法中各自所需执行的程序指令，这些程序指令被处理器执行时能够用以实现本申请实施例提供的基于签约流程的数据处理的过程。

示例性的，在用户需要签约某种银行产品时，则银行的后台服务器需要执行一系列的签约流程来为用户签约该银行产品。例如，签约流程中包括对用户进行签约认证相关的操作节点，例如签约身份合法性检查、风险评估测试、签约信息检查等节点，还可以包括执行签约的操作节点，而每个操作的实现也是由一个个基础服务来实现的，例如对于签约身份合法性检查节点，则需要调用获得用户身份信息、获取合法条件以及比较二者来验证是否合法等基础服务来实现。那么当采用本申请实施例提供的基于签约流程的数据处理方法实现签约流程时，则银行一方只需要实现配置流程配置文件、场景配置文件以及服务逻辑文件等即可，在实际执行签约时，针对每一目标操作节点，则可以在接收请求执行目标签约流程中目标操作节点的目标服务功能的节点服务请求后，则根据节点服务请求中携带的场景参数，匹配目标服务功能对应的服务场景，并根据服务场景对应的场景配置文件，从节点服务请求中，提取请求参数集合，进而根据服务场景对应的服务逻辑文件，对目标服务功能进行服务编排，获得执行目标服务功能所需调用的基础服务序列，并依次调用基础服务序列中的各个基础服务，其中调用每个基础服务时，从请求参数集合中获得每个基础服务对应的至少一个请求参数，并基于至少一个请求参数发起每个基础服务的服务调用，最终在基础服务序列调用完成时，获得节点服务请求对应的服务响应。因此，无需重新开发该签约流程，降低了签约服务功能的繁琐程度，提升业务实现效率。

本申请实施例中，终端设备201和服务器202之间可以通过一个或者多个网络203进行直接或间接的通信连接。该网络203可以是有线网络，也可以是无线网络，例如无线网络可以是移动蜂窝网络，或者可以是无线保真(Wireless-Fidelity，WIFI)网络，当然还可以是其他可能的网络，本申请实施例对此不做限制。需要说明的是，图2所示只是举例说明，实际上终端设备和服务器的数量不受限制，在本申请实施例中不做具体限定。

参见图3A，图3A为本申请实施例提供的签约流程示意图，其中，签约流程由操作节点、流程流转过程以及节点间跳转条件组成，一个操作节点即为签约流程中的一个操作或者审批步骤，不同角色用户对当前节点完成相关操作后，将签约流程流转至下一操作节点。参见图3A所示，该签约流程由操作节点1～5组成，参见操作节点1，对于不同的操作结果，即“同意”和“拒绝”，则可以跳转至不同的操作节点，例如同意则跳转操作节点4，拒绝则跳转操作节点2，则对于每个操作节点的相关节点事务，也就是该节点的服务功能需要在交易引擎中进行配置以及处理。

本申请实施例提供的交易引擎也可以称为自动编排路由引擎，用于实现自动匹配服务场景，进行按照该服务场景的相关配置文件自动执行服务编排与调度来实现相应的服务功能。参见图3B所示，为本申请实施例提供的交易引擎的架构示意图，交易引擎接收到请求参数，经过场景解析器(亦可以称为场景解析模型)、元数据解析器(亦可以称为元数据解析模型)、服务编排器(亦可以称为服务编排模型)、服务转发解析器(亦可以称为服务转发解析模型)等进行处理后，最终返回对应的响应参数。

具体的，交易引擎上述各部分的介绍如下：

(1)场景解析器，用于在接收请求参数后，负责匹配服务场景，调用元数据解析器实现请求参数和标准原子数据项的互相转换等过程。如图3B所示，场景解析器相当于请求参数的接收单元，需要进行接收单元相关的元数据逻辑定义，元数据逻辑定义可以属于场景配置文件的一部分，用于指导进行匹配服务场景的过程以及匹配完成后在该服务场景下的数据逻辑。

(2)元数据解析器，用于实现请求参数和标准原子数据项的互相转换，以及响应参数和标准原子数据项的互相转换。元数据解析器需要为其配置相应的元数据定义，元数据定义也可以属于场景配置文件的一部分，用于指导参数和标准原子数据项的互相转换。图3B中的物理元数据是指基于物理结构存储的元数据，物理结构是指数据的逻辑结构在计算机中的存储形式。

(3)服务编排器，用于根据服务逻辑定义进行特定服务场景的服务编排，生成该服务场景对应的基础服务序列，并按照该基础服务序列进行基础服务的调度。服务逻辑定义也可以称为服务逻辑文件，其中定义了不同服务场景下的服务逻辑。

(4)服务转发解析器，用于按照服务编排器的调度，发起基础服务的调用。如图3B所示，服务转发解析器作为服务调用的发起方，相当于交易引擎的外呼单元，需要进行外呼单元相关的元数据逻辑定义，元数据逻辑定义也可以属于场景配置文件的一部分，用于指导进行该服务场景下发起调用时的转发数据的转换以及接收到的响应参数的转换数据逻辑。

下面，结合上述描述的应用场景和系统架构，参考附图来描述本申请示例性实施方式提供的方法，需要注意的是，上述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。

本申请实施例中，在创建一个签约流程，需要配置相关的配置文件，进而签约流程的流程控制以及签约流程中的操作节点的服务功能实现都需要在已配置的相关配置文件的基础上进行，因此这里先对配置的过程进行介绍。参见图4所示，为本申请实施例提供的流程创建过程的流程示意图，该过程可以包含如下步骤。

步骤401：终端设备发起目标签约流程的流程创建请求，服务器接收该流程创建请求。

本申请实施例提供了可以动态配置签约流程的方法，即需要新建一个目标签约流程时，则可以通过终端设备开启创建签约流程页面，参见图5所示，示出了一种可能的创建签约流程页面的示意图，在该页面中，可以包括签约流程相关的必要配置项，在逐一进行配置后，提交服务器实现目标签约流程的创建。除了图5所示的页面之外，还可以针对每个配置文件预先配置可选项，进而也可以不提供配置文件，而直接在创建页面上选择配置项实现签约流程的配置。

参见图5所示，针对一个签约流程，至少需要配置如下内容：

1、流程配置文件

流程配置文件用于指示目标签约流程中的操作节点、签约流程的流转过程以及节点间跳转条件等内容，操作节点即为目标签约流程中的操作或者审批步骤，不同角色用户完成相关操作后，将签约流程流转至下一操作节点。

具体的，流程配置文件可以配置如下内容：

(1)操作节点的配置，包括配置各个操作节点的名称、操作节点所需要调用的交易以及操作节点的操作权限等，这里提及的交易具体可以是指一个数据处理过程，例如调用基础服务进行的输出处理过程。

(2)操作节点之间的跳转条件的配置，比如针对一个操作节点，配置该操作节点需要完成某些输入项的输入或者完成交易请求后才可流转至下一操作节点。

(3)操作节点操作前后触发动作的配置，在许多签约场景中，可能需要在处理前请求外部数据，以及在处理后把操作结果同步给外部服务，则需要进行这些内容的触发动作的配置。

(4)流程中操作节点的配置，即需要配置节点处理前交易、处理后交易，处理中操作对应的交易，这些交易可以在交易引擎中配置，进而交易引擎得以根据配置内容处理操作节点的数据处理过程。

还需要说明的是，上述过程均是针对新建签约流程而言，而在实际过程中，当需要修改一个签约流程时，也可以通过修改配置文件的方式来进行，从而使得创建或者修改流程变得更加方便。而签约流程按流程节点的多少可以划分为长签约流程和短签约流程，相对于短签约流程，长签约流程涉及到的操作节点更多，节点间逻辑更为复杂，因此长签约流程的复杂度是更高的，那么长签约流程的开发过程显然更为繁琐，通过本申请实施例提供的动态配置的方法，即便是长签约流程，也可以更为方便的实现动态配置，提升了签约流程的配置效率。

2、场景配置文件

在场景配置文件中，可以配置签约流程的签约场景、以及该签约场景下涉及到的数据逻辑、参数(如请求参数和响应参数)与标准原子数据项之间的转换关系，以便于后续交易引擎中的相关部分可以基于此实现自身的功能。在一些实施例中，还可以按照不同的操作节点进行配置，一个操作节点可以认为是当前签约场景下的一个服务场景，用于实现在当前签约场景下一个服务功能。

3、服务逻辑文件

在服务逻辑文件中，可以定义签约场景下服务功能的执行逻辑，从而交易引擎中的服务编排器可以根据服务逻辑文件进行服务编排，以进行服务功能涉及到的基础服务的调度。

进而，当配置好相关的配置文件之后，则终端设备可以向服务器发起流程创建请求，并携带上述目标签约流程涉及到的流程配置文件，以及目标签约流程包括的各个操作节点各自对应的场景配置文件以及服务逻辑文件。当然，在实际应用时还可能涉及到其他的配置文件，则当包括其他的配置文件时，则流程创建请求同样可以携带这些配置文件，本申请实施例对此不做限制。

在一种可能的实施方式中，考虑到当操作节点相同时，是可以复用该操作节点的，例如当签约流程A和签约流程B均包括操作节点1时，则新建签约流程A时，则可以复用签约流程B的操作节点1，其中，在进行复用时，可以是复用操作节点1的部分内容，也可以是复用操作节点1的全部内容。那么，当可以用其他签约流程中的操作节点时，则流程创建请求中指示各个操作节点可以为新的操作节点，即与已有的操作节点库中的各个操作节点均不同。

步骤402：服务器将流程配置文件配置至签约流程库中，并建立流程配置文件与目标签约流程之间的关联关系。

具体的，服务器接收到流程配置文件之后，则可以将其配置到签约流程库中，并将其与目标签约流程建立关联关系，以使得后续处理目标签约流程的业务时，则可以根据关联关系找到流程配置文件，进而根据流程配置文件来控制目标签约流程的执行。

步骤403：服务器分别将各个操作节点各自对应的场景配置文件配置至场景配置库中，并建立场景配置文件与相应的操作节点之间的关联关系。

步骤404：服务器分别将各个操作节点各自对应的服务逻辑文件配置至服务逻辑库中，并建立服务逻辑文件与相应的操作节点之间的关联关系。

同样的，对于各个操作节点各自对应的场景配置文件以及服务逻辑文件，服务器也可以将其分别配置至各自对应的数据库中，并管理与相应的操作节点之间的关联关系，以使得后续处理相应操作节点的服务功能时，则可以根据关联关系找到场景配置文件以及服务逻辑文件，进而根据这些配置文件实现相应的服务功能。

在实际应用时，当处理目标签约流程时，则可以加载上述的流程配置文件进行相应的处理，并且当执行目标签约流程的操作节点的服务功能时，也可以将上述的场景配置文件以及服务逻辑文件加载到交易引擎中进行相应的处理。

参见图6所示，为本申请实施例提供的基于签约流程的数据处理方法的流程示意图，该方法可以由计算机设备执行，该计算机设备可以是图2所示的终端设备或服务器，该方法的具体实施流程如下：

步骤601：接收节点服务请求，节点服务请求用于请求执行目标签约流程中目标操作节点的目标服务功能。

本申请实施例中，当用户需要针对某种业务进行签约时，则会触发母校签约流程，目标操作节点可以为目标签约流程中的任意一个操作节点，也就是说，节点服务请求可以在终端设备发起目标签约流程时触发的，则该节点服务请求相当于目标签约流程的流程发起请求，相当于节点服务请求是用于请求执行目标签约流程中的第一个操作节点的服务功能；或者，节点服务请求还可以是在目标签约流程的流转过程中触发的，例如该节点服务请求可以是在上一个操作节点完成之后，需要跳转至下一个操作节点时发起的，则该节点服务请求可以是用于请求下一个操作节点的服务功能。

步骤602：根据节点服务请求中携带的场景参数，匹配目标服务功能对应的服务场景，并根据服务场景对应的场景配置文件，从节点服务请求中，提取请求参数集合。

本申请实施例中，为了正确的执行服务功能，需要正确的找到相应的配置文件，则可以采用不同的服务场景来表示不同的服务功能，一个服务功能则可以为一个服务场景。因此，在接收到节点服务请求之后，需要根据节点服务请求中携带的场景参数，来匹配当前的目标服务功能所对应的服务场景，该过程例如可以是上述交易引擎中的场景解析器来执行的。

在一种可能的实施方式中，可以为不同的操作节点赋予不同的标识(identity，ID)，则场景参数可以为操作节点的ID，进而在节点服务请求中可以携带相应的ID，进而与库中的各个场景参数进行匹配，来确定当前的服务场景。

在一种可能的实施方式中，一个签约流程可以为一个签约场景，而一个签约流程可以包括多个操作节点，一个操作节点可以用于实现一个服务功能，则一个服务场景通过签约流程和操作节点的标识综合进行限定，例如场景参数可以包括签约流程的ID和操作节点的ID，进而在节点服务请求中可以携带这两个ID，进而与库中的各个场景参数进行匹配，来确定当前的服务场景。

为了实现场景的匹配以及后续的数据项的转换，场景解析器需要与请求端均需要达成共识，需要做如下约定：

(1)约定请求的功能场景，功能场景即为需要请求的服务功能，比如订单查询、下单、支付等。

(2)约定功能场景下具有哪些key值，请求端发送key以及key对应的value，场景解析器解析约定的key以及key的value。

上述的约定均可以通过配置文件进行配置，也就是说，服务器和请求端都可以配置上述的内容。

具体的，确定当前的服务场景之后，场景解析器可以根据确定出的服务场景，找到对应的场景配置文件，并根据场景配置文件，从节点服务请求中，提取请求参数集合，进而基于这些请求参数集合执行后续的服务过程的相关过程。

在一种可能的实施方式中，为了交易引擎中数据的处理便捷性，需要将节点服务请求中请求参数的数据结构格式进行转换，来得到交易引擎能够处理和识别的数据结构格式，且转换后的标准原子数据项也能够提高交易引擎的数据处理效率。

具体的，场景解析器接收请求参数后，负责匹配场景以及负责请求参数和标准原子数据项的互转过程，因此，场景解析器在匹配到目标服务场景并获得相应的场景配置文件之后，还会根据场景配置文件中配置的数据标准化方式，对请求参数集合中各个请求参数进行数据标准化操作，获得标准原子数据项集合。其中，场景解析器来进行转换时，可以调用元数据解析器俩执行具体的转换过程。参见图7所示，为本申请实施例提供的请求参数转换为标准原子数据项的流程示意图。

步骤S11：匹配服务场景。

步骤S12：抽取场景下所有请求参数，得到请求参数集合。

进而，针对提取得到的请求参数集合中每个请求参数，分别执行以下操作，来将每个请求参数转换为标准原子数据项。其中，该过程可以通过遍历的方式来进行，也可以通过并行处理的方式来进行。图7中具体是以遍历为例进行说明的。

步骤S13：遍历请求参数集合中每个请求参数，确定参数类型，即是否为原子类型参数。

其中，原子类型参数具有不可拆分特性，即其为不可拆分的参数，例如身份证号、姓名等可以为原子类型参数，而非原子类型参数为还可以进一步拆分的参数。

步骤S14：若为原子类型参数，映射为标准原子数据项。

也就是说，若当前确定的请求参数为原子类型参数，则可以通过标准原子数据转换器，来根据数据标准化方式，对该请求参数进行数据标准化操作，获得该请求参数对应的标准原子数据项。

具体的，场景配置文件中可以包括原子类型参数与原子数据项标识之间的第一对应关系。参见图7所示，场景配置可以包括如下内容：

(1)场景ID。

(2)该服务场景下涉及到的参数key。

(3)该服务场景下涉及到的参数类型，例如原子类型列表、key-value数组等。

(4)key对应的标准原子数据项ID，即上述的第一对应关系，该内容可以在参数类型为原子类型参数时进行配置。

(5)key对应的拆分后标准原子数据项ID列表，即非原子类型参数拆分后的各个请求子参数与原子数据项标识集合之间的第二对应关系，该内容可以在参数类型为非原子类型参数时进行配置。

此外，考虑到同一个key在不同的服务场景中可能具有的意义不同，且为了标识不同服务场景下的key，还可以采用如图7所示的唯一性约束，即采用场景ID+参数key的形式进行约束。

则若该请求参数为原子类型参数，则可以根据第一对应关系，确定将该请求参数的目标关键字所对应的目标原子数据项标识，并基于服务场景的场景标识、目标原子数据项标识以及该请求参数的参数值，获得该请求参数对应的标准原子数据项。例如，第一对应关系可以包括姓名与ID之间的对应关系，则当请求参数的key为“姓名”时，则可以查找到对应的ID，例如为“1”来表征这一项参数。

步骤S15：若为非原子类型参数，映射为标准原子数据项列表。

也就是说，若当前确定的请求参数为非原子类型参数，则可以通过标准原子数据转换器，来对该请求参数进行拆分，获得多个请求子参数，并分别对多个请求子参数进行数据标准化操作，获得多个请求子参数各自对应的标准原子数据项。

具体的，如上所述，场景配置文件中可以包括非原子类型参数拆分后的各个请求子参数与原子数据项标识集合之间的第二对应关系，则进行拆分后，可以针对多个请求子参数中每个请求子参数，分别执行该操作：根据第二对应关系，确定将该请求子参数的目标关键字所对应的目标原子数据项标识，并基于服务场景的场景标识、目标原子数据项标识以及该请求子参数的参数值，获得每个请求子参数对应的标准原子数据项，进而各个请求子参数的标准原子数据项即组成上述的标准原子数据项列表。

步骤S16：遍历完成之后，则可以得到最终的标准原子数据列表，包括上述各个请求参数转换之后的标准原子数据项。

步骤603：根据服务场景对应的服务逻辑文件，对目标服务功能进行服务编排，获得执行目标服务功能所需调用的基础服务序列。

本申请实施例中，服务逻辑文件中定义了在目标服务功能的服务场景下的服务逻辑，即需要调用的基础服务以及服务之间的先后顺序，进而服务编排器可以按照该服务逻辑文件对目标服务功能进行服务编排，获得执行目标服务功能所需调用的基础服务序列，进而可以按照该基础服务序列俩调用目标服务功能的执行过程。

步骤604：依次调用基础服务序列中的各个基础服务，其中调用每个基础服务时，从请求参数集合中获得每个基础服务对应的至少一个请求参数，并基于至少一个请求参数发起每个基础服务的服务调用。

具体的，基础服务序列中包含了各个基础服务之间的执行顺序，则可以按照该顺序依次执行各个基础服务。且，在实际场景中，基础服务之间可能存在依赖关系，例如一个基础服务的输入依赖于上一次基础服务的输出，因此二者之间必须严格按照执行先后顺序进行。

在每次调用一个基础服务时，可能需要输出一些请求参数，而该请求参数可以为请求参数集合中的部分参数或者全部参数，进而可以基于确定出的每个基础服务所需的至少一个请求参数，来调用该基础服务。该过程可以是服务转发解析器来执行的，该服务转发解析器作为交易引擎的外呼单元，能够向其他的基础服务发起调用，以实现节点服务请求的自动路由。其中，该基础服务可以内部模块提供的，也可以是外部系统提供的，本申请实施例对此不做限制。

在一种可能的实施方式中，当场景解析器将请求参数转换为标准原子数据项集合时，则需要从标准原子数据项集合中，获得每个基础服务对应的至少一个标准原子数据项，至少一个标准原子数据项是对至少一个请求参数标准化操作得到的，并将至少一个标准原子数据项转换为每个基础服务对应的请求参数子集，并基于请求参数子集发起一个基础服务的服务调用。也就是说，在服务转发解析器发起调用时，则获取的实质上为标准原子数据项，则还需要对其进行转换为请求参数后，再基于请求参数来发起基础服务的调用。其中，服务转发解析器也可以调用元数据解析器来执行该转换过程。

参见图8所示，为本申请实施例提供的标准原子数据转换为请求参数或者响应参数的流程示意图。图8中具体是以转换为响应参数为例，当转换为请求参数是也是同理，请求参数与响应参数的不同则在于针对的对象不同，请求参数是指输入到交易引擎中的参数，响应参数是指数据处理过程得到的参数，在一些场景需要同步通知给其他服务系统。

步骤S21：输入待转换的响应参数标准原子数据列表后，匹配服务场景。

步骤S22：获取服务场景下响应参数配置。

对于上述的至少一个标准原子数据项中每个标准原子数据项，分别执行如下操作，来将每个标准原子数据项转换为相应的请求参数。其中，该过程可以通过遍历的方式来进行，也可以通过并行处理的方式来进行。图7中具体是以遍历为例进行说明的。

步骤S23：遍历请求参数集合中每个标准原子数据项，确定其参数类型，即是否为组装类型数据项。

其中，组装类型数据项的标准原子数据项对应的请求参数为非原子类型参数，也就是说，组装类型数据项是需要进行组装后得到请求参数或者响应参数的，实质上图8的转换过程即为上述图7的转换过程的逆向过程。

步骤S24：若为组装类型数据项，映射为key-value列表。

也就是说，若当前确定的标准原子数据项为组装类型数据项，则可以将其转换为相应的请求子参数或者响应子参数，进而将关联的请求子参数或者响应子参数组装起来，即得到相应的请求参数。这里以请求参数采用key-value形式为例，则每个组装类型数据项可以映射为一个key-value，多个关联的key-value则可以得到相应的key-value列表，该key-value列表即对应被拆分前的请求参数。

具体的，参见图8所示，对于标准原子数据转换为请求参数或者响应参数的场景配置可以包括如下内容：

(1)场景ID。

(2)该服务场景下涉及到的参数key。

(3)该服务场景下涉及到的参数类型，例如组装类型和非组装类型等。

(4)参数value对应的标准原子数据项，该内容可以在转换后的请求参数的参数类型为原子类型参数时进行配置。

(5)参数value对应的拆分后标准原子数据项列表，该内容可以在转换后的请求参数的参数类型为非原子类型参数时进行配置。

(6)响应参数类型or请求参数类型，即指示转换后的参数为请求参数还是响应参数。

步骤S25：若为非组装类型数据项，映射为key-value。

也就是说，若当前确定的标准原子数据项为非组装类型数据项，则可以直接转换得到相应的请求参数，也就是key-value。

步骤S26：遍历完成之后，则可以得到最终的key-value列表，包括上述各个标准原子数据项转换之后的key-value和key-value列表。

最终，基于转换之后得到的请求参数子集合发起基础服务的调用。

步骤605：在基础服务序列调用完成时，获得节点服务请求对应的服务响应。

在所有基础服务调用完成且成功时，则可以得到当前服务功能对应的数据处理结果，也就是节点服务请求对应的服务响应，则可以基于服务响应继续后续的签约流程。

下面，结合图3B的过程来对本申请实施例的技术方案进行介绍。

步骤1：场景解析器接收节点服务请求中的请求参数。

步骤2：场景解析器调用元数据解析器进行请求参数到标准原子数据项的转换。其中，转换过程需要借助于配置的元数据定义。

步骤3：元数据解析器向场景解析器返回转换结果。

步骤4：场景解析器将节点服务请求以及标原子数据项发送给服务编排器，请求服务编排器进行服务编排。其中，该过程场景解析器需要借助于配置的元数据逻辑定义来理解节点服务请求的意图。

步骤5：服务编排器根据服务逻辑定义进行服务编排后，依次请求服务转发解析器发起基础服务的调用。

步骤6：服务转发解析器按照服务编排器的指示，向基础服务发起调用。

步骤7：服务转发解析器获得基础服务返回的调用结果。

步骤8：服务转发解析器请求元数据解析器进行调用结果到标准原子数据项的转换。

步骤9：元数据解析器向服务转发解析器返回转换结果。

步骤10：服务转发解析器将调用结果的标准原子数据项发送给服务编排器。

步骤11：服务编排器确定是否整个流程是否执行完成，若没有则继续请求服务转发解析器发起后续的基础服务的调用。

步骤12：若已执行完成，则服务编排器将最终响应返回给场景解析器。

步骤13：场景解析器将最终响应输出。其中，该过程中需要将最终响应的标准原子数据项转换为响应参数后输出。

综上所述，本申请实施例提出了一种可动态配置和调整的签约流程处理方法，提出一种新的服务模式，从而达到一次建设，多签约场景复用，快速构建签约流程，具有高容错性和易搭建性。

请参见图9，基于同一发明构思，本申请实施例还提供了一种基于签约流程的数据处理装置90，该装置包括：

接收单元901，用于接收节点服务请求，节点服务请求用于请求执行目标签约流程中目标操作节点的目标服务功能；

场景匹配单元902，用于根据节点服务请求中携带的场景参数，匹配目标服务功能对应的服务场景，并根据服务场景对应的场景配置文件，从节点服务请求中，提取请求参数集合；

服务编排单元903，用于根据服务场景对应的服务逻辑文件，对目标服务功能进行服务编排，获得执行目标服务功能所需调用的基础服务序列；

服务调用单元904，用于依次调用基础服务序列中的各个基础服务，其中调用每个基础服务时，从请求参数集合中获得每个基础服务对应的至少一个请求参数，并基于至少一个请求参数发起每个基础服务的服务调用；

响应获得单元905，用于在基础服务序列调用完成时，获得节点服务请求对应的服务响应。

在一种可能的实施方式中，该装置还包括转换单元906，用于：

根据场景配置文件中配置的数据标准化方式，对请求参数集合中各个请求参数进行数据标准化操作，获得标准原子数据项集合；

则服务调用单元904，具体用于：从标准原子数据项集合中，获得每个基础服务对应的至少一个标准原子数据项，至少一个标准原子数据项是对至少一个请求参数标准化操作得到的；以及，将至少一个标准原子数据项转换为每个基础服务对应的请求参数子集，并基于请求参数子集发起一个基础服务的服务调用。

在一种可能的实施方式中，转换单元906，具体用于：

针对请求参数集合中每个请求参数，分别执行如下操作：

确定每个请求参数是否为原子类型参数，原子类型参数具有不可拆分特性；

若每个请求参数为原子类型参数，则根据数据标准化方式，对每个请求参数进行数据标准化操作，获得每个请求参数对应的标准原子数据项；

若每个请求参数为非原子类型参数，对每个请求参数进行拆分，获得多个请求子参数，并分别对多个请求子参数进行数据标准化操作，获得多个请求子参数各自对应的标准原子数据项。

在一种可能的实施方式中，场景配置文件包括原子类型参数与原子数据项标识之间的第一对应关系；则转换单元906，具体用于：

若每个请求参数为原子类型参数，根据第一对应关系，确定将每个请求参数的目标关键字所对应的目标原子数据项标识；

基于服务场景的场景标识、目标原子数据项标识以及每个请求参数的参数值，获得每个请求参数对应的标准原子数据项。

在一种可能的实施方式中，场景配置文件包括非原子类型参数拆分后的各个请求子参数与原子数据项标识集合之间的第二对应关系；则转换单元906，具体用于：

针对多个请求子参数中每个请求子参数，分别执行如下操作：

根据第二对应关系，确定将每个请求子参数的目标关键字所对应的目标原子数据项标识；

基于服务场景的场景标识、目标原子数据项标识以及每个请求子参数的参数值，获得每个请求子参数对应的标准原子数据项。

在一种可能的实施方式中，服务调用单元904，具体用于：

针对至少一个标准原子数据项中每个标准原子数据项，分别执行如下操作，以获得请求参数子集：

确定每个标准原子数据项是否为组装类型数据项，组装类型数据项的标准原子数据项对应的请求参数为非原子类型参数；

若每个标准原子数据项为组装类型数据项，则将每个标准原子数据项转换为相应的请求子参数，进而对关联的请求子参数进行组装，获得相应的请求参数；

若每个标准原子数据项为非组装类型数据项，则将每个标准原子数据项转换为相应的请求参数。

在一种可能的实施方式中，该装置还包括配置单元907，用于：

接收目标签约流程的流程创建请求，流程创建请求携带目标签约流程的流程配置文件，以及目标签约流程包括的各个操作节点各自对应的场景配置文件以及服务逻辑文件，其中，各个操作节点为均与操作节点库中的操作节点不同；

将流程配置文件配置至签约流程库中，并建立流程配置文件与目标签约流程之间的关联关系；

分别将各个操作节点各自对应的场景配置文件配置至场景配置库中，并建立场景配置文件与相应的操作节点之间的关联关系；

分别将各个操作节点各自对应的服务逻辑文件配置至服务逻辑库中，并建立服务逻辑文件与相应的操作节点之间的关联关系。

通过上述装置，可以实现自动根据场景配置文件匹配服务场景，以及根据服务逻辑文件自动按序调用相关的基础服务，以实现该目标操作节点的目标服务功能，因而在新增一个签约流程，则只需要配置该签约流程的相关配置文件即可，例如场景配置文件以及服务逻辑文件等，则可以通过上述的数据处理方法来实现相应功能，而无需重新开发该签约流程，降低了签约服务功能的繁琐程度，提升业务实现效率。

该装置可以用于执行本申请各实施例中所示的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考前述实施例的描述，不多赘述。

请参见图10，基于同一技术构思，本申请实施例还提供了一种计算机设备。在一种实施例中，该计算机设备例如可以为图1所示的服务器，该计算机设备如图10所示，包括存储器1001，通讯模块1003以及一个或多个处理器1002。

存储器1001，用于存储处理器1002执行的计算机程序。存储器1001可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统，以及运行本申请实施例的功能所需的程序等；存储数据区可存储各种功能信息和操作指令集等。

存储器1001可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器1001也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；或者存储器1001是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1001可以是上述存储器的组合。

处理器1002，可以包括一个或多个中央处理单元(central processing unit，CPU)或者为数字处理单元等等。处理器1002，用于调用存储器1001中存储的计算机程序时实现上述基于签约流程的数据处理方法。

通讯模块1003用于与终端设备和其他服务器进行通信。

本申请实施例中不限定上述存储器1001、通讯模块1003和处理器1002之间的具体连接介质。本申请实施例在图10中以存储器1001和处理器1002之间通过总线1004连接，总线1004在图10中以粗线描述，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线1004可以分为地址总线、数据总线、控制总线等。为便于描述，图10中仅用一条粗线描述，但并不描述仅有一根总线或一种类型的总线。

存储器1001中存储有计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于实现本申请实施例的基于签约流程的数据处理方法，处理器1002用于执行上述各实施例的基于签约流程的数据处理方法。

基于同一发明构思，本申请实施例还提供一种计算机存储介质，该计算机存储介质存储有计算机程序，当该计算机程序在计算机设备上运行时，使得计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的基于签约流程的数据处理方法中的步骤。

在一些可能的实施方式中，本申请提供的基于签约流程的数据处理方法的各个方面还可以实现为一种计算机程序产品的形式，其包括计算机程序，当该计算机程序产品在计算机设备上运行时，计算机程序用于使计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的基于签约流程的数据处理方法中的步骤，例如，计算机设备可以执行各实施例的步骤。

该计算机程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请的实施方式的计算机程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括计算机程序，并可以在计算机设备上运行。然而，本申请的计算机程序产品不限于此，在本申请件中，可读存储介质可以是任何包含或存储程序的有形介质，其包括的计算机程序可以被命令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由命令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的计算机程序，程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机程序的计算机存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

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

Claims (12)

1.一种基于签约流程的数据处理方法，其特征在于，所述方法包括：

接收节点服务请求，所述节点服务请求用于请求执行目标签约流程中目标操作节点的目标服务功能；

根据所述节点服务请求中携带的场景参数，匹配所述目标服务功能对应的服务场景，并根据所述服务场景对应的场景配置文件，从所述节点服务请求中，提取请求参数集合；

根据所述服务场景对应的服务逻辑文件，对所述目标服务功能进行服务编排，获得执行所述目标服务功能所需调用的基础服务序列；

依次调用所述基础服务序列中的各个基础服务，其中调用每个基础服务时，从所述请求参数集合中获得所述每个基础服务对应的至少一个请求参数，并基于所述至少一个请求参数发起所述每个基础服务的服务调用；

在所述基础服务序列调用完成时，获得所述节点服务请求对应的服务响应。

2.如权利要求1所述的方法，其特征在于，在根据所述服务场景对应的场景配置文件，从所述节点服务请求中，提取请求参数集合之后，所述方法还包括：

根据所述场景配置文件中配置的数据标准化方式，对所述请求参数集合中各个请求参数进行数据标准化操作，获得标准原子数据项集合；

则所述从所述请求参数集合中获得所述每个基础服务对应的至少一个请求参数，并基于所述至少一个请求参数发起所述每个基础服务的服务调用，包括：

从所述标准原子数据项集合中，获得所述每个基础服务对应的至少一个标准原子数据项，所述至少一个标准原子数据项是对所述至少一个请求参数标准化操作得到的；

将所述至少一个标准原子数据项转换为所述每个基础服务对应的请求参数子集，并基于所述请求参数子集发起所述一个基础服务的服务调用。

3.如权利要求2所述的方法，其特征在于，根据所述场景配置文件中配置的数据标准化方式，对所述请求参数集合中各个请求参数进行数据标准化操作，获得标准原子数据项集合，包括：

针对所述请求参数集合中每个请求参数，分别执行如下操作：

确定所述每个请求参数是否为原子类型参数，所述原子类型参数具有不可拆分特性；

若所述每个请求参数为原子类型参数，则根据所述数据标准化方式，对所述每个请求参数进行数据标准化操作，获得所述每个请求参数对应的标准原子数据项；

若所述每个请求参数为非原子类型参数，对所述每个请求参数进行拆分，获得多个请求子参数，并分别对所述多个请求子参数进行数据标准化操作，获得所述多个请求子参数各自对应的标准原子数据项。

4.如权利要求3所述的方法，其特征在于，所述场景配置文件包括原子类型参数与原子数据项标识之间的第一对应关系；

则若所述每个请求参数为原子类型参数，则根据所述数据标准化方式，对所述每个请求参数进行数据标准化操作，获得所述每个请求参数对应的标准原子数据项，包括：

若所述每个请求参数为原子类型参数，根据所述第一对应关系，确定将所述每个请求参数的目标关键字所对应的目标原子数据项标识；

基于所述服务场景的场景标识、所述目标原子数据项标识以及所述每个请求参数的参数值，获得所述每个请求参数对应的标准原子数据项。

5.如权利要求3所述的方法，其特征在于，所述场景配置文件包括非原子类型参数拆分后的各个请求子参数与原子数据项标识集合之间的第二对应关系；

则所述分别对所述多个请求子参数进行数据标准化操作，获得所述多个请求子参数各自对应的标准原子数据项，包括：

针对所述多个请求子参数中每个请求子参数，分别执行如下操作：

根据所述第二对应关系，确定将所述每个请求子参数的目标关键字所对应的目标原子数据项标识；

基于所述服务场景的场景标识、所述目标原子数据项标识以及所述每个请求子参数的参数值，获得所述每个请求子参数对应的标准原子数据项。

6.如权利要求2～5任一所述的方法，其特征在于，所述将所述至少一个标准原子数据项转换为所述每个基础服务对应的请求参数子集，包括：

针对所述至少一个标准原子数据项中每个标准原子数据项，分别执行如下操作，以获得所述请求参数子集：

确定所述每个标准原子数据项是否为组装类型数据项，所述组装类型数据项的标准原子数据项对应的请求参数为非原子类型参数；

若所述每个标准原子数据项为组装类型数据项，则将所述每个标准原子数据项转换为相应的请求子参数，进而对关联的请求子参数进行组装，获得相应的请求参数；

若所述每个标准原子数据项为非组装类型数据项，则将所述每个标准原子数据项转换为相应的请求参数。

7.如权利要求1～5任一所述的方法，其特征在于，在根据所述节点服务请求中携带的场景参数，匹配所述目标服务功能对应的服务场景之前，所述方法还包括：

接收所述目标签约流程的流程创建请求，所述流程创建请求携带所述目标签约流程的流程配置文件，以及所述目标签约流程包括的各个操作节点各自对应的场景配置文件以及服务逻辑文件，其中，所述各个操作节点为均与操作节点库中的操作节点不同；

将所述流程配置文件配置至签约流程库中，并建立所述流程配置文件与所述目标签约流程之间的关联关系；

分别将所述各个操作节点各自对应的场景配置文件配置至场景配置库中，并建立所述场景配置文件与相应的操作节点之间的关联关系；

分别将所述各个操作节点各自对应的服务逻辑文件配置至服务逻辑库中，并建立所述服务逻辑文件与相应的操作节点之间的关联关系。

8.一种基于签约流程的数据处理装置，其特征在于，所述装置包括：

接收单元，用于接收节点服务请求，所述节点服务请求用于请求执行目标签约流程中目标操作节点的目标服务功能；

场景匹配单元，用于根据所述节点服务请求中携带的场景参数，匹配所述目标服务功能对应的服务场景，并根据所述服务场景对应的场景配置文件，从所述节点服务请求中，提取请求参数集合；

服务编排单元，用于根据所述服务场景对应的服务逻辑文件，对所述目标服务功能进行服务编排，获得执行所述目标服务功能所需调用的基础服务序列；

服务调用单元，用于依次调用所述基础服务序列中的各个基础服务，其中调用每个基础服务时，从所述请求参数集合中获得所述每个基础服务对应的至少一个请求参数，并基于所述至少一个请求参数发起所述每个基础服务的服务调用；

响应获得单元，用于在所述基础服务序列调用完成时，获得所述节点服务请求对应的服务响应。

9.如权利要求8所述的装置，其特征在于，所述装置还包括转换单元，用于：

根据所述场景配置文件中配置的数据标准化方式，对所述请求参数集合中各个请求参数进行数据标准化操作，获得标准原子数据项集合；

则所述服务调用单元，具体用于：从所述标准原子数据项集合中，获得所述每个基础服务对应的至少一个标准原子数据项，所述至少一个标准原子数据项是对所述至少一个请求参数标准化操作得到的；以及，将所述至少一个标准原子数据项转换为所述每个基础服务对应的请求参数子集，并基于所述请求参数子集发起所述一个基础服务的服务调用。

10.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，

所述处理器执行所述计算机程序时实现权利要求1至7任一项所述方法的步骤。

11.一种计算机存储介质，其上存储有计算机程序，其特征在于，

该计算机程序被处理器执行时实现权利要求1至7任一项所述方法的步骤。

12.一种计算机程序产品，包括计算机程序，其特征在于，

该计算机程序被处理器执行时实现权利要求1至7任一项所述方法的步骤。