在1月16日的“SharePoint 2010 Day”活动中,我奉献了一节《SharePoint 2010:新一代无代码工作流》讲座,会后Choral兄让我把它拆成几篇日志,于是就有了本文(本文是当天课程去掉Demo之后再添油加醋的图文重现版)。
我们知道,工作流是真实世界中流程的抽象,在真实世界中,流程可以按照有没有人类参与来泛泛地分为两种:系统流程和人类交互流程。
系统流程是指那些没有(或者几乎没有)人类参与的流程,这种流程的执行过程早在设计阶段就能够完全预料,虽然某些情况下也可能会有少量的人类参与,但并不会左右流程的执行方向。
系统流程主要旨在解决系统以及数据之间的问题,我们可以把它视为服务或者过程。正因为系统流程如此简单,所以在SharePoint中有许多方式可以实现系统流程,比如Event Handler、Timer Job或者Console Application;也正因为系统流程如此简单,我们在面对一个需要实现的系统流程时,甚至不会(或者忘记了)将它与“工作流”这个看似高深的概念联系到一起。
而人类交互流程,既有人类参与的流程,才是我们最容易联想到“工作流”这个概念的流程。环顾我们生活的四周,人类交互流程无处不在。把真实世界中的流程抽象为数字化的工作流时,我们虽然能够尽可能多地处理每一种可能发生的情况,却很难知道工作流将来究竟会沿着怎样的路线执行。
人类交互使得工作流变得复杂,在SharePoint中,我们大多使用Visual Studio来实现人类交互流程,这是因为在SharePoint 2007时代,SharePoint Designer的工作流设计能力还不足以应付复杂的人类交互流程;而在SharePoint 2010时代,SharePoint Designer虽然仍旧不能设计可以循环回退的工作流(哦,这真是个令人沮丧的消息),但其大量新特性势必会让我们设计人类交互流程(或者系统流程)时更加得心应手,并且我们也可以看到,SharePoint Designer的工作流功能也一直在向着这个方向努力。
SharePoint 2007第一次引入了“工作流”这个概念。在SharePoint 2007中,工作流是基于Windows Workflow Foundation 3.0/3.5来构建的。SharePoint 2007内置了一些工作流来供我们使用,比如“审批”和“收集反馈”,但我们只能选择用或者不用,而不能修改这些内置工作流。除了内置的工作流之外,SharePoint 2007还允许我们使用SharePoint Designer 2007来设计无代码的工作流,或者使用Visual Studio 2005/2008来开发包含代码的工作流。
在SharePoint 2010中,工作流的底层基础结构依然是Windows Workflow Foundation 3.5(很遗憾没能够基于WF 4.0)。代码工作流的开发工具升级到了Visual Studio 2010,无代码工作流的设计工具也升级到了SharePoint Designer 2010。
SharePoint 2010将Office的一个重要的客户端成员,Visio,引入了工作流创作之中。众所周之,Visio是一个非常强大并且易用的图表设计工具,在SharePoint 2007时代,就有许多人在问“为什么不能用Visio来设计SharePoint工作流”这样的问题,因为用Visio可以很方便地设计出直观的流程图,相比而言,SharePoint Designer的工作流设计器却并不是那么令人满意。
我们可以在上图中发现,Visio和SharePoint Designer总是结伴出现,这是以为Visio只是一个工作流建模工具,它的作用只是帮助业务人员很方便直观的“画”出工作流流程图,这张流程图里只有简单的逻辑,而且没有包含任何数据,所以它必须经过SharePoint Designer补充加工之后才可以变成真正可以运行的SharePoint工作流。
除此之外,我们还可以使用Visio 2010和SharePoint Designer 2010来编辑SharePoint 2010的内置工作流(这种编辑并不是严格意义上的“编辑”,而是“复制并编辑”),对我们来说,这个功能不仅能够让我们修改内置工作流以满足我们的需求,也能够通过查看内置工作流的组成来学习如何用SharePoint Designer来无代码工作流。
在SharePoint 2007时代,工作流必须和列表或文档库做关联(或者绑定)之后才能够使用,这种工作流是一种列表级的工作流,在SharePoint 2010中,它被称为“列表工作流”。众所周知,列表工作流最为人所诟病的就是它难以重用,在使用SharePoint Designer设计列表工作流时,第一步便是选择需要关联的列表,并且工作流在设计完成之后,是无法将它复制到其他列表去使用的。
针对这个问题,SharePoint引入了一种新的工作流类型:可重用工作流。可重用本质上还是一种列表级的工作流,依然需要和列表做关联之后才可以使用,但我们在使用SharePoint Designer 2010来设计可重用工作流时,无需事先选择将要关联的列表,在工作流设计完成后,我们可以自由地将它关联到多个列表,甚至导出为一个WSP文件来部署到其他服务器之上。SharePoint 2010内置的几个工作流就是一种特殊的可重用工作流:全局可重用工作流,既可以在整个网站集的所有网站中重用的工作流,SharePoint Designer 2010可以让我们轻松地将一个普通的可重用工作流提升为全局可重用工作流。
除了必须和列表相关联之外,列表级工作流还有一个特点,就是必须基于一个列表项来启动。所以有些时候,我们为了使用一些系统流程,或者在流程执行期间才创建列表项的工作流,就不得不去准备一个无意义的列表,并且去创建一个无意义的列表项,只是为了启动一个工作流,无论从设计方式还是用户体验来说,这都不是一个令人满意的解决方案。SharePoint 2010中新增加的“网站工作流”则可以解决这个问题,顾名思义,网站工作流是一种网站级别的工作流,它不需要和列表做关联,也不需要基于一个存在的列表项来启动。如果需要启动一个网站工作流,可以直接在网站的【网站操作】【网站工作流】中进行操作。
由于Visio的引入,SharePoint 2010便有了三个工作流创作工具。其中,Visio凭借其易用直观的设计方式,为业务人员提供了设计工作流流程图的良好用户体验。业务人员在Visio中设计好工作流流程图之后,将其导出成为一个VWI文件,交给IT人员,IT人员再将其导入到SharePoint Designer中,补充逻辑和数据,使其成为一个可以运行的工作流。在这期间,由于各自领域和所用软件的差异,业务人员可能要与IT人员进行多次沟通。
如果在将来的某一天,无代码工作流已经无法满足我们的需求,IT人员就可以将其导出成为一个WSP文件,交给开发人员,开发人员再将其导入到Visual Studio中进行二次开发,经过这样一个过程之后,无代码工作流就变成了代码工作流。
此外,开发人员还可以使用Visual Studio 2010来为SharePoint Designer开发自定义操作,来丰富和补充SharePoint Designer的操作库。
以上便是我在“SharePoint 2010 Day”活动中奉献的讲座:《SharePoint 2010:新一代无代码工作流》的部分内容,本文略去了讲座中对于SharePoint Designer 2010新增的“自定义任务”的生命周期的相关介绍,以及关于网站工作流、可重用工作流、Infopath协同、Visio协同以及工作流状态图的相关Demo。如果时间和精力允许,我会将它们单独成文。
另外,感谢这次报名参加“SharePoint 2010 Day”活动的所有朋友,《SharePoint 2010:新一代无代码工作流》的PPT可以点击这里下载,此次活动的所有PPT可以访问这里获取。