Filtry tematów i akcje

Subskrybenci mogą zdefiniować, które komunikaty chcą odbierać z tematu. Komunikaty te są określone w formie co najmniej jednej nazwanej reguły subskrypcji. Każda reguła składa się z warunku filtru, który wybiera określone komunikaty i opcjonalnie zawiera akcję , która donotuje wybrany komunikat.

Wszystkie reguły bez akcji są łączone w oparciu o OR warunek i skutkują pojedynczym komunikatem w subskrypcji, nawet jeśli masz wiele pasujących reguł.

Każda reguła z akcją tworzy kopię komunikatu. Ten komunikat będzie miał właściwość o nazwie RuleName , gdzie wartość jest nazwą zgodnej reguły. Akcja może dodawać lub aktualizować właściwości albo usuwać właściwości z oryginalnego komunikatu w celu wygenerowania komunikatu w subskrypcji.

Rozważmy następujący scenariusz, w którym subskrypcja ma pięć reguł: dwie reguły z akcjami i pozostałe trzy bez akcji. W tym przykładzie, jeśli wyślesz jeden komunikat zgodny ze wszystkimi pięcioma regułami, otrzymasz trzy komunikaty w subskrypcji. To dwa komunikaty dla dwóch reguł z akcjami i jeden komunikat dla trzech reguł bez akcji.

Każda nowo utworzona subskrypcja tematu ma początkową domyślną regułę subskrypcji. Jeśli nie określisz jawnie warunku filtru dla reguły, zastosowany filtr jest prawdziwym filtrem, który umożliwia wybranie wszystkich komunikatów w subskrypcji. Reguła domyślna nie ma skojarzonej akcji adnotacji.

Uwaga

Ten artykuł dotyczy scenariuszy innych niż JMS. W przypadku scenariuszy JMS użyj selektorów komunikatów.

Filtry

Usługa Service Bus obsługuje trzy typy filtrów:

• Filtry SQL
• Filtry logiczne
• Filtry korelacji

Poniższe sekcje zawierają szczegółowe informacje o tych filtrach.

Filtry SQL

Element SqlFilter zawiera wyrażenie warunkowe podobne do języka SQL, które jest oceniane w brokerze względem właściwości użytkownika i właściwości systemowych przychodzących komunikatów. Wszystkie właściwości systemu muszą być poprzedzone prefiksem sys. w wyrażeniu warunkowym. Podzbiór języka SQL dla warunków filtrowania sprawdza istnienie właściwości (), wartości null (EXISTSIS NULL), operatorów logicznych NOT/AND/OR, relacyjnych, prostych arytmetycznych liczbowych i prostego wzorca tekstu pasującego do LIKEelementu .

Oto przykład platformy .NET do definiowania filtru 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;")
}

Filtry logiczne

Wartości TrueFilter i FalseFilter powodują wybranie wszystkich przychodzących komunikatów (true) lub brak przychodzących komunikatów (false) dla subskrypcji. Te dwa filtry pochodzą z filtru SQL.

Oto przykład w .NET definiujący filtr boolowski.

// 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()));	

Filtry korelacji

Właściwość CorrelationFilter zawiera zestaw warunków, które są zgodne z co najmniej jedną właściwością użytkownika i systemu odbierającego komunikatu. Typowym zastosowaniem jest dopasowywanie do właściwości CorrelationId, ale aplikacja może także korzystać z dopasowywania do następujących właściwości:

• ContentType
• Label
• MessageId
• ReplyTo
• ReplyToSessionId
• SessionId
• To
• wszelkie właściwości zdefiniowane przez użytkownika.

Dopasowanie istnieje, gdy wartość przychodzącego komunikatu dla właściwości jest równa wartości określonej w filtrze korelacji. W przypadku wyrażeń ciągów jest uwzględniana wielkość liter. Jeśli określisz wiele właściwości dopasowania, filtr łączy je jako logiczny warunek AND, co oznacza, że aby filtr zadziałał, wszystkie warunki muszą być spełnione.

Oto przykład platformy .NET do definiowania filtru korelacji:

// 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"} ));	

Użyj konstruktora CorrelationRuleFilter , który przyjmuje String argument , aby utworzyć filtr korelacji z identyfikatorem korelacji.

Używając CorrelationRuleFilter konstruktora domyślnego, można przypisać właściwości systemowe (ContentType, Label, MessageId, ReplyTo, ReplyToSessionId, SessionId, To) oraz właściwości zdefiniowane przez użytkownika do filtrowania. Aby określić właściwości zdefiniowane przez użytkownika dla filtru korelacji, użyj właściwości Properties typu IDictionary <string, object>. Klucze dla tego słownika są właściwościami zdefiniowanymi przez użytkownika do przeszukiwania wiadomości. Wartości skojarzone z kluczami to wartości do skorelowania. Oto przykład.

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

Uwaga

• Wszystkie filtry oceniają właściwości komunikatu. Filtry nie mogą ocenić treści komunikatu.
• Złożone reguły filtrowania wymagają pojemności przetwarzania. W szczególności użycie reguł filtru SQL powoduje obniżenie ogólnej przepływności komunikatów na poziomie subskrypcji, tematu i przestrzeni nazw. Jeśli to możliwe, aplikacje powinny wybierać filtry korelacji zamiast filtrów przypominających język SQL, ponieważ są znacznie bardziej wydajne w przetwarzaniu i mają mniejszy wpływ na wydajność.

Akcje

Za pomocą warunków filtru SQL można zdefiniować akcję, która może dodawać adnotacje do komunikatu, dodając, usuwając lub zastępując właściwości i ich wartości. Akcja używa wyrażenia przypominającego sql, które luźno opiera się na SQL UPDATE składni instrukcji. Akcja jest wykonywana po dopasowaniu komunikatu i przed wybraniem komunikatu do subskrypcji. Zmiany we właściwościach komunikatu są prywatne dla komunikatu skopiowanego do subskrypcji.

Oto przykład platformy .NET, który tworzy regułę SQL z akcją w celu zaktualizowania ilości, gdy kolor jest czerwony.

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;")
}

Ważne

Podczas aktualizowania właściwości systemu za pomocą akcji reguły może to spowodować zmianę oczekiwanego zachowania. Niektóre właściwości są oceniane tylko wtedy, gdy komunikat zostanie odebrany w kolejce lub temacie. W związku z tym, gdy aktualizujesz te właściwości w akcji reguły i następnie dostarczasz je w subskrypcji, są one ignorowane. Kiedy następuje automatyczne przekazywanie do innej kolejki lub tematu, są one ponownie oceniane.

• ScheduledEnqueueTime: po ustawieniu lub zaktualizowaniu tej właściwości jest ona ignorowana w subskrypcji.
• MessageID z deduplikacją: w subskrypcji nie jest wykonywana deduplikacja, gdy identyfikator MessageID jest aktualizowany i powoduje zduplikowanie.
• SessionID z partycjonowaniem: w tym scenariuszu identyfikator sesji jest kluczem partycji dla jednostek partycjonowanych i służy do decydowania o partycji, do którego jest wysyłany komunikat. Zmiana identyfikatora sesji w akcji reguły oznacza, że klucz partycji jest zmieniany po dostarczeniu komunikatu do partycji. W związku z tym użytkownik może nie odbierać niektórych z tych komunikatów w sesji. Nawet jeśli konsument otrzyma komunikat, wydaje się, że pochodzi on z nieprawidłowej partycji z powodu zmienionego klucza partycji.

Wzorce użycia

• Wzorzec emisji

  Najprostszym scenariuszem użycia tematu jest to, że każda subskrypcja pobiera kopię każdego komunikatu wysyłanego do tematu, co umożliwia wzorzec emisji.

• Wzorzec partycjonowania

  Partycjonowanie używa filtrów do dystrybucji komunikatów w kilku istniejących subskrypcjach tematów w przewidywalny i wzajemnie wykluczający się sposób. Wzorzec partycjonowania jest używany, gdy system jest skalowany w poziomie w celu obsługi wielu różnych kontekstów w funkcjonalnych identycznych przedziałach, z których każdy przechowuje podzbiór ogólnych danych; na przykład informacje o profilu klienta. W przypadku partycjonowania wydawca przesyła komunikat do tematu bez konieczności znajomości modelu partycjonowania. Następnie komunikat zostanie przeniesiony do właściwej subskrypcji, z której można go pobrać przez procedurę obsługi komunikatów partycji.

• Wzorzec routingu

  Routing używa filtrów do dystrybucji komunikatów między subskrypcjami tematów w przewidywalny sposób, ale niekoniecznie wyłącznie. W połączeniu z funkcją automatycznego przekazywania filtry tematów mogą służyć do tworzenia złożonych wykresów routingu w przestrzeni nazw usługi Service Bus na potrzeby dystrybucji komunikatów w regionie świadczenia usługi Azure. Usługa Azure Functions lub Azure Logic Apps działająca jako most między przestrzeniami nazw usługi Azure Service Bus umożliwia tworzenie złożonych globalnych topologii z bezpośrednią integracją z aplikacjami biznesowymi.

Uwaga

Ponieważ witryna Azure Portal obsługuje teraz funkcje Eksploratora usługi Service Bus, filtry subskrypcji można tworzyć lub edytować w portalu.

Następne kroki

Aby uzyskać więcej przykładów, zobacz Przykłady filtrów usługi Service Bus.