復合事件處理方法及裝置的制作方法

專利名稱：復合事件處理方法及裝置的制作方法
技術領域：
本申請涉及網絡技術領域，尤其涉及一種復合事件處理方法及裝置。
背景技術：
基于互聯網實現各種業務功能時，會產生海量的基礎事件(Base Event)，包括各種銷售數據、業務數據、系統之間的交互數據等，這些基礎事件僅反映了業務功能的片面信息，且信息量龐大，難以從中獲取有用信息。因此，需要對海量的基礎事件進行處理以提取出有用的復合事件(Complex Event) 0例如，某個商品銷售時被POS機掃描，此時會觸發一個基礎事件至后臺服務器，而后臺服務器結合眾多商品出售的基礎事件，分析得到該商品的銷售趨勢信息即為復合事件處理后得到的復合事件信息。現有技術中，復合事件處理(Complex Event I^rocess，CEP)基于數據庫系統實現，預先對基礎事件進行分類，同一類型的基礎事件具有相同的字段，用于保存基礎事件的信息，同一類型的基礎事件被存放在數據庫的同一個數據庫表中；多個有關聯的基礎事件形成一種事件模式，以支付寶(www.alipay.com)的擔保交易為例，擔保交易為一種事件模式，這個事件模式下包含了相互關聯的五個基礎事件，分別為創建交易、買家付款到中介機構、賣家發貨、買家收貨和中間機構付款到賣家；在進行復合事件處理時，采用結構化查詢語言(Structured Query Language, SQL)對數據庫表進行查詢，從中找出復合事件，例如， 如果從數據庫表中依次找到擔保交易模式的五個基礎事件，則表示找到一個交易正常完成的復合事件，如果無法順序查找到這五個基礎事件，則返回交易系統異常的復合事件，進行報警。發明人在對現有技術的研究過程中發現，現有復合事件處理都基于數據庫實現， 每個數據庫表要預先定義字段及對字段的限制，因此難以根據實際應用靈活調整，并且數據庫內需要存儲海量的基礎事件信息，因此將占用系統的大量存儲空間；另外，數據庫查詢語言難以描述和查詢復雜的復合事件，因此限制了復合事件處理的應用范圍。

發明內容
本申請實施例的目的是提供一種復合事件處理方法及裝置，以解決現有技術中基于數據庫進行復合事件處理時占用大量存儲空間，且難以對復雜事件進行處理的問題。為解決上述技術問題，本申請實施例提供了一種復合事件處理方法，是這樣實現的—種復合事件處理方法，所述方法包括接收到基礎事件后，根據所述基礎事件的事件信息確定所述基礎事件所屬的事件模式，所述基礎事件中攜帶事件標識；將所述基礎事件輸入與所述事件標識對應的狀態機實例，所述狀態機實例為按照所述基礎事件所屬的事件模式定義的狀態機所創建的實例，屬于同一個狀態機實例的基礎事件具有相同的事件標識；
根據所述狀態機實例的狀態遷移結果輸出復合事件。為解決上述技術問題，本申請實施例還提供了一種復合事件處理裝置，是這樣實現的一種復合事件處理裝置，包括接收單元，用于接收基礎事件；確定單元，用于根據所述基礎事件的事件信息確定所述基礎事件所屬的事件模式，所述基礎事件中攜帶事件標識；輸入單元，用于將所述基礎事件輸入與所述事件標識對應的狀態機實例，所述狀態機實例為按照所述基礎事件所屬的事件模式定義的狀態機所創建的實例，屬于同一個狀態機實例的基礎事件具有相同的事件標識；輸出單元，用于根據所述狀態機實例的狀態遷移結果輸出復合事件。可見，本申請實施例中接收到基礎事件后，根據基礎事件的事件類型確定基礎事件所屬的事件模式，將基礎事件輸入與該基礎事件的事件標識對應的狀態機實例，并根據狀態機實例的狀態遷移結果輸出復合事件。由于本申請復合事件處理的實施例無需數據庫支持，通過狀態機實例的狀態遷移結果輸出復合事件，由此節約了系統為存儲大量基礎事件所耗費的存儲空間，并且由于可以根據實際應用需求變換對某個事件模式的狀態機定義，因此增強了系統對復合事件處理的靈活性；由于復合事件的處理都基于狀態機進行，無需運用大量的查詢語言，因此只需定義狀態機，就可處理各種復雜的復合事件，擴展了復合事件處理的應用范圍。


為了更清楚地說明本申請實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請中記載的一些實施例，對于本領域普通技術人員來講，在不付出創造性勞動性的前提下，還可以根據這些附圖獲得其他的附圖。圖1為本申請復合事件處理方法的第一實施例流程圖；圖2A為本申請復合事件處理方法的第二實施例流程圖；圖2B為本申請一種應用實例中擔保交易的事件模式狀態機定義示意圖；圖3為本申請復合事件處理裝置的第一實施例框圖；圖4為本申請復合事件處理裝置的第二實施例框圖。
具體實施例方式本申請實施例提供一種復合事件處理方法及裝置，對接收到的基礎事件，根據預先定義的事件模式對應的狀態機輸出相應的復合事件，從而可以針對復合事件進行報警或者對復合事件進行所需要的處理。為了使本技術領域的人員更好地理解本申請實施例中的技術方案，并使本申請實施例的上述目的、特征和優點能夠更加明顯易懂，下面結合附圖對本申請實施例中技術方案作進一步詳細的說明。參見圖1，為本申請復合事件處理方法的第一實施例流程圖
步驟101 接收到基礎事件后，根據基礎事件的事件信息確定該基礎事件所屬的事件模式。事件模式是對一系列相互關聯的基礎事件的總稱，每種事件模式都包含了順序執行的多個基礎事件。以支付寶的擔保交易為例，擔保交易是一種需要關心是否發貨的事件模式，擔保交易包括的基礎事件有創建交易、買家付款到中間機構、賣家發貨、買家收貨和中間機構付款到賣家；另外，即時到賬也是一種事件模式，這種事件模式不需要關心是否發貨。本申請實施例中，為每種事件模式定義一個狀態機，這個狀態機中包含了若干遷移狀態，從初始狀態開始，該事件模式包含的順序執行的每個基礎事件都對應一個遷移狀態，以一個包含三個基礎事件的事件模式A為例，假設基礎事件的執行順序應為基礎事件 1、基礎事件2、基礎事件3，則從初始狀態開始，應順序執行基礎事件1，相應的從初始狀態遷移到狀態1，然后執行基礎事件2，相應的從狀態1遷移到狀態2，最后執行基礎事件3，相應的從狀態2遷移到結束狀態。每個基礎事件中都攜帶了事件信息，以擔保交易中的創建交易這個基礎事件為例，該基礎事件的事件類型就為“創建交易”，其包含的事件信息包括交易序號、買家賬號、 賣家賬號、商品描述、交易金額、事件模式。當接收到一個創建交易的基礎事件后，根據該基礎事件的事件信息就可以確定該基礎事件所屬的事件模式為“擔保交易”。當系統中定義了多個事件模式時，可以為每個事件模式分配一個模式標識，則通過在基礎事件中攜帶該模式標識來實現對其所屬事件模式的識別。步驟102 將該基礎事件輸入與其事件標識對應的狀態機實例。仍然以擔保交易這個事件模式為例，在該事件模式定義的狀態機下，可能需要處理若干筆交易，則為每筆交易都創建一個狀態機實例，屬于同一個狀態機實例的基礎事件都具有相同的事件標識，這個事件標識應可以唯一識別一筆交易，例如使用交易序號。在擔保交易所定義的狀態機中，各個基礎事件攜帶的事件信息如下創建交易攜帶事件信息交易序號、買家帳號、賣家帳號、商品描述、交易金額、事件模式；買家付款到中間機構攜帶事件信息交易序號、買家帳號、交易金額；賣家發貨攜帶事件信息交易序號、賣家帳號、商品描述；買家收貨攜帶事件信息交易序號、買家帳號、商品描述；中間機構付款到賣家攜帶事件信息交易序號、賣家帳號、交易金額。由此可知，上述擔保交易的每個基礎事件中都包含了“交易序號”，因此可以將交易序號作為每個狀態機實例的唯一標識，當接收到一個基礎事件后，讀取該基礎事件中的交易序號，就可以將該基礎事件輸入到與該交易序號唯一對應的狀態機實例中。步驟103 根據狀態機實例的狀態遷移結果輸出復合事件，結束當前流程。查找狀態機實例所遷移的當前狀態，根據基礎事件的事件類型判斷狀態機實例是否能夠從當前狀態順序遷移到下一狀態，若判斷結果為是，則遷移到下一狀態，并進一步判斷下一狀態是否為狀態機實例的結束狀態，若是結束狀態，則輸出系統事件完成的復合事件，若不是結束狀態，則將下一狀態保存為狀態機實例的當前狀態；若不能從當前狀態遷移到下一狀態，則輸出系統異常的復合事件。
仍然以前述包含三個基礎事件的事件模式為例，假設當前收到基礎事件2，在找到該基礎事件2對應的狀態機實例后，可以查看該狀態機實例當前所遷移的狀態，假如該狀態機實例已經遷移到狀態1，則根據接收的基礎事件2可以判斷該狀態機實例能夠從狀態 1遷移到狀態2，由于狀態2仍然不是該狀態機實例的結束狀態，因此保存狀態2為該狀態機實例的當前狀態，以便后續接到其它基礎事件后依據該保存的當前狀態進行復合事件處理；假如該狀態機實例已經遷移到狀態2，則根據接收的基礎事件2判斷該狀態機實例無法進行狀態遷移，因此輸出系統異常的復合事件，并可據此結果進行報警。參見圖2A，為本申請復合事件處理方法的第二實施例流程圖，該實施例示出了復合事件處理的詳細過程步驟201 預先為每個事件模式定義狀態機，該狀態機中包含按照基礎事件的事件類型順序遷移的若干狀態。參見圖2B為，為一種擔保交易的事件模式狀態機定義示意圖其中，擔保交易包括的基礎事件有基礎事件1 (創建交易)、基礎事件2 (買家付款到中間機構)、基礎事件3 (賣家發貨)、基礎事件4 (買家收貨)和基礎事件5 (中間機構付款到賣家)；相應的，擔保交易的狀態機中包含了六個狀態，分別為狀態1(初始狀態)、狀態 2 (等待買家付款)、狀態3 (等待賣家送貨)、狀態4 (等待買家收貨)、狀態5 (等待向賣家付款)和狀態6 (結束狀態)。結合圖2B，描述該狀態機的完整狀態遷移過程初始，狀態機處于狀態1 ；接收到基礎事件1(創建交易，ET-CREATE)后狀態變遷，進入狀態2 (等待買家付款)，此時只需要記錄當前的狀態為狀態2，不需要保留基礎事件1的所有事件信息；接收到基礎事件2 (買家付款到中間機構，ET-BUYER-TO-ALIPAY)后狀態變遷，進入狀態3 (等待賣家送貨)，此時只需要記錄當前的狀態為狀態3，不需要保留基礎事件1和基礎事件2的所有事件信息；接收到基礎事件3 (賣家發貨ET-SELLER-SHIP)后狀態變遷，進入狀態4 (等待買家收貨)，此時只需要記錄當前的狀態為狀態4，不需要保留基礎事件1、基礎事件2和基礎事件3的所有事件信息；接收到基礎事件4 (買家收貨，ET-BUYER-RECEIVE)后狀態變遷，進入狀態5 (等待向賣家付款)，此時只需要記錄當前的狀態為狀態5，不需要保留基礎事件1、基礎事件2、基礎事件3和基礎事件4的所有事件信息；接收到基礎事件5 (中間機構付款到賣家，ET-ALIPAY-TO-SELLER)后狀態變遷，進入狀態6 (結束狀態)，此時只需要記錄當前的狀態為狀態6，不需要保留基礎事件1、基礎事件2、基礎事件3、基礎事件4和基礎事件5的所有事件信息；當進入狀態6 (結束狀態)時， 表示找到一個復合事件。由于本申請實施例中狀態機可以隨著基礎事件進行狀態遷移，這個過程中只需要記錄當前所遷移到的狀態即可，無需記錄所有基礎事件信息，因此與現有技術相比，節約了大量系統存儲空間。步驟202 接收到基礎事件后，對該基礎事件攜帶的信息進行格式轉換。通常復合事件處理中心可以接收通過網絡傳輸的基礎事件，例如，支付寶交易過程中觸發的每個基礎事件都通過網絡發送到服務器端的復合事件處理中心。通過對基礎事件攜帶的事件信息進行格式轉換得到事件類型、事件標識、事件描述等，以便于根據這些信息執行復合事件處理的后續步驟。轉換后的事件信息可以采用如
下格式字段1 =值1 ；字段2 =值2 ；......；例如，對于一個基礎事件“創建交易”，其轉
換格式后的事件信息包括事件類型=“ET-CREATE”;交易序號=“12212319”;買家帳號= “ 1522326223”;賣家帳號=“242326893”;商品描述= “HL-220 三件”；交易金額=“540. 00”。步驟203 根據基礎事件的事件信息確定基礎事件所屬的事件模式。每個基礎事件中都攜帶了事件信息，以擔保交易中的創建交易這個基礎事件為例，該基礎事件的事件類型就為“創建交易”，其包含的事件信息包括交易序號、買家賬號、 賣家賬號、商品描述、交易金額、事件模式。當接收到一個創建交易的基礎事件后，根據該基礎事件的事件信息就可以確定該基礎事件所屬的事件模式為“擔保交易”。當系統中定義了多個事件模式時，可以為每個事件模式分配一個模式標識，則通過在基礎事件中攜帶該模式標識來實現對其所屬事件模式的識別。步驟204 根據事件標識判斷是否已經創建與該事件標識對應的狀態機實例，若是，則執行步驟207 ；否則，執行步驟205。以擔保交易為例，其所對應的每個狀態機實例都通過“交易序號”來唯一標識，當接收的基礎事件為攜帶了交易序號“12212319”的“創建交易”時，讀取該交易序號，由于 “創建交易”為狀態機中順序執行的首個基礎事件，因此查找不到該交易序號“12212319” 對應的狀態機實例(若創建，則記為實例A)；當接收到的基礎事件為攜帶了交易序號 “22212319”的“買家收貨”時，讀取該交易序號，由于“買家收貨”為狀態機中順序執行的第四個基礎事件，因此通常可以查找到該交易序號22212319”對應的狀態機實例(記為實例 B)。步驟205 判斷該基礎事件的事件類型是否為所創建狀態機的初始狀態對應的事件類型，若是，則執行步驟206 ；否則，執行步驟214。如果判斷還未創建與接收到的基礎事件的事件標識對應的狀態機實例，則需要進一步判斷該基礎事件是否為初始狀態對應的事件類型。以擔保交易為例，當接收到的基礎事件“買家收貨”攜帶的交易序號為“12345”，且未查找到與該交易序號對應的狀態機實例， 此時判斷“買家收貨”對應的狀態并非初始狀態；如果接收到的基礎事件“創建交易”攜帶的交易序號為“12345”，且未查找到與該交易序號對應的狀態機實例，此時判斷“創建交易” 對應的狀態為初始狀態。步驟206 創建與事件標識對應的狀態機實例。如果接收到的基礎事件“創建交易”攜帶的交易序號為“12345”，且未查找到與該交易序號對應的狀態機實例，在判斷“創建交易”對應的狀態為初始狀態后，可以根據交易序號“ 12345”創建一個新的狀態機實例。步驟207 將該基礎事件輸入與其事件標識對應的狀態機實例。步驟208 查找狀態機實例所遷移的當前狀態。假設接收到的基礎事件為“買家收貨”，根據該基礎事件中攜帶的交易序號找到對應的狀態機實例B后，查看該狀態機實例B中的當前遷移狀態。步驟209 根據該基礎事件的事件類型判斷狀態機實例是否能夠從當前狀態順序遷移到下一狀態，若是，則執行步驟210 ；否則，執行步驟213。如果狀態機實例B當前已經順序遷移到了狀態4，則說明該狀態機實例B根據“買家收貨”這個基礎事件4能夠順序遷移到狀態5 ；如果狀態機實例B當前遷移到了除狀態4 外的其它狀態，則說明該狀態機實例B根據“買家收貨”這個基礎事件4難以從當前狀態進行遷移。步驟210 判斷下一狀態是否為狀態機實例的結束狀態，若是，則執行步驟211 ；否則，執行步驟212。步驟211 輸出系統事件完成的復合事件，結束當前流程。狀態機實例的狀態從初始狀態順序遷移到結束狀態后，則表示一個復合事件完成，輸出該復合事件完成的結果。步驟212 將下一狀態保存為狀態機實例的當前狀態，結束當前流程。假設狀態機實例B根據“買家收貨，，這個基礎事件4，從狀態4順序遷移到了狀態 5，由于狀態5不是結束狀態，因此將該狀態5記錄為狀態機實例B的當前狀態。步驟213 輸出系統異常的復合事件，結束當前流程。如果狀態機實例B根據“買家收貨”這個基礎事件4難以從當前狀態進行遷移，則會產生系統異常的復合事件，并可進一步輸出報警信息。步驟214 丟棄該基礎事件，結束當前流程。當接收到的基礎事件“買家收貨”攜帶的交易序號為“12345”，且未查找到與該交易序號對應的狀態機實例，則判斷“買家收貨”對應的狀態并非初始狀態后，說明該基礎事件無用，丟棄該基礎事件即可。與本申請復合事件處理方法的實施例相對應，本申請還提供了復合事件處理裝置的實施例。參見圖3，為本申請復合事件處理裝置的第一實施例框圖。該復合事件處理裝置包括接收單元310、確定單元320、輸入單元330和輸出單元 340。其中，接收單元310，用于接收基礎事件；確定單元320，用于根據所述基礎事件的事件信息確定所述基礎事件所屬的事件模式，所述基礎事件中攜帶事件標識；輸入單元330，用于將所述基礎事件輸入與所述事件標識對應的狀態機實例，所述狀態機實例為按照所述基礎事件所屬的事件模式定義的狀態機所創建的實例，屬于同一個狀態機實例的基礎事件具有相同的事件標識；輸出單元340，用于根據所述狀態機實例的狀態遷移結果輸出復合事件。參見圖4，為本申請復合事件處理裝置的第二實施例框圖。該復合事件處理裝置包括預設單元410、接收單元420、轉換單元430、確定單元 440、判斷單元450、執行單元460、輸入單元470和輸出單元480。其中，預設單元410，用于預先為每個事件模式定義狀態機，所述狀態機中包含按照基礎事件的事件類型順序遷移的若干狀態；接收單元420，用于接收基礎事件；轉換單元430，用于對所述接收單元接收的基礎事件攜帶的信息進行格式轉換，所述格式轉換后的信息包括事件類型、事件標識和事件描述；確定單元440，用于根據所述基礎事件的事件信息確定所述基礎事件所屬的事件模式，所述基礎事件中攜帶事件標識；判斷單元450，用于根據所述事件標識判斷是否已經創建與所述事件標識對應的狀態機實例；執行單元460，用于當所述判斷單元450的判斷結果為是時，觸發所述輸入單元 470的功能；進一步，所述判斷單元450，還用于當所述判斷單元450的判斷結果為否時，進一步判斷所述基礎事件的事件類型是否為所述狀態機的初始狀態對應的事件類型；進一步，所述執行單元460，還用于當所述判斷單元450判斷是初始狀態對應的事件類型時，創建與所述事件標識對應的狀態機實例，當所述判斷單元450判斷不是初始狀態對應的事件類型時，丟棄所述基礎事件；輸入單元470，用于將所述基礎事件輸入與所述事件標識對應的狀態機實例，所述狀態機實例為按照所述基礎事件所屬的事件模式定義的狀態機所創建的實例，屬于同一個狀態機實例的基礎事件具有相同的事件標識；輸出單元480，用于根據所述狀態機實例的狀態遷移結果輸出復合事件。具體的，所述輸出單元480可以包括(圖4中未示出)狀態查找單元，用于查找所述狀態機實例所遷移的當前狀態；狀態判斷單元，用于根據所述基礎事件的事件類型判斷所述狀態機實例是否能夠從所述當前狀態順序遷移到下一狀態；結果執行單元，用于當所述狀態判斷單元的判斷結果為是時，遷移到所述下一狀態，當所述狀態判斷單元的判斷結果為否時，輸出系統異常的復合事件；進一步，所述狀態判斷單元，還用于當遷移到所述下一狀態后，判斷所述下一狀態是否為所述狀態機實例的結束狀態；所述結果執行單元，還用于當所述狀態判斷單元的判斷結果為是時，輸出系統事件完成的復合事件，當所述狀態判斷單元的判斷結果為否時，將所述下一狀態保存為所述狀態機實例的當前狀態。通過以上的實施方式的描述可知，本申請實施例中接收到基礎事件后，根據基礎事件的事件類型確定基礎事件所屬的事件模式，將基礎事件輸入與該基礎事件的事件標識對應的狀態機實例，并根據狀態機實例的狀態遷移結果輸出復合事件。由于本申請復合事件處理的實施例無需數據庫支持，通過狀態機實例的狀態遷移結果輸出復合事件，由此節約了系統為存儲大量基礎事件所耗費的存儲空間，并且由于可以根據實際應用需求變換對某個事件模式的狀態機定義，因此增強了系統對復合事件處理的靈活性；由于復合事件的處理都基于狀態機進行，無需運用大量的查詢語言，因此只需定義狀態機，就可處理各種復雜的復合事件，擴展了復合事件處理的應用范圍。通過以上的實施方式的描述可知，本領域的技術人員可以清楚地了解到本申請可借助軟件加必需的通用硬件平臺的方式來實現。基于這樣的理解，本申請的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟件產品的形式體現出來，該計算機軟件產品可以存儲在存儲介質中，如ROM/RAM、磁碟、光盤等，包括若干指令用以使得一臺計算機設備 (可以是個人計算機，服務器，或者網絡設備等)執行本申請各個實施例或者實施例的某些部分所述的方法。本說明書中的各個實施例均采用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對于系統實施例而言，由于其基本相似于方法實施例，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。本申請可用于眾多通用或專用的計算系統環境或配置中。例如個人計算機、服務器計算機、手持設備或便攜式設備、平板型設備、多處理器系統、基于微處理器的系統、置頂盒、可編程的消費電子設備、網絡PC、小型計算機、大型計算機、包括以上任何系統或設備的分布式計算環境等等。本申請可以在由計算機執行的計算機可執行指令的一般上下文中描述，例如程序模塊。一般地，程序模塊包括執行特定任務或實現特定抽象數據類型的例程、程序、對象、組件、數據結構等等。也可以在分布式計算環境中實踐本申請，在這些分布式計算環境中，由通過通信網絡而被連接的遠程處理設備來執行任務。在分布式計算環境中，程序模塊可以位于包括存儲設備在內的本地和遠程計算機存儲介質中。雖然通過實施例描繪了本申請，本領域普通技術人員知道，本申請有許多變形和變化而不脫離本申請的精神，希望所附的權利要求包括這些變形和變化而不脫離本申請的精神。
權利要求
1.一種復合事件處理方法，其特征在于，所述方法包括接收到基礎事件后，根據所述基礎事件的事件信息確定所述基礎事件所屬的事件模式，所述基礎事件中攜帶事件標識；將所述基礎事件輸入與所述事件標識對應的狀態機實例，所述狀態機實例為按照所述基礎事件所屬的事件模式定義的狀態機所創建的實例，屬于同一個狀態機實例的基礎事件具有相同的事件標識；根據所述狀態機實例的狀態遷移結果輸出復合事件。
2.根據權利要求1所述的方法，其特征在于，還包括預先為每個事件模式定義狀態機，所述狀態機中包含按照基礎事件的事件類型順序遷移的若干狀態。
3.根據權利要求1所述的方法，其特征在于，所述接收到基礎事件后，還包括對所述基礎事件攜帶的事件信息進行格式轉換，所述格式轉換后的事件信息包括事件類型、事件標識、事件描述、事件模式之一或其組合。
4.根據權利要求1所述的方法，其特征在于，所述將基礎事件輸入與所述事件標識對應的狀態機實例之前還包括根據所述事件標識判斷是否已經創建與所述事件標識對應的狀態機實例；若判斷結果為是，則執行所述將基礎事件輸入與事件標識對應的狀態機實例，若判斷結果為否，則創建與所述事件標識對應的狀態機實例。
5.根據權利要求4所述的方法，其特征在于，還包括當所述判斷結果為否時，判斷所述基礎事件的事件類型是否為所述狀態機的初始狀態對應的事件類型；若判斷結果為是，則執行所述創建與事件標識對應的狀態機實例，若判斷結果為否，則丟棄所述基礎事件。
6.根據權利要求1至5任意一項所述的方法，其特征在于，所述根據所述狀態機實例的狀態遷移結果輸出復合事件包括查找所述狀態機實例所遷移的當前狀態；根據所述基礎事件的事件類型判斷所述狀態機實例是否能夠從所述當前狀態順序遷移到下一狀態；若判斷結果為是，則遷移到所述下一狀態，否則判斷結果為否，則輸出系統異常的復合事件。
7.根據權利要求6所述的方法，其特征在于，還包括當遷移到所述下一狀態后，判斷所述下一狀態是否為所述狀態機實例的結束狀態；若判斷結果為是，則輸出系統事件完成的復合事件，若判斷結果為否，則將所述下一狀態保存為所述狀態機實例的當前狀態。
8.一種復合事件處理裝置，其特征在于，包括接收單元，用于接收基礎事件；確定單元，用于根據所述基礎事件的事件信息確定所述基礎事件所屬的事件模式，所述基礎事件中攜帶事件標識；輸入單元，用于將所述基礎事件輸入與所述事件標識對應的狀態機實例，所述狀態機實例為按照所述基礎事件所屬的事件模式定義的狀態機所創建的實例，屬于同一個狀態機實例的基礎事件具有相同的事件標識；輸出單元，用于根據所述狀態機實例的狀態遷移結果輸出復合事件。
9.根據權利要求8所述的裝置，其特征在于，還包括預設單元，用于預先為每個事件模式定義狀態機，所述狀態機中包含按照基礎事件的事件類型順序遷移的若干狀態。
10.根據權利要求8所述的裝置，其特征在于，還包括轉換單元，用于對所述接收單元接收的基礎事件攜帶的事件信息進行格式轉換，所述格式轉換后的事件信息包括事件類型、事件標識和事件描述、事件模式之一或其組合。
11.根據權利要求8所述的裝置，其特征在于，還包括判斷單元，用于根據所述事件標識判斷是否已經創建與所述事件標識對應的狀態機實例；執行單元，用于當所述判斷單元的判斷結果為是時，觸發所述輸入單元的功能，當所述判斷單元的判斷結果為否時，創建與所述事件標識對應的狀態機實例。
12.根據權利要求11所述的裝置，其特征在于，所述判斷單元，還用于當判斷結果為否時，進一步判斷所述基礎事件的事件類型是否為所述狀態機的初始狀態對應的事件類型；所述執行單元，還用于當所述判斷單元判斷是初始狀態對應的事件類型時，執行所述創建與所述事件標識對應的狀態機實例，當所述判斷單元判斷不是初始狀態對應的事件類型時，丟棄所述基礎事件。
13.根據權利要求8至12任意一項所述的裝置，其特征在于，所述輸出單元包括狀態查找單元，用于查找所述狀態機實例所遷移的當前狀態；狀態判斷單元，用于根據所述基礎事件的事件類型判斷所述狀態機實例是否能夠從所述當前狀態順序遷移到下一狀態；結果執行單元，用于當所述狀態判斷單元的判斷結果為是時，遷移到所述下一狀態，當所述狀態判斷單元的判斷結果為否時，輸出系統異常的復合事件。
14.根據權利要求13所述的裝置，其特征在于，所述狀態判斷單元，還用于當遷移到所述下一狀態后，判斷所述下一狀態是否為所述狀態機實例的結束狀態；所述結果執行單元，還用于當所述狀態判斷單元的判斷結果為是時，輸出系統事件完成的復合事件，當所述狀態判斷單元的判斷結果為否時，將所述下一狀態保存為所述狀態機實例的當前狀態。
全文摘要
本申請實施例公開了一種復合事件處理方法及裝置，所述方法包括接收到基礎事件后，根據所述基礎事件的事件信息確定所述基礎事件所屬的事件模式，所述基礎事件中攜帶事件標識；將所述基礎事件輸入與所述事件標識對應的狀態機實例，所述狀態機實例為按照所述基礎事件所屬的事件模式定義的狀態機所創建的實例，屬于同一個狀態機實例的基礎事件具有相同的事件標識；根據所述狀態機實例的狀態遷移結果輸出復合事件。本申請實施例通過狀態機實例的狀態遷移結果輸出復合事件，由此節約了系統為存儲大量基礎事件所耗費的存儲空間，并且由于可以根據實際應用需求變換對某個事件模式的狀態機定義，因此增強了系統對復合事件處理的靈活性。
文檔編號G06Q30/00GK102214187SQ201010147358
公開日2011年10月12日 申請日期2010年4月12日 優先權日2010年4月12日
發明者蔡學鏞 申請人:阿里巴巴集團控股有限公司