對於集團公司，企業內容的集中管理是目前的一個趨勢，在這邊文章裏，我們講解某集團銀行如何通過 FileNet 實現企業內容的統一管理。
某集團銀行是我國最大的投資銀行之一，下屬五十幾家分行，分佈在全國各地。在日常業務中，每天會產生大量的業務憑證，包括信貸合同、儲蓄憑單、支票、會計檔案等。如何對這些憑證進行統一集中管理，有效的分類、保存、歸檔以及查詢，是該集團銀行面臨的一個比較棘手的問題。
憑證電子化管理可以有效解決這個問題，所謂憑證電子化管理是指將紙面憑證掃描轉化爲電子影像文件，並實現電子影像文件的自動分類、存儲、調閱、查詢以及歸檔。
利用 IBM 的 Datacap，總行以及分行可以快速有效的完成紙面憑證到電子影像文件的自動識別、轉換以及分類，但是各個分行要將每天產生的這些大量電子影像文件發送到總行做統一集中管理面臨下面這些問題：
- 由於分行到總行的網絡帶寬的限制，在業務時間把電子影像文件上傳到總行比較慢；
- 電子影像文件上傳佔用帶寬比較大，嚴重影響了其它業務的操作；
- 由於分行對影像文件沒有緩存，分行對已經上傳的影像文件的查閱比較慢。
這樣的業務場景在集團公司非常常見，內容的集中管理也是未來企業內容管理的一個趨勢。目前，VPN 的搭建也很昂貴，網絡帶寬是實現非結構化內容集中管理的一個瓶頸，在我們的這個客戶系統中，總行和分行的網絡帶寬只有 10M，10M 帶寬是給分行所有的應用系統使用，電子影像文件集中管理系統佔用的帶寬也就 3M，有效帶寬就更少大約爲 1.8M，每個影像大概有 2M，每個分行每天業務會產生 5000 多個影像， 差不多 10G 的數據。
考慮到網絡帶寬這個瓶頸，爲了不在業務時間佔用帶寬，我們的解決方案是分行產生的影像文件首先臨時保存在分行的系統中，也就是把分行作爲一個存放影像文件的緩存。等到非業務時間，錯峯使用網絡，把各個分行的影像文件遷移到總行做集中管理。
利用 FileNet P8 Content Engine 的分佈式部署可以有效實現上面這個解決方案，下面我們來了解一下 FileNet 的相關知識。
FileNet P8 是可靠的、可擴展的、高可用性的企業平臺，使你能夠捕獲、存儲、管理、保護和處理信息，提高操作效率，降低總體擁有成本。
Content Engine 是 FileNet P8 的一個核心模塊，提供企業內容和客戶自定義業務對象的存儲管理服務，管理的企業內容和對象包括影像、電子文檔、音頻、視頻、報表、網絡內容、記錄、文件夾、預存的檢索、工作流定義、發佈模板、登錄模板等。在這裏，我們重點介紹內容存儲的兩個概念，File storage area 和 Content cache area。FileNet 的相關術語，請參照下面表 1。在本文裏面，我們把 FileNet Content Engine 簡稱爲 CE ，File storage area 是 CE 用來存儲內容的具體地方，支持 UNIX NFS，Windows DFS,GPFS 和 NTFS 文件系統，而 Content cache area 裏面主要存儲了最近訪問的文檔，和瀏覽器裏面的緩存作用很像，當 CE 訪問一個文檔內容的時候，CE 首先嚐試從 Content cache area 裏面查找該內容，如果沒有的話，再從 File storage area 裏面查找，把內容返回給 Client 端後，CE 再把內容拷貝到 Content cache area，下次訪問的時候就直接從 Content cache area 訪問了。一般來說，Content cache area 創建在分行的系統文件裏，便於分行直接訪問提高訪問文檔內容的性能。
表 1. FileNet 術語表
| 術語 | 解釋說明 |
|---|---|
| Content Engine | 內容引擎，FileNet 的一個核心組件，用來管理整個企業的工作對象、自定義對象和文件。 |
| Object Store | 是一個數據庫的貯藏室，用來存儲文檔、文件夾、自定義的業務對象以及這些對象的元數據信息。 |
| File Storage Area | 文件存儲區域，是內容引擎具體存放非結構化文件的地方，對於結構化文件被內容引擎存儲在數據庫裏面。 |
| Content Cache Area | 文件緩存區域，CE 首先從這個地方獲取文件內容，如果沒有的話，再從文件存儲區域獲取。 |
| Request forwarding | 請求轉發，一個 CE 服務器可以把請求轉發給另外一個 CE 服務器，以提高性能。 |
| Migration Application | 自己寫的一個文檔內容遷移的小應用，用來把文檔內容從一個文件存儲區域遷移到另外一個文件存儲區域。 |
| Property | 屬性，根據業務需要，自定義的元數據。 |
| Class | 類，包含了自定義的元數據定義。是用來創建文檔的模板。 |
| Document | 文檔，是類的實例，包含了具體元數據的值和附加的非結構化文件。 |
此解決方案的核心是先把影像文件緩存在分行，然後利用網絡錯峯時間把分行的影像文件遷移到總行做集中管理，所以在總行要創建一個 File storage area 做影像文件的集中存儲管理，在各個分行我們要創建一個 File storage area 做影像文件的臨時緩存，同時在分行也要創建一個 Content cache area，這樣當分行 File storage area 的影像文件被遷移到總行後，還可以從本地的 Content cache area 訪問。接下來的問題是如何把影像文件從分行的 File storage area 遷移到總行的 File storage area，CE 的 com.filenet.api.core.Document 類有一個 moveContent(StorageArea) 方法，通過在 Document 對象上調用 moveContent 方法，就可以把分行的影像文件遷移到總行的 File storage area 上。
根據上面的描述，我們設計的分佈式部署架構如下圖 1，下面我們詳細講解一下這個架構圖。
數據庫和 LDAP 都安裝在總行，在總行也創建了一個 CE File storage area，用來集中存儲 50 個分行的影像文件。在每一個分行，都創建了一個 File storage area 和 Content cache area，分行的 File storage area 用於臨時存儲影像文件，分行把影像文件上傳後，以後再訪問的時候直接從分行的 Content cache area 來訪問。分行影像文件上傳流程如下：
- 分行掃描影像後，Client 端直接訪問分行的 CE，發出電子影像文件上傳請求。
- 分行的 CE 處理這個請求，把影像文件分別保存到分行的 File storage area 和 Content cache area。
- 然後分行的 CE 通過請求轉發（Request forwarding），把影像文件對應屬性數據信息保存請求發送給總行的 CE。
- 總行的 CE 處理請求，把屬性數據信息保存在數據庫裏面，然後把操作結果返回給分行的 CE。
- 分行的 CE 把操作結果返回給調用的 Client 端。
- 然後定時調用 Migration Application 應用程序，把影像文件從分行的 File storage area 遷移到總行的 File storage area。
圖 1. 分佈式部署架構圖
各個分行的影像文件被上傳到總行做集中管理後，總行直接從本地的 File storage area 訪問電子影像文件，訪問速度很快；而分行在本地有 Content cache area，分行從 Content cache area 訪問電子影像文件也很快。
文檔遷移 (Migration Application) 應用程序編寫比較簡單，主要調用上文描述的 moveContent 方法，具體實現如下面代碼片段，可以通過 EJB timer 或者定義一個作業來按時運行這個程序 , 比如說在每天夜裏 12 點非業務時間運行。
清單 1. 文檔遷移應用的代碼片段
public static void migrateStorageArea(ObjectStore objectstore,StorageArea sourceStorage,
StorageArea targetStorage){
System.out.println("===Migrate content from " + sourceStorage.
get_DisplayName() + " to " + targetStorage.get_DisplayName() + "===");
//each transaction will migrate 1000 docs' content
int batchSize=1000;
int temp=0;
IndependentObjectSet docSet=null;
Document doc=null;
//set up RetrievingBatch to migrate content
RetrievingBatch rb = RetrievingBatch.createRetrievingBatchInstance
(objectstore.get_Domain());
Integer pageSize = new Integer(1000);
PropertyFilter filter = new PropertyFilter();
int filterLevel = 1;
filter.setMaxRecursion(filterLevel);
filter.addIncludeType(new FilterElement(null, null, null,"StorageArea",
null));
filter.addIncludeType(new FilterElement(null, null, null,"DocumentTitle",
null));
Boolean continuable = new Boolean(true);
try{
//search all docs stored in sourceStorage
String queryString="select this,StorageArea from document where
StorageArea=Object('" + sourceStorage.get_Id().toString() + "')";
System.out.println("create search scope");
SearchScope search = new SearchScope(objectstore);
System.out.println("create search SQL by query string
<" + queryString + ">");
SearchSQL searchSQL = new SearchSQL(queryString);
System.out.println("execute search");
docSet=search.fetchObjects
(searchSQL, pageSize, filter, continuable);
Iterator iter=docSet.iterator();
while(iter.hasNext()){
doc=(Document) iter.next();
System.out.println("get doc " + doc.getProperties().
getStringValue("DocumentTitle"));
temp++;
doc.moveContent(targetStorage);
rb.add(doc, null);
if(temp==batchSize){
//if there are 1000 docs, migrate them
System.out.println("submit batch " + batchSize);
rb.retrieveBatch();
temp=0;
}
}
rb.retrieveBatch();
System.out.println("===Migration is done===");
}catch(EngineRuntimeException erEx){
//just in case there is no doc needed migration
if(erEx.getExceptionCode()==ExceptionCode.API_EMPTY_BATCH){
System.out.println
("There are no objects in this batch to process");
}else{
System.out.println
("Unexpected error occurred when migrating content");
throw new RuntimeException(erEx);
}
}catch(Exception ex){
System.out.println("Error occurred when migrating content");
throw new RuntimeException(ex);
}
}
|
按照上面的分佈式部署架構圖，接下來我們詳細講解分佈式部署環境的詳細搭建。在我們的這個例子裏，某集團銀行用的是 WebSphere ND，FileNet CE 支持分佈式部署，只需要把 FileNet CE 安裝在總行，就可以把它部署到所有的分行，FileNet CE 的分佈式部署非常便於升級和維護。
在總行，我們需要安裝 WebSphere ND deployment manager 和一個 node，然後安裝 FileNet CE。
在分行，我們只需要安裝 WebSphere ND node 或者 WebSphere Application Server，然後用 WebSphere ND deployment manager 來管理所有分行的 WebSphere Application Server。
在 WebSphere 和 FileNet CE 安裝完成後，我們就可以進行配置。下面是詳細安裝流程。
在總行，安裝 WebSphere ND deployment manager 和一個 node，運行 WebSphere ND 的安裝文件，選擇安裝”Cell(deployment manager and a managed node)”，如下圖 2 所示，其它的步驟按默認安裝就好。
圖 2. 安裝 WebSphere deployment manger
安裝完 Base WebSphere ND deployment manager7.0 後，還需要安裝 FP，CE5.1 支持的最低版本是 WAS 7.0 FP9，在我們的試驗中，我們安裝的是 FP21，如下圖 3：
圖 3. 升級 WebSphere deployment manger 到 FP21
在總行安裝完 WebSphere ND deployment manager 和 node 後，我們接着需要安裝 Content Engine，Content Engine 的安裝和配置是分開來的，安裝很簡單，所有步驟按照默認安裝就好。詳細步驟請參照 infocenter。
在各個分行，只需要安裝 WebSphere ND node（另外一種方法是在分行安裝 WebSphere Application Server，然後通過總行的 deployment manager 來統一託管），運行 WebSphere ND 的安裝文件，選擇安裝”Custom”，如下圖 4 所示，其它的步驟按默認安裝就好。
圖 4. 安裝 WebSphere ND node
在安裝 WebSphere ND node 過程中，需要輸入總行 deployment manager 機器名，端口號（默認爲 8879）以及安裝 deployment manager 的時候指定的用戶名和密碼，如下圖 5：
圖 5. 輸入總行 WebSphere deployment manger 信息
安裝完 Base WebSphere ND node 7.0 後，還需要安裝 FP，CE5.1 支持的最低版本是 WAS 7.0 FP9，在我們的試驗中，我們安裝的是 FP21，如下圖 6：
圖 6. 升級 WebSphere ND node 到 FP21
在總行和分行安裝工作完成後，我們要對 WebSphere deployment manager 做一些配置，然後就可以部署 Content Engine。
進入總行 deployment manager 的 Console，打開 Nodes 菜單，可以看到總行的 Node 和所有分行的 Node，在我們的實驗中，總行的 Node 是 winceNode01，我們只有一個分行，Node 名稱是 wincss1Node01，如下圖 7：
圖 7. 總行和分行的 Nodes 信息
分行的 Node wincss1Node01 還沒有 server 信息，創建一個新的 server，名稱爲 shanghaiServer1，選擇的 Node 爲分行的 Node wincss1Node01，如下圖 8， 增加完成後，我們可以看到總行和分行的 servers 信息，如下圖 9。
圖 8. 爲分行的 Node 增加 Server
圖 9. 總行和分行的 Servers 信息
Content Engine 的分佈式部署和普通部署比較起來，只有 Deploy Application 這個 task 不一樣，在分佈式部署裏面，Deployment type 選擇 Network Deployment，如下圖 10。然後選擇 Application server node，我們需要分別在總行和各個分行部署 CE，所以需要依次選擇總行和各個分行的 node，選擇 Application server node 後，Application server name 會自動被篩選出來，根據不同的 node，我們可以給 Content Engine application name 不同的名稱，比如在我們的實驗中，總行的名稱爲 FileNetEngineBJ，分行的名稱爲 FileNetEngineSH。
圖 10. 在分行的 Node 上面部署 CE
在總行和各個分行部署 Content Engine 後， 打開 Enterprise Applications，可以看到我們部署的 FileNet Engine，如下圖 11。部署完成後，需要重啓分行和總行的 node，然後再把各個 node 同步一下，如下圖 12。
圖 11. 總行和分行部署的 FileNet Engine
圖 12. 同步總行和分行的 node
部署完 Content Engine 後， 打開桌面上 FileNet Content Engine Enterprise Manager，連接到 CE Server，創建兩個 StorageArea，一個創建在總部爲 BJ_StorageArea，另外一個創建在分行爲 SH_StroageArea，如下圖 13。然後在分行再創建一個 ContentCacheArea，如下圖 14.
圖 13. 總行和分行的 StorageArea
圖 14. 分行的 ContentCacheArea
按照上面的配置，即可完成分佈式環境的安裝和配置，我們接着以信用卡申請爲例，講解這個分佈式環境在集團銀行總行和分行的使用。
顧客到銀行分行櫃檯提出信用卡申請請求，業務人員首先審覈顧客的資料，身份證、工作證明比如工牌或者名片、最近幾個月的收入證明，這些材料都是紙質材料，業務人員把這些紙質材料通過 IBM DataCap 自動掃描、分類生成電子影像文件，通過分行的 CE 保存到分行的 StorageArea 和 CacheStorage 中，然後信用卡申請流程被觸發。
內容遷移應用程序在非業務時間被定時調用，把顧客提交的電子影像文件從分行的 StorageArea 遷移到總行的 StorageArea。
電子影像文件遷移到總行後，分行的業務人員等待總行審批部門的審覈結果，在此期間，分行業務人員可以隨時從 CacheStorage 查閱顧客的電子影像文件。
在總行的審批部門，審覈人員通過信用卡申請系統看到信用卡審覈任務，審覈人員從總行的 StorageArea 中查閱從分行提交的電子影像文件，按照一定的規則對顧客的資料進行覈查。由於這些文件都已經被遷移到總行，極大提高了審覈人員的工作效率。