之前在講課的時候，介紹到SharePoint 2013工作流的時候會做一個例子——通過調用一個REST服務來獲取某個城市的天氣預報信息。
其實這個例子是來自SPC（SharePoint Conference） 2012的，在此整理一下。
首先簡單的回顧一下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都一樣，最后的效果：
