拒绝访问 | www. | 百度云加速
请打开cookies.
此网站 (www.) 的管理员禁止了您的访问。原因是您的访问包含了非浏览器特征(43e9-ua98).
重新安装浏览器，或使用别的浏览器503 Service Temporarily Unavailable
503 Service Temporarily Unavailable
openresty/1.9.7.4工作流概要设计规格说明书(gld)
我的图书馆
工作流概要设计规格说明书(gld)
工作流是广联达T6平台中的技术平台内的业务组件之一，T6平台的工作流需要满足建筑工程行业企业中的所有关于“业务流程”类的需求，包括业务单据转换，业务服务编排，自由流和审批流，实现多人协作，多级审批，互相整合，战略落地。
本文是工作流的总体概要设计，主要描述了工作流的体系结构，模块划分，模块间的关系，工作流定义，工作流的执行引擎，工作流相关的工具，工作流对外的服务接口，工作流的事件，工作流与T6平台概念模型以及其他业务组件的关系和集成，内容涵盖从工作流建模到工作流运行，再到工作流优化的各方面内容。
和一般的工作流产品不同，T6平台工作流的重点在于对工作流的“流能力”的描述和实现。而与工作流相关的业务单据，提醒，安全以及其他内容在本文中会提到但是不是重点描述的对象。
本文的主要读者是：
l工作流各子系统的设计人员
了解系统的组成与数据结构，通讯方式
了解工作流的基本原理，内部、外部接口，开发模式与开发环境
了解工作流产品的主要结构，特性和对外接口
l产品集成与安装
了解工作流产品的组成以及集成、安装、部署过程
《工作流参考模型》
当下工作流规范众多，例如BPMN，XDPL，WFMC，BPEL和PetriNet等等。其中最基本的是WFMC，它所描述的工作流参考模型（如图）是工作流产品的最基础的体系结构模型（如图），绝大多数工作流产品目前都无法超越此体系结构描述的范畴。
WFMC工作流参考模型图
以上几种工作流标准的概述如下：
lWFMC的工作流参考模型把工作流系统分为，工作流定义工具，过程模型（工作流定义），工作流引擎，工作流控制数据（工作流实例），任务表（待办任务）和工作流监控管理工具等几个大模块。在这些模块中工作流定义是核心模块，它是工作流的能力模型，其他模块都围绕工作流定义来构建。WFMC规范里规定的工作流引擎必须提供5大类服务接口涵盖了工作流大部分必须提供的能力范畴。
lBPMN规范描述用户容易理解的工作流的各种构成图元，例如圆圈表示事件，方框表示活动。以及图元间的关系描述，如何构成工作流图。
lXPDL规范描述工作流由Activity（活动）和Transition（转移）构成，它是一套与具体实现技术无关的工作流定义规范。
lBPEL是可执行的工作流定义语言，一般用来实现WEB服务（WebService）的编排，通过编排现有服务满足需求或组成新的服务。它之所以是可执行的，是因为BPEL合适用来实现自动的，无人工交互的工作流需求。
lPetriNet规范描述工作流图由Activity（活动），Place（站点）和Token（令牌）组成，活动允许激活的条件是所有输入里都有令牌，活动激活后消耗令牌同时生成新令牌，站点可以暂存令牌。PetriNet更确切的说是可以用来做工作流引擎的实现算法基础，而不是一个工作流体系结构。
由于上述规范对协作要求高的，交互要求高的，自动和人工互相配合的，突发状况多的中国式特色工作流模式的支持力度有限。并且它们也不关注工作流如何与UI，与组织机构，与业务单据和系统其它模块的集成。
更何况上述标准所能解决的问题域都相对单一，故这些规范都要求业务上的标准化程度较高才可实施。所以实现完整的企业工作流需求，这些标准都是不可能拿来直接使用的，而需要在借鉴和参考的基础大力扩展上抽取出复核中国特色建筑行业业务的，满足T6平台的工作流系统。
T6平台的工作流在参考了以上几种工作流规范，例如在图元上参考BPMN，能力上包含BPEL，体系结构上参考WFMC。在此基础上根据大量业务需求，抽象出工作流规则，类型更加丰富的环节，集成业务单据和组织机构，使工作流能适应绝大多数复杂的业务场景，工作流能力涵盖企业中所有工作流应用场景的需求。
1.敏捷化，工作流产品需要满足建筑工程行业的企业的关于“业务流程”的复杂业务场景的需求，通过建模即可实现绝大多数需求而不需要写代码。
2.通用化，工作流产品既可以被当做一个独立的产品使用，也可以集成到T6平台内与其他业务组件配合使用，这就要求工作流和T6的其他业务组件间的关系必须是动态的松散耦合的关系。例如工作流要适应使用其他的组织机构，其他的业务单据。同时在使用T6平台自己的组织机构和业务单据时其能力还能保证。
3.业务化，工作流的基础概念要和实际业务场景中的业务概念一一对应，由于工作流在业务过程中会一直不断变化演变，在项目实施完以后这些变化演变工作就需要由最终用户方的技术人员完成，所以工作流的基础概要很容易的可以让此类人员和实施人员理解。
4.扩展化，工作流产品的体系结构可扩展性要好，便于和其他产品集成。
企业中工作流应用场景（如工作流应用场景图），包含业务单据之间转换的单据流，用于WEB服务编排的服务流，用于多级审批的审批流和用于临时的离散型协作的自由流。
工作流应用场景图
在实际业务需求中，这几种工作流的应用场景往往是即独立应用，又相互结合。例如在审批流中自动调用服务，在审批流中做单据转换，在审批流中使用自由流等等。
单据流指的是业务单据之间的单据转换（如单据转换体系结构图），用来实现单据的拆分，合并，前项单转为后项单，后项单转为前项单的需求。单据转换的核心是单据转换规则，由单据转换引擎解析和处理单据转换规则。
&&&&&&&&&&&&&&&&&&&&&&& &单据转换体系结构图
单据转换规则是单据转换组件的能力模型，就好像工作流定义是工作流产品的能力模型一样。单据转化能规则描述单据间的字段映射关系，计算关系，合并关系和拆分关系。实现单据拆分，单据合并，数据同步和数据日志等能力。
单据转换可以由业务规则触发或者由用户写代码触发而独立使用，所以它可以不包含在工作流的范畴内。独立实现单据转换规则和单据转换引擎，然后通过在工作流中提供对单据转换的集成（通过单据转换环节的方式）在工作流中应用。
业务流指的是业务服务的编排（如业务图），也就是BPEL规范所解决的问题范畴。通过特定顺序和规则编排现有服务实现新的业务需求，或者形成新服务。
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 业务流图
服务编排中最重要的部分就是服务前后顺序关系和参数的映射，即如何把前项服务的输出变成后项服务的输入。
在工作流体系结构中，将使用工作流的逻辑环节和转移描述业务服务间的前后和逻辑关系，将使用工作流变量描述业务服务的参数和参数的映射关系。
审批流和自由流的共同点或者说基本认识是，它们都是通过把待办任务携带着业务单据在人与人之间传递，从而实现业务协作的（如业务协作图）。审批流是按照一定的规则和先后顺序发送待办任务，而自由流则是没有任何顺序和逻辑限制的可以自由的发送待办任务。
&&&&&&&&&&&&&&&&&&&&&&&&&& 业务协作图
审批流用来实现多级审批，例如采购单审批，项目审批，合同审批等等。自由流则用来实现临时性，零散型的（AdHoc）协作，例如在审批的过程中临时发给某个人确认单据。
各种应用场景互相结合应用图
根据工作流的应用场景抽象构建的工作流体系结构（如工作流体系结构图），它是一个以待办任务和工作流定义为核心的单纯的“流调度”体系结构，重点实现待办任务的维护，工作流的定义，解析和运行，同时以插件方式接入外界诸如单据转换，组织范围和业务表达式计算等能力。
工作流体系结构图
工作流体系结构中各要素的概述如下：
l控制数据是外界干预工作流运行的手段，通过修改和构造控制数据可以使工作流“违背规则”运行。控制数据决定了工作流服务接口分为查询和提交两大类。
l工作流工具包含工作流相关的各种工具，例如工作流定义工具，待办任务中心，工作流监控工具和工作流管理工具等等。
l工作流服务是工作流对外的接口，以WEB服务的方式提供。工作流服务的接口分为查询和提交两大类。
l待办任务引擎负责待办任务的生成，维护，载入和保存。它以自由流的方式实现工作流服务接口。
l工作流定义是工作流的能力模型，是工作流体系结构的核心。工作流定义描述业务需求的能力决定了工作流产品的能力。
l工作流引擎解析工作流定义，基于待办任务引擎，维护工作流实例。它结合工作流定义，实现工作流服务接口。
l工作流实例是工作流定义每次运行而产生的实例，它包含一堆待办任务。
工作流体系结构中各子模块的关系（如工作流对象模型图）：
工作流对象模型图
由于T6平台存在有其他很多基础模块，例如表单定义，数据交换和异步服务等。所以此工作流体系结构它实现的是单纯的“流调度”，它和其他模块是互相的正交，组合和集成的关系，而不是像一般工作流产品一样需要在工作流产品内置表单定义，异步服务和提醒服务等。
在工作流运行的过程中，当需要外界介入处理时工作流引擎将会生成待办任务通知外界，同时工作流暂停运行等待外界的处理。待办任务像邮件一样通知用户有业务单据需要处理，用户打开待办任务处理业务单据，然后经过工作流处理再把业务单据转发给其他人从而推进工作流的运行。
除此之外，待办任务还具有其他一般工作流产品所不具备的重要使命，即一个业务单据的所有相关待办任务实际上记录了此业务单据的详细处理过程，则这些待办任务就可以作为过程管理和精细管理基础（如待办任务图）。
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 待办任务图
一个业务单据相关的待办任务分为两个大类，分别是的审批性的待办任务和零散产生的事务性的待办任务。审批性的待办任务例如项目审批等，事务性的待办任务例如项目沟通记录等，由于待办任务中包含了详细的处理信息，例如处理人，处理时间，内容等。那么基于待办任务可实现真正的过程管理和精细管理。
例如项目经理今天跟业主进行了沟通，把沟通内容当做一条工作记录录入系统，通过提醒或者其他手段领导可以看到这条工作记录且审核其内容，从而能提早发现沟通中和项目中的问题。
待办任务携带业务单据在人与人之间传递，则待办任务最主要的内容应该包含前后的关系，标题，内容，业务单据号，表现业务单据的UI对应的URL，提交人，处理人和处理方式等信息。
待办任务的前后关系定义了待办任务处理过程的轨迹，例如先人员A处理然后人员B处理，再由人员C处理。则待办任务A的后续就是待办任务B，待办任务B的后续任务就是待办任务C，照此类推。同时前后关系也定义了待办任务的分支和聚合关系，分支关系例如人员A处理完毕以后人员B和人员C要同时的各自处理，则待办任务A的后续就是待办任务就是B和C。聚合关系例如人员A1和A2处理完毕以后人员B才可以处理，则待办任务B的前趋就是待办任务A和A1。
待办任务对象模型图
由于一条待办任务可能是发给多人同时处理的，则待办任务与处理人就是一对多的关系。基于高效率和统一体系结构的角度考虑，这种一对多关系将抽象为待办任务的父子关系进行描述。当一条待办任务是发给多人同时处理时，就为这条待办任务生成与处理人个数相等的N条子待办任务。而当一条待办任务是发给单人处理时则，就在待办任务本身上维护处理人信息部生成子任务。这种做法将简化查询待办任务的SQL，简化待办任务的对象体系结构和简化处理过程带来巨大好处。
当处理人把待办任务处理完毕，需要把当前业务单据再发给下一个人时，就需要指定下一条待办任务的处理人，标题，内容和时限等信息，然后工作流引擎再根据这些信息生成待办任务，这些信息就叫做控制数据。
控制数据既可以完全由直接外界构造然后传入工作流引擎，也可以由工作流引擎提供的查询类接口获得，在工作流引擎内部则是根据工作流定义生成。由于控制数据导致了工作流服务的接口分为查询类和提交类，查询类接口根据工作流定义生成和返回控制数据，提交类接口根据控制数据生成待办任务而忽略工作流定义。
基于控制数据外界可以干预控制工作流的运行，例如基于对话框选择流向，选择标题，选择时限和选择处理人等等。甚至还可以让工作流超越工作流定义运行，在工作流服务的提交类接口中只要外界传入了控制数据则工作流引擎优先控制数据生成待办任务而无视工作流定义，例如跳转，特送和直送等等。
控制数据图
基于控制数据可以在UI层提供通用的工作流交互UI，在此UI中实现通用的流向选择，处理人选择，处理方式选择，填写标题，填写内容和时限等信息。例如在流转过程中选择，在回退过程中选择等。
由于控制数据是为了外界控制工作流引擎生成的待办任务内容而定义的，所以控制数据里主体包含的内容其实就是待办任务的内容。为了供外界选择，控制数据里还包含允许选择的处理人范围，允许选择的待办任务范围，待办任务间的逻辑关系等内容。
控制数据对象模型图
请参考控制数据定义的Schema文件。
工作流服务是工作流引擎对外的接口，也就是WFMC规范里的WAPI，当然包含的函数能力范畴必须要远远超过WFMC里规定的WAPI的范畴才能满足中国特色的工作流要求。
工作流服务以WEB服务（WebService）的方式对外提供，能力工作流定义的更新部署，工作流的运行处理，待办任务的列表和处理，工作流监控和管理5个方面的特性。
&&&&&&&&&&&&&&&&&& 工作流服务接口图
当工作流产品集成在T6平台中使用时，工作流服务其实就以元数据模型中服务的fsade的方式实现，实现工作流与技术平台集成。则工作流服务就可以触发元数据模型中的事件，就可以集成业务规则。
工作流接口根据其特性分为5个大接口，其中工作流的监控和查询都归纳到共同的查询接口里了。
工作流接口对象模型图
待办任务服务接口对象模型图
工作流服务接口图
工作流定义服务接口图
工作流定义又叫过程模型，它指的并不是工作流图，而是基于一套概念体系描述和诠释企业中实际的业务经营过程。这套概念体系可以存储到XML文件中，落实到对象体系上，甚至可以使用N中工作流图来表现。
工作流定义是工作流体系结构的核心，它所能描述的业务需求的复杂度决定了工作流产品能力的强弱。工作流体系结构中的其他模块都围绕工作流定义来构建，例如工作流定义工具产生工作流定义，工作流引擎解析和执行工作流定义，工作流实例基于工作流定义等等。
工作定义主要由环节，转移，规则，变量和事件五个要素构成（如图），其中环节和规则是工作流定义的核心，它们不是死的而是可扩展的。多版本和多组织则是两大必要特性，而组织范围和业务表达式则是贯穿于整个工作流定义的，不仅仅是只有工作流会用，而可能会在其他多个地方使用的两个基础要素。
工作流定义体系结构图
工作流体系结构中各子模块的概述如下：
l环节描述的是企业实际经营过程中的各类业务活动，及业务活动间的关系。
l转移描述的是环节的顺序关系，其实就是有向线条。
l规则描述的是环节的处理方式。
l事件描述的是通知，是外界对工作流做接管的切入点。
l变量描述的是外界可以记录入工作流的一些数据，这些数据可以参与工作流的各种运算，例如条件判断，赋值运算和组织范围运算等。
l组织范围是通过表达式的方式，变枚举为组合描述工作流中的处理人范围和通知接收人范围的定义。
l业务表达式打通工作流和业务单据之间的关系，使得业务单据和业务逻辑可以更多的参与工作流的运算。
l多版本描述的是在同一刻，同一个业务过程在系统中存在多个版本。也就是一个多工作流定义，有多个不同版本。
l多组织描述的是因为工作流提交人的不同，同一个业务过程会有多种不同的处理轨迹。
工作流定义是一个比较宽泛的概念，从广义上说它特指工作流的描述定义，也就是前面所说的过程模型。从技术上来说工作流定义是个对象（如图），它包含环节，转移和规则等。
&&&&&&&&&&&&&&&&&&&&& 工作流定义体系结构图
工作流定义对象模型图
工作流定义对象模型图
严格来说工作流定义其实也是业务模型的一种，就像业务实体和业务单据一样，所以工作流定义的存储的方案之一是跟着业务模型体系走。这样实施，部署，缓存，分布式和个性化都将会比较统一，甚至实现代码都可以依赖业务模型的统一架构，实施部署工具也比较好统一的进行处理。
从另一个角度来说工作流定义和业务实体，业务单据等业务模型对象又有着本质区别，那就是工作流定义可以认为是最终用户的资源，是在实施过程中定义的，并且在要随业务的变化而变化就像组织机构一样。所以从这个角度工作流定义存入数据库也具备其合理性。
环节定义了在工作流中哪里需要人工参与处理，哪里需要条件判断，哪里需要自动处理，哪里需要分支聚合等。在工作流定义中包含多种类型的环节分别描述不同的业务场景（如表）。
环节根据其特点分为标识，逻辑和活动三类。标识类环节是为了用户和工作流引擎便于理解和定位工作流而定义的，没有具体实际的意义例如开始环节和结束环节。逻辑类环节定义环节间的分支，聚合和条件分支等关系，用于实现复杂工作流逻辑控制例如分支，聚合等。活动类环节分为人工活动和自动两类，是需要人工参与或者计算自动处理的环节。
环节对象模型图
T6平台的工作流里提供的环节是为了满足绝大多数要求的环节，碰到特殊情况环节是可扩展的，例如扩展出一种自动环节用来实现调用代码。
抽象基础环节对象模型图
抽象活动环节对象模型图
抽象逻辑环节对象模型图
抽象条件环节对象模型图
开始环节标识工作流的起点，在一个工作流定义中必须且只可以包含一个开始环节。工作流启动的过程其实就是以开始环节为起点，处理开始环节的后续环节。
开始环节可以有任意个输入，也可以有任意个输出。当工作流是单起点时可以后续跟一个活动环节，当工作流是多起点时则后续跟多个活动环节，且多个环节间还可以用逻辑类环节标识它们的逻辑关系（如图）。
开始环节对象模型图
结束环节标识工作流的终点，在一个工作流定义中可以包含单个或多个结束环节。在运行时当工作流运行到结束环节时并不意味着当前工作流已经结束，而工作流结束的唯一条件是所有工作流实例相关的待办任务都结束。
结束环节不能有输出，而可以有任意个输入。当结束环节和其他环节组成分支时它们之间必须是“排它”关系（如图）。
结束环节对象模型图
人工活动标识工作流中需要参与人手工处理的环节，在运行时当工作流运行到人工活动时为参与人生成待办任务，同时工作流暂停等待参与人处理待办任务以后工作流再继续运行。人工活动是工作流中最主要的环节，是实现多级审批的关键。
人工活动分为同步模式和异步模式，同步模式指的是为处理人生成待办任务同时工作流暂停，等待处理人处理然后再继续运行。而异步模式则表示为处理人生成待办任务后工作流继续往下运行，处理人一般都是看过就完了他对待办任务的处理不影响流程的运行。
人工活动环节对象模型图
人工活动是工作流人工处理的基础，所有需要人工处理的环节都是基于它扩展或者只是它的几种应用场景，例如审批环节，会签环节都是人工环节的几种应用模式。
自动活动在工作流中用来实现诸如自动调用服务，自动触发规则等可以自动完成的需求，例如在工作流运行过程中触发另外一个工作流，触发一个单据转换等。运行时当工作流运行到自动活动时是一调而过的，工作流不会暂停。
自动活动分为同步模式和异步模式，同步模式指的是当工作流运行到自动环节时马上进行自动处理且等待结果返回，然后工作流继续运行。异步模式则把自动处理的请求的放入异步服务器，不等待结果返回工作流就继续运行。
自动活动对象模型图
自动活动只是一个基础的抽象环节，它不实现任何具体的业务逻辑。实现具体的自动类业务逻辑的环节都从它继承，例如服务环节，单据转换环节和业务规则环节等。
自动环节体系结构图
服务环节继承自自动活动，在工作流中调用WEB服务，实现应用场景中关于业务流的需求。假设一个工作流定义只由服务环节组成，则此工作流定义就是一个单纯的业务流。
服务环节对象图
服务环节属性图
单据转换环节继承自自动活动，在工作流中调用单据转换引擎。实现应用场景中关于单据流的需求。
子流程环节是为了工作流定义的组合度和重用度，同时为了满足描述多工作流间的关系和协作而提出的。
子流程环节可以引用一个工作流定义，表现上看起来被引用的工作流定义就好像是画在子流程环节的位置一样，实现工作流定义的组合重用。但它实际的意义不仅仅只是简单的工作流定义的重用，因为子流程环节产生的工作流实例可以是单个也可以是多个，例如一个单子有5个明细记录可以产生5个子流程实例实现各自独立审批。
子流程环节分为同步模式和异步模式，同步模式指的是当工作流运行到子流程环节时启动子流程且等待子流程运行完毕，然后主流程继续运行。异步模式则主流程启动子流程以后就不管了，各自独立运行。
子流程环节对象模型图
为了在工作流图中明确标识出哪个位置需要根据条件确定流向，采用条件环节而非在转移上写条件的方式来标识工作流定义中的根据条件选择流向。
在条件环节以业务表达式的形式设置条件，在工作流运行时如果此条件表达式计算结果为True则表示条件环节允许通过，路径畅通后续环节可以激活执行。为False则标识条件环节不允许通过，后续环节不可以被活动。
条件环节对象模型图
和条件环节一样在工作流图中明确标识出哪个位置需要根据条件确定流向，和条件环节的区别在于条件分支环节只允许且必须有两个输出，分别是条件表达式计算为True时的输出和为False时的输出。
条件分支环节对象模型图
AND环节在工作流中表示多个环节间的逻辑与关系，根据输入和输出个数的不同，它分为分支和聚合两种模式。
当一个AND环节只有一个输入而有多个输出时则处于分支模式（如图），分支模式表示在AND所有输出的路径中只要畅通的就必须都走。无论在工作流自动运行时，还是在工作流的UI中选择流向时都遵守此规则。
经过AND分支以后一条待办任务被拆分成多条，实现待办任务分支，如图中环节A的待办任务就有两条后续待办任务分别为活动B和活动C。拆分出来的这些待办任务将在工作流中被并行的独立的处理，如图中环节B和环节C的待办任务将各自运行。
当一个AND环节具有多个输入而只有一个输出时则处于聚合模式（如图），合并模式表示所有可能输入到AND环节的待办任务都必须达到以后AND环节才允许通过。由于AND环节的输入可能是有先后顺序的，则先达到AND环节的待办任务就需要等待尚未到达的待办任务，等所有待办任务都到达以后AND环节才允许通过。
如图中假设环节A1先到达AND环节那么它将不能流转给环节B，必须等环节A2也达到AND环节以后才可以流转给环节 B。
经过AND合并以后多条待办任务将被合并为一条待办任务，实现待办任务聚合，如图中环节A1和环节A2的待办任务在经过AND合并以后，环节B的处理人其实只收到一条待办任务。
AND环节对象模型图
AND环节不允许同时具有多个输入和多个输出。
XOR环节在工作流中表示多个环节间的排它关系，根据输入和输出个数的不同，它分为分支和聚合两种模式。
当一个XOR环节只有一个输入而具有多个输出时则处于分支模式（如图），分支模式表示在XOR环节全部输出的路径中只要畅通的只能走其中唯一的一条。无论在工作流自动运行时，还是在工作流的UI中选择流向时都遵守此规则。
经过XOR分支待办任务不会被拆分，如图环节A是一条待办任务则环节B也是一条待办任务。
当一个XOR环节具有多个输入而只有一个输出时则处于聚合模式（如图），聚合模式表示所有输入的路径达到XOR环节时都允许直接通过，不进行待办任务的等待和合并。
如图环节A1和环节A2的都可以直接运行到环节B，由于经过XOR聚合待办任务不会被合并，则环节B就有可能收到两条待办任务分别来自于环节A2和环节A2。
XOR环节对象模型图
XOR环节不允许同时具有多个输入和多个输出。
环节定义了构成工作流处理过程的各个步骤，而规则是用来定义工作流是如何启动的，在环节内参与人是如何处理等等这些详细的处理属性的。
需要说明的是，这里所说的规则是工作流规则而不是业务规则，两者的差别在于工作流规则是工作流自己的由工作流引擎解析执行的，而业务规则是T6技术平台的基础概念中的一个重要元素，工作流会被业务规则集成但工作流引擎不负责解析和执行业务规则。
抛开规则，其实这些处理属性是可以直接定义在各自的宿主中的，例如在环节上处理人范围和处理方式。但是这样做的话处理属性就只能定义唯一的一份，例如环节只有一个处理人范围属性和只有一个处理方式属性。所以就先把处理选项纳入规则再把规则定义到宿主中，那么每个宿主都可以定义多条规则（如图），例如处理人范围属于执行规则，在人工活动环节中可以定义多条执行规则。
工作流规则对象模型图
每一种类型的工作流规则在各自宿主上定义时都可以定义多条，例如人工活动环节上定义多条执行规则，多条流转规则等。在运行时，工作流引擎根据规则的生效条件算出唯一的一条起作用的参与工作流运算，其他不起作用的规则就被忽略。
抽象基础规则对象模型图
抽象启动规则对象模型图
抽象处理人规则对象模型
规则一般只有在调用查询类服务的时候起作用，也就是说规则都是用来生成控制数据的，在调用提交类服务时则基于控制数据而不再依赖规则。
基于规则可以实现根据条件确定环节的处理方式，例如&1000万三个秘书审核，金额&1000万则一个秘书审核。
启动规则是工作流在做启动操作时的属性定义，它可以用来实现选择入口环节，初始化工作流实例和初始化全局变量等特性。启动规则的宿主是开始环节。
启动规则对象模型图
流转规则用于人工活动环节在做流转操作时的属性定义，它可以用来实现流转检查，待办任务等待和待办任务合并等特性。流转规则的宿主是人工活动环节。
由于当前环节可能具有多个输出环节，所以流转规则并不定义当前环节输出的目标环节的处理属性，而仅定义当前环节流转的相关属性。
流转规则对象模型图
回退规则用于人工活动环节在做回退操作时的属性定义，它可以用来实现回退检查，回退目标范围选择，回退后的流转模式选择和对同步待办任务的处理等特性。回退规则的宿主是人工活动环节
由于当前环节可能具有多个输入环节，所以回退规则并不定义当前环节的输入源环节的处理属性，而仅定义当前环节回退的相关属性。
回退规则对象模型图
转发规则是人工活动环节在做转发操作时的属性定义，它可以用来实现转发检查，转发后的处理等特性。转发规则的宿主是人工活动环节。
转发和流转的区别在于，流转是结束当前环节的待办任务并且为输出的目标环节生成待办任务，转发则是结束当前待办任务为其他处理人在当前环节再生成新的待办任务。流转是环节发生了改变，而转发环节并没有改变。
执行规则是其他环节在做流转操作或者回退操作，也有可能是当前环节在做转发等操作而流入当前环节时的属性定义，也就是当前环节被激活是的熟悉定义。执行可以用来实现处理人范围选择，处理方式选择，提醒方式选择，初始化待办任务和初始化环节变量等特性。执行规则的宿主是人工活动环节。
执行规则对象模型图
通知指的是当工作流发生某些操作时，需要通过待办任务，邮件，短信或MSG等方式告知其他人，例如请假审批通过了，采购申请通过了等等。接收人收到通知以后，绝大多数的处理方式都是看看就完了，不需要做任何处理。
通知规则是在工作流在做流转，回退，终止，启动和结束时的通知相关属性定义，它可以用来实现通知时机选择，通知接收人范围选择，通知方式选择，通知处理方式选择等特性。
通知规则宿主即可以是人工活动环节，又可以是工作流定义本身。两者的区别在于当通知规则的宿主是人工活动环节时通知时机的选择是环节级的操作，例如流转和回退等。而当通知规则宿主属于工作流定义本身时通知时机的选择是工作流级的操作，例如启动和终止等。
通知规则对象模型图
分支规则用于AND环节处于分支模式是对输出的选择控制，它用来实现对AND分支的输出的可选和必选的控制。
分支规则对象模型图
&分支规则只有在AND环节处于分支模式时才起作用，根据图里的案例，例如当项目金额&1000万时环节C就必须处理，否则环节C处理不处理都可以。
聚合规则用于AND环节处于聚合模式时对输入的选择控制，它用来实现对输入的优先级排序，输入模式的选择和相关并行的待办任务的处理控制。聚合规则宿主是AND聚合环节。
聚合规则对象模型图
聚合规则只有在AND环节处于聚合模式时才起作用，根据图里的案例，例如环节A1处理完毕以后就可以直接到环节B而不用管环节A2和环节A3处理得怎么样。在环节A1没有处理完毕以前，环节A2和环节A3不能达到环节B，它们都只能等待。
子流程规则用于子流程环节对子流程的处理控制，它用来实现对子流程的模式选择，子流程和主流程间的关系描述等特性。子流程规则宿主是子流程环节。
子流程规则对像模型图
子流程有单实例模式和多实例模式两种（如图），例如一个单子有5个明细记录可以产生5个子流程实例实现各自独立审批。
变量用于在工作流运行的过程中可以把一些外界传入的，自动计算出来的或者初始化出来的数据存储下来。这些数据可以参与工作流的各种计算，例如业务表达式，组织范围，条件等。
变量根据其宿主的不同分为全局变量（过程变量）和环节变量（活动变量），当变量的宿主是工作流定义对象本身时是全局变量，而当变量的宿主是环节时就是环节变量（如变量定义图）。假设把工作流定义看成是一个类，则全局变量就是类的域变量，环节变量就是类里方法和函数内的局部变量。局部变量可以使用全局变量而全局变量无法使用局部变量。
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 变量定义图
在所有类型的环节中一般只有活动类的环节和会导致待办任务分支和合并的AND环节具有变量定义，那是因为只有此类环节才会导致变量的值发生改变。其他环节则只会使用变量，而不会导致变量值发生变更。
变量的名称，ID和值表达式组成，在工作流启动和运行过程中会对变量赋值或者使用变量值。在工作流运行期，变量以ID，VALUE的形式变量的ID和变量值存储于工作流实例和待办任务中。
变量对象模型图
由于变量定义和传输的复杂性导致一般用户不容易理解用好变量，所以为了较方便的满足绝大多数需求系统为每一个工作流都内置了一组特殊的全局变量即业务单据号变量。这组变量建立了工作流与业务单据之间的关联，存储业务单据号的值。
业务单据号变量目前一共有4个，它们分别是（如表）。也就是说目前工作流支持的业务单据号最多可以由4个字段组成。
业务单据号变量的值需要在启动工作流时从外界传入，可以在工作流中的任意地方基于业务表达式根据业务单据号获取到业务单据的详细信息，或者更新业务单据的信息。
变量的传递一般只会发生在环节变量中，例如环节A的输出变量如何变为环节B的输入变量。传递变量的途径就是转移，首先把环节A的变量输出到转移，然后环节B再从转移中读取（如图）。
转移定义了环节间的前后关系，说白了就是有向线条。基于转移还可以进行变量的传递，所以在转移上有变量定义。
转移对象模型图
组织范围指的是工作流中所有关于处理人范围和接收人范围等，表示组织机构树中特定范围的节点的定义，例如姓名叫张三的人，属于某个角色的人，属于某个部门下的岗位，这些都是表示组织机构树种某个特定范围的节点。
在一般的工作流产品中对组织范围的定义都以枚举的形式支持，例如在底层写函数枚举了获取申请人所属部门下拥有某个角色的人，获取当前操作者所属岗位下拥有某个角色的人等业务需求。假设用户再提需求要获取申请人所属同一公司下拥有某个角色的人，则就需要代码扩展了。而往往由于组织机构和业务需求的复杂性，此类需求是无法枚举完的，所以此模式是无法满足要求的。
&&&&&&&&&&&&&&&&&&&&&&&&&&& 组织范围定义图
为了满足复杂的组织机构形式和业务场景的需求，T6平台的工作流以业务表达式为基础通过原子函数组合的方式描述组织范围，叫做组织机构表达式。也就是说，系统默认只提供有限的原子函数（如表），然后通过以表达式的方式组合原子函数来满足复杂的组织范围的需求。
这些原子函数其实也只是系统默认提供的，针对T6平台的组织机构的原子函数。本质上工作流只要求组织范围表达式的返回值格式（如图），而并不管函数的具体形式和个数。
执行者对象模型图
当工作流需要适应一套新的组织机构时，只需要基于对应的组织机构形式再实现一些原子函数即可，不影响工作流整体的体系结构。甚至实现原子函数的个数和形式都可以根据组织机构来定，不一定所有原子函数都要实现完，例如有些组织机构里没有角色则角色相关函数就不管。
组织机构表达式本质上就是业务表达式，所有在运行期间也交由业务表达式引擎进行计算。
业务表达式用在工作流中用于实现条件判断，变量赋值，待办任务赋值和工作流实例赋值等特性。从表现上说业务表达式以代码片段的方式定义，在工作流运行期则代码片段被表达式引擎解析执行。
在工作流中构造业务表达式不仅可以使用系统提供的公共函数，还可以使用工作流变量，同时工作流也提供一些具有工作流特色的函数供外界使用（如表）。
工作流函数列表
一个已经实施上线的管理系统，由于业务需求的变更导致工作流发生变化，客户要求系统中没有批完的单据根据老的工作流来审批，新增单据按照新的工作流审批。这也就意味同一业务的同一工作流在系统中可能同时存在多个工作流定义（多个工作图），即多版本（如多版本体系结构图）。
&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 多版本体系结构图
在工作流定义中提供版本号属性， 在工作流设计器中当此属性被修改时则当前正在编辑的工作流定义不覆盖原始的工作流定义，而是重新生成一份。
对于工作流定义来说定位的依据不再是ID编号，而是ID编号加版本号，这就要求工作流启动时版本号也带入到工作流实例以标识此实例属于哪个版本的工作流定义。系统中所有相关工作流定义相关的函数都需要ID编号和版本号两个参数，当没有版本号传入时则默认最新版本。
工作流定义的版本号属性使用字符串表示，默认值为1.0。版本号不设编码规则用户可以随意编号，对于底层来说只要新修改的工作流定义版本好和老工作流定义不一致则认为添加了新版，否则直接覆盖老版本。
一般情况下，总公司的请假审批流程和分子公司的请假审批流程是存在差异的，小则环节的规则不一样，例如审批环节在总公司是部门经理在分子公司是公司经理。大则整个工作流定义都不一样，例如总公司有3个步骤，分公司1有5个步骤，分公司2有4个步骤。这就是说同一工作流由于其使用它的组织不一样而可能存在多个工作流定义（多个工作流图），即多组织。
&&&&&&&& &&&组织间工作流差异图
通常多组织都在一个工作流定义内通过条件判断的方式来实现，这种方式适用于差异小条件判断少的情况。而当差异很大条件判断很多时，这种方式会导致工作流定义变得复杂不可维护了，修改任一条条件判断都可能会影响到其他分子公司。
多组织的底层实现机制和多版本一样，都是同一工作流定义同时存在多份。同时工作流定义提供组织范围属性用以表示当前工作流版本适用于哪种组织。
工作流定义的Schema是工作流定义在XML文件中存储的形式，本文中不做详细描述，请参考工作流定义.XML文件。
工作流引擎是工作流的运行框架，它实现工作流服务的接口，围绕着维护处理待办任务和解析运行工作流定义两大核心能力构建。
工作流引擎是一个由多个组件组合而成的，“微内核”模式的体系结构（如图），其中的内核是待办任务引擎和工作流定义运行引擎，除此以外的其他组件都是上层扩展的，可以有多种实现方式的，都是可拆卸替换的。
工作流引擎对象模型图
工作流引擎体系结构中各子模块的概述如下：
l工作流服务组件（FlowEngine）达成工作流的服务接口和具体实现服务的内核组件之间的关联，同时负责实现组件间的关联。
l待办任务存取组件(TaskStorage)负责把待办任务的对象到数据库的存取。
l待办任务运行组件(TaskEngine)实现自由流能力，基于控制数据生成待办任务。
l工作流定义池组件(ProcessDefineEngine)负责把工作流定义从XML解析到对象，同时缓存和更新这些对象。它是全局唯一的单态对象。
l工作流定义运行组件(ProcessEngine)实现审批流能力，解析运行工作流定义。
l组织范围组件是工作流引擎的插件之一，实现组织范围表达式的计算。
l业务表达式组件也是工作流引擎的插件之一，实现业务表达式的计算。
l单据转换组件是工作里引擎插件之一，实现单据转换规则的解析执行。
工作流服务组件是工作流引擎的体系结构中真正实现工作流服务接口的组件，它是工作流引擎对外提供的组件。对外它是访问工作流引擎的入口负责接收服务请求，对内它是工作流引擎的调度控制中心负初始化各内部组件和维护它们之间的关联。
工作流服务组件可以是一个全局唯一的单实例对象，也可以每次访问工作流服务前动态创建。
工作流服务组件对象模型图
当工作流服务组件接收到服务请求以后，根据待办任务的类型和服务接口的类型，创建并初始化具体实现服务的内核组件，例如待办任务运行组件或者工作流定义运行组件，然后调用内核组件的服务函数，待函数返回后对的返回值再进行处理，要么保存，要么直接返回，最终完成服务。
在服务一个工作流请求的过程中，出于代码效率和代码结构化的考虑，除了在存储和读取两个地方和数据库打交道以外，其他地方无论是传着走的还是操作的都应该是待办任务的对象。
待办任务存取组件负责从数据库表中读出待办任务对象，或者把待办任务对象存入数据库。它是一个单纯的存取组件，而不管待办任务的如何构成，如何使用。它可以基于平台底层提供的DAS和业务实体机制构建，也可以认为它就是待办任务实体的控制器。
待办任务存取组件也是一个全局唯一的单实例对象。
待办任务运行组件实现工作流服务组件规定的内核接口，在不感知工作流定义的情况下单纯的实现针对待办任务的处理。待办任务运行组件由工作流服务组件在每次服务请求时动态创建，也就是说每个实例的只服务于一次请求，服务完毕以后实例就被释放。
待办任务运行组件对象模型图
（ProcessDefineEngine）
工作流定义工具生成的工作流定义都是以XML文件的形式存在的，如果在工作流运行的过程中通过操作XML文件的方式读取工作流定义则会带来代码效率和代码结构化的问题，所以需要把XML文件装载入工作流定义的对象里，然后在运行的过程中操作此对象。
同时因为效率的问题不能每次服务一个请求就做一次把XML文件装载到对象，所以需要把工作流定义的对象缓存下来。
工作流定义服务组件对象模型图
工作流定义池组件是一个全局唯一的单实例组件，由于每次请求一个工作流定义对象它会动态的从XML文件载入此工作流的定义，所以载入的过程是需要线程同步的。避免重复载入。
（ProcessEngine）
工作流定义运行组件
是工作流体系结构真正实现解析和运行工作流定义的组件，它实现审批流，业务流和单据流的能力。工作流定义运行组件指的不是某一个的对象，它是由多个组件组合而成的（如图）。其中最内核的是调度组件，规则运行组件和环节运行组件。
工作流运行组件对象模型图
&&& 在此体系结构中，规则运行组件和环节运行组件是内核组件，每一种类型的规则或者每一种类型的环节都有对与之应的运行处理组件。这些运行组件由调度组件来统一创建，调度处理。
调度组件是工作流定义运行组件的控制中心，它实现工作流服务组件规定的内核接口。根据工作流定义推进工作流运行。它集成自待办任务运行组件。
工作流运行调度组件对象模型图
调度组件采用PetriNet网算法，根据工作流定义的环节和转移推进工作流运行。在推进的过程中，遇到不同的环节时就创建与之对应的环节组件来处理此环节。
动作处理插件对象模型图
规则组件由环节组件在处理环节的过程中调用，规则组件实现对规则的一些公共处理，例如根据生效条件算出起作用的规则，生成控制数据等。
规则处理插件对象模型图
在工作流中每一种环节都有一个与之对应的运行组件，实现对环节的处理。环节组件必须实现调度组件规定的接口。
环节处理插件对象模型图
表达式计算插件对象模型图
工作流实例对象模型图
TA的最新馆藏[转]&[转]&[转]&[转]&[转]&[转]&
喜欢该文的人也喜欢