WebSphere Process Server V7 中的併發人工任務分配

Werner Vanzyl 是一位 IBM Software Services for WebSphere 認證的 IT 專家，他有著超過 15 年的從業經驗，主要從事各種軟體產品的研發，包括 IBM 軟體和其他的開發平臺。目前，他負責 IBM 業務流程和開發、實現及部署領域的客戶日常諮詢。

簡介： 當一組工作專案被用於分配 WebSphere® Process Server 中的任務所有者時，許多組成員可能會嘗試同時宣告一個任務。在 V7 之前的版本中，避免一個併發異常的惟一方法是封裝同步塊中決定和宣告任務的查詢。本文提出一個新的方法使用查詢表宣告任務。

概述

當一個人工任務分配給一組潛在所有者時，例如，WebSphere Process Server 中的 Everyone 或一個 Group 工作專案，組內的多個成員試圖同時宣告一個任務。在之前的 WebSphere Process Server 版本中，消除併發異常的惟一方法是封裝同步塊中決定和宣告任務的查詢（或使用 Java™ 5 中的可重入鎖）。同步方法有一些缺陷，由以下原因引起的：

• 同步塊在工作專案上的員工查詢完成之前執行。這就導致了訪問任務時所有執行緒阻塞，不僅僅是訪問任務和工作組成員的使用者請求阻塞。
• 同步塊被限制在一個 JVM 上，請求被路由到叢集中的另一個節點並引起接收節點中的併發異常，這種可能性仍然存在。

早期的申明任務方法

在 WebSphere Process Server 早期的版本中，申明人工任務方法是分兩次呼叫，首先是查詢資料庫中的可用任務，其次是宣告第一次查詢返回的任務。這兩種方法都是圍繞著同步塊的，這意味著每次只有一個執行緒可以執行這個程式碼，如圖 1 所示。

圖 1. 宣告人工任務時的同步訪問

申明任務的新方法

在 WebSphere Process Server V7 中，宣告任務的方法是用一個查詢表，並結合早期用於消除同步塊需求的查詢和宣告方法。這提供了多執行緒併發訪問資料庫中的人工任務，如圖 2 所示。

圖 2. 宣告人工任務時的查詢表任務訪問

在本文中，您將檢查新方法同時使用同步方法和查詢表方法，證明新方法確實如宣傳的那樣，不會引起某種形式的併發異常。

構建一個樣例應用程式

為了證明新方法確實如前面所說的那樣，您將構建一個樣例應用程式，突出該功能所需的元件。應用程式不應該是一個已經實現的產品，而應該是一個說明使用查詢表方法申明的樣例。

假設您已經安裝了 WebSphere Integration Developer V7（以下簡稱 Integration Developer）。您可以下載一個 專案交換檔案，其中附有樣例所需的所有程式碼，除了程式碼之外，還需要如下描述的附加軟體：

• 下載 WebSphere Integration Developer 查詢表外掛。
• 當應用程式在伺服器上執行時，使用 Apache JMeter 測試併發性。

應用程式將執行在 WebSphere Process Server V7 測試環境中，測試環境是 WebSphere Integration Developer V7 安裝的一部分。當您安裝了查詢表外掛之後，像 PA71 Getting Started 文件描述的那樣，您可以檢視查詢表構件，它是專案交換的一部分。JMeter Test Project 也是專案交換的一部分，在本文後面在本地伺服器上測試併發性時將會用到。

回頁首

定義補充表和查詢表屬性

定義 SUPLDATA 表

建立這個解決方案的第一步是在 BPEDB 中建立補充表 SUPLDATA。 BPEDB 表包含補充資料，說明使用查詢表方法宣告的分類功能。SUPLDATA 表含有申明任務時區分任務優先順序所需的資料。該表強調了任務資料和使用查詢表的補充資料的連線。在下一小節中，將基於此表建立一個查詢表，用於宣告一個任務。

SUPLDATA 表由連線表中資料和 TASK 檢視中任務資料的列構成，還有申明時安排任務次序所需的列。REFID 列是一串序列號，是在建立任務時 JMeter 測試案例所生成的。它們被放在任務例項的客戶屬性中，在進行補充資料清理時用於引用補充資料行（任務完成時）。

以下步驟幫助您建立 SUPLDATA 表：

1. 為了避免連線資料庫錯誤，確保 WebSphere Application Developer 中的測試伺服器是停止的，第一次您需要建立一個新連線到本地 Derby 資料庫。
2. 在 ConcurrentAccQueryTables 專案中，切換到 Data 檢視並開啟 CreateSuplData.sql 檔案。該檔案包含在 BPEDB 中建立 SUPLDATA 表所需的所有 SQL 命令。
3. 在編輯器中右鍵單擊此檔案，並選擇選單選項來執行 SQL。
4. 驗證 SQL 在 SQL Results View 中成功執行。

定義查詢表

下一步是定義查詢表。圖 3 顯示了一個應用程式所需要的查詢表的高階檢視，以及如何關聯 BPEDB 資料庫中的物理表或檢視。

圖 3. 查詢表關係

樣例應用程式所需的查詢表是基於 SUPLDATA 表中的訪問補充資料和連線 TASK 和 WORKITEM 資料的，是為 Human Task Manager 預定義的。

表 1. 樣例應用程式所需的查詢表

查詢表定義已經建立了，在本文的 專案交換檔案 中提供。首先建立一個補充查詢表，供隨後建立的複雜查詢表引用。使用預定義 TASK 查詢表（圖 4）將連線定義在補充查詢表中。

圖 4. DW.SUPLDATA 查詢表屬性

DW.ASSIGNED 查詢表將被定義來返回 SUPLDATA 表中的所有列以及 TASK 表中的 TKIID 列。當任務被分配之後，授權級別僅限於個人。過濾器將定義在 Task 型別、State (Claimed)、Name 和 Namespace 欄位來消除其他型別的任務返回。如果一個任務存在，資料將被放置在任務的 HTTP 會話中來完成後續步驟，如果只返回狀態為已申明的任務，過濾器要被新增到查詢表。

DW.ASSIGNED 查詢表（圖 5）需要檢索分配給使用者的任務，但是，如果有錯誤就不能完成。這個操作在新任務申明之前完成。這保證一次只有一個任務分配給使用者。

圖 5. DW.ASSIGNED 查詢表屬性

DW.CLAIM 是最終查詢表，返回一個任務作為潛在所有者工作專案的一部分，潛在所有者源自於 WORKITEM 檢視中的 Group 工作專案行，與呼叫者 ID 相匹配。注意查詢表必須是 TASK 查詢表。授權僅限於 Groups，而且過濾器設定為 Task 型別、State (Ready)、Name 和 Namespace。

在此版 Integration Developer 中，查詢表被部署到您工作空間的伺服器中。切換到查詢表檢視並右鍵單擊每個查詢表，從 DW.SUPLDATA 查詢表開始（因為它被後面的查詢表引用），然後選擇 Test on local WebSphere Process Server 選單選項。輸入管理員 ID 和密碼，然後選擇 Deploy 按鈕。

通過驗證控制檯中的成功訊息，確認 3 個查詢表已經全部成功部署到伺服器。操作完成之後，關閉查詢表測試視窗。

回頁首

人工任務模板定義

業務整合模組包含任務模板（圖 6），它是基於一個 To-do 任務建立的，有一個名稱 “ConAccTask” 和一個名稱空間 http://com.ibm.ca/htm。這是匯入工作空間的專案交換檔案其中一部分。

圖 6. 人工任務模板屬性

在這個例子中，Administrators 和 Potential Creators 將被設定為 cn=managers,o=defaultWIMFileBasedRealm 的 Group Id，這是標準 Integration Developer 安裝的一部分。Potential Owners 被設定為一個執行時變數值，分配給任務的輸入訊息，供執行時變數 %htm:input.TaskRequest\GroupDn% 參考。

在此樣例中所有組和使用者所用的是 Integration Developer V7 預設安裝。試用樣例應用程式時，沒有必要建立任何額外組或使用者。

回頁首

使用併發存取測試 servlet

當您想執行併發任務測試時，動態 Web 應用程式中的 servlet 常用來以一種不復雜的方法執行測試、與 JMeter 互動。

servlet 將實現四個不同的方法，如表 2 所示，這些方法將根據 HTTP 請求中的 “action” 引數來執行。servlet 與 Human Task Manager 相互作用並儲存必要任務資料，完成 HTTP 會話中的任何訂閱請求。不再需要在活動之間傳輸 Task ID ，簡化了 JMrter 測試。

表 2. 測試 servlet 實現的方法

Servlet 安全配置

應用程式一個很重要的部分就是在部署描述符中定義的安全屬性。這些設定需要傳送安全證照給 Human Task Manager，將依次根據 Caller Principal（Subject 的一部分）確定任務的所有者或所有關係。圖 7 展示了在 Web 專案中定義的安全形色和在應用程式中配置的繫結。設定指出 servlet 要求所有經過認證的使用者要有一個使用者名稱和密碼 。

由於 JEE 5 規範的實施，使得安全性的定義不同於早期版本。早期定義安全形色的方法是使用 Web Application Project 中的 Security Editor。本例建立一個名為 “AllAuthRole” 的 Security Role，並將其與所有資源聯絡起來。

圖 7. Web 應用程式安全屬性

在應用程式的部署描述符中不再有一個 “聚集” 選項。這是通過部署描述符編輯器手工操作的。如果您需要建立一個新的應用程式，右鍵單擊 EAR 專案並選擇 Java EE > Generate WebSphere Bindings Deployment Descriptor，一個 ibm-application-bnd.xml 檔案被建立，這樣您就可以使用 “All Authenticated Users” 新增 Security Role。如圖 8 所示。

圖 8. 繫結安全屬性的應用程式

用查詢表方法宣告

帶有物件 FilterOptions、AuthorizationOptions 和 Retry Count 的查詢表 “DW.CLAIM” 被傳遞到方法（清單 1）。重試僅用於查詢表執行時出現併發異常且查詢表需要重新申明的情況下。當任務被建立且儲存在補充資料中時，根據任務重要性定義一個 Sort Attribute，這是一個接收的引數。這將為您提供根據預定義次序宣告任務的功能。ClaimResult 物件是申明請求的響應，包含任務 ID，TKIID，它現在分配給呼叫使用者。

清單 1. 用查詢表方法申明

				
FilterOptions filter = new FilterOptions();
filter.setDistinctRows(true);
filter.setSortAttributes("IMPORTANCE ASC");

AuthorizationOptions authorization = new AuthorizationOptions();
authorization.setGroupsUsed(true);

int RETRY_COUNT = 5;

List list = null;

try {
  ClaimResult cr = lHtm.claim("DW.CLAIM", filter, authorization, 
   list, 
              RETRY_COUNT);
  if (cr != null and cr.getTKIID() != null) {
    tkiid = cr.getTKIID();
	setTkiidInSession(request, tkiid);
	response = tkiid.toString();
  } else {
    logger.info("No more tasks to claim, please create more!!!");
  }
} catch (Exception e) {
	e.printStackTrace();
	response = "ERROR: " + e.getMessage();
}

建議您更詳細地檢視 servlet，理解該測試所需的其他方法。

回頁首

測試併發性

正如前面提到的，免費 Apache JMeter v2.3.4 負載測試應用程式 更適合在樣例應用程式中測試併發性。

3 個獨立的測試案例被建立，作為專案交換檔案的一部分位於 JMeterTestCased 專案中。測試案例完成以下任務：

• 建立足夠任務來執行後續併發測試。
• 查詢之前建立的任務來分配和完成任務。這個測試案例使用兩個使用者來模擬查詢表申明方法中的併發存取。
• 查詢任務和前面的一樣，但是現在呼叫非同步方法來查詢和申明任務。這個查詢案例用來展示不使用首選方法時可能出現的錯誤。

1. 將測試案例檔案 ConcurrentAccTests.jmx 和 users.txt 檔案從 JMeterTestCases 專案的測試案例目錄下複製到 JMeter 安裝位置的 testplans 目錄下。
2. 通過選擇 JMeter 安裝位置的 bin 目錄下的 JMeter.bat 檔案來啟動 JMeter 應用程式。
3. 從 File > Open 選單開啟之前複製的 ConcurrentAccTests.jmx 檔案來檢視 Navigation Area 中的 3 個 Thread Groups，如圖 9 所示。
   
   圖 9. JMeter 桌面應用程式檢視
   
   
   
4. 如圖 9 所示通過紅色箭頭，將所有 Thread Groups (Tests) 從 Tests 節點拖放到 Workbench 節點。改變埠號匹配您 WebSphere Process Server 測試環境的 HTTP 埠（預設是8080）。

執行測試來建立任務

您將要執行的第一個測試是建立一些任務來進行後續測試。

1. 將 1-Create Tasks 從 Workbench 節點拖放到 Tests 節點。
2. 擴充套件 1-Create Tasks 節點並在樹中選擇 Configure Creator User Element。測試案例使用 Integration Developer 中的標準使用者來進行測試，但是這可以根據需要修改。您可以修改使用者在配置元素中建立任務。
3. 通過選擇 Run > Clear All 選單選擇啟動，執行任務之前重置所有報告資料，確保 Process Server Test 伺服器正在執行，並確保可以在 Integration Developer 中檢視控制檯訊息。
4. 現在，選擇 Run > Start 選單選項。通過觀察控制檯中的輸出可以看到測試正在執行，也可以看到 JMeter 視窗右上角的小盒子變綠（可能很快）。
5. 測試完成後，如果控制檯中沒有報告錯誤，啟動 Integration Developer 中的 Business Process Choreographer Explorer 來確保有 100 個新任務被建立。如圖 10 所示。
   
   圖 10. 在 BPC Explorer 中檢視任務數量
   
   
   

執行查詢表測試

下一個將要執行的測試是呼叫該方法的 “2-Query Table Test”，它使用查詢表進行申明。

1. 將 1-Create Tasks 測試從 Tests 節點拖放到 Workbench 節點，並將 2-Query Table Test 測試從 WorkBench 節點拖放到 Tests 節點。
2. 使用 CRTL-E 清理結果，並使用 CRTL-R 像之前那樣執行測試。該測試案例使用 user.txt 檔案作為使用者輸入檔案，這將同時申明且完成 50 個任務。
3. 切換回 BPC Explorer 並確認任務數量。現在您將看到的確有 50 個任務已完成。回到控制檯，這應該沒有錯誤報告。

執行非同步測試

為了建立對使用非同步程式碼時所出現的錯誤的理解，執行 “3-Unsync Test”。

1. 將 2-Query Table Test 從 Tests 節點拖放到 WorkBench 節點，並將 3-Unsync Test 移到 Tests 節點。該測試案例也使用 user.txt 檔案作為使用者輸入，將同時申明且完成 50 個任務，如果一切順利的話。兩個使用者同時迴圈進行兩個活動。
2. 測試結束時，您將在控制檯中看到一些或者兩個這種型別（清單 2 ）的異常。
   
   清單 2. 控制檯中可能存在的異常
   

   CWTKA0062E: Task instance state 'Claimed' of task '_TKI:a01b0127.e586669b. d6d5bef6.cd5e0000' does not allow the requested action 'claim()'. or CWTKA0024E: The '_TKI:a01b0127.e593764b.d6d5bef6.cd5e09ea' task does not exist.

   
   

這僅僅是一些可能的異常，但根據硬體和資料庫，您可以使用該測試生成的大量異常。測試結束時，您可以在 BPC Explorer 中核實任務數量。儘管測試案例試圖宣告且完成全部 50 個剩餘任務，但仍然有些任務沒有完成。

回頁首

結束語

本文著重介紹了 Human Task Manager 中使用查詢表方法的新申明。用一個簡單的樣例應用程式證明該方法可在沒有任何併發性異常的情況下使用 Apache JMeter 測試存取。樣例應用程式決不能部署到產品系統中，只是展示了測試客戶構建 Human Task Manager 應用程式所需的元件。查詢表是一個有用的附加特性，已在 WebSphere Process Server 中使用，可以用於任何客戶端應用程式。

原文連結：http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1006_vanzyl/1006_vanzyl.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-673756/，如需轉載，請註明出處，否則將追究法律責任。