■使用任務相關的工作流活動
■構建自定義任務編輯表單
在第4章，SharePoint Designer工作流提供了任務處理能力。Visual Studio提供了類似的任務處理能力爲它的工作流。Task-related 活動使Visual Studio工作流能創建任務，刪除任務，和完成任務。他們也有事件活動，你的工作流能使用去人交互例如任務編輯和刪除。通過放入這些活動去使用，你可以創建和分配任務給用戶，並且任務等待完成。
Visual Studio 還支持完整自定義任務編輯表單和自定義InfoPath表單。這些表單能很容易的集成到你的Visual Studio工作流去支持複雜的表單要求或者使你的最終用戶很直觀的使用。當分配編輯任務，默認情況下，認爲開箱即用任務編輯表單和這個表單可能不足。例如，開箱即用表單包含許多字段你可能不需要最終用戶去編輯。這些額外數據可能會給最終用戶造成混亂，建立一個自定義InfoPath表單是可取的。
10.1 使用task-related 活動
除了在SharePoint Designer中創建工作流，Visual Studio工作流提供了類似任務處理的機會。Visual Studio中的多個SharePoint活動幫助管理工作流中的任務。你可以使用這些活動在你的Visual Studio工作流去創建，刪除和更新任務。表10.1顯示任務關聯活動清單。在這一章，並不覆蓋表10.1所有的活動，我們將介紹最常用的活動，如創建和刪除任務和事件交互類似任務修改和刪除。
表10.1
現在你有了所有可用任務活動的清單，讓我們建立一個例子去使用它們。這個例子你將去通過類似Capital Expenditure請求工作流，之前你建立在SharePoint Designer，現在，你將建立它在Visual Studio。這將有助於比較兩個工作流工具。它們不需要創建一個新的請求列表，你將添加第二個工作流到節4.2的列表。開始時，創建一個新的Visual Studio 順序工作流項目標題爲CapitalExpenditureRequests。在項目創建嚮導，輸入包含你的capital expenditure請求列表的網站網址，創建一個新的列表工作流，名字爲Expenditure Requests Approval—VS.Last,關聯新的工作流到capital expenditure request 列表。
第4章示例依賴
注意這個例子是在節4.2建立的，那個節介紹你通過SharePoint Designer建立一個Capital Expenditure Request工作流。如果你不希望回到第4章，創建一個新的自定義列表叫Capital Expenditure Request。添加兩個列到列表，RequestDescription是多行文本字段和Dollar Amount是貨幣類型。有了這個通用的列表你將趕上進度。
如果你記得，在SharePoint Designer請求示例你有兩個動作去檢查工作流項更新或者刪除。只要符合一種情況，你希望工作流停止處理。去設置相同的功能從你的Visual Studio工作流，你可以使用EventHandlingScope活動搭配OnTaskDeleted和OnWorkflowItemChanged活動。EventHandlingScope活動允許你去在活動範圍內的事件觸發交互。你將放入你工作流業務邏輯核心到這個活動。所以每次一個任務刪除，例如，你的EventHandlingScope活動將捕捉事件並執行代碼。按照表10.2的步驟去配置這些事件。
表10.2
圖10.1
現在你的工作流監聽請求更新、取消工作流和刪除任務如果這些發生。如果工作流等待任務的提交和任務被刪除，你想去確認你的工作流不在一個孤立的狀態。在第二個EventDriven活動添加一個新的OnTaskDeleted。
添加和配置SetState和terminate活動像你的第一個EventDriven活動。Correlation toekn爲SetState活動需要設置爲workflowToekn。有某個點在加入DeleteTask活動，因爲通過這個點，它將被刪除。之後，你的第二個EventDriven活動看起來像圖10.2。
圖10.2
現在修改和刪除事件鏈接起來，現在去添加主要業務邏輯到你的工作流。像SharePoint Designer示例，當工作流啓動你想要的任務創建。任務創建之後，你想去等待批准人批准或者拒絕請求。批准或者拒絕之後，你設置工作流狀態到相應狀態。讓我們開始創建任務，並等待它的審批。按照表10.3的步驟去配置工作流部分。
TaskId屬性和OnTaskDeleted活動的CorrelationToken
確保OnTaskDeleted活動上的TaskId屬性是設置爲和DeleteTask活動相同。所有的這些在capital expenditure請求工作流上的活動是工作相同的任務，他們的TaskId屬性也應該是相同的。請注意，correlation Token必須設置爲TaskToken因爲這是用於DeleteTask活動的token。
表10.3
Listing 10.1 createTask1_MethodInvoking
private void createTask1_MethodInvoking(object sender, EventArgs e)
TaskProperties.Title =
onWorkflowActivated1.WorkflowProperties.Item.Title;
TaskProperties.Description =
onWorkflowActivated1.WorkflowProperties.
Item["Request Description"].ToString();
TaskProperties.AssignedTo = "philsdevdomain\\pwicklund";
}
表10.3 續
Listing 10.2 WhileTaskNotComplete
bool taskComplete = false;
{
if (taskComplete)
e.Result = false; // similar to while(0)
else
e.Result = true; // similar to while(1)
}
續表10.3
Listing 10.3 onTaskChanged1_Invoked
private Guid statusColumnId =
private string status = "";
private void onTaskChanged1_Invoked(object sender, ExternalDataEventArgs e)
{
status = AfterProperties.ExtendedProperties [statusColumnId].ToString();
if (status == "Not Started")
taskComplete = false;
else
taskComplete = true;
}
TaskProperties屬性包含許多任務公共字段如Title，DueDate，和Description對於一些默認列像Status和任何自定義列，ExtendedProperties必須使用。ExtendedProperties是一個哈希包含默認列如Status，以及任何自定義列，或者通過一個內容類型。有趣的事情是默認列是輸入在哈希通過一個唯一的ID，他們的GUID,而自定義列是通過他們的列名進入的。
圖10.3顯示如何獲取字段ID通過PowerShell如果你想去檢索默認列從ExtendedProperties屬性的哈希。
圖10.3
有了這些步驟，你的While活動將停止循環，當Status列改變到Not Started。現在你添加ifEsle活動去確定如何設置工作流狀態。如果Status 在任務中是設置爲Approved。設置工作流Status爲Approved。如果任務的狀態是爲Deferred，設置工作流狀態爲Deferred，以此類推。
圖10.4
通過表10.4
配置IfElse活動，以確定Status是否Approved或Deferred
此時，你的工作流已經接近完成。剩下的是填寫SetState活動。在做這個之前，先確認你的工作流設計界面看起來像圖10.5。
圖10.5
爲了和我們之前創建的SharePoint Designer工作流保持一致，我們需要去添加一些SendEmail活動去發送通知。這個活動涵蓋在第八章，我們這裏將跳過。
第一步設置你的自定義工作流Statuses在工作流的Elements.xml文件中的定義。任何的自定義狀態需要在這個XML文件中的MetaData元素中定義。Status外面的子元素我們叫做ExtendedStatusColumnValues，每個狀態都在一個StatusColumnValue標籤中。打開工作流的Elements.xml並定義你的擴展狀態值,看起來像圖10.6。
圖10.6
每一個SetState活動有一個屬性叫State。這是一個整數值確定工作流狀態。這裏有15個狀態，你可以將這些屬性設置1到15，你將設置你的工作流狀態。表10.5顯示這些狀態的當前值對象模型。
表10.5
要設置工作流到你的自定義狀態的某一個，你需要去設置它爲16或者更高。例如，如果你設置它爲16，你需要設置工作流狀態爲Approved。如果你設置它爲19，工作流狀態需要設置爲Canceled。而不是硬編碼一個值，最好的做法是通過代碼。通過代碼，你可以使用SPWorkflowStatus.Max屬性。這將保護你如果微軟不斷變化Max從15到16.要做這一點，配置你的SetState處理類似列表10.4。
Listing 10.4 Handlers for the SetState activities
enum CustomStates
Approved = 0,
Rejected,
Deferred,
Canceled
};
private void setCanceledState_MethodInvoking(object sender, EventArgs e)
{
((SetState)sender).State = (Int32)SPWorkflowStatus.Max +
(Int32)CustomStates.Canceled;
}
private void setApprovedState_MethodInvoking(object sender, EventArgs e)
{
((SetState)sender).State = (Int32)SPWorkflowStatus.Max +
(Int32)CustomStates.Approved;
}
private void setDeferredState_MethodInvoking(object sender, EventArgs e)
{
((SetState)sender).State = (Int32)SPWorkflowStatus.Max +
(Int32)CustomStates.Deferred;
}
private void setRejectedState_MethodInvoking(object sender, EventArgs e)
{
((SetState)sender).State = (Int32)SPWorkflowStatus.Max +
(Int32)CustomStates.Rejected;
}
正如你看到的，你使用了枚舉去設置你的自定義狀態證書。然後在每個處理，你添加Max值到你的枚舉整數值，計算狀態。
圖10.7
10.2 自定義任務編輯表單（Custom task edit forms）
你的Capital Expenditure Request工作流的核心已完成，但是有個問題一直存在。任務編輯表單審批者使用不直觀。只能編輯Status列。這將很容易讓審批者失去自己應該做的軌跡。
表單服務器依賴
本節規定SharePoint服務器版本。SharePoint Foundation不允許Infopath表單部署到表單服務器。
圖10.8
在這一點上，你可能想，“爲什麼不自定義像第8章的開箱即用表單".雖然這是一個選項，大多數工作流是可重用的在他們被部署到更大的區域。而自定義開箱即用任務編輯表單需要一次又一次的建立，自定義表單你將建立它一次。
跳到Visual Studio項目之前，你需要做一些指定的事情爲這個InfoPath表單工作。注意在圖10.8兩個主要需求，顯示capital expenditure request titile和description，顯示三個按鈕，每個接受的狀態。
由於在設計時，InfoPath不知道關聯列表，你不能直接在表單上添加SharePoint數據。SharePoint自定發送表單項數據到Infopath表單當表單加載。所有你需要去做的是告訴InfoPath表單要獲取什麼數據。要做到這點，你需要去設置一個二級數據源指向到一個XML文件標題爲ItemsMetadata.xml。按照表10.6的步驟設置。
表10.6
當你的二級數據源創建，你可以添加控件到表單上讀取數據。添加兩個新控件到表單上，一個叫Title，另一個叫Description。對於Title的文本框，右擊並選擇更改綁定。選擇ItemMetadata從數據源下拉列表，選擇ows_Title字段。同樣的事情做Description，除了選擇的是ows_ Body字段。有了這兩個文本康到位，當你的表單加載，它將拉出title和description數據，並寄放他們到這些字段。這將幫助審批者知道他們是否應該審批請求或者不審批。最後，配置三個按鈕。然後，你將可以準備去發佈。按照表10.7的步驟配置提交按鈕。
表10.7
你已經準備好發佈你的表單。保存表單併發布它到網絡位置。當你發佈時，確保安全級別設置爲域。
現在，讓我們參與這個發佈表單到你的Visual Studio工作流。對於更多的詳細演練，請參見9.3節。按照表10.8的步驟去告訴工作流去使用你的自定義表單，而不是開箱即用的表單。
表10.8
圖10.9
TaskProperties.TaskType
TaskType屬性讓你創建多種類型的任務，並且能每個類型的任務關聯不同的表單。注意工作流的Elements.xml文件中的Task0_FormURN元素的零。零在元素名相對應任務的TaskType屬性。TaskType屬性設置爲零去通知工作流使用表單零當任務被編輯時。 這是很有幫助的當你創建兩個任務，一個是正常的審批者，另外一個是CEO。CEO的需要看到不同的表單當他們審批請求。在這種情況下，正常審批者能獲取任務類型零，CEO能獲取另一個任務類型，他們都有自己的FormURN在elements.xml。
在你部署之前，你需要去做之後一件事情-更新你的OnTaskChanged活動。如果你記得，改活動是查找當前任務的Status列。現在，在你的自定義任務編輯表單，你不在去查找Status列，而是在InfoPath表單數據的ApprovalStatus字段當這個表單提交。進入OnTaskChanged事件處理，確認代碼是引用ApprovalStatus列如列表10.5
Listing 10.5 onTaskChanged1_Invoked
private string status = "";
e)
{
status = AfterProperties.ExtendedProperties
["ApprovalStatus"].ToString();
}
重要的是注意，一個自定義任務編輯表單，你的任務不能被修改如果它沒有提交。這意味着你不需要While活動。在此之前，有人可以輕鬆的更改任務的Title列，和永遠不變的Status列。隨意移動OnTaskChange活動到While活動外，並直接後面放置CreateTask活動。然後，你可以刪除While活動。
你終於準備測試。生成並部署Visual Studio解決方案。然後創建一個新的Capital Expenditure Request，然後啓動工作流。點擊任務，你應該看到你的自定義InfoPath任務編輯表單（圖10.10）。在這個表單中，你將發現Title和Description，之後你單擊三個按鈕之一，工作流將完成，它的狀態將被更新。
圖10.10
本人聲明