EOS流程设计与开发经验总结.doc

PRIMETON TECHNOLOGIES, LTD.
上海普元信息技术有限责任公司

EOS流程设计与开发

经验技巧总结

No part of this document may be reproduced, stored in any electronic retrieval system, or transmitted in any form or by any means, mechanical, photocopying, recording, otherwise, without the written permission of the copyright owner.

COPYRIGHT 2006 by Primeton Technologies, Ltd. ALL RIGHTS RESERVED.

文档修订记录
序号
版本号
修订日期
修订概述
修订人
审批人
备注
1
0.1
2009-3-8
创建
周进

规范及约定

1. 【规范及约定】的内容仅仅是对本文档编写的规范和约定进行描述，文档编写人员必须严格按照本规范和约定进行编写，在文档正式发布时删除该部分内容；
2. 文档内容采用“首行缩进、小四号字体、1.5倍行距”的格式，选中段落文本使用快捷键【Ctrl+Alt+4】可以进行格式化（直接选中蓝色的说明文字即可）；
3. 必须填写“文档修订控制记录”；
4. 文档目录必须更新为最新的，与实际内容相对应；
5. 模版中每部分内容的下面的蓝色字体是对这块内容的说明，编写文档时选中这段文字，使用【Ctrl+Alt+4】快捷键即可格式化成要求的字体；

目 录

1 文档摘要 5
1.1 文档分类 5
1.2 关键字/Tag 5
1.3 摘要 5
1.4 作者、协作者及评审人员 5
1.5 定义、首字母缩写词及缩略语 5
2 业务流程开发设计总结 6
2.1 流程客户端设计 6
2.2 流程设计 6
2.3 业务流程的表设计 8
2.4 流程相关数据区设计 9
2.5 展现逻辑设计 9
2.6 业务逻辑设计 12
2.7 页面的设计 14
2.8 其它设计与实现 14
2.9 总结 15

1 文档摘要

1.1 文档分类
EOS、流程设计、流程表
1.2 关键字/Tag
EOS、流程开发、设计
1.3 摘要
在开发商给员工培训EOS以后，总会碰到有人问，流程应怎么样去设计，设计流程时需要考虑一些什么，当碰到这种问题时，总没有一个比较好的解答。
在开发流程时，针对某一些特定行业的流程，例如政府，电信等行业，涉及到的情况大部分是申请环节填写大部分的信息，其它环境填写的信息相对较少，只是修改申请环节的部分信息，或者只是填写意见。对于这一类流程的设计与实现，可以统一通用的实现，供大家参考
1.4 作者、协作者及评审人员
作者：周进
1.5 定义、首字母缩写词及缩略语

2 业务流程开发设计总结
在与流程相关的项目中，流程比较多时，就需要一种流程的设计模式，定义一个流程的设计模式，一般可以包含流程的设计、表的设计、相关数据区、业务逻辑、展现逻辑的设计。
如果在项目组中有一个统一的模式，每一个流程的处理方式都一样，只是具体业务数据的不同，不用去考虑流程设计的一致性之类的东西，如果流程设计模式是统一的就可能只需要将各类型的文件复制，修改不同的路由，业务表，和参与者等，这样对于整个项目组来说，开发速度是非常快的。
2.1 流程客户端设计
开发业务流程的项目的工作内容，包含以下一些：
1、 流程客户端开发
2、 业务流程流转开发
3、 业务流程的统计分析
4、 辅助性的配置功能
流程客户端一般是客户的要求来定，在这些当中，要想找到通用的设计还是比较难，只能是在某一个行业当中，相差是很小的，并且会有很多的行业术语，可达到通用。
工作流客户端必须的功能中可以分为如下几类：
１、 流程状态的查询与统计
流程的查询，就包含所有流程的查询，个人待办查询、已办查询等。查询时，一都会有按流程类型、创建时间、业务状态、创建人、标题、流程类型等进行查询。
２、 流程的创建
通常是每一个不同流程都有一个创建的页面，来引导用户输入业务数据。
３、 流程信息的配置：角色的配置、业务字典的配置等
2.2 流程设计
在流程设计时，流程环节的设计直接影响流程与业务的吻合程度，流程的设计过程就是客户业务的抽象过程，不同的人设计出来的流程可能会完全不一样。
总的来说，可以将流程可以分为两类：
l 业务审批类：由首环节填写完成大部分的业务内容，其它环节只是查看首环节填写的信息，并填写审批意见。
l 过程表单类：过程的每一个环节都有的业务信息输入，而每一个环节输入的信息有比较大的区别，每一个环节都是业务信息的组成部分。整个流程走完，业务信息也收集完成。
这两类流程的环节和路由设计时，都会涉及到以下几个概念
1. 退回设计
流程一般都要求有任意环节回退，通常用增加路由线来实现业务上的退回，而不使用流程引擎的回退，流程引擎的回退，通过业务表是无法查看退回环节的已办任务。
2. 多工作项设计
在流程设计时，某一个业务的处理需要由几个参与者完成，完成某项业务没有显示的先后顺序，用单环节多工作项，还是使用多环节单工作项，可以依据以下原则：
1、 如果使用单环节多工作项，一般是某一环节所有的人填写的信息都是一致的，并且某一条件满足环节退回或者进入下一环节时，整个环节退回或者进入下一环节的处理都相同。参与者的个人是不确认的。
2、 如果环节填写的信息不完全相同，某一个人的退回或者进入下一环节不影响其它人的填写，这时，就需要使用多环节单工作项，并且参者可是可以进行分类，或者确定
3. 子流程设计
某一环节的处理，可能会引起另一串活动，这时在设计时会通常会引入子流程，子流程的实现采用启动一个新的流程来实现，用程序代码控制流程的流转。达到业务要求，在设计子流程时，通常会加入确认环节，即谁派发的任务需要谁确认。
4. 流程状态设计
通常在流程流转过程中，需要标识当前流程的状态，通常会每一个环节对应一个业务状态，如果有子流程，还会增加一个特殊状态，用于标识当前主单的业务状态，增加这个状态主要是区分流程在派了子单后，主单暂时不需要在待办中出现，而设置。

下图为一个典型的审批类流程，首环节申请，后续环节只需要填写审核意见，确认是否通过往后走。
此时的退回，使用流程的路由实现，在设置路由的值时，就形成了规则：
１、 进入同一环节的路由值相同
２、 默认是下一环节
按此规则设计，可以减少路由值的设置。

2.3 业务流程的表设计
在表设计过程中，业务表与流程表之间通常用流程实例号作为关联，在每一个业务表中都会增加一个流程实例号字段，某一业务需要用到活动ID或者工作项ID也将它写入业务表。
业务流程的表主要分为两类
一、 流程客户端的表
a) 流程公共信息表：
通常所有流程都有的公共信息存放于此表。常用的字段有：流程实例号、流程标题、流程类型、流程编号、上一级处理人、当前责任人、超时时间、开始时间、结束时间、当前业务状态、创建人部门、是否为子流程、流程定义ID等，如果有子流程，需要加入父流程实例ID，根流程实例ID字段
b) 流程处理表
流程处理表作用是将环节的处理过程进行记录，只在流程流转历史，常用的字段有：流程实例ID、流程标题、流程编号、环节名称、活动定义ID、处理人、环节开始时间、环节结束时间、上一环节工作项ID，上一环节名称、是否最后提交等字段。
其中是否最后提交字段作用是标识环节的最新数据，有退回的环节，可能会出现两条相同的记录。
二、 业务流程的业务表
对于业务表的设计，
审核类流程，通常是有一张业务主表，将的业务信息写存入此表，再建一个处理过程信息表，用于存放环节处理意见。
过程表单类流程，环节的信息变化多样，需要每一个环节建一个业务表来存储相应的业务数据，也有需要在不同的环节都保存业务信息的不同版本，每一个环节保存一份业务数据，并标识是某一环节的数据。
三、 其它业务表
为了业务流程统计需要，针对某一特定流程的处理过程进行统计与分析，流程客户端记录信息不够时，需要针对某一流程的业务处理过程日志进行以达到统计需要。
四、 视图的设计
对于业务表的视图设计，一般都是一个环节一个视图，方便业务数据的查看。
总之：业务流程的表设计可以按以下原则：
1、 工作流客户端的表字段根据所有流程都需要的属性设计。
2、 特定流程属性字段存放在业务表，有一张业务主表，通常将首环节的业务信息存放到业务主表当中，其它环节信息写入环节信息表，如果环节信息基本相同则建一个特定流程的环节信息表，如果不同，则每一环节建一个业务表用流程实例号关联。
3、 视图的设计：一般按一个环节一个视图处理，如果是只有一张环节信息表，则根据环节定义ID建视图，如果每一环节都有表，则一张环节表建一个视图。

2.4 流程相关数据区设计
设计的原则是相关数据区的数据越少越好，能省则省。在设计流程相关数据区时，一般会固定分为几个区域：
１、 参与者区域
a) 将每一个环节的参与者，单独一个的节点。保证环节的参与者之间不会冲突，只需要设置过后，参与者将不会出错。
b) 参与者的数据结构进行统一，一般使用三个节点的形式存诸。ID、NAME、 TPYE。
２、 路由区域
路由区域的设置可以按以下原则进行处理：
a) 设置一个默认路径的路由值。
b) 不同环节流向同一个环节的路由值应是相同的。
c) 路由节点的个数是由流程设计时当前最大的活动数决定
３、 时限配置区域
EOS中可以配置的超时时限，业务可能需要在流程流转过程中，对时限进行修改，根据具体业务确认这个区域的值。
４、 业务数据区域
在某些自动活动，或者触发事件时，能够读取到的数据只有相关数据区，这时，就需要将一部分业务数据存放到此区域。通常会将流程实例号存放在此区域，通过他找到相应的业务数据。

2.5 展现逻辑设计
在EOS的展现逻辑中，与流程有关的展现逻辑主要有以下几类
1. 创建流程的展现逻辑
a) 流程信息输入页面打开的展现逻辑 pr_GCJD_apply_input
i. 此展现逻辑，根据流程的申请环节的复杂程度，而不同，但可以总结为：准备页面需要的初始数据，打开相应的JSP页面，这两步处理，流程的不同就只有业务数据的准备以及页面的不同

b) 流程创建时的保存展现逻辑 pr_GCJD_apply_submit
此展现逻辑的处理过程为：本流程的业务处理、流程的其它处、提示操作成功状态。
在下图中的展现逻辑中，保存业务数据时做了如下处理：创建流程、保存业务数据、保存公共表、设置参与者、设置路由，其它处理、结束工作项。如果还有其它的处理，再实现其它的处理逻辑。
所有申请环节的提交都可以按此来操作，也包含重新申请的提交，两个的区别只是重新提交时，不创建新的流程，对业务表的操作也只是更新，不是插入操作。

2. 流程环节处理的展现逻辑
a) 流程处理环节的输入展现逻辑　pr_GCJD_audit_input

流程处理环节的展现主要包括有：获取业务数据，取了流程公共信息，这些步骤通常是为业面显示数据的需要而做处理。
b) 流程处理环节的提交展现逻辑　pr_GCJD_audit_submit
在流程的处理环节的数据提交时处理步骤为：保存业务数据、设置参与者、设置路由、保存公共信息这几步，和流程的首环节处理都是一样，两个环节的处理提交理论上是可以合并，在首环节还有一些保存草稿等功能，与其它环节的处理差异性会比较大，所以将其拆分两个展现逻辑。

3. 流程查看的展现逻辑
流程查看，只是将流程的当前信息显示给用户，只需要将当前的业务信息，流程公共信息展现即可。

2.6 业务逻辑设计
流程的业务逻辑可以分为以下面种
1. 业务数据保存：这根据流程页面的复杂程序，所需要保存的数据数据会有不同，这个业务逻辑的保存，申请环节与其它环节会有区别，申请环节需要创建流程，创建公共表字段等，通常会将其分开实现。
a) 申请环节流程提交时的保存业务的逻辑设计，此实现是没有草稿的情况下的代码实例，如果有草稿，写法将不一样。

b) 其它环节的保存业务逻辑设计：
通常只需要更新业务主表信息以及增加本流程的环节信息。

2. 公共数据保存：这是一个通用的业务逻辑，每一个环节都会用到，将流程的当前信息写入到流程客户端表中。
3. 相关流程处理：如果有子流程，都需要准备数据对子流程做相应的处理，这根据实际的业务需要来实现
4. 流程路由设置：根据业务规则，设置流程流转的路由。只需要往相关数据区中设置下一环节的路径值即可。

5. 后续环节参与者设置：设置此环节以后的已知参与者，因为每一个环节都有独立的参与者结点，设置好以后，直接设置即不会产生数据冲突。

6. 相关数据区特殊处理：相关数据区的设置，是根据业务的需要进行设置。

2.7 页面的设计
１、 流程相关的业务主要有如下几部分：
a) 申请环节页面：
b) 申请环节查看页面：
c) 流程环节处理页面
d) 流程环节查看页面
e) 流程图显示页面
f) 流程处理过程页面
g) 附件上传页面
这些页面都是流程的最基本的元素，根据客户要组，将这些页面进行组装，生成相应的页面，其中申请环节的填写页面，根据业务的复杂程度，页面会有很大的差别。每一个环节信息的填写都有一个查看和填写页面，这些页面一般都是成对出现。

2.8 其它设计与实现
1. 并发控制的处理：
a) 如果某一环节的参与者为一个角色，如果两个人同时具体这一角色，并同步打开，后提交的用户将无法提交，在提交时需要做并发控制的处理。
2. 通用功能的设计：
a) 在某一个项目中，总会有一个通用的功能，比如：附件上传、抄送、流程流转记录等功能，这些在设计上就需要考虑到本项目一级的通用。
3. 与KPI相关的设计
a) 做流程相关的项目，主要目的是为了更好的做管理，客户一般都会对流程的统计提出一些要求，统计一般是统计某一环节的平均占用时间，流程平均退回次数，流程超时时间等一系统列指标，这些就需要在数据库表设计时进行确认，为了统计方便，会将工作项开始时间与结束时间设计到业务表中，方便进行统计。
4. 业务状态：
a) 有很多状态都可以在流程引擎的相关表中查询到，有时为了方便，会将流程引擎的相关状态写入到业务表中方便统计。
5. 草稿的设计
a) 在项目中，草稿只是存放一些业务信息，在设计中为了方便，通用在草稿的信息中增加一个字段进行标识，业务信息表中通过设定某一主表的ID作为主键进行标识。
6. 多工作项的实现：
在EOS默认的多工作项处理时，只有按工作项数，来决定活动结束的条件。
在多工作项中，会有这种常见的业务，某一个工作项分给N个人，只要有一个人退回，其它未处理完成的工作项将不再需要处理，整个流程都需要退回。在实现此业务时，只需要根据业务条件进行判断，通过构件直接结束活动，流程就实现了退回。

2.9 总结
在流程项目开发时，对于流程不复杂，可以按照一定的模式来快速开发流程。对于很多通用的功能，进行抽象，让整个项目组按一定的模式处理。
l 流程图设计原则
a) 路由设计
i. 进入同一环节的路由值相同
ii. 默认是下一环节
b) 其它：
i. 能够尽量使用单工作项的，尽量使用单工作项。
ii. 尽量使用关联流程实现子流程
iii. 尽量使用路由线来实现退回
l 展现逻辑设计原则
a) 将首环节的展现与其它环节的展现逻辑进行分开。
b) 将非首环节的展现逻辑进行统一处理。
l 逻辑设计原则
a) 在首环节，所有流程的处理基本上都是一致，由创建流程、保存业务数据、保存公共数据、设置路由、设置参与者、设置相关数据区、其它处理。将这一些功能写成通用的BIZ。
b) 在其它环节更新业务数据、保存公共数据、设置路由、设置参与者、设置相关数据区、其它处理。这几个步骤。这些与首环节绝大部分是相同的，现一次对其进行抽象即可。这样就提高了代码的复用。
l 业务表的设计原则
a) 工作流客户端的表字段根据所有流程都需要的属性设计。
b) 特定流程属性字段存放在业务表
c) 一般按一个环节一个视图设计