正如語言是人之間的溝通方式一樣，數據是IT系統之間的溝通方式，語言之間的溝通總是最有效的，數據交互卻未必，因為IT系統里的數據除了讓計算機理解外重要的是還需要人理解。在這篇文章里，我們將討論工作流系統里的數據，從數據角度分析工作流數據的分類以及不同的應用場景。
一、工作流系統的應用場景
在正式開始對工作流數據的討論之前，首先對工作流系統的應用場景進行討論是必要的，因為工作流數據脫離不開工作流系統這個大的上下文。目前，工作流系統的應用主要有兩種方式：
1、 將工作流系統嵌入到業務系統中使用。此時工作流系統作為內部組件對業務系統進行流程邏輯的橫切。試想一個需要多人處理的電力繳費流程，在引入工作流系統之前，我們需要為每個業務表單設置一個狀態位，以此來進行業務處理狀態的跟蹤。如果流程固定，那么這樣做并沒有什么不好，例如財務軟件、海關報關軟件等，它們的流程雖然復雜但是不常改變，此時就沒有必要引入工作流系統。但是對于另外一些情況，例如制造業的訂單處理、庫存管理、政府的協同辦公等，流程經常需要定制修改，此時如果繼續由業務系統自己處理流程邏輯那么成本將會很高。
2、 使用工作流系統進行業務系統的集成。在上規模的企業里，很多流程會涉及到不同的業務功能，例如報價、訂單審核、資產核準、績效評估等，這些流程經常會跨越不同的部門和業務系統。因為不同企業都有自己所采用的業務系統、組織機構以及最佳的業務協作方法，所以這些流程基本上也隨企業而異。工作流系統此時扮演的就是集成角色，由其通過定制流程將這些業務系統撮合起來，實現企業內各部門、客戶間的信息流動和協作。
在第一種應用場景下，工作流系統作為業務系統的內部橫切組件出現，作為橫切組件，工作流數據僅僅包括與流程邏輯相關的數據以及其他必需數據，這些數據包括工作流控制數據、工作流相關數據以及需要通過流程傳遞的業務數據。
在第二種應用場景下，由于不同業務系統之間的數據傳遞很大程度上依靠工作流系統，所以這些數據被封裝為SDO在不同WEB服務間傳遞，需要注意的是，這些數據并不在工作流系統中存儲。
在下面的工作流數據分類中，我們將詳細分類這些工作流數據。
二、工作流數據的分類
提到工作流數據，就不得不提業務數據。作為最直接的區分，我們將存儲于業務系統中的數據稱為業務數據，將存儲于工作流系統中的數據稱為工作流數據。根據WFMC定義，我們將工作流數據分為工作流控制數據和工作流相關數據。
1、 工作流控制數據。指被工作流系統管理的系統數據，這些數據包括了與流程實例和任務實例相關的執行數據，例如流程實例的狀態、執行時間等信息、任務實例的執行者、執行時間、狀態、緊急程度等。
2、 工作流相關數據。指與業務流程相關的數據。工作流相關數據又具體分為3種：
· 影響流程實例執行的業務數據。在WFMC中，這個數據被描述為：工作流系統通過該數據來確定流程實例的流轉條件，并選擇下一個將執行的任務，這些數據可以被業務系統訪問并修改。例如報銷流程中的“報銷金額”，這個數據會決定該流程的審批路徑；再例如為任務設置的超時時間，這個數據會觸發任務的取消。實質上這些數據就是工作流系統需要依賴于進行流程流轉的業務數據。
· 契合業務的關聯數據。指工作流系統與業務系統進行關聯的數據，例如特定于WEB系統，工作流系統會在每個流程實例里保持有導航至對應業務表單的URL。
· 傳遞作用的業務數據。當流程跨越多個業務模塊時，需要在模塊間傳遞數據，此時會利用工作流系統進行傳遞，會在工作流系統里暫時存儲這些業務數據。
那么，工作流數據有哪些應用場景呢？
三、工作流數據與業務上下文
工作流數據最重要的職責之一就是為業務系統的不同應用場景建立起與之對應的業務上下文。
什么是業務上下文？
我們知道，IT系統是對企業現實業務的映射。在一個翻譯公司的典型業務場景中，校對人員對翻譯人員提交的翻譯文檔進行審校，此時，校對人員持有翻譯人員翻譯后的文檔，他需要對該文檔進行檢查，產生新的審校文檔并反饋翻譯人員的翻譯質量。那么，映射到IT系統里，校對人員的任務通常對應于一張需要處理的業務表單，業務表單里會展現他進行當前工作所需要的數據：翻譯文檔、翻譯人員信息、該校對工作的緊急程度等，另外，在這張表單里，他所能進行的操作也根據他此時的職責作出了行為限定：例如他可以上傳新的校對后的文檔，但是不能刪除已有的翻譯文檔等。如下圖1所示，業務表單實質上反映的是此刻我們能獲取哪些數據以及能夠如何處理這些數據，我們把它稱之為業務上下文，可以看到，在IT系統里，業務上下文實質上等于數據加上行為。
企業業務由一系列相互關聯的業務場景組成，這些業務場景對應于IT系統里的業務上下文，而業務上下文的本質則是數據加上行為。數據和行為的不同決定了業務上下文的差別。這與現實中的工作相符，人們根據獲取/處理信息的不同，擔負不同的職責。
圖 1與應用場景對應的業務上下文
工作流數據如何建立業務上下文呢？看一個簡單的例子。
在實際應用工作流系統進行開發時，我們經常會碰到這樣的問題：同一流程中的不同任務對業務數據擁有不同的權限，如下圖6-9所示。
圖 6?9與流程相關的業務數據權限
上圖中，在執行請假申請任務時，申請者可以編輯請假人、天數和原因3個字段；而到審批任務時，審批者增加了一個可編輯的審批意見字段，但其余3個字段變化為只讀字段。我們將這類問題統稱為與流程相關的業務數據權限控制。
產生這類問題的原因是什么呢？原因就在于在一個業務流程里，不同的任務具有不同的業務上下文。如下圖6-10所示，不同的任務展現不同的數據，并具有不同的行為。
圖 6?10任務與業務上下文
在IT系統的設計實現中，數據的建模是通過領域模型實現的。在工作流系統的嵌入式應用中，流程實例即是通過與領域模型相關聯實現與業務契合的。那么，圖6-10可以進一步泛化為圖6-11，流程中任務通過獲取領域模型不同的部分實現業務上下文的界定。
圖 6?11領域模型與業務上下文
在大部分的業務流程建模中，一個流程模型只與一個領域模型關聯。
那么，回到最初的問題上，如何處理此類權限問題呢？答案非常明了：由領域模型實現對業務上下文的切分，工作流系統通過契合業務的關聯數據與業務上下文掛接，保持工作流系統的單一職責。
圖 6?12流程相關的業務數據權限控制
如上圖6-12所示，我們在業務系統里引入業務權限角色的概念，通過該角色隔離開工作流系統與業務數據權限，即我們認為業務數據權限的管理屬于業務系統范圍（由業務系統具體實現），更進一步，我們認為其屬于領域模型的職責范圍。在定義好業務系統的權限角色后，我們通過任務級別的工作流變量將流程中的具體任務與業務權限角色綁定，這樣就實現了流程任務與業務數據權限的掛接。
在上面的例子中，我們看到的是利用關聯業務的工作流數據界定任務級別的業務上下文，這是一種最簡單的工作流數據應用場景。在不同應用中，我們可以看到，工作流數據一個重要的職責就是為業務流程里的任務/流程建立業務上下文，實現數據的聚合。在簡單的應用場景里，對一個流程實例而言，這些數據可能只對應于一個領域模型；對流程實例里的一個任務實例而言，這些數據對應于領域模型的一個切面。復雜一些的情況，業務上下文需要跨越多個領域模型甚至多個業務系統，這時我們可以看到，通過工作流系統能夠顯著降低業務系統建模的復雜性，因為這些數據聚合工作可以有效分派給工作流系統承擔。同時，我們需要保持工作流系統的單一職責，工作流系統只保存與業務數據進行關聯的關聯數據、必需的業務傳遞數據以及自身的執行數據。
圖 6?29跨系統的業務上下文
四、工作流數據與數據分析
工作流數據的第2個應用場景是對業務流程執行進行數據分析，這部分的數據主要是工作流控制數據。這一部分正受到越來越多的重視，是未來工作流系統的發展方向。
圖 6?48外部環境從流程實例拉數據進行分析
這里有兩個典型的應用例子：
例子1在對報銷流程進行分析時，我們發現大部分的報銷金額都低于500元，然而這些報銷流程卻都要經過很多環節，在與客戶確認后，我們將低于500元的報銷限定于部門內部審批即可，這樣對個人來說大大加快了報銷過程，對公司來說則省下了很多的辦公成本。
例子2，在制造流程里，很重要的一點是需要控制流程的節拍時間，即流程里各個任務的完成時間要一致，如果有一項任務的時間多于其他任務，那么很快就會形成瓶頸，造成在制品的大量積壓，前續的任務完成很快，中間忙死，后續任務執行者卻無事可做，更重要的是，不能對客戶進行快速交付。
五、工作流數據與流程路由
最后一種應用場景非常常見，這部分數據即影響流程實例執行的業務數據，直接上圖：
這部分影響路由的一定是業務數據，它們保存到工作流系統里對流程路由產生影響。這種影響不限于任務的選擇，還包括的任務的執行條件、任務的完成條件、基于數據的任務觸發等。
六、工作流數據小結
總結一下，作為區分，我們將存儲于業務系統中的數據稱為業務數據，將存儲于工作流系統中的數據稱為工作流數據。
工作流數據分為兩種：工作流控制數據和工作流相關數據。其中工作流相關數據又分為3種：影響流程實例執行的業務數據、契合業務的關聯數據和傳遞作用的業務數據。
工作流數據的應用場景：為流程/任務建立業務上下文，這部分數據主要是契合業務的關聯數據和傳遞作用的業務數據，這是工作流數據最重要的職責之一；數據分析，這部分數據主要是工作流控制數據，這是未來工作流的發展方向；影響流程路由，這部分數據人如其名，是影響流程實例執行的業務數據。
實際應用中，我們一定要保持工作流系統的單一職責，例如劃分任務權限這個需求，一定需要業務系統自行實現權限的界定，工作流數據僅僅進行掛接。