SharePoint 2013 工作流连接Web服务/REST服务

首先简单的回顾一下SharePoint和工作流的历史：

在SharePoint 2007之前，SharePoint本身只能借助一些第三方产品实现一些工作流的应用；

SharePoint从2007版本开始支持内置的工作流，这完全得益于.Net Framework 3.0中增加的Workflow Foundation；

2010的时候，因为整个SharePoint没有赶上.Net 4.0的发布，还是3.5版本（本质上和3.0没什么区别），所以在工作流这个功能中并没有太突出的改进。

SharePoint 2007 / 2010中的工作流，根据WF 3.0的特点，分为顺序工作流和状态机工作流两种；开发工具分为SPD（SharePoint Designer）和VS（Visual Studio），当然更严格一点划分的话，2010中从内置工作流到VS开发工作流可以分成5个不同的层面（完全是用内置工作流、用SPD修改内置工作流、使用SPD工作流、使用SPD工作流+自定义开发的Activity、使用VS开发工作流）。其中SPD作为一个无代码开发工具，可以作一些简单流程（虽然是无代码，但是其实这个设计过程相当于伪代码编写，还是需要一定的编程思想——至少你要知道什么叫变量），但是其最大的几个弊端：只支持顺序工作流不支持跳转、不支持循环、不支持访问外部数据或者服务，从而极大地限制了SPD工作流的应用场景。而VS工作流虽然功能比较强大，但开发起来却又非常繁琐（一个完整的任务都要分成3个Activity来实现），尤其是VS工作流 + InfoPath表单的时候。

另外，根据SharePoint 2007 / 2010的设计，工作流是宿主在SharePoint本身的进程（也就是IIS的进程）去完成的，所以一旦流程并发量很大的时候，对SharePoint的服务器性能也会造成一定的依赖甚至影响。

所以可以说，在SharePoint 2010及其之前的时代，工作流一直是整个产品的一个短板，因此也就催生了无数第三方的SharePoint工作流产品，包括国外鼎鼎有名的诸如K2、Nintex这样的产品，也有国内的一些产品（国内某产品完全是Nintex的Copycat，还很喜欢在各种地方留下自己的名字），也有如QuickFlow这样面向开发人员的开发工具。不过从我们做项目的经验来看，不论什么样的产品，在做实际应用的时候，多多少少都会碰到一些坑，需要自己编写一些辅助的周边支持代码，才能满足用户的需求（或者就是用户退而求其次，接受产品的默认性质——这在国内用户中比较少见）。

到了SharePoint 2013的时候，由于依附于.Net Framework 4.5，因此工作流层面也有了非常大的改进：

首先，SharePoint 2013为了兼容以前升级过来的系统，依然支持传统模式的工作流（WF 3.0 模式的），其功能和运行原理完全和2010保持一致性。

其次，2013提供了全新的一套工作流框架，可以完全独立于SharePoint服务器安装，也就意味着如果需要使用2013额外的工作流功能的话，需要单独安装一套工作流的服务器端 / 客户端产品，具体的安装过程可以参考 kaneboy的这篇博客：SharePoint 2013 App 开发 (2) - 建立开发环境。

在这套全新的工作流引擎中，工作流不在宿主于SharePoint进程运行（包括工作流所涉及到的数据库也独立于SharePoint数据库），而是使用了如下图所示的一套框架：

流程引擎和SharePoint之间，完全通过REST调用和事件驱动来实现数据的交互。

在能力上，之前SharePoint Designer工作流的三大短板：跳转、循环、调用外部数据/服务，在这套框架下都得到了支持。

在这套新的框架下，2013工作流本质上利用了WF 4的Flow Chart，实现了一个状态机的方式，同样可以在Visio中进行流程设计：

（图中的蓝方块就是一个个“状态”，可以根据不同的条件进行跳转）。

另外，SharePoint Designer中也支持了两种循环模式：循环N次，或者指定条件循环。

当然，本文的重点还是放在第三项，对外部服务调用的支持。

首先看看一下那个天气预报的服务，这个服务来自http://free.worldweatheronline.com 这个网站，如果需要调用它的服务的话，需要注册一个账号，并免费获取一个API Key。

调用的形式类似：http://free.worldweatheronline.com/feed/weather.ashx?q=Seattle&format=json&num_of_days=1&key=xxxx

所有的参数都通过Url传递，其中q=Seattle，表示查询西雅图的天气；format=json表示返回json格式的数据结果；num_of_days=1表示要获取1天的天气预报；key=xxx就是我们注册后获取的那个API Key。

返回结果类似如下结构：

（这是软件一个JSON查看器，来自http://jsonviewer.codeplex.com/ ）

那个例子所做的功能，就是建立一个列表，让用户输入一个城市名称，然后启动工作流去调用这个服务，传入城市名称，得到返回的结果，并填入列表的其他字段中。

这个列表很简单，只包括下面这几个字段（我是在Office 365上做这个Demo的，懒得切换成中文，大家将就看吧）：

然后启动SPD，打开这个网站，新建一个列表工作流：

可以看到，在平台类型中，默认会选中“SharePoint 2013 工作流”；如果我们是在On-Premise的环境中使用，如果你的环境中正确安装配置了那套新的工作流平台的话，会看到这个选项，否则的话，只有传统的“SharePoint 2010 工作流”。

SPD 2013的基本界面和2010是一致的，我们现在需要做的，就是调用那个Web服务，这时候会用到SPD 2013新提供的一个Activity：调用HTTP Web服务：

插入之后，有如下一些选项：

其中“this”那个地方我们填入Web服务的地址，使用HTTP GET方法，并用列表中的“城市”字段，作为Url中的q参数：

由于这个Web服务是一个非常简单的GET形式的REST协议，除了Url参数外，我们不需要在header或者body传递任何额外的数据，因此那个“request”我们不需要进行设置；获取的时候，因为只是一个Demo，也不需要获取Response Code（比如200表示调用成功之类的）或者Response Header，而只需要得到Response的内容，因此，我们只针对Response本身创建一个变量：

我们之前已经看到了，这个服务的返回结果是一个复杂的JSON，其中包含多层属性、数组等内容，此时，我们就需要用到2013全新增加的“字典（Dictionary）”这样一个变量类型——专门用于描述这种复杂的数据结构。

接下来的事情，就是从整个结果中抽取单独的结果并保存在列表条目的字段中。如何从一个复杂结果中抽取一个值呢？我们需要用到2013另一个新的Activity：Get an item from a dictionary（从字典中获取值）：

其中最主要的就是路径，它指明了如何从一个复杂的数据结构中获取某一个值，对于比如“最高温”而言，这个路径是“data/weather(0)/tempMaxC”——如果你去看一下之前某张图中的JSON数据结构的话，就很容易理解这个是怎么来的了。

当然，这个Activity只能把结果存到一个变量中，因此我们可以新建一个变量来保存它：

SPD 2013的另外一个好处，就是支持复制粘贴，因此我们只需要简单的选中并复制一下这个操作，多粘贴几次，进行简单地修改，就能够得到：

随后，把这些变量都更新到当前列表条目中即可（天气图片是个多行文本，我们需要把图片的Url地址加工一下）：

之前说过，SPD 2013默认是一种类似状态机的工作流，所以最后别往了把状态跳转到“结束”：

当然，我们可以把工作流设置为“新建时自动启动”——这个和2007 / 2010都一样，最后的效果：