按照正常的想法，SharePoint的任务列表也是一个SPList，所以我们会这样尝试：

SPSite site = new SPSite("http://windstyle");
SPWeb web = site.OpenWeb();
web.AllowUnsafeUpdates = true;
SPList taskList = web.Lists["任务"];
SPListItem task = taskList.Items[0];
task["状态"] = "已完成";
task["Completed"] = true;
task.Update();
web.AllowUnsafeUpdates = false;

执行之后，发现任务确实已经被设置为已完成状态，但工作流却没有继续执行，也就是说，工作流的OnTaskChanged活动并没有捕捉到任务被更改的事件。

其实SharePoint对象模型提供了更改工作流任务属性的方法，即SPWorkflowTask.AlterTask，此方法不仅能够更改工作流任务的属性，还会将这一更改通知相应的工作流，使得相应的工作流能够继续执行。

此方法的用法也很简单：

SPSite site = new SPSite("http://windstyle");
SPWeb web = site.OpenWeb();
SPList doclib = web.Lists["共享文档"];
SPListItem doc = doclib.Items[0];
SPWorkflowTaskCollection tasks = doc.Workflows[doc.Workflows.Count-1].Tasks; //找到具体的SPWorkflowTask
Hashtable ht = new Hashtable();
ht.Add(SPBuiltInFieldId.FormData, SPWorkflowStatus.Completed);
ht.Add(SPBuiltInFieldId.Completed, true); //将任务设置为完成状态
ht.Add(SPBuiltInFieldId.TaskStatus, "已完成");//将任务在任务列表中的显示状态设置为“已完成”
ht.Add(SPBuiltInFieldId.PercentComplete, 1); //将任务在任务列表中的完成百分比设置为“100%”
ht.Add(SPBuiltInFieldId.WorkflowOutcome, "Some output infomation"); //设置任务的输出消息，等同于使用Visual Studio设计工作流 时，CompleteWorkflow活动的TaskOutput属性
SPWorkflowTask.AlterTask(tasks[0], ht, true);

从上段代码可以看出，以编程的方式来完成任务并不困难，其中比较麻烦的是如何找到正确的工作流任务。因为SPListItem.Workflows可能包含不止一个SPWorkflow，这些 SPWorkflow可能源于同一个SPWorkflowTemplate，也可能源于不同的SPWorkflowTemplate。而且还可能包含源于同一个SPWorkflowTemplate的多个SPWorkflow，当然，我们知道，同一个工作流模板在同一个SPListItem上只能启动一个工作流实例，所以这些SPWorkflow中只有一个的IsCompleted属性为true。

所以在编写代码来完成工作流任务时，注意获取到正确的工作流任务，然后就可以轻松的完成任务了。

我们虽然将任务分配给了某人,但事实上,所有在任务列表中有编辑权限的用户都可以编辑该任务.

而我们并不希望用户能够看到不属于自己的任务.

我曾经尝试过采用以下两种方法解决这一问题,未果.

1.更改任务列表的视图.

1. 通常我们会把工作流任务分配给某人或者某组,所以我的想法是将任务列表的”我的任务”视图和”按我的用户组”视图合并为一个新的”所有我的任务”视图;
2. 设置”所有我的任务”视图为默认视图;
3. 删除其余视图;
4. 取消用户创建视图的权限;

看起来不错,但是我连第一步都没能实现.

2.定制一个EventHandler

记得园子里的一个朋友写过一篇通过开发EventHandler来控制工作流权限的文章.

思路是为任务列表定制一个EventHandler,使任务列表在增加项目时可以自动更改该项目的权限.

通过定制EventHandler确实可以实现任务的权限分配,但是会引发另外的问题,譬如说,我的工作流中用OnTaskChanged活动来捕捉任务的变更.但是因为在任务创建之后EventHandler马上对其进行权限修改,所以导致工作流会发生一个小小的错误.

不过奇怪的是,虽然在文档库中显示该工作流发生了错误,但事实上流转还是正常的.

我一直固执的认为任务列表的权限应该是在MOSS中配置,而不应该在工作流内部做判断,后来,我终于发现我错了.

我们使用CreateTask活动来创建任务,CreateTask活动有一个HybridDictionary类型的属性叫做SpecialPermissions.

这个属性表示该任务的”特别权限”,如果指定了”特别权限”,那么创建的任务就不再继承任务列表的权限了.所以我们可以在创建任务之前为其指定这个”特别权限”.

1.新建一个全局的Contact对象用来存储分配对象

Contact assignee = default(Contact);

2.在onWorkflowActivated的Invoked事件中从初始化表单中获取assignee对象

assignee = Contact.FromName(init.contact[0].DisplayName, workflowProperties.Web);

3.在属性面板中将createTask的SpecialPermissions属性绑定到新的specialPermissions对象

4.编写createTask的MethodInvoking方法

private void createTask1_MethodInvoking(object sender, EventArgs e)
{
taskId = Guid.NewGuid();
taskProperties.AssignedTo = assignee.LoginName;
//判断分配对象是否用户
if (assignee.IsSPUser)
{
//为其添加"参与讨论"的权限.
specialPermissions.Add(assignee.LoginName, SPRoleType.Contributor);
}

//判断分配对象是否用户组
if(assignee.IsCollection)
{
try
{
SPGroup group = workflowProperties.Web.Groups[assignee.DisplayName];
//为组内每一个用户添加"参与讨论"的权限.
foreach (SPUser user in group.Users)
{
specialPermissions.Add(user.LoginName, SPRoleType.Contributor);
}
}
catch { }
}
}

因为默认的”参与讨论”权限就可以编辑工作流任务,所以为任务指定了”特别权限”之后,该任务将对不在SpecialPermissions中的用户不可见,这正是我们所需要的.

首先在OnWorkflowActivated方法中设置断点来调试,检查断点是否可以成功暂停,如果可以,则可以再检查一下OnWorkflowActivated中的逻辑代码.

如果断点处不停止就出现了”启动时失败”的错误,也就是说错误发生在工作流激活之前,这种情况就可以排除代码的错误,检查infopath表单和workflow.xml即可.

infopath表单的配置较为麻烦,甚至连命名都是有规则的,需要多加注意.

另外,如果工作流包含关联表单(Association),那么初始化表单(Instantiation)中必须包含关联表单中定义的域.

如果还是找不出错误的来源,那么,记住工作流启动时的时间,检查SharePoint日志吧.日志的目录是:$:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS

最后再引用一句Kaneboy的签名:

“玩SharePoint就像是魔术,你不知道它为什么工作,也不知道它为什么不工作.”

02/06/2007 10:31:03.92         w3wp.exe (0×0758)       

0x0F3C        Windows SharePoint Services         Workflow Infrastructure         72eo        Unexpected        

DehydrateInstance: System.Runtime.Serialization.SerializationException: 在分析完成之前就遇到流结尾。

在 System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()

在 System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)

在 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)

在 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream)

在 System.Workflow.ComponentModel.Activity.Load(Stream stream, Activity outerActivity, IFormatter formatter)…        

02/06/2007 10:31:03.92*        w3wp.exe (0×0758)         

0x0F3C        Windows SharePoint Services         Workflow Infrastructure         72eo        Unexpected        …

在 System.Workflow.ComponentModel.Activity.Load(Stream stream, Activity outerActivity)

在 System.Workflow.Runtime.Hosting.WorkflowPersistenceService.RestoreFromDefaultSerializedForm(Byte[] activityBytes, Activity outerActivity)

在 Microsoft.SharePoint.Workflow.SPWinOePersistenceService.LoadWorkflowInstanceState(Guid instanceId)

在 System.Workflow.Runtime.WorkflowRuntime.InitializeExecutor(Guid instanceId, CreationContext context, WorkflowExecutor executor, WorkflowInstance workflowInstance)

在 System.Workflow.Runtime.WorkflowRuntime.Load(Guid key, CreationContext context, WorkflowInstance workflowInstance) 在 System.Workflow.Runtime.WorkflowRuntime.GetWorkflow(Guid instanceId)

在 Microsoft.SharePoint.Workflow.SPWinOeHostServices.DehydrateInstance(SPWorkflowInstance wo…        

02/06/2007 10:31:03.92*        w3wp.exe (0×0758)         

0x0F3C        Windows SharePoint Services         Workflow Infrastructure         72eo        Unexpected        …rkflow)

02/06/2007 10:31:03.93         w3wp.exe (0×0758)         

0x0F3C        Windows SharePoint Services         Workflow Infrastructure         88xr        Unexpected        WinWF Internal Error, terminating workflow Id# 472dae03-5465-4f04-876f-d4cc4caa902a

看里边最长的一段中文描述：“在分析完成之前就遇到流结尾”，如果是SharePoint英文版,这段错误信息应该是“End of Stream encountered before parsing was completed”。

也就是说Workflow Runtime根本就没有完整的分析完整个流程。

再看这句中文之前的英文：“DehydrateInstance: System.Runtime.Serialization.SerializationException”。

原来工作流是在钝化实例的时候发生了序列化异常。

回想一下工作流的持久性，Workflow Runtime会把空闲的工作流数据序列化为XML形式，然后把工作流实例从内存中清除，等到需要的时候再将其反序列化加载到内存。

会不会是因为我在工作流项目中添加了自定义类，而这个类又不支持序列化，所以导致工作流序列化失败？

在工作流中使用InfoPath Initiation（或者Association）表单时需要为其生成一个类，观察这个类，发现这个用XSD生成的类有如下特性来修饰：

[System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true)]
[System.Xml.Serialization.XmlRootAttribute(Namespace="http://schemas.microsoft.com/office/infopath/2003/myXSD/2007-01-30T13:00:28", IsNullable=false)]

下面来逐行分析一下:

[System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42")]

表示这个类是由XSD工具生成的.

[System.SerializableAttribute()]

表示这个类可以被序列化，我想关键就在这里

[System.Diagnostics.DebuggerStepThroughAttribute()]

表示调试器会自动忽略被修饰的类内部的断点

[System.ComponentModel.DesignerCategoryAttribute("code")]

表示设计器的类别是“code”

[System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true)]

表示系列化时生成的XSD架构是匿名类型

[System.Xml.Serialization.XmlRootAttribute(Namespace="http://schemas.microsoft.com/office/infopath/2003/myXSD/2007-01-30T13:00:28", IsNullable=false)]

设置序列化时根元素的命名空间

删去或修改我们不需要的特性（比如第一项），将其插入到我们的自定义类中，工作流就正常了。

其实只需要将自定义类标识为[Serializable]即可。

其实不仅是自定义类，只要是在工作流类中的类级别变量，都必须实现了ISerializable的，而方法内的局部变量则可以不支持序列化。否则工作流在 进行钝化是无法序列化某些变量，也会导致这个错误。比如在工作流累中定义了一个XmlDocument，就会发生此错误。

2008.12.25最后更新

可不可以把这些工作都集成到Visual Studio.net 2005 IDE中呢?答案是肯定的,利用VS.net 2005 IDE的外部工具功能,就可以轻松实现.

方法

点击工具菜单下的外部工具,将会弹出来一个非常容易理解的外部工具对话框,在这里可以进行外部工具的添加,删除和修改以及排序的工作.

下面来说明一下怎样利用外部工具更方便的开发工作流吧.

生成GUID

在配置Feature.xml和Workflow.xml的时候,需要为这两个文件配置不同的GUID ,VS.net自带了一个生成GUID的小工具GUIDGEN并默认的把它添加到外部工具中,如果你像我一样发现并没有这个外部工具的话,打开外部工具对话框,填入以下信息:

*如果你再次像我一样在初始目录中没有找到GUIDGEN.exe的话,你可以到微软的下载中心去下载(为什么我如此不幸?).

生成表单模板类文件

如果你的工作流中用到了InfoPath表单模板,而且需要为此表单模板生成类文件的话(比如要获取关联表单中的值),你可以添加一个这样的外部工具:

使用时,会弹出一个对话框,在参数栏的”\之间填入包含模板架构文件(.xsd)的目录路径即可.

如:”c:\tempdir\myschema.xsd” /c /o:$(ProjectDir)

(其中粗体字就是自己添加的目录路径)

安装工作流

只要配置好了Install.bat文件,直接调用此外部工具即可完成安装,而且可以在输出窗口中查看进度信息.

外部工具还有很多很有帮助的应用场景,就看你能不能想得出了.

参考资料

<<Walkthrough: Creating Office SharePoint Server 2007 Workflows in Visual Studio 2005 >>

准备

1. HelloWorldSequential的开发环境如下，请确保您的开发环境与此相同或相兼容:

• 已部署好的可用的SharePoint Server 2007
• .Net Framework 3.0（下载）
• Visual Studio 2005 Extensions for Windows Workflow Foundation （下载）
• ECM starter kit for Visual Studio 2005（下载）
• Office InfoPath 2007 RTM 中文版

1. 安装ECM starter kit之后如果出现项目模板丢失的情况请参考我的另外一篇文章<< Visual Studio.net 2005 新建项目对话框中项目模版消失的解决方案>>
2. 添加SharePoint Workflow Actions到工具箱时选择Microsoft.SharePoint.WorkflowActions命名空间下的控件.

Visual Studio项目

1. 项目模板是SharePoint Server 下的 SharePoint Sequential Workflow Library.
2. 添加并配置工作流活动时请注意所有活动都有一个Correlation Token属性,值得注意的是工作流本身(Workflow),任务(Task)和修改(Modification)需要不同的Correlation Token.
3. 创建强命名的程序集,因为您的程序集是要加入GAC的.

InfoPath表单

1. 创建空白表单模板时要勾选仅启用浏览器兼容性功能.
2. 在表单选项的安全和信任中,将表单的信任级别设置为域或者完全信任.
3. 用于设置接收参数的xml文件中,接受参数总是以”ows_”开头.
4. 修改组的名称,组的名称默认是MyFields,如果您想要为此表单生成类文件,那么类的名字就是组的名字,所以建议修改默认的名称(尤其当您的工作流项目中包含多张需要生成类文件的表单时).
5. 为简单起见,将表单发布到项目文件夹内,否则在部署时需要特别注意.
6. 发布表单时将可访问路径留空,否则安装工作流时会失败

部署

1. Feature.xml和Workflow.xml可以用插入代码段(Snippet)的方法生成内容,如果您发现您没有相关的代码段,请参照我的另外一篇文章<< Visual Studio 2005中代码段丢失的解决方案>>.
2. Feature的ID和Workflow的ID是两个不同的GUID.
3. Install.bat文件中, 请用可以作为文件夹名称的字符串来替换MyFeature,最好不要包含空格,否则需要手动将Install.bat文件中的路径前后加引号.

调试

1. 更改了Feature.xml,Workflow.xml和表单文件之后需要重新安装工作流并重启IIS.
2. 如果只是更改了程序集,只需要用新的程序集替换旧的,然后重启IIS就可以了.

1. 模板(Template),关联(Association)和实例(Instance)模板:部署到站点集中的工作流功能(Feature),用来描述该功能所包含的程序集和表单等信息.关联:将工作流模板与列表(List)或者内容类型(Content Type)联系起来,并向工作流提供初始值或参数.对应的表单叫做Association.实例:在列表或内容类型项上启动的工作流.对应的表单叫做Initiation.

   也就是说,实例是基于关联的,而关联又是基于模板的.一个列表或者内容类型可以拥有许多来自相同工作流模板的关联,但同一时刻同一关联只能启动一个工作流实例.

2. 钝化(Dehydrated)钝化指将工作流序列化(Serialized)并保存在数据库中.钝化后的工作流将从内存中清除.当工作流等待的事件发生时,工作流将反序列化(Deserialized)并被唤醒,然后继续它的流程.事务性动作(Transacted Action)和批处理动作(Batched Action)直到工作流钝化后才会提交.例如,CreateTask并没有马上创建任务,而是等到OnTaskChanged将工作流钝化之后才创建任务.所以在创建任务之后马上访问任务是错误的.
3. Method 和 Event HandleMethod用来执行动作,例如CreateTask就是一个Method活动.Event Handle用来将工作流钝化,然后等待一定的事件被触发后唤醒工作流,例如OnTaskChanged就是一个Event Handle活动.Method的Method Invoking在Method要执行的动作之前执行,而Event Handle的Method Invoking却在Event Handle的事件触发之后执行.
4. Correlation Token将若干相关联的活动映射到同一集合的标识符,例如给CreateTask,OnTaskChanged和CompleteTask指定相同的Correlation Token,则这几个活动被关联到同一个任务.在SharePoint Workflow Actions中,Correlation Token大致按照下表来分组指定:
   

   工作流	任务	修改
   OnWorkflowActivated   OnWorkflowItemChanged OhWorkflowItemDeleted  SetState SendEmail UpdateAllTasks	CreateTask   CreateTaskWithContentType UpdateTask DeleteTask CompleteTask RollbackTask OnTaskChanged OnTaskDeleted OnTaskCreated	EnableWorkflowModification   OnWorkflowModified

5. InfoPath表单

   表单类型	宿主ASPX	需要执行的动作	Event Handle	接收数据的属性
   Association	CstWrkflIP.aspx	建立工作流模板和列表(或者内容类型)之间的关联	无	无
   Initiation	IniWrkflIP.aspx	启动工作流实例	OnWorkflow Activated	SPWorkflowActivationProperty.InitiationData
   Task	WrkTaskIP.aspx	更改了任务	OnTaskChanged	OnTaskChanged.AfterProperties
   Modification	ModWrkflIP.aspx	修改工作流	OnWorkflowMosified	OnWorkflowMosified.ContextData

   Association表单不接受数据,也不会存在相应的Event Handler,因为此时工作流实例还没有启动,便没有钝化和唤醒一说,不过Associatin中的数据却可以在SPWorkflowActivationProperty.AssociationData中获取.