K2流程设计指南.PDFVIP

K2 流程设计指南 2011-10-20 文档版本 日期 版本 作者 状态 2011-10-20 V 0.2 Xxxx Draft 1. 总体设计理念 充分发挥流程引擎的灵活的业务规则计算和人机任务流转的功能，实现上层业务逻辑和流程控制逻辑 的分离；业务数据和流程数据的分离。从而达到 UI 层只处理点的操作，而由点之间的连线及流程控 制逻辑交由K2 处理。而在流程控制之中，涉及的业务数据处理也由K2 驱动，从而充分利用K2 企业 级流程引擎的强壮性。 在具体的K2 流程设计时，推荐按如下的指导原则进行K2 流程设计：  任务路由的逻辑尽量在K2 内部实现  在涉及到 K2 流程和外部数据交互时，遵从从 K2 到外部的设计思路，避免从外部到K2 的反向设 计。  在K2 流程内的数据交互建议通过K2 Smart Object 方式实现  避免在K2 内大量使用DataField 保存业务数据而造成K2 处理性能的下降流程交互设计  尽量利用K2 开发工具提供的图形化向导完成开发，避免大量在K2 流程图中嵌入代码而易造成流 程可读性、可维护性、BUG 调试方面的问题。 PAGE 2 2. 流程基础功能设计 2.1 任务路由 K2 作为独立的流程引擎产品，任务路由是其核心功能，故该功能的全面性、稳定性、可管理性等都是 非常强大的。把任务路由的判断逻辑放在K2 内部具有如下优势：  整体系统设计逻辑简单，职责分明：K2 负责流程的走向控制，表单负责单个节点的数据操作。从 而整体系统的开发和测试成本也可大大降低。  流程变更或优化较为方便 K2 的任务路由主要基于K2 的Line Rule 和在Code Event 中利用Goto Activity 功能实现。通常情况下， 利用K2 的Line Rule 可以满足绝大部分的任务路由需求。当存在如下场景时，可以利用Goto Activity 功能实现节点的跳转：  流程图中节点很多，在实现诸如流程发起人Rework 功能时，存在多个节点Rework 时到同一个节 点的情况，通过Line Rule 画线方式将使得流程图美观性和可读性较差  存在某个审批节点动态跳转到不确定的审批节点 2.2 汇报关系 K2 自身带有基于AD 的汇报关系，也可利用K2 自带的角色功能实现汇报关系，但以上二种方式过于 简单，一般无法满足企业流程的复杂汇报关系需求。故通常需要自行实现汇报关系。针对流程应用的 自定义的汇报关系，通常有如下二种实现方式：  独立的汇报关系模块 该方式通过分析企业的组织架构及业务流管理模式，建构一套较为通用的独立汇报关系模块，并 通过开发服务接口方式为供各具体应用消费。可以以该方式开发独立的业务中间件，实现为全公 司各类相关应用系统提供统一的服务功能，从而在整体上降低了企业的应用系统构建和维护成本。 在针对ASB 这类流程应用较广泛的环境下，该实现方式的价值将得到充分体现。  各个流程应用系统根据自身需求自行设计实现：该方式通过分析项目本身的汇报关系需求建构， 一般以满足本项目需求为目标。因而从单个项目的角度，相对需求的复杂度和实现成本较低；但 同样也具有明显的缺点：不同项目难以通用，一般存在不同系统相关功能重复开发的现象；可维 护性较差。 2.3 流程审批 K2 以图的形式支持多种场景下的人机交互流程审批：  单个流程节点审批：  单人审批、多人中任一人审批：设置K2 的Destination Rule 中Slot 为1 即可  多人收到任务，需要部分或全部参与审批：设置K2 的Destination Rule 中多个Slot，配置不 同Action 的Outcome 规则  并行分支节点的汇总：通过K2 的Proceeding Rule 设置汇总规则，需要注意的是K2 的Proceeding