CN104517189A - 一种基于事件的工作流间协作的系统及方法 - Google Patents

Abstract

本发明公开了一种基于事件的工作流间协作的系统和方法，该系统包括：交互单元、处理单元、分发单元；所述交互单元分别与所述处理单元和总线通信连接，所述分发单元分别与所述处理单元、工作流引擎、所述交互单元通信连接；所述交互单元接收所述总线发送的消息滤除其中的事件传送给所述处理单元，所述处理单元根据事件路由表对交互单元传递过来的数据判定，判定时间消息的层次级别，并提交至分发单元，所述分发单元根据事件层次级别，将消息转发给流程引擎或者通过交互单元发送至总线。本发明能够有效的降低整合异构的工作流系统的成本，不破坏原有的不同系统，从而降低工作流系统间协作的费用，对于流转流协作要求较高的领域。

Description

一种基于事件的工作流间协作的系统及方法

技术领域

本发明涉及一种埋地管道阴极保护数据采集装置，属埋地管道保护于技术领域。

背景技术

国际工作流管理联盟(Workflow Management Coal ition，WfMC)的成立标志着工作流技术开始进入相对成熟的阶段。为了实现不同工作流产品之间的互操作，WfMC在工作流管理系统的相关术语、体系结构及应用编程接口等方面制定了一系列标准。工作流管理联盟给出的工作流定义是：工作流是指整个或部分经营过程在计算机支持下的全自动或半自动化。在实际情况下可以更广泛地把凡是计算机软件系统(工作流管理系统)控制其执行的过程都称为工作流。

EDA(Event Driven Architecture，事件驱动架构)是Gartner在2003年提出的一种基于事件的架构。在该架构中，事件消息独立的、松耦合的在组件间发布或传递，且传递的各方并不了解对方的存在。EDA这种特点将极大改善对各式各样、毫无关联的事件的响应能力。先进EDA技术已经在很多工具中得到了应用。

企业服务总线(Enterprise Service Bus，ESB)的概念是从面向服务体系架构(Service Oriented Architecture，SOA)发展而来的。SOA描述了一种IT基础设施的应用集成模型；其中的软构件集是以一种定义清晰的层次化结构相互耦合。一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。而且现有的大多企业服务总线产品都是基于事件驱动开发的。

工作流系统发展到今天，和不同的技术的结合已经有了很多的尝试，其中尤其是EDA的引入，很多产品有基于事件驱动的工作流的功α。比如IBM，就在工作环境下引入工作流和事件，通过服务总线完成交互的实现。Marechaux等人提出利用ESB(Enterprise ServiceBus)方式来合并实践服务，以实现对事件的检测、触发以及发布等。

但主流的工作流的发展趋势仍然是主要解决简单的工作流问题，对于复杂的流程的交互的工作环境的支持并不够。较多的内容由开发人员使用手写代码完成，复用性并不好。现在的工作流系统大多引入了事件驱动的概念，但是支持并不完善，只是简单的部分的解决了对于单个工作流的支持，而且并不包括代码自动生成和自动化部署，不支持事件的建模。而对于事件的完美支持，可以很好的解决工作流之间的逻辑耦合问题。

复杂的流程环境不管是对于设计者和开发者都是一个挑战，而不难看出，对于复杂的工作环境，主要需要解决的问题是保证逻辑准确的情况下，如何更好的协同合作的问题，而且，其中引发的关于某些开发内容需要复用的问题，也是不容忽视的。

发明内容

本发明要解决的技术问题是：了减少流程之间的逻辑耦合，以减轻流程设计人员在设计之初的逻辑负担。

为实现上述的发明目的，本发明提供了一种基于事件的工作流间协作的系统，包括：

交互单元、处理单元、分发单元；

所述交互单元分别与所述处理单元和总线通信连接，所述分发单元分别与所述处理单元、工作流引擎、所述交互单元通信连接；

所述交互单元接收所述总线发送的消息滤除其中的事件传送给所述处理单元，所述处理单元根据事件路由表对交互单元传递过来的数据判定，判定时间消息的层次级别，并提交至分发单元，所述分发单元根据事件层次级别，将消息转发给流程引擎或者通过交互单元发送至总线。

其中较优地，所述交互单元包括：

总线消息交互模块、内部消息交互模块、事件过滤模块、和消息解析模块；

所述总线消息交互模块与总线建立连接向总线订阅交互事件，向总线接收或发送事件；所述消息解析模块接收交互单元传输的消息后解析并传送至事件过滤模块，过滤后发送到内部消息交互模块，内部消息交互模块发送至所述处理单元；内部消息交互模块接受分发单元的消息，再将消息发到解析模块封装，然后由总线消息交互模块发出，再发送至总线。

其中较优地，所述处理单元包括：

持久化模块、绑定模块和路由模块；

所述路由模块与所述持久化模块、所述绑定模块通信连接；

绑定模块用于绑定流程引擎，对工作流引擎进行实时监控，解析其中的流程信息，节点信息和事件信息，在系统初始化时，进行绑定，并把信息交给路由模块处理；

路由模块解析流程信息和时间信息，构建全局视图，进行事件路由；

持久化模块，在整个系统中需要对事件表存储。

其中较优地，所述分发单元包括：消息封装模块和消息发送模块；

其中消息封装模块先对事件消息解析，根据事件的层次定位到消息的目的地，然后将消息封装成可用的结构，将其递交给消息发送模块；消息发送模块将消息传递给指定的模块。

另一方面，本发明还提供一种基于事件的工作流间协作的方法，包括如下步骤：绑定工作流引擎，绑定总线；

解析业务流程管理模型，得到各节点的属性信息，流程信息和事件信息；

对工作流引擎实时监控，获取事件消息；

根据事件消息生成与对应的事件路由表；

根据所述事件路由表，对每次的事件通信进行路由。

其中较优地，所述根据所述事件路由表，对每次的事件通信进行路由的步骤具体包括：

S1：对工作流引擎进行实时监控，获取事件消息；

S2：根据当前事件消息比对事件路由表；如有相应的事件，则执行S3，否则执行S4。

S3.根据事件路由表上的指定信息，将封装好的事件消息，发送到分发单元。

S4.在事件路由表中注册当前事件消息的内容,返回S1；

S5.分发单元根据事件消息的目的地，将事件消息发给流程实例的任务节点；

S6.交互单元将事件消息封装，发送给总线系统。

其中较优地，所述将事件消息发给流程实例的任务节点的步骤具体包括：

判断是否有流程实例；

若无流程实例，则根据流程启动相应的流程实例，再发送；

若流程实例不在本流程引擎内部，则分发给交互单元处理。

其中较优地，所述分发单元根据事件消息的目的地，将事件消息发给流程实例的任务节点的具体步骤包括：

处理单元解析事件消息，判断事件路由表是否中是否有处理这个事件消息的条件；

如果有处理这个事件消息的条件，则交给分发单元，由分发单元将消息给目标流程实例；

如果无处理这个事件消息的条件，则交给交互单元，由交互单元发给总线，去寻找其他流程引擎。

本发明提供的基于事件的工作流间协作的和方法，具有良好的易用性，不改变有用系统，即插即用。本发明具有良好的可扩展性，基于本系统的核心特征，对于不同近期可以轻量级的适配，可扩展性高。高效性，本系统可以大大减轻流程设计人员的工作，具有很好的高效性。

附图说明

图1为本发明实施例的工作流间协作的系统的结构示意图；

图2为本发明系统的交互单元组成结构示意图；

图3为本发明系统的处理单元的组成示意图；

图4为本发明实施例的工作流间协作的方法的示意图；

图5为本发明系统的业务流程环境的示意图；

图6为本发明实施例的流程间协作示意图；

图7为供暖系统报警流程与保修流程协作实例示意图；

图8为供暖系统保修流程与审计流程协作实例示意图。

具体实施方式

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

如图1所示，本发明提供一种基于事件的工作流间协作的系统，包括：交互单元、处理单元、分发单元；所述交互单元分别与所述处理单元和总线通信连接，所述分发单元分别与所述处理单元、工作流引擎、所述交互单元通信连接；所述交互单元接收所述总线发送的消息滤除其中的事件传送给所述处理单元，所述处理单元根据事件路由表对交互单元传递过来的数据判定，判定时间消息的层次级别，并提交至分发单元，所述分发单元根据事件层次级别，将消息转发给流程引擎或者通过交互单元发送至总线。下面对本发明提供的基于事件的工作流间协作的系统展开详细的说明。

如图2所示，交互单元包括：总线消息交互模块、内部消息交互模块、事件过滤模块、和消息解析模块；所述总线消息交互模块与总线建立连接向总线订阅交互事件，向总线接收或发送事件，并接受分发单元路由过来的消息；所述事件过滤模块用于对接收到的原始事件进行过滤，滤除事件中的噪声，过滤事件的不同层次，判断事件是否需要向下传递；所述消息解析模块用于事件的解析、整合，将其传换成统一的消息格式，并传递给处理单元进行下一步处理。具体地：

交互单元包含四个模块：总线消息交互模块、内部消息交互模块、事件过滤模块和消息解析模块。其中总线消息交互模块，与总线系统建立连接，向总线系统订阅交互消息事件，向总线系统接收或者发送事件，并且接收分发单元路由过来的消息；事件过滤模块用于对接到的原始事件进行过滤，滤除事件噪声，只留下有意义的、与业务逻辑紧密相关的事件，过滤事件的不同层次，判断事件是否需要向下传递；消息解析模块用于事件的解析、整合，将其传换成统一的消息格式，并传递给处理单元进行下一步处理。

总线消息交互单元是一个发布/订阅消息系统的客户端，总线作为一种透明的结构，链接不同系统间的总线消息接收模块。发布/订阅是一种消息范式，消息的发送者把将要发布的消息标记为不同的类别，不需要知道具体的接收者，接收者只需要订阅这个消息类别就可以接收到这个消息。订阅者可以对一个或多个类别感兴趣，只需接收感兴趣的消息，同样不需要知道发布者到底是什么。这种发布者和订阅者的解耦带来了更好的可扩放性和更为动态的网络拓扑。

系统初始化时，总线消息交互单元会绑定总线系统，订阅感兴趣的主题。当总线系统接收到同主题的数据时，将数据转发给交互单元的总线消息交互单元。总线消息交互单元将数据转发至处理单元，处理单元的路由模块调用事件过滤模块对接收到的消息过滤，事件过滤模块会对接收到的消息进行过滤。事件层次过滤模块的实质是一个事件处理引擎。由于发布订阅模式对于主题的要求，系统会接收所有消息，如果对它们全部都进行处理，既无必要，也会浪费宝贵的计算资源。在此模块内部过滤消息层次，排除不需要处理的事消息。事件过滤模块利用事件处理引擎，根据工作流事件的匹配规则过滤事件。最后，消息解析模块把这些已过滤的事件发送给消息解析模块，由消息解析模块整合成特定的事件消息格式，以供处理单元处理。

如图3所示，所述处理单元包括：持久化模块、绑定模块和路由模块；所述路由模块与所述持久化模块、所述绑定模块通信连接；绑定模块用于绑定流程引擎，对流程引擎进行实时监控，解析其中的流程信息，节点信息和事件信息，在系统初始化时，进行绑定，并把信息交给路由模块处理；路由模块解析流程信息和时间信息，构建全局视图，进行事件路由；持久化模块，在整个系统中需要对事件表存储。具体地：

处理单元包含三个模块：持久化模块、绑定模块和路由模块。绑定模块用于绑定流程引擎，对流程引擎进行实时监控，解析其中的流程信息，节点信息和事件信息，在系统初始化时，进行绑定，并把信息交给路由模块处理。路由模块在系统中位于核心位置，其工作内容包括，解析流程信息和时间信息，构建全局视图，进行事件路由。最后是，持久化模块，在整个系统中需要对事件表存储。处理单元的大致步骤如下：

1.初始化系统，初始的事件路由表由设计人员导入。绑定流程引擎，将初始化的流程信息和事件信息初始化到工作内存中；

2.持续对流程引擎进行监控，监控流程实例发出的事件消息，实时更新事件表，并将事件表存储；

3.整合流程信息和事件信息，呈现全局化的事件表，在系统运行过程中以视图呈现；

4.对于新输入的事件消息，查阅事件表，从而整合事件消息的层次，然后将事件消息送到分发单元。

分发单元主要包含两个模块：消息封装模块和消息发送模块。其中消息封装模块先对事件消息解析，根据事件的层次定位到消息的目的地，然后将消息封装成可用的结构，将其递交给消息发送模块；消息发送模块将消息传递给指定的模块。

为进一步体现本发明提供的基于事件的工作流间协作的系统的优越性，本发明还提供一种应用上述系统的基于事件的工作流间协作的方法，如图4所示，该方法包括如下步骤：绑定工作流引擎，绑定总线；解析业务流程管理模型，得到各节点的属性信息，流程信息和事件信息；对工作流引擎实时监控，生成全局事件表，生成数据持久数据；根据各节点的所述流程信息，节点信息和事件信息，生成显示数据并显示；根据所述流程信息，节点信息以及所述视显示数据，对事件信息路由处理。下面对本发明提供的基于事件的工作流间协作的方法展开详细的说明。

步骤101：分发单元绑定流程引擎,交互单元绑定总线。

具体地，处理单元中的绑定模块解析连接流程引擎，保持实时通信。所述绑定模块，连接到流程引擎，并持续监控，实时控制数据。

步骤102：处理单元解析业务管理流程模型，解析JBPM流程模型，得到各节点的属性信息、流程信息和事件信息。

具体地，解析业务流程处理装置中的业务流程管理模型JBPMJ得到各节点的属性信息。属性信息包括：节点名称、任务的执行者、节点的迁移路径。其中，节点的迁移路径可以是一条或者多条。

解析所述业务流程管理模型JBPM，得到事件信息；其中，事件信息是工作流建模过程中加入的事件信息。

步骤103：处理单元中的绑定模块对流程引擎实时监控，生成全局事件表，并保存。

具体地，所述根据所述业务数据表，并保存数据，包括：根据所述事件表的数据结构，生成与所述事件表对应的Pojo类文件、Hibernate映射文件、Service类文件、Dao类文件、业务配置文件。上述方案中，与所述全局事件表对应是指与所述全局事件表的名称相对应。这里，在Service类文件中，需引用与其名称相对应的Dao类文件的一个实例。

上述方案中，生成与所述业务数据表对应的Pojo类文件，具体为：获取全局事件表的字段类型和字段名称；向Pojo类文件中写入与所述全局事件表的字段类型和字段名称对应的属性信息，同时写入每个属性信息所对应的获取(getter)应用和设置(setter)应用。

步骤104：处理单元中的路由模块根据各节点的所述流程信息，节点信息和事件信息，生成显示数据并显示。

优选地，所述根据所述流程信息，节点信息和事件信息，生成显示数据并显示的具体步骤包括：根据所述流程信息，节点信息和事件信息，生成超文本标记语言Html标签；基于所述Html标签，生成显示数据并显示。

步骤105：处理单元根据所述流程信息，节点信息以及所述显示数据，对事件消息路由。

处理流程的方法的整体步骤包括：

S1.流程实例运转到某一任务节点，任务节点产生事件消息。事件消息形如(ID,eventID,name,proinstanceID,taskID,VARIABLES，action)。

S2.处理单元中的绑定模块监控到事件消息，交给路由模块，路由模块比对事件路由表。如有相应的事件，则进入3，否则进入4。其中，路由表形如(ID,eventID,condition，action)，ID与事件消息对应，则表示同一事件会导向同一个流程，eventID与事件消息对应，则表示同一个流程实例，将唯一导向同一流程实例，condition和action表征条件及动作。

S3.根据事件路由表上的指定信息，将封装好的事件消息，发送到分发单元。封装后的事件消息形如(Content，Event)，Content表征事件消息的内容及类型，Event为原事件消息。

S4.本事件消息的内容在事件路由表中注册，包括流程实例信息。此时发出事件消息的流程实例，处于挂起状态，直到绑定模块监控到了相应的事件消息，从而根据事件路由表中的注册信息再次激活流程实例。这种激活的行为，是通过设计人员对全局视图的观察，发现需要处理的事件消息，设计并启动相应的流程实例达到的。

S5.分发单元根据事件消息的目的地，将事件消息发给流程实例的任务节点，若无流程实例，则根据流程启动相应的流程实例，再发送。若流程实例不在本流程引擎内部，则分发给交互单元处理。

S6.交互单元将事件消息封装，发送给总线系统，经总线系统路由，发送给知道的流程引擎。封装后的事件消息形如(Topic，Message)，topic内封装了Content和单独的表征事件类型的Type信息，Message内封装的是Eevent。

S7.指定的流程引擎的交互单元接收到消息后，解析交给处理单元，其后续行为同步骤S2及其以下。

优选地，对事件消息路由的具体步骤包括：

针对每个节点，根据所述节点的信息、相应的流程信息和时间信息，生成与所述节点对应的事件路由表；处理单元根据所述事件路由表，对每次的事件通信进行路由，具体步骤如图5，分对外路由和对内路由。

优选地，所述根据所述对事件的路由，分为静态路由和动态路由，其中事件消息的结构描述为：

E＝(ID,eventID,name,proinstanceID,taskID,VARIABLES，action)，其中：ID，为事件实例标识符，在流程引擎中唯一标识一个事件，在事件发起时由系统自动产生；eventID，为事件标识符，在事件路由表中定义，在事件流通过程中，标识事件的行为；name，事件消息的名字；proinstanceID，为流程实例标识符，接收事件时定位到指定流程；taskID，为活动节点标识符，接收事件时定位到指定活动节点；VARIABLES，为业务数据的数组，在发出事件时，指定各字段的名，在接收事件时，指定各字段的值；action，预留字段，在事件消息需要定位时目标节点时，帮助消息定位任务节点。

处理事件消息的静态路由处理过程具体过程包括：

S201:流程实例产生事件消息，将事件消息交给处理单元；

S202:处理单元解析事件消息，判断事件路由表是否中是否有处理这个事件消息的条件，在这里静态路由意味着对于事件的处理已经嵌入到路由表中；

S203:如S202中的消息，如果是目标在本流程引擎内，则交给分发单元，由分发单元将消息给目标流程实例；

S204:如S202中的消息，如果是目标在其他流程引擎，则交给交互单元，由交互单元发给总线，去寻找其他流程引擎。

处理事件消息的动态路由处理过程具体过程包括：

S301:流程实例产生事件消息，将事件消息交给处理单元；

S302:处理单元解析事件消息，判断事件路由表是否中是否有处理这个事件消息的条件，在这里静态路由意味着对于事件的处理未嵌入到路由表中；

S303:通过流程人员对全局事件的监控，对于可以处理的事件项目，生成单独的流程实例处理事件路由表中的路由项，其具体过程怎等同于静态路由的处理过程。

下面以供暖系统为例，对本发明实施案例的流程间协作方法做进一步的说明。图6为本发明实施例的流程间协作系统在工作流系统中的位置示意图，供暖系统主要有四大块组成，报警流程工作流引擎，报修流程工作流引擎，计费工作流引擎和审计工作流引擎。四大工作流引擎由于安全的考虑或者是历史问题，未能集成到同一工作流引擎，所以应用本工作流间协作系统，对原有工作流引擎进行组合。报警流程会触发报修流程，通知启动报修流程，报修流程会涉及到计费问题和审计问题。

本系统的宗旨在于不破坏原有工作流引擎，对现有异构工作流引擎进行交互。所以在工作流引擎初始化阶段主要有两阶段的工作，

在工作流设计阶段，在原有设计工具中加入事件化工作流节点，<event form＝"EVENT"eventId＝"00030"condition＝""action＝""g＝"219,179,104,52"name＝"报修"><transition to＝"派遣维修员"/></event>，审计任务节点插入原来设计的工作流程的不同任务节点中间，不影响原有工作流工作。在工作流引擎业务数据库中加入EVENT数据库表单，工作流引擎API中加入对event节点的操作，其主要有四个属性值eventId，condition，action，name，通过API在流程中任务节点的流转过程中，将属性值存入数据库，持久化模块监控数据库，以后续的使用。name属性宽泛表征事件消息，便于第一次过滤，比如报修事件，有报修启动和报修结束，若流程实例只接收报修事件则可以将其他事件均忽略，在流程内部再对启动和结束事件进行筛选。eventId对事件消息精准比对。condition代表事件消息的动作的条件，空值表示广播，action代表事件消息的动作。在流程设计阶段的事件任务节点，其事件消息是发送的消息，act ion属性一般为空值，由流程引擎API在工作流程中任务节点运转过程中填充。

另外对于新设计的工作流，可以利用改造的工作流设计工具，普通的任务节点加入了事件消息功能。<taskcandidate-groups＝"accepters"eventForm＝"EVENT"eventName＝"报修"condition＝"out"action＝""g＝"219,179,104,52"name＝"受理报修"><transition to＝"派遣维修员"/></task>。本task节点自带了事件消息，对于原有的工作流引擎API，加入了对其四个属性的功能。其属性值同上。

持久化模块要监控数据库，对事件消息实时处理，其中一部分要在初始化阶段初始化内部事件路由表单。同样是根据报修事件消息，事件表单的一条记录为(ID＝"00030"，NAME＝"报修"，COND＝"in"，ACT＝"pid＝1346812397859")。事件路由表会以视图形式呈现，管理人员可以对事件路由表监控，对于普通的事件消息，事件消息本身带有的属性可以完成路由的情况。但是对于一些事件消息中未指明的情况，管理人员可以对于新增加的事件定向，也就是在ACT中加入目标流程的信息。

图7图8为本系统基本的业务流程实例，图7为结合静态和动态路由的基本业务流程，下面结合供暖系统的情况对本发明实施例的代码生成方法做进一步详细说明。

步骤701：底层数据采集到了报警信号。报警流程工作流引擎对报警信号处理，诊断报警信号，发出报警音，提醒值班人员。普通的流程引擎一般运行到这里。经过对报警流程工作流引擎的改造，在报警流程实例中在触发报警音的活动节点，加入发出报警事件消息。(ID＝0001,eventID＝00040,name＝"报警"，proinstanceID＝1346812398840,taskID＝140006)。

步骤702：处理单元的绑定模块监听报警流程工作流引擎中的报警事件，绑定模块将监听到的报警事件发送至路由模块，路由模块比对事件路由。匹配(ID＝"00040"，NAME＝"报警"，COND＝"out"，ACT＝"")。对于没有初始化注册到事件路由表的事件和首次出现的事件消息，设计人员观察到事件消息后，为事件消息指派动作，并在事件路由表中注册，同时更新显示的数据。对于本消息，因为COND＝"out"，ACT为空值，则直接广播。

步骤703：路由模块根据路由表地址封装事件消息，交给分发单元，分发单元递交给交互单元，再递交给总线系统，经总线系统发送到指定的报修流程工作流引擎的交互单元。

步骤704：处理单元中的路由模块匹配路由表，发现(ID＝"00040"，NAME＝"报警"，COND＝"in"，ACT＝"pid＝1346812397869")，没有task_id，所以直接启动指定pid的报修流程实例来处理。

步骤705：报修流程实例处理完事件之后，根据事件消息带有的task_id(任务节点的id同事件消息中的taskID)和pid(任务节点的流程实例id同事件消息中的proinstanceID)原路返回，提示值班人员已经处理此报警。

由此可以看出，对于事件消息的路由分为静态和动态，静态一般在系统初始化时，会封装到事件路由表，动态需要设计人员对事件消息进行指派，指派之后一般会形成固定路径，从而在下次处理同一事件消息变为静态。在图中右侧，指明了一种比较常见的事件一对多模式，本系统也有支持。

图8涉及到特殊的事件消息传送，具体过程如下：

步骤801：报修流程被发起。维修人员接单的任务节点，会产生报修启动事件消息。(ID＝0002,eventID＝00030,name＝"报修"，proinstanceID＝1346812398840,taskID＝130006)。

步骤802：处理单元的绑定模块检测到报修流程工作流引擎中报修启动事件消息，处理单元将报修启动事件消息发送到路由模块，路由模块查阅事件路由表。匹配(ID＝"00030"，NAME＝"报修"，COND＝"out"，ACT＝"")的路由项。报修启动事件消息发送到分发单元，分发单元交给交互单元，再由其递交给总线系统，广播出去消息。由于审计功能和计费功能在原始设计中就有参考，所以在审计流程引擎的路由表的初始化中就加入其中，(ID＝"00030"，NAME＝"报修"，COND＝"in"，ACT＝"pid＝1366812297860，task_id＝1600")。对于审计流程，系统运行后审计流程实例随即启动，交互单元收到报修事件消息，交给路由模块直接找到到相应任务节点，再由分发单元发送到相应的任务节点。报修消息会在审计流程实例的报修任务节点中记录。

步骤803：报修启动消息经如上同样的流程，经本系统发送到计费流程引擎。

步骤804：计费流程引擎中的处理单元接收到消息后，匹配路由表(ID＝"00030"，NAME＝"报修"，COND＝"in"，ACT＝"pid＝1346812398845")，交给分发单元，分发单元启动计费流程实例。

步骤805：报修流程处理完后，产生报修结束事件。(ID＝0003,eventID＝00031,name＝"报修结束"，proinstanceID＝1346812398840,taskID＝130008)路由方式同报修启动消息，但是在匹配路由表中(ID＝"00030"，NAME＝"报修"，COND＝"answer"，ACT＝"")，由于COND＝"answer"，本事件消息需要应答，所以除了原来的操作还需要在路由表中加入本事件消息(ID＝"00030"，NAME＝"0003"，COND＝"answer"，ACT＝"1346812398840130008")。同时审计流程引擎接收消息并处理这一事件的方式同报修启动事件一致。

步骤806：计费流程接收消息并处理。在接收到报修结束消息之后，计费完成，产生完成计费事件消息(ID＝0001,eventID＝00040,name＝"计费完成"，proinstanceID＝350002,taskID＝300006，act ion＝"1346812398840130008")。本事件消息经过计费流程引擎的模块从总线广播出去,在报修流程引擎中接收到事件消息后，比对路由项，对于成功比对的ACT属性，就定位到了相应的任务节点，再由分发单元发送到相应的任务节点。

由于审计流程引擎和报修流程引擎的脱离，可以很好的解决安全性问题。在总线系统中，报修事件的消息为(Topic＝"报修",type＝00,Message＝event)会有统一的一级标题Topic，报警流程引擎，审计流程引擎和计费流程引擎，会根据事件消息中封装的类型Type属性，区分其为报修启动和报修技术，从而做出不同的操作，或者不做操作，将消息过滤掉。

综上所述，本发明提供的基于事件的工作流间协作的系统和方法有以下两方面的优点。

第一方面、总线环境下消息驱动与不同的流程间相融合，从而达到不同流程间的交互。总线技术利于透明传输，基于发布/订阅的消息传递可以尽可能的减少系统的耦合程度，对外提供透明的接口，大大降低了系统的复杂度，使得整个系统由消息驱动起来。一旦处置逻辑需要变化，只需要修改相应的流程或者web服务，将流程重新部署即可，不会影响系统自身，最大限度体现了系统的灵活性和异构性。分散不同的逻辑到不同的流程中，利用设计。

第二方面、事件处理方式的应用。由于业务逻辑的不断复杂，对流程的要求也越来越多，无法提供合适的流程粒度，事件驱动的流程引擎，好处就在于可以解耦流程与流程节点，并且使用事件处理技术，可以从原子事件中提取、过滤出有价值的、有意义的基本事件，或者更进一步，将基本事件组合成复杂事件，这也就是时间分层。系统可以有针对性的对这些事件进行分析处理，将系统的其他单元从海量事件中解放出来，同时也达到了计算资源的更高效使用。

以上实施方式仅用于说明本发明，而并非对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本发明的范畴，本发明的专利保护范围应由权利要求限定。

Claims (8)

1.一种基于事件的工作流间协作的系统，其特征在于，包括：

交互单元、处理单元、分发单元；

所述交互单元分别与所述处理单元和总线通信连接，所述分发单元分别与所述处理单元、工作流引擎、所述交互单元通信连接；

所述交互单元接收所述总线发送的消息滤除其中的事件传送给所述处理单元，所述处理单元根据事件路由表对交互单元传递过来的数据判定，判定时间消息的层次级别，并提交至分发单元，所述分发单元根据事件层次级别，将消息转发给流程引擎或者通过交互单元发送至总线。

2.如权利要求1所述的工作流间协作的系统，其特征在于，所述交互单元包括：

总线消息交互模块、内部消息交互模块、事件过滤模块、和消息解析模块；

所述总线消息交互模块与总线建立连接向总线订阅交互事件，向总线接收或发送事件；所述消息解析模块接收交互单元传输的消息后解析并传送至事件过滤模块，过滤后发送到内部消息交互模块，内部消息交互模块发送至所述处理单元；内部消息交互模块接受分发单元的消息，再将消息发到解析模块封装，然后由总线消息交互模块发出，再发送至总线。

3.如权利要求1所述的工作流间协作的系统，其特征在于，所述处理单元包括：

持久化模块、绑定模块和路由模块；

所述路由模块与所述持久化模块、所述绑定模块通信连接；

绑定模块用于绑定流程引擎，对工作流引擎进行实时监控，解析其中的流程信息，节点信息和事件信息，在系统初始化时，进行绑定，并把信息交给路由模块处理；

路由模块解析流程信息和时间信息，构建全局视图，进行事件路由；

持久化模块，在整个系统中需要对事件表存储。

4.如权利要求1所述的工作流间协作的系统，其特征在于，所述分发单元包括：消息封装模块和消息发送模块；

其中消息封装模块先对事件消息解析，根据事件的层次定位到消息的目的地，然后将消息封装成可用的结构，将其递交给消息发送模块；消息发送模块将消息传递给指定的模块。

5.一种基于事件的工作流间协作的方法，其特征在于，包括如下步骤：

绑定工作流引擎，绑定总线；

解析业务流程管理模型，得到各节点的属性信息，流程信息和事件信息；

对工作流引擎实时监控，获取事件消息；

根据事件消息生成与对应的事件路由表；

根据所述事件路由表，对每次的事件通信进行路由。

6.如权利要求5所述的工作流间协作的方法，其特征在于，所述根据所述事件路由表，对每次的事件通信进行路由的步骤具体包括：

S1：对工作流引擎进行实时监控，获取事件消息；

S2：根据当前事件消息比对事件路由表；如有相应的事件，则执行S3，否则执行S4。

S3.根据事件路由表上的指定信息，将封装好的事件消息，发送到分发单元。

S4.在事件路由表中注册当前事件消息的内容,返回S1；

S5.分发单元根据事件消息的目的地，将事件消息发给流程实例的任务节点；

S6.交互单元将事件消息封装，发送给总线系统。

7.如权利要求6所述的工作流间协作的方法，其特征在于，所述将事件消息发给流程实例的任务节点的步骤具体包括：

判断是否有流程实例；

若无流程实例，则根据流程启动相应的流程实例，再发送；

若流程实例不在本流程引擎内部，则分发给交互单元处理。

8.如权利要求5所述的工作流间协作的方法，其特征在于，所述分发单元根据事件消息的目的地，将事件消息发给流程实例的任务节点的具体步骤包括：

处理单元解析事件消息，判断事件路由表是否中是否有处理这个事件消息的条件；

如果有处理这个事件消息的条件，则交给分发单元，由分发单元将消息给目标流程实例；

如果无处理这个事件消息的条件，则交给交互单元，由交互单元发给总线，去寻找其他流程引擎。