WebSphere Business Events 進行業務事件處理

CloudSpace發表於2009-05-20

轉自DW中國

作者:Doina Klinger, 顧問軟體工程師, IBM
Latha Sivakumar, 顧問軟體工程師, IBM

概述

本文是一個系列中的第一篇文章,此係列介紹 WebSphere Business Events(以下稱為 Business Events),並說明如何將其與 WebSphere 系列中的其他產品一起使用,例如 WebSphere Enterprise Bus、WebSphere Process Server、WebSphere Message Broker 和 WebSphere Business Monitor。在第 1 部分中,您將瞭解 Business Events 在整合企業應用程式方面的業務價值,以及核心的 Business Events 概念和工具。第 2 部分將描述有關如何開發和測試一個簡單的 Business Events 應用程式的逐步過程。本系列中的其他文章將說明如何將該應用程式與其他 WebSphere 產品整合。

業務事件處理

企業在不斷變化的相互聯絡的事件環境中運作。客戶事務、利率更改、供應商訂單、物流難題以及從颶風到罷工的意外外部事件全都會影響企業。

通常,巨量的實時資料使得確定這些事件中的模式變得非常困難。這種困難可能意味著錯失新機會、當需要出現時的資源重定向延遲,以及應對意外情況的苦苦掙扎。

業務事件處理(business event processing,BEP)軟體幫助企業實時檢測、評估事件模式並對其做出反應,從而滿足業務目標。對於業務流程管理(business process management,BPM)領域,BEP 新增了實時事件檢測和動態流程以響應這些模式。

有關更多資訊,請參閱 IBM 的業務事件處理:智慧 SOA 解決方案

WebSphere Business Events 可以在以下情況下處理來自不同應用程式的事件:

  • 邏輯路徑不可預測,並且要求跨多個應用程式按時間和順序對活動進行檢測和關聯(非線性處理)
  • 業務邏輯頻繁更改(動態處理)
  • 實時監視結果並自動響應活動趨勢是關鍵要求。這提供了活動監視的閉環。

Business Events 增強了現有的 BPM 和麵向服務的體系結構(Service-Oriented Architecture,SOA)基礎結構。

WebSphere Business Events

Business Events 提供了易於使用的圖形創作工具,您可以將其用於定義業務策略和邏輯,以便響應您感興趣的業務事件和模式,以及發起相應的業務操作。業務策略對非技術使用者來說也很容易閱讀,並鬆散地遵循普通語言中描述的規則。策略描述系統將如何對某些組合中或在某些時間發生或未發生的事件做出反應。它們允許您檢測和分析人員、事件以及資訊之間的簡單和複雜關係,並動態地對其做出反應。

事件可能來自於各種各樣的系統和應用程式,這些系統和應用程式可能連線也可能沒有連線。Business Events 可以關聯和確定所有這些來源中的模式,然後生成將由外部系統使用的操作,或者生成將傳送到 Business Events 的新事件。

圖 1 演示了 Business Events 在管理方面表現出色的一些業務情形。可以看到,存在不同時間期限內來自不同來源的多個事件需要考慮:股票交易、帳戶開立、密碼更改、帳戶概要更新、帳戶經理訪問、帶交易指令的電子郵件、客戶更改詳細資訊和大額提款。Business Events 可以通過實時查詢非順序和非線性的關聯和模式,從而使所有這些異構來源的不同事件變得有意義。


圖 1. 概述:檢測事件、制定決策以及交付操作
業務事件流

示例場景

在本系列中,我們將使用一個示例場景來說明 Business Events 是如何工作的。在此場景中,我們需要檢測交易系統中的投機行為。該場景需要確定並相應地響應隨時間推移而形成的事件模式。

請考慮一個接收買入和賣出請求的交易系統。需要對該系統進行監視以瞭解實時交易資料中的特定模式。我們對大量交易事件(或訊息)中可能指示投機行為的模式感興趣。我們將定義兩個策略來確定此類情形:Sell 和 Buy 事件具有描述客戶、股票、交易發生的日期和時間、股份數額和價格的屬性。當相同客戶在 Buy 事件後一小時內針對相同股票發生 Sell 事件時,將生成一個 SellAfterBuy 操作。如果一個客戶一天內針對相同或不同股票在買入後執行了三次賣出,則會生成一個 SpeculativeCustomer 操作。這些操作就是 Business Events 輸出。其他外部系統可以處理這些操作,您將在本系列的後續部分中看到這一點。

我們的示例場景是金融業中的規章遵從性用例的簡化版本的應用。經紀人需要識別投機交易,法律法規要求他們在某些情況下報告此類情況。

Business Events 體系結構

圖 2 顯示了 WebSphere Business Events 執行時體系結構的主要元件。


圖 2. Business Events 執行時體系結構
Business Events 體系結構

  • 執行時伺服器是 Business Events 的核心。這是執行業務事件處理邏輯的地方。
  • 聯結器是通過各種各樣的協議在接觸點之間來回提供無程式碼連線的內部系統元件。
  • 儲存庫為 Business Events 資產的定義提供共享的安全儲存。

Business Events 工具

Business Events 附帶了兩個針對不同使用者角色的核心工具:

  • Design Data 工具用於定義將與 Business Events 互動的外部業務系統,以及所需的資料物件。此工具的典型使用者是負責 IT 連線的 IT 專業人員。
  • Design 工具用於定義業務事件規則,這些規則描述當事件進入 Business Events 以及確定了某些模式時將怎麼辦。此工具的典型使用者是業務分析人員,他們可以分析規則並根據需要修改規則,以響應不斷變化的條件。

在本部分中,我們將介紹這些工具,我們將在整個系列中提到並使用這些工具。本系列中未討論的其他 Business Events 工具包括 Administration、Dashboards、Design Dashboards、Properties 和 User Console。在第 2 部分中,您將更詳細地瞭解如何使用這些工具。有關這些工具的更多資訊,請參考 WebSphere Business Events V6.1 資訊中心

Design Data 工具

Design Data 工具的主要元件如下:

  • 接觸點表示針對 WebSphere Business Events 傳送和接收事件的外部系統或應用程式。該示例應用程式中定義的接觸點是 TradeSystem。生產 Business Events 應用程式中會定義多個接觸點,並且事件來自於各種各樣將進行關聯並確定其模式的來源。為簡單起見,我們將在該示例應用程式中使用單個接觸點。
  • 事件確定接觸點中將觸發 Business Events 中的某些計算的活動。在該示例應用程式中,我們將定義 Buy 和 Sell 事件。事件由一個或多個事件物件組成。
  • 事件物件是已定義的資料欄位集。Buy 和 Sell 事件共享一個名為 TradeObject 的事件物件,該物件具有欄位 CustomerID、StockID、Quantity、Price、Date。
  • 操作確定當 Business Events 中的一個或多個規則為 true 時將在接觸點中發生的活動。該示例中定義的操作包括 SellAfterBuy Speculative Customer。操作由一個或多個操作物件組成。
  • 操作物件是一組已定義的資料欄位。TradeOut 操作物件由該示例應用程式中的所有操作共享。
  • 人工事件是取代互動塊中的某個操作而被使用的結果事件。人工事件允許互動塊直接呼叫另一個事件,這對於複雜事件處理會非常有用,其中複雜事件可作為不同事件被觸發,而不是立即進行處理。
  • 中間物件是業務物件的概念表示形式,通常在不同的應用程式或系統中(從而在不同的事件和操作物件中)以不同的名稱或採用不同的格式進行描述。中間物件在新事件進入 Business Events 時被建立,其部分欄位是從事件欄位複製來的,部分欄位是計算得來的,還有部分欄位則設定為常量,或者是從資料庫表填充的。在我們的示例中,我們有一箇中間物件 TradeObject。
  • 資料來源是附加的資料來源,例如關聯式資料庫或 Excel 電子表格。它們通常用於計算事件中不存在的中間物件欄位。例如,基於事件的 customerID 欄位,針對資料庫表使用 SELECT 語句來計算地址欄位。從資料來源檢索資料的過程稱為資料獲取。資料庫可以是託管的(例如在 DB2® 或Oracle® 中)、本地的(例如 Microsoft® Excel 電子表格),或者是遠端的。可以將中間物件的一個或多個欄位對映到某個表中的列。
  • 聯結器在接觸點和執行時使用的 JMS 訊息主題之間傳遞資料有效負載(定義為 XML 訊息)事件聯結器識別接觸點中的事件,並通過諸如 HTTP 等協議將資料直接或間接傳遞到一個內部 Java™ Message Service (JMS) 訊息佇列,以便由一組已定義的互動策略進行評估。類似地,操作聯結器取得業務流程規則評估的結果,以有效負載的形式從內部 JMS 訊息佇列檢索一個操作,並將其傳遞給接觸點。操作聯結器也可以返回結果,該結果放在入站訊息佇列中,並且可以將其作為結果事件進行評估。

圖 3 顯示了 Design Data 工具的示例。在左側,您可以看到資產樹,相關定義分組在三個部分中:

    • 資料來源
    • 中間物件
    • 接觸點

在右側,您可以看到所選物件的編輯器。


圖 3. Design Data 工具
Design data 工具

Design 工具

Design 工具的主要元件包括:

  • 互動塊 互動集。互動塊描述在某些條件或篩選器得到滿足時,由於事件到達 Business Events 中而觸發的操作。由相同事件同時觸發的一個或多個相關塊的組稱為互動集。屬於某個策略的一部分的規則可能附加了不同的篩選器,或者可能應用於不同接觸點中的操作。在我們的示例中,我們擁有 SellAfterBuy 和 SpeculativeCustomer 互動策略。
  • 上下文是通過名為 context ID 的中間物件欄位關聯在一起的一組互動集。上下文 ID(例如,客戶 ID)唯一地標識流經某個流的一組公共事件。函式和篩選器的評估針對具有相同上下文 ID 的事件進行。在我們的示例中,SellAfterBuy 策略使用的上下文 ID 是客戶 ID 和股票 ID 的組合。當為策略定義了上下文關係時,函式(例如某個事件的 Occurrences of)將引用與所評估的事件具有相同上下文 ID 的所有事件。
  • 篩選器是出現在一個或多個規則中的條件。篩選器中表達的條件可能非常簡單,例如測試單個資料欄位的值;或者相當複雜,涉及到隨時間推移而發生(或未發生)的多個事件的模式。我們的應用程式中的篩選器為 After Buy 和 Speculative Customer。
  • 事件流是業務流程的可執行圖形表示形式。它們包括一組互動集,以及相關業務步驟,這些步驟表示預期要在所觸發的操作之後發生的事件。

圖 4 顯示了取自 Design 工具的示例螢幕快照。資產樹顯示了互動集和篩選器。Design 工具中的定義、帶有事件和操作的接觸點以及中間物件可供檢視,但不能修改。


圖 4. 顯示互動集和篩選器的 Design 工具
Design 工具

本系列中的後續文章

本系列中的後續文章將教您如何檢測業務事件模式,並向您介紹如何將 Business Events 與其他 WebSphere 產品和技術整合。

  • 在第 2 部分中,您將瞭解如何構建和測試該示例應用程式,以檢測交易資料中的模式。您將瞭解如何使用 Design Data 工具來定義諸如事件和操作等資料。您還將瞭解如何使用 Design 工具來定義篩選器和互動集。最後,您將瞭解如何部署和測試 Business Events 應用程式。
  • 在第 3 部分中,您將瞭解如何整合 WebSphere Message Broker 和 Business Events,以篩選訊息並將其轉換為事件,然後形成操作。Business Events 檢測生成操作的事件中的模式。
  • 在第 4 部分中,您將瞭解如何將 Business Events 與 WebSphere Process Server 和 WebSphere Enterprise Service Bus (WebSphere ESB) 整合,以便將 WebSphere ESB 中的訊息作為事件傳送到 Business Events,後者檢測模式並將結果操作發回 WebSphere ESB 進行處理。
  • 在第 5 部分中,您將瞭解如何將 Business Events 與 WebSphere Business Monitor (Monitor) 整合,以便 Business Events 能夠以 Monitor 伺服器能夠接收和處理的格式轉發業務事件。然後 Monitor 可以進行分析並提供有關接收到的業務資料的報告。Monitor 儀表板還提供了全面的圖表、報告和通知集,可將其用於監視從 Business Events 接收的資料並對該資料採取行動。
  • 在第 6 部分中,您將瞭解如何配置 Business Events 以接受並生成通過公共事件基礎結構(Common Event Infrastructure,CEI)傳輸的公共基礎事件 (Common Base Event)。

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

相關文章