SharePoint工作流解决方案QuickFlow系列(5)—会签（MultiTask and GroupTask）

xiaodouya33

　　会签可能会有很多解释或定义，本文讲的会签是指在一个流程中的某一步操作有多个用户同时参与，这些用户的操作界面一般是一样的。
　　QuickFlow的会签是通过MultiTask实现的，MultiTask实现了多个任务同时分配的逻辑，它具有以下控制属性：

　　1）ExecutionType--指定任务的分配是串行还是并行，如果是串行，则上一个用户完成任务后才会给下一个用户分配任务，如果是并行，则所有任务同时分配。
　　2）CompletionMode--任务的完成模式，可以为RequireOne和RequireAll，如果RequireOne,则无论这一步分配了几个任务，只要一个用户完成，步骤即结束，未完成的任务会被自动取消，如果是RequireAll，并且没有指定CompleteRule，则要求所有用户都完成任务。
　　3）CompleteRule--CompleteRule是一个Condition类型的属性，可以为CodeConditon或DeclareRuleConditon。当CompletionMode为RequireAll时，可以利用CompleteRule进一步控制审批步骤何时结束。我们经常碰到的如下的业务场景：当多个人参与审批，所有人都同意则到下一步，如果只要有一个用户不同意，则流程退回或结束，即使其他用户还没有审批。这种情况即可利用CompleteRule。
　　下面看一个示例：
　　流程很简单，第一步多人会签审批，如果有一人不同意则结束流程，如果所有人都同意则到经理审批。
　　Step1）画出如下的流程图
　　其中“开始”节点对应Start活动，“会签审批”对应MultiTask活动，“经理审批”对应Task活动，“结束”对应End活动。

　　注意：如果你已经画好了流程图中的线，然后改了活动的名字，可能需要将画好的线删掉重新画线，不然会出现活动找不到错误。
　　Step2）处理“会签审批”
　　指定会签审批的CompletionMode为RequireAll，ExecutionType为Parallel。
　　将“会签审批”的TaskOutcomes属性绑定到工作流的字段：

　　处理“会签审批”的Initialized事件：
　　private void 会签审批_Initialized(object sender, EventArgs e)
       {
           this.会签审批.Users.Add("dc\\user1");
           this.会签审批.Users.Add("dc\\user2");
           this.会签审批.Users.Add("dc\\user3");
           //如果是串行分配任务，这里的顺序就决定了任务分配的顺序
       }
　　设置“会签审批”的CompleteRule：

　　说明：只要有一个人的审批结果是Reject，则此条件为true。
　　Step3）设置“会签审批”后的路由判断
　　设置decision的Conditon为code conditon：
　　private void allAgree(object sender, ConditionalEventArgs e)
       {
           e.Result = this.会签审批.TaskOutcomes.Filter("Reject") == 0; //没有reject的
       }
　　Step4） 处理“经理审批”，设置其TaskCreating事件：
　　private void managerTaskCreating(object sender, QuickFlow.TaskEventArgs e)
       {
           e.TaskProperties.AssignedTo = "dc\\manager";
       }
　　完成！
　　
　　关于GroupTask
　　每次使用MulitiTask时都要写代码指定审批人，这是一个不好的习惯，通常，审批人可以按照某些规则来获取，比如来自SharePoint组，来自AD组，来自第三方的角色管理系统，很显然我们应该将这些常用的用户获取逻辑做个封装。
　　GroupTask继承于MultiTask，它的代码很简单，只是在MultiTask的Initialized事件中将用户从某个组中取出来添加到Users集合中，这样，如果我们要将任务分配给SharePoint用户组中的用户，直接用GroupTask，设置一下它的Group属性即可：
　　//GroupTask获取用户的代码
　　void GroupTask_Initialized(object sender, EventArgs e)
        {
　　if (this.WorkflowProperties == null)
                throw new Exception("WorkflowProperties is null , please bind it to correct field");
　　SPRoleUserProvider up = new SPRoleUserProvider();
　　IList<User> users = null;
            try
            {
                if (this.DeptInherits)
                {
                    User user = up.GetUser( this.WorkflowProperties.Web , this.WorkflowProperties.Originator);
                    users = up.GetRoleUsers( this.WorkflowProperties.Web, this.Group,user.Department );
                }
                else
                {
                    users = up.GetRoleUsers(this.WorkflowProperties.Web, this.Group);
                }
            }
            catch (Exception ex)
            {
                ActivityUtil.Log(this, SPWorkflowHistoryEventType.WorkflowError, null, "获取组用户出错[" + this.Group + "]", ex.Message);
                throw ex;
            }
　　foreach (User u in users)
            {
                this.Users.Add(u.LoginName);
            }
        }
　　GroupTask有个DeptInherit属性，这个是来做什么的呢？
　　假设有一步审批是&#8220;部门经理审批&#8221;，而这个公司是一个有多个部门的大公司，每个提交人发起的审批，都需要&#8220;他所在的部门的经理&#8221;进行审批，如何实现？
一种方式是将部门经理作为用户的AD属性，在AD中进行维护，那么只要用Task活动，写代码从用户的AD属性中获取即可，这种方式的一个缺点是维护工作量太大了。
　　还有个简单的方式：在网站建个部门经理的组，SharePoing中每个用户都有个&#8220;部门&#8221;属性，提交人和&#8220;本部门经理&#8221;的部门属性一定是一样的，那么用提交人的部门属性从部门经理组中进行一下过滤，即可取到&#8220;本部门经理&#8221;，当DeptInerit设置为true时，GroupTask即会进行这个操作。当然这个方法要求AD中用户的&#8220;部门&#8221;属性一定要维护正确，然后正确同步到UserProfile中（AD中维护后1小时）。
　　这两种方法是不开发专门的&#8220;用户角色管理系统&#8221;的前提下的，如果您有完善的角色管理系统，可能实现的就更&#8220;优美&#8221;了。
　　
　　用过K2的朋友可以比较下，这个MultiTask和GroupTask跟K2的ClientEvent是很类似的。
　　
　　示例代码下载：
　　http://files.cnblogs.com/jianyi0115/QuickFlowExample_%E4%BC%9A%E7%AD%BE.zip
　　注意：此代码并没有经过测试，只能作为参考。