本文以一个工作流测试项目为例，总结了在测试过程中积累的经验，探讨了目前国内软件开发企业在软件测试过程中遇到的问题以及解决的方法。测试项目背景和实施情况工作流在某公司软件产品线中占有重要地位，XXX5.2 Workflow项目是5系列中的一个小版本，主要增加了任务代办、任务代理、以及任务交接等功能，同时还修复了一些易用性和功能性的Bug。下面，我们大概介绍一下这个项目的实施情况：
● 项目规模与测试人员配置：
○ 项目代码行数：5万行
○ 开发人员配置：开发人员5名、实习生1名
○ 测试人员配置：测试设计人员1名、测试执行人员2名、实习生1名
● 项目测试时的系统部署情况:
● 测试预期与测试执行情况整个测试项目是比较成功的，项目的时间执行情况和预期的测试指标度量都比较接近。发现Bug总数和缺陷密度都达到了要求的标准。当然，测试周期的实际值比计划值晚了两周，原?因是在系统测试后期，为了满足PSO部门提出的定时器需求造成了一定的延期。回顾整个项目的测试过程，我有几点小小的感悟，愿在此和大家一起分享。
测试如何尽早介入
基于以前的测试经验，我们也越来越认识到测试人员应该尽早介入项目的重要性。简单地沿用测试V模型往往出现很多问题，特别是在项目进度拖延的情况下更是如此。如果测试人员一味固执地被要求严格按照V模型定义的标准来开展测试工作的话，则结果往往是在项目初期测试人员工作量极度不饱和（很多测试人员无所事事），而到了项目后期，一旦项目经理决定压缩测试时间，测试人员就不得不加班加点地工作。但是，不少朋友实践“测试人员尽早介入”的效果并不理想，例如：
● 测试人员参加项目前期的各种会议，会被当作“专职的”会议记录员。
● 测试人员参加代码评审，又不甚了解程序开发语言，浪费了时间其丢失了自信。那么，在这个XXX5.2 Workflow项目中我们是怎么做的呢？实际上，在项目开发初期，测试人员可以开展很多有价值的工作，例如：
● 评审需求文档的正确性和可测试性；根据需求文档整理和分析测试需求，清晰明确的测试需求是测试设计的基础。
● 在开发设计过程中，根据需求文档和设计文档进行测试设计，测试设计方案是
测试用例的保证。
● 和项目团队中的集成组和开发组协?商软件版本的编译方式和编译进度以及
测试人员提取版本的方式和进度。
● 开发人员每天下午4：30之前提交所有可编译的代码，每天晚上进行日编译；
● 开发经理根据版本稳定情况，每周提交测试申请单。
● 测试人员根据测试进度需要，提取测试版本。
● 提前准备测试环境，包括数据库环境，操作系统和web应用服务器，以及复杂集群环境。
● 如果项目需要，还可以在此阶段研究一下自动测试工具，包括一些准备外包测试的工作。根据产品的成熟度调整测试策略开发测试一盘棋。测试经理应该有大局观，保持测试策略总与开发的进展相一致，保证最终的软件成果最佳（而不是测试部发现Bug数最多）。在这个XXX5.2 Workflow项目过程中，我们合理制定了不同阶段的测试策略，收到了很好的效果。
产品开发期同情的测试
要忍！要在这个能够发现大批Bug的黄金时段学会做减法。就现实而言，这个阶段的产品，大多难以满足系统测试的条件。如果进行穷兵黩武式的测试，无疑会加重开发人员的焦虑心情，甚至对测试产生逆反心理。另一方面，测试工作不应停滞，特别是不少测试人员对产品的了解还流于皮毛，抓紧时间进行“测试练兵”非常有必要。因此，“产品开发期”的测试切忌生硬。其实，此时程序人员也知道产品还不成熟，所以要告诉测试执行人员：
● 这个阶段不要提交界面简单错误和易用性方面的Bug（可以先记录下来到项目末期提交），否则会使开发人员质疑测试人员只会发现简单的Bug。
● 换位思考，了解此时开发人员最关心的是功能是否能正确运行，多对基本功能进行测试。
产品成熟期积极的测试
随着产品的不断成熟，主要功能的实现已经趋于完善，关键路径的测试已经不成问题。此时的程序员们，压力已经大大减轻，他们的工作重点也从“构建”转移到了“修复Bug”，这个阶段程序人员对于Bug的接受程度是最高的，对Bug
的修复和反馈也非常积极。于是，此时的测试工作应对整个产品的细节和所有路径进行覆盖测试，保证测试的全面性，层层深入地测试产品值得测试的各个部分，尽可能多的发现并报告Bug。
产品稳定期多样的测试
在这个阶段，可以尽情的向开发人员报告产品易用性和界面的Bug；可以充分发挥每个测试人员的想象力，根据以往的测试经验来搭建测试场景，构造测试数据；可以通过不同业务场景的不同操作，通过特殊的测试数据，以及相对复杂的集群测试环境来进行多样化测试。为什么？因为此时必须测试得更加深入，才能发现更深层次的Bug，于是多样性的测试、探索式的测试必不可少。
产品发布期谨慎的测试
在临近产品发布的日子，包括测试在那的很多工作都变得谨慎起来：代码的提交权限受到了控制，只保留开发经理一个入口；测试的重点更加具有防御性，要仔细测试每个变更，还可以组织“结对测试”来增加测试的保障。测试经理应知人善任为了保证测试工作的质量，首当其冲地就是应该有专业的测试团队。在很多小的软件项目中，往往没有专门的测试团队。这样一来，到了代码基本完成之时，就只能从客户支持部门或研发部门抽调一些人手临时拼凑出“测试团队”进行几周的测试工作，测试质量难以保证。我们则会尽早规划测试团队的人员结构，完善测试团队的配置。每个测试人员的特点和强项常常不尽相同，例如，擅长测试数据质量的测试员，未必能胜任系统环境配置复杂的测试任务。总之，对测试经经理而言，做到知人善任非常重要。同时，在项目测试过程中及时进行调整有时也很必要。此次测试的工作流系统，要求测试人员不仅应掌握一定的工作流业务知识，还需要有较强的逻辑思维能力。而在此项目测试过程中，笔者发现一位测试人员对功能的细节过分关注，而对整个工作流程总是理解不到位。显然，其设计出的测试用例不能适应工作流测试的要求。于是，立即进行人员分工和测试任务的调整，保证了测试工作顺利进行。坚持立场，规范流程我们公司有严格的测试流程，所有提交测试的软件版本，在提交之前，都要完成必需的冒烟测试（Smoking Test）。冒烟测试是一种测试包，其目标是检查版本的基本功能。这个测试包是由测试人员根据测试用例中级别为“基本”的测试用例抽取出来的，如果该版本没有通过冒烟测试，则就可以说明该版本不太稳定，不值得提交测试人员进行系统测试。有的公司冒烟测试是由测试人员手工或者自动测试。在我们这个项目中，为了保证每个可测试版本的冒烟测试质量，是由开发人员负责完成的。他们知道，如果程序不能通过冒烟测试，测试小组就会拒绝该版本。因此，他们会填写一份提交测试申请表来申请进行系统测试。在这份表格中，不仅会明确版本号，修改或新增的功能详细说明，还会给测试人员提供此版本的测试重点，以及可能会影响到的功能。这些内容对测试人员都是至关重要和大有裨益的。
在项目测试过程中，我们也出现过打回某个版本的情况，拒绝测试。总结起
来，基本上有以下几种情况：
● 由于任务查询的技术难度比较大，开发进度已经延期了5天，测试人员正在焦急的等待这部分的功能测试。可是，新提交的可测试版本中，这个功能根本就不能使用，如果进一步测试就是浪费时间，我们立即打回了这个测试版本。
● 新增了代办的功能，可是以往的代理功能中的增加代理人功能却不能正常使用，而增加代理人功能又是代办功能的基础，也就是说，在这个版本中，及时代办功能完全能够测试，可离开了增加代理人功能，代办测试是没有意义的。
● 在回归测试阶段，可测试版本的提交是比较频繁的。开发人员一旦解决了一部分bug就会提交一个可测试版本，如果此时测试人员并不急需更换版本，并且得知另一个版本会在几个小时之后就会完成，我们可以不测试这个版本。为了能更好的完成冒烟测试这个关键阶段，测试人员积极与开发人员配合：
● 负责提供冒烟测试案例。
● 如果测试人员处于版本等待阶段，主动和开发人员一起做冒烟测试。开展有效测试，提高测试效率有效的测试用例是软件测试成功的关键，有助于提高测试效率和测试覆盖率。在这个工作流软件测试项目中，我们从测试模型（Test Model）入手，结合丰富的测试经验和专业知识，从繁多的测试用例中挑选出有效的用例，用尽可能少的测试输入，覆盖尽可能多的软件需求。主要采用了状态机模型和组合模型，并结合了正交设计技术和组合覆盖技术，完成了对整个系统的测试设计。详细内容可以参考笔者在《程序员》杂志2007年第4期上的文章《基于模型的有效测试用例设计——工作流系统测试实战》一文。知己知彼，合力制胜提供服务使测试人员有机会赢得程序员的信任，同时也有机会展示自己的才能。同时，带来的回报是得到了开发人员对我们的帮助。在整个项目过程中，我们获得了很好的回报，比如：开发人员讲解设计思路、算法流程；和测试人员一起构造测试数据；积极参加每日测试例会，主动解决问题等。这样良好的合作状态与测试人员的主动努力是分不开的，主要体现在：
● 获取程序员信任，及时沟通不要与被测程序的开发人员形成不必要的敌对关系。如果能与打交道的程序员共享信息，比如他们的计划、设计文档的早期草案和早期原型等，测试工作会更加有效。越早与程序员接触，情况就越好。尽早提出你的意见和反馈，了解程序员提交前完成的工作。
● 主动出击，提供服务○ 在测试前期，直接向开发人员提供服务；这不仅可以建立信任，而且还可以证明测试人员是能够与之合作的人。我们在项目过程中提供给开发人员的服务：○ 对工作流的运算逻辑?构件进行了测试，方便了后期开
发工作流客户端应用的使用。○ 对内部版本和原?型进行测试。○ 对需求文档的可测试性进行评审。开发人员和测试人员一样，对模棱两可的要求很头疼，他们非常希望测试人员的介入。○ 帮助程序员建立测试环境，方便程序员进行测试。
● 耳目作用
○ 在项目过程中，测试人员有机会能够发现很多存在的问题，比如：需求和设计以及开发的不一致性，项目计划中工作任务的缺失等等。测试人员不要仅局限于测试命令链本身，及时验证和发现项目环节中的问题。总之，测试项目能否成功，与整个项目组的精诚合作是密不可分的。测试人员是一种服务角色，要乐于接受这种角色，只有这样，才能得到被服务的人的帮助和支持，以及认可。
全部脚印不留脚印留下脚印:
什么是工作流引擎，工作流引擎有什么作用，为什么需要工作流管理系统，在这里我们主要研究它的好处，你想要理解它的好处，就得知道不使用它会带来什么样的坏处。 现在我们来讲工作流，什么是工作流？所谓的工作流就是通常所说的业务流程，那么所谓的业务流程换句话来讲就是多个人在一起去完成一件事情。这就可以称之为工作流。流程的本质就是一个参与者参与到一个过程里面来 那么现在我们就想为什么需要工作流管理系统，工作流管理系统能给我们带来什么好处。我们就从这个角度出发来了解JBPM 工作流引擎 下面我们就来看关于为什么需要工作流管理系统，以及它给我们带来的好处。 实际上它带来的好处就是使某些容易变化的东西抽象出去，我们能够通过某种方式改变它，然后你就可以对你的某些核心部分不需要做什么变动 现在就通过一个小例子来讲这个工作流引擎到底是一个什么东西 举个请假流程的例子 一个请假的过程 重点讲解UML 里面的内容，确定UML 里面流程图的讲解顺序 请假流程 现在只看左边的内容，右边的后面再讲，我是方便讲解就将这点东西放到这个空白的地方 一个简单的流程图Main 模拟出请假的过程
对提交请假单进行分析 用一个用户来表示普通用户和审批者，只不过他们的权限不同，他们都能够登录到这个系统 现在我们来看用户和请假单，分析他们之间的关系，用户和请假单之间的联系有请假，用户填了一个请假单就创建了一个请假单对象，他们之该是一对多的关系。因为某一个用户可以请多次假 对吧（其实一般是一个请假单对应一个请假者，这个需求就应该得到客户的确定，客户说了算）那么用户和这个请假单之间还有没有其他联系？ 接下来是提交请假单。我首先将请假单提交给张三，那么张三就能够看到这个请假单，如果用户将请假单提交给张三，那么就可以在张三和请假单之间建立一个待审关系 他们之间的关系也是一对多的关系，因为张三可以同时审核几个请假单，就是这意思，一个请假单等待的用户是一个，从现在的需求来看。那么两者之间还有另外一个联系那就是已审，一个用户可以审批过多个请假单，请假单也可以被多个用户审批 比如张三审批以后交给李四审批，李四审批以后交给王五审批，其实这个已审就是记录审批信息的，比如审批时间，审批意见，把它放在审批关联里边 这个就是一个基本的概念，了解这个概念之后我们就考虑它的设计，JBPM 实际上就是协助我们把这个请假单从一个用户手上转递到另一个用户手上。当把这个模型分析清楚了我们就要去实现它。 这里重点分析提交，怎样去提交，在SSH 架构体下，提交请假单这个业务逻辑，你可能就需要这样一个业务逻辑类，里边可能有这么一个方法专门来进行提交操作的，那么这个方法怎样设计，以及这个方法怎样去实现。了解这点你就可以了解JBPM 干什么的，能给我们带来什么好处 (用自己的话说明一下提交请假单的过程 <读一下那段伪代码>) 在这个过程里边写这些代码是比较麻烦的，现在还只是一个固定的流程，假设我现在在这里边变化一下 那么整个方案都要变动。 我现在希望有一个会签的功能 比如我现在要将这个这样的功能，把这个请假单同时提交给多个审批者审批。 那这个时候你就不能够在请假单中间增加一个外键， 把它整成审批者什么的，
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/9217317445.html,/designer/update/ 输入完成后，单击OK按钮等待下载完成后安装。 安装完成后在菜单选项中会出现Activiti的目录选项
2009，45（13）工作流控制模型（Petri 网） 抽象化 工作流模型 工作流定义语言 工作流元语言 工作流概念模型 表示形式化 基于 基于 图1三层模型间的关系 1引言随着软件在信息社会中发挥日益重要的作用，人们对软件 的正确性、可靠性、安全性等可信性质给予了越来越多的关注。如何在软件的开发和运行过程中保证软件具有可信性质也成为软件理论和技术越来越重要的研究方向。自从20世纪90年代，工作流管理系统的研究与应用得到了长足的发展，实践证明它在改进和优化业务过程，提高业务工作效率，实现更好的业务过程控制，提高顾客服务质量，提高业务过程的柔性等方面起到了重要作用。 工作流管理系统中的两个核心组件分别是流程定义组件与流程执行组件。而现有的工作流系统或多或少都存在着一些缺憾：（1）模型描述能力有限；（2）难以快速适应多变的市场需求；（3）定义的流程和实际系统之间的正确性差异。为保证流程设计的正确与可靠，应该对所设计的流程分别进行静态的分析验证和动态的仿真测试。 通过研究与分析，一个完整的工作流模型应该分为三个层次：元模型层、模型层和控制模型层。其中元模型层给出了流程定义的主要成分及其语言描述。扩展的信牌驱动模型属于模型 层，它对经典Petri 网进行了改进与扩充，基本解决了经典Petri 网描述业务过程的局限性。只保留了控制机制的Petri 网模型 是对工作流流程定义语言的更高级别的抽象，因此属于控制模型层。三层模型之间的关系如图1所示。 因此关于流程的分析验证也可以分为三个层次进行：基于元模型层次上的语法验证、基于模型层次上的语义验证（仿真） 和基于控制模型层次上形式化分析。又可以将它们分为静态检查与动态仿真，其中静态检查主要针对的是流程的静态定义，包括基于元模型层次上的语法验证和基于控制模型层次上的形式化分析；而动态仿真主要针对流程的动态执行过程即基于 工作流流程动态仿真技术的研究 付丽娜，郝克刚FU Li-na ，HAO Ke-gang 西北大学软件工程研究所，西安710069 Software Engineering Institute ， Northwest University ，Xi ’an 710069，China E-mail ：fulina_97@https://www.doczj.com/doc/9217317445.html, FU Li-na ，HAO Ke-gang.Research on dynamic simulation of workflow https://www.doczj.com/doc/9217317445.html,puter Engineering and Applications ， 2009，45（13）：29-33.Abstract ：The mode to capability analysis and correctness verification of workflow process is divided in static inspection and dy － namic simulation.Especially the paper studies several key problems in process simulation ，setting up simulation enviroment ，the al －gorithm for arranging events in a queue based on path coverage rule ，analyzing simulation results.It adopts interactive and non-interactive means ， employs white-box and black-box methods to test workflow process based on high coverage rate.And at last it gives expression to type ，distribution and trend of process defects. Key words ：Workflow Management System （WFMS ）；token-driven workflow computation model ；process ；simulation engine ；event ；verification 摘要：对于工作流流程的能力分析以及正确性验证，其方式上可分为静态分析与动态仿真。论文侧重研究通过动态仿真手段对 流程进行测试与分析，验证流程在合适的时间，由合适的资源做合适的事。针对仿真过程中的几个关键问题———设置仿真环境、基于路径覆盖准则的事件排队算法及仿真结果的统计分析做了较深入研究。仿真采用了交互式与非交互式两种手段，利用白盒与黑盒两种测试方法对被测流程进行高覆盖度仿真，并通过仿真结果反映缺陷的类型、分布与走势。关键词：工作流管理系统；信牌驱动模型；流程；仿真引擎；事件；验证 DOI ：10.3778/j.issn.1002-8331.2009.13.009文章编号：1002－8331（2009）13-0029-05文献标识码：A 中图分类号：TP311 基金项目：国家高技术研究发展计划（863）（the National High-Tech Research and Development Plan of China under Grant No.2007AA010305）。作者简介：付丽娜（1979-），女，博士研究生，研究方向为软件理论、工作流相关技术等；郝克刚（1936-），男，博士生导师，目前研究方向为工作流技 术、分布式计算和软件理论等。 收稿日期：2009-01-21 修回日期：2009-02-25 Computer Engineering and Applications 计算机工程与应用29
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任务
Toward Workflow Block Activity Patterns for Reuse in Workflow Design Lucinéia Heloisa Thom and Cirano Iochpe Federal University of Rio Grande do Sul, Brazil; Vinícius Amaral and Daniel Viero, iProcess, Brazil 1.I NTRODUCTION Research on both business process modeling and implementation issues re-lated to workflow technology have quickly increased over the last years. The most significant initiatives are in the field of standardization [1], [2], [4], specification [5] and workflow definition languages [6], [7], [3]. However, since it is a relatively new and still evolving technology, workflow design pre-sents some challenges, especially with respect to techniques that can en-force correctness as well as efficiency during both the requirements analysis and the modeling phase of the workflow project. Within this context, research on workflow patterns has attracted increasing attention mainly because of the advantages of reusing patterns [8], [9]. The most extensively studied are in the field of control/data flow patterns [10], [11] as well as resource and application–oriented patterns (12). Such pat-terns are being used not only in business/workflow process modeling but also in critical evaluations of workflow languages and workflow tools (13). However, a lot less research can be found relating workflow design to a set of recurrent business process “pieces” or “parts” that must be atomically exe-cuted by the workflow process (e.g., an activity request execution and a noti-fication activity). Although one can precisely characterize the semantics of such business process “pieces” [14], [15], [16] and they have to be recur-rently re-designed in practically every workflow modeling process, there is no known research relating these business process structures to workflow pat-terns. 1.1 Approach Our approach applies the concept of block activity to well-known business processes. An activity set is a self-contained set of activities and transitions [7]. Transitions in the set should refer only to activities in the same set and there should be no transitions into or out of the set. Activity sets can be modeled as block activities. The block execution starts at the first activity in the set and executes the next activities by following the partial order im-posed upon them by the transitions until an exit activity is reached. Work-flow execution then returns to the next activity following the block. In this paper, we apply the block activity concept in order to represent a set of business (sub-)process types (e.g., logistic, financial, information and de-cision) that we call “workflow block activity patterns”. These patterns are re-lated to a set of specific atomic structures that are frequently found in busi-ness processes and have already been identified in the literature [14], [15],
基于工作流引擎的系统框架设计开发 ——工作流引擎子系统 摘要 工作流就是一系列相互衔接、自动进行的业务活动或任务。工作流引擎是工作流管理系统的核心，它的主要功能是通过计算机技术的支持去定义、执行和管理工作流，协调工作流执行过程中工作之间以及群体成员之间的信息交互。 论文主要讲述了工作流引擎的基本功能及设计方法，介绍工作流引擎的基本原理，具体分析了工作流引擎所包含的内容，详细介绍了相关的信息模型和控制模型。系统采用关系结构的理念来设计工作流引擎，给出了用Microsoft Visual Studio 2005和Microsoft SQL Server2000实现系统的方法。论文中利用本工作流引擎构建系统能适应大多数业务流程的扭转，大大缩短常见信息系统的项目开发周期，提高效率。 关键词：工作流引擎；关键业务；关系
The design of information system frame based on workflow engine ---- The subsystem of workflow engine Abstract Workflow is a series of interlocking, automatic business activities or tasks. Workflow engine is the work flow management system in the core, and its main function is to define, implement and manage work flow through the support of computer technology as well as co-ordinate work flow process of working implementation and groups of information between members of interaction. The thesis has mainly described basic functions and design of the workflow engine, introduced the basic theories, and specifically analyzed the content included in the work flow and the details of the relevant information model and control model. The idea of relation structure has been used to design this system and the method to achieve the system function with Microsoft Visual Studio 2005 and Microsoft SQL Server2000 has been given out. Constructing system with the workflow engine can adapt to the majority of the business process reversing that significantly reduce the development cycle of the common information system and improve efficiency. Key words：Workflow engine; Critical business; Relationship
Activiti工作流使用说明文档 V1.0 2019年8月9日
目录 一、模型设计器 (4) 1.1任务 (5) 1.1.1 用户任务 (5) 1.1.2 服务任务 (5) 1.1.3 脚本任务 (6) 1.1.4 业务规则任务 (7) 1.1.5 接收任务 (7) 1.1.6 手动任务 (7) 1.1.7 邮件任务 (8) 1.1.8 Camel任务 (8) 1.1.9 Mule任务 (8) 1.1.10 决策任务 (9) 1.2构造 (10) 1.2.1 子流程 (10) 1.2.2 事件子流程 (11) 1.3泳道列表 (11) 1.4分支 (12) 1.4.1 排他分支 (12) 1.4.2 并行分支 (12) 1.4.3 包容分支 (13) 1.4.4 事件分支 (13) 1.5事件 (14) 1.5.1 定时器事件 (14) 1.5.2 信号事件 (14) 1.5.3 消息事件 (16) 1.5.4 错误事件 (16) 1.5.5 边界事件 (17) 1.5.6 中间事件 (18)
1.5.7 开始事件 (18) 1.5.8 结束事件 (18) 1.6属性元素 (18) 1.6.1 异步 (18) 1.6.2 排他 (19) 1.6.3 补偿 (19) 1.6.4 中断任务 (20) 1.6.5 分配 (21) 1.6.6 到期时间 (22) 1.6.7 表单 (22) 1.6.8 表达式 (24) 1.6.9 多实例 (25) 1.7监听器配置 (28) 1.7.1 执行监听器 (29) 1.7.2 任务监听器 (30) 1.7.3 事件监听器 (32) 1.7.4 全局事件监听器 (33) 二、workflow-service (34) 2.1数据更新逻辑 (34) 2.2方法表达式配置 (35) 2.3自定义外置表单 (36) 2.4事件监听器配置 (37) 2.5方法调用说明 (37) 三、常见问题 (37)
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/9217317445.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概述3 1.1工作流现状 (3) 1.2建设原则 (3) 1.3建设目标 (3) 1 (4) 2总体设计方案4 2 (4) 2.1业务架构设计 (4) 2.1.1业务功能设计 4 2.1.2业务模型设计 5 2.2总体架构设计 (6) 2.2.1工作流总体结构图 6 2.3技术架构设计 (7) 2.3.1展现层 7 2.3.2控制层 7 2.3.3业务逻辑层 7 2.3.4数据持久层 8 2.3.5缓存 8 3应用系统设计8 3 (8) 3.1流程定义 (8) 3.2流程管理和监控 (8) 3.3工作流引擎 (8) 3.4工作项列表 (9) 1 (9) 1.1 (9) 1.2 (9) 1.3 (9) 1 (9) 1.1 (9) 1.2 (9) 1.3 (9)
1概述 1.1工作流现状 工作流是实现企业业务过程建模、业务过程仿真、业务过程管理与集成，从而实现最终业务过程自动化化的核心技术。 传统的工作流管理系统缺乏柔性，不能及时响应变化和相互之间缺乏互操作的缺点不能满足这种复杂业务流程管理的需要。针对这种情况，提出工作流管理平台的实现方案，以便更好地对企业业务流程实行管理。 1.2建设原则 工作流管理平台的设计主要遵循实用性、稳定性、高效性、灵活性等原则： （1）稳定性原则：需要采用成熟的技术模型、稳定的软硬件产品、软件开发平台和工具。 （2）安全性原则：提供完整备份机制，提供安全的数据访问机制。 （3）友好性原则：考虑到平台将针对各个层面的用户群体，使用者的计算机水平参差不齐，所以需求平台提供的界面简便友好、操作方便。 （4）扩展性原则：系统设计应具有良好的可扩展性和升级能力，可以根据新的业务拓展，方便地追加新的模块，也可以根据运营的状况，自由地追加硬件，以实现对系统有效的负载均衡。 （5）快速开发原则：提供封装的开发构件，提供基本的系统管理模块，提供简洁的开发模板，能够满足各类业务需求的快速开发。 1.3建设目标 根据上述原则，工作流管理平台建设的主要建设目标为： （1）实现基于Jbpm的流程引擎的二次开发。 （2）实现图形化的流程定义工具和流程管理监控工具。 （3）实现工作项列表（包括待办事宜、已办事宜、历史事宜）的统一管理界面。 （4）实现在流程生命周期中应用系统对流程触发的动作的相关服务接口：工作流定义相关服务、工作流引擎相关服务、工作项列表相关服
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
AO流程引擎总体设计方案 一、名词。 流程表：每设置一个新的流程时，都会设置流程相关的字段信息。设置后生成一张流程表。每按此流程进行一个办事流程时即是此表的一条记录（实例）。 流转单：即处理流程中的各个环节，如科员填表申报环节、科长审批环节等。每个流转单所需要的字段是从流程表中选出的字段。每个流转单实例即是根据选择的字段从流程表的实例记录中进行显示或操作。 二、流程设置 2.1 流程表设置 在设置流程时，根据其下流转单的情况设置好所要的所有字段信息。设置好后生成一张数据库表。并把流程名称，流程表名等信息记录到一个流程记录表里（这张表只用来记录流程表及流程对应的流程表名）。默认存在的字段应该有：流程实例名（如：2011年3月消防器材发放管理工作），流程状态，父流程表名，父流程实例id,父流程关联流转单编号，开始时间，结束时间等。 2.2流转单设置。 2.2.1流转单基础信息设置。 设置流转单名称，即流程在此环节时的名称（如科长审批）； 设置流转单编号，编号应该是唯一性的； 设置流转单类型：一般流转单或子流程流转单或起始流转单； 2.2.2选择表单字段。 字段从流程表中字段进行选择。选择每个字段后， 要设置此字段的配置属性：是否只读、是否隐藏； 要设置此字段的验证属性：是否必填、验证方法（email验证、长度验证等）； 要设置此字段对应的控件：HTML控件：文本框、文本域、密码框、下拉框、多选框、单选框、上传框。及对应的默认数据和备选数据。动态控件：如部门下拉框等。及对应默认数据。 要设置此字段的控件样式：高宽等。 根据字段的名称流程表名等信息对此字段设置一个字符串标识。 在设置字段过程中如果觉得字段不够，应该有操作可以再添加流程表字段。 2.2.3设置流转单显示模板。
根据activiti官方提供的编写 1.财务部门填写月财务报告 2.股东审核月财务审计报告 流程图： 流程配置： <;?xml version=";1.0"; encoding=";UTF-8";?>; <;definitions xmlns=";https://www.doczj.com/doc/9217317445.html,/spec/BPMN/20100524/MODEL"; xmlns:xsi=";https://www.doczj.com/doc/9217317445.html,/2001/XMLSchema-instance"; xmlns:activiti=";https://www.doczj.com/doc/9217317445.html,/bpmn"; xmlns:bpmndi=";https://www.doczj.com/doc/9217317445.html,/spec/BPMN/20100524/DI"; xmlns:omgdc=";https://www.doczj.com/doc/9217317445.html,/spec/DD/20100524/DC"; xmlns:omgdi=";https://www.doczj.com/doc/9217317445.html,/spec/DD/20100524/DI"; typeLanguage=";https://www.doczj.com/doc/9217317445.html,/2001/XMLSchema"; expressionLanguage=";https://www.doczj.com/doc/9217317445.html,/1999/XPath"; targetNamespace=";https://www.doczj.com/doc/9217317445.html,/bpmn20";>; <;process id=";financialReport"; name=";Monthly financial report reminder process";>; <;startEvent id=";startevent1"; name=";月财务报告审核开始";>;<;/startEvent>; <;!-- 采用用户组为accountancy编写财务报告 -->; <;userTask id=";usertask1"; name=";财务编写月财务报告"; activiti:candidateGroups=";accountancy";>;<;/userTask>; <;userTask id=";usertask2"; name=";股东审核月财务审计报告"; activiti:candidateGroups=";management";>;<;/userTask>; <;endEvent id=";endevent1"; name=";月财务报告审核结束";>;<;/endEvent>; <;sequenceFlow id=";flow1"; name=";"; sourceRef=";startevent1"; targetRef=";usertask1";>;<;/sequenceFlow>; <;sequenceFlow id=";flow2"; name=";"; sourceRef=";usertask1"; targetRef=";usertask2";>;<;/sequenceFlow>; <;sequenceFlow id=";flow3"; name=";"; sourceRef=";usertask2"; targetRef=";endevent1";>;<;/sequenceFlow>; <;/process>; <;bpmndi:BPMNDiagram id=";BPMNDiagram_financialReport";>; <;bpmndi:BPMNPlane bpmnElement=";financialReport"; id=";BPMNPlane_financialReport";>; <;bpmndi:BPMNShape bpmnElement=";startevent1"; id=";BPMNShape_startevent1";>; <;omgdc:Bounds height=";35"; width=";35"; x=";30"; y=";200";>;<;/omgdc:Bounds>; <;/bpmndi:BPMNShape>; <;bpmndi:BPMNShape bpmnElement=";usertask1"; id=";BPMNShape_usertask1";>;