專利名稱：工作流程管理系統(tǒng)中的信令事件的制作方法
技術領域：
本發(fā)明涉及用于改進具有涉及事件的信令的可比較功能的工作流程管理系統(tǒng)或計算機系統(tǒng)(WFMS)的健壯性和易用性的裝置和方法。
背景技術：
一個重要性越來越大的新技術領域是工作流程管理系統(tǒng)(WFMS)領域。WFMS支持業(yè)務進程的建模和執(zhí)行。在WFMS環(huán)境內執(zhí)行的業(yè)務進程可以控制誰將執(zhí)行網絡的哪件工作以及為此工作利用哪些資源。單件工作可以跨被某種網絡連接的大量不同計算機系統(tǒng)地進行分布。
“IBM MQSeries Workflow”(以前叫做“IBMFlowMark”)這一產品代表了這樣的典型、現(xiàn)代化的、先進的、功能強大的工作流程管理系統(tǒng)。它支持將業(yè)務進程建模為活動網絡。此活動網絡(進程模型)是作為有向非循環(huán)加權彩色圖來構建的。圖形的節(jié)點代表執(zhí)行的活動。圖形的邊(控制連接器)描述了執(zhí)行活動的可能的順序。進程圖的定義是通過IBM MQseries Workflow的流程定義語言(FDL)或通過內嵌的圖形編輯器進行的。
工作流程管理系統(tǒng)的運行時組件使用所說的進程模型作為創(chuàng)建進程實例的模板。每一個進程實例都與一組值(通常叫做“上下文”)關聯(lián)。所說的值是進程實例的請求者或者通過相應的請求提供，或者由實現(xiàn)各種活動的程序檢索，或者是某一進程實例的執(zhí)行歷史的結果。上下文是某一進程實例所特有的。所說的上下文內的一個特定的重要信息片段是唯一地標識進程實例的進程實例標識符。值得注意的是，通常，進程實例標識符只是在從特定的進程模型派生的進程實例集內唯一的。
特別重要的活動類型是事件活動。事件活動提供了讓進程實例等到發(fā)出事件的能力。信號，或換句話說，事件，可以在WFMS內創(chuàng)建，但通常其來源位于工作流程管理系統(tǒng)之外。在接收到所說的信號時，工作流程管理系統(tǒng)將所提供的信息作為上下文信息存儲(在此情況下，存儲到事件活動的輸出容器中)，并繼續(xù)導航。
事件的信令是通過發(fā)送到工作流程管理系統(tǒng)的相應的信號請求進行的。所說的信號請求可以由利用工作流程管理系統(tǒng)所提供的應用程序編程接口的程序來創(chuàng)建，或者通過向通常可以執(zhí)行這樣的信號請求的工作流程管理系統(tǒng)發(fā)送一個相應的工作流程管理系統(tǒng)定義的消息來創(chuàng)建。與執(zhí)行信令事件的方式無關，信令請求必須包含其中事件正在等待的進程實例的相應的進程實例標識符以及事件的標識符。此信息是必需的，以便工作流程管理系統(tǒng)可以定位進程模型內的正確的進程實例和正確的事件。如果信令請求的發(fā)出者不知道事件標識符，或者甚至不知道進程實例標識符，則發(fā)出者必須獲得此信息。為便于執(zhí)行此項操作，工作流程管理系統(tǒng)提供了查詢功能，以便允許發(fā)出者查詢事件活動的輸入容器。進程建模者的必須確保，事件活動的輸入容器包含從中可以派生進程實例標識符的相應的值。
這種最先進的方法具有多處不足，特別是，當事件通過向工作流程管理系統(tǒng)發(fā)送一個消息來發(fā)出時。
事件的信令發(fā)送者必須向工作流程管理系統(tǒng)指出，請求是為了請求發(fā)送事件；意思是說，請求者必須遵循工作流程管理系統(tǒng)定義的消息結構。此結構通常要求具有某些指示符，如在消息的某些位置消息代表文本字符串信號作為消息的第一字段的命令。這就要求，當信號應該由工作流程管理系統(tǒng)進行處理時，現(xiàn)有的面向消息的發(fā)送者程序必須修改；這是一個不一定總可以實現(xiàn)的方法。另一個克服此情況的方法是使用一種轉換程序，該轉換程序將發(fā)送者的原始消息轉換為工作流程管理特定的消息；該方法不僅增大了整個系統(tǒng)的復雜性(使維護和系統(tǒng)管理變得更加復雜)，而且還降低了產生信號的性能。
發(fā)送者必須維護目標進程實例的進程實例標識符。如果這不可能實現(xiàn)，發(fā)送者必須從工作流程管理系統(tǒng)獲取相應的信息(事件的輸入容器中的數(shù)據)。這要求，發(fā)送者已經知道事件的名稱，以便它可以設置到工作流程管理系統(tǒng)的相應的查詢。這也有缺點，對進程模型作出的每個更改(如更改事件的名稱)都需要對發(fā)送者進行重新編程(如修改事件的新名稱)。
發(fā)送者必須知道事件的名稱(根據WFMS的命名法)，即使它知道進程實例標識符。知道名稱包括在某種程度上知道進程模型的結構；例如，進程模型可以在同一個進程模型內多次使用同一個名稱，當從比較簡單的進程模型合成一個比較復雜的進程模型時可能會容易產生這種情況。
從上文列出的不足可以看出，該技術的當前狀態(tài)強制事件的發(fā)送者和工作流程管理系統(tǒng)之間的緊密耦合，該耦合由發(fā)送者必須維護關于工作流程管理系統(tǒng)維護的信息的信息所聲明。由于上文概述的原因，此情況是相當不受歡迎的。在工作流程管理系統(tǒng)中應該可以指定處理任意消息以便發(fā)送事件所需的所有信息。還應該可以任意發(fā)送事件，以便向WFMS發(fā)送信令事件，而不必為適應WFMS要求而修改所說的信號。任意的發(fā)送者應該被允許不知道信令請求的消費者(即，收件人)的具體特征。然后，可以獨立于信令請求的消費者開發(fā)信號發(fā)送者。
如果一個人想起通常以諸如C2B(消費者對企業(yè))或B2C(企業(yè)對消費者)業(yè)務進程之類的術語所概述的典型的因特網情況，最先進的方法在這一問題的領域的弱點變得更加顯著。在這些情況下，顯然，信號發(fā)送者與工作流程管理系統(tǒng)的緊密耦合是根本不理想的。
本發(fā)明基于這樣的目標使事件發(fā)送者在等待所說的事件的通知的相應的進程實例中定位相應的事件時，無需維護所需要的信息。

發(fā)明內容
本發(fā)明的目標由獨立的權利要求解決。在相應的子權利要求中闡述了本發(fā)明的有利的配置和實施例。
本發(fā)明提供了一種計算機化的方法，用于確定具有可比較功能的工作流程管理系統(tǒng)或計算機系統(tǒng)(WFMS)內的信令請求的收件人。
在接收到信令請求(該請求提供一組信號數(shù)據元素)時，本發(fā)明不要求信號數(shù)據元素包括所說的信令請求的收件人的任何顯式說明。
為確定作為業(yè)務進程的進程模型的實例的進程實例的特定事件活動是否為信令請求的可能的收件人，建議確定進程模型是否包括事件標識說明。根據本發(fā)明的此事件標識說明涉及信號數(shù)據元素的子集。對事件標識說明的評估允許間接地判斷事件活動是否為信令請求的收件人。
所提出的本發(fā)明避免了上述所有不足?；谒岢龅姆椒獬诵帕钫埱蟮陌l(fā)送者指定某一收件人提供了又一個優(yōu)點，即，對于單一的信令消息，可以存在多收件人。


圖1顯示了由進程圖代表的進程模型的示例。
圖2說明了作為輸入和輸出容器的活動的簽名和通過數(shù)據連接器將數(shù)據從一個活動移動到另一個活動的實施例。
圖3說明了當激活時等待處理消息的事件活動的結構。
圖4說明了使用用于描述消息的內容的XML架構定義發(fā)送事件的消息的定義。
圖5直觀地顯示了使用MQseries Workflow的流程定義語言的必需的規(guī)范的細節(jié)。
圖6說明了確定發(fā)送事件的消息的結構的另一種方法。
圖7說明了標識作為信令消息的目標的事件的另一種方法。
具體實施例方式
在附圖和說明書中，闡述了本發(fā)明的優(yōu)選實施例，雖然這里使用了特定的術語，但是如此給出的描述只是在作為通用和描述性的意義上使用術語的，而不是起限制作用。然而，很顯然，在不偏離所附權利要求所闡述的本發(fā)明的更廣泛的精神和范圍的情況下，可以進行各種其他更改和修改。
本發(fā)明可以以硬件、軟件或硬件和軟件的組合實現(xiàn)。任何類型的計算機系統(tǒng)-或適于執(zhí)行這里描述的方法的其他裝置都適合。典型的硬件和軟件的組合可以是具有這樣的計算機程序的通用計算機系統(tǒng)，當加載并執(zhí)行該計算機程序時，控制計算機系統(tǒng)以便它執(zhí)行這里描述的方法。本發(fā)明還可以嵌入在包括實現(xiàn)這里描述的方法的所有特點的計算機程序產品中，這種計算機程序產品在加載到計算機系統(tǒng)中時，能夠執(zhí)行這些方法。
本上下文中的計算機程序裝置或者計算機程序是指以任何語言、代碼或注釋表達的一組指令的任何表達式，用于使具有信息處理能力的系統(tǒng)直接或者在下列操作中的任何一種或兩種操作都執(zhí)行之后執(zhí)行特定的功能a)轉換到另一種語言、代碼或注釋；b)以不同的材料形式再現(xiàn)。
是基于IBM的“MQSeries Workflow”工作流程管理系統(tǒng)來對本發(fā)明進行說明的。當然，也可以使用任何其他WFMS。此外，本發(fā)明還可以應用于不作為單獨的WFMS而在某些其他類型的系統(tǒng)內提供WFMS功能的任何其他類型的系統(tǒng)。
根據本發(fā)明，如果WFMS引擎是基于由發(fā)送者提供的數(shù)據元素確定任何信令請求的收件人的處理實體，是有利的。但是，當然，本發(fā)明也可以在對發(fā)送事件的請求的處理實體不是WFMS引擎本身而是某些其他實體的其他情況下應用。
1.概述下面是有關基于IBM的“MQseries Workflow”的工作流程管理系統(tǒng)WFMS的基本概念的簡要概述。
從企業(yè)的觀點來看，對業(yè)務進程的管理變得越來越重要業(yè)務進程(或簡稱為“進程”)控制哪件工作將由誰來執(zhí)行以及為此工作利用哪些資源，即，業(yè)務進程描述了企業(yè)將如何實現(xiàn)其業(yè)務目標。WFMS可以支持對業(yè)務進程的建模和它們的執(zhí)行。
以軟件系統(tǒng)直接支持的方式將業(yè)務進程作為一個語法單位建模是非常理想的。此外，軟件系統(tǒng)也可以作為基本上作為輸入獲取這樣的模型的解釋器來工作該模型叫做“進程模型或工作流程模型”，然后可以對該模型實例化，從而可以確定取決于模型的實例化的上下文的工作步驟的單獨的順序。這樣的業(yè)務進程的模型可以被視為在企業(yè)內執(zhí)行的類似的進程的一個類別；它是描述特定類型的業(yè)務進程的所有可能的執(zhí)行變量的架構。這樣的模型的實例以及其解釋代表單獨的進程，即，模型規(guī)定的變量的具體的、與上下文相關的執(zhí)行。WFMS有助于業(yè)務進程的管理。它提供了描述業(yè)務進程(生成時)的模型的手段，它基于相關的模型(運行時)驅動業(yè)務進程。下面將描述IBM的WFMS MQseries Workflow的元模型，即，為描述業(yè)務進程模型而提供的語法元素，以及這些語法元素的含義和解釋。
進程模型是進程的完整的表示，包括進程圖和定義圖表的組件后面的邏輯的設置。MQseries Workflow進程模型的重要組件有●進程●活動●區(qū)塊●控制流程●連接器●數(shù)據容器●數(shù)據結構●條件●程序
●人員下面將描述這些元素中的其中幾個。
活動是元模型的基本元素。活動代表從某種角度來看是其自己的語義實體的業(yè)務操作。
MQSeries Workflow進程模型由下面幾種類型的活動構成程序活動指派一個程序執(zhí)行活動。當啟動活動時，調用該程序。在完全自動化的工作流程中，程序執(zhí)行活動，無需人的干預。否則，用戶必須通過從運行時工作列表選擇活動來啟動該活動。來自程序的輸出可被用于程序活動的退出條件以及用于到其他活動的過渡條件。
進程活動指派一個(子)進程執(zhí)行活動。當啟動活動時，調用該進程。進程活動代表了重復使用一組對不同的進程通用的活動。來自進程的輸出可被用于進程活動的退出條件以及用于到其他活動的過渡條件。
控制流，即，通過運行中的進程的控制流程確定了執(zhí)行活動的順序。MQSeries Workflow工作流程管理器將進程沿著通過啟動條件、退出條件和過渡條件被評估為TRUE而確定的路徑導航。
連接器鏈接進程模型中的活動。使用連接器，可以定義活動的順序和活動之間的數(shù)據傳輸。由于活動可能不任意地執(zhí)行，因此它們通過控制連接器綁定在一起?？刂七B接器可以被視為兩個活動之間的有向邊；連接器的終點的活動不能在連接器的起點處的活動(成功地)完成之前開始。從而控制連接器對一個業(yè)務進程模型內的控制的潛流進行建模。默認連接器指定當沒有其他控制連接器離開活動的過渡條件被評估為TRUE時控制應該流向哪里。默認連接器能使工作流程模型處理例外的事件。數(shù)據連接器指定一個工作流程模型中的數(shù)據的流動。數(shù)據連接器發(fā)自一個活動或區(qū)塊，并將活動或區(qū)塊作為其目標。可以指定輸出數(shù)據發(fā)往一個目標或發(fā)往多個目標。一個目標可以有一個以上輸入數(shù)據連接器。
進程定義包括活動的建模、活動之間的控制連接器，輸入/輸出容器，以及數(shù)據連接器。進程被表示為以活動作為節(jié)點，控制/數(shù)據連接器作為圖形的邊的有向非循環(huán)圖。圖形是通過內嵌的圖形編輯器操作的。數(shù)據容器有指定為命名的數(shù)據結構。這些數(shù)據結構本身是通過DatastructureDefinition功能指定的。程序活動是通過程序實現(xiàn)的。程序是通過Program Definition功能注冊的。區(qū)塊與進程包含相同的結構，如活動、控制連接器等等。然而，它們是未命名的，并且有它們自己的退出條件。如果不符合退出條件，則再次啟動區(qū)塊。區(qū)塊如此實現(xiàn)Do Until結構。進程活動是作為進程來實現(xiàn)的。這些子進程是作為帶有其通常的屬性的常規(guī)，命名的進程定義的。進程活動為進程定義提供了較大的靈活性。它不僅允許通過對活動的永久優(yōu)化為程序和進程活動來構建進程(自頂向下)，而且從一組現(xiàn)有的進程生成進程(自底向上)。
實現(xiàn)程序活動的所有程序是通過Program Registration功能定義的。為每一個程序注冊了程序的名稱、其位置，調用字符串。調用字符串由程序名稱和傳遞到程序的命令字符串構成。
作為這樣的一個進程模型的示例，圖1概要顯示了這樣的進程圖的結構?；顒?A1到A5)被表示命名的圓形；名稱通常描述了活動的用途?；顒右愿鞣N形式解決可能需要執(zhí)行的不同的任務。它們可能具有不同的活動實施方式，以滿足這些不同的需要。程序活動由指派的程序執(zhí)行，進程活動(如100)由另一個進程101執(zhí)行，區(qū)塊(如102)以內嵌的do-until循環(huán)實現(xiàn)宏103?？刂七B接器p12、p13、p24、p35、p45被表示為箭頭；箭頭的頭部描述了控制流沿著進程移動的方向。控制連接器從那里開始的活動叫做“源活動”；它在那里結束的活動叫做“目標活動”。當一個以上的控制連接器離開活動時，這表示潛在地平行的工作。
2.容器和數(shù)據連接器圖2顯示了兩個活動A 200和B 210，可以是比較復雜的進程模型的一部分。活動A 200和B 210具有一個與它們關聯(lián)的輸入容器220、240；活動A 200還具有與其關聯(lián)的輸出容器230。在根據本發(fā)明的基本的變更中，一個活動的輸入和輸出容器在概念上可以視為活動的簽名?；顒訌妮斎肴萜鳙@取其執(zhí)行所需的數(shù)據，并將它產生的數(shù)據以及其他活動所需要的數(shù)據寫入到輸出容器中。如同簽名一樣，活動的容器只對該活動可用；意思是說，它們只在本地可用。例如，輸入容器220和輸出容器230只對所關聯(lián)的活動A 200可用。因此，如果活動B 210需要來自活動A 200的輸出容器230的數(shù)據，則此數(shù)據必須從活動A 200的輸出容器230復制到活動B 210的輸入容器240。
為了將數(shù)據從其中一個活動復制到另一個活動，提供了數(shù)據連接器260，該數(shù)據連接器在圖2中被描述為虛線箭頭。圖2的數(shù)據連接器260表示，活動A 200的容器230的所有或部分必須復制到活動B 210的輸入容器240。
然而，一個活動的輸出容器和另一個活動的輸入容器通常具有不同的數(shù)據結構，例如，包含不同的數(shù)據字段。因此，在圖2中提供了容器圖250，該圖定義了活動A 200的輸出容器230的數(shù)據字段復制到活動B 210的輸入容器240的數(shù)據字段中。容器圖250還指定在將數(shù)據復制到活動B 210的輸入容器240之前，是否必須由工作流程管理系統(tǒng)執(zhí)行數(shù)據的轉換。
3.事件活動事件活動是工作流程管理系統(tǒng)支持的另一種類型的活動。它們提供了讓進程實例等到從工作流程管理系統(tǒng)外面發(fā)出事件的能力。在接收到信號時，工作流程管理系統(tǒng)處理請求并繼續(xù)導航。事件活動具有大多數(shù)屬性程序和進程活動。輸入和輸出容器是關聯(lián)的。它可以是控制連接器的源和目標以及數(shù)據連接器的源和目標。它具有開始條件，可以為它指定最后期限。
圖3說明了比較復雜的進程模型的此概要顯示的部分301?？刂七B接器360一進入事件活動，事件活動300就進入了等待狀態(tài)。如果在實現(xiàn)進程模型時事件活動沒有進入的控制連接器，一旦創(chuàng)建進程實例，事件活動就進入等待狀態(tài)。事件活動一直處于此狀態(tài)，直到發(fā)出事件。某客戶端310向發(fā)出事件活動300正在等待的事件的工作流程管理系統(tǒng)發(fā)出相應的請求350。此請求必須(1)將相應的進程實例中的相應的事件(2)標識為收件人。此外，事件信號可以提供存儲在輸出容器320中的數(shù)據，以便事件發(fā)送者所提供的信息可以對進程實例可用。當正確地發(fā)出事件時，導航繼續(xù)。有關事件活動的更多細節(jié)可以在Leymann/Roller，Production WorkflowConceptsand Techniques，Prentice Hall，New Jersey ISBN和US Patent US6,065,009 Events as Activities an Proeess Models of WorkflowManagement Systems中找到。
4.通過XML定義消息圖4顯示了通過XML架構定義對消息的定義(有關XML和XML架構的細節(jié)，請參閱http//www.w3.org)。消息的用途是向圖5中定義的事件活動發(fā)送事件。關鍵字complexType 400開始用戶定義的XML結構的定義。結構的名稱是SignalMessage 410。該結構由一組元素420構成，并帶有所說的元素的元素名稱430和數(shù)據類型440。
5.處理事件的信令圖5說明了使用MQSeries Workflow(申請者出售的最先進的工作流程管理系統(tǒng))的流程定義語言(FDL)實現(xiàn)/指定的本發(fā)明。FDL只被用作示例；可以使用指定發(fā)送事件的任何其他方式?；A元模型只作說明；可以使用其他元模型。
本發(fā)明的重要原理是提供允許事件的任意發(fā)送者完全不知道信令請求的收件人的技術；意思是說，具體的進程實例等待所說的事件。這就免除了發(fā)送者維護等候具體的進程實例的進程實例標識符和維護對應的進程模型內的事件活動的標識符。
本發(fā)明的基本目標是，WFMS本身可以利用信令請求內的發(fā)送者提供的數(shù)據元素或數(shù)據元素的子集，以唯一地標識作為事件的收件人的具體進程實例(或多個進程實例)和/或具體的事件活動(或多個事件活動)。
為使WFMS能執(zhí)行此標識任務，建議提高包括具有說明的事件活動的進程模型，這些說明定義要使用的信令請求所提供的(一個或多個)數(shù)據元素集，以將所說的進程模型的某些進程實例和所說的事件活動標識為收件人。一旦WFMS接收到信令請求，知道進程模型的WFMS將利用這些預先定義的事件標識說明和擁有信令請求的具體數(shù)據元素，以確定事件的具體收件人。
該示例說明了利用本發(fā)明的事件活動的定義。
DATASTRUCTURE定義500標識具有名稱SignalMessage501的數(shù)據結構。數(shù)據結構引用(通過XML關鍵字)502 XML架構SignalMessage 503(這是圖4中定義的XML架構)。此數(shù)據結構定義了被接受為張貼事件活動520的信令的消息的結構。
DATASTRUCTURE定義510標識具有名稱EventOutput的數(shù)據結構。數(shù)據結構包含INTEGER 512類型的字段AmountOffered。此數(shù)據結構用于事件活動520的輸出容器；字段AmountOffered被計劃作為在信令消息中提供的相應的字段的目標。
事件活動是通過EVENT_ACTIVITY關鍵字520進行定義的；事件活動的名稱是ReceiveOffer 522。事件活動的輸出容器是通過OUTPUT關鍵字進行定義的，該關鍵字將數(shù)據結構EventOutput 524標識為輸出容器的結構。
關鍵字SIGNAL 540標識與發(fā)送事件關聯(lián)的所有屬性；在本發(fā)明提出的特定的事件標識說明中，包括在本節(jié)內。在本示例內，它標識了，數(shù)據結構SignalMessage 526代表了發(fā)送事件的消息的結構。
關鍵字MESSAGE_IDENTIFICATION 536用于向工作流程管理系統(tǒng)指出應該如何確定消息的結構；該結構定義消息的布局。參數(shù)XML_SCHEMA 528指出，應該使用消息提供的XML架構名稱(這對于XML消息是典型的，因為能夠使用XML分析器來分析消息是理想的)。下面將討論MESSAGE_IDENTIFICATION參數(shù)的其他可能的參數(shù)值。如果信令消息具有指定的XML架構，則工作流程管理系統(tǒng)將此消息當作此ReceiveOffer活動的潛在的信令消息。意思是說，如果信令消息具有XML架構SignalMessage，則信令消息是事件活動ReceiveOffer 522的信令消息的備選。
關鍵字PROCESS_INSTANCE 542標識信令消息中的應該用于標識進程實例的字段。在該示例中，使用了XML消息的字段ContractId 530。一般而言，進程實例可以由涉及信令消息內的數(shù)據元素的值和來自進程實例的上下文的數(shù)據元素的值的任何任意的復雜布爾表達式來標識。
關鍵字TARGET_IDENTIFICATION 544用于定義表達式532，當該表達式被評估為True時，信令消息被指向事件活動。因此，此關鍵字允許標識WFMS將信令事件到其中的進程模型內的具體活動。表達式通過使用信令消息中的一個或多個字段來構建。在該示例中，如果信令消息中的字段ActionId包含文本字符串ReceiveOffer，則信令消息指向此活動。
MAP關鍵字546提供了將字段從信令消息映射到活動輸出容器的能力。在該示例中，它將字段AmountOffered從信令消息復制到輸出容器。其他可能性是將信令消息的字段復制到全局/鍵容器(有關細節(jié)，請參閱Leymann/RollerProduction WorkflowConcepts and Techniques，Prentice Hall，2000)。
圖6說明了標識信令消息的結構的另一種可能性。它定義了一個表達式，當該表達式被評估為True時，信令消息具有被指定為信令消息結構的結構。意思是說，當字段messageId 610包含值512時，信令消息具有為信令消息定義的結構，因此是事件活動ReceiveOffer的信令消息的備選。
圖6提出了對進一步問題的解決方案。在某些環(huán)境中，潛在的收件人只在所說的某些領域內是唯一的。這種情況的示例是進程實例標識符，這些進程實例標識符只在該進程實例集(它們是由常見的進程模型派生而來)內是唯一的。
為應付這種情況，有人建議，事件標識說明包括說明，當對這些說明進行評估時，允許將潛在的收件人的范圍限制到常見的進程模型的進程實例。圖6中的特定的實施例620允許從信令消息的一個或多個數(shù)據元素(在此示例中，參數(shù)businessProcessID-請參見圖4)解釋進程模型的標識符。結果，只有以此解釋的標識符從進程模型實例化的進程實例被視為潛在的收件人；當然，事件標識說明內的其他說明將進一步變窄，并標識具體的收件人。
一個進程實例內的事件唯一地通過活動實例標識符進行標識。因此，存在其他用于指定信令消息的目標的方法。所說的說明是PROCESS INSTANCE和TARGET_IDENTIFICATION說明的組合的備選說明。圖7說明了這種說明的形式。關鍵字ACTIVITY_IDENTIFICATION 710標識信令消息內的一個或多個字段，以將事件活動的標識符解釋(甚至通過一個更復雜的表達式)為信令事件的收件人。在當前示例中，作為信令消息的一部分的字段EventId 720直接用于解釋代表所說的收件人的事件活動標識符。
在運行時，上述說明被WFMS以下列方式使用首先，WFMS判斷信令消息的結構。這就要求檢查所有進程模型中的所有事件活動的所有MESSAGE_DEFINITION。如果不能確定信令消息的結構，WFMS認為，消息不是事件信令消息，并采取其他必需的操作。
其次，WFMS確定作為信令消息的目標的進程實例。
第三，WFMS確定作為信令消息的目標的所說的進程實例內的活動實例。
第四，WFMS將字段信令消息復制到進程實例的上下文。
權利要求
1.一種計算機化的方法，用于判斷具有可比較功能的工作流程管理系統(tǒng)或計算機系統(tǒng)(WFMS)內的信令請求的收件人，所說的WFMS管理作為業(yè)務進程的進程模型(301)的實例的進程實例，所說的進程模型包括至少一個事件活動(300)，以及在第一個步驟中，所說的方法接收(350)信令請求，所說的信令請求提供了一組信號數(shù)據元素(430)；以及所說的信號數(shù)據元素不包括所說的信令請求的收件人的任何顯式說明；以及在第二個步驟中，所說的方法判斷所說的進程模型是否包括涉及所說的信號數(shù)據元素的子集的事件標識說明(540)；以及在肯定的情況下，對事件標識說明進行評估以間接地判斷所說的事件活動是否為所說的信令請求的收件人；以及，在第三個步驟中，所說的方法向所說的事件活動作為收件人提供所說的信令請求。
2.根據權利要求1所述的用于判斷信令請求的收件人的計算機化方法，其特征在于，所說的事件標識說明包括第一說明(542)，該第一說明通過評估判斷所說的進程實例是否為所說的信令請求的所說的收件人。
3.根據權利要求2所述的用于判斷信令請求的收件人的計算機化方法，其特征在于，所說的事件標識說明包括第二說明(544、720)，該第二說明通過評估確定所說的進程實例的所說的事件活動是否為所說的信令請求的所說的收件人。
4.根據權利要求3所述的用于判斷信令請求的收件人的計算機化方法，其特征在于，所說的第一和/或所說的第二說明包括進一步涉及所說的進程實例的上下文的數(shù)據元素的布爾謂詞。
5.根據權利要求3所述的用于判斷信令請求的收件人的計算機化方法，其特征在于，所說的第二說明(720)從所說的信號數(shù)據元素的所說的子集解釋要與標識所說的事件活動的第二標識符進行比較的第一標識符，以便確定所說的進程實例的所說的事件活動是否為所說的信令請求的所說的收件人。
6.根據權利要求2所述的用于判斷信令請求的收件人的計算機化方法，其特征在于，所說的事件標識說明包括第四說明(620)，該第四說明通過評估將可能的收件人的范圍限制到所說的進程模型的進程實例。
7.根據權利要求1所述的用于判斷信令請求的收件人的計算機化方法，其特征在于，所說的事件標識說明包括第三說明(536)，該第三說明基于所說的信令請求的類型判斷所說的進程實例是否為所說的信令請求的所說的收件人。
8.一種包括適用于執(zhí)行根據前面的權利要求1到7的任何一個權利要求的方法的各步驟的裝置的系統(tǒng)。
9.用于在數(shù)據處理系統(tǒng)中執(zhí)行的數(shù)據處理程序包括軟件代碼部分，用于當所說的程序在所說的計算機上運行時執(zhí)行根據前面的權利要求1到7的任何一個權利要求的方法。
10.一種存儲在計算機可使用的介質上的計算機程序產品，包括計算機可讀的程序裝置，用于當所說的程序在所說的計算機上運行時，使計算機執(zhí)行根據前面的權利要求1到7中的任何一個權利要求的方法。
全文摘要
本發(fā)明提供了一種計算機化的方法，用于確定具有可比較功能的工作流程管理系統(tǒng)或計算機系統(tǒng)(WFMS)內的信令請求的收件人。在接收到信令請求(該請求提供一組信號數(shù)據元素)時，本發(fā)明不要求信號數(shù)據元素包括所說的信令請求的收件人的任何顯式說明。為確定作為業(yè)務進程的進程模型的實例的進程實例的特定事件活動是否為信令請求的可能的收件人，建議確定進程模型是否包括事件標識說明。根據本發(fā)明的此事件標識說明涉及信號數(shù)據元素的子集。對事件標識說明的評估允許間接地判斷事件活動是否為信令請求的收件人。
文檔編號G06Q10/00GK1531701SQ02809425
公開日2004年9月22日 申請日期2002年4月17日 優(yōu)先權日2001年5月12日
發(fā)明者弗蘭克·雷曼, 弗蘭克 雷曼, 洛勒爾, 蒂特爾·洛勒爾 申請人:國際商業(yè)機器公司