CN108563425B - 一种事件驱动的多流程协同处理系统 - Google Patents

Abstract

本发明提供一种事件驱动的多流程协同处理系统，通过多流程建模模块创建业务流程的协作图，为业务流程之间进行信息交互创造了可能，根据协作图配置消息路由，可知道消息的发送者和接收者，通过对协作图进行安全性验证、可达性验证、死锁检测以及死循环检测，能够检测出协作图中的错误，避免在业务流程运行时造成损失，再通过分布式部署及运行模块将协作图拆分成单业务流程，将各单业务流程打包后分布式部署到jBPM流程引擎，分布式运行能解耦，而且根据具体的业务场景，可能每个业务流程发生在不同的地方，每个流程就近部署和运行；分布式运行也为流程管理带来方便，每个jBPM服务器上的流程可由不同的组织管理和维护。

Description

一种事件驱动的多流程协同处理系统

技术领域

本发明涉及计算机技术领域，更具体地，涉及一种事件驱动的多流程协同处理系统。

背景技术

在企业运作过程中，业务流程是被抽象出来的被视为最有价值的企业资产，其特指为某些指定的客户或对象创造和提升价值的过程。具体地说，业务流程就是为了达到既定的目标而进行的一系列互相关联而且有组织的任务或活动，是一系列活动的集合。业务流程通常具有一种或多种输入，但它的输出是确定的，并且这些输出对客户具有重要的价值。比较典型的解释是：业务流程始于客户需求，止于客户需求的满足，并为客户实现价值目标。企业的业务流程应依据市场需求做出及时的适应性调整，为企业设计合适的业务流程，具有更好的效益(企业成本降低)和更高的效力(客户价值增加)。这对企业保持良好的市场竞争力具有重要的现实意义。

企业信息化进程中，引入业务流程管理(Business Process Management,BPM)用于实现各种业务环节整合的全面管理目标。业务流程管理是运营管理领域的概念，侧重于管理和优化公司的业务流程并提高企业经济效益。因此业务流程管理可以被视为一个业务流程优化的过程。相较于着眼功能的传统分级管理方式，业务流程管理可以使得使企业组织更加高效，可以很好地适应市场的变化。业务流程管理通常通过网络形式进行数据通信和业务集成，是工作流技术和企业管理理念的一个突破。

JBPM引擎(Java Business Process Management)，即Java业务流程管理，是一个用Java编写的开源的工作流程引擎。通过BPMN 2.0描述的业务流程或由早期的jBPM自己的流程定义语言jPDL定义的流程可以在jPMN中运行执行。JBPM由JBoss公司发布，基于ASL和LGPL开源标准的流程语言框架。其主要功能为业务流程管理，同时还提供工作流相关的功能，并涵盖服务协作等相关领域。

现有的业务流程管理系统仅能对单业务流程进行处理，导致单业务流程之间不存在交互，这样对复杂的业务场景进行良好的抽象，而复杂的场景用单业务流程描述太庞大，容易出错，甚至不能描述。

发明内容

本发明提供一种克服上述问题或者至少部分地解决上述问题的事件驱动的多流程协同处理系统。

根据本发明的一个方面，提供一种事件驱动的多流程协同处理系统，包括：

多流程建模模块，用于创建业务流程的协作图、根据所述协作图生成消息路由、完成所述协作图的安全性验证、可达性验证、死锁检测以及死循环检测；

分布式部署及运行模块，用于将所述协作图拆分为一定数量的单业务流程，将各单业务流程打包后分布式部署到jBPM流程引擎。

优选地，所述多流程建模模块包括消息建模子模块，所述消息建模子模块包括：

复合消息类单元，用于创建业务流程的协作图，并在协作图中定义业务流程之间进行消息交互的类型；

消息路由表单元，用于消息交互建模、提取协作图中业务流程的消息路由以及构建消息路由表。

优选地，所述多流程建模模块还包括多流程验证子模块，所述多流程验证子模块包括：

业务流程转换单元，用于将业务流程转换为Petri网；

安全性验证单元，用于对所述Petri网的安全性进行验证，以及当安全性验证不通过时，定位到业务流程中出现不可控顺序流的节点；

可达图生成单元，用于进行安全性验证时，生成Petri网的可达图，可达图中的状态用于标识Petri网中每个库所包含的令牌数；

可达性验证单元，用于当检测到Petri网中所有变迁都出现在所述可达图中时，获知协作图可达；

死锁检测单元，用于当检测到可达图中每个出度为0的节点均对应结束事件时，获知协作图不存在死锁节点；

死循环检测单元，用于当检测到可达图中存在环路时，获知协作图中存在死循环。

优选地，所述分布式部署及运行模块包括：

协作图拆分子模块，用于遍历协作视图中的各业务流程，将不同的业务流程提取出来，形成多个单独业务流程，提取过程中各业务流程的内部结构不变，还用于保留业务流程之间交互的消息和单独业务流程的流程图片；

分布式部署和运行子模块，用于显示jBPM服务器的状态、关联各业务流程与jBPM服务器的IP地址，将各业务流程进行打包，并在打包后按照关联结果将业务流程部署至jBPM服务器；所述jBPM服务器的状态为连接状态、未连接状态、启动状态以及未启动状态中的一种。

优选地，所述事件驱动的多流程协同处理系统还包括：消息中间件模块，用于采用发布-订阅模式完成分布式通信，自定义发送任务的第一处理程序Handler和接收任务的第二处理程序Handler；

其中，所述第一处理程序Handler用于定义构造消息对象的方法和调用发布-订阅接口向发布/订阅主节点发布消息的方法；所述第二处理程序Handler用于定义监听发布/订阅主节点转发的消息、缓存消息对象的方法，以及处理接收的消息的方法。

优选地，所述事件驱动的多流程协同处理系统还包括：流程监控模块，用于查看业务流程的运行状态、在业务流程出现异常时挂起业务流程和在异常排除后恢复业务流程。

优选地，所述可达性验证单元具体用于：

提取可达图中所有边上的变迁，构成散列表；

循环遍历Petri网中的所有变迁，检测是否存在于散列表，对于petri网中的一个变迁，若该变迁存在于所述散列表中，若将该变迁加入至变迁表中，若该变迁不存在于散列表中，则继续判断变迁表是否为空；

若变迁表不为空，则获知可达性验证成功；若变迁表为空，则查找并显示变迁表中变迁对应的BPMN元素，同时判断不通过可达性验证。

优选地，所述死循环检测单元具体用于：

S1、将可达图的根节点赋为当前节点；

S2、将当前节点加入至路径集合中，循环遍历当前节点的子节点，对于当前节点的任意一个子节点，若该子节点不在路径集合中，则执行步骤S3，若该子节点已存在于路径集合中，执行步骤S4；

S3、将该子节点赋为当前节点，并返回执行步骤S2；

S4、判断可达图中存在环路，将当前节点加入至节点集合中，同时将当前节点从路径集合中移除。

本发明提出的事件驱动的多流程协同处理系统，通过多流程建模模块创建业务流程的协作图，为业务流程之间进行信息交互创造了可能，根据协作图配置消息路由，可知道消息的发送者和接收者，通过对协作图进行安全性验证、可达性验证、死锁检测以及死循环检测，能够检测出协作图中的错误，避免在业务流程运行时造成损失，再通过分布式部署及运行模块将协作图拆分成单业务流程，将各单业务流程打包后分布式部署到jBPM流程引擎，分布式运行能解耦，而且根据具体的业务场景，可能每个业务流程发生在不同的地方，每个流程就近部署和运行；分布式运行也为流程管理带来方便，每个jBPM服务器上的流程可由不同的组织管理和维护。

附图说明

图1为根据本发明实施例的事件驱动的多流程协同处理系统的功能示意图；

图2为根据本发明实施例的安全性验证的流程示意图；

图3为根据本发明实施例的可达性验证的流程示意图；

图4为根据本发明实施例的死锁检测的流程示意图；

图5为根据本发明实施例的死循环检测的流程示意图；

图6为根据本发明实施例的预定义的回调逻辑的流程示意图。

具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

为了克服现有技术的上述问题，本发明实施例提供了一种事件驱动的多流程协同处理系统，参见图1，包括：

多流程建模模块101，用于生成消息路由、使不同业务流程之间进行复合类型的消息交互、完成协作图的安全性验证、可达性验证、死锁检测以及死循环检测。多流程建模模块为流程设计和建模人员提供可视化界面和良好的接口，帮助其完成协作图的创建、配置、验证和持久化。

分布式部署及运行模块102，用于将所述协作图拆分为单业务流程，并将单业务流程打包并分布式部署各单业务流程到jBPM流程引擎。分布式部署及运行模块将协作图拆分成单业务流程，打包和分布式部署单流程，并支持浏览器远程启动各流程。

在上述实施例的基础上，多流程建模模块包括消息建模子模块，消息建模子模块使业务流程之间进行复合类型的消息交互成为可能，消息建模子模块为流程建模人员提供创建、删除、修改和查看复杂消息类型的图形操作界面，使得流程建模人员不用书写Java代码，而把注意力集中在流程逻辑上。

消息建模子模块进一步包括：

复合消息类单元，用于确定业务流程之间进行消息交互的类型，并将确定后的类型以Java类的形式保存在项目目录下。

需要说明的是，业务流程间的消息交互的格式由设计时具体确定的，消息交互的数据可以是简单的，例如单个字符串，也可以使用自定义的结构的数据。本发明实施例的消息建模子模块提供复合消息数据定义的功能，用于建模人员构建具体的数据结构。流程建模人员可在eclipse窗口中创建、删除、修改和查看消息的类型。复杂消息类型可以包含简单数据类型，简单数据类型支持字符串(String)，整型(int)，布尔型(boolean)，字符型(char)，浮点型(float)，字节型(byte)，短整型(short)，长整型(long)。复合消息类单元创建的类型包括类名、成员名及成员类型、成员变量的get()及set()方法和带参数的构造方法。创建的复合消息类自动保存在当前工程目录下。

消息路由表单元，用于消息交互建模并提供用于管理和显示消息路由信息的消息路由表。

需要说明的是，消息交互建模指在协作视图中通过消息流对流程间的不同任务(Task)进行关联，声明消息的发送者与接收者。为了直观地管理与显示消息的交互，消息路由表单元提供消息路由表，用于管理和显示消息具体的路由信息，消息路由表记录协作图中消息的交互关系，在“RouterTable”标签页中实时显示消息路由信息。路由信息不仅可以用于显示，并且提供运行时选择消息路由的作用。消息路由表单元能够提取并解析消息路由，将消息路由保存在工程目录下的特定的消息路由文件下。消息路由包括消息的发送者、接收者、关联的消息ID以及消息的主题，消息路由的集中显示可以让建模人员浏览所有流程间交互的具体细节，提高建模及排错的效率；协作图的消息路由信息自动保存在消息路由文件(即消息路由表在计算机中的具体存储形式)中，消息路由文件在当前工程目录下。

在上述实施例的基础上，多流程建模模块还包括多流程验证子模块，多流程验证子模块用于验证多流程业务的安全性、可达性以及对多流程业务中的死锁、死循环进行检测。本发明实施例的多流程验证子模块通过将业务流程转换为Petri网，并生成Petri网的可达图，在可达图的基础上完成流程验证，通过查询转换映射表定位流程中存在问题的节点，并通过可视化界面展示给流程设计人员。

需要注意的是，消息建模子模块中的复合消息类单元是用户触发的，发生在构建协作图时，消息建模子模块中的消息路由表单元是协作图完成后执行的，而多流程验证子模块的动作也在创建业务流程完图成后执行，可以认为多流程验证子模块的动作是发生在消息建模子模块的动作之后的。

具体地，多流程验证子模块包括：

业务流程转换单元，用于将业务流程转换为Petri网；本发明实施例的事件驱动的多流程协同处理系统在单流程转换规则的基础上，引入消息库所，将多流程中的消息流转换为Petri网中的元素，例如库所、变迁和有向弧等待。Petri网在系统中表现为内存中的有向图，用于后续的流程验证模块。

业务流程可以理解成一个容器，该容器中可以有任务(task)、事件(event)等具体的可执行的节点。在业务流程转换单元对业务流程进行转换的过程中，业务流程中的任务(Task)或者中间事件(Intermediate event)被转化为带有一个输入库所和一个输出库所的变迁，其中输入库所、变迁、输出库所依次连接，输入库所和输出库所可能与其它流程节点共用。该变迁带有task或event的标签，用于区分具体的节点类型。变迁可以将令牌从输入库所“搬”到输出库所。

业务流程中还可以容纳开始事件和结束事件，开始事件和结束事件都是事件(event)的一种，开始事件是流程开始运行时要执行的事件，结束事件则是流程完毕时要执行的事件。除了开始事件和结束事件，还有中间事件，即是发生在流程运行中的事件。开始事件或者结束事件也做类似的转化，不同的是构建一个匿名的变迁，用于流程的开始或者结束。匿名变迁即变迁没有名字。由于等价转换的需要，一条网关路由就对应一个变迁，这些变迁是不需要名字的。

在本发明实施例中，网关用于业务流程的分流，比如选择、并行等，基于事件的网关的分流路径由事件是否发生来决定，比如：某事件发生了则选择第一条路径。除了基于事件(Event-based)的网关和排它网关(Exlusive Gateways)，在业务流程的转换过程中，通过Petri网的匿名变迁表示网关路由。

转换/数据驱动网关的过程中，通过匿名变迁构建多个布尔条件作为输出，并且这些布尔条件拥有一个共同的输入库所。本步骤中的输出就是把令牌输出到输出库所里，而库所可以理解为令牌的“栖息地”。转化后的匿名变迁共同竞争(每条网关路由之间竞争，因为不是每一条路由都要走。而网关路由是由匿名变迁建模的)输入的令牌使得这些迁移中的具体选择哪一个激活(激活(或者触发)即激活变迁，也称作选择哪一条路由)是不确定的。换句话说，在流程转换过程中并不模拟布尔条件本身，而是通过这种令牌竞争机制使得网关的众多布尔条件中只有一个输出得到执行。

一般情况下，顺序流(英文名称：SequenceFlow，顺序流连接同一个业务流程中的节点，而消息流是不同流程之间的数据交互，用于不同业务流程之间)被映射成为一个库所(这里的库所一般作为顺序流连接的两个节点所共用的库所，既可以理解成输入库所，也可以理解成输出库所)。

安全性验证单元，用于对Petri网的安全性进行验证，以及当安全性验证不通过时，定位到业务流程中出现不可控顺序流的节点。

需要说明的是，Petri网满足安全性约束当且仅当Petri网是1有界的，即在任何时刻，Petri网中的库所最多包含1个令牌。Petri网的安全性验证与可达图的生成具有相似的流程。若安全性验证不通过，则存在至少一个BPMN元素(BPMN元素就是业务流程里的一个节点，而业务流程是一个容器)可能出现不可控的顺序流，安全性验证单元定位到该BPMN元素并将其呈现给流程设计人员。

具体地，对petri网的安全性进行验证的方法，参见图2包括：

令startevent(中文名称：开始事件，是业务流程的一种元素，)的token(中文名称：令牌)为1，其他库所的token为0，并将此状态定义为初始状态；

构造栈，将上述初始状态载入栈；

判断栈是否为空，需要注意的是，本步骤是个循环的过程，因为会不断的压栈和弹栈，当压栈次数多于弹栈次数时，栈就为空了，初始时栈中有且只有一个元素；

若为空，则petri网为安全，结束安全性验证；

若不为空，则获知栈顶状态出栈。循环遍历所有token为1的库所，判断变迁是否被激发，若不是，则返回判断栈是否空；若是，则继续判断当前状态是否安全(由安全性定义，每个状态下，每个库所中的令牌数不超过1)；若判定安全，则在前缀树中查询当前状态；若判定不安全，则流程结束。需要说明的是，栈是一种先进后出的数据结构，由于栈里的每个元素表示Petri网的一个状态，因此叫栈顶状态。

可达图生成单元，用于进行安全性验证时，生成Petri网的状态转移图(即可达图)，状态转移图中的状态用于标识当前Petri网中每个库所包含的令牌数，状态的转移条件为Petri网中的某个变迁是否满足激发条件。需要说明的是，可达图生成算法流程与安全性验证算法类似，可在进行安全性验证的时同时生成Petri网的可达图，可达图表现形式依然是内存中的有向图。

可达性验证单元，用于当检测到Petri网中所有变迁都出现在状态转移图中时，判断协作图。

需要说明的是，可达性验证是在可达图的基础上完成的，算法只需检测Petri网中的所有变迁是否都出现在可达图中，如果都出现，说明Petri网中所有变迁都可达，即协作图可达；否则，协作图不可达。算法流程图如图3所示：

提取可达图中所有边上的变迁，构成散列表t；

循环遍历Petri网中的所有变迁，检测是否存在于散列表t，对于petri网中的一个变迁，若该变迁存在于散列表t中，若将该变迁加入至变迁表中，若该变迁不存在于散列表t中，则判断变迁表是否为空；

若变迁表不为空，则判断通过可达性验证；若变迁表为空，则查找并显示变迁表中变迁对应的BPMN元素，同时判断不通过可达性验证。

由上述实施例可知，可达性验证与安全性验证类似，可达性验证也可定位到某个BPMN元素并将其呈现给流程设计人员，

死锁检测单元，用于当检测到状态转移图中每个出度为0的节点均对应结束事件时，判断协作图不存在死锁节点。

死锁检测单元的具体执行流程参见图4，如图所示，包括：

1、循环遍历可达图中的所有节点，检查当前节点的出度是否为0，若为0，则执行步骤2；若不为0，则执行步骤5；

2、循环遍历当前节点所有含有令牌的库所，判断该库所是否是结束时间对应的库所，若否，则执行步骤3；若是，则执行步骤4；

3、将该库所对应的BPMN节点加入至变迁表中，执行步骤4；

4、判断循环遍历是否结束，若没有结束，则返回执行步骤2，若已结束，则执行步骤5；

5、判断循环遍历过程是否结束，若结束，则返回步骤1，若未结束，则判断变迁表是否为空，若为空，则判断协作图通过死锁验证；若不为空，则将变迁表中的节点作为死锁节点，并进行显示。

死循环检测单元，用于当检测到可达图中存在环路时，判断协作图中存在死循环。可达图的环路检测可使用深度优先遍历算法完成，具体地，参见图5，包括：

S1、将可达图的根节点赋为当前节点；

S2、将当前节点加入至路径集合中，循环遍历当前节点的子节点，对于当前节点的任意一个子节点，若该子节点不在路径集合中，则执行步骤S3，若该子节点已存在于路径集合中，执行步骤S4，

S3、将该子节点赋为当前节点，并返回执行步骤S2；

S4、判断可达图中存在环路，将当前节点加入至节点集合中，同时将当前节点从路径集合中移除。

在上述实施例的基础上，分布式部署及运行模块包括：

协作图拆分子模块，用于遍历协作视图中的各业务流程，将不同的业务流程提取出来形成多个单独业务流程，提取过程中保证各流程的内部结构不变，保留业务流程之间交互的消息和单独业务流程的流程图片。

需要说明的是，协作视图源文件的元素结构是相同的，所有的领域模型元素及视图元素通过元模型定义的方式按照一定结构组织在一起，所有的元素节点都位于一个元素(bpmn:definitions元素)下。

业务流程的具体切分步骤如下：

a)顺序遍历bpmndi:BPMNDiagram节点下所有的视图元素，获取每一个BPMNShape或者BPMNEdge对应的领域模型元素，并按照领域模型元素id和视图元素通过Map结构存储；

b)顺序遍历Definitions节点下的领域模型元素(领域模型是emf里的概念，是mvc里的模型的表示，而流程元素是用领域模型来表示的)，如果是itemDefinition或者是message节点，则按照id和领域模型元素通过Map结构存储，否则转到步骤c)；

c)如果领域模型元素是bpmn2:process类型，则根据流程的id创建一个流程resoure，并初始化根元素为bpmn2:definitions，若领域模型元素不是bpmn2:process类型，进入步骤h)；

d)创建临时Process类型对象，并根据原始协作图中对应的流程元素的信息初始化临时的Process对象；

e)获取并遍历原始process元素(即步骤d)中的流程元素)下所有的Property节点，遍历过程中对于每一个Property节点对应地创建一个新的Property对象，并且根据原始Property对象初始化新的对象，根据原始Property对象关联的itemDefinition的id在步骤c)中存储的Map结构中查找到对应的元素，根据对应的元素的信息新建一个itemDefinition，将新的Property对象与之相关联，将新的Property加入新的process对象中。

f)遍历原始process元素下所有的流程元素(FlowElement)，对每一个流程元素都新建一个流程元素对象，根据原始的流程元素信息初始化新的流程元素对象，并且根据原始流程元素对象的id查找步骤a)中的Map结构，获取对应的视图元素对象；同样对应地新建一个视图元素对象，根据原视图元素初始化，最后将新建的流程元素对象和视图元素对象关联并加入到步骤c)中创建的流程resource中。

g)如果流程元素关联有Message元素，需要通过引用关系找到对应的Message，并且生成一个新的Message对象，根据原Message信息初始化，由于Message关联有itemDefinition元素，因此需要将新建的Message对象根据原Message对象关联的itemDefinition元素的id在步骤e)中查找到对应的元素进行关联。

h)返回执行步骤b)，直到没有新的元素。

特别需要注意的是，因为原始的协作视图中的视图元素的位置信息都是通过存储绝对值的方式存在于bpmndi节点下，其参考的坐标为画布的左上角，以参与者为单位提取到不同的流程文件后，需要以每个流程元素与其所属的参与者对应的图元的左上角的相对位置为该元素的绝对位置写入新的流程文件中，使单独的流程文件中的视图元素都能处于相对合适的位置。

分布式部署和运行子模块，用于显示jBPM服务器的状态、关联各业务流程与jBPM服务器的IP地址，将各业务流程进行打包，并在打包后按照关联结果将业务流程部署至jBPM服务器(jBPM流程引擎部署的主机称之为jBPM服务器)；jBPM服务器的状态为连接状态、未连接状态、启动状态以及未启动状态中的一种。

需要说明的是，用户完成多流程项目设计后，可利用maven的打包命令将工程打包为.war为后缀的形式，辅助实现部署；同时工具栏的打包按钮会触发检测可用jBPM服务器和写主题树的功能。

通过点选将选中文件部署到jBPM服务器，实现了已部署的同步刷新，并可即时实现解部署功能；配合Socket实现将工程对应的流程文件等发送至jBPM服务器中的指定文件夹，便于jBPM服务器端使用。在本地还可查看jBPM服务器上流程的部署情况，避免重复部署。

远程部署完流程之后，可在浏览器中远程启动单业务流程。jBPM服务器端使用Servlet解析http请求，Servlet类包含调用JBPM的接口来实例化流程，同时将上文中的消息中间件集成在Servlet的类中。

在上述实施例的基础上，事件驱动的多流程协同处理系统还包括消息中间件模块，用于采用发布-订阅模式完成分布式通信，自定义发送任务的第一处理程序Handler和接收任务的第二处理程序Handler，以将发布-订阅通信系统集成到jBPM中；

其中，发送任务的第一处理程序Handler用于定义构造消息对象的方法和调用发布-订阅接口向发布/订阅主节点发布消息的方法；接收任务的第二处理程序Handler用于定义监听发布/订阅主节点转发的消息、缓存消息对象的方法，以及处理接收的消息的方法。

需要说明的是，消息中间件为流程运行时提供消息发送、接收、路由、缓存等支持。消息中间件模块，采用发布-订阅机制，通过自定义发送任务和接收任务的处理程序Handler来实现。发布-订阅通信模式满足消息交互双方的异步解耦，并支持多对多的消息交互，消息的发送方和消息的订阅方在时间或者空间上并不需要知道对方的存在，消息通信过程中，用消息主题(topic)来标识消息。本发明实施例的事件驱动的多流程协同处理系统中的发送任务的第一处理程序Handler和接收任务的第二处理程序Handler，使分布式流程的消息交互采用发布-订阅通信模式；第一处理程序Handler定义如何构造消息对象，以及如何调用发布-订阅接口向发布/订阅主节点发布消息，第二处理程序Handler定义如何监听发布/订阅主节点转发的消息，如何缓存消息对象，以及如何处理接收的消息。

本发明实施例的事件驱动的多流程协同处理系统提供图形界面供流程建模人员配置发布/订阅主节点(简称主节点)IP地址、消息主题和消息对象内容等。在启动业务流程时，运行时逻辑首先向主节点订阅本流程需要的消息主题，一旦发送任务发送该消息主题至主节点，主节点即将该消息转发给该业务流程，这样即完成一次消息交互。在业务流程分布式运行时，本发明实施例的事件驱动的多流程协同处理系统可自动按发送任务和接收任务的处理程序Handler里的逻辑进行消息的发送和接收。

在本发明实施例利用消息中间件进行消息事件传输的过程中，消息的订阅端或者发布端利用并封装消息中间件提供的接口消费或者发布消息事件。消息的发布逻辑比较简单，只是将流程引擎运行过程中产生的具体消息事件调用发布接口进行消息发布。而消息订阅端的逻辑稍微复杂一些，消息的订阅者需要通过订阅接口声明对某个主题关联的消息事件的订阅，并且传入具体的回调处理逻辑。该回调处理逻辑定义了对消息的具体解析处理过程，当消息中间件中有该主题的消息事件产生时，消息中间件将消息推送到订阅者的流程引擎中，回调处理逻辑将解析具体的事件消息，并作用到流程引擎中。

除此之外，订阅端提供消息事件缓存功能。当发布端提前发布消息事件到发布-订阅中间件中，而订阅端流程还未运行到接收任务(receive task)节点时，订阅端流程引擎需要对消息事件进行缓存，直到流程执行到该接收任务(receive task)节点，该消息才被消费。

如上所述，消息的发布节点逻辑比较简单，只是将流程引擎运行过程中产生的具体事件进行封装发布，对应地，消息中间件的事件发布过程实现逻辑也比较简单。业务流程建模过程中，需要对发送任务节点进行一些细化的配置，例如设置输入输出赋值和关联的Message等。JBPM流程引擎在流程实例化后将其包装成一个WorkItem，并且将相关信息写入该WrokItem实例中。发送任务对应拓展的WorkItemHandler可以在运行时通过相关的接口获取这些信息。

处理逻辑中，首先通过相关的调用来获取发送任务节点的配置信息，以用于消息封装，其中包括关联的流程变量，发送的消息名称、消息主题及消息对应的数据类型等。消息的封装通过Java反射机制，调用已经对象化的类型对象内部set函数设置对象的成员属性。消息对象设置完毕之后调用发布/订阅的消息发布接口，将消息对象通过跟消息主题关联并进行发布。消息发送完毕之后调用JBPM接口来结束WorkItem在流程引擎中的生命周期。

消息的订阅端逻辑稍微复杂一些，接收任务的处理逻辑分为两个阶段。在使用消息中间件时，消息的消费者需要通过向消息中间件声明感兴趣的消息主题，即消息的订阅。订阅消息过程中除了需要进行主题声明，同时会声明该主题的回调处理逻辑。当所有消息中间件连接的系统中产生该主题的消息事件实例时，消息中间件会将消息推送到消息的接收端中，并且调用接收端先前声明的回调处理逻辑进行消息事件的处理。

基于上述过程，本发明实施例的消息接收端的处理逻辑设计可分为两个部分。

首先，在JBPM业务流程引擎启动一个流程实例时，对消息进行集中订阅。具体订阅的消息主题从路由文件中查询获得，这也就是在流程建模工具中将消息路由表与业务流程一起部署的原因之一。因为流程实例启动后，接收任务节点可能不会立即执行，为了防止数据的丢失，在引入消息缓存的基础上还应该提前订阅相关的消息，否则如果订阅动作推迟到接收任务所在节点执行时触发，那么消息缓存就失去了原有的作用。消息集中订阅完毕之后，消息中间件才可能将感兴趣主题对应的消息推送到该消息订阅端。发布/订阅的客户端进行消息订阅时还需要传入预定义的回调处理过程，该回调过程对消息中间件推送来的具体消息事件进行处理。这种等待回调的运行机制由消息中间件通过WebService方式实现。

图6展示了预定义的回调逻辑的处理流程，在对推送过来的消息实例进行处理时可以获取消息的主题及消息的内容，根据消息主题在对该主题感兴趣的流程实例中进行遍历，查看是否有等待该主题的流程节点实例存在，如果尚未有具体的WorkItem等待该消息，则将消息缓存下来。如果已有等待该消息的WorkItem存在，直接将等待该主题的WorkItem唤醒，让WorkItem进行后续操作。

消息接收端的处理逻辑的第二个部分为接收任务对应的WorkItemHandler处理逻辑。当jBPM流程引擎中的流程实例运行到接收任务的实例时执行该处理逻辑。开始执行处理逻辑后，先获取关联消息的主题信息，根据主题在消息缓存中进行查找，如果缓存中已有对应的事件信息，则直接取出进行处理。消息处理过程中，根据主题及消息的类型解析消息体。获取消息中成员属性的值之后作用于业务对应的流程实例，之后调用接口结束WorkItem的执行。如果消息缓存中没有对应主题的消息存在则流程节点实例进入阻塞状态，等待唤醒。当消息中间件推送该主题对应的消息到流程引擎中时，回调处理逻辑会唤醒阻塞的WorkItem。流程节点被唤醒则同样执行消息消费的几个步骤：消息解析、作用于流程和结束WorkItem实例。

在上述实施例的基础上，本发明实施例的事件驱动的多流程协同处理系统，还包括流程监控模块，用于查看业务流程的运行状态、在业务流程出现异常时挂起业务流程和在异常排除后恢复业务流程。

需要说明的是，本发明实施例的流程监控模块为流程管理人员提供远程监控流程运行状态的功能，包括实时显示执行完毕的节点、挂起流程以及恢复流程。通过流程监控模块，流程管理人员可在本地浏览器中实时地查看各jBPM服务器上流程的运行状态，并在流程运行出现异常时远程挂起流程，异常排除后可远程再启动流程。本模块为流程管理人员提供了方便快捷的流程管理功能。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

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

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (7)

1.一种事件驱动的多流程协同处理系统，其特征在于，包括：

多流程建模模块，用于创建业务流程的协作图、根据所述协作图生成消息路由、完成所述协作图的安全性验证、可达性验证、死锁检测以及死循环检测；

分布式部署及运行模块，用于将所述协作图拆分为一定数量的单业务流程，将各单业务流程打包后分布式部署到jBPM流程引擎；

其中，所述多流程建模模块还包括多流程验证子模块，所述多流程验证子模块包括：业务流程转换单元，用于将业务流程转换为Petri网；以及可达性验证单元，用于当检测到Petri网中所有变迁都出现在可达图中时，获知协作图可达；

所述可达性验证单元具体用于：

提取可达图中所有边上的变迁，构成散列表；

循环遍历Petri网中的所有变迁，检测是否存在于散列表，对于petri网中的一个变迁，若该变迁存在于所述散列表中，将该变迁加入至变迁表中，若该变迁不存在于散列表中，则继续判断变迁表是否为空；

若变迁表不为空，则获知可达性验证成功；若变迁表为空，则查找并显示变迁表中变迁对应的BPMN元素，同时判断不通过可达性验证。

2.如权利要求1所述的事件驱动的多流程协同处理系统，其特征在于，所述多流程建模模块包括消息建模子模块，所述消息建模子模块包括：

复合消息类单元，用于创建业务流程的协作图，并在协作图中定义业务流程之间进行消息交互的类型；

消息路由表单元，用于消息交互建模、提取协作图中业务流程的消息路由以及构建消息路由表。

3.如权利要求1或2所述的事件驱动的多流程协同处理系统，其特征在于，所述多流程验证子模块还包括：

安全性验证单元，用于对所述Petri网的安全性进行验证，以及当安全性验证不通过时，定位到业务流程中出现不可控顺序流的节点；

可达图生成单元，用于进行安全性验证时，生成Petri网的可达图，可达图中的状态用于标识当前Petri网中每个库所包含的令牌数；

死锁检测单元，用于当检测到可达图中每个出度为0的节点均对应结束事件时，获知协作图不存在死锁节点；

死循环检测单元，用于当检测到可达图中存在环路时，获知协作图中存在死循环。

4.如权利要求1所述的事件驱动的多流程协同处理系统，其特征在于，所述分布式部署及运行模块包括：

协作图拆分子模块，用于遍历协作视图中的各业务流程，将不同的业务流程提取出来，形成多个单独业务流程，提取过程中各业务流程的内部结构不变，还用于保留业务流程之间交互的消息和单独业务流程的流程图片；

分布式部署和运行子模块，用于显示jBPM服务器的状态、关联各业务流程与jBPM服务器的IP地址，将各业务流程进行打包，并在打包后按照关联结果将业务流程部署至jBPM服务器；所述jBPM服务器的状态为连接状态、未连接状态、启动状态以及未启动状态中的一种。

5.如权利要求1所述的事件驱动的多流程协同处理系统，其特征在于，还包括消息中间件模块，用于采用发布-订阅模式完成分布式通信，自定义发送任务的第一处理程序Handler和接收任务的第二处理程序Handler；

其中，所述第一处理程序Handler用于定义构造消息对象的方法和调用发布-订阅接口向发布/订阅主节点发布消息的方法；所述第二处理程序Handler用于定义监听发布/订阅主节点转发的消息、缓存消息对象的方法，以及处理接收的消息的方法。

6.如权利要求1所述的事件驱动的多流程协同处理系统，其特征在于，还包括流程监控模块，用于查看业务流程的运行状态、在业务流程出现异常时挂起业务流程和在异常排除后恢复业务流程。

7.如权利要求3所述的事件驱动的多流程协同处理系统，其特征在于，所述死循环检测单元具体用于：

S1、将可达图的根节点赋为当前节点；

S2、将当前节点加入至路径集合中，循环遍历当前节点的子节点，对于当前节点的任意一个子节点，若该子节点不在路径集合中，则执行步骤S3；若该子节点已存在于路径集合中，执行步骤S4；

S3、将该子节点赋为当前节点，并返回执行步骤S2；

S4、判断可达图中存在环路，将当前节点加入至节点集合中，同时将当前节点从路径集合中移除。