服务调用流程信息处理方法、装置及电子设备与流程

本申请涉及服务调用流程信息处理技术领域，特别是涉及服务调用流程信息处理方法、装置及电子设备。

背景技术：

在“新零售”等线上线下相结合的业务模式下，零售商可以通过线上的应用程序(app)提供商品对象的信息，用户可以通过线上的app进行浏览、购买等行为。同时，零售商还可以开设线下的实体店铺，用户也可以通过线下的实体店铺进行商品对象的购买。同时，线上的订单也可以由线下的实体店铺进行发货等一系列的处理，并最终配送到用户指定的收货地址。但是，有些零售商可能受限于自身的资源或者能力，无法为用户提供完善的发货、配送等服务，甚至在具体进行商品的上架等处理时，也可能存在一些困难，导致效率低下，出错率高等情况。为了使得这种零售商也能够加入到“新零售”系统中，“新零售”平台方可以为零售商提供一些服务，例如，标准化的流程处理服务，零售商可以通过采购平台方的服务，来完善线上线下相结合的销售链路。例如，某零售商可以采购“上架”服务，此时，平台方可以为该零售商提供相对应的解决方案，等等。

通常，具体业务链路上的服务可以是由平台方来提供，但是，随着系统的发展，越来越多的外部商家需要与“新零售”平台进行合作。例如，某外部商家也能够提供“上架”服务，也希望加入到“新零售”系统中，使得其他零售商也可以采购该外部商家提供的服务来解决某类问题，进而，使得这种外部商家也能够通过销售这种服务的方式，来作为另一种收入来源。

但是，能够提供上述业务链路上相关服务的商家，其内部通常也会使用具体的erp系统来实现各种信息、数据的管理。例如，商家a内部使用了一种erp系统，其内部在具体实现商品上架处理时，采用的具体方式方法，与“新零售”系统平台方默认的上架处理的方法可能是不同的。此时，外部商家接入平台时，可能会希望继续沿用自己内部惯用的处理方式，而不是统一使用平台方的方案，后者需要对外部商家内部的软硬件系统进行改造升级，成本会比较高。

因此，如何灵活的支持业务场景，快速、低成本的进行新商家的接入，成为需要本领域技术人员解决的技术问题。

技术实现要素：

本申请提供了服务调用流程信息处理方法、装置及电子设备，能够灵活的支持业务场景，快速、低成本的进行新商家的接入的同时，实现工作流模式与状态机模式的兼容。

本申请提供了如下方案：

一种服务调用流程信息处理方法，包括：

根据接收到的创建请求，创建流程实例，所述流程实例中包括多个节点，以及至少一个触发事件，所述触发事件用于触发从一个节点切换为下一个节点；

为所述流程提供可配置对象，所述可配置对象包括所述节点以及所述触发事件，以便为针对所述流程实例中的节点和/或触发事件进行任务配置；

其中，所述配置的任务中包括所需调用的服务接口标识，以及用于定位该服务接口下的服务实现的参数信息；所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的，服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

一种服务调用流程信息处理方法，包括：

接收客户端创建的流程实例，以及针对所述流程实例中的节点和/或触发事件配置的任务信息，其中，所述配置的任务中包括所需调用的服务接口标识，以及用于定位该服务接口下的服务实现的参数信息；所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；

为所述调用流程实例提供标识信息；

提供工具包信息，以便服务调用方通过所述工具包，对所述标识信息对应的流程实例进行操作，在执行所述流程实例的过程中，通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

一种服务调用流程信息处理方法，包括：

在服务调用方执行指定流程的过程中，根据所述流程对应的任务中指定的服务接口标识以及调用参数信息，定位到待调用的目标服务实现；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；

根据所述任务对应的流程实例中的配置对象类别信息，确定流程引擎的工作模式；

返回该目标服务实现对应的服务地址，以便所述服务调用方客户端向所述服务地址发起调用。

一种服务调用流程信息处理装置，包括：

流程实例创建单元，用于根据接收到的创建请求，创建流程实例，所述流程实例中包括多个节点，以及至少一个触发事件，所述触发事件用于触发从一个节点切换为下一个节点；

可配置对象提供单元，用于为所述流程提供可配置对象，所述可配置对象包括所述节点以及所述触发事件，以便为针对所述流程实例中的节点和/或触发事件进行任务配置；

其中，所述配置的任务中包括所需调用的服务接口标识，以及用于定位该服务接口下的服务实现的参数信息；所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的，服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

一种服务调用流程信息处理装置，包括：

流程实例接收单元，用于接收客户端创建的流程实例，以及针对所述流程实例中的节点和/或触发事件配置的任务信息，其中，所述配置的任务中包括所需调用的服务接口标识，以及用于定位该服务接口下的服务实现的参数信息；所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；

标识提供单元，用于为所述调用流程实例提供标识信息；

工具包提供单元，用于提供工具包信息，以便服务调用方通过所述工具包，对所述标识信息对应的流程实例进行操作，在执行所述流程实例的过程中，通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

一种服务调用流程信息处理装置，包括：

服务定位单元，用于在服务调用方执行指定流程的过程中，根据所述流程对应的任务中指定的服务接口标识以及调用参数信息，定位到待调用的目标服务实现；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；

工作模式确定单元，用于根据所述任务对应的流程实例中的配置对象类别信息，确定流程引擎的工作模式；

服务地址返回单元，用于返回该目标服务实现对应的服务地址，以便所述服务调用方客户端向所述服务地址发起调用。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

根据接收到的创建请求，创建流程实例，所述流程实例中包括多个节点，以及至少一个触发事件，所述触发事件用于触发从一个节点切换为下一个节点；

为所述流程提供可配置对象，所述可配置对象包括所述节点以及所述触发事件，以便为针对所述流程实例中的节点和/或触发事件进行任务配置；

其中，所述配置的任务中包括所需调用的服务接口标识，以及用于定位该服务接口下的服务实现的参数信息；所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的，服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

在服务调用方执行指定流程的过程中，根据所述流程对应的任务中指定的服务接口标识以及调用参数信息，定位到待调用的目标服务实现；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；

根据所述任务对应的流程实例中的配置对象类别信息，确定流程引擎的工作模式；

返回该目标服务实现对应的服务地址，以便所述服务调用方客户端向所述服务地址发起调用。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，由于是通过将商品对象服务流程中的标准作业程序流程按照逻辑节点粒度进行拆分并抽象后进行定义的服务接口，然后针对该服务接口提供服务实现，使得流程中不同节点对应的服务实现之间实现相互独立，并提供了相应的流程引擎，可以路由到具体的服务实现层级，从而使得各个服务实现可以单独开发，单独部署，单独被调用。在上述实现架构的基础上，在具体对服务接口进行编码调用的过程中，可以通过创建流程实例以及任务的方式来实现，其中，流程实例中的可配置对象可以是节点，也可以是事件，能够兼容工作流模式以及状态机模式，从而能够在不同业务场景下使用多种不同的表达方式，对服务接口进行编排。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的系统的示意图；

图2-1是工作流模式流程图；

图2-2是状态机模式流程图；

图2-3是本申请实施例提供的工作流模式与状态机模式兼容的流程图

图3是本申请实施例提供的第一方法的流程图；

图4-1、4-2是本申请实施例提供的任务配置示意图；

图5是本申请实施例提供的第二方法的流程图；

图6是本申请实施例提供的第三方法的流程图；

图7是本申请实施例提供的第一装置的示意图；

图8是本申请实施例提供的第二装置的示意图；

图9是本申请实施例提供的第三装置的示意图；

图10是本申请实施例提供的电子设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

首先需要说明的是，在“新零售”等线上与线下相结合的服务模式下，业务场景复杂，业务链路很长，实现了一整套从供应链到用户端的中台系统。在此过程中，服务平台中的业务方经常需要处理多种标准作业流程。例如，对于面向消费者的业务方，可能会涉及到处理下单流程，发货流程等。而对于面向商家的业务方，则可能更需要处理上架流程，仓调货流程，仓补货流程，仓配送流程，修改商品价格流程等等。其中，每个流程中都可能包括多个业务逻辑节点，例如，对于商品上架流程，其中包括了拣货->打包->装箱->上架等多个节点。

现有技术中，平台方是使用了基于应用的开发模式，开发者按照应用维度进行代码开发，使得一个应用中通常包含了一个具体流程中的多个节点的实现。例如，对于前述例子中的商品上架流程，其中包括了拣货->打包->装箱->上架等多个节点，在现有技术中，会将上述流程中各个节点上的实现代码组合在一起，绑定在同一个单元里，一起开发，一起部署，一起对外提供服务。此时，假设对于上述流程中的打包服务，除了平台方能够提供相应的实现之外，另外还有两个合作的商家a、b，也能够提供各自的实现，则需要加入到上述流程中时，但是原有的流程上的实现可能就无法满足新商家的需求。比如：原流程为start->节点a->节点b->节点c->end。当有一个新商家需要加入流程时，“节点a”对应的服务实现是按照平台的默认方式来实现的，无法满足该商家a的需求，需要基于对节点a节点新增一个实现方式：“a服务的实现2”。此时，如果按照传统的流程引擎，可以有以下几种方案：方案1：重新定义一个新流程，依旧包含“start->节点a->节点b->节点c->end”，修改“服务a”的实现方式为“a服务的实现2”。方案2：使用原流程，但需要修改流程对应的代码，在代码中写条件语句，用以判断选择哪个调用服务，也即硬编码方式。方案3：在原流程的基础上，新增分支流程，即新增选择节点，在选择节点上增加判断条件，同时，新增条件对应的选项，通过判断条件选择调用哪个服务。这三种方案各有缺陷：方案1，需要维护多套流程，维护成本高。一旦流程模板进行了修改，对应的所有流程均需要进行修改。方案2，业务逻辑依赖代码来实现，一旦有新流程接入，就需要对流程对应的代码进行修改，这是一种侵入式的实现方式，每次修改均需进行代码发布，发布风险高，且逻辑在代码中对于非技术人员不友好。方案3，一旦有新商家接入，都需要修改流程配置，无法保持一个相对稳态的流程。

而在本申请实施例中，为了能够更灵活地支持业务场景，快速、低成本的进行新商家的接入，如图1所示，首先可以将“新零售”等服务平台中的标准作业程序流程以节点为单位，抽象出标准服务接口(在本申请实施例中可以称为spi)，并提供第一系统101，可以用于对具体的服务接口进行定义，并进行注册；之后，可以将这种服务接口的定义信息提供给具体的服务提供方(例如，服务平台本身，或者其他的外部商家等，在本申请实施例中，称为第三系统103)，服务提供方则可以按照具体的服务对应的标准作业接口规范，提供具体的服务实现(在本申请实施例中可以称为bundle)。也就是说，在本申请实施例中，具体流程上的业务逻辑节点不再对应某一个固定的具体实现，而是以接口的形式存在，在定义服务接口时，只需要定义其入参、出参、功能等，而无需提供具体的实现代码。换言之，一个服务接口只需要定义出对应何种功能，需要哪些入参，哪些出参，而不需要提供具体的实现代码。具体的服务提供方则可以为具体的服务接口提供多种不同的服务实现，例如，对于“拣货”这种服务接口，在服务接口级别，无需确定具体如何实现拣货功能，但是，商家a能够提供具体的拣货服务，则可以为该服务接口提供具体的服务实现代码，也即，由商家a根据该商家a的具体拣货实现逻辑，提供关于该拣货服务的服务实现代码。另外，如果商家b也能够提供具体的拣货服务，则也可以根据该商家b内部的具体拣货实现逻辑，提供对应的拣货服务实现代码。通过这种方式，使得业务流程中的不同节点之间实现相互解耦，不同节点上的服务实现可以独立开发，独立部署，独立对外提供服务。并且，对于同一服务接口而言，可以由多个不同的服务提供方提供多种不同的服务实现代码，分别注册到流程引擎子系统中，使得同一个服务接口可以有“多态”实现。

也就是说，在本申请实施例中，可以由平台方抽象出具体的服务接口，然后由服务提供方提供具体的服务实现代码，每个服务提供方的服务实现代码都可以是按照服务提供方内部erp(企业管理计划)系统中的服务实现逻辑来进行开发的。另外，具体的服务提供方所提供的服务实现代码，可以直接保存在服务提供方自己的服务器上，后续在被具体的服务调用方调用时，这种服务实现代码也可以在服务提供方自己的服务器上运行，按照服务提供方内部的实现逻辑来执行具体的操作，并将处理结果返回给服务调用方。

在通过上述方式进行了服务接口的抽象及定义，并为具体的服务接口提供了至少一个服务实现之后，服务调用方(例如，具体的业务方，等等，在本申请实施例中，可以称为第二系统102)则可以通过具体的服务接口调用该服务接口下的其中一个具体的服务实现，以此获得相应的服务。服务调用方在具体进行服务调用时，可以指定所需调用的服务的id或者名称，还可以对具体所需服务实现的信息进行指定，再由具体的流程引擎系统将具体的调用请求路由到具体某个服务实现对应的服务地址。其中，具体在进行服务实现的指定时，可以在调用代码中设定具体的参数信息。为了便于服务调用方进行调用参数的设定，服务提供方在提供服务实现代码时，还可以设定具体的路由规则。例如，可以一种形式下，可以直接指定具体的服务实现的id或者名称等标识信息，使得流程引擎能够直接通过服务实现的id或名称定位到具体所需调用的服务实现代码。或者，另一种实现形式下，还可以通过正则运算等方式来进行指定，此时，具体传入的参数可以是一些间接的信息，例如，可以是仓库类型，仓库id等信息，然后通过正则运算的方式定位到具体的服务实现代码。

例如，在某“新零售”模式的服务系统中，为了能够在该系统的标准业务链路上，为系统的标准服务接入不同合作方的erp系统，实现某一服务节点的多样化，本申请实施例针对具体业务链路上的每一种服务进行抽象，定义服务的标准接口，可以称之为spi，例如，包括拣货服务接口，打包服务接口，上架服务接口，等等。将服务的具体实现，称之为bundle，一个spi可以有多个bundle实现，做到服务实现的多态化。比如，在前述商品上架流程中，包括的拣货，打包，装箱，上架这四个节点，则在本申请实施例中，可以抽象为四个服务接口，分别为拣货服务接口，打包服务接口，装箱服务接口，上架服务接口。其中，拣货服务接口这个spi，可以由服务提供方1提供服务实现；打包服务接口这个spi，可以有服务提供方a提供的默认实现(defaultbundle)，也可以有服务提供方2提供的实现(例如，darunfabundle)，等等。

在进行了服务接口的抽象，并在服务粒度上开发了服务实现后，可以注册到服务系统中，这样，具体的实体店铺中的服务调用方便可以通过对上述服务实现的调用，来获得某种具体的功能。例如，实体店铺a中的服务调用方可以对服务提供方1提供的打包服务的实现进行调用，实现打包功能，对服务提供方2的上架服务的实现进行调用，实现上架功能；实体店铺b中的服务调用方可以对服务提供方1提供的拣货服务的实现进行调用，实现拣货功能，对服务提供方2的上架服务的实现进行调用，实现上架功能，等等。也就是说，同一服务调用方客户端在实现标准作业流程的过程中，可以通过对多种不同服务对应的实现的编排，包括设定不同服务之间的调用关系等，使用多个不同的服务提供方提供的服务实现来共同解决实际业务场景中的具体问题。

以上所述对本申请实施例提供的基于服务粒度进行开发以及服务调用的方案进行了介绍。其中，将商品服务流程按照节点进行了拆分并抽象出具体的服务接口，并由服务提供方提供具体的服务实现代码后，相当于将标准作业流程全部打散成一个一个的服务接口，每个服务接口下对应着多个服务实现，在平台层面上不再存在流程的概念。服务调用方在具体调用上述服务接口的过程中，可以单独调用某个服务接口，例如，某服务调用方只需要某个节点上的服务，则仅针对该节点对应的服务接口进行调用，获得其中一个服务实现提供的服务即可。或者，具体到服务调用方的实际业务场景中，可能仍然需要以流程的形式来实现某个功能，因此，还可以预先对多个服务接口进行编排，生成流程实例，第二系统可以以流程实例为单位进行调用。例如，某服务调用方中需要进行商品上架，则可能仍然需要一个从拣货到打包，再到装箱，最后再进行具体的上架这样一个流程。

因此，为了满足服务调用方的服务接口的编排需求，还可以提供流程配置子系统，用于在服务平台中创建业务流程实例，并在具体的业务流程实例中进行任务配置，在进行任务配置时，则可以通过指定某个具体的服务接口、服务实现来完成对应的任务。流程配置子系统还可以为流程实例分配id等标识，并且可以为服务调用方提供工具包，该工具包中可以包括用于对已经配置的流程进行操作的工具，这样，服务调用方可以在自己的客户端中引入上述工具包，并按照实际的业务需求，在客户端代码中对具体定义的流程进行调用、终结等操作。

在通过流程配置子系统进行具体的流程创建，并进行任务配置的过程中，可以基于具体所需的流程生成流程图，之后在该流程图的基础上进行具体的任务配置，以此实现可视化配置。但是，在现有技术中，流程引擎或是专注于纯内存执行的无状态，或者就是纯粹的状态机，因此，要么只能对流程中的节点进行任务配置，要么对流程中的事件进行任务配置。其中，有限状态机，简称状态机(statemachine)，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。状态机的要点是：拥有一组状态，并且可以在这组状态之间进行切换，且同时只能在一个状态。有限状态机的工作原理为：发生事件(event)后，根据当前状态(current_state)，决定执行的动作(action)，并设置下一个状态(next_state)。工作流(workflow)模式，强调的是任务的执行。一个节点就认为是一个任务，任务执行完成后，跳转到下一个任务节点。现有技术中，有的流程引擎只支持工作流模式，如图2-1所示，其展示的是仅支持工作流的流程引擎。在这种流程引擎中，任务配置在节点上，当在流程运行到节点时候，执行对应的任务配置，完成后跳转到下一个节点；有的流程引擎则只支持状态机模式，如图2-2所示，其展示的是仅支持状态机的流程引擎，在这种流程引擎中，任务配置在事件上，在流程运行到该事件时候，执行事件对应的任务，执行完成后在跳转到下一节点。

而在本申请实施例中，为了能够在不同业务场景下使用不同的表达方式，提供了能够兼容工作流模式以及状态机模式的流程引擎，也就是说，在本申请实施例中，如图2-3所示，流程图中的可配置对象可以是节点，也可以是事件。具体实现时，业务方可以通过点击流程图中的某个节点，来为该节点配置具体的任务，也可以通过点击流程图中相邻节点之间的连接线，来为对应的事件配置具体的事件。这样，本申请实施例中的流程引擎可以融合工作流模式以及状态机模式下的服务编排方式。

下面对具体的实现方式进行介绍。

实施例一

该实施例一首先从流程配置子系统客户端的角度，提供了一种服务调用流程信息处理方法，参见图3，该方法具体可以包括：

s301：根据接收到的创建请求，创建流程实例，所述流程实例中包括多个节点，以及至少一个触发事件，所述触发事件用于触发从一个节点切换为下一个节点；

具体实现时，流程配置子系统可以提供用于创建流程的入口，具体可以是代码编辑入口，或者，在另一种方式下，为了更加便于操作，还可以提供可视化的流程创建界面。通过该界面，可以为所创建的流程实例生成流程图，例如，如图4-1所示，在该流程图中可以包括多个节点以及节点的连线。其中，具体的节点就可以是对应流程中的逻辑节点，而连线则对应具体流程中的触发事件。

s302：为所述流程提供可配置对象，所述可配置对象包括所述节点以及所述触发事件，以便为针对所述流程实例中的节点和/或触发事件进行任务配置；

其中，所述配置的任务中包括所需调用的服务接口标识，以及用于定位该服务接口下的服务实现的参数信息；所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的，服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

具体在创建了流程实例之后，可以为流程实例提供可配置对象，在本申请实施例中，具体的可配置对象可以包括所述节点以及所述触发事件，这样，可以为针对所述流程实例中的节点和/或触发事件进行任务配置。也就是说，在本申请实施例中，在节点以及事件上都可以为流程实例进行任务配置，以此实现对工作流模式以及状态机模式的兼容。具体在进行任务配置时，如果4-2所示，可以对具体所需调用的服务接口的标识，服务实现的标识，用于定位服务实现的参数等信息进行配置。

其中，具体在通过流程图提供可配置对象时，可以将所述流程图中的节点以及节点间的连线置为可操作状态，以便通过对目标节点的操作，将该目标节点确定为待进行任务配置的节点，通过对目标连线的操作，将所述目标连线对应的目标事件确定为待进行任务配置的触发事件。具体实现时，业务方可以通过点击流程图中的某个节点，来为该节点配置具体的任务，也可以通过点击流程图中相邻节点之间的连接线，来为对应的事件配置具体的事件。

在完成配置后，还可以将为所述流程配置的任务配置信息提交到服务器，以便所述服务器为所述流程分配标识信息，并提供工具包，以便服务调用方客户端通过所述工具包对所述流程实例进行操作。

也就是说，在本申请实施例中，具体为同一个流程实例进行任务配置时，不同的任务对应的配置对象的类型可以是不同的，服务器可以对这种信息进行保存，以便后续具体的流程引擎在进行路由的过程中，可以根据具体任务对应的配置对象的类型，切换不同的工作模式。具体的，该服务器中保存的信息具体可以如表1所示：

表1

这样，后续具体在对所创建的流程中的任务进行执行的过程中，一方面可以根据具体的任务对应的配置对象的类型，确定出流程引擎的工作模式，另一方面，则可以根据任务中的服务接口标识，服务实现对应的参数等信息，进行目标服务实现的定位及路由。其中，在具体确定流程引擎的工作模式时，如果某任务对应的配置对象为流程中的节点，则可以确定为工作流模式，否则，如果是触发事件，则确定为状态机模式。流程引擎则可以在不同的工作模式之间切换，实现工作流模式与状态机模式的兼容。

总之，通过本申请实施例，流程中的可配置对象可以是节点，也可以是事件，能够兼容工作流模式以及状态机模式，从而能够在不同业务场景下使用多种不同的表达方式，对服务接口进行编排。

实施例二

该实施例二是与实施例一相对应的，从服务器的角度，提供了一种服务调用流程信息处理方法，参见图5，该方法具体可以包括：

s501：接收客户端创建的流程实例，以及针对所述流程实例中的节点和/或触发事件配置的任务信息，其中，所述配置的任务中包括所需调用的服务接口标识，以及用于定位该服务接口下的服务实现的参数信息；所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；

s502：为所述调用流程实例提供标识信息；

s503：提供工具包信息，以便服务调用方通过所述工具包，对所述标识信息对应的流程实例进行操作，在执行所述流程实例的过程中，通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

实施例三

该实施例三从流程引擎子系统客户端的角度，提供了一种服务调用流程信息处理方法，参见图6，该方法具体可以包括：

s601：在服务调用方执行指定流程的过程中，根据所述流程对应的任务中指定的服务接口标识以及调用参数信息，定位到待调用的目标服务实现；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；

s602：根据所述任务对应的流程实例中的配置对象类别信息，确定流程引擎的工作模式；

如果所述配置对象类别为逻辑节点，确定所述工作模式为工作流模式。如果所述配置对象类别为触发事件，则可以确定所述工作模式为状态机模式。也就是说，并申请实施例中的流程引擎可以兼容两种模式。

s603：返回该目标服务实现对应的服务地址，以便所述服务调用方客户端向所述服务地址发起调用。

关于上述实施例一至实施例三中的未详述部分，可以参见前述实施例中的记载，这里不再赘述。

与实施例一相对应，本申请实施例还提供了一种服务调用流程信息处理装置，参见图7，该装置具体可以包括：

流程实例创建单元701，用于根据接收到的创建请求，创建流程实例，所述流程实例中包括多个节点，以及至少一个触发事件，所述触发事件用于触发从一个节点切换为下一个节点；

可配置对象提供单元702，用于为所述流程提供可配置对象，所述可配置对象包括所述节点以及所述触发事件，以便为针对所述流程实例中的节点和/或触发事件进行任务配置；

其中，所述配置的任务中包括所需调用的服务接口标识，以及用于定位该服务接口下的服务实现的参数信息；所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的，服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

具体实现时，该装置还可以包括：

流程图生成单元，用于为所创建的流程实例生成流程图，所述流程图中包括多个节点以及节点的连线；

所述可配置对象提供单元具体用于：通过所述流程图提供可配置对象。

更具体的，所述可配置对象提供单元具体可以用于：

将所述流程图中的节点以及节点间的连线置为可操作状态，以便通过对目标节点的操作，将该目标节点确定为待进行任务配置的节点，通过对目标连线的操作，将所述目标连线对应的目标事件确定为待进行任务配置的触发事件。

另外，该装置还可以包括：

信息提交单元，用于将为所述流程配置的任务配置信息提交到服务器，以便所述服务器为所述流程分配标识信息，并提供工具包，以便服务调用方客户端通过所述工具包对所述流程实例进行操作。

与实施例二相对应，本申请实施例还提供了一种服务调用流程信息处理装置，参见图8，该装置具体可以包括：

流程实例接收单元801，用于接收客户端创建的流程实例，以及针对所述流程实例中的节点和/或触发事件配置的任务信息，其中，所述配置的任务中包括所需调用的服务接口标识，以及用于定位该服务接口下的服务实现的参数信息；所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；

标识提供单元802，用于为所述调用流程实例提供标识信息；

工具包提供单元803，用于提供工具包信息，以便服务调用方通过所述工具包，对所述标识信息对应的流程实例进行操作，在执行所述流程实例的过程中，通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

与实施例三相对应，本申请实施例还提供了一种服务调用流程信息处理装置，参见图9，该装置具体可以包括：

服务定位单元901，用于在服务调用方执行指定流程的过程中，根据所述流程对应的任务中指定的服务接口标识以及调用参数信息，定位到待调用的目标服务实现；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；

工作模式确定单元902，用于根据所述任务对应的流程实例中的配置对象类别信息，确定流程引擎的工作模式；

服务地址返回单元903，用于返回该目标服务实现对应的服务地址，以便所述服务调用方客户端向所述服务地址发起调用。

其中，所述工作模式确定单元具体可以用于：

如果所述配置对象类别为逻辑节点，确定所述工作模式为工作流模式。

如果所述配置对象类别为触发事件，确定所述工作模式为状态机模式。

另外，本申请实施例还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

根据接收到的创建请求，创建流程实例，所述流程实例中包括多个节点，以及至少一个触发事件，所述触发事件用于触发从一个节点切换为下一个节点；

为所述流程提供可配置对象，所述可配置对象包括所述节点以及所述触发事件，以便为针对所述流程实例中的节点和/或触发事件进行任务配置；

其中，所述配置的任务中包括所需调用的服务接口标识，以及用于定位该服务接口下的服务实现的参数信息；所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的，服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

以及另一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

在服务调用方执行指定流程的过程中，根据所述流程对应的任务中指定的服务接口标识以及调用参数信息，定位到待调用的目标服务实现；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是由服务提供方根据所述服务接口对应的定义信息提供的；

根据所述任务对应的流程实例中的配置对象类别信息，确定流程引擎的工作模式；

返回该目标服务实现对应的服务地址，以便所述服务调用方客户端向所述服务地址发起调用。

其中，图10示例性的展示出了计算机系统的架构，具体可以包括处理器1010，视频显示适配器1011，磁盘驱动器1012，输入/输出接口1013，网络接口1014，以及存储器1020。上述处理器1010、视频显示适配器1011、磁盘驱动器1012、输入/输出接口1013、网络接口1014，与存储器1020之间可以通过通信总线1030进行通信连接。

其中，处理器1010可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器1020可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储用于控制电子设备1000运行的操作系统1021，用于控制电子设备1000的低级别操作的基本输入输出系统(bios)。另外，还可以存储网页浏览器1023，数据存储管理系统1024，以及服务调用处理系统1025等等。上述服务调用处理系统1025就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1013用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口1014用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。

总线1030包括一通路，在设备的各个组件(例如处理器1010、视频显示适配器1011、磁盘驱动器1012、输入/输出接口1013、网络接口1014，与存储器1020)之间传输信息。

另外，该电子设备1000还可以从虚拟资源对象领取条件信息数据库1041中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器1010、视频显示适配器1011、磁盘驱动器1012、输入/输出接口1013、网络接口1014，存储器1020，总线1030等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的服务调用流程信息处理方法、装置及电子设备，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。