BPM框架设计
对 Workflow和BPM，没有严格的概念界限区分
首先让我们回顾到上个世纪九十年代，诞生了 “Process Reengineering”，可惜那个时候只是一阵风，因为技术跟不上，所以大多都只停留在管理层概念。但是，在九十年代，workflow技术却蓬勃发展，可谓是百家争鸣，蒸蒸日上。
2000左右，工作流技术应用已经非常成熟，数据集成，应用集成也发展迅速。随之也推动了业务过程管理、整合、统计、优化等方面的应用需求。于是就诞生了“BPM”这个概念。
如果 Workflow是早期人们为了解决“办公自动化”“流程自动化”而诞生的应用技术和解决方案的话；那么BPM则是为了“对全局性的业务分析、整合”，以及“能够基于这些分析提供对上层管理决策的支持”的一种应用技术和解决方案。
事实上，如何去描述业务过程 “Business Process”，一直还是个争论不休的话题，也因此存在几种标准。主要是以WfMC为代表的XPDL，OASIS为代表的BPEL，OMG为代表的BPMN和BPDM。
虽然描述过程 “Process”的标准并不一样，但是在圈定以：过程定义、过程执行、过程监控、过程分析、过程优化这几个方面为核心的BPM Solution ，这一方面各家几乎都是相同的，只是实现技术不同。
BPM关注于由一些独立的应用系统组成的业务流程的的模拟、定义、执行、分析和管理。BPM是工作流的超集，最大的不同是使不同的应用活动相互协作提供强大的整合能力。
工作流管理系统用于控制流程从一个人到另一个人，从一个应用到另一个应用，因此，它用于管理工作流的信息。工作流管理不考虑业务流程的优化。 BPM真正控制整个流程，确保工作流能够按计划实施。
ＢＰＭ的解决方案包含很多工具，可以帮助业务人员很容易的创建和记录流程。可以为 IT人员提供一个协同环境，来将业务人员创建的业务流程转换为可以执行的、与数据库、电子表格和业务规则相集成的代码。当业务流程很复杂的时候，一个人是不够的，很多不同的人要一起工作，协同工具是有必要的，它使得业务人员和IT人员可以进行协作。
ＢＰＭ可以帮助软件开发人员来集成第三方的应用软件。在企业中有很多不同的应用系统。例如， ERP、PLM、财务软件等。这些系统可以通过ＢＰＭ平台进行集成。此外ＢＰＭ还用于处理流程执行过程中的意外和特殊情况，发布流程，并对流程进行版本控制。另外有一种工具，可以从正在执行的流程中提取一系列的指标，生成各种形式的报告，使流程的拥有者能够管理流程的资源，实现流程的优化。
简而言之， BPM可以提供所有的流程控制功能，并实现与各类应用软件的集成，但工作流管理不能实现这些功能。
1、工作流(Workflow)
在模拟、定义、执行和分析方面并不是非常关心完整周期的流程管理。没有内置的流程管理概念。
有限的可测量性和可靠性，通常只是为部门级的使用进行设计并只有有限的平台支持。
缺乏整合能力，通常只限于传送图片或者文档附件。
通常只能运行指定的应用系统，无法运行外部的主机应用系统，比如 Oracle、SAP等等。
功能着重于提供强大的电子表单功能。
通常在非任务验证和收入结算领域使用。
2、BPM
业务流程的管理、模拟、执行和分析的独立的软件平台，通常用于 P2P、P2A和A2A(STP)任务验证和收入结算流程中。
高可测性、高事务数、大用户量的设计。
很强的集成能力，业务流程能够通过不同应用系统与多个软 /硬件平台进行端到端的连接。
提供的主要功能：
a.高可视化
b.可管理化
c.灵活性
d.模块化
e.整合性
f.基于规则
g.持续的优化
h.嵌入的
3、BPMN
由BPMI(The Business Process Management Initiative)开发了一套标准叫业务流程建模符号(BPMN - Business Process Modeling Notation)。在 BPMI Notation Working Group超过2年的努力，于2004年5月对外发布了BPMN 1.0 规范。后BPMI并入到OMG组织，OMG于2011年推出BPMN2.0标准，对BPMN进行了重新定义(Business Process Model and Notation)。BPMN的主要目标是提供一些被所有业务用户容易理解的符号，从创建流程轮廓的业务分析到这些流程的实现，直到最终用户的管理监控。BPMN也支持提供一个内部的模型可以生成可执行的BPEL4WS。因此BPMN的出现，弥补了从业务流程设计到流程开发的间隙。BPMN定义了一个
业务流程图（Business Process Diagram），该业务流程图基于一个流程图（flowcharting），该流程图被设计用于创建业务流程操作的图形化模型。而一个业务流程模型（Business Process Model），指一个由图形对象（graphical objects）组成的网状图，图形对象包括活动（activities和用于定义这些活动执行顺序的流程控制器flow controls）。
流程编辑器
流程引擎设计
设计理论，依据图论。节点，节点直接的连线。这里只介绍基本流程框架。
节点：节点可以分为 开始、结束、审批、任务等类型节点。大家有各自不同的处理逻辑。
此外节点上会有一些属性，比如说审批人等设计业务的参数，此类参数可以根据业务继续扩展。
连线：连线有正向和反向的区分。
连线上也可以扩展业务参数，根据自己业务需求。
流程定义表
|
ID
|
主键
|
|
ProcessCode
|
流程编码
|
|
ProcessName
|
流程名称
|
|
Version
|
版本，每次修改发版流程版本号
|
|
ProcessDesign
|
流程定义，可以是xml json等表述流程BPMN流程图
|
流程节点
|
ID
|
|
|
ProcessCode
|
流程编码
|
|
NodeName
|
|
|
NodeCode
|
|
|
NodeType
|
1、开始节点 2、审批节点 3、任务节点、4、ifelse节点 99、结束节点
|
流程节点 连线
|
ID
|
|
|
ProcessCode
|
|
|
FromNodeId
|
开始节点
|
|
ToNodeId
|
结束节点
|
|
Direction
|
方向1正向 2反向
|
上述表已经可以定义一个图(数据结构)。还可以加上版本编号。
节点审核用户 表
这里可以扩展很多类型比如说审批人上级，固定角色等等。会签 或签等场景。
|
ID
|
主键
|
|
NodeId
|
|
|
UserId
|
审核人ID
|
流程节点 连线 条件表
在判断的时候，需要
|
ID
|
|
|
LinkId
|
流程连线ID
|
|
ConditionExp
|
条件表达式，可以根据流程实例变量，以及节点审批状态等参数做判断
|
以上又加入节点属性，连线属性表。可以根据功能在扩展。
流程实例表
|
ID
|
|
|
ProcessCode
|
流程编码
|
|
BizCode
|
对应业务code
|
|
CurrentNodeId
|
当前节点
|
|
ProcessVersion
|
流程版本
|
|
Status
|
状态，标识流程是否结束
|
流程实例 变量表
|
ID
|
|
|
ProcessInstanceID
|
流程实例ID
|
|
FormKey
|
|
|
FormValue
|
流程审批记录表
|
ProcessInstanceID
|
|
|
FromNode
|
开始节点
|
|
ToNode
|
结束节点
|
|
ApproveStatus
|
审批状态
|
|
ApproveRemark
|
审批意见
|
