在XPDL規範中，一個人工參與的活動有以下特性：活動任務的多執行個體（根據活動上指定的參與者，分配活動任務，活動任務我們稱為工作項目），工作項目的分配策略（ALL所有參與者分配和Radom隨機挑選分配，當然還有更多的資源模式，因為是是demo就不實現了），活動的完成策略（ALL所有工作項目完成活動才完成和ANY任意工作項目完成即完成），工作項目執行模式（並行和串列）。
開始我的描述，是封好的組合活動，整個組合活動暴露的屬性有：參與者（是個集合，可以自己定義組織模型介面，使用者、崗位、使用者組、組織等）、分配策略、完成策略、執行模式、警示規則等。
我們一一來看組合活動中的每個活動的作用：
1、FindParticipant活動傳入參與者清單和分配策略，經過對策略的不同處理（動態參與者需要從上下文中擷取），返回最終確定的參與者。
2、ApprovalReplicator活動是ReplicatorActivity，這個是實現活動任務多執行個體的關鍵。將計算獲得的參與者清單作為ReplicatorActivity的InitData，參與者清單的數量會決定整個ReplicatorActivity塊的執行次數，每次會起單獨的線程（通過觀察ActivityExecutionContext的ID與父活動的不一樣得知，非同步線程的Context都是自己管理的），每個線程的初始資料即為具體的一個參與者。根據工作項目執行模式是並行的還是串列的來設定ReplicatorActivity的ExecutionType屬性。ReplicatorActivity的四個事件都很有用，為了初始資料和支援策略的實現，這裡不贅述。再多說一句，WF設計器好像對IList類型的屬性支援不好，實現中我都是手寫代碼綁定的這類參數，應該是個Bug。
3、SingleApproval是封的組件活動，因為ReplicatorActivity裡只能包含一個活動，所以必須封一下。
4、CreateWorkItem根據線程擁有的參與者，在資料庫中建立工作項目。工作項目概念在WF中沒有，估計WF就不是為人工活動設計的。我們就將其設計為業務資料，可以在資料庫部署上與WF預設提供的資料庫分離。
5、LintenForApproval+WaitComplete配合實現流程對使用者完成工作項目的等待。這裡要注意的關鍵點是CorrelationToken的運用，目的是分清楚來自與宿主程式的完成工作項目的事件到底要發給哪個線程。WF的這個設計還是與Biztalk一致的，需要有建立CorrelationToken的活動（本例中是CreateWorkItem），後續的活動（本例中是WaitComplete）標記為Follow這個CorrelationToken。CorrelationToken的OwnerActivityName的設定也是很關鍵的點，這種多線程的情境中，如果這個屬性設定為SingleApproval就壞事了，這樣每個線程的CorrelationToken還是區分不出來，這裡的技巧是設為/Parent，由運行時指定為父活動，WF引擎是支援的。還有一點要提的是，需要使用CorrelationToken的這種活動引用的使用者介面必須加上CorrelationParameter特性，這個Lab中都有，不贅述了。
6、UserSolve活動就是根據使用者完成工作項目的執行情況（宿主程式在事件參數中傳入使用者執行結果）。
7、DelayActivity根據傳入的預警資訊產生等待的時間，DefaultSolve即完成預警資訊中指定的動作。
8、還差一點就是完成策略還沒有提到，這個是通過ReplicatorActivity的UntilCondition來實現的，只要這個條件計算的結果是true，那麼整個ReplicatorActivity就結束，而丟棄其他未完成的線程，每個線程的結束都會觸發這個條件計算的執行。剩下的策略規則就不難實現了，根據不同的情境堆代碼吧。
以上的組合活動來實現人工活動的要點有：
1、處理好ReplicatorActivity活動
2、Listen活動+HandlerExternalEvent活動的配合，CorrelationToken的設定
完成這個demo後還覺得這樣實現太過於囉嗦，真想用代碼直接寫個HumanActivity。對於上面的兩個關鍵點的用代碼實現的設想：
1、ReplicatorActivity，我們用代碼根據參與者清單起幾個Thread的問題。
2、Listen活動+HandlerExternalEvent活動，用WF的訊息佇列+書籤的方式就可以搞定了，這個有疑問請看我前一篇博文。CorrelationToken我們寫代碼想這麼搞怎麼搞，哈哈！
