2016-05-12 92 views
1

我對IBM MQ非常陌生,我正在嘗試編寫一個應用程序以使用消息來自通用隊列,該通用隊列可能最初在發送到別名隊列或主題之前被路由到共同隊列。獲取消息後,我希望能夠根據消息的特定目標執行條件邏輯。從IBM MQ消息中檢索原始目標信息

在RabbitMq中,我們有能力獲得用於發佈消息的原始路由密鑰。這允許我使用通配符進行訂閱,但是根據實際的RoutingKey爲每個消息做一些特殊的處理。

我目前正在使用IBM MQ的普通安裝。在MQ重新路由之前是否可以確定消息的原始目標(別名隊列或主題)?

MQ可以在路由期間操縱消息(屬性,MQMD字段等),以便在檢索到時可以將自定義值拉出來?

如果我不能使用MQ的簡單版本來做到這一點,那麼我可以添加一個額外的工具,以便能夠適應這種功能的MQ(我見過很多關於IBM Integration Bus,以前稱爲Message Broker的文章,但我仍然無法將自己的頭部圍繞到它所做的事情上,或者它能滿足我的需求。)

我在.Net中進行編程,並且使用XMS和通過amqmdnet提供的簡單.Net客戶端工具。 dll

回答

5

如果消息已經被髮​​布到一個主題,並從那裏發送到基於訂閱的消息都將包含它給你的主題字符串,他們發佈到MQTopicString消息財產的隊列。

作爲示例,使用瀏覽示例amqsbcg查看隊列中第三個參數設置爲'1'(amqsbcg 1)的消息。如果有,他們將被列爲該消息在消息屬性...

****消息屬性****

MQTopicString: '/ A/B/C'

+0

這讓我朝着正確的方向前進!我發現屬性名稱是「mqps.Top」而不是「MQTopicString」,但它確實包含用於發佈消息的原始主題字符串。我還驗證了在使用別名隊列轉發到主題時設置了此屬性。 – bdway

0

不,製造商使用的對象名稱丟失。儘管某些MQMD標題(例如PutApplNameReplyToQReplyToQMgr)可能有助於推導該消息的來源。

我認爲擁有多對一隊列端點對於WMQ實現來說是一個不好的做法。

+0

我曾想過在使用這些字段時,可能值的列表可能會很長。只是好奇爲什麼多對一會是不好的做法?對我來說,似乎讓每個發佈者都發送到他們自己的隊列,然後嘗試從所有這些單獨的隊列讀取是一個管理噩夢。每次添加另一個發佈者時,我都必須添加額外的進程來使用該隊列。 – bdway

+0

直到你試圖找出誰發送了什麼,這一切都很好。如果有一種實現你所要求的萬無一失的方法,我會對多個生產端點沒有問題。 – Stavr00

1

MQ是許多應用程序使用的中間件,如果它們開始集成對每個應用程序邏輯的支持,它會變得非常混亂,這就是爲什麼MQ只管理從發送者到接收者獲取消息所需的大量信息的原因。 一般來說,我認爲使用傳輸層的機制來支持應用程序邏輯並不是一個好習慣。通過這樣做,您可以在您的傳輸解決方案中引入太深的依賴關係。

通信應用程序提供其服務所使用的任何信息都應包含在發送方和接收方應用程序的消息中。 MQ提供了傳輸信息的手段,而不是創建或管理信息。

例如,您可以編寫發件人應用程序,以便它將發件人應用程序ID包含在郵件屬性中。 MQ將傳遞這些屬性並提供通過這些屬性獲取消息的方法。

對於您的進一步問題,默認情況下,MQ無法處理傳輸的消息(除代碼頁轉換外),這就是Message Broker(IIB)的用途。 但是Message Broker沒有集成到MQ中,它只使用MQ作爲傳輸機制,所以當消息由MQ完全路由時,它不會幫助確定消息的發起者。 如果消息由Message Broker路由,那麼它可以在發送的消息中包含任何信息。