Фильтры разделов и действия

  • Статья

Подписчики могут самостоятельно определять, какие сообщения они хотят получать из раздела. Эти сообщения определяются в одном или нескольких именованных правилах подписки. Каждое правило состоит из условия фильтра, которое выбирает определенные сообщения и, при необходимости, содержит действие, которое добавляет к ним заметки.

Все правила без действий объединяются с помощью условия OR, в результате создается одно сообщение в подписке, даже если в ней присутствует несколько правил сопоставления.

Каждое правило с действием создает копию сообщения. Это сообщение будет иметь свойство, называемое RuleName, где значение — это имя правила сопоставления. Действие может добавлять или обновлять свойства или удалять свойства из исходного сообщения, чтобы создать сообщение в подписке.

Рассмотрим следующий сценарий, когда подписка имеет пять правил: два правила с действиями и другими тремя без действий. В этом примере, если вы отправляете одно сообщение, соответствующее всем пяти правилам, вы получаете три сообщения в подписке. Это будет два сообщения для двух правил с действиями и одно сообщение для трех правил без действий.

Для каждой новой подписки на раздел устанавливается правило подписки с начальным значением по умолчанию. Если явно не указать условие фильтра для этого правила, применяется фильтр true, который отбирает в подписку все сообщения раздела. Для правила по умолчанию не установлено действие по созданию заметок.

Примечание.

Эта статья относится к сценариям, отличным от JMS. В сценариях JMS используйте селекторы сообщений.

Фильтры

служебная шина поддерживает три типа фильтров:

  • Фильтры SQL
  • Логические фильтры
  • Фильтры корреляции

В следующих разделах содержатся сведения об этих фильтрах.

Фильтры SQL

SqlFilter содержит условное выражение SQL, которое будет оцениваться в брокере с учетом определяемых пользователем свойств и системных свойств поступающих сообщений. Все системные свойства в условном выражении предваряются префиксом sys.. Подмножество языка SQL для проверки условий фильтрации для существования свойств (), значений NULL (IS NULLEXISTS), логическихAND//NOTOR, реляционных операторов, простых арифметических и простых текстовых шаблонов, совпадающих с.LIKE

Ниже приведен пример .NET для определения фильтра SQL:

adminClient = new ServiceBusAdministrationClient(connectionString);    

// Create a SQL filter with color set to blue and quantity to 10
await adminClient.CreateSubscriptionAsync(
		new CreateSubscriptionOptions(topicName, "ColorBlueSize10Orders"), 
		new CreateRuleOptions("BlueSize10Orders", new SqlRuleFilter("color='blue' AND quantity=10")));

// Create a SQL filter with color set to red
// Action is defined to set the quantity to half if the color is red
await adminClient.CreateRuleAsync(topicName, "ColorRed", new CreateRuleOptions 
{ 
	Name = "RedOrdersWithAction",
	Filter = new SqlRuleFilter("user.color='red'"),
	Action = new SqlRuleAction("SET quantity = quantity / 2;")
}

Логические фильтры

TrueFilter и FalseFilter либо вызывают все поступающие сообщения (true) или ни один из поступающих сообщений (false) для подписки. Эти два фильтра являются производными от фильтра SQL.

Ниже приведен пример .NET для определения логического фильтра:

// Create a True Rule filter with an expression that always evaluates to true
// It's equivalent to using SQL rule filter with 1=1 as the expression
await adminClient.CreateSubscriptionAsync(
		new CreateSubscriptionOptions(topicName, subscriptionAllOrders), 
		new CreateRuleOptions("AllOrders", new TrueRuleFilter()));

Фильтры корреляции

CorrelationFilter содержит набор условий, которые соответствуют одному или нескольким свойствам пользователя и системы прибывающих сообщений. Обычно они используются для сопоставления со свойством CorrelationId, но приложение также может выбрать сопоставление со следующими свойствами:

  • ContentType
  • Label
  • MessageId
  • ReplyTo
  • ReplyToSessionId
  • SessionId
  • To
  • все определяемые пользователем свойства.

Совпадение регистрируется, когда значение свойства поступающего сообщения равно тому значению, которое указано в фильтре корреляции. Для строковых выражений при сравнении учитывается регистр. При указании нескольких свойств соответствия фильтр объединяет их в виде логического условия И, что означает, что фильтр соответствует, все условия должны соответствовать.

Ниже приведен пример .NET для определения фильтра корреляции:

// Create a correlation filter with color set to Red and priority set to High
await adminClient.CreateSubscriptionAsync(
		new CreateSubscriptionOptions(topicName, "HighPriorityRedOrders"), 
		new CreateRuleOptions("HighPriorityRedOrdersRule", new CorrelationRuleFilter() {Subject = "red", CorrelationId = "high"} ));

CorrelationRuleFilter Используйте конструктор, который принимает String аргумент для создания фильтра корреляции с идентификатором корреляции.

При использовании конструктора CorrelationRuleFilter по умолчанию можно назначать системные свойства (ContentType, , LabelMessageId, ReplyToReplyToSessionId, , SessionIdTo) и пользовательские свойства для фильтрации. Чтобы указать определяемые пользователем свойства для фильтра корреляции, используйте свойство Properties типа IDictionary <string, object>. Ключи этого словаря — это определяемые пользователем свойства для поиска сообщений. Значения, связанные с ключами, — это значения для сопоставления. Вот пример.

var filter = new CorrelationFilter();
filter.Label = "abc";
filter.ReplyTo = "xdeu@hotmail.com";
filter.Properties["prop1"] = "abc";
filter.Properties["prop2"] = "xyz";

Примечание.

  • Все фильтры оценивают только свойства сообщения. Фильтры не могут оценить текст сообщения.
  • Сложные правила фильтрации требуют значительных вычислительных ресурсов. В частности, использование правил фильтрации SQL снижает общую пропускную способность (количество обрабатываемых сообщений) на уровне подписки, раздела и пространства имен. Насколько это возможно, в приложениях вместо фильтров SQL следует применять фильтры корреляции, поскольку они выполняются значительно быстрее и меньше влияют на пропускную способность.

Действия

С помощью условий фильтров SQL можно определить действие, которое добавляет примечания с помощью добавления, удаления или изменения свойств и их значений. В действии используется такое выражение SQL, которое слабо зависит от синтаксиса инструкции SQL UPDATE . Это действие применяется к сообщению после его сопоставления, но до помещения в подписку. Все изменения свойств сообщения действуют только для той копии сообщения, которая помещается в подписку.

Ниже приведен пример .NET, который создает правило SQL с действием для обновления количества, когда цвет красный.

adminClient = new ServiceBusAdministrationClient(connectionString);    

// Create a SQL filter with color set to red
// Action is defined to set the quantity to half if the color is red
await adminClient.CreateRuleAsync(topicName, "ColorRed", new CreateRuleOptions 
{ 
	Name = "RedOrdersWithAction",
	Filter = new SqlRuleFilter("user.color='red'"),
	Action = new SqlRuleAction("SET quantity = quantity / 2;")
}

Варианты использования

  • Шаблон трансляции

    Самый простой сценарий использования разделов — копирование в каждую подписку каждого сообщения, отправляемого в раздел, что соответствует режиму широковещательной трансляции.

  • Шаблон секционирования

    Секционирование использует фильтры для распространения сообщений между несколькими существующими подписками раздела предсказуемым и взаимоисключающим способом. Метод секционирования удобен в том случае, если масштаб системы требует обрабатывать много идентичных по функциональности секций, каждая из которых имеет свой контекст и содержит определенное подмножество данных. В качестве примера можно указать данные профилей клиентов. Издатель, отправляющий сообщение в определенный раздел, не обязан понимать, как работает модель секционирования, и даже знать о ее существовании. Сообщение помещается в нужную подписку, из которой его получает обработчик сообщений, настроенный для этой секции.

  • Шаблон маршрутизации

    Маршрутизация использует фильтры для распространения сообщений между подписками тем в прогнозируемом режиме, но не обязательно эксклюзивным. В сочетании с функцией автоматической переадресации фильтры разделов позволяют создавать сложные схемы маршрутов в пространстве имен сервисной шины и распространять сообщения внутри региона Azure. Если вы примените Функции Azure или Azure Logic Apps в качестве моста между пространствами имен Служебной шины Azure, вы получите возможность создавать еще более сложные глобальные топологии с прямой интеграцией в бизнес-приложения.

Примечание.

Поскольку портал Azure теперь поддерживает работу Service Bus Explorer, фильтры подписки можно создавать и изменять внутри портала.

Следующие шаги

Дополнительные примеры см. в служебная шина примерах фильтров.