一种基于业务事件驱动的工作流框架的制作方法

1.本发明涉及计算机技术领域，尤其是涉及一种基于业务事件驱动的工作流框架。


背景技术：

2.目前主流的开源工作流框架主要是flowable和activti，均采用java语言开发。
3.主流工作流框架最大的缺点是工作流api与业务应用层、业务服务层强耦合，在业务应用层和业务服务层代码中需要调用工作流框架提供的api，即流程层侵入了业务应用层和业务服务层，污染了这些层的代码。


技术实现要素：

4.本技术实施例提供了一种可以有效隔离流程层、业务应用层和业务服务层，便于修改的基于业务事件驱动的工作流框架，通过这种隔离极大地降低流程层与其他层的耦合。
5.本技术实施例的第一方面，提供了一种基于业务事件驱动的工作流框架，应用于业务系统上，包括：业务应用层、流程层和业务服务层；
6.所述业务应用层响应客户端请求，调用对应的流程层代理接口；其中，每一种请求对应一种业务事件；所述流程层代理接口为通过spring aop切面技术自动提供的动态代理接口；
7.所述流程层代理接口的功能包括：前处理逻辑、调用业务服务层的服务接口和后处理逻辑；
8.其中，所述前处理逻辑包括：检查是否为开始事件，如果是则创建新的流程实例；如果不是开始事件，则获取业务编号并根据业务编号查找对应的流程实例和当前流程节点，判断该事件是否允许发生在当前流程节点上，若不允许则抛出异常；
9.所述后处理逻辑包括：如果业务服务层返回业务异常，把该异常直接返回给业务应用层；如果是开始事件，则建立业务编号和流程实例的绑定关系；根据预设的流转条件进行流程流转；返回业务服务层的业务处理结果给业务应用层；
10.所述业务应用层将所述业务处理结果反馈至客户端。
11.在一个实施例中，所述流程层代理接口基于spring aop切面拦截业务应用层对业务服务层服务方法的调用，流程层代理接口通过读取业务服务层方法上的java注解配置，获取业务事件类型、开始事件判断信息及业务编号。
12.在一个实施例中，所述基于业务事件驱动的工作流框架基于spring框架构建，所述工作流框架的流程配置数据保存在预设路径的配置文件中。
13.在一个实施例中，所述配置文件中的每个流程包括多个流程节点，每个节点有对应的流程状态；每个节点上配置有在该节点上允许发生的业务事件类型以及业务事件被业务服务层处理后的流程流转配置。
14.在本技术实施例中，通过在本框架的流程层代理接口中根据业务编号查找对应的
流程实例和当前流程节点，调用业务服务层对应的服务得到处理结果，根据预设的流转条件，将流程实例流转到下一个流程节点。利用该框架提供的功能，将流程流转逻辑从业务应用层和业务服务层中剥离到本框架的流程层，避免流程逻辑污染这两层的代码，业务开发人员在开发业务应用层和业务服务层代码时，不需要调用工作流框架的api接口，实现流程层与业务应用层和业务服务层的高内聚低耦合，也便于拓展工作流框架功能。
15.为了更好地理解和实施，下面结合附图详细说明本发明。
附图说明
16.图1为本发明一个实施例中基于业务事件驱动的工作流框架的交互图；
17.图2为本发明一个实施例中流程节点流转的过程示意图；
18.图3为本发明另一个实施例中基于业务事件驱动的工作流框架的交互图。
具体实施方式
19.为使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术实施例方式作进一步地详细描述。
20.应当明确，所描述的实施例仅仅是本技术实施例一部分实施例，而不是全部的实施例。基于本技术实施例中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它例子，都属于本技术实施例保护的范围。
21.在本技术实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本技术实施例。在本技术实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
22.下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。在本技术的描述中，需要理解的是，术语“第一”、“第二”、“第三”等仅用于区别类似的对象，而不必用于描述特定的顺序或先后次序，也不能理解为指示或暗示相对重要性。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本技术中的具体含义。
23.此外，在本技术的描述中，除非另有说明，“若干个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
24.本技术实施例所述基于业务事件驱动的工作流框架可以应用在业务系统上，所述业务系统包括客户端和服务器，客户端通过网络与服务器进行通信。客户端用于接收用户的请求，并通过网络发送至服务器，所述服务器部署有本技术实施例所述的基于业务事件驱动的工作流框架，在接收到用户的请求之后，利于所述基于业务事件驱动的工作流框架进行业务处理，并返回业务处理结果至客户端。
25.在编写业务代码时，业务应用层调用的是业务服务层的接口。通过本流程框架的spring aop切面拦截了该调用，在运行时，业务应用层实际调用的是流程层的代理接口而
非业务服务层的接口。这个流程代理接口是业务服务层接口的代理，由这个代理接口去调用业务服务层的服务接口，并在调用业务服务层的服务接口之前和之后，执行前处理和后处理逻辑。
26.如图1所示，本发明提供了一种基于业务事件驱动的工作流框架，包括业务应用层、流程层和业务服务层；
27.所述业务应用层响应客户端请求，调用对应的流程层代理接口；
28.其中，每一种请求对应一种业务事件；具体地，当所述业务系统为电商平台时，业务事件可以是下单事件、支付成功事件、确认收货事件等，其中，所述业务事件包括业务编号等信息，业务编号通常是订单号等。
29.所述流程层代理接口为通过spring aop切面技术自动提供的动态代理接口；
30.所述流程层代理接口的功能包括：前处理逻辑、调用业务服务层的服务接口和后处理逻辑；
31.其中，所述前处理逻辑包括：检查是否为开始事件，如果是则创建新的流程实例；如果不是开始事件，则获取业务编号并根据业务编号查找对应的流程实例和当前流程节点，判断该事件是否允许发生在当前流程节点上，若不允许则抛出异常；
32.所述后处理逻辑包括：如果业务服务层返回业务异常，把该异常直接返回给业务应用层；如果是开始事件，则建立业务编号和流程实例的绑定关系；根据预设的流转条件进行流程流转；返回业务服务层的业务处理结果给业务应用层；
33.所述业务应用层将所述业务处理结果反馈至客户端；
34.具体地，所述流程层代理接口基于spring aop切面拦截业务应用层对业务服务层服务方法的调用，通过读取业务服务层方法上的java注解配置，获取业务事件类型、开始事件判断信息及业务编号。
35.aop(aspect orient programming，面向切面编程)切面拦截方法为通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术，在本技术实施例中，利用spring aop切面拦截方法拦截业务应用层对业务服务层服务方法的调用，通过拦截可以达到以下效果：在代码编写时，业务应用层调用业务服务层接口；但在运行时，业务应用层实际上调用的是流程层的代理接口，再由这个代理接口调用业务服务层接口，代理接口可以在调用业务服务层接口的前后执行本工作流框架提供的前后处理逻辑，从而降低业务应用层和业务服务层之间的耦合度，提高程序的可重用性和开发效率。
36.开始事件是流程的第一个事件。例如，对于电商系统，开始事件一般是下单事件。对开始事件，在流程层代理接口的前处理逻辑中会创建新的流程实例；在开始事件的后处理逻辑中会建立订单号和该流程实例的绑定关系，这样在该订单上其余事件的前处理逻辑中就可以根据订单号(业务编号)通过绑定关系找到这个流程实例。
37.具体地，如图2所示，一个流程(process)可以包含多个流程节点(node)，其中有一个为开始节点和一个为结束节点；其中，开始节点为流程的第一个节点，结束节点为流程的最后一个节点。每一个流程节点可以定义用于流转至该节点的流入操作(action)和用于离开该节点的流出操作(action)，流入操作可以是流转到该流程节点时执行的一段处理代码，流出操作可以是离开该流程节点时执行的一段处理代码，每一个流程节点的流入操作和流出操作可以由用户自定义。每一个流程节点可以触发一个或多个流程业务事件
(event)，例如，例如在电商订单流程中的待支付节点，可以有支付事件，也可以有取消订单事件。每种类型的流程业务事件由事件类型加以区分。每种事件可以由对应的事件处理器(eventhandler)进行处理，当处理完成后，工作流框架会根据事件上的流转配置(流转条件)将流程实例流转到下一个流程节点。其中，事件处理器可以是业务服务层的服务方法。
38.事件(actor)可以是实际触发流程业务事件的人或系统，例如在电商订单流程中，买家进行支付时，就会触发支付事件。如果actor是人，在流程节点上可以为不同的actor定义不同的客户端页面(form)。
39.所述业务服务层进行业务逻辑处理，并返回业务处理结果；
40.业务服务层提供与该业务事件对应的服务方法，该服务方法用于进行业务逻辑处理，得到业务处理结果。
41.在本技术实施例中，通过在本框架的流程层代理接口中根据业务编号查找对应的流程实例和当前流程节点，调用业务服务层对应的服务得到处理结果，根据预设的流转条件，将流程实例流转到下一个流程节点。利用该框架提供的功能，将流程流转逻辑从业务应用层和业务服务层中剥离到本框架的流程层，避免流程逻辑污染这两层的代码，业务开发人员在开发业务应用层和业务服务层代码时，不需要调用工作流框架的api接口，实现流程层与业务应用层和业务服务层的高内聚低耦合，也便于拓展工作流框架功能。
42.在一个实施例中，所述基于业务事件驱动的工作流框架还包括数据层，所述数据层用于保存业务数据和流程数据。
43.在一个实施例中，所述基于业务事件驱动的工作流框架基于spring框架构建，所述工作流框架的流程配置数据保存在预设路径的配置文件中。
44.所述工作流框架的流程配置数据以spring xml格式保存在预设路径的配置文件中，流程配置数据包括流程(process)、流程节点(node)等数据。所述配置文件中的每个流程包括多个流程节点，每个节点有对应的流程状态；每个节点上配置有在该节点上允许发生的业务事件类型以及业务事件被业务服务层处理后的流程流转配置。该xml文件使用自定义名字空间(namespaces)，需要定义配置文件对应的xsd文件对所述xml文件进行解析，通过拓展spring框架的namespacehandlersupport类和abstractsinglebeandefinitionparser类，在meta
‑
inf/spring.handlers和meta
‑
inf/spring.schemas两个属性中加入相应的配置，即可完成解析。
45.如图3所示，其为利用一个实施例中将本技术的基于业务事件驱动的工作流框架应用在电商系统上进行确认收货的交互图。具体地，在本实施例中，开始事件可以是买家下单。
46.所述工作流框架以spring boot starter jar包形式提供集成，当集成了本工作流框架的电商后台系统启动时会自动产生确认收货服务代理接口。买家通过客户端发送确认收货请求，业务应用层调用本流程框架自动提供的确认收货代理接口(通过前面描述的spring aop切面拦截实现)，确认收货代理接口在调用业务服务层的确认收货方法之前，根据订单号查找对应的流程实例，调用业务服务层中的确认收货服务。业务服务层进行确认收货逻辑处理后，确认收货代理接口根据该事件配置的流转条件，将流程实例流转到下一个流程节点。最后返回确认收货响应至客户端。
47.本技术实施例所述基于业务事件驱动的工作流框架通过借助java注解、spring依
赖自动注入和spring aop技术实现业务应用层、流程层和业务服务层之间的隔离和弱耦合，使得开发人员在开发时无需关注流程层，即可完成其余软件层的编辑和修改，同时，本技术实施例通过将工作流框架的配置数据以spring xml格式保存在预设路径中，便于开发人员结合java和spring丰富的生态系统进行组件拓展，提高业务系统的拓展性。
48.本发明并不局限于上述实施方式，如果对本发明的各种改动或变形不脱离本发明的精神和范围，倘若这些改动和变形属于本发明的权利要求和等同技术范围之内，则本发明也意图包含这些改动和变形。