（计算机科学与技术专业论文）jpdl流程建模在行政执法系统中的应用.pdf

口d l 流程建模在行政执法系统中的应用 摘要 随着电子政务的推广和深入，工作流技术己成为该领域的主流技 术，工作流管理的主要目标是通过调用有关的信息资源和人力资源来 协调业务过程中的各个环节，使之按照一定的顺序依次进行，从而实 现业务过程的自动化。在计算机和网络使用越来越广泛的今天，工作 流管理系统正在吸引来自研究机构和产业界越来越多的关注。 业务流程定义是对实际的业务流程进行形式化定义，一个好的业 务流程定义规范是实现一个具有高度的灵活性、可靠性、可伸缩性和 互操作性的工作流管理系统的关键和基础。工作流技术发展至今产生 了许多流程定义规范，这些规范在工作流的发展过程中起到了非常重 要的作用。但是通过对这些规范进行深入研究可以发现传统的业务流 程定义规范存在许多缺陷，如无法对流程中特殊的情况进行定义等， 致使工作流管理系统的应用受到限制。 j p d l 是一种新的流程定义语言，与以往流程定义语言有很大的区 别。j p d l 除了提供以往流程定义语言所提供的节点类型以外，还提 供了其他一些特殊的节点类型。通过使用j p d l 提供的节点类型，用 户可以更方便、符合实际情况地对业务流程进行描述。 本文探讨了工商行政业务流程描述中存在的特定问题，给出了 j p d l 所提供的对这些问题的解决办法。通过对工商行政执法系统进 行分析。笔者选择了两个具有代表性的业务流程为例子，使用j p d l 流程定义语言对其进行描述。最后，将流程定义部署到系统中，并给 出了使用这些流程定义进行开发所得到的结果页面。通过这些例子， 我们可以看到在电子政务系统开发过程中引入j p d l 所带来的快捷、 方便的优点。 关键词电子政务流程定义j p d lj b p m 第1 页 t h ea p p l i c a t i o no f d lp r o c e s sm o d e l i n g qb u s i n e s sa d m 匝n i s t ra t i o ns y s t e m a b s t r a c t a st ot h ep o p u l 撕t ya n dp e n e t r a t i o no fe i g o v e m m e n ts y s t e m ， w o r k n o wt e c l l l l o l o g yh a sb e c o m eam a i n s 虹p a mo ft h i sd o m a i n t h em a i n t a 唱e to fw o r k n o wm a n a g e m e n ti st oa d j u s tr e l a t i v ei n f o n n a t i o na n d h u m a l lr e s o u r c et 0c o o p e r a t ee v e 呵a s p e c to fw o r kp r o c e s s t h i sw i l l m a k ew o r kp r o c e s se x e c u t e da c c o r d i l l gt op r e s e to f d e r s o 础i e v em e g o a lo fw o r kp r o c e s sa u t o m a t i o n n o w a d a y s ，c o m p u t e r 锄dn e t w o r kw e r e w i d e l yu s e d ，m o r ea n dm o r er e s e 鲫c ho 玛锄i z a t i o l l sa i l di l l d l i s t r i e s a r e p a y i n ga 牡e 幽o nt o 刚i r k f l o wm a n a g e m ts y s t e m s p r o c e s sd e f i n i t i o ni sf o r n l a i i z e dd e f i l l i t i o no fr e a lw o r kp r o c e s s ，a w e up r o c e s sd e f - m e 撕t e r i o ni sc m c i a lt oa 、v o r k f l o wm a n a g e m e ms y g t e m o fa g i l i 劬r e l i a b i l i 吼s c a l a b i l i t ) ，a n dm a n e u v e r a b i l i 哆t h e r ew e r em a j l y p r o c e s sd e f i n ec r i t e r i o n sd u r i n gt h ep e r i o do f w o r k n o wd e v e l o p m e m ，a n d h a dp l a y e da 1 1i m p o r t a l l tp a n b u t 勰e rc a r e m l l yl o o k e di r l t ot h o s e c r i t e _ r i o n s ，w ec a i lf o u n dt l l a tt 1 1 e yh a dm a i l yd e f e c t s ，s u c ha sn o ts u i t a b l e f o rs o m e s p e c i a l s i t u a t i o n si l l p r o c e s sd e f i n i t i o n ，w h i c h1 i m i t m e 印p l i c a t i o no f 、o r k n o wm a n a g e m e ms y s t e m j p d li san e wp r o c e s sd e n n ec r i t e r i o n ，i ti sd i f f e r e n tt ot r a d i t i o n a l c r i t e r i o n s j p d lp r o v i d e sm o r en o d et y p e sw h i c hw ec a nn o tf o u n di n t r a d i t i o n a lp r o c e s sd e f i n ec r i t e r i o n u s e r sc a nd e f i n ep r o c e s s e sa c c o r d i n g t om er e a ls i t i l a t i o na tm o s t w e 、) l r i l lp r o v i d es o m es p e c i a ls i n j a t i o n se x i s tw h e nd e f i n ep r o c e s s e s o fb u s i n e s sa d m i n i s 仃a t i o ns y s t e mi nm i sp 印e r ，a n dd i s c u s ss o i u t i o n sb y u s i n gd i 腩r e n tp r o c e s sd e f i n ec r i t e r i o n s a 髓rc o m p 撕s o n ，w ew i uf i n d 第2 页 t h e a d v a n t a g e o fj p d l a c c o r d i n g t o r e q u i r e m e m o fb u s i l l e s s a d m i n i s 缸谊t i o ns y s t 咖，w ec h o o s et 、oc m c i a lp r o c e s s e s 勰e x a m p l e sa 1 1 d d e f i n e l e mu s i n gj p d lp r o c e s sd e f i n e 翻t e r i o n w bw i nd 印l o yt l l 0 d e f i n “i o n st 0 廿l ed a t a b a s ea f t e rt l l e yw e r ed e f i n e d w bw i l ld e v e l o pt l l e s y s t e mu s i n gd 印l o y e dp m c e s sd e f i n i t i o n s ，a 1 1 dg i v es o m ef i n a lp a g e s d e v e l o p e db yu s w bc a nf i n dm ea d v a l l 诅g e so fa p p l y i n gj p d lp r o c e s s d e f i n e 嘶t e r i o nt 0 e g o v e m m e ms y s t e md e v e l o p m e n t 廿l m u 曲m e e x 锄p l e so fd e f m e ，d 印l o ya 1 1 dd e v e l o p a tl a s t ，w e w i l lm a k ea c o n c l u s i o no fw h a t 、v eh a v ed o n ei nt h j sp a p e ra n dp m s p e c t 如t u r ew o r k o f 印p l y i n gj p d lp r o c e s sd e f i mc f i 钯r i t oe - 9 0 v e m m e ms y s b 锄 d e v e l o d m e n t k e yw o r d s ： e g o v e m m e n t ；p r o c e s sd e f i n i t i o n ；j p d l ；j b p m 第3 页 独创性( 或创新性) 声明 本人声明所呈交的论文是本人在导师指导下进行的研究工作及取得的研究 成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不 包含其他人已经发表或撰写过的研究成果，也不包含为获得北京邮电大学或其他 教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任 何贡献均已在论文中作了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 本人躲( ，越圣鸟魄! z 丝：羔 j 关于论文使用授权的说明 学位论文作者完全了解北京邮电大学有关保留和使用学位论文的规定，即： 研究生在校攻读学位期间论文工作的知识产权单位属北京邮电大学。学校有权保 留并向国家有关部门或机构送交论文的复印件和磁盘，允许学位论文被查阅和借 阅；学校可以公布学位论文的全部或部分内容，可以允许采用影印、缩印或其它 复制手段保存、汇编学位论文。( 保密的学位论文在解密后遵守此规定) 保密论文注释：本学位论文属于保密在一年解密后适用本授权书。非保密论 文注释：本学位论文不属于保密范围，适用本授权书。 本人签名： 导师签名： ：蓁：鞋 1 1 论文背景 第一章绪论 从上世纪9 0 年代初起，我国政府部门就开始大规模的电子政务系统建设。 电子政务系统建设过程中最突出的问题就是政府机构、政策以及法律法规等变化 过快，而政务流程的设计是以相应法律法规为依据的，因此政策的快速变化必然 导致政务流程的改动也极为迅速。目前遗留下来的政务系统大都以硬编码的方式 对业务流程进行描述，因此业务流程与系统其他部分功能的耦合性过大。国家、 地方政策的改变都会给系统带来巨大的变化，使得系统难以维护，大大缩短了系 统的生命周期。 工作流技术可将业务逻辑从具体的业务实现中分离出来，使得业务流程的再 造不再对系统造成很大的影响。政策、法规发生变化时，用户只需改变相应的业 务流程。因此，自9 0 年末起，电子政务系统开发中越来越多地引入了工作流技 术。工作流技术的优劣很大程度上取决该工作流管理系统所使用的流程定义规 范。 工作流技术发展至今产生了许多流程定义规范，包括) 印d l 、b p m l 、w s c i 、 b p e l 4 w s 以及e b 沮。等。这些定义规范是在不同背景下，基于不同的应用侧 重点提出的，有各自不同的优点。这些定义规范在政务系统中的应用提高了系统 的灵活性，减少了系统的维护工作，促进了电子政务系统的发展。但这些规范也 存在许多不足，如对业务过程描述能力有限。例如，在案件审批流程中，案件审 批通过后进入结案阶段。结案需要完成的工作主要是填写“行政处罚决定书”，并 结束该案件。结案节点的这些工作可以不需要人工的参与，而由系统自动处理。 但是，传统流程定义规范没有提供可以描述自动化节点的节点类型。因此，它们 不能对这种情况进行描述。同时，传统流程定义规范还具有描述过于繁杂，对业 务过程定义合理性约束不足以及定义出的流程柔性不足等特点，使得工作流技术 在实际应用中缺乏灵活性和稳定性，工作流技术的应用受到了一定的限制。 1 2 问题的提出 由以上问题可以看出，传统流程定义规范并不太适用于电子政务系统的开 发。在电子政务系统开发过程中，我们需要一种简单、易用、可扩展的流程定义 规范。j p d l ( 旧p mp r o c e s sd e f i i l i t i o nl 舯g l l a g e ) 是j b o s s 组织提出的一种新的 第l 页- 流程定义规范。它把一个业务流程看作是一个明订l 活动图，详细定义了这个活 动图的每个部分，如起始、结束状态，以及状态之间的转换等，有利于业务人员 和开发人员之间的沟通。与其他流程定义规范不同，j p d l 使用状态管理来扩展 j a v a ，并使之与编程语言的能力之间的重叠尽量的小，而其他的流程定义规范并 没有做出这种明确的分离。同时，j p d l 还是一种简单、开端( o p e n e n d e d ) 的 流程定义规范。 电子政务系统业务复杂多变，并且存在许多独特的业务要求，如任务自动化、 子流程定义等。这些问题在政府业务工作中起着十分重要的作用。同时，我们还 要注意流程定义的灵活性与可扩展性。因此，在将j p d l 流程定义应用于电子政 务系统开发过程中我们需要集中精力解决如下几个问题： 1 自动化节点定义闯题：自动化节点只的是在流程执行过程不需要人工参 与的节点类型。例如，在案件审批流程中，案件经过市局审批后将确定 最后处理办法。如果市局审批决定对案件进行销案处理，那么案件就进 入销案处理步骤。销案处理所要完成的工作主要是填写“销案决定书”， 该工作可以不需要人工参与，只需要系统根据案件信息进行填写。但是， 传统流程定义规范提供的节点类型都需要人工参与，不存在可以用来描 述自动化节点的节点类型。因此，我们不能使用传统流程定义规范对包 含自动化节点的流程进行描述。所以，传统流程定义规范不能满足电子 政务业务的这种特殊需要。 2 多任务分配问题：多任务分配指的是在流程执行过程中，多个不同的任 务需要由同一个用户完成。例如，在日常巡查流程中，办案员甲在巡查 时发现企业b 存在问题，于是将企业b 以及该企业存在的问题上报给上 级领导乙。领导乙在查询企业b 信息以及该企业存在问题时，认为办案 员甲上报的问题比较严重，需要甲进行核实。办案员甲收到上级领导核 实指令后，对企业b 进行再次检查。在这个流程中，向上级领导汇报问 题以及对企业进行核实的工作需要由同一个办案员来完成。但是，传统 流程定义不提供对多任务分配的支持。因此，我们需要完成额外的工作 来实现该功能。 3 子流程定义问题：子流程是指在流程的执行过程中，流程的某个步骤需 要调用另外一个单独的业务逻辑，这个新的业务逻辑就叫子流程。例如， 在日常巡查过程中，巡查员发现企业存在问题上报给上级领导，上级领 导审批后指示巡查员责令企业进行改正。这个时候，办案员就需要开始 调用责令改正子流程。待子流程运行完毕后，主流程开始继续执行。我 们需要注意到，在调用子流程的过程中，主流程需要向子流程传递一些 第2 页 包含主流程信息的数据。在子流程执行完毕后，这些信息有可能已经被 修改。因此，我们还需要将这些信息再次传回主流程，以备主流程在执 行过程中使用这些得到更新的数据。在子流程的定义过程中，我们要注 意它对主流程所带来的影响，以及流程之间信息的传递等问题。 1 3 论文的主要工作 针对上面提出的问题，本文将从以下几个方面展开讨论： 1 分析j p d l 流程定义语言：介绍j p d l 流程定义语言，分析j p d l 流程 定义语言中存在的流程定义元素。对j p d l 的流程定义元素进行分类， 从而使我们对j p d l 流程定义语言形成了初步认识。 2 分析电子政务业务中存在的问题并给出解决办法：分析电子政务业务中 存在的问题，如自动化节点定义、子流程定义等，给出传统解决办法。 在分析传统解决办法不足的基础上，给出j p d l 流程定义规范的解决方 式，并分析新式解决办法的优点。 3 实现工商行政业务工作流原型：分析工商行政业务需求，选择具有代表 性的业务流程，如日常巡查、案件审核等。结合j p d l 流程定义规范， 给出具有代表性业务流程的分析与设计。在此基础上，使用j p d l 实现 代表性业务流程。将流程定义部署到系统中，使用这些流程定义进行业 务开发，并给出示例结果， 1 4 论文的组织结构 为了更好的说明以及解决本文提出的问题，笔者将本文的结构设置成如下形 式： 第一章绪论介绍了本文所涉及的实际项目的背景情况，分析了在实际开发 过程中所遇到的问题，并简单介绍了整篇论文需要完成的工作。 第二章j p d l 流程定义规范介绍了一种新的流程定义规范以及该规范所包 括的元素，与传统流程定义规范进行比较，指出其如何解决传统流程 定义规范存在的问题使得其适用于电子政务系统的开发。 第三章应用关键问题介绍了电子政务业务开发过程中存在的关键问题，分 别使用传统流程定义规范以及j p d l 解决这些问题。通过比较，给出 j p d l 所能提供的更好解决办法，为后续实际应用打下基础。 第四章j p d l 在工商行政执法系统中的应用在关键问题分析解决的基础上， 结合工商行政执法工作流的需求，给出工商行政执法业务中具有代表 性的业务流程的设计与实现。最后将行政执法业务流程定义部署到系 第3 页- 统中，并给出了系统的实现结果。 第五章总结与展望对本文工作进行了总结，并针对本文工作中存在的问题 进行未来工作展望。 第4 页 第二章j p d l 流程定义规范 j p d l ( j b p mp r 0 h 淄s 喇t i 伽l a n g i m g c ) 是j b o s s 组织提出的一种新的流 程定义规范，它把一个业务流程看作是一个u m l 活动图，详细定义了这个活动 图的每个部分，如起始、结束状态，以及状态之间的转换等，有利于业务人员和 开发人员之间的沟通。j p d l 指定了一个咀，模式，这个机制打包所有的业务 程序定义相关文件迸一个业务程序存档文件。 与其他流程定义规范不同，j p d l 使用状态管理来扩展j a v a ，并使之与编程语言 的能力之间的重叠尽量的小，而其他的流程定义规范并没有做出这种明确的分 离。同时，j p d l 还是一种简单、开端( o p e n 嘲1 d e d ) 的流程定义规范，除了规 范提供的节点类型外，用户还可以自定义特定节点类型。 3 1 节点( n o d e s ) j d p l 每个节点都有两个职责：执行节点动作、控制流程的执行。对于控制 流程的执行，每个节点可以有以下几种选择： 1 暂停流程执行：通过进入等待状态实现； 2 从某个变迁离开节点继续流程执行：进入节点的原始信令通过节点的某 个变迁分支离开节点。该节点作为自动节点在执行完动作后自动进入流 程的下一状态； 3 创建新的执行路径：节点可以创建新的信令组，每个新的信令代表一条 新的执行路径，信令在离开该节点的时开始执行； 4 结束执行路径：节点可以结束执行路径，即终止信令并进入执行完毕状 态： 5 节点还可以改变流程的执行结构：执行结构指包含树状结构信令组的流 程实例，每个信令代表一条执行路径。节点可以创建或结束信令，将信 令置于流程的节点中，并在变迁的时候载入信令。 j d p l 流程定义规范包括如下几个具体节点类型： 3 1 1 任务节点( t a s k - n o d e ) 一个任务节点包含一个或多个任务( t a s k ) 子元素和完成这些任务的用户 ( 璐e r ) 。任务代表一个或多个需要用户完成的动作。当流程执行到任务节点时， 系统会自动创建任务对应的任务实例( t a s ki n s t 雏c e ) 。一个任务元素对应着一个 任务实例，并且将它们放迸用户的任务列表中。之后，流程就进入等待状态，直 到所有任务实例都被用户执行完为止。用户执行完所有的任务实例后，流程自动 变迁到下一节点( 相当于给当前的信令( t o k e n ) 发了一个信号( s i g n a l ) ) ，继续 第5 页 流程的执行。 3 1 2 状态节点( e t a t e ) 状态节点( s t a t e ) 是纯粹的等待状态节点( w a i ts t a t e ) ，与任务节点的区别在 于它不会自动创建任务实例。流程执行到该类型结点时进入等待状态，直到当前 信令发一个信号。因此要让流程离开状态节点，必须在程序中有t o k e n s i g n a l o 之类的调用，否则流程将一直处于等待状态。 该结点的典型的用法就是：流程进入该节点时，发送一条消息到外部系统， 然后流程就进入等待状态。外部系统完成相应操作后返回一条消息，该消息触发 一个信号到信令，流程开始继续执行。 3 1 3 流程状态( p r o s s s t a t e ) 一个流程状态( p 揪瑚ss t a t c ) 对应一个超级流程( s u p c rp r o c e 黯) 的调用。 当流程执行到流程状态时，父流程将启动一个子流程。在子流程的执行流程中， 父流程将一直处于流程状态直到子流程执行完毕，然后离开流程状态继续流程执 行。 3 1 4 判断节点( d e c i s i o n ) 当需要在流程中根据不同条件来判断执行不同路径时，就可以用判断节点 ( d e c i s i o n ) 节点，一个判断节点可以有任意多的变迁路线。当工作流引擎需要 根据上下文( c o n t e x t ) 来选择变迁路线时，可以使用决策模型进行建模或者采用 多个变迁离开某个节点的方式建模。在后一种情况下，用户需要通过指定变迁名 称来决定变迁路线。 工作流引擎根据判断节点的转向条件，决定执行哪一个转向。遇到第一个满 足条件的转向就执行，如果没有满足条件的转向，那么就执行默认转向( 第一个) 。 所以判断节点和节点( i l o d e ) 一样，是即时状态，不会停下来让用户参与决定。 3 1 5 节点( n o d e ) 节点( n o d e ) 是专门用来添加用户代码的，是j p d l 流程定义规范最具特色 的一种节点类型。节点要求有一个动作( a c t i o n ) 子元素，该元素对应着一个实 现了a c t i o i l h 卸d l e r 接口的类名。在该类的c 】【c c u t e 0 方法中可以实现任何操作， 如调用j a v a a p i 、e j b 等。 当流程到达该类型结点时，动作元素对应的实现了a c t i o n h 卸m c r 接口的类 第6 页 的c x e c u t e 0 方法会自动执行，从而实现用户所需求的操作。但要注意的是，该实 现类应对流程的继续执行负责，一般是通过在该类的e 】【e c u t e o 方法体的最后加上 既跏i o n c o n 钯赋1 翰v e n o d e o 来实现。 3 2 变迁( t r a n s i t i o n s ) 变迁( t 舢m o n s ) 用以标明节点之间的有向连接，包括一个起始节点和一 个目的节点。起始节点由觚m 属性指定，目的节点由t o 属性指定，变迁元素应 该放置在变迁离开的节点内部，用户可以选择给变迁起名字。由于工作流引擎是 通过名字来识别不同的变迁，因此，多个变迁具有相同名字时，工作流引擎将使 用第一个找到的具有该名字的变迁。 一个节点中可能存在多条变迁路线具有相同名字，因此 g e t l e a v i n g t r a l l s i t i o n s o 返回的变迁路线数大于等于g e t l e a v i n g t r 醐s i t i o n s m a p o 返 回的数目。变迁路线列表中的第一条变迁路线为默认变迁路线。 3 3 动作( a c t i o n s ) 动作( t i o n ) 是一段i a v a 代码，在流程执行过程中触发一个事件时工作流 引擎会执行这段代码。动作是流程定义元素的子元素，父元素加上事件类型 ( e v t 咖e ) 精确定义了业务流程中动作执行的时间，一个动作的可能事件类 型取决于其包含的动作元素。通过重载系统函数，用户可以自定义节点的动作， 使节点执行恰当的业务逻辑并在节点执行完动作以后继续流程的执行。 动作的执行是通过委派来实现的，委派是一个机制，用来在业务程序的执行 中包含用户的定制代码。委派类是指，在业务程序实例的执行过程中被调用的用 户自定义的j a v a 类。用户提供的这些类，会被系统所调用。同时这些类可以使 用系统传入的业务程序实例和任务等的信息。委派模式，就是把任务交给下层助 手类去处理。工作流管理系统中之所以叫我们自定义的类为委派类，就是因为系 统把任务交给了这些助手类，通过接口调用这些助手类。a c t i o n h a l l d l e r 等实现 类，实际上还是委派模式的委派者，它们可能还会继续把任务委派给助手类。 事件( e v e n t s ) 指定流程执行过程中动作发生的时刻，工作流引擎会在计算 下一流程状态的时候触发事件的执行。事件总是与流程定义中的元素相关联，如 流程定义、节点或变迁。大部分的流程元素都可以触发各种类型的事件，如进入 节点( n o d c e n t e r ) 或离开节点( n o d e ，l e a v e ) 等。事件是动作的一个跳板，每个 事件都有一个动作列表，当该事件被触发时，这些动作就会被执行。 一第7 页， 3 4 泳道( 8 w i m i a n e ) 一个参与者需要负责一个流程中的一个或多个状态，j p d l 通过创建泳道 ( s 埘n l l 锄e ) ，并将某参与者负责的所有状态分配给该泳道来实现的。j d p l 中的 泳道( s w i l l 锄e ) 概念是由u m l 活动图中引入的。泳道( s w h n i 锄e ) 是在流程 级别上定义的，在业务流程中可以被视为一个参与者在该流程中的角色名称，它 定义了流程中的多个任务由相同参与者完成 3 5 事务划分 多数情况下，流程的同步执行是一种简单的处理方式。流程执行可以很方便 的绑定到服务器端事务中，在一个事务中，流程由一个状态变迁到另一个状态。 但是，某些情况下，流程内的计算需要耗费大量的时间，给用户带来很大的不便。 为了处理这种情况，j p d l 允许流程以异步方式执行。如图3 2 中所示，节点b 是一个需要花费大量时间执行动作的节点。在使用同步执行方式情况下，流程在 接收到外界发送的信号( s i l 霉a 1 ) 后进入节点b 执行相应动作，直到动作执行完 毕，然后进入节点c 。在使用异步执行方式情况下，流程在接收到外界信号后， 首先进入节点b 。但是流程并不等待节点b 将动作执行完毕，而是向系统发送一 个异步消息，然后进入节点c ，节点b 的动作将在后台继续执行。 ，第8 页 图2 一l 流程异步执行 在j p d l 的任意节点中。将a s ”c 属性设置为t n l e 即打开节点异步执行方式。 异步执行的节点不会在客户端线程中执行任务，而是将消息发送到异步消息系 统，然后返回客户端。由于客户端代码可以提交事务，因此发送消息的动作将在 流程中更新事务状态。事务更新的结果是信令转移到了下一个节点( 但还没有执 行) ，并且消息通过异步消息系统传递到了命令执行器。随后，命令执行器从消 息队列中提取消息并开始执行，每个命令都将在单独的事务中执行。 在打开流程异步执行方式前，用户需要先打开命令执行器。用户在使用过程 中不需要花过多的精力在异步消息上，只需要记住一点：默认情况下系统会在客 户端的事务中执行任务，直到整个计算过程结束，然后进入等待状态。将弱) r 1 1 c 属性设置为仇l e 将会对流程事务进行划分。 3 6 本章小结 由以上的分析与介绍，我们可以对j p d l 流程定义元素分成以下几个层级： 第9 页 1 图形元素( g r a p he l e m e n t ) ，每个可拖放对象都是一个图形元素。图形元 素包括以下四个属性： 1 ) 流程定义( p r o c e 韶d e f i n e ) ：表示当前元素属于哪个流程定义； 2 ) 事件( e v e l i t s ) ；表示可以接收哪些事件： 3 ) 名字( i l 锄e ) ：表示该图形元素的名称； 4 ) 异常处理( e x c e p t i o nh 锄d l e r ) ：异常处理类集合。 2 节点( d e ) 、变迁( t r 髓s i t i o n ) 、任务( 协k ) ，它们都继承自图形元素。 1 ) 节点( n o d e ) ：表示定义的节点，包括四个属性；离开变迁( l e a v i n g t r 趾s i t i o 瞄) 、迸入变迁( m r i v i n gt r a i l s i t i o n s ) 、动作( a c t i o n ) 以及 超级状态( s u p e rs t a t c s ) ； 2 ) 变迁( t r 黜i t i o n ) ：表示转移，它有三个属性：从( 丘d m ) 、到( t 0 ) 、 支持的事件类型( s u p p o r t c de v e m l y p e s ) ； 3 ) 任务( t a s k ) ：表示定义的任务。 3 判断节点( d e c i s i o n ) 、开始状态( s 毛a r ts t a l e ) 、结束状态( e n ds t a l e ) 、 分支节点( f o r k ) 、合并节点( j o 址) 、状态节点( s t a t e ) 、流程状态( p r o c e 站 s t a l e ) ，这些节点都继承自n o d e 节点。 j p d l 通过变迁、分支和合并等概念定义了状态之间的控制流。当一般的程 序逻辑更适合业务需求时，业务流程开发者应该在一个流程事件上标明一个动作 ( a c t i ( m ) 。 第1 0 页 第三章应用关键问题 工商行政执法是个复杂的过程，行政执法过程中存在许多特殊的业务要求， 如自动化节点定义、子流程定义等等。传统流程定义规范不支持或不能很好的支 持这些特殊要求的定义。对于这个问题的解决有多种办法，可以使用传统流程定 义规范解决业务逻辑问题。而编写特定程序解决流程执行中遇到的这些特殊问 题。但是，这种办法将会消耗用户很大精力，而不能将注意力集中在如何更好的 对流程做出定义以及改进。下面我们将对这些特殊要求的部分做出分析，并探讨 j p d l 如何对这些特殊要求提供更好的支持。 3 1 自动化节点定义 3 1 1 自动化节点定义场景 自动化节点指的是节点动作不需要人工参与，可以完全由机器执行的节点类 型。政务流程中有许多这类特殊应用，如案件审核流程中，案件经过市局审批后， 上级指示办案员对案件进行销案处理。办案员在收至4 指示后，开始案件的销案处 理。销案的主要工作是填写“案件销案书”，并注销该案件。随着社会电子化程度 的提高，填写“案件销案书”的动作不再需要人工执行。而交由系统根据案件信息 以及上级审批意见，使用“案件销案书”模板进行填写，生成最终的“案件销案书”。 图3 1 案件销案流程 除j p d l 以外，所有的流程定义规范都只提供需要用户参与的节点类型。因 此，我们不能直接使用传统流程定义蠹孚决该问题。下面我们来看看在使用j p d l 流程定义规范以前，我们是如何解决这个问题的。我们有两种方式解决该问题： 第l l 页 第一种办法，将销案节点与市局审批节点合并到一起，组合成一个新的流程节点。 这样，我们就不再需要办案员关心何时执行销案操作。这种办法虽然解决了问题， 但却带来了许多附加问题：首先，使用这种办法描述的流程定义并不能反映出案 件审批的真正流程；其次，这种解决办法容易造成人员的职责混乱。例如，本来 需要由办案员完成的销案工作被分配给了市局审批员。 图3 2 合并审批与销案 第二种解决办法，使用传统流程定义规范中提供的需要人工参与的节点类型 对销案节点进行定义。使用这种方法进行插述，得到的流程定义符合案件审批的 实际过程。但是，这种解决办法仍然存在一些问题。例如，原来不需要人工参与 的销案动作变成需要人工进行干预，虽然办案员的工作只是让流程进入下一个节 点。但是，这种解决办法也在一定程度上加大了办案员的工作量，降低了案件审 批工作的执行效率。 3 1 2 n o d e 用于自动化节点定义 n o d e 节点是j p d l 流程定义规范最具特色的一种节点类型，是专门用来添加 用户代码的。当j p d l 提供的节点类型不能满足需要时，用户可以使用n o d e 节点 进行扩展。在n o d e 节点中定义特定的业务逻辑，生成符合业务需要的特定节点 类型。j p d l 通过n o d e 节点类型提供了很好的可扩展性。 n o d e 元素要求有一个动作( a c t i o n ) 子元素，该元素对应着一个实现了 a c t i o n h a n d l e r 接口的类名。在该类的e x e c u t e ( ) 方法中可以实现任何操作，如 调用j a v aa p i 、e j b 等。当流程到达该类型结点时，对应动作类的e x e c u t e ( ) 方 法会自动执行。但要注意的是，该实现类应对流程的继续执行负责，一般是通过 在该类的e x e c u t e ( ) 方法体的最后加上e x e c u ti o n c o n t e x t 1 e a v e n o d e ( ) 来实现。 以日常巡查流程中的责令改正步骤为例，我们可以使用n o d e 节点对责令改 正步骤进行定义，得出如下节点描述： - 第1 2 页 其中，责令改正步骤需要完成的动作包括：调用责令改正予流程，取得子流 程执行结果，最后继续主流程的执行。在责令改正节点的动作类中实现这些操作， 我们可以得到如下所示的动作代码： p u b l i cc l a s sc l o s e c a s ei m p l e m e n t sa c t i o n h a n d l e r p u b l i cv o i de x e c u t e ( e x e c u t i o n c o n t e x tc t x )t h r o w se x c e p t i o n 填写案件销案书 继续案件审批流程的执行 e x e c u t i o n c o n t e x t 1 e a v e n o d e ( ) ： ) 由上面的例子可以看出，办案员不再关心销案步骤需要完成的工作。流程进 入销案节点后，销案节点自动完成“案件销案书”填写工作，同时继续案件审批 流程的执行。因此，这种解决办法提高了案件审批流程的执行效率。 3 2 多任务分配 3 2 1 多任务分配场景 多任务分配指的是在流程执行过程中，多个不同的任务需要由同一个用户完 成。例如，在日常巡查流程中，办案员甲在巡查时发现企业b 存在问题，于是 将企业b 以及该企业存在的问题上报给上级领导乙。领导乙在查询企业b 信息 以及该企业存在问题时，认为办案员甲上报的问题比较严重，需要甲进行核实。 办案员甲收到上级领导核实指令后，对企业b 进行再次检查。我们注意到，在 这个流程中，向上级领导汇报问题以及对企业进行核实的工作需要由同一个办案 员来完成。我们可以由以下的流程图中看出这个过程的详细描述： 第1 3 页 办擞蜓带 图3 3 多任务分配 传统流程定义没有提供对流程多任务分配的支持。因此，在使用传统流程定 义对流程进行描述，或者未使用流程定义时，我们需要单独解决该问题。一种可 行的解决办法是在流程定义过程中，对于需要由同一个用户完成的任务添加一个 特定的标识，并在数据库中增加一张数据库表用来存储该标识。在流程执行到第 一个带有标识的节点时，系统负责将该标识以及执行此任务的用户作为一对信息 存储在数据库中，存储的形式为( 标识+ 用户) 。在流程的后续执行过程中，如 果流程的某个节点包含标识，那么系统首先在数据库中查找是否存在包含此标识 的数据库记录。如果存在，则将该用户信息取出，然后将任务分配给该用户。如 果不存在，那么创建一个包含( 标识+ 用户) 的数据记录，然后将该记录存入数 据库中以备以后使用。 这种办法虽然能够解决上面提到的多任务分配问题，但是这种解决办法需要 开发人员管理任务的分配，并且导致开发人员在使用业务员提供的流程描述进行 形式化定义时，需要更多地与业务员进行沟通。因此，系统开发的效率就会降低。 3 2 2s 、i n i l 锄e 用于多任务分配 j p d l 从u m l 中引入了泳道( s 嘶i i l i 锄e ) 用于解决这个问题。s 谢m l a i l e 指定 一第1 4 页 流程的多个任务由同一个用户完成。在第一个任务实例为指定泳道创建后，参与 者将被流程记住，i 以各同一泳道中的后续任务使用。涌道具有记忆功能，能够记 住任务的原始执行者，并在任务再次执行时分配给初始执行者。由于泳道与参与 者的关系是存储在一个变量中，因此我们可以通过更新这变量来操纵这一关系。 在以下例子中，我们将创建一个办案员泳道，然后该泳道被分配给“巡查”节点， 以及“核实”节点。 铡鲫e n tc l 硒s a s s i 鲫n 1 ) e | 耐 = t a s ks 、 ，i m l a n e = ”i n s p c c t o r ，t 懿抄 仃a 邯i t i o nt o = 领导审批”卢 c a s k - n o d en a i i l 萨”领导审批 t a s ks 、v i m l a n e - ，i l l s p e c t o r 在这个例子中，当“日常巡查流程”执行到“巡查”任务，第一次进入办案员泳 道时，工作流引擎开始计算参与者。于是，办案员甲的名称将被存储在流程变量 i i l ! 籼r 中。当流程执行到“核实”任务时，再次进入办案员泳道。流程找到 抽s p e c 奴变量，并将令牌( t o k e n ) 分配给办案炅甲，于是“核实”任务便转移到 了办案员甲手中。当办案员泳道的第一个任务一“巡查”被创建时，泳道的 第1 5 页 a s s i 鲫i n p e c 自o r 将被调用，将办案员甲分配给巡查任务，函数传递的参数是办案 员泳道实例a 。在流程的后续调用过程中，办案员泳道中的所有任务实例的分配 都被传播到办案员泳道实例a 。这个行为是被作为默认实现的，因为办案员甲在 履行办案员的角色任务。因此，所有后续对办案员泳道的任务实例的分配都会自 动转到办案员甲。 3 3 子流程定义 3 3 1 子流程定义场景 工商行政流程中有许多特殊的应用，例如流程的某个步骤需要调用子流程。 子流程是指在流程的执行过程中，流程的某个步骤需要调用另外一个单独的业务 逻辑，这个新的业务逻辑就叫子流程。例如，在日常巡查过程中，巡查员发现企 业存在问题上报给上级领导。上级领导审批后指示巡查员责令企业进行改正。这 个时候，办案员就需要开始执行责令改正所要完成的工作。待责令改正子流程运 行完毕后，日常巡查主流程开始继续执行。我们需要注意到，在调用责令改正子 流程的过程中，只常巡查流程需要向子流程传递一些包含其流程上下文信息的数 据。责令改正子流程执行完毕时，这些传递过来的数据已经被更新。因此，我们 还需要将这些数据再次传回日常巡查主流程。以备主流程在流程继续执行时，使 用这些更新后的数据。 b 常邂霞 ， 、 ， 、 图3 4 责令改正子流程 第1 6 页 在使用流程定义语言以前，对于这个问题，我们采用的一种解决办法就是将 子流程与主流程放在一起。也就是，将责令改正子流程的步骤合并到日常巡查流 程中。这样，我们就不需要考虑子流程调用问题，也不需要考虑流程之间的信息 传递问题。但是，这种解决办法存在一些缺陷。例如，责令改正子流程的业务逻 辑发生变化时，我们就得对整个流程进行重新定义。因此，子流程的一个业务变 动都将带来整个流程的重构。 3 1 3 2 p r o c e s s s t a _ 钯用于定义子流程 p r o c e s s g t a t e 是j p d l 流程定义规范提供的一种元素，用来定义子流程。当流 程执行到包含该元素的步骤时，工作流引擎会自动调用p r o c c s s s t a t e 中指明的子 流程，并将子流程需要用到的上下文信息自动传递过去。如下所示： 在上面这个例子中，我们定义了一个o r d e r c h a n g e 节点。在该节点中，我们 调用o r d e r c l l a l l g e _ s u b 子流程。在调用子流程的过程中，我们向子流程传递了三 个变