工作流项目实施的
一些问题和解决策略
Issues and solutions of workflow projects
implement
版本：1.0
作者 ：胡长城 [ 银狐999 ]
https://www.doczj.com/doc/de6952377.html,
https://www.doczj.com/doc/de6952377.html,/james999
完成日期：2006-12-10 version 1.0
联系信箱：james-fly@https://www.doczj.com/doc/de6952377.html,
MSN ：fcxiao2000@https://www.doczj.com/doc/de6952377.html,
本文最早发表于《程序员》杂志2007年第1期
我们需要更多的原创······
更多工作流参考文档，请访问在https://www.doczj.com/doc/de6952377.html,
注：转载文章，请注明作者信息。
这两年工作流应用越发火爆了，大多管理信息系统都或多或少涉及到流程应用。一方面客户对流程认识和需求在提高，另一方面开发商也希望通过流程技术为客户提供更灵活的应用支持。
先简单说说什么是工作流：
工作流（Workflow）就是工作流程的计算模型，其表示的是：对流程中的任务（活动），以什么样的逻辑或者规则串接起来，并以什么样的模型进行表示和计算。
上面的概念解释比较抽象化，由于本篇不是定位于讲解工作流概念的文章，所以我们暂且不深入的探讨工作流的一些基础知识和理念。简单的举例加以说明：例如，在日常办公中，当撰写好某份报告之后，可能需要将其提交给领导进行审阅或批示；审批意见可能需要汇集并提交给另外一个人，以便对报告进行进一步的修改。这样，可能会形成同一篇文档在多个人之间的顺序或同时传递。对于这样的情况，我们可以使用工作流技术来控制和管理文档在各个计算机之间自动传递，而非手工传递。这就可以称之为工作流。
本篇主要探讨工作流实施过程中的一些需要注意的问题。对于工作流的实施，其实就是基于一个工作流引擎或平台，通过扩展开发实施，满足客户对流程信息化应用的需求。从一个开发商接手一个流程应用开发，到其给客户实施成功，需要面对一些比较棘手的决策性问题，而这就是本篇所要探讨的主题。通过对一些工作流实施问题的讲解和方案探讨，来辅助开发商进行一些基本决策。
第一个问题：为什么就一定需要使用工作流技术？
首先简单阐述一下为什么一定需要使用工作流技术。
我想最直接的原因应该是来自于客户的管
理和运营信息化的需求推动：在客户的运行管理
体系中，在不同的职能领域，是由各种各样的处
理流程交互协助的，而这些处理流程都是由一些
处理活动和任务组成的。传统的信息系统仅能满
足客户对数据处理信息化的最基本要求，却很难
满足客户对“协助处理信息化”的要求，这就是
客户为什么需要工作流技术的基本原因。
而从另一个角度来说，开发商也希望通过流程技术的应用，一方面提高流程项目的实施进度，另一方面则希望能够为客户带来更高体验度的实施效果。
这个问题不过多的解释，因为目前工作流的应用已经是越来越广泛。
第二问题：工作流技术就真的可以提供工作流项目实施进度吗？
这几年在工作流培训过程中，碰到很多技术人员问我这个问题。在他们看来：首先他们对工作流系统是存在一些困惑的，特别是从来没有接触过工作流系统的开发人员；其次他们搞不清楚工作流技术是否真的能提高项目开发进度。
单纯说使用工作流技术提高项目实施效率，这不一定就有
效。这几年的实施的流程项目很多，但只有个别几个，因为客
户对流程相关的应用应用的需求不是很复杂（如表单、权限
等），我们流程产品本身辅助的表单系统也基本满足客户的需
求，在这样的情况下实施的流程应用相对是快很多的。
但绝大多数实施的流程项目，单纯从按照客户的需求来完成流程运行和实施，有没有工作流引擎支持，其实并没有提高的太多。我记得2002年下半年的时候，给国家发改委实施了一个“提案信访”的流程，流程本身不是很复杂，如右图所示。当时我们已经有一个较为完善工作流系统了，但这个流程项目依然实施了半年多。主要原因是耗费了大量的开发精力在客户操作习惯、交互界面以及组织管理中的一些非常规权限方面。
可以说，一个单纯的工作流引擎，本身似乎并不能提高多少的流程项目实施效率。但是我们依然推崇使用工作流技术来解决流程性问题。这是因为工作流技术本身是基于“定义模型、解析模型、运行模型”原则，这就是说“流程是可被描述的”，一般我们会采用xml来描述流程定义。基于这个模型“定义——解析——运行”原则，则会带来两个最直接的益处：（1） 基于可被描述的模型，也就意味着流程定义是可被复制的。那么对于类似的流程就可以很容易被快速复制和扩展。
（2） 基于模型的解析运行，也就代表着可被有效的监控和管理，这是传统硬编码开发很难逾越的。
第三个问题：如果去获取一个工作流引擎或平台？
工作流项目实施的前提就是必须已经存在一个工作流平台或工作流引擎，基于这个引擎或平台实施项目：这个平台或引擎，不论是够买第三方的，还是自己研发的，抑或是扩展自开源的，但总归必须是有那么一个了。
如果某一个厂商，其有自己的工作流产品，那么这个问题似乎就没有存在可能性了。但是对国内大多数开发商来说，这是一个很头疼的问题。当这些开发商接到一个工作流项目的时候，摆在他们面前的最直接问题就是：怎么搞定这个基础的工作流系统或工作流引擎，是够买一个现有流程产品，还是基于开源引擎扩展，抑或是自主研发？
这三个选择似乎都很困难，因为现在国内的工作流应用蓬勃发展，工作流厂商也如雨后春笋般一个接着一个的冒出来了，而且其中不乏有很多是以提供Platform为主的；而开源引擎也越来越成熟和完善；而很多开上也着实希望能够用有自己知识产品的引擎，为以后项目实施解决成本。
下表就显示了一些代表性厂商和开源引擎：
平台厂商起步、浪潮楼上、炎黄盈动、普元、中创
工作流厂商西安协同、东兰、Joinwork、信亚达、华创动力、盛松
开源工作流引擎 jBpm、OSWorkflow、Shark
所以对开发商来说，选择什么样的方式，是首要问题，甚至有可能上升到战略性问题。在此，提供一些基本分析意见，供参考：
（1）如果仅仅只是实施一个或一些简单的流程应用，
这个简单的意思不是指流程的结构简单，而是指客户的操作
性简单，没有诸如“回退”“会签”“跳跃”之类的运转模型；
而且客户对流程图形化定义也没有什么要求，只要能保证流
程稳定运行，以及可进行简单的管理和监控操作即可。那么
这种情况下，应该首先考虑“基于开源引擎扩展”。这是因
为目前开源引擎基本上都比较成熟和稳定了，特别是jBpm，
自从其被JBoss收购之后，jBoss3是越来越完善（如右图所
示）。据我所知，目前国内很多开发商就是基于jBpm之上
进行扩展实施流程项目的，并且很多都已经成功应用。
（2）如果项目要求非常紧，而且客户对流程设计、流
程运行的要求也比较高。那么这种情况下，一般建议优先考虑商业应用产品，虽然采用商业产品必然会带来成本的增加，但是从满足客户的需求应用角度来讲，还是比较值的。但选择什么样的产品，这对很多厂商来说，也是较难于把握的。这一点我们随后再讲，先接下来看看什么情况适合自主研发。
（3）相信很多开发商都希望能拥有自己的工作流引擎或平台，因为对他们来说，首先是采用第三方的厂商产品会带来采购成本的增加，其次较为担心在流程项目实施过程中，因为客户需求的复杂或突然变更，而厂商产品接口有限或功能却恰巧不满足的情况下，则会带来非常麻烦的事情。
但自主研发只在如下情况比较合适：目前项目交付压力不是很大，有至少两至三人的研发团队，持续投入半年到一年，并且其中有对工作流系统结构模型等方面有较深理解，并有适当的实际引擎开发经验更好。从上面的条件可以看出来，这个要求是很高的，对国内大部分开发商来说，是很难提供这样的研发环境。
自主研发工作流引擎或系统，一般都需要半年到一年左右的研发期，还需要一两年左右的项目实施和完善期，才大约能够走向成熟。比较有代表性的开发商如下：公司工作流引擎名称研发启动时间引擎初版发布
北京用友软件工程 Nucleus 2004年初 2005年中
北京慧点科技 Galaxy 2003底或2004初2004年底或2005年初
在这里也顺便提个忠告，存在一些开发商的管理人员把工作流技术看的过于简单。当突然碰到有类似的项目的时候，以为找个开发人员，让其在开源引擎上去研究一段时间就可以应付复杂流程项目，这是大错特错的，而且大多都以失败告终。在我前面的参考方法中，第一句话就是——“仅仅只是实施一个或一些简单的流程应用”，才应该优先考虑开源引擎。
第四个问题：如果考虑第三方工作流产品，那么选择哪家产品更合适自己？
接下来，讲讲如何选择商业工作流引擎。
这两年国内工作流厂商是越来越成熟，产品的定位和分层也逐渐显现出来，比如西安协同的流程产品逐渐开始支持于基于ESB的分布式流程应用，而上海携创的Joinwork则依然定位在嵌入式工作流引擎。但是对于那些决定采用第三方工作流产品的开放商来说，如何选择一个最适合的产品，也依然是件非常困难的事情，毕竟国内大大小小的工作流产品有数十家：
在google上搜索“工作流产品”，大约会搜索出7840000条记录。下表列出一些较为常见的工作流厂商和产品（不包括一些平台性厂商，如起步、普元、炎黄盈动等）：神马EasyFlow、西安协同SynchroFLOW、上海携创的Joinwork、
信雅达SunFlow、东兰LiveFlow、中创InfoFlow、
有生博大RiseBPM、华创动力MatrixFlow、慧点Galaxy
东方易维Workflow、华苓AgentFlow、世纪金政Koof、盛松W-Flow、
东方通TongWorkFlow、维泰WiseFlow、超微SuperFlow、明基逐鹿eFlow
面对这么多的工作流厂商，开发商的选择主要困难在三个方面：
（1） 很多开发商只有在接到工作流项目的时候才匆忙考虑购买产品，但此时客户需求详细调研还尚未完成，其所面对的客户也很难提出清晰明确的流程应用需求。
所以开发商很难有个准确的衡量标准来评价什么产品最适合他们（2） 很多产品的功能表述的都很类似，产品演示也看似相近。功能似乎很多，但是到底哪些功能是真正需要的，而哪些产品是适合后续应用和扩展的，对开发商
来说是很难决断的。
（3） 开发商的心理担心和犹豫：毕竟购买的工作流产品，对他们来说，似乎就像一个“黑匣子”一样，很担心后期实施中，因为客户的需求不满足而又无法更改
产品，从而造成实施不下去的情况发生。
基于这几年工作流咨询和培训的经验，简单阐述一些选择的标准。主要是从如下几个角度进行选择：
（1） 首先搞清楚客户对流程设计器的要求或期望如何，是倾向于B/S的web设计器还是，还对C/S设计器也可接受。可能很多最终客户对这两者是用上的区别不
胜清楚，那么就需要开发商首先自己需要清楚这两者的区别，以及斟酌所定位
的客户的应用习惯和场景，那种操作凡是更适合客户使用。
（2） 其次，客户对流程的应用模型和操作习惯如何，诸如是否支持“串型”“并型分支”“条件分支”“同步异步子流程”“多种类型的执行人分配”“会签”“回退”
“取回”“跳跃（速称自由流）”等等，这些都是国内常用的基本流程应用需求。
相信这些功能很多产品也都宣称支持，但是具体支持的力度，却需要自己仔细
分析。举个例子：有些产品宣称支持回退，但是在项目实施的时候，却告诉开
发商在流程图上需要额外多绘制一条转移连接线来实现回退的操作。那么一旦
开发商所面对的客户要求能够实现“逐级回退”则变得非常棘手。
（3） 客户的流程变更性如何，如果客户提出了流程变更，那么如何维护流程的变更操作是开发商需要仔细考虑的。一方面以此来分析工作流产品如何支持流程变
更，一方面需要确定是否会存在客户自己进行流程定义更改的情况。毕竟一个
工作流系统实施后，最终的使用者还是客户，而客户的业务应用有可能会在后
续发展中发生变化的。
（4） 客户的应用系统中流程是否很多。存在有些工作流应用中，只实施几个流程而已，但也存在有的项目实施中，一个系统却包含几十个甚至上百个流程定义。
前一种情况如果产品提供商所提供的工作流系统完整性还不够的话，通过后续
开发商的实施尚且可以弥补；而后一种情况则要非常小心了，开发商必须选择
一个系统完整化和成熟度比较高的工作流产品。这样一类的工作流产品除了流
程设计器和引擎以外，还可能会包含：可扩展的组织模型、表单系统、工作列
表系统，甚至还有监控和管理部分。——但是系统复杂度越高，扩展复杂度也
越大，所以开发商必须在这个层面寻找一个适度的平衡。
（5） 就国内目前的绝大多数流程应用来说，流程监控应用性需求还不是很高。很多客户提出对流程监控的需求，也仅仅只是“觉得有这个必要”，但等到系统真正
上线后，使用流程监控功能的却很少的。但是，有这一类功能的工作流产品总
归比没有要强一些，但需要哪种深度的监控，那就需要开发商自己斟酌一下了。
这两年在给一些开发商咨询的过程中，碰到很多开发商希望工作流产品能够“assembling on demand”，就是能够按照需要的功能组装。因为很多开发商抱怨，他们用昂贵的价格选择了一个很好的工作流产品，但是却只使用了很少的功能；而那些价格较低的轻量型流程产品，却在有些功能上不能满足或细粒度不够，很难达到客户和二次开发的需求。事实上我也一直在期待国内能有这样架构的流程产品出现。
第五个问题：如何更加有效的进行流程系统实施
如果此时开发商已经有一个基础的工作流引擎或产品了，不论是采购第三方的，还是自
主研发的，那么接下来所面对的最大的一个问题就是如何更加有效的实施流程了。
很多工作流实施阶段本身其实没有太多的技术难度关口，最大的难度是在需求调研阶段的“流程梳理”。很多开发商在需求阶段都会反复抱怨“客户没有什么需求，或者客户让我们先做个demo再提需求”。
就目前国内流程应用情况来说，绝大多数客户都会直接把“流程需求”的问题直接推给开发商自己处理。这就需要开发商采取正确的策略和方式来一步步推进，而不能再像早期实施其它MIS系统似的采用“需求+静态页面Demo+数据库设计+开发”策略了。
对于很多客户来说，实施工作流系统一方面是响应“从有纸化转变为无纸化”号召，逐渐推进信息化应用；另一方面则希望通过“流程系统”有效的梳理出某些流程在办理过程中的真正处理过程。
在早期没有流程系统的时候，不论在政府办公还是企业管理，某些处理流程虽然有“规章制度约束”，但是在真正办理过程中，因为一些人为的因素，会存在一些变通的处理，从而会造成某些流程实际在审批过程中会“跳过”或“多出”一些环节。而且对一个管理人员来说，当其面对一个审批文件过来的时候，一般是很难非常清晰这个事情到底要经过哪些环节、哪些人的审批的。所以在现实操作过程中，很多情况是依据一些常规经验和个人判断处理。
那么流程信息化就要逐步帮助管理人员来逐步规范和梳理这些流程的处理步骤。这也是很多客户在流程信息化中的现阶段真实目标。开发商只有摸清客户对流程的真实目标期待，才能过采取有效的需求调研和实施方案，以及流程实施功能定位。
网络上不乏有一些所谓工作流实施介绍的文章，大体会告诉大家采用如下的步骤：建立项目管理办公室、业务分析、确定目标、确定实施计划、流程建模、软件集成······。这套步骤对于那些具有深厚的行业应用积累经验以及成熟的工作流实施经验的厂商是非常合适的，但是对于很多开发商来讲，却存在很大的误导性。
前面已经说过，对很多客户来说，其真正关心的是“梳理真实清晰的现实流程”。如果开发商能够通过与客户的不断沟通，逐渐帮助客户梳理现实操作中的流程处理过程，并用流程系统实现，则基本百分之九十的满足客户需求了。这个梳理过程不是一次两次就可以清晰搞定的，需要开发商在需求调研阶段不断的绘制流程图（最好就用流程设计器直观的绘制），每绘制一次就与客户进行沟通和演示，依据客户确认后提出意见再修改，再完善，再由客户确认。如此反复，才能正确帮助客户梳理出流程。
在梳理流程阶段，一定要把握几点：
（1） 一定不要抱怨客户提不出什么需求，这个必须自己去逐步挖掘需求。因为客户对流程系统和流程信息化所带来的办公操作和影响并没有预见性，这需要开发
商逐步帮助客户去理解，去应用。
（2） 一定要不断的找相关业务处理的负责人进行流程确认，找真实办理职员进行系统演示，因为只有这些人员才清楚现实流程的真实办理过程。
（3） 不要把需求调研和流程实施过分区分开，如果在需求调研过程中，就一步步地用流程设计器进行流程绘制，并给客户演示，则更容易让客户提出一些潜在的
流程需求，而不至于到了项目后期或上线试运行阶段，客户才大量的提出修改
需求来。
作者简介：
胡长城，网名“银狐999”。就职于TIBCO CDC，Infrastructure team
国内J2EE开源应用的支持者，有过六年的J2EE应用和产品开发及架构经验，huihoo
开源组织成员。
国内工作流应用的推广者，有过四年的工作流研发经验。利用个人主页和Blog共享了很多宝贵的工作流研究心得。尝试开拓了工作流培训方式，为企业工作流应用提供咨询和指导。
工作流系统需求分析 业务过程描述： 工作流是一种反映业务流程的计算机化的、实现经营过程集成与经营过程自动化而建立的可由工作流管理系统执行的业务模型。工作流起源于生产组织和办公自动化领域，其目的是将现有工作分解，按照一定的规则和过程来执行并监控，提高效率，降低成本。 下图是用户使用工作流系统的业务过程：
业务模型描述：
系统组成： 工作流管理系统由客户端、流程定制工具、流程监控与管理和工作流运行服务四个部分组成，下图是系统构件图： 系统功能划分： 工作流管理系统是指运行在一个或多个工作流引擎的软件上用于定义、实现和管理工作流运行的一套软件，从用户建模的过程来看在建立阶段功能主要是工作流过程和相关活动的定义和建模，在运行阶段包括运行流程的监控、管理以及执行过程中的人机交互等。 工作流管理系统由流程定制工具、流程监控与管理、工作流运行服务和客户端交互四个部分组成，整个系统的使用者可以分为四种：系统管理员、流程设计人员、流程管理人员、普通用户。 下图是整个工作流管理系统的顶层用例：
第一部分流程定制工具 本部分主要完成企业信息流中业务过程的图形化建模，定制工具提供丰富的图形化元素、简单易懂的建模方法以及完善的模型管理方式。 流程定制用例图：
打开流程模型 参与者：流程设计者。 前置条件：流程定制工具已经打开。 后置条件：被选择的流程模型中的内容被展开。 步骤序列： 1．打开流程模型列表或新建流程模型文件。 2．选择流程模型文件名称。 3．展开流程模型中的设计内容。 保存流程模型 参与者：流程设计者。 前置条件：某个流程模型已经被打开，并且被修改。 后置条件：修改过的流程模型存到了物理文件中。 步骤序列： 1．保存流程模型到物理文件中。 删除流程模型 参与者：流程设计者。 前置条件：拥有可被删除的流程模型。 后置条件：选中的流程模型被删除。 步骤序列： 1．用户打开流程模型列表。 2．用户选择想要删除的流程模型。 3．系统删除选中的流程模型。 导入导出流程模型 参与者：流程设计者。 前置条件：拥有可被导入的文件或导出的流程模型。 后置条件：流程模型被导出成文件或模型文件被导入到设计系统成为流程模型。 步骤序列： 1．用户打开可被导入文件列表或设计工具中的流程模型列表。 2．用户选择将被导入的流程文件或选择将被导出的流程模型。 3．系统把导入文件生成流程模型或把导出流程模型生成流程文件。 流程发布 参与者：流程设计者。 前置条件：拥有设计完成并可供发布的流程模型。 后置条件：流程模型被发布并可通过客户工具执行。 步骤序列： 1．用户打开流程模型列表。 2．用户选择发布的包或流程。 3．用户选择发布的运行服务器。 4．用户形成发布版本。
湖北XXXXXXXXX）产业集团 关于修订印发《工作流使用管理办法》的通知 各单位/部门： 为减少工作流使用不当的情况发生，从而提高工作流审批效率及企业信息化实施水平，我部门制定了《工作流使用管理办法》。根据该办法前期执行的实际情况，经征求各方面意见后，我部门对部分条款进行了修改和完善。现将修订后的《工作流使用管理办法》（见附件）印发，请各单位认真组织学习。 修订后的《工作流使用管理办法》自2012年8月20日实施，望各单位/部门遵照执行。 特此通知! 信息中心 二O—二年八月十九日
工作流使用管理办法 第一章总则 第一条为推进企业信息化建设的顺利实施，规范0A系统工作流的管理，明确公司工作流使用的要求，达到提高工作及管理效率的目的，特制定本办法。 第二条本办法适用于湖北XX建筑装饰工程有限公司（以下简称集团公司）及子公司所有员工。 第二章工作流的定义 第三条工作流：0A内置的流程子系统，可实现各类工作的申请、审批、会签、登记、查询等环节的管理，可将协同工作的过程进行记录，便于日后审核与查询；并实现业务数据的规范化录入、查询、统计和存档；0A的工作流系 统由表单和流程两个重要元素构成。 第四条表单：是与工作相关的数据的载体，相当于现实工作中的纸质工作单，工作单上的手写数据通过表单上的各类控件得以体现；除表单以外，我们还可以通过公共附件或会签区传递一些数据和信息，以便更好的完成工作流程。 第五条流程：是工作过程和环节的描述，流程由工作的多个步骤组成，每一步由指定的经办人填写指定的表单控件。 第三章工作流的发起 第六条为节约办公耗材，提高工作效率，实现信息化的有效推广，经集团公司审核通过的工作流禁止采用纸质操作。 第七条各员工需认真学习各工作流的作用及适用范围，在发起流程时，需选择与该工作相对应的工作流。 第八条对于明确指定了对应发起人的流程（IT类、盖章类、物业服务类等），当其他人员需要申请该工作流时，需和具有相应申请权限的人员进行对接， 委托该人员进行流程的申请。
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任务
流程业务需求 Prepared by 拟制方进 Date 日期 2013-10-16 Reviewed by 评审人Date 日期 Approved by 批准Date 日期
1工作流建设目标 为某某公司建立统一，集成的工作流系统平台，实现业务审批流程电子化。体现某某公司业务执行的透明度和规范化，提高业务处理效率和协作效率。 1.1管理需求 管理模式：通过实施工作流理顺业务流程，即销售业务审批流程，设计业务审批流程，行政管理审批流程等，提高业务协作效率，实现公司有效规范的管理目的 数据集成方面：工作流系统与业务系统集成，共享业务数据，实现单一创建多出引用原则 技术方面：要求系统在集成性，稳定性，拓展性，可适应性方面符合某某公司的发展需要。对于权限和安全性方面，提供可靠的保障。同时需要支持移动设备的审批。 组织和人员：通过工作流的建立帮助企业实现业务处理的完整性，实现业务和公司规范执行的有效结合。帮助企业梳理业务，规避风险，提升工作质量。 1.2技术要求 ◆流程设计工具实现流程定义，实现，人员，角色，部门定义。实现流程版本控制 ◆流程设计工具实现表单定义 ◆实现流程中不同的节点和不同的表单关联 ◆工作流节点支持脚本扩展,比如编写beanshell脚本,或其他语言的脚本 ◆实现表单中，一对多的主子表单的关联，比如在《担保支付运费服务协议》中除 了有正文合同，可能还有授权委托书a1，授权委托书a2，第三方代付费用，结算 方案确认合同等等。 ◆对于流程审批的人员管理如何设定 ◆审批委托设定，比如部门经理a出差，委托经理b待审批流程。 ◆手持设备访问工作流，进行审批动作 ◆流程中的某个节点长期没有审批，设置一个阀值，超过该阀值触发邮件动作提醒， 或终止流程等业务动作。 ◆工作流系统与其他业务系统集成方式
保密程度：仅限内部使用 v TradEx项目实施 实施方法论 Project Implementation Methodology 唯智信息技术有限公司 2003年10月
目录索引 1.概述 (2) 1.1.总原则 (2) 1.2.项目实施阶段工作目标定义 (2) 2.项目实施规范 (3) 2.1.团队确定（P ROJECT T EAM S ETUP） (3) 2.2.项目会议（M EETING） (4) 2.3.项目进度报告（S TATUS R EPORT） (4) 2.4.会议纪要（M EETING M INUTES） (5) 2.5.变更控制（M EETING M INUTES） (5) 2.6.报修控制（B UG R EPORT） (5) 2.7.APMS使用（C ONTROL Y OUR P ROJECT） (6) 2.8.三人制设计模式（T REBLE D ESIGN） (6)
成功的项目实施是一个复杂的工程问题，存在一定风险的；为了最大程度降低风险，唯智公司在长期的项目实践中总结出（逐步完善）一套能避免或把风险降为最低的方法：项目实施方法论。同时按照规范进行项目管理，能够保证不同能力的项目经理能够在面对客户的时候，提供同样的专业服务，能够提高客户满意程度。 各种类型的项目实施有其特点，都有自己的一套规范和文档模版。本规范中规定的各项内容和模版是所有项目都需要的共性问题。本规范是所有其他规范的基础，必须得到切实执行。 实施方法论保证了分析人员能够按照一种比较和的方法有条不紊的进行分析设计工作，同时留下足够的文档，帮助后期开发小组工作。但是必须注意，实施方法论无法取代分析设计人员对于客户业务的直观理解和创造性的思维。不动脑筋的进行文档填写工作是不能满足公司要求的。也会对于项目造成严重损害。 1.1. 总原则 ●项目尽可能采用迭代方式实施 ●尽可能引入客户参与项目的各个阶段，让客户项目小组的人员成为帮助项目成功的战 友，而不是站在相反方向，防止甲方利益受损的敌人 ●对于项目进行严格的过程控制 ●项目文档需要简明扼要，多使用表格，清单的方式，避免大段的描述性文档，各种会 议纪要，进度报告等过程性文档原则性不应该超过2-3页 1.2. 项目实施阶段工作目标定义
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.doczj.com/doc/de6952377.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.0 编写：年月日校对：年月日审核：年月日批准：年月日
目录 1引言 (1) 1.1编写目的 (1) 1.2背景 (1) 1.3定义 (1) 1.4参考资料 (2) 2任务概述 (2) 2.1目标 (2) 2.2用户特点 (2) 3需求详述 (3) 3.1关键信息 (3) 3.1.1名词解释 (3) 3.2过程描述 (5) 3.2.1系统管理 (5) 3.2.2流程设计 (8) 3.2.3业务管理 (14) 3.2.4用户操作 (23) 4说明 (26)
1引言 1.1编写目的 本需求规格说明书对系统所要实现的功能分模块进行了详细说明，它是一份描述系统整体结构及工作流程的文档。本需求规格说明书主要向客户方及与本项目相关的人员发放，使他们了解该软件的功能结构详细情况。 1.2背景 待开发系统是由631所提出的，针对该所的业务要求及外协任务说明。该系统包括四个子系统： 系统管理； 流程设计； 业务管理； 用户系统。 本系统由西北工业大学软件与微电子学院负责开发，系统的开发环境为：Windows＋J2EE。 1.3定义 WfMC（Workflow Management Coalition）：工作流管理联盟。 流程设计：创建工作流模型，根据实际的业务流程创建可视的流程模型。 业务管理：是对工作流模型和实例进行监控和管理。 活动：是一项工作的原子单元。有时会使用节点代替活动。 流程：是活动的集合，有时会使用工程代替流程。 角色：指工作流模型的参与者和任务承担者，和权限相关联。 用户：指工作流系统的使用者。 连接：是两个活动之间顺序依赖的根据，有时会使用边代替连接。 变量：是工作流的数据单元，被称做工作流相关数据。
版本一： 回退（Rollback WorkItem） 回退是工作流参与者对自己“待办任务”（实际是对工作项）的一种操作，即参与者主动回退待办任务列表中的任务到已经执行过的人工节点。 为什么要回退？ 参与者接受任务后，发现不应由自己办理此任务或以前的执行者办理有错误等情况后，需要将此接受的任务回退给以前某个节点的执行者重新办理。 回退模式 回退的情况实际上是非常复杂的，其中包括了参与者的重新选择以及回退的条件判断等等。这里先列出常见的回退模式（其实也是我们支持的模式）。 串行
这种情况最为简单，后续节点可以回退到前续任意人工节点。回退后，节点重走。 分支 这种情况也相对简单，实际执行的分支上的节点可以回退到前续任意人工节点（不区分主支和分支）。同样，主支上的节点也可以回退到任意实际执行的分支上的节点。 可能的问题：多次回退后的回退节点选择。例如：第一次流程经过节点2、节点3到达节点5，节点5可以回退到节点1、节点2和节点3的任意一个，此时节点5回退到节点1，节点1重走，这一次流程改为经过节点4到达节点5，节点5回退时如何选择回退节
点？此时的策略是以最近实际执行的分支为准，即节点5只允许回退到节点4和节点1，不允许回退到节点2和节点3。（抹去记忆） 并发 对于并发的情况，分支节点只允许在分支的节点间回退。
同理，主支节点也只允许在主支的节点间回退。多实例汇聚
在这种情况下，节点5会产生2个实例，实际相当于继续并发。节点5根据具体哪个节点触发的它而产生回退节点。同时不允许回退到节点1以及前续的节点去。 子流程 支持子流程到父流程的回退，也支持父流程到子流程节点的回退。 需要注意的是子流程节点有可能产生多个子流程实例，在这种情况下不支持父子流程之间的相互回退。 回退节点的参与者选择 默认策略是由原先节点的实际参与者重新处理，比如节点2回退到节点1，则节点1的实际参与者重新处理该节点任务。这也符合大多数实际的业务场景。
目录 一、概述 (2) 1.1 总则 (2) 二、项目实施规范 (3) 2.1 项目阶段划分 (3) 2.2 各阶段规范 (3) 2.2.1 项目启动（进场前） (3) 2.2.2 项目规划 (4) 2.2.3 项目执行 (5) 2.2.4 项目监控 (14) 2.2.5 项目验收 (17) 三、疑问汇编 (20) 3.1为什么说医院信息化是一把手工程？ (20) 3.2信息化能给医院带来哪些变化？ (20) 3.3客户更愿意用习惯解决问题，因此要求功能和以前相一致？ (20) 3.4客户要求个性化，认为公司的行为只是为了少改动程序，如何办？ (21) 3.5有没有必要对客户原有系统做一个全面的了解？ (21) 3.6医院信息科协调力度不够，项目计划不能正常执行？ (21)
项目实施方法论 任何软件项目的实施逻辑 [调研-规划-环境安装-基础数据维护-系统调试-培训-上线-验收] 一、概述 成功的项目实施是一个复杂的工程问题，存在一定风险的；为了最大程度降低风险，天网软件公司在长期的项目实践中总结出（逐步完善）一套能避免或把风险降为最低的方法：项目实施方法论。同时按照规范进行项目管理，能够保证不同能力的项目经理能够在面对客户的时候，提供同样的专业服务，能够提高客户满意程度。 各种类型的项目实施有其特点，都有自己的一套规范和文档模版。本规范中规定的各项内容和模版是所有项目都需要的共性问题。本规范是所有其他规范的基础，必须得到切实执行。 1.1总则 ●在公司及用户现场着装要商务装，不能穿运动鞋、拖鞋、背心等非商务装.●与人沟通要面带微笑. ●接到工作任务，有规划（项目经理完成）、计划. ●用户及公司领导关注或提出的问题要每天有邮件汇报或电话汇报进展.有问必答. ●勤总结,多分享.
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.doczj.com/doc/de6952377.html,/designer/update/ 输入完成后，单击OK按钮等待下载完成后安装。 安装完成后在菜单选项中会出现Activiti的目录选项
特别响、非常近——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系统背景 医院的运作过程本质上是人、财、物等资源的优化和配置，形式上无一不体现为信息流、资金流、物流、价值流等合理的流动；随着医院不同科室、部门分工的日益具体化，合作已成为主题，合作的体现形式必然是一个完整而高效的工作流程；有管理的医院的活动过程必然是有序的，这种有序性体现为合理的工作流程。因而工作流(workflow)无处不在。 2系统建设目标 1)隔离workflow系统的控制逻辑和医院业务系统的业务逻辑，使得业务逻辑 的变更对于控制逻辑透明。 2)利用该引擎开发的业务信息系统可以根据具体业务需求量身定制个性化的 业务流程，而不用修改控制逻辑，甚至无需修改源代码。 3)业务人员、开发人员、实施人员可以共同参与流程制定、流程、节点维护 4)提供灵活、丰富的标准开发接口，使得开发人员能采用自己习惯的开发工 具在该平台上定制和扩充模块。 5)采用多层分布式组件技术，力求技术先进性和应用的健壮性。 6)工作流自动化和医院应用积木化。 3工作流技术选型方案 3.1 技术选型目标 1)较好的流程定义工具。 2)工作流技术架构与业务系统之间解耦性较强。
3)工作流系统定位为嵌入式系统，并进行嵌入式部署。 4)业务人员、开发人员、部署实施人员均可参与对流程定义做可视化管理 5)业务人员、开发人员、部署实施人员均可参与流程走向做可视化管理。 6)可从容应对较常使用的工作流场景 7)架构开源程度——100% 8)开源社区活跃度较高 9)架构文档较为齐全 10)监控、管理功能支持 11)有较好其他工作流引擎整合方案 3.2 开源工作流选型 当前开源工作流种类繁多，现对目前国内较活跃的三种工作流（jBPM4,jBPM5,Activiti5）做简要介绍与分析，供参考： 3.2.1jBPM4 3.2.1.1架构简介 jBPM4 全称java Businuess Process Management 第四版(最后一个修订版本jBPM4.4发布于2010-07-19 ),是一种基于javaEE 的轻量级工作流管理软件包。jBPM 项目由Tom Baeyens 2002年发起，并与2004加入到JBoss组织，至今jBPM 发展至今有九年时间，在国内外均有大量的社区与商业支持。jBPM3、jBPM4拥有极度活跃的用户论坛和开发者论坛。
文件代码：
湖北XXXXXXXXXX产业集团 关于修订印发《工作流使用管理办法》的通知 各单位/部门： 为减少工作流使用不当的情况发生，从而提高工作流审批效率及企业信息化实施水平，我部门制定了《工作流使用管理办法》。根据该办法前期执行的实际情况，经征求各方面意见后，我部门对部分条款进行了修改和完善。现将修订后的《工作流使用管理办法》（见附件）印发，请各单位认真组织学习。 修订后的《工作流使用管理办法》自2012年8月20日实施，望各单位/部门遵照执行。 特此通知！ 信息中心 二〇一二年八月十九日
工作流使用管理办法 第一章总则 第一条为推进企业信息化建设的顺利实施，规范OA系统工作流的管理，明确公司工作流使用的要求，达到提高工作及管理效率的目的，特制定本办法。 第二条本办法适用于湖北XX建筑装饰工程有限公司（以下简称集团公司）及子公司所有员工。 第二章工作流的定义 第三条工作流： OA内置的流程子系统，可实现各类工作的申请、审批、会签、登记、查询等环节的管理，可将协同工作的过程进行记录，便于日后审核与查询；并实现业务数据的规范化录入、查询、统计和存档；OA的工作流系统由表单和流程两个重要元素构成。 第四条表单：是与工作相关的数据的载体，相当于现实工作中的纸质工作单，工作单上的手写数据通过表单上的各类控件得以体现；除表单以外，我们还可以通过公共附件或会签区传递一些数据和信息，以便更好的完成工作流程。 第五条流程：是工作过程和环节的描述，流程由工作的多个步骤组成，每一步由指定的经办人填写指定的表单控件。 第三章工作流的发起 第六条为节约办公耗材，提高工作效率，实现信息化的有效推广，经集团公司审核通过的工作流禁止采用纸质操作。 第七条各员工需认真学习各工作流的作用及适用范围，在发起流程时，需选择与该工作相对应的工作流。 第八条对于明确指定了对应发起人的流程（IT类、盖章类、物业服务类等），当其他人员需要申请该工作流时，需和具有相应申请权限的人员进行对接，
项目实施方法论-CAL-FENGHAI-(2020YEAR-YICAI)_JINGBIAN
项目实施方法论 未找到目录项。 前言 手册使用说明 ERP项目实施中有一个成功等式：企业ERP系统的成功应用=有准备的企业+合适的软件+成功实施，三个条件缺一不可。对于用友来说，客户企业的自身条件属于外部因素，用友无法控制，只能通过合同和建议书来约束双方的责任和义务，减少项目风险；合适的软件是成功应用的基础，用友需要做的是提供适合客户的成熟的产品；在前两个条件既定的情况下，项目能否成功，则取决于咨询实施顾问的实施能力。因此，为了保证项目实施的成功，必须对实施工作进行规范。2001年初用友公司发布了第一套项目用友法论，向规范化实施迈出了可喜的一步。通过广大咨询实施顾问1年多贯彻执行，增强了他们的项目管理意识和规范实施ERP项目的意识，用友法论深入人心。同时，咨询实施顾问也反映实施方法论有些方面过于抽象，缺少具体的工作内容、步骤等的解释，缺少可以借鉴的工具和模板。 为此我们根据用友实施方法论，综合借鉴一些参与过项目实施的项目经理和咨询实施顾问的实施经验和体会，对项目实施流程的各阶段、各项任务的工作内容、策略、角色和责任、交付成果、潜在风险逐一进行了介绍，并整理了一套工具、模板，力求流程清晰、简练实用。 编写这部《用友实施法指南》是我们的第一次尝试，每个人的工作经验毕竟有限，加上时间非常仓促，书中难免有不尽如人意的地方，我们诚心的希望广大顾问批评指正，以使我们这套《用友用友法指南》日臻完善，把它做成我们咨询实施顾问手头必备的工作指南，成为顾问的良师益友。
需要说明的是，本文的介绍只是用友ERP实施所使用的通用的流程和方法。并没有分行业的版本介绍。在具体的项目应用中，可以根据实际的情况进行调整。所使用的阶段、活动、任务以及提交成果可以适当裁剪或增加。 我们的建议：项目环境千变万化，咨询实施顾问，尤其是项目经理要根据实际情况随机应变，《指南》提供了一些解决问题的方法和建议，并不一定对所有客户都适用。希望大家利用《指南》，但不要被它所限制。 标准实施路线图
目录 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．打开流程模型列表或新建流程模型文件。 2．选择流程模型文件名称。 3．展开流程模型中的设计内容。 保存流程模型 参与者：流程设计者。 前置条件：某个流程模型已经被打开，并且被修改。 后置条件：修改过的流程模型存到了物理文件中。 步骤序列： 1．保存流程模型到物理文件中。 删除流程模型 参与者：流程设计者。 前置条件：拥有可被删除的流程模型。 后置条件：选中的流程模型被删除。 步骤序列： 1．用户打开流程模型列表。 2．用户选择想要删除的流程模型。 3．系统删除选中的流程模型。 导入导出流程模型 参与者：流程设计者。 前置条件：拥有可被导入的文件或导出的流程模型。 后置条件：流程模型被导出成文件或模型文件被导入到设计系统成为流程模型。 步骤序列： 1．用户打开可被导入文件列表或设计工具中的流程模型列表。 2．用户选择将被导入的流程文件或选择将被导出的流程模型。 3．系统把导入文件生成流程模型或把导出流程模型生成流程文件。 流程发布 参与者：流程设计者。 前置条件：拥有设计完成并可供发布的流程模型。 后置条件：流程模型被发布并可通过客户工具执行。 步骤序列： 1．用户打开流程模型列表。 2．用户选择发布的包或流程。 3．用户选择发布的运行服务器。 4．用户形成发布版本。
第 1 页 工作流需求说明书 1 前言 为构架完整EDM 产品，更好满足特定用户需求，需要进行项目管理和工作流管理模块的开发。 此需求计划由公司内部提出，在需求讨论和编写过程中，总结PDM 组在“863”项目中开发工作流原型的经验，吸收部分企业对工作流的需求意见，参照国内外同类产品的现有系统，确定了我公司开发的要求和目标。 此工作流需求说明书作为项目组内部开发指导文件。 1.1 目的 开发项目管理和工作流模块，所有的过程逻辑控制在工作流中实现，并通过项目管理进行任务分发、任务提交、过程跟踪等。工作流系统中的服务模块（如工作流引擎）基于DCOM 实现，作为组件提供给系统使用。 本文档的预期读者为项目组开发人员、质量保证人员、市场销售人员及公司领导层。 1.2 范围 实现的项目管理（ProjectManage ）和工作流管理（WorkflowManage ）作为CEDM 的两个模块，不单独包装为产品。 工作流管理实现WfMC 定义的基本功能：工作流引擎、图形化定义工具、工作流客户端、工作流管理平台。但实现的功能为WfMC 定义功能的子集，不考虑异构工作流系统间的交互，不考虑数据对象在工作流上的传递，不考虑工作流结点上脚本的实现。 项目管理以工作流管理为核心。项目加载工作流模板后，对任务进行描述，包括设定项目承担人、任务截止日期、任务优先级等，进行工作流的启动、流转、操作。项目管理不包括对设备等其他非人力资源的调度，不负责对项目进度排程的优化和组合。 1.3 定义、缩写词、略语 WfMC(Workflow Management Coalition)工作流管理委员会，有关工作流的国际标准化组织。
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