当前位置: 首页 > 知识库问答 >
问题:

Azure服务总线订阅中基于系统属性的SQLFilter

公冶智刚
2023-03-14

我有一个使用本教程的工作示例,可以根据需要发送和接收主题/订阅:https://azure.microsoft.com/en-us/documentation/articles/service-bus-queues-topics-subscriptions/

但是,现在我想根据BrokeredMessage的to属性为每个订阅设置SQL过滤器。我后面的教程提到,有可能“创建订阅时,您可以提供一个对消息的属性进行操作的筛选表达式,包括系统属性(例如,Label)和自定义应用程序属性(例如StoreName.)”

如果我设置一个自定义属性,例如StoreName,如下所示:

message.Properties.Add("StoreName", "TestMe");

并使用SQL筛选器设置订阅,如下所示:

namespaceManager.CreateSubscription("MyNSTestTopic", "TestSubscription", new SqlFilter("StoreName = 'TestMe'"));

订阅按预期筛选。但是,如果我尝试使用BrokeredMessage对象作为属性(或标签),就像本文中描述的那样,我无法使其工作。我尝试了以下SQL筛选器,但没有成功。访问消息的系统属性的正确语法是什么?

html lang-html prettyprint-override">BrokeredMessage message = new BrokeredMessage();
message.To = "TestMe";

namespaceManager.CreateSubscription("MyNSTestTopic", "TestSubscription", new SqlFilter("To = 'TestMe'"));
namespaceManager.CreateSubscription("MyNSTestTopic", "TestSubscription", new SqlFilter("Message.To= 'TestMe'"));
namespaceManager.CreateSubscription("MyNSTestTopic", "TestSubscription", new SqlFilter("MessageTo= 'TestMe'"));
namespaceManager.CreateSubscription("MyNSTestTopic", "TestSubscription", new SqlFilter("messageto= 'TestMe'"));

共有1个答案

苏华荣
2023-03-14

本文主题订阅筛选器:

SQL筛选器-sqlfilter包含一个类似SQL的条件表达式,该条件表达式在代理中根据到达的消息的用户定义属性和系统属性求值。所有系统属性(都是BrokeredMessage类上显式列出的属性)必须在条件表达式中以sys.作为前缀。SQL子集实现了属性是否存在的测试(exist)、空值的测试(is null)、逻辑not//、关系运算符、数值算术以及与like匹配的简单文本模式。

因此,在您的情况下,需要在sys.to属性上创建sqlfilter:

namespaceManager.CreateSubscription("MyNSTestTopic", "TestSubscription",
    new SqlFilter("sys.To = 'TestMe'"));
 类似资料:
  • 来自第三次订阅的消息会发生什么情况,是否会在TTL之后发送到死信队列 有没有办法找出消息未被使用的订阅

  • 我想将一个小的JSON消息放入中。消息将具有附加到它的“ProviderID”属性,并且根据筛选规则,该消息将被筛选到特定于提供程序的上 但是,我似乎无法在上指定共享访问策略,以限制第三方提供商仅连接到他们自己的 我假设应该在订阅上设置以便将这些消息发送到另一个并在那里应用特定于提供程序的安全性,这样做是否正确。 或者有其他/更好的/推荐的方法来做这件事。

  • 我正在使用Java和Qpid JMS 0.23测试发布/订阅。 我在SB中创建了一个名为“测试主题”的主题。 我可以从测试应用程序向主题发布消息,但在尝试订阅(动态创建订阅)时失败,例外情况: javax.jms.InvalidDestinationException:找不到消息传递实体mynamesspace:主题:test.topic~15|DurableSubscriber2。Trackin

  • 这似乎是最简单的解决办法。让我们看看流程: 第三方向RESTful API发送请求,以获取Windows Azure服务总线连接字符串-凭据-。 一旦拥有连接字符串,第三方就会连接到Windows服务总线,并开始从某个主题订阅接收消息。注意:连接字符串是在服务器端加密的,只能由接受的客户端解密。 优点 null null 第三方请求一个类似于RESTful的TCP API,以便订阅一些Window

  • 我们使用服务总线主题作为pub/sub系统的引擎。我们的逻辑涉及我们的NodeJS服务用多个订阅连接到一个主题。对于每个订阅,我们删除$default(TrueFilter),并在消息头的Label属性上创建一个CorrelationFilter,并且不在订阅中应用AutoDeleteOnIdle设置,因为我们希望确保订阅服务器功能在服务启动之前一直运行。 这个问题可以归结为这样:某件事能导致规则