目录开场白 (2)工作流技术调研： (2)工作流的概念 (2)工作流相关术语 (2)工作流系统功能概述 (3)工作流运行的模式列举 (5)业内工作流产品调研 (6)Mocha BPM产品 (6)中软工作流产品调研 (7)天翔myApps工作流产品调研 (8)我们的需求分析 (10)系统模块划分 (11)工单系统的功能性需求列表 (11)需求变更总结 (14)设计方案 (16)数据库设计 (16)关于hibernate实现持久层和session的管理 (18)自定义表单的设计 (19)自定义流程的设计 (20)消息模块的设计 (22)后记 (23)开场白我告诉自己要有专业精神，可是。
我真的好业余。
以前我不知道，我到底适不适合学计算机，如今我有了答案，以前我不知道我能在这个行业取得多大的成就，如今我仍然没有答案，只是当我有一天我发觉枪毙一个毫无常理可言的可以称为意识流的bug 的时候，我觉得这种感觉仿佛是自己成为了侦探小说里的主角一般，故事的结局是聪明才智让迷离的云雾消散，那一刹那的欢喜就像是一个你坚持了很久的英雄梦想霎那间以一种最满意的方式开出花来。
也许很少有人能理解这宗近乎疯狂的感觉，而对于一个每天对着计算机将近9个小时的IT者来说，我的确需要这样的近乎自恋的情感变化或者说异样的愉悦体验。
情也抒了，于是该变身回一个真正的IT者，紧以此贴记录在过去的半年里我所从事的高尚职业，如果你要问我我从事的什么高尚职业，它为何高尚，那我会告诉你原因就是我装逼，自恋，而又认为有体会到了一些与众不同的感觉。
首先自量底牌，我只是一个普通的大四学生，通过自己的努力保研成功，大四之后经常浪迹在javaEye中，此贴可称为处女贴。
本贴的意义在于自我终结，顺便带着抛砖引入的使命，再顺便让我打破万事开头难的俗套，一边督促自己常常自我总结，自我提高。
关键词：工作流jbpm 动态流程可定制表单。
本文就以我在过去三个月开发的一个完整流程系统为背景，总结在我知识所及范围里的工作流系统开发经验，贻笑大方想来是不可避免的，还望各位牛人指正，俺只是一个放低了姿态的学生。
工作流技术调研：工作流的概念●工作流是一类能够完全或部分自动执行的经营过程，它根据一列过程规则，文档、信息或任务能够在不同的执行者之间进行传递与执行(WfMC)●工作流管理系统是一个软件系统，它完成工作流的定义和管理，并按照在计算机中预先定义好的工作流逻辑推进工作流实例的执行(WfMC)●工作流起源于办公自动化领域，我们可以把工作流系统比作生产流水线，不同的部门和加色根据权限的划分执行相应的任务。
工作流相关术语●Activity定义：在一个进程中，形成一个逻辑步骤的一次工作。
包括manual activity和automatedactivity用法：一个进程可以由多个对整个商业进程的可行性有帮助的有逻辑顺序关系的activity组成；每个activity一般都是流程引擎的最小工作单元●Process Instance定义:一个单独制订的进程的表现用法:由工作流管理系统管理或创建每个进程实例表现了一个单独制定的实例,使用它自己的进程实例数据,并可独立控制或检查完成或终止●Participant定义:它是一个资源,执行由一个工作流活动实例表达的工作.这个工作一般都是指定到工作流参与者的一个或多个工作条目用法:通常是指人力资源,但不能简单概念的包括智能代理(intelligent agent)之类的机器资源，一个工作流参与者可以在商业进程中直接定义,或者由组织或角色实体定义●Task定义:在一个进程实例中的一次活动的一次工作用法:一个活动代表性的都产生一个或多个工作条目,这些工作条目组成了用户着手的任务工作流系统功能概述●流程定制工具提供了一个流程建模的可视化开发环境，让用户能够使用图形化拖拽的方式，方便、直观、有效地设计、修改和维护企业业务流程，并且所见即所得，极大地提高了易用性（如下图）●管理监控工具提供可视化的平台查看流程历史，对流程任务进行查询等工作。
（如下图）●工作流客户端与应用我们工作流提供了一个客户端的应用，提供了用户任务列表、签收任务、完成任务等等，但是在具体的项目中，可以根据用户的需求需要重新做一个应用，核心接口已经提供了，只需做一个用户需要的展现形式●工作流引擎引擎支持多种流程运行模式，运行时对流程和活动进行有效管理，根据流程向参与者分配任务，并对管理和监控功能提供有效支持。
引擎通过接口与工作流工具、外部应用和第三方工作流引擎进行交互，向系统提供工作流执行服务。
（如开源的jbpm流程引擎）工作流运行的模式列举●顺序（Sequence ）-- 顺序执行任务;；●并行分叉（Parallel Split）-- 并行执行任务；●同步（Synchronization）-- 同步两个并行执行的线程；●排它选择（Exclusive Choice）-- 从多个路径种选择一个执行；●简单合并（Simple Merge）-- 合并两个可选执行路径●任意循环（Arbitrary Cycles）-- 执行工作流图时无任何环路限制；●绝对终止（Implicit Termination）-- 若无事可做时则终止。
给出一个简单的流程建模图：业内工作流产品调研Mocha BPM产品（注：以下信息基于mocha bpm产品白皮书整理）➢Mocha bpm产品特点介绍：●提供了业务流程设计、运行、维护和优化的工具，同时将提供应用引擎的方式来支撑企业核心业务应用系统，灵活地与业务系统的应用集成，实现业务流程管理系统的自动化。
●全面整合业务流程，摩卡BPM 以其强大的工作流引擎为依托，依靠完备的数据交换平台，完全按照业务流程本身的流转规则，并以全程的自动化方式，实现跨机构、跨业务、跨部门、跨应用的流程整合。
●完整的生命周期管理建模：由业务人员完全以业务视角，使用流程图来描述一个业务流程，即配即用的动态定制自动化：定义好的流程，在BPM 系统中自动执行，完全废弃传统的纸张，流程的传递无需人工干预。
搜索：BPM 中的流程和数据呈指数增加，系统能对流程状态、运行情况等数据信息进行索引和监控，实现快速查找。
管理：能够可视化地监控流程的执行情况，对流程执行中出现的意外进行处理。
开发：简化工作中的流程步骤，满足随时变化的业务需求，降低了二次开发的难度，提高开发的效率。
整合：BPM 不仅仅是由人来参与，通过整合Mocha BPM Integration，部分活动也可以由IT 系统来参与，达到自动化的目的。
Mocha BPM 通过对组织内外的流程管理，提高了组织的客户满意度，提升了组织的竞争能力，加强了组织的适应变化能力，使组织在竞争之中始终具有领先的优势。
Mocha BPM 帮助企业，让流程成为一个企业的竞争优势。
它是经过多年的项目经验积累不断完善的成熟的BPM产品。
中软工作流产品调研功能列表：●监控管理监控流程状态管理流程运行查看流转历史提供考核依据●流程定制图形化定制符合行业规范独立运行修改便捷●组织结构图形化定制符合行业规范独立运行修改便捷●任务管理查询任务办理任务委托任务分派任务发起会签天翔myApps工作流产品调研主要关注点：（流程自定义，表单自定义，任务自定义）流程定义：拖拽方式的流程定义节点上任务自定义：表单自定义：通过三部自定义过程，该工作流软件可以实现业务无关的流程建模方式。
作为一个初出茅庐的学生，第一次来到公司面前做技术调研报告，胸里貌似没有了成竹，只是老师的一番话顿时让我淡定了不少，都把他们当作傻子吧，此时此刻以我的智商以定能唬得主那帮最可爱的人。
当时的情形我已经记不住了，所有的只言片语在脑海里聚拢成一句话：我们的需求三句话：流程可定制，表单可定制，流程可监控，小孙作为绝对主力，千万不要在需求上再出问题，你看我刚才叫什么外卖来着，明明是鸡腿，到手的却成了鸡翅，并且三个月后给出第一个版本。
于是我在此记住了这个人，他叫张总，在公司里一直强调着业务。
如今回过头来想想，这也是我第一次做技术调研，对于一个全新的领域这一环节显得如此的重要，再次打个比如，就像你去一个陌生的城市读书，这一步就像你的一个亲戚或朋友一样，虽然你之后总是要一个人去面对这个陌生的城市，但你朋友或亲戚的存在让你感到了一种叫做方向的东西。
我们以后的设计方案，貌似就是对上述几个产品加上joffice 加上shareidea 的整合，或者说是博取众长，虽然并不确定采众长之后我们取得了站在巨人肩膀上一般的成功。
我们的需求分析系统模块划分工单系统的功能性需求列表功能类别功能名称、标识符描述需求变更总结设计方案数据库设计流程ER说明：由于考虑到支持流程可定制，我们开始想过给jbpm的一些表中加入一些字段以达到支持灵活的需求，但这牵涉到对jbpm开源框架进行重构，并且我们对jbpm也没重源码上进行解读，所以我们放弃这一种办法。
我们采用的设计思想如上述E—R 模型，我们通过对jbpm 数据库结构的一些研究并进行了一些包装，我们抽象出流程定义，流程实例活动节点，并分别用外键关联jbpm 中相应的实体，本质上就是对jbpm 进行了一下包装，把业务数据都放在这些自定义的实体上，jbpm 的数据表负责流程逻辑相关的数据。
用户ER说明：用户模块对权限粒度要求比较细：总体来说就是用户与用户组多对多关联，用户组相当于角色控制了基本的权限，资源与资源组多对多关联，并且资源组与用户组关联，这样就间接实现了资源的权限控制，这在小型的系统中是比较常用的用户管理数据模型了。
关于hibernate实现持久层和session的管理在我们的数据库建模中，存在很多一对多的关系，一开始我们使用hibernate全部实现了所以的关联关系，在实际的调试中由于我们对延迟加载的不精通我们在很多部分都使用了非延迟加载，其中我们遇到了几次内存溢出的问题，这主要是由于非延迟加载把所有的相关数据都一次加载出来了，比如查找流程类型的时候几乎把数据库查询了一遍。
无奈之下我们把延迟加载用上，结果出现这样或那样的问题（主要是学艺不精），最后我们干脆放弃使用hibernate来管理1对多的关系，我们把model 对象里面集合属性全部去掉使用一个外键字段，有关联关系的我们就多写一个service 方法，这样我们发现虽然增加了访问数据的次数但每次获得的数据都是最小最实用的。
在此我的经验就是如果你对hibernate 不是那么精通建议放弃hibernate 1对多关系维护。
在一开始的session管理中，我们使用的是threadlocal方式，为每个连接保持一个session，在实际的操作中，经常出现一个session中有duplicated model 情况，并且一些问题时而出现时而不出现，还是由于我们对hibernate session 具体原理不是很清楚，在调试过程中吃尽了苦头，最后我们采用的方法是，我们在service 层自己管理session，每个sevice 方法对应一个session。