實際中應該實現的功能
1、實時跟蹤工作流的運行狀況
2、超時任務監控
3、跟蹤查詢歷史工作流的處理過程?工作流異常處理
4、可執行任務改派
5、可以掛起/恢復工作流
6、可以取消工作流
7、可實現業務流程動態調整
wf對管理監控的支持：流程級和活動級的日志(TrackingService) 。默認只支持保存到SQL Server,需要按照重新實現接口才能實現保存到Oracle或者文件。默認是控制台界面的日志顯示，需要圖形化的監控和管理界面。
結論：WF只是實現了非常基礎的部分，可以說只是提供了工作流的編程框架。和目前已有的工作流開發平台相比，微軟已經提供的Acitivity功能還是非常薄弱的。現在社區和微軟都沒有非常好的工作流實例。Start Kit是比較完善的一個例子，建議大家看一下。但是只要我們熟悉了WF的框架，通過自己實現一些基礎功能，絕對是可以做的工作流開發平台高度的。這就是為什麼要學習《WF框架編程》的意義
沒有任務表對wf的影響
在3.1節中任務分配考慮時說到，WF沒有任務表的概念，WF引擎也不關心流程什麼時候流轉，向什麼地方流轉。這是目前為止。這種設計本身非常好，但是WF不提供任務表對待辦任務的檢索造成很大影響。非常有必要再明確討論一下。考慮一下待辦任務查詢：我們如果遍歷工作流實例，再看每個活動的角色指定是否是當前角色，肯定會存在嚴重的性能問題。如果我們自己建任務表，考慮下面兩種情況：1、運行時指定角色，這個時候我們可以在應用程序級別插入任務信息（工作流ID，指派人，提出人…等等），但是如果這樣流程的運轉其實不是靠WF而是靠任務表實現的，相當於沒有使用WF。而且任務表的維護工作非常麻煩，任務執行後要更新任務表，回退，會簽邏輯要頻繁在業務邏輯層面維護任務表。反而麻煩。所以對任務表的維護必須用工作流自身完成。這個也是建議使用自定義Acitivity方式維護任務表的原因。2、設計時指定WorlflowRole。這種情況下一般也是使用自定義Acitivity做維護任務表。
問題：一、是否有必要自己實現任務表
二、如果要自己實現，文中方法是否可行，是否有更好的方法
