几年前做个工作流相关的一些工作，感兴趣的也可参考一下，说明一下，这是几年前的，后期只是作为OpenExpressApp的参考。
本文档是工作流设计部分的关于技术选择和实现的一些过程的记录，以便说明选择的依据以及提供给后续设计的参考。以下内容主要涉及单据审核技术。
平台为什么要做工作流
因素
- 用户需求
- 技术考虑
分析
业务角度
满足用户的多级审核要求。实际业务中，不管是预算人员、材料人员、技术人员等所处的工作流程中都会涉及到工作流程，在越众的广州丽岛翠堤项目中对于一般材料出库的流程入下图所示：
此流程中涉及到多个岗位之间工作的审核步骤，这些流程实际发生，但不能在以前应用中体现，用户也提出过此类需求。
目前项目部一般都处在同一办公地点，交流比较方便，所以人工纸张审核仍有效，但如果以后涉及到项目组和公司之间审核的电子化则按现在实施方式将不能进行，所以实现流程化将有利于以后后续的业务需求。
技术角度
在底层提供一个工作流的平台将有利于抽象对流程的设计和处理，可以统一处理工作流程的设计、部署、执行、监督等步骤，而不需要对每个流程单独处理。另一方面，工作流的实现也可以适用在代码处理逻辑上的流程，对于定制规则和流程都有很大用处。通过图形化的流程设定可以更好的提供平台支持。
平台提供的工作流是什么
因素
- 对平台的支持
- 易用
- 可扩展
分析
- 不仅满足多级别审核需要，也可应用在商业流程自动化逻辑流程上
- 提供图形化流程设计器的拖拽能够简单的定义工作流程，并可在任何时间查看流程执行当前的情况
- 通过对流程提供的Activity扩充，可以扩展流程中可以提供的功能，第一阶段支持单人、多人、条件分支、邮件通知
- 审核流程与业务单据低耦合，可以方便的和单据关联
工作流引擎产品的选择
因素
- 审核流程实现的可行性
- 开发的扩展性
- 费用问题
解决方案
构建在微软的下一代开发平台的WinFX中的WWF技术上
分析
- 微软WWF开发框架提供了工作流引擎、.Net-managed API、运行时服务以及与VS2005集成的可视化编辑器和调试工具，完全可以实现多级审核流程。
- 可以通过其提供的设计时支持开发开发自己的流程设计器，获得更好的用户体验
- WF不仅提供了以往的人力工作流引擎，还可以支持用户界面页面流和面向服务的应用程序、商业流程自动化以及系统管理流，可以在此基础上二次开发更多应用
- 不需要自己开发引擎部分，减少了机会成本。目前在WF上进行开发不需要任何费用，个人预计正式发版后也不需要费用
考虑过的备选方案
- 自主开发
在还没有深入分析WWF之前考虑自主开发一套工作流子系统，但如果开发一个完整的工作流平台需要占用较多的人力资源和时间。WFW实现了我们希望做的所有功能，而且做的更好。
审核流程功能实现范围
因素
- 需求
- 易用性
- 实现难易程度
- 时间
解决方案
| 重点内容 | 工作说明 |
| 自定义Activity | 通过工作流提供的Activity与系统组件进行交互 |
| 提交 | 一旦接受到提交事件则启动流程执行到审核步骤 |
| 单人审核 | 指定某个人对提交的单据进行审核 |
| 多人审核 | 指定一群人对提交的单据进行审核，分为以下情况 |
| 同时执行 | 每个人同时执行当前任务 |
| 依次执行 | 依照指派顺序依次执行当前任务 |
| 邮件通知 | 通过邮件通知收件人 |
| 条件分支 | 可以通过条件表达式确定流程分支的走向 |
| 流程设计器 | 通过图形化界面拖拽生成流程定义 |
| 流程设计控件 | 提供流程定义容器，可以加载流程定义和定义流程活动 |
| 流程设计器 | 使用流程设计界面，提供用户流程设计界面 |
| 工作流服务 |
|
| 持久化服务、跟踪服务、Web模块 | 采用WWF提供的默认服务 |
| 业务和流程交互接口 | 通过提交、审核接口使得业务系统与工作流系统进行关联，通过触发接口方法使得流程运转到流程定义的下一步活动 |
| Web服务 |
|
| 流程触发 | 提供提交、审核通过、审核不通过方法 |
| 流程状态图形 | 获取某一工作流程的执行情况的图形表现 |
| 数据库设计 | 持久化工作流子系统的数据 |
| 流程表 | 记录一个工作流程的基本信息，包括启动结束时间、启动人、流程状态等 |
| 工作任务表 | 记录工作流程每个审核步骤信息，包括启动、结束时间、活动状态等 |
与各子系统接口
| 重点内容 | 工作说明 |
| 组织机构 | 通过组织机构提供的API获取人员、组织选择，指定工作流程执行者 |
| 权限子系统 | 通过权限子系统限定流程创建者、提交者、审核人的权限 |
| 界面引擎 | 通过界面引擎显示流程中指定的单据 |
| 表达式引擎 | 通过表达式应用在流程中确定流程的运行分支 |
留待扩展实现
| 重点内容 | 工作说明 |
| 完善数据库设计以及提供工作流API |
|
| WfWorkflow的实现 | 工作流状态信息表，由此提供当前单据提交者、单据审核状态等 |
| 添加额外数据 |
|
| 自定义Activity | 通过工作流提供的Activity与系统组件进行交互 |
| 多人审核 | 指定一群人对提交的单据进行审核 |
| 单人审核 | 指定某个人对提交的单据进行审核，内置邮件通知、审核不通过是否结束流程等 |
| 一人独占执行 | 第一个处理的人处理完后其他人将不能再处理 |
| 流程回转活动 | 根据条件可以从单前活动中跳转到以前执行的步骤 |
| 手机短信通知 | 发送手机短信通知 |
| 流程设计器 | 通过图形化界面拖拽生成流程定义 |
| 流程设计器 | 提供用户友好的流程设计界面 |
| 活动规则 | 流程运转中应该遵循的规则 |
| 时间规则 |
|
| 过期规则 | 如果希望某些任务必须在一定时间内完成，比如8小时，如果超过8小时任务依然没有被执行，我们必须执行一定的操作（比如：发邮件催办，或者强制本任务过期并且将流程流转到某一个流程节点等） |
| 安全与权限规则 | 通过权限子系统限定流程创建者、提交者、审核人的权限 |
| 执行人规则 |
|
| 多人审批后置规则 | 是一个逻辑表达式，当它为真时，某个流程节点才可以完成。换句话说就是：什么情况下流程节点才可以结束。比如：有一个审批任务，需要同时发给5个部门经理作审批，我们希望：只要他们中的一个不同意，流程就执行下一步操作（否决后的操作）；至少有3个部门经理同意，流程就流转到下一步操作（同意后的操作）。 |
| 单人审核时可动态添加审核活动 | 可以动态在已定义流程上添加审核步骤 |
| 报表支持 | 通过报表引擎建立与工作流相关的报表 |
| 其他工作流系统的需求 |
|
与各子系统关系
参见文档《工作流对平台各子系统的需求》
流程图形化实现
因素
- 易用、美观
- 实现时间
解决方案
封装WWF本身提供的图形设计时支持，在C/S下进行流程设计（通过ClickOnce进行网络部署）或者通过ActiveX在网页中显示，监控流程图形可以通过图片形式展现
分析
- 由于基于WWF开发，开发的图形存储也要基础WWF格式，自己实现一套图形化需要较长时间
- WWF提供的图形化界面布局不能自己随意控制，但是足以清晰的表现流程，使用起来还是比较方便
- WWF本身提供了设计时支持，包括一些序列化的API都已经提供
考虑过的备选方案
- 采用Netron开源图形项目进行图形处理：时间因素和在技术上需要实现很多内容
- 采用VML在网页形式下开发：在网页上可以操作浏览，但是界面表现能力不强
审核工作流程设计
解决方案
- 实现提交、单人审核、多人审核、邮件通知Activity，支持条件分支，不支持流程回转。
- 对于多人审核根据审核人列表和审核类型动态生成一系列单人审核活动
多人审核Activity设计
因素
- 能方便的设计流程
- 满足同时审核、依次审核、一人独占执行功能
解决方案
- 封装一个多人审核的Activity，实现同时审核、依次审核功能，内部处理审核信息的存储和多人审核结果的合并工作
- 动态生成多个单人审核活动(此步骤由工作流程完成)，单人审核的审核结果同步到工作流程参数中，以便进行满足合并同时审核类型的审核结果
- 如果审核人员列表为表达式，则由表达式引擎子系统确定审核人员列表
考虑过的备选方案
- 初期迭代本来还想实现一人独占执行类型，本来考虑采用ListenActivity，但是由于封装的单人审核不满足ListActivity子活动要求，如果需要实现以后可以考虑使用ConditionedActivityGroup，给每个人添加阈值达到满足哪些人提交审核通过就算通过的情况
分支Activity设计
解决方案
- 采用IfElseActivity活动，使用CodeCondition进行分支条件处理。由工作流代码提供Code模板进行编译
- 为了简便，使用活动的Description属性编写表达式。根据此来重新生成xoml文件
- 表达式解析由表达式引擎负责
考虑过的备选方案
目前使用IronPython进行表达式解析，对于最终用户不够友好
动态更新设计
解决方案
在工作流程添加一个动态更新办法，由多人审核活动内部通过反射机制调用来达到动态更新效果
考虑过的备选方案
在多人审核Activity中自己处理动态流程，但是WWF本身为了简单升级后不允许更新自定义的复合Activity，导致不能按照预先的想法实现
流程监控界面效果
解决方案
- 仍旧采用工作流程设计控件处理，添加DesignerGlyphProvider显示活动执行状态效果
- 同时显示多人审核以及由多人审核动态生成的单人审核活动
考虑过的备选方案
显示每个审核步骤审核结果而不只是状态，不显示由多人审核动态更新的单人活动，但是由于实现起来需要时间，所以暂时先不实现
数据库设计
解决方案
- Tracking服务和持久化服务采用WWF提供的数据库模板
- 工作流子系统本身提供两张表，一张记录工作流状态信息，一张记录工作任务状态信息
WfWorkflow 工作流表：
| 字段 | 类型 | 说明 |
| ProcessID | GUID（主键） | 工作流实例标识 |
| Status | 工作流程实例状态 | Completed = 2 完成Idle = 3 空闲Terminated = 10 中止Changed = 12 动态变化 |
| CreateTime | Datatime | 流程创建时间 |
| CloseTime | Datatime | 流程结束时间 |
WfTask 工作任务表：
| 字段 | 类型 | 说明 |
| TaskID | 整形（主键） | 活动标识 |
| ProcessID | GUID | 流水号，与WfWokflow的ProcessID关联 |
| ReviewInfo | XML | 提交人 |
| ReviewerID | 字符串 | 审核人标识,由组织机构子系统确定具体格式 |
| Status | 整形 | Executing = 1 进行中Closed = 3 任务执行完毕 |
| CreateTime | Datatime | 任务创建时间 |
| CloseTime | Datatime | 任务结束时间 |
存储过程
| 字段 | 输出参数 | 说明 |
| InsertWfTask | TaskID int OUTPUT | 插入任务项记录 |
| UpdateWfTask |
| 更新任务项记录 |
ReviewInfo Schema：
| 元素 | 说明 |
| SubmitInfo | 提交信息，包括提交者、提交文档标识，由界面引擎决确定文档标识uri具体内容，目前uri设计是假定在界面引擎基于表确定界面 |
| Items | 审核信息，记录流程中每个审核步骤的结果。一个流程的后续审核步骤的Items信息包含前一活动此元素的所有信息，也就是说后续流程人员能够看到前续流程的所有审核记录 |
欢迎转载，转载请注明：转载自 [ ]