訊息

類似 JMS 訊息的 Enterprise Message Service (EMS) 訊息,其中包含了三個不同部分:標頭、屬性和內文。 標頭是 EMS 訊息唯一要求指定的部分。 本主題描述如何在 Microsoft BizTalk Adapter for TIBCO Enterprise Message Service 中處理訊息。

注意

例如,若要設定或擷取標頭欄位 (,請設定訊息優先順序或相互關聯識別碼) 或協調流程中的訊息屬性,您必須使用 方案總管 在專案中新增Microsoft.BizTalk.Adapters.TIBCOEMSProperties.dll的參考。

訊息標頭

訊息標頭包含一連串含值的預先定義欄位。 BizTalk Adapter for TIBCO Enterprise Message Service 知道標題中可設定和不可設定的項目。 如果您嘗試設定唯讀值,配接器會在 [屬性 {} ] 區段中重新導向或設定您的值。

標頭範例

在下列範例中,請注意 Properties= { Destination={String:Queue[Q2]} }Properties 是包含字串的屬性,而字串的內容是 Q2。 這個屬性與 Destination 區段完全無關,因為它包含的是哪兒也不去的字串值 (您所設定的值),所以配接器會將這些字串保存在這個區段內。

ReplyTo屬性可以在協調流程中設定,以告知最終取用者傳送回應的位置。 EMS 會在收到來自 TIBCOEMS 的訊息時設定 Destination 屬性。 在訊息為接收自 TIBCOEMS 的協調流程中,這個第二個屬性具有唯讀性質,因此無法在協調流程中加以編輯。

例如,協調流程無法動態地分派協調流程內的訊息和設定訊息目的地。 Destination 的值會依據將傳送該訊息的連接埠而設定。

若您要將訊息分派到不同的佇列,您就必須針對個別佇列建立傳送埠。 這樣一來,協調流程就可以決定將哪個連接埠指派給該訊息。

在下列訊息範例中,Destination= {Queue[Q1]} 是唯讀的。 這個值是 TIBCOEMS 在伺服器接收訊息時設定的。 Destination 和 Q1 的值來自「傳輸屬性」。

範例

TextMessage={   
    Header={ MessageID={ID:EMS-SERVER.824437A58B11C75F4:1}   
    Destination={Queue[Q1]}   
  
        ' This is READONLY. It gets set by the server when the  
        ' message is received by the server (EMS). It is set in the  
        ' Transport Properties when you specify that you want to  
        ' listen for messages on Q1.  
    ReplyTo={}   
    DeliveryMode={Persistent}   
    Redelivered={False}   
    CorrelationID={}   
    MsgType={}   
    Timestamp={12/1/2005 11:59:01 PM}   
    Expiration={0}   
    Priority={1} }   
    Properties={ Destination={String:Queue[Q2]} }   
  
        ' This is a property that contains a string, and the   
        ' contents of the string is Q2. This has nothing to do with  
        ' the Destination section above – it is just another   
        ' property that is set.   
        ' This is in the schema. The adapter knows what it can and   
        ' cannot set in an EMS header. The values that the adapter   
        ' cannot set are put in the Properties section.   
    text={<?xml version="1.0" encoding="utf-16"?>  
    <ns0:Employees xmlns:ns0="http://BizTalk_Server_Project1.Employee">  
        <Emp Id="Id_0">  
            Name>Name_0</Name>  
        </Emp>  
    </ns0:Employees>  
    }  

標頭內含的一連串預先定義欄位,包含了配接器會升級到 BizTalk Server 訊息以便用於協調流程的值。 所升級屬性在標準標頭屬性中的定義,與 JMS 規格和 TIBCO Enterprise Message Service 延伸所下的定義,完全相同。 除了兩個屬性之外,協調流程的所有屬性都可供從 EMS 接收: DestinationReplyTo 描述無法正確對應以在協調流程中使用的目的地做為單一屬性。

BizTalk Adapter for TIBCO EMS 會將 TIBCOEMS 屬性對應成字串型別,並且使用 Destination 字串表示法。 這看起來像 StaticQueue[queuename]StatisTopic[topicname] 。 協調流程可以設定 的值 ReplyTo ,而配接器會將它取代為 標頭中有效的目的地物件。

配接器會提供結構描述和參考組件,這兩者會描述可供協調流程使用的任何 TIBCO EMS 標頭屬性。 這些屬性可用於篩選內送訊息,或是加入到外寄訊息。 掌控協調流程篩選條件的規則,不同於 EMS 伺服器訊息選取器所使用的規則。 例如,協調流程可以篩選 TibcoEMS.ReplyToTibcoEMS.Destination 屬性,但 JMS 規格中不支援允許這個相同屬性上的訊息選取器。

當協調流程有設定這些屬性時,JMS 訊息的標頭屬性中就會包含這些屬性。 否則,當 EMS 訊息獲得接收時,這些標頭屬性就會複製到 BizTalk Server 訊息內容中。

當某個屬性與連接埠組態相符時,在訊息上之該屬性值的優先順序便會高於該連接埠組態。 例如,如果連接埠內所設定的優先順序為 4,而您在協調流程邏輯中是將訊息的優先順序設成 9,則此訊息會依據優先順序 9 來由 TIBCO EMS 接收。

屬性描述

下表描述 BizTalk Adapter for TIBCO Enterprise Message Service 如何使用各個屬性。

名稱 類型 Description
TibcoEMS.MessageID 字串 傳送呼叫,可為各個訊息指派唯一識別碼,並將此識別碼記錄在標頭中。

任何訊息識別碼值的開頭都是 3 個字元組成的前置識別碼 (已就這個用途而保留)。

唯讀。 變更這個值並不會影響訊息。
TibcoEMS.Timestamp long 傳送呼叫,可在標頭中記錄 UTC 時間戳記。 這個時間戳記會指出伺服器接受訊息的大致估計時間。

這個值是自 1970 年 1 月 1 日以來所經過的毫秒數。

唯讀。 變更這個值並不會影響訊息。
TibcoEMS.Redelivered boolean 伺服器會將標頭設定成指出某個訊息是否與先前所傳送的訊息重複:

- false—伺服器先前未嘗試將此訊息傳遞給取用者。
- true— 伺服器先前嘗試將此訊息傳遞給取用者,但取用者未及時傳回通知,但可能不保證。

唯讀。 變更這個值並不會影響訊息。
TibcoEMS.Destination 字串 傳送呼叫,可在這個標頭中記錄此訊息的目的地 (佇列或主題)。 格式會從目的地改成字串表示法。 格式已於先前內容中介紹過。

唯讀。 變更這個值並不會影響訊息。
TibcoEMS.DeliveryMode 字串 有兩個可能的值:PERSISTENT 和 NON-PERSISTENT。 預設值為 PERSISTENT 模式。

配接器會先等候來自 EMS 伺服器的通知,接著才發出訊息已傳送到 BizTalk Server 的通知。 這個標頭屬性和連接埠組態項目會決定 EMS 將這個通知傳送給配接器時所花費的時間,並決定訊息傳輸的穩定性。

使用 PERSISTENT 傳遞模式 -- EMS 伺服器會一直等候到訊息成功保存於 EMS 伺服器中。 這個動作可保證該訊息有送達佇列。 使用 PERSISTENT 模式傳遞時,請注意下列幾點:

訊息越大,BizTalk Server 就會花更多時間來判定該訊息為已傳送。

使用 NON-PERSISTENT 模式 -- EMS 伺服器會先傳回通知,再保存該訊息。 如果 EMS 伺服器發生失敗,在系統判定 BizTalk Server 已成功傳送該訊息之際,訊息可能已經遺失了。
TibcoEMS.Expiration long 訊息在過期前維持有效的時間長度。 如果設成 0,表示訊息永遠不會過期。

此段有效時間的指定單位是毫秒。
TibcoEMS.Priority int 使用從 0 到 9 的數字排名,定義訊息的優先順序為一般或是加速。 數字越大表示優先順序越前面。
TibcoEMS.CorrolationID 字串 可以用來連結訊息,例如將回應訊息連結到要求訊息。

這通常與 EMS.JMSMessageID 相同。 這通常會與 屬性搭配 EMS.JMSReplyTo 使用。
TibcoEMS.ReplyTo 字串 訊息回覆時應該送至其中的目的地。 格式與 EMS.JMSDestination 和 埠的組態相同。
TibcoEMS.Type 字串 不描述訊息類型 (文字、位元組、字串…)。

有些 JMS 提供者會使用訊息儲存機制來存放訊息類型定義。 用戶端程式可在這個欄位中,存放可參考至該儲存機制內定義的值。 EMS 支援這個標頭,但是並不會使用它。

JMS 規格不會定義標準的訊息定義儲存機制,也不會定義訊息類型定義的命名原則。

有些提供者需要使用各個應用程式訊息的訊息類型定義。 為了保證與這類提供者維持相容性,用戶端程式可以設定這個標頭,即使該用戶端應用程式並不會使用該標頭。

為了保證可攜性,用戶端可以用符號值 (而不要用常值) 來設定這個標頭,並將標頭設定成與提供者的儲存機制相符。

屬性

整合者可以定義要升級到 BizTalk Server 訊息內容的一組屬性,等到升級過後,這些屬性就會加入到 JMS 訊息的屬性部分。 整合者會在建立結構描述的同時,注意何時要定義該屬性的類型。 如果這個屬性值將用於訊息選取器,這個屬性的型別將會決定特定作業是否可有效執行。 例如,如果使用訊息選取器 myMessageProperty > 5 ,則必須將 屬性定義為整數值,而且配接器會將值放入訊息中做為整數值。 對於要升級的屬性,屬性名稱的開頭必須是 EMSX, 而且屬性名稱不能和預先定義的屬性相同。

BizTalk Adapter for TIBCO Enterprise Message Service 會提供結構描述和組件,這兩者會宣告可能出現在這個區段中的 EMS 專屬和 JMS 專屬屬性。 這些屬性可予以增加以包含任何遺漏。 在此訊息內容中加以參考的任何 EMSX 屬性,都會放入該 EMS 訊息的訊息屬性區段。 如需詳細資訊,請參閱《TIBCO EMS 使用者指南》。

主體

EMS 支援 JMS 規格中列舉的所有訊息:文字、位元組、資料流程、對應和物件。 BizTalk Adapter for TIBCO EMS 僅支援文字訊息類型。

JMS 不要求文字訊息類型一定要包含 XML 格式的內文。 配接器不會處理訊息本文;它提供給接收BizTalk Server。 因此,配接器提交至 BizTalk 的訊息不一定會剖析為 XML 資料。

保存的訊息

訊息可以保存在 EMS 伺服器上來保證完整一次傳遞給訂閱者,但是,這種作法可能會嚴重影響到配接器的效能。 當您傳送訊息時,EMS 會先將訊息存放在本機儲存區,再向配接器發出已接收訊息的通知。 您可以在協調流程中針對各個訊息來設定這個屬性,或是針對連接埠所處理的任何訊息設定這個屬性。

就接收的角度來說,配接器可能會在主題沒有訂閱訊息情況下遺漏掉某些訊息。 當 EMS 沒有保存任何訂閱時,訊息就會張貼到主題上。 即使目前未訂閱,配接器也需要一種機制來接收訊息張貼;不過,就像使用永續性訊息一樣,這對 EMS 效能有顯著的影響,而且不一定是必要的。

注意

還有一種從 EMS 檢視位置進行接收的機制,不過這種機制尚未實作,也沒有實際的需要。 這個問題只和主題有關,而不會影響到佇列。 主題通常是用於時間特定資料,例如,股票報價。 當股票價格漏掉時,您知道稍後它就會補貼出來。

基於這些因素,您可以選擇為連接埠組態啟用或停用將訊息保存在 EMS 伺服器上。

訊息應答

BizTalk Adapter for TIBCO Enterprise Message Service 一定會在訊息已正確分派給 BizTalk Server 時應答已接收訊息。 這樣表示,沒有應答的訊息會從 EMS 重新傳送給配接器。 配接器無法決定 EMS 重新傳送訊息的次數,因為這是目的地本身的組態設定;但是,配接器可以決定該訊息是否要傳送到 MessageBox。 EMS 伺服器會決定失敗訊息傳送到佇列的最多次數。

針對重新傳遞的訊息,EMS 伺服器會將 JMSRedelivered 屬性設定為 True,並遞增 JMSXDeliveryCount 。 這兩種屬性值都可用於協調流程。 您不能在訊息還未傳遞之前就將它移到 EMS 未傳遞佇列。 這樣做會改變訊息的屬性。

當訊息到達其已設定的最大重新傳遞計數時,EMS 伺服器就會判斷該訊息應該要加以刪除,或是放入 $sys.undelivered 佇列。 EMS 伺服器會根據 JMS_TIBCO_PRESERVE_UNDELIVERED 屬性做出決定;如果為 True,則訊息會移至未傳遞的佇列,或刪除該佇列。 這個屬性可以先設定於協調流程中,接著才傳送該訊息。 傳遞之後,訊息屬性就不能變更。 系統會在傳送到 EMS 的訊息成功抵達時應答 BizTalk Server。 如果對 EMS 的傳送發生失敗,這些訊息會擱置,並標記為可再嘗試。

另請參閱

快速入門