XPDL与BPEL工作流比较
BPEL 及其发展历程
目录
1.BPEL 及其发展历程 (2)
1.1.SCA不能解决的问题 (3)
1.2.BPEL应运而生 (5)
1.3.BPEL就是顺应了SOA潮流 (7)
1.4.BPEL规范的设计原则 (7)
1.5.BPEL规范具有以下特点 (10)
1.5.1.异构执行 (10)
1.5.2.高度的松耦合性 (10)
1.5.3.服务的重用性 (10)
1.5.4.高度的敏捷性 (11)
2.BPEL相关技术 (11)
2.1.Web服务 (12)
2.1.1.Web服务描述语言 (13)
2.1.2.BPEL规范与Web服务标准关系 (19)
3.初识BPEL (21)
3.1.活动的分类 (23)
3.2.BPEL引擎 (24)
3.3.间接支持BPEL的流程引擎 (26)
3.4.BPEL与SOA (29)
1规范发展篇 (44)
2二者内容的大致概述 (46)
2.1.规范内容层次 (46)
2.2.XPDL相比WS-BPEL缺乏的部分 (46)
3人工活动 (47)
4工作流模式 (48)
5形势与未来 (49)
5.1.标准不决定解决方案的成败 (49)
5.2.WfMC在中国还是被认可，还是比较成熟的 (49)
5.3.xpdl已入暮年，ws-bpel的未来存在变数 (49)
1.BPEL 及其发展历程
作为SOA 的关键技术，SDO 和SCA 分别为SOA 提供了数据模型和服务组件模型的定义标准。那么到目前为止，SOA 是否能解决用户所面临的所有业务问题呢？让我们先来看看下面的例子。
一个企业将提供一个订单处理服务。这个订单处理服务在接收到订单后，调用其内部的订单审核服务，而后调用银行提供的支付服务以支付货款，最后调用物流公司，提供的送货服务将货物送给客户。这里用户所要做的就是调用订单处理服务下订单，而后他就可以坐等货物的到来了。他不需知道这个订单处理服务的内部都干了些什么。图14-1 描述了这一场景。
图14-1 订单处理场景
目前有三个现存的服务：企业内部的订单审核服务，银行提供的支付服务，以及物流公司提供的送货服务。在SOA中，我们可以将它们封装成三个SCA 组
件，而用户输入的订单数据可以用SDO 来建模。现在我们需要解决的问题是，如何将这三个SCA组件以想要的顺序进行调用，而这一调用过程对用户来说又是透明的呢？
1.1.SCA不能解决的问题
通过前面SCA 的相关章节，我们知道SCA 规范定义了SCA 组件的封装标准以及如何将多个SCA 组件进行连接（wire）。SCA组件之间的连接表明了这两个SCA组件之间有服务的调用的关系，即一个SCA组件的实现调用了另外一个SCA组件的服务。我们这个场景中的三个SCA组件是相互独立的，它们之间并没有服务的调用关系。我们无法用SCA组件的连接来达到目的。看来我们还需要提供另外一个SCA组件，这个SCA组件的实现将分别调用订单审核、支付服务以及送货服务这三个SCA组件。实际上，这个SCA组件的实现就是一个业务流程逻辑，它将按照业务需求，以一定的顺序调用现存的服务。也就是说，这个SCA组件实现了对其他SCA组件的编排。而用户只需要调用这个SCA组件就可以获得所需的流程服务。
图14-2说明了这一场景。
图14-2 SCA组件化的订单处理场景
可以看到，订单处理SCA将按照顺序调用订单审核SCA，支付SCA以及送货SCA。我们该如何实现这个订单处理SCA呢？订单处理SCA是按照预定的业务逻辑调用现有的SCA组件，从而形成了一个业务流程，但它本身并不涉及任何具体服务的实现。我们可以选择C++，Java等编程语言来实现这样的调用逻辑，但这将面临以下问题：
无法以图形化的方式将业务流程逻辑展现给用户。在流程的设计上，我们将不得不借助于图形工具来直观地表现流程逻辑，而后再由编程人员根据这个流程逻辑进行编程实现。业务流程设计人员与IT的设计人员将使用不同的表达方式进行各自的设计，他们之间将存在沟壑并带来理解上的差异。表达方式的不一致最终可能导致系统的实现与最初的业务需求不能吻合，同时这也与SOA的业务与IT对齐的思想相违背。
维护上的困难。企业经常会根据实际需求不断调整流程逻辑。一旦流程出现任何改变，我们将不得不相应修改代码，重新编译部署。这样必将付出较大代价。
无法抽象出组件化的流程语义。纷繁复杂的业务流程也蕴涵着某些共性的逻辑，我们可以把它们抽取出来以便重用。比如刚才的订单处理流程以串行的方式调用了一系列的服务，因此我们可以抽象出串行组件来为流程的建模使用。同样，实际的流程还可能有并行处理的组件，循环调用的组件等。代码实现的流程逻辑很难进行这种流程级别的粗粒度的抽象。即使能够将相应的实现封装成类库来重用实现逻辑，这也只能是企业内部或局部范围的代码级别的重用，而无法形成统一的标准和语义。
看来我们还需要一种标准，它能按照业务需求完成多个SCA组件的调用与编排，从而形成业务流程服务。具体来说，这个标准应具备以下特点：
●完全支持SCA组件的调用；
●只是定义服务的调用逻辑与规则，不应涉及具体的服务实现；
●能够支持将SDO定义的业务对象定义为流程的接收参数，服务的调用参数
以及流程的中间变量；
这个标准定义的业务流程本身也能够被封装为SCA服务组件对外提供服务。
1.2.BPEL应运而生
我们知道，SCA的服务调用以及接口描述都基于Web服务，而SDO的建模则基于XML Schema。对这两者都能进行很好支持的WS-BPEL标准自然成为合适的选择。
BPEL（Business Process Execution Language）即业务流程执行语言，是业界在以XML、Web服务为基础的诸多规范之上提出的一种新型的业务流程定义语言。它以业务流程及其参与者的交互为基础定义了业务流程的描述语法，用于业务流程建模。其中，业务流程及其参与者的交互用Web服务接口标准加以描述。因此BPEL流程可直接调用符合Web服务规范的服务。BPEL用来描述多个服务交互的协作与协调，从而对外提供流程服务，以达到某种商业价值。BPEL标准的早期版本称为BPEL4WS（Business Process Execution Language For Web Service），后改名为WS-BPEL（Web Service Business Process Execution Language），可简称为BPEL。
BPEL的前身是IBM的WSFL和Microsoft的XLANG。WSFL即Web Service Flow Language，是一种基于图的流程模型，具有直观性和灵活性的特点。XLANG是以过程代数为基础的工作流程描述语言，在结构化构造方面具有优势。随着Web服务标准的广泛流行，应用程序将以粗粒度的功能为单位，用Web 服务规范封装，对外提供一致的服务。这时，迫切需要一种开放的标准，能够对现存的以及新创建的服务以某种规则进行调度与协调，最终形成具有某种商业价值的业务流程。BPEL标准就是在这种需求下应运而生。
2002年7月，基于WSFL和XLANG，IBM，BEA 和Microsoft提出了BPEL4WS 1.0版本。该标准得到了SAP和Siebel的支持，并在2003.5进行了修正，形成了1.1版本。BPEL融合了这两种标准的长处，继承了图模型的直观性和灵活性，同时又对异常处理进行了很好的支持。2003年4月，OASIS WS-BPEL技术委员会成立（WS-BPEL TC），专门负责BPEL标准的升级与支持。
BPEL标准随后被更新为WSBPEL2.0。WSBPEL2.0已于2007年4月被OASIS 正式批准为BPEL的最新标准。
1.3.BPEL就是顺应了SOA潮流
BPEL标准发布后，由于其以Web服务为基础，与具体的实现无关，具有平台无关性和松耦合性。特别是随着SOA即面向服务的体系结构概念的出现，所有的软件资源与应用都将封装成服务，服务将是基本的操作单位。业务流程在SOA中既是服务的消费者又是服务的提供者。它居于SOA上层，将SOA系统中的孤立服务按照预定的规则进行调度与协调，从而提供有价值的流程服务。BPEL规范的特点使得其在SOA架构中具有固有的优势，被众多的厂商所采用，将BPEL实现作为SOA产品中的一部分提供业务流程服务。
1.4.BPEL规范的设计原则
BPEL所定义的流程实质上是对一系列单个无状态服务的调用与编排，使得这些服务调用按照既定的规则进行。因此BPEL所定义的流程必然涉及与外部服务的交互。其交互接口由WSDL所描述的Web服务接口所定义。从简单性和可重用性考虑，其接口定义应是抽象的，不应涉及服务绑定、服务质量定义等实现相关的细节问题。这些实现相关的定义可在BPEL流程部署时加以确定。
BPEL流程本身也以由WSDL所描述的接口声明为Web服务。在这里，BPEL 实际上作为Web服务的一种实现向外界提供服务调用，实现了与Web服务的无缝兼容，同时也为子流程或嵌套流程的定义提供了解决方案。
BPEL是一种基于XML的标准，只描述业务流程本身，而并不关注业务流程的图形化表示，也不涉及业务流程的设计方法学。不同的厂商可以基于BPEL规范在流程建模工具中提供自己的图形化界面来表示BPEL流程。
BPEL的前身是XLANG和WSFL。XLANG是一种由专门的控制构件构成的结构化的流程建模语言，而WSFL是一种基于加入（join）和转换（transition）条件的、图形化的建模语言。WSFL可以根据流程模式进行图形化的建模，具有很强的直观性，易于图形化建模工具的支持。这两种建模语言都有很大的用户群，因此BPEL的目的是要融和两者的优点，争取最多的用户群，提供一个易于直观的图形化建模，同时又可以不加修改的部署到运行环境上的业务流程语言。因此它的建模视图和执行视图应该是一致的，基于同样的概念集，不需任何转换。
BPEL是以流程规则的定义为中心的，并不是一般意义上的数据操作语言，因此BPEL的数据操作支持应以保证流程建模的需要为基础，提供相对简单的数据操作，比如消息的构建，变量的提取与赋值，简单的数据表达式等。而复杂的数据操作和数据存取功能则应交给BPEL过程所调用的服务来完成，而将结果返回给BPEL过程。
任何流程在执行过程中都可能有异常和错误情况发生。因此BPEL必须将错误和异常情况的处理放在与业务流程本身同等重要的地位。业务流程可能是长期运行的流程并跨越多个事务边界，一旦某个环节发生异常，不可能将整个流程执行中所发生的结果都进行回滚。因此BPEL应提供可定制的错误处理和补偿机制，可在定义流程的同时，根据流程自身的特点、异常类型以及实际需求，定义相应的错误恢复或补偿操作，以应对相应的异常情况。
BPEL定义了流程的模板。在BPEL流程的执行环境中，同一个流程模板可以生成多个BPEL流程实例。同时BPEL的服务调用是松耦合的，它所调用的服务不会保留BPEL的实例信息。在BPEL流程与一个服务进行异步交互时，如何将属于同一交互的消息路由到正确的流程实例，是BPEL必须面对的问题。因此BPEL提供了消息与流程实例的关联机制以解决该问题。为了保持Web服务的实现无关性，这种关联机制必须依赖于业务数据，也就是消息中所携带的业务数据，而不是实现相关的数据，如流程实例的标示符。为此BPEL规范定义了关联集合（correlation set）的概念用于消息和流程实例的关联。用户将一组业务属性定义为关联集合，关联集合必须唯一确定一个BPEL流程实例。BPEL运行环境将消息路由到与该关联集相匹配的流程实例。而且，对于流程中不同的接口，用户可以定义不同的关联集合，以适应不同的业务需求。
由于BPEL本身可以作为Web服务的实现向外界提供服务调用。Web服务是一种无状态的服务描述，而BPEL作为多个服务的协调服务可以看作是一种有状态的服务。对外的无状态性以及自身的有状态性，决定了对BPEL实例的生命周期管理必须是隐含性的。生命周期的隐含性意味着流程实例的创建和销毁是由BPEL运行环境根据到来的消息自动进行的，不需人工干预。因此BPEL服务的调用者也就不能通过Web服务调用直接对BPEL的实例进行管理，如实例的创建，运行实例的挂起与继续，实例的销毁等。这些高级的BPEL生命周期的管理功能将留待今后的版本予以增强。
1.5.BPEL规范具有以下特点
1.5.1.异构执行
基于开放的Web服务标准，易于实现跨系统、跨部门、跨企业的互操作。BPEL的调用对象是Web服务，本身也可以作为Web服务向外提供服务，因此与现有的Web 服务标准相融合。由于Web 服务是开放标准，已被众多的企业所采用，BPEL使建立跨企业的业务流程成为可能。
1.5.
2.高度的松耦合性
BPEL可看作是对多个服务的调度与协调。BPEL本身只定义流程相关的逻辑，具体的功能则由它所调用的服务来实现，与BPEL无关。由于BPEL调用的对象都是一致的Web服务接口，BPEL定义本身只需指定相应的接口即可，不需要指定实现该接口的服务。相应的实现服务完全可以在部署甚至运行时确定。同时，流程与所调用的服务之间以XML形式传递消息，不直接与服务的实现打交道。因此BPEL流程和所调用的服务之间是松耦合的，他们可以独立地进行替换或修改，而不对另一方产生影响。
1.5.3.服务的重用性
由于BPEL流程的调用对象是服务。一个服务在被一个流程调用的同时也可向其他流程，其他客户提供服务。同时BPEL流程本身也可以封装成流程向客户提供服务或是作为子流程为其他流程所重用。这种服务的可重用性为企业的流程管理减少了开发成本，同时也提高了维护效率。
1.5.4.高度的敏捷性
现代企业的业务需求随时都在改变以适应千变万化的市场。这种需求的快速改变也相应对企业的IT基础设施提出了更高的要求。在企业的业务需求改变时，相应的IT设施必须能够快速调整为新的业务需求提供支持。从业务流程的角度来说，相应的业务流程必须能够容易的、快速的甚至是动态的改变才能满足这一要求。正是由于BPEL具有高度的松耦合性和可重用性，才使其具有敏捷性的特点。
2.BPEL相关技术
BPEL作为业务流程的建模语言，基于一系列的开放标准。图14-3是BPEL 及其相关标准的示意图。我们可以看到，在这个类似栈结构的图中，BPEL处于所有标准的顶端。
图14-3 BPEL相关技术示意图
XML是所有标准的基础，它为定义标准提供了表述的形式。XPATH则针对XML文档提供了定位某一数据的手段。XML Schema是定义标准的标准。XML
Schema由XML进行描述，提供了定义标准的语法。SOAP，WSDL以及BPEL 均使用XML Schema进行定义。在BPEL中，XML Schema还被用来定义业务流程的输入输出变量以及中间变量。SOAP为服务调用过程中的消息交换提供了消息的封装标准。WSDL是BPEL流程及其参与者交互时的接口描述语言，同时BPEL流程本身也以WSDL为接口标准对外提供自己的服务。由于BPEL是一种实现无关的标准，其运行环境及其他相关工具可用J2EE、.NET等作为实现平台。Web Service的运行环境则为BPEL流程提供了服务的发布，查询，调用等功能。BPEL则关注于定义流程逻辑，实例关联，错误处理，事件处理，变量定义等与业务流程本身相关的标准。
2.1.Web服务
BPEL起源于Web服务，这里有必要对Web服务作简要介绍。Web服务是Web时代的产物，它可以使得任何信息或服务，无论其原始的实现如何，都封装成统一的形式。用户不需要知道其功能是如何实现的，只要拿到它的接口描述便可以直接访问该服务，如图14-4所示。
图14-4 Web服务场景示意图
Web服务屏蔽了客户与服务提供者之间的系统差异，使得客户可以很容易地访问或调用所需服务。Web服务提供以功能为单位的调用标准，目的是对功能的实现进行基于标准的封装，对服务的调用者展现统一的调用接口，而屏蔽服
务的实现细节。它是一种无状态的功能调用。而当用户需要以某种定制的次序或规则调用多个功能或服务时，Web服务标准本身就显得无能为力了。而这恰恰是BPEL所关注的焦点。因此，BPEL关注于相对独立的服务或功能的组织和协调，从而在整体上形成具有业务价值的业务流程，而所形成的流程作为整体又可以以服务（service）的形式提供给客户。因此，说BPEL是基于Web服务的，是指它的标准特别是服务的调用以及自己向用户提供服务的标准以Web服务为基础，尽量不定义新的标准。BPEL标准所定义的是多个服务调用的协作以及流程的规则，而服务的提供与调用与Web服务相兼容。
2.1.1.Web服务描述语言
WSDL即Web服务描述语言，用于定义在一个Web服务在交互中所需的消息，接口类型，接口参数以及绑定等。下面的XML文档说明了一个WSDL的一般结构。
targetNamespace="the WSDL namespace" xmlns:tns="the WSDL namespace" xmlns:soap="https://www.sodocs.net/doc/2017178236.html,/wsdl/soap"> xmlns:xsd="https://www.sodocs.net/doc/2017178236.html,/2001/XMLSchema"
在定义一个WSDL接口文档时，一般先定义该WSDL所需要的数据类型（type）。当然，数据类型也可以用import元素直接从外部定义文件引入。然后定义消息（message），这些消息将被接口操作定义引用，作为操作的输入输出参数或错误消息定义。定义消息所需要的数据类型应该已经定义或引入。端口类型（port type）实际上就是WSDL的接口定义，其内部定义了该接口所拥有的操作（operation）。操作的输入输出参数将引用消息的定义。绑定（binding）定义了调用Web服务时，输入输出消息采用什么样的协议进行传输。而服务（service）则定义了访问该服务的URL，也就是指出了用户如何才能调用接口提供的服务。可以看出，绑定和服务的定义是与实现相关的定义。而消息及接口的定义则是与实现无关的定义。
假设一个网上商店提供网上直接下订单的Web服务。用户提交订单信息，系统处理订单后返回订单处理结果。消息的传递将采用soap document的方式进行绑定，服务的访问地址是https://www.sodocs.net/doc/2017178236.html,/OrderProcess。相应的WSDL文档如下所示：
targetNamespace="https://www.sodocs.net/doc/2017178236.html,/ OrderProcess.wsdl" xmlns:tns= "https://www.sodocs.net/doc/2017178236.html,/ OrderProcess.wsdl" xmlns:xsd="https://www.sodocs.net/doc/2017178236.html,/2001/XMLSchema" xmlns:xsd1="https://www.sodocs.net/doc/2017178236.html,/ OrderProcess.xsd " xmlns:soap="https://www.sodocs.net/doc/2017178236.html,/wsdl/soap/" xmlns="https://www.sodocs.net/doc/2017178236.html,/wsdl/"> < xsd:sequence> < xsd:element name="orderId" type="string"/> < xsd:element name="productId" type="string"/> < xsd:element name="price" type="string"/> "tns:OrderProcess"> soapAction="https://www.sodocs.net/doc/2017178236.html,/OrderProcess /orderProcess"/> "orderProcessPort">
BPEL规范位于Web服务标准之上，它能够直接基于WSDL接口对Web服务进行调用。图14-5是BPEL规范与Web服务标准的关系图。
2.1.2.BPEL规范与Web服务标准关系
图14-5 BPEL与Web服务示意图
BPEL使用WSDL作为服务调用的接口定义标准。实际上，BPEL通常使用WSDL 定义以下信息：
服务的端口类型（port type）定义；
BPEL流程的伙伴链接类型（partner link type）定义。伙伴链接类型是WSDL 对BPEL的扩展；
BPEL流程的属性（property）及属性别名（property alias）定义。属性及属性别名也是WSDL对BPEL的扩展。
服务的端口类型描述了服务将要调用的接口和对外提供的接口以及它们所包含的操作和操作所用到的参数定义。在SOA中，参数通常是符合SDO标准的业务对象，由XML Schema文件定义。WSDL接口定义将引入业务对象的定义，并将其指定为某个操作的输入输出参数。
BPEL的伙伴链接类型是为了描述BPEL流程及其参与者的交互以及它们在交互中的作用。伙伴连接类型会引用端口类型定义以指出本交互需要调用的接口，同时还定义了交互的角色（role），以指出本流程在这个交互中是服务的提供者，还是服务的调用者。第15章对伙伴链接类型进行了详细的描述。
属性别名则是将某个变量属性或消息部分（part）映射为另一属性名，这样就可以将多个不同消息的部分映射为同一属性名，从而认为它们实际上是同一属性，只是属于不同消息而已。下面的代码实例分别将InputMessage中的orderId和OutputMessage中的orderId映射到了属性OrderNumber上。BPEL流程的关联集合（correlation set）可以引用这一属性将不同消息关联到同一个流程实例。第15章对关联集合的定义和使用进行了详细的描述。
part="OrderInfo" propertyName="tns:OrderNumber">
part="Result" propertyName="tns:OrderNumber"> 业务流(BPM)与工作流(workflow) 的区别 在SOA 实践中，对于 BPM面临着不少困惑与选择，主要是工作流与业务流的架构区别。有些项目把业务流产品用作工作流设计，而有些工作流为主的产品工具却作为业务流实现。这里简单地讨论一下 BPM 中业务流与工作流的作用区别。简要概述了工作流与业务流的主要区别。 工作流与业务流的主要区别 斯欧信息 简言之，业务流程管理主要包含业务建模，组装，部署及管理。使用业务流或工作流工具似乎都能设计开发业务流程管理。但从 SOA 的角度，服务的划分及交互通常是项目关注的重点。所以， SOA 强调的是如何灵活组合业务服务。而业务流的核心功能是编排流程服务，并且主要针对企业级应用整合。同时利用 BPM 工作流的主要功能，诸如 : 活动（任务）节点的人工任务配置，流程运转时的活动节点调控等。 在 SOA/BPM 初始阶段，如果一个企业没有较深的 IT 或 ERP 根基，实施业务流会有相当的阻力。因为业务流程管理并非主要是技术问题。对于有些中小型企业或应用 （ 特别是那些没有规范支撑的人工流程模式 ），一些随意包干，或带有自由流功能的工作流系统一般更易于接受。 对于同样的一个较为复杂的流程应用项目， 如果使用工作流， 会显得很复杂， 结果是很多流程产出件， 而如果使用业务流，一般架构设计较为规范， 流程量骤然减少， 重用性提高。 值得一提的是，工作流与业务流的定义范围有相当程度的交叠与互斥，这取 决于采用的流程管理产品（或几个不同产品）及架构设计及理念。工作流可以理解为技术层面的东西或办公自动化，而 SOA 关注业务流的实现，及与之相关的价值链，并且关注流程的生命周期管理。其实，工作流或业务流本身并无绝对优势，在SOA/BPM 都要用到，如何用好用对才是关键。 Activiti-5.21数据字典 简介 #前缀描述 1ACT_RE_RE表示Repository资源库，保存流程定义，模型等设计阶段的数据。 2ACT_RU_RU表示Runtime运行时，保存流程实例，任务，变量等运行阶段的数据。 3ACT_HI_HI表示History历史，保存历史实例，历史任务等流程历史数据。 4ACT_ID_ID表示Identity身份，保存用户，群组，关系等组织机构相关数据。（Activiti中的组织机构过于简单，仅用于演示。） 5ACT_GE_GE表示General通用，属于一些通用配置。 6其他ACT_EVT_LOG和ACT_PROCDEF_INFO没有按照规则来，两者分别属于HI和RE。 ACT_RE_ ACT_RU_ ACT_HI_ 数据库 #表名描述 1ACT_EVT_LOG事件日志 2ACT_GE_BYTEARRY xml, png等二进制内容3ACT_GE_PROPERTY引擎版本信息 4ACT_HI_ACTINST历史节点 5ACT_HI_ATTACHMENT附件 6ACT_HI_COMMENT评论 7ACT_HI_DETAIL变更历史 8ACT_HI_IDENTITYLINK历史参与者 9ACT_HI_PROCINST历史流程实例 10ACT_HI_TASKINST历史任务 11ACT_HI_VARINST历史变量 12ACT_ID_GROUP群组 13ACT_ID_INFO用户的人员详细信息 14ACT_ID_MEMBERSHIP用户与群组关系 15ACT_ID_USER用户的基本信息 16ACT_PROCDEF_INFO流程定义的动态变更信息17ACT_RE_DEPLOYMENT部署包 18ACT_RE_MODEL模型（用于Web Designer）19ACT_RE_PROCDEF流程定义 20ACT_RE_EVENT_SUBSCR事件监听 21ACT_RU_EXECUTION流程实例与分支 22ACT_RU_IDENTITYLINK参与者 23ACT_RU_JOB异步作业 24ACT_RU_TASK任务 25ACT_RU_VARIABLE变量 ACT_EVT_LOG 事件日志，默认不开启。 #字段名字段类型长度空默认描述主 键 外 键 1LOG_NR_BIGINT19主键自 增2TYPE_VARCHAR64类型 3PROC_DEF_ID_VARCHAR64流程定义 4PROC_INST_ID_VARCHAR64流程实例 5EXECUTION_ID_VARCHAR64执行 6TASK_ID_VARCHAR64任务 工作流引擎 产品功能介绍V0.07 目录 1.1工作流引擎简介 (4) 1.1.1产生背景 (4) 1.1.2发展阶段 (5) 1.1.2.1EDF(电子数据流)阶段 (5) 1.1.2.2TPF(事务处理流)阶段 (5) 1.1.2.3IMF(整体集成管理流)阶段 (5) 1.1.2.4CPF(知识共享和持续改进)阶段 (6) 1.1.3主要特点 (6) 1.1.4流程定义和运行 (7) 1.1.5流程运转模式 (7) 1.1.6工作流引擎不等于OA系统 (9) 1.2XX工作流引擎 (10) 1.2.1XX工作流引擎简介 (10) 1.2.2产品设计 (11) 1.2.2.1工作流是XX电子政务平台的组件之一 (11) 1.2.2.2工作流引擎设计思想 (12) 1.2.2.3工作流引擎产品架构 (14) 1.2.3产品功能 (15) 1.2.3.1支持流程运转模式 (15) 1.2.3.2设计工具 (19) 1.2.3.3控制平台 (21) 1.2.3.4任务列表 (22) 1.2.3.5流程与用户 (24) 1.2.3.6工作流数据 (25) 1.2.3.7事务处理 (26) 1.2.3.8异常处理 (26) 1.2.4产品安全能力 (26) 1.2.5产品集成扩展 (26) 1.2.6运行环境 (27) 1.3XX工作流引擎适应复杂应用的要求 (27) 1.3.1多机构联合作业 (28) 1.3.2流程的定义集中管理 (29) 1.3.3嵌套子流程和和引用子流程 (29) 1.4XX工作流应用实施方法 (29) 1.4.1点面结合，全面推进 (29) 1.4.2分步实施，适当激励 (30) 1.4.3持续改进，形成文化 (30) 1.5XX工作流引擎成功案例 (30) 1.5.1广州移动广州公务机管理系统 (31) 1.5.1.1实现功能 (31) 1.5.1.2实施效果 (32) 1.5.2广州外经贸网上政务-发文管理 (33) 1.5.2.1实现功能 (33) 1.5.2.2实施效果 (35) activiti流程开发指南 ?一、BPMN ?二、activiti主要接口 ?三、如何实现一个业务流程 ?四、如何管理所有流程与实例 ?五、开发流程 ?六、api 一、BPMN 1. 什么是BPMN 首先BPMN规范是由标准组织BPMI发布的.BPMN 1.0规范发布于2004年5月。此规范展示了BPMI组织两年多的努力成果。BPMN的主要目标就是要提供被所有业务用户理解的一套标记语言，包括业务分析者、软件开发者以及业务管理者与监察者。BPMN还将支持生成可执行的 BPEL4WS语言。所以，BPMN在业务流程设计与流程实现之间搭建了一条标准化的桥梁。 BPMN定义了业务流程图，其基于流程图技术，同时为创建业务流程操作的图形化模型进行了裁减。业务流程的模型就是图形化对象的网图，包括活动（也可以说工作）和定义操作顺序的流控制。 2. BPMN基础 业务流程图由一系列的图形化元素组成。这些元素简化了模型的开发，且业务分析者看上去非常熟悉。这些元素每个都有各自的特性，且与大多数的建模器类似。比如，活动是矩形，条件是菱形。应该强调的是：开发BPMN的动力就是为了在创建业务流程模型时提供一个简单的机制，同时又能够处理来自业务流程的复杂性。要处理这两个矛盾的需求的方法就是将标记的图形化方面组织分类为特定的类别。这里提供标记类别中的一小部分，以便业务流程图的读者可以简单地识别出元素的基本类型从而理解图形。以下是四种基本的类型： 1）流对象 2）连接对象 3）泳道 4）人工信息 BPMN2.0概要：https://www.sodocs.net/doc/2017178236.html,/workclass/201206272.asp 二、activiti主要接口 ProcessEngine processEngine =ProcessEngines.getDefaultProcessEngine(); RuntimeService runtimeService = processEngine.getRuntimeService(); RepositoryService repositoryService = processEngine.getRepositoryService(); TaskService taskService = processEngine.getTaskService(); ManagementService managementService = processEngine.getManagementService(); IdentityService identityService = processEngine.getIdentityService(); HistoryService historyService = processEngine.getHistoryService(); FormService formService = processEngine.getFormService(); ProcessEngines.getDefaultProcessEngine()会在第一次调用时初始化并创建一个流程引擎，以后再调用就会返回相同的流程引擎。使用对应的方法可以创建和关闭所有流程引擎：ProcessEngines.init()和ProcessEngines.destroy()。 ProcessEngines会扫描所有activiti.cfg.xml和activiti-context.xml文件。对于activiti.cfg.xml文件，流程引擎会使用Activiti的经典方式构建： ProcessEngineConfiguration.createProcessEngineConfigurationFromInputStream (inputStream).buildProcessEngine(). 对于activiti-context.xml文件，流程引擎会使用Spring方法构建：先创建一个Spring的环境，然后通过环境获得流程引擎。 工作流引擎产品功能介绍 目录 1.1工作流引擎简介 1.1.1产生背景 随着我国信息化建设的不断深入，越来越多的政府部门和企事业单位都清醒地认识到信息化对于自身的生存与发展的重要性，以IT 系统建设为基础提高工作效率，增强竞争能力，已经成为共识。 在过去的若干年中，许多企业以当时的IT 发展水平为基础，针对不同的业务需求搭建了种类繁多的应用系统。回顾这一阶段，我们可以发现长期以来IT 系统的建设一直跟随着技术的革新和业务需求的增长而被动地发展着。不论技术手段如何变化，企业仍旧习惯于沿着功能分析的思路为特定的需求开发专有应用。随着时间的推移，企业内部逐渐积累了许多相互孤立的筒仓式应用系统。不可否认，正是这些应用系统共同构成了当今企业的主要IT 运行环境并有效地支撑了企业早期的业务发展，但是我们也必须清醒地认识到，在这些缺乏前期规划、互连性极差的应用系统之间信息不能被有效地共享且难于保持一致，业务过程也无法顺畅地流转，它们是造成“信息孤岛”现象的根源。一些企业也曾经尝试采用整理、合并各种需求、统一数据接口、规范业务过程等方式来降低集成的复杂度，但是在经过一番实践后，人们又发现仅仅依靠规范静态信息的交换格式，集合局部的需求等方法并不足以支持更大范围内的应用整合。因此当前的企业迫切需要一个能够支持在不同的应用系统之间完成协作任务的具有前瞻性的应用集成框架。 当前，企业面对的是一个多变且难以预测的市场，要在这样的环境中生存和 发展，就必需具备对外部变化做出迅速响应的能力。同样，政府部门也面临着转变工作职能，适应市场经济发展要求的压力，需要不断地为大众提供各种高效的公共服务。各项独立调查表明: 对业务系统和IT 基础设施进行快速调整和扩展一直是政府部门和企事业单位应对外部环境变化的重要手段。然而在早期的IT 系统设计过程中，人们往往更加关注于系统的稳定性而不是迅速应对变化的能力，原先那种僵硬的基于硬编码实现的系统功能扩展和集成方式已远远不能满足要求。“采用什么样的技术来搭建能够实现跨部门、跨企业、跨地理范围的支持流程协作和流程自动化的IT 基础设施”，“如何能够从被动地应对变化到预见变化进而实现前瞻性地主动变化”…这些都是当前每一个政府部门和企事业单位必须面对的挑战。 通过工作流系统把各业务部门的孤立应用系统整合起来是IT技术发展的必然趋势，而我国从上实际八十年代大量建设基础信息系统至今，工作流技术的发展可以分成以下几个阶段。 1.1.2发展阶段 1.1. 2.1EDF(电子数据流)阶段 此阶段的工作流在信息技术中的应用,仅着眼于利用信息技术减轻人们在流程中的计算强度最主要的特点是仅对企业单项业务进行处理,基本不涉及管理的内容。国内最早成功的产品是财务管理产品，为了配合产生正确的数据，可能要设计一个流程用来协调多个会计统计帐目。 此阶段仅仅停留在诸如文档处理、公文流转以及信息发布等这些简单的业务 软件是程序/数据/相关文档的完整集合软件发展阶段:程序设计阶段/程序系统阶段/软件工程阶段项目是在一定的资源约束下，完成既定目标的一次性的系列任务项目受4因素制约:工作范围/成本/进度计划/客户满意度项目目标的三重约束:功效/时间/费用项目的生命周期:启动/计划/实施/结束项目管理:以项目为对象的系统管理方法，通过一个临时的专门的柔性组织，对项目进行高效率的计划、组织、指导和控制，以实现项目目标软件项目管理:为了使软件项目能按照预定的成本、进度、质量顺利完成，而对经费、人员、进度、性能、风险等进行分析和管理的活动软件工程:应用计算机科学、数学、及管理科学等原理开发软件的工程软件工程3要素:方法/工具/过程软件工程的过程:软件规格说明/软件开发/软件确认/软件演进软件开发阶段:需求分析/概要设计/详细设计/编码/测试/安装及维护瀑布模型特点:阶段间具有顺序性和依赖性/推迟实现的观点/每个阶段必须完成规定的文档和成果/每个阶段结束前完成文档审查，尽早改正错误快速应用开发RAD模型:强调极短的开发周期，使用基于构件的方法RAD阶段:需求计划/用户描述/构建/结束螺旋模型活动:制定方案/风险分析/实施工程/评估敏捷软件开发模型Scrum:能够尽快的响应变化软件能力成熟度模型CMM:初始级/可重复级/已定义级/已管理级/优化级PSP:个体软件过程TSP:群组软件过程RUP是建立在uml基础上的RUP二维坐标:横轴表示时间组织/纵轴以内容来组织RUP的阶段:初始/细化/构造/交付RUP核心工作流:商业建模/需求/分析和设计/实现/测试/部署/配置和变更管理/项目管理/环境极限编程XP微软解决方案框架MSF软件项目管理过程:启动软件项目/制定项目计划/实施和监控阶段/项目收尾和结束软件工程开发过程与软件项目管理过程的关系:两个过程目标是一致的/两个过程管理的对象是一致的/两个过程的开始和结束时间是一样的/它们分析问题的角度和管理的侧重点不同，前者是从工程的角度出发，后者是从计划和执行的角度；前者侧重开发过程的工作内容，后者侧重管理的内容项目范围是指为交付具有规定特征和功能的产品或服务所必须完成的工作识别项目是确定项目范围的首要工作用户和技术是识别项目的关键预算方法:工作分解结构WBS/自底向上的成本估算/自顶向下的成本估算(模拟估算法/参数模型法) 可行性分析:经济可行性/技术可行性/社会可行性(外部环境可行性/管理和操作的可行性) 项目范围管理:是指对项目包括什么与不包括什么的定义与控制过程范围包含两方面:产品范围/项目范围项目范围管理的过程:范围计划编制/范围定义/范围核实/范围的变更控制项目结构分析包括:项目的结构分解/项目的单元定义/项目单元之间逻辑关系的分析项目结构分解的工具是工作分解结构WBS，它是一个分级的树形结构，是将项目按照其内在结构或实施过程的顺序进行逐层分解而形成的结构示意图任务责任矩阵是在任务分解的基础上，把工作分配给相关人员，用一个矩阵表格表示任务的分工和责任WBS设计的方法:类比法(以一个类似项目的WBS模板为基础，来制定本项目的工作分解结构)/自上而下法(从整个项目开始，逐步分解为下一级的多个子项)/自下而上法(先确定项目有关的各项具体任务，然后将任务合并到整体或上一级中) WBS项目结构分解的原则:在各层次上保持项目内容的完整性，不能遗漏工作单元/一个项目单元只能从属与某一个上层单元，不能交叉/项目单元应能区分不同的责任人和不同的工作内容/项目结构分解应能方便工期、成本、质量等的控制/详细程度适中范围变更控制:将范围变更控制在一定的限度内，控制需求变更和减小变更对项目的影响项目时间管理:主要任务就是项目进度计划的制定、执行和变更控制定义活动是一过程，它涉及确认和描述一些特定的活动，完成了这些活动意味着完成了WBS结构中的项目细目和子细目活动排序过程包括确认且编制活动间的相关性活动排序过程包括编制活动间的三种相关性:内在的相关性(强制依赖关系)/指定性的相关性(自由依赖关系)/外部相关性(外部依赖关系) 活动间有4种相关依赖的关系:结束-开始(某活动必须结束，另一活动才能开始)/结束-结束(某活动结束前，另一活动必须结束)/开始-开始(某活动必须在另一活动开始时开始)/开始-结束(某活动结束前另一活动必须开始) 活动排序的结果是项目网络图，是项目所有活动以及活动之间逻辑 各种工作流模式的实现 作者：非也QQ：20674450Email：nychen2000@https://www.sodocs.net/doc/2017178236.html, 目录 1.概述 (3) 2.Fire Workflow流程元素介绍 (3) 1)Activity和Task： (3) 2)Synchronizer、StartNode、EndNode (4) 3)Transition (4) 3.设计约束 (4) 1)约束1 (4) 2)约束2 (4) 3)约束3 (5) 4)约束4 (5) 5)关于设计约束的说明 (5) 4.顺序、分支、汇聚 (6) 1)顺序分支汇聚其实是统一的 (6) 2)顺序业务流程举例 (8) 3)并行业务流程举例 (8) 4)分支选择业务流程举例 (9) 5)汇聚业务流程举例 (10) 5.子流程 (11) 1)流程设计 (11) 2)流程模拟 (12) 3)关于“Multi-Merge”的探讨 (13) 6.“自由流”(Jump) (14) 1)流程设计 (14) 2)流程模拟 (14) 3)相关API (17) 7.循环(Loop) (18) 1)流程设计、模拟 (18) 2)相关API (18) 8.略过(Skip) (18) 1)流程设计 (18) 2)流程模拟 (19) 9.会签 (20) 10.委派 (21) 11.任务完成期限 (21) 1)流程设计、模拟 (21) 2)相关API (22) 12.监听工作流事件 (22) 1)TaskInstance事件监听器 (22) 2)ProcessInstance事件监听器 (23) 13.表单绑定 (24) 14.流程元素属性详细说明 (25) 1)所有流程元素通用属性 (25) 2)WorkflowProcess的属性 (25) 3)StartNode、Synchronizer、EndNode属性 (25) 4)Activity属性 (25) 5)Transition的属性 (26) 6)Subflow Task的属性 (26) 7)Tool Task的属性 (26) 8)Form Task的属性 (26) Activiti入门教程详解完整教程 1.A ctiviti介绍 Activiti是由Alfresco软件在2010年5月17日发布的业务流程管理(BPM)框架,它是覆盖了业务流程管理，工作流，服务协作等领域的一个开源，灵活的，易扩展的可执行流程语言框架。 Activiti基于Apache许可的开源BPM平台，创始人Tom Baeyens是JBoss JBPM的项目架构师，它的特色是提供了eclipse插件，开发人员可以通过插件直接绘画出业务流程图。 1.1工作流引擎 ProcessEngine对象，这是Activiti工作的核心。负责生成流程运行时的各种实例及数据，监控和管理流程的运行。 1.2BPMN 业务流程建模与标注（Business Process Model and Notation,BPMN），描述流程的基本符号，包括这些图元如何组合成一个业务流程图(Business Process Diagram) 2.准备环境 2.1Activiti软件环境 1)JDK1.6或者更高版本 2)支持的数据库有:h2,mysql,oracle,mysql,db2等 3)支持Activiti运行的jar包，可以通过maven依赖引入 4)开发环境为Eclipse3.7或者以上版本，myeclipse为8.6版本2.2安装流程设计器(eclipse插件) 1）打开Help →Install New Software →Add 输入Name: Activiti Designer Location: https://www.sodocs.net/doc/2017178236.html,/designer/update/ 输入完成后，单击OK按钮等待下载完成后安装。 安装完成后在菜单选项中会出现Activiti的目录选项 主流三维引擎对比分析 随着计算机可视化、虚拟现实技术的飞速发展,人们对实时真实感渲染以及场景复杂度提出了更高的要求。传统的直接使用底层图形接口如OpenGL、DirectX开发图形应用的模式越来越暴露出开发复杂性大、周期性长、维护困难的缺陷。为此国外出现了许多优秀的三维渲染引擎,比如Delta3D,OGRE,OSG,Unity3d,VTK等。渲染引擎的作用就是要优化遍历与显示三维模型。本文主要对OGRE与OSG这两个三维图形渲染引擎做个简单的比较,介绍她们在运行效率、场景管理、功能支持、可扩展性等方面的异同。通过了解两者差异后,可以根据不同的项目需求,选择合适的渲染引擎。 ogre OGRE(Object-Oriented Graphics Rendering Engine,面向对象图形渲染引擎) 又叫做OGRE 3D。OGRE就是面向场景的、灵活的图像引擎。OGRE仍然在发展中,如果就功能与商业游戏引擎还有一定差距。在OGRE的论坛网站上您可以得到更多的信息,里面谈论到OGRE的一些格外的插件,如声音,UI ,物理检测,还有网络应用。采用C++开发,以MIT许可证发布,可以在Windows、Linux、Mac上运行。OGRE自己也说明本身不就是游戏引擎。 其主要特征如下: 面向对象,插件扩展架构,具有文档支持。 支持脚本。可以通过脚本管理材质资产并进行多路渲染。 支持物理碰撞检测。 支持顶点灯光、像素灯光、灯光映射。 支持阴影映射、三维阴影。 支持多纹理、凹凸贴图、多重材质贴图、立体投影。 支持顶点、像素、高级着色。 支持场景管理,具有多种数据结构。 支持逆向运动动画、骨架动画、变形动画、混合动画及姿态动画。 支持网格加载、皮肤、渐进网格。 支持环境映射、镜头眩光、公告牌、粒子、运动模糊、天空、水、雾、丝带轨迹、透明对象。支持XML文件转换。 引擎特性全面( ),稳定性好( ),支持全面( ),不容易上手与使用( )。 软件工程复习提纲 Chapter1 1.开发文档都有哪些？用图来表示它们之间的关系。 2.说明软件工程研究的内容。 3.软件工程的7条基本原理有何现实意义。 4.怎样理解ISO9000的文档体系？质量手册、程序文件、质量记录三者有何联系和区别？ 5.怎样理解CMMI，如何用CMMI去管理软件企业？ 6.是否存在这一种现象：搞系统软件的公司不需要采用CMMI和ISO9000模式？CMMI和ISO9000模 式只适用于搞应用软件的企业？如果是，为什么，如果不是，又为什么？ 7.软件工程与信息系统工程有何异同？ 8.怎样理解元数据？ Chapter2 1.为什么要选择软件开发模型？软件开发模型与软件生存周期有什么关系？ 2.简述瀑布模型、增量模型、迭代模型、原型模型的优缺点。 3.软件公司的ISO9000或CMM管理体系与软件开发模型有关吗，为什么？ 4.你对“生存周期模型裁剪指南”有什么看法？ 5.“图书馆信息系统”的开发选用什么开发模型合适？ Chapter3 1.立项的具体表现形式是什么？ 2.立项建议书的编制者为什么主要是软件公司的市场销售人员，而不是开发人员？ 3.什么叫风险分析，技能风险与技术风险有何区别？ 3.合同、任务书、立项建议书三者有何异同？有何关系？ 4.对软件项目和产品的“功能、性能、接口”三项指标如何理解？ Chapter4 1.需求分析的目的是什么，需求分析的难点在哪里？ 2.需求分析的理论基础有哪几条？ 3.为什么说需求分析是面向流程的？ 4.解释术语：元数据、实体、中间数据。 5.用户需求报告与需求规格书有何差异？ 6.需求描述有哪几种工具？你喜欢哪一种，为什么？ 工作流模式与K2实现 1.背景 工作流产品众多，而它们之间又缺乏统一的标准，使得不同的产品之间很难实现协同工作。为了解决这一问题，工作流管理联盟（WFMC） 于1993 年成立，并提出了工作流参考模型，制定了五个标准接口。 其中有一个接口是过程定义接口。几乎每个工作流产品都有自己的过程定义语言（也称为工作流语言），可以从四个方面（控制流、数据流、资 源、操作）来研究流程，工作流模式（Work Flow Pattern）只是涉及到其中的控制流部分。控制流（control flow）描述了活动在不同结构中的执行顺 序。控制流对我们有效认识、理解工作流规范具有很大帮助。工作流规范需要不断地扩展，以便满足新的需求，因此有必要对控制流进行基础的认识和分析。 2.模式总述 工作流模式系统化地表述了基本的和复杂的结构。模式（pattern）是从具体形式中抽象出来的。面向对象的设计模式，规定了不依赖于具体的实现技术，同时也不依赖于所在领域的基本需求。 Carl Adam Petri基于Petri网原理提出的21个工作流模式，用于工作流过程建模和分析。这些模式，仅限于静态控制流，而不考虑资源分配、实例控制、异常处理和事务管理。 3.K2 Blackpearl K2 Blackpearl 是SourceCode公司基于.NET WF构建的流程开发平台的核心产品。代码可支持生成WF代码，流程设计环境使用WPF构建，并完全嵌入到VS 2005中，与微软产品紧密结合。 K2 blackpearl 包括业务流程管理与工作流性能。可以通过建立应用来管理业务流程并使其自动化，或者集业务流程、人员、服务、信息和系统于单一的应用，从而帮助推动业务发展。 4.基础控制过程 这五个模式的共同点在于：模式所涉及流程的执行路径是在设计时即可确定的，不需运行时的信息。包括：Sequence（顺序模式）、Parallel split（并行分支模式）、Synchronization（同步模式）、Exclusive choice（排他选择）、Simple merge（简单合并模式）。 ?1 顺序（Sequence） ●描述： 工作流中的各个活动在同一个进程中按顺序依次执行。 ●案例： “用户付款”后才能进行“发送货物”。 ●K2实现： 特别响、非常近——BPMN2新规范与Activiti5 上世纪九十年代以后，随着WfMC联盟的成立，BPM市场群雄逐鹿如火如荼，工作流技术得到了突飞猛进的发展，其中IBM、Oracle等大型软件厂商在工作流领域各扯大旗割据一方。2011年BPMN2.0新规范的发布为各工作流产品互容互通提供了统一的标准，结束了各工作流厂商各自为政相互抵斥的局面。 什么是BPMN、Workflow？ ?BPM（Business Process Management）——“通过建模、自动化、管理和优化流程，打破跨部门跨系统业务过程依赖，提高业务效率和效果”。 ?Workflow——“全部或者部分由计算机支持或自动处理的业务过程”（工作流管理联盟WfMC组织对工作流概念的经典定义） BPM基本内容是管理既定工作的流程，通过服务编排，统一调控各个业务流程，以确保工作在正确的时间被正确的人执行，达到优化整体业务过程的目的。BPM概念的贯彻执行，需要有标准化的流程定义语言来支撑，使用统一的语言遵循一致的标准描述具体业务过程，这些流程定义描述由专有引擎去驱动执行。这个引擎就是工作流引擎，它作为BPM的核心发动机，为各个业务流程定义提供解释、执行和编排，驱动流程“动“起来，让大家的工作“流”起来，为BPM的应用提供基本、核心的动力来源。 现实工作中，不可避免的存在跨系统跨业务的情况，而大部分企业在信息化建设过程中是分阶段或分部门（子系统）按步实施的，后期实施的基础可能是前期实施成果的输出，在耦合业务实施阶段，相同的业务过程可能会在不同的实施阶段重用，在进行流程梳理过程中，不同的实施阶段所使用的流程描述语言或遵循的标准会有所不同（服务厂商不同），有的使用WfMC 的XPDL，还有些使用BPML、BPEL、WSCI等，这就造成流程管理、业务集成上存在很大的一致性、局限性，提高了企业应用集成的成本。 BPMN2.0规范的引入 遵循BPMN2.0新规范的工作流产品能很大程度上解决此类问题。BPMN2.0相对于旧的1.0规范以及XPDL、BPML及BPEL等最大的区别是定义了规范的执行语义和格式，利用标准的图元去描述真实的业务发生过程，保证相同的流程在不同的流程引擎得到的执行结果一致。BPMN2.0对流程执行语义定义了三类基本要素，它们是日常业务流程的“三板斧”： ?Activities（活动）——在工作流中所有具备生命周期状态的都可以称之为“活动”，如原子级的任务（Task）、流向（Sequence Flow），以及子流程（Sub-Process）等?Gateways（网关）——顾名思义，所谓“网关”就是用来决定流程流转指向的，可能会被用作条件分支或聚合，也可以被用作并行执行或基于事件的排它性条件判断 ?Events（事件）——在BPMN2.0执行语义中也是一个非常重要的概念，像启动、结束、边界条 1.1工作流引擎技术 工作流概念的提出是人们注意到了隐藏在业务处理的过程控制的共性，并从业务处理操作中分离出过程逻辑单独加以研究，从而可以实现过程优化配置和重组。但是，多年来，不同的研究者和产品供应商从不同的角度给出了工作流的定义。下面分别从工作流定义及工作流相关术语进行解释，并分析工作流应用中所遇到的多种模式，提出了工作流参考引擎、处理模型、体系结构等。 1.1.1工作流定义 WfMC给出的工作流的定义[21]：工作流（Workflow）是一类能够完全或者部分自动执行的经营过程，根据一系列过程规则，文档、信息或任务能够在不同的执行者之间传递、执行。 工作流是指业务领域的流程，它描述了业务过程中的各个要素以及要素之间的关系。 业务过程则是对工作流的抽象，通过对业务过程中各要素的描述形成过程定义。过程定义是过程自动化的基础数据，它通过工作流引擎进行管理。 下面将对工作流引擎技术中涉及到的一些基本概念给出其定义。这些概念包括：工作流引擎、业务过程、过程定义、活动、自动活动、人工活动、实例、过程实例、活动实例、工作流参与者、工作项、工作项列表等。 1.工作流引擎 工作流引擎是一个软件系统，它定义、创建和管理工作流的执行，并且运行在一个或多个工作流引擎之上。工作流引擎能够解释过程定义、实现与工作流参与者的交互并且调用各种外部IT工具和应用。 2.业务过程 一个包含一个或多个相关程序或活动的集合，这些程序或活动共同实现一个业务或决策目标。通常地，业务过程存在于一个定义了职能角色和业务关系的组织结构中。 3.过程定义 过程定义是对业务过程的描述，这种描述形式支持诸如建模、通过工作六管理系统执行等操作的自动化处理。过程定义有活动和它们之间的关系组成，这些活动和关系形成了一个网状结构，并且还包含过程开始和结束条件和各活动的详细信息，如活动参与者、相关应用和数据等。 4.活动 活动是对一份工作的描述，它是过程中的一个逻辑步聚。一个活动可以是 文件代码： 目录 1 环境准备 (1) 2 创建SQL脚本 (1) 3 下载所需依赖包 (2) 3.1IDEA配置使用阿里云MAVEN仓库 (2) 3.2下载所有依赖包 (5) 4 修改配置文件 (5) 4.1修改APPLICATION.PROPERTIES文件 (5) 4.2修改POM.XML文件 (6) 5 加载DM驱动程序 (6) 5.1拷贝DM驱动程序 (6) 5.2将驱动程序打入M AVEN仓库 (7) 6 修改ACTIVITY-ENGINE-5.22.0 (8) 6.1修改P ROCESS E NGINE C ONFIGURATION I MPL文件 (9) 6.2修改D B S QL S ESSION F ACTORY文件 (9) 6.3修改A BSTRACT Q UERY文件 (10) 7 ACTIVITY-ENGINE-5.22.0打包 (11) 8 验证结果 (12) 9 附录 (12) 1环境准备 项目名称：Spring boot整合activiti工作流引擎实例 Spring-Boot-Activiti5.22.0项目文件：Spring-Boot-Activiti5.22.0.zip 开发工具：IntelliJ IDEA 2020.2 (Ultimate Edition) IDEA安装路径：D:\IDEA 项目路径：D:\IDEA\work 将项目文件解压至D:\IDEA\work目录下，并导入IDEA： 2创建SQL脚本 将项目中activiti.sql脚本在数据库中创建。 说明：项目中activiti.sql脚本是Mysql的语法，可先在Mysql中创建，再通过DTS工具迁移至DM中。也可使用以下activiti.sql直接在DM中创建（以下activiti.sql语法已修改为DM语法）。 DM语法activiti.sql脚本：activiti.sql 3下载所需依赖包 3.1IDEA配置使用阿里云maven仓库 IDEA工具左上角：文件→设置→构建、执行、部署→构建工具→Maven 指定以下三个目录： 工作流的基本模式 1 、顺序(Sequence )模式 描述：只有当前一个活动结束后，后一个活动才会被触发，即按照预定的任务列表，有序的执行。(提交一亍日UG、______________________ 弍FEX该日UG 、 _______________________________ Close^BUG 2、并行(Parallel Split)模式 描述：- 一个活动的结束能够触发若干个活动的开始，这些被触发的活动能以并行的方式同时或按任意顺序举例：当提交一个BUG时会分别向BUG信息表和BUG日志表中添加相应记录 进行 3、同步(Synchronization )模式 描述：如果不考虑超时(一般流程会设定任务执行期限)和异常等情况，流程必须在聚合点等待所有的分支都执行完(到达And汇聚点)才能激活后继任务，才能正确的往下运行。 举例：支持人员分派的问题由开发人员修改，然后不仅要经过测试人员验证通过还要再次经支持人员验证通过才能Close该BUG。 4独占式选择(Exclusive Choice )模式 该模式分为显式独占模型(explic Exclusive Choice )和隐式独占选择模式(implicit Exclusive Choice) 1)显式独占选模型(explic Exclusive Choice ) 描述：当一个活动处理完后，其后有若干个分支流程可供选择，但根据工作流控制数据 (workflow control data )只允许选择其中某一个分支运行。 XOR1 1 t Activiti数据表结构 目录 1ACTIVITI数据库表结构 ----------------------------------------------------------------------------------------------- 2 1.1数据库表名说明 ------------------------------------------------------------------------------------------------ 2 1.2数据库表结构---------------------------------------------------------------------------------------------------- 3 1.2.1Activiti数据表清单: ---------------------------------------------------------------------------------------- 3 1.2.2表名:ACT_GE_BYTEARRAY （通用的流程定义和流程资源）-------------------------------- 3 1.2.3表名:ACT_GE_PROPERTY （系统相关属性） ----------------------------------------------------- 4 1.2.4表名:ACT_HI_ACTINST （历史节点表） ------------------------------------------------------------ 5 1.2.5表名:ACT_HI_ATTACHMENT （附件信息）-------------------------------------------------------- 6 1.2.6表名:ACT_HI_COMMENT （历史审批意见表）-------------------------------------------------- 6 1.2.7表名:ACT_HI_DETAIL （历史详细信息）----------------------------------------------------------- 7 1.2.8表名:ACT_HI_IDENTITYLINK （历史流程人员表） ---------------------------------------------- 8 1.2.9表名:ACT_HI_PROCINST（历史流程实例信息）核心表---------------------------------------- 8 1.2.10表名:ACT_HI_TASKINST（历史任务流程实例信息）核心表------------------------------ 9 1.2.11表名:ACT_HI_VARINST（历史变量信息） ------------------------------------------------------ 9 1.2.12表名:ACT_ID_GROUP（用户组表） ------------------------------------------------------------ 10 1.2.13表名:ACT_ID_INFO （用户扩展信息表） ---------------------------------------------------- 10 1.2.14表名:ACT_ID_MEMBERSHIP（用户用户组关联表） -------------------------------------- 11 1.2.15表名:ACT_ID_USER（用户信息表） ------------------------------------------------------------ 11 1.2.16表名:ACT_RE_DEPLOYMENT（部署信息表）------------------------------------------------ 12 1.2.17表名:ACT_RE_MODEL (流程设计模型部署表) ----------------------------------------------- 12 1.2.18表名:ACT_RE_PROCDEF （流程定义表） ---------------------------------------------------- 13 1.2.19表名:ACT_RU_EVENT_SUBSCR (运行时事件) ------------------------------------------------- 14 1.2.20表名:ACT_RU_EXECUTION （运行时流程执行实例） ----------------------------------- 15 1.2.21表名:ACT_RU_IDENTITYLINK（身份联系） --------------------------------------------------- 15 1.2.22表名:ACT_RU_JOB（运行中的任务）---------------------------------------------------------- 16 1.2.23表名:ACT_RU_TASK(运行时任务数据表) ------------------------------------------------------ 16 1.2.24表名:ACT_RU_VARIABLE(运行时流程变量数据表) ----------------------------------------- 17 2ACTIVITI中主要对象的关系 -------------------------------------------------------------------------------------- 18业务流(BPM)与工作流(workflow) 的区别
Activiti 库表结构 张表
工作流引擎技术白皮书
activiti流程开发基本步骤详解
工作流引擎技术白皮书
软件项目管理重点
各种工作流模式的实现
Activiti工作流入门详解完整教学教程
主流三维引擎对比分析说明书
软件工程复习提纲[2017年0615]
工作流模式与K2实现
特别响、非常近——BPMN2新规范与Activiti5
工作流引擎技术
activiti5.17流程进入阻塞状态,定时任务根据数据库状态推动流程到下个节点
Activiti连接达梦数据库
工作流的基本模式
Activiti工作流数据库表结构