我是IBM MQ的新手,我正在尝试编写一个应用程序来使用来自公共队列的消息,这些消息最初可能在被路由到公共队列之前被发送到别名队列或主题。在获取消息后,我希望能够根据消息的特定目的地执行条件逻辑。
在RabbitMq中,我们可以获取用于发布消息的原始RoutingKey。这允许我使用通配符订阅,但是然后根据实际的RoutingKey为每条消息做一些特殊的事情。
我目前正在使用IBM MQ的普通安装。在MQ重新路由之前,是否可以确定消息的原始目标(别名队列或主题)?
MQ可以在路由期间操纵消息(属性,MQMD字段等),以便在检索到自定义值后将其拉出来吗?
如果我不能用普通版本的MQ做这个,那么我可以添加一个额外的工具来支持这个功能的MQ(我已经看过很多关于IBM Integration Bus的帖子,以前的Message Broker,但我仍然不能完全理解它的作用,或者它是否符合我的需要。)
我在.Net中编程,我使用了XMS和通过amqmdnet.dll提供的普通.Net客户端工具
答案 0 :(得分:5)
如果消息已发布到主题,并从那里根据订阅路由到队列,则消息将包含MQTopicString消息属性,该属性为您提供发布到的主题字符串。
例如,使用浏览示例amqsbcg查看队列中的消息,并将第三个参数设置为“1”(amqsbcg 1)。如果邮件中有邮件属性,则会将其列为...
****消息属性****
MQTopicString:'/ A / B / C'
答案 1 :(得分:1)
MQ是许多应用程序使用的中间件,如果它们开始集成对每个应用程序逻辑的支持,它就会变得非常混乱,这就是为什么MQ只管理从发送方到消息所需的大量信息的原因接收器。 总的来说,我认为使用传输层的机制来支持应用程序逻辑是一种很好的做法。通过这样做,您会对传输解决方案引入过深的依赖关系。
通信应用程序用于提供其服务的任何信息都应由发送方和接收方应用程序包含在消息中。 MQ提供了传输信息的方法,而不是创建或管理信息。
例如,您可以编写发件人应用程序,使其在邮件属性中包含发件人应用程序ID。 MQ将传输这些属性并提供通过这些属性获取消息的方法。
对于您的进一步问题,默认情况下,MQ无法操纵传输的消息(除了代码页转换),这是Message Broker(IIB)的用途。 但是Message Broker没有集成到MQ中,它只使用MQ作为传输机制,因此当消息完全由MQ路由时,它无法帮助确定消息的发起者。 如果消息由Message Broker路由,则它可以在发送的消息中包含任何信息。
答案 2 :(得分:0)
不,生产者使用的对象名称丢失了。虽然PutApplName
,ReplyToQ
或ReplyToQMgr
等一些input()
标题可能有助于推断消息的来源。
我认为拥有多对一队列端点对于WMQ实现来说是一种不好的做法。