簡介
IBM DB2 Content Manager
IBM DB2 Content Manager 為商業解決方案提供了極好的文檔管理和文檔路由的支持。商業中包含著種類繁多的文檔，商業解決方案需要支持這些不同種類的文檔。Content Manager 擁有靈活的定義文檔結構的能力，它可以根據解決方案的需要來定義文檔的結構，這滿足了解決方案中文檔多樣化的需求。Content Manager 還擁有強大的定義文檔處理流程的能力，解決方案憑借這種能力可以描繪出商業中真實的文檔處理過程。Content Manager 可以定義解決方案需要的文檔類型和每種類型的文檔的工作流程，並且按照這些工作流程去路由文檔。這為解決方案將文檔定義和文檔路由進行了結合，使解決方案滿足商業中對於文檔管理和文檔路由的需求。
LDAP
LDAP（Lightweight Directory Access Protocol）是輕量級目錄訪問協議。目錄是以層次結構排列的對象的信息集合，是一個允許用戶或者應用程序根據格式化的參數在其中檢索資源的數據倉庫。如果目錄中只有一個對象的格式化參數的值與用於檢索的參數值相同，目錄會查詢出這個對象。如果目錄中有多個對象的格式化參數的值與用於檢索的參數值相同，目錄會找出所有這些對象。所以目錄是將數據以對象的形式存儲，並且可以根據對象的屬性來檢索出對象的數據倉庫。它以層次結構存儲對象的特性可以和商業中人力資源模型進行極好的對應，因為二者都具有層次結構和以對象存儲兩個特點。
IBM Tivoli Directory Server 是一個功能強大的高性能目錄服務器。它實現了 LDAP 並可以為解決方案提供靈活和穩定的目錄服務，已經被許多人力資源解決方案采用。
人力資源的票據管理解決方案
票據的管理，審批和歸檔是人力資源的重要組成部分。票據種類的多樣性和票據數量的龐大使票據管理解決方案越來越多的應用到人力資源領域，因為憑借人工方式來管理種類繁多並且數量浩瀚如海的票據幾乎是不可能的任務。人力資源的票據管理解決方案致力於解決人力資源領域中票據的處理，主要包括票據管理，審批和歸檔。其中票據管理分為對於票據類型和對於票據的管理，票據審批很大程度上依賴於票據的審批流程。對於票據歸檔，解決方案需要提供靈活並且功能強大的票據檢索能力，因為對於歸檔後的票據的檢索將可能包含多種不同的檢索條件和檢索條件的組合。由於商業中票據的審批和人員之間存在著密切的聯系，所以商業中的人員組織結構信息也是票據管理解決方案的重要組成部分之一，票據管理解決方案需要具有管理人員組織結構信息的能力。
票據管理解決方案的 Content Manager 建模
票據管理解決方案首先需要對商業中的票據管理進行建模，這些模型主要包括人員組織結構模型，票據模型和票據審批流程模型。在建立好這些模型後，解決方案需要將這些模型對應到 Content Manager 中。Content Manager 提供了用戶和用戶組（user group），itemtype，工作流程和工作列表（worklist）來為解決方案描述這些商業模型。這個過程是商業模型在 Content Manager 中的體現，是在 Content Manager 對於商業中的票據管理進行的建模。
票據管理解決方案模型
票據管理解決方案模型主要由人員組織結構模型，票據模型和流程模型組成。人員組織結構模型包括用戶和部門兩個元素，其中用戶之間和部門之間都存在著平行和層級的關系，同時用戶和部門之間還具有涵蓋關系。票據模型體現著票據的種類，每種票據都擁有一個使其區別於其他票據的票據模型，但是一個票據模型中的某些屬性是可以和其他票據模型所共享的。流程模型是人員組織結構模型和票據模型的集成者，票據的處理是在流程中完成的，也就是說票據的處理者處理的是流程中的票據。
用戶和部門
用戶和部門是人員組織結構模型中最基本和關鍵的兩個元素。用戶之間最重要的關系是層級關系，用戶和部門之間最重要的關系是涵蓋關系，同時部門之間也存在著層級關系，這些關系決定了一個用戶或者部門在整個人員組織結構中的位置。例如若干用戶同屬於一個部門並擁有同一個上級用戶，那麼這些用戶之間就是平行關系，同時都與那個上級用戶構成層級關系。如果若干部門包含著不同的但是具有平行關系的用戶，那麼這些部門很可能是一些具有平行關系的部門。
用戶和部門都具有自身的屬性並且在商業中大多數屬性是固定的，例如用戶擁有用戶名和上級用戶的 ID，部門有部門名和所涵蓋用戶的用戶名。因此用戶和部門都可以作為對象來管理，其中用戶和部門的屬性可以作為對象的屬性來管理。LDAP 具有良好的對象存儲和檢索能力 , 將人力資源解決方案中的用戶和部門作為對象存儲在 LDAP 中是一個很好的選擇，這也是許多人力資源解決方案應用 LDAP 的方式。在 LDAP 中部門通常以用戶組的形式來表示。
票據管理解決方案需要在 LDAP 中建立兩類對象，分別是用戶對象和用戶組對象。用戶對象通常包含一個標識上級用戶的屬性，憑借這個屬性票據管理解決方案可以描述所有用戶之間的層級關系。用戶對象通常還包括一個用戶組標識屬性來標識用戶所從屬的用戶組，憑借這個屬性票據管理解決方案建立了用戶和用戶組之間的聯系，也就是人員和部門之間的聯系。用戶組對象通常包含一個標識上級用戶組的屬性來幫助票據管理解決方案描述用戶組之間的層級關系，並且還包括一個標識用戶屬性來記錄所有屬於這個用戶組的用戶。
票據
票據是人力資源的票據管理解決方案的核心，商業中的票據種類繁多，解決方案需要為每種票據都建立一個模型來描述它。票據模型是一些屬性項的集合，也就是說一種票據模型包含著眾多的屬性條目。其中一些屬性是存在於每種類型的票據模型中的，例如票據日期和票據金額。所以票據管理解決方案需要將每種票據上的數據條目抽象成屬性項，然後根據每種票據的屬性結構將相關的屬性項集合在一起形成這種類型票據的模型。
票據管理解決方案的票據模型通常包括以下屬性：票據編號，票據類型，票據日期，國家代碼，貨幣，票據總額，票據淨額，稅率，稅額，票據所有者和票據描述。
審批流程
人員組織結構模型和票據模型建立完成後，解決方案需要將兩者結合起來使用戶可以處理相應的票據，這就需要流程模型的參與。商業中通常每種票據都有自己的審批流程，票據會在流程中的工作節點上被用戶處理。
票據管理解決方案在對商業流程進行建模的時候，首先需要確定流程中需要包含的工作節點，這些工作節點與商業中對票據的每個操作步驟相對應。例如票據在進入審批流程後首先需要進行校對，然後進行審批和歸檔，與其對應的流程模型則需要包括校對節點，審批節點和歸檔節點。在校對節點上，負責校對票據的用戶會對票據進行信息准確性方面的校對，然後將通過校對的票據路由到下一個工作節點，等待在下一個節點負責審批票據的用戶會根據一定的規則對票據進行審批然後繼續路由票據到下一個節點供負責票據歸檔的用戶處理。可以看出，票據和用戶已經參與到流程模型中。解決方案通過流程模型將人員組織結構模型和票據模型結合了起來，使用戶處理票據這個過程最終得以實現。
在定義流程模型時，參與流程中票據處理的用戶可以以用戶組的形式來定義。也就是說，流程模型中處理某個工作節點上的文檔的用戶並沒有被確定，而是指定了一個用戶組。當票據在流程的工作節點上被處理的時候，解決方案首先會找到這個用戶組，然後選擇用戶組中的用戶來處理票據。在用戶組中選擇用戶的時候，解決方案可以引進許多分配算法來加強工作負載分配的科學性和合理性。
Content Manager 建模
IBM DB2 Content Manager 為解決方案提供了強大和穩定的文檔管理和文檔路由的能力，這些能力可以很好的滿足人力資源的票據管理解決方案對於票據處理的需求。Content Manager 還擁有靈活的建模能力，解決方案可以在 Content Manager 中完成對人力資源的票據管理的建模，並且根據建立的模型來實現票據的處理過程。
Content Manager用戶
在 LDAP 中建立的人力組織結構模型已經足以描述解決方案的人員組織結構，解決方案只需要將這個模型引入到 Content Manager 中即可。用戶和部門的層級關系和涵蓋關系已經在 LDAP 進行了定義，所以 Content Manager 不需要再次定義它們。同時由於參與 Content Manager 流程操作的是用戶而不是用戶組，所以也不需要導入用戶組而只需要將用戶導入到 Content Manager。
Content Manager 提供了根據 LDAP 中的對象來建立用戶的能力，建立 Content Manager 用戶前首先需要將一個 LDAP 關聯到 Content Manager 上，如圖 1 所示。
圖 1. 在 Content Manager 管理客戶端中關聯 LDAP 到 Content Manager
查看原圖（大圖）
完成 Content Manager 與 LDAP 關聯的建立，解決方案可以在 Content Manager 管理客戶端根據 LDAP 中的對象來建立用戶，如圖 2，根據存儲在 LDAP 中的用戶對象 test@BLUE 建立一個同名的 Content Manager 用戶。
圖 2. 根據 LDAP 中的對象建立 Content Manager 用戶
查看原圖（大圖）
Item Types
Content Manager 的 itemtype 是定義票據管理解決方案的票據模型的主要元素，是由一些屬性組成的集合。這完全符合商業中真實票據的特點，因為票據也是由一系列的屬性條目組成的。 Content Manager 票據管理解決方案需要為每種可以支持的票據都建立一個 itemtype。
解決方案首先提取出可以支持的票據包含的所有屬性，這些屬性可以被票據模型共享。然後解決方案在 Content Manager 中為每個屬性建立一個相應的 attribute，這些 attribute 也被 itemtype 共享。解決方案會根據每個票據的具體特征形成一個屬性集合，也就是在 Content Manager 中建立一個由 attribute 組成的 itemtype，這個 itemtype 就是票據的 Content Manager 的模型。如圖 3，打開 Content Manager 管理客戶端建立新的 itemtype，將預先建立好的 attribute 加入到 itemtype 中。
圖 3. 在 Content Manager 管理客戶端中添加 attribute 到 itemtype 中
查看原圖（大圖）
流程和工作列表
Content Manager 可以建立復雜的流程並且驅動 Content Manager 文檔沿著流程路由下去，同時通過工作列表完成與用戶的交互。憑借這種能力，票據管理解決方案可以在根據商業需求定義的流程上路由文檔，並且在路由過程中解決方案的用戶可以完成對票據的處理。
圖 4. 在 Content Manager 管理客戶端中建立工作節點
查看原圖（大圖）
解決方案首先需要在 Content Manager 中建立工作節點，如圖 4，在管理客戶端的 work basket 中建立一個新的工作節點。建立完流程需要的所有工作節點後，解決方案需要根據商業邏輯將工作節點用路徑進行連接以完成流程模型的建立。Content Manager 提供了圖形化接口來幫助解決方案完成這個過程，如圖 5，在 Content Manager 管理客戶端中勾畫一個流程模型。
圖 5. 在 Content Manager 管理客戶端中勾畫流程模型
查看原圖（大圖）
IBM DB2 Content Manager 為流程建模提供了大量的流程元模型，流程建模主要通過組合這些元模型來實現。除工作節點以外，元模型還包括開始和結束節點，判定節點，分裂和聚合節點，子流程節點，這些節點都是非工作節點。
從判定節點出發與工作節點相連接的路徑不同於普通路徑，這種路徑允許指定判定條件，Content Manager 會根據指定的條件來判定文檔應該沿著哪條路徑進行路由。
商業中一個票據需要被多個審批者並行處理的情況是大量存在的，分裂和聚合節點滿足了票據管理解決方案中並行處理一個票據的需求。分裂節點將文檔復制成多個拷貝文檔並沿著不同的路徑路由這些拷貝文檔，在這個過程中拷貝文檔會在流程的不同路徑上的工作節點分別得到處理，並行處理結束後聚合節點將整合這些拷貝文檔並形成一個文檔。分裂和聚合節點在流程中必須是成對出現的，否則流程中必定存在錯誤。
將非常復雜的商業邏輯建模到一個工作流程中是非常困難的，因為大量的工作節點和節點之間的路徑會嚴重的降低工作流程的清晰性。在這種情況下將商業邏輯進行劃分然後將每部分邏輯分別進行流程建模，然後再將這些流程模型進行整合，是一個非常好的選擇。Content Manager 子流程節點解決了這個問題，它使流程之間可以嵌套，進而就使商業邏輯在建模時可以得到切分和整合。
用戶所處理的票據停留在工作節點上，票據不能停留在工作節點之間的路徑和非工作節點上。所以在用戶完成對票據的處理後，票據會被路由到下一個工作節點，等待被相應的用戶處理。這形成了票據在流程上逐步的路由，實現了票據在整個流程上的流轉和處理。
工作列表是 Content Manager 和用戶之間的橋梁，它將 Content Manager 中的票據提供給票據管理解決方案的用戶供用戶處理。票據都停留在工作節點上，工作列表是停留在一些工作節點上的票據的集合。Content Manager 將這個集合以列表的形式展現給用戶，用戶可以從列表中拿出票據進行處理，處理後的票據將被路由到下個工作節點被其他用戶繼續處理。用戶在處理票據的時候完全不需要知道票據從哪裡來和到哪裡去，用戶處理完票據後，Content Manager 會按照流程去路由票據以繼續票據在流程中的流轉。如圖 6，在 Content Manager 管理客戶端中建立一個工作列表並將一些工作節點加入到這個工作列表中。工作列表建立完成後，這些工作節點上的票據文檔都會被這個工作列表展現給用戶。
圖 6. 在 Content Manager 管理客戶端中添加工作節點到工作列表
查看原圖（大圖）
結束語
本文描述了使用 Content Manager 的元模型和 LDAP 為解決方案進行建模的方法。對票據管理解決方案的用戶，票據和流程進行建模，然後將這些模型逐個的用 Content Manager 元模型和 LDAP 進行表示，這是在 IBM DB2 Content Manager 和 LDAP 中為人力資源的票據管理解決方案進行商業建模的原理。
