Teamplate 工作流开发技术总结(2)

关注一下Add方法所使用的几个参数，请再看第7行代码，

第一个参数是ProcessName，我们这里用业务表单的流水号来修改它，它可以是空字符串，空字符串时产生的流程名称是在设计Model时输入的DefaultProcessName值后面加上流程的ID号。在这里需要补充说明的一点是ProcessName是不能有重复值的，包括不跟FolderName、ModelName重名，原因是Teamplate在保存这些对象的Files表中Name字段有一个UNIQUE 约束来强制名称的唯一性。

第二个参数是指定放置这个Process的文件夹ID，这个文件夹不是指的物理磁盘的中的文件夹，而是Teamplate系统虚拟的文件夹，具有唯一的ID。

第三个参数指定流程的所有者，微软的网站上介绍Teamplate的文档中是这样描述的：

Teamplate for .NET 也将增强其基于角色（role-based）的安全模型，以充分利用基于人员的工作流服务的不同用户的限制条件。这将保证在一个特定的工作流中，只有创造工作流任务的用户有权委派或分配任务给其他的用户。

很不幸，受微软所吹捧的这一功能在我们的客户面前碰了一个大钉子，客户的需求是：微软文中的创造工作流的用户只能做为一个流程的发起人，而委派或分派任务的权限要交由这个流程模板的管理人员来执行。为了解决这个问题所以有了上面的代码，我们在部署项目时把Model的所有权赋给这个Model的管理人员后，在新建流程之前先获取这个Model的所有人，然后在创建新流程时将流程的所有权限赋给这个Model的所有人（这个值不设置时，默认为就是流程的发起人），从而使Model的所有人获得了Process所有人的权限，问题得到解决。

第四个参数很好理解，就是你要新建Process的Model对应的ID值。

现在可能已经有人对下面的三行代码提出疑义来了，为什么还需要这么一段代码呢？其实很简单，Add一个Process时，默认的第一个Task的执行人就是Add参数中的所有人，那么现在执行权限都给管理拿过去了，也就是所有的流程都交给管理员去做了，我们就不用做事了，^_^！当然是不可以的，要把执行的权限拿回来，所以就有了后面的三行代码，先LoadProcess，获取TaskID，再Update Task的ResponseID（前面有讲过，Task的责任人）。

对最前面的4行代码的解释：代码的功能应该是一目了然，目的是获取后面几个方法所需要的参数。这里唯一需要说明的是TeamplateLib对象不是Teamplate提供的，是我们对Teamplate不直接提供的方法做的一些补充，具体实现是直接在Teamplate数据库中查寻得出的。

1.1               工作流的流转

在Task对应应用程序执行程序时，当业务数据提交时，我们需要将流程往后流转，先看代码：

                     process = new BProcess();

                     process.SetSessionToken(token);

                     process.Load(processId);

                     this.SaveBindingData(process);

                     process.WorkflowAdvance(taskId, null);

代码说明：

前面3行代码通过前面的两个例子应该都有所了解，现在来看这个Sample的最关键的一句代码也就是最后一行代码，这一句调用Process的WorkflowAdvance方法来进行流程的流转，详细的说明可以参考Teamplate的帮助文档，这里需要说明的一点是它的第一个参数TaskID，TaskID必须是当前Process的处于Ready状态的Task的ID。

另一个比较重要的说明，代码的第四行用了一个SaveBindingData方法，在这个方法的主要功能是业务数据的保存和保存Process的XML数据。前面在讲设计Model的时候，提到过定义XML数据用于流程流转的控制，在流程流转前，我们就需要根据实际的业务数据将数据保存到之前定义好的XML，然后在WorkflowAdvance方法执行时，就会根据保存的XML数据做为条件根据定义好的业务规则进行控制流转。
   

1           对Teamplate的扩展开发

1.1               为什么要进行扩展开发

为什么要扩展开发，也就时Teamplate的局限性，首先Teamplate在流程角色定义上表现过于简单，跟客户需求相比它没有对流程管理员、流程发起人，流程参与人等角色有明确定义，而且Teamplate提供的标准任务列表控件功能又过于简单，在流程监控，权限控制以及过滤查询方面的功能都不能满足客户的需求，而且又没有流程的流转日志记录，所有上面所描述的这些都是我们进行自定义扩展开发的原因。

1.2               扩展开发的主要工作成果

a)         任务列表User Control

任务列表User Control主要是针对Teamplate提供的TaskList控件的一些不足所做的开发，它在保持原控件功能基础上补充了如下功能：基于用户的区域性动态加载特定的语言资源，目前支持中英文界面、实现了任务列表的过滤功能、实现了流程管理员/发起人/参与人对流程的监控、在任务列表中显示定制的业务数据、对各种角色的权限进行控制、并且扩展了用户对Teamplate用户视图的定制功能。

User Control的应用说明：

TaskList User Control 的属性列表：

属性名称	属性类型	属性说明
SessionToken	string	用户Token，可以不设置
ViewType	string	视图类型具体说明参考下文
ShowTaskProperties	bool	是否显示任务属性按钮
ShowViewProperties	bool	是否显示视图属性按钮
ShowProcessColumn	bool	是否显示列表中的Process列
ShowFormNoColumn	bool	是否显示列表中的Process列
…	bool	可以定义列表中的每一列是否显示
ShowDueDateColumn	bool	是否显示列表中的Process列
ShowDetailColumn	bool	是否显示列表中的Detail列
DetailColumnTitle	string	定制Detail列标题
ShowFilter	bool	是否显示过滤框
PageSize	int	列表中每页显示记录条数

ViewType (视图类型)说明：

值	对应视图
1	Inbox(待办任务)
2	Outbox（已办任务）
3	Overdue（过期任务）
4	Urgent（紧急任务）
5	其它自定义视图
…	其它自定义视图

Sample：采购模块的任务列表

<uc1:TaskListCtrl id=TaskListCtrl1 ViewType="6" PageSize=10 ShowCategoryColumn=false ShowCompletionDateColumn=false ShowDetailColumn=true DetailColumnTitle="Supplier" runat="server"></uc1:TaskListCtrl>

b)        审批控件User Control

审批控件主要功能包括：审批要素和日志的保存、审批日志的显示等功能；

Approve User Control的属性列表：

属性名称	属性类型	属性说明
CurrentUser	string	当前登录用户，必须设置
PID	Int	任务ProcessID，必须设置
TID	Int	任务TaskID，必须设置
IsResponsibl	bool	是否任务的责任人，只读
IsApproveTask	bool	是否审批任务，必须设置
IsReady	bool	任务状态是否为Ready，只读

审批控件的补充说明：审批控件根据IsResponsibl、IsApproveTask、IsReady三个属性判断是否显示审批的四个要素，只有当当前用户又是责任人，又是一个审批任务，并且当前状态又为Ready时，审批控件才可以审批，否则只显示审批日志供用户查看。