Onderwerpfilters en acties
Abonnees kunnen definiëren welke berichten ze willen ontvangen van een onderwerp. Deze berichten worden opgegeven in de vorm van een of meer benoemde abonnementsregels. Elke regel bestaat uit een filtervoorwaarde die bepaalde berichten selecteert en eventueel een actie bevat waarmee aantekeningen worden toegevoegd aan het geselecteerde bericht.
Alle regels zonder acties worden gecombineerd met behulp van een OR
voorwaarde en resulteren in één bericht in het abonnement, zelfs als u meerdere overeenkomende regels hebt.
Elke regel met een actie produceert een kopie van het bericht. Dit bericht heeft een eigenschap die wordt aangeroepen RuleName
waarbij de waarde de naam van de overeenkomende regel is. De actie kan eigenschappen toevoegen of bijwerken, of eigenschappen verwijderen uit het oorspronkelijke bericht om een bericht in het abonnement te produceren.
Overweeg het volgende scenario waarbij een abonnement vijf regels heeft: twee regels met acties en de andere drie zonder acties. Als u in dit voorbeeld één bericht verzendt dat overeenkomt met alle vijf regels, krijgt u drie berichten over het abonnement. Dat zijn twee berichten voor twee regels met acties en één bericht voor drie regels zonder acties.
Elk nieuw gemaakt onderwerpabonnement heeft een initiële standaardabonnementsregel. Als u niet expliciet een filtervoorwaarde voor de regel opgeeft, is het toegepaste filter het ware filter waarmee alle berichten in het abonnement kunnen worden geselecteerd. De standaardregel heeft geen gekoppelde aantekeningsactie.
Notitie
Dit artikel is van toepassing op niet-JMS-scenario's. Voor JMS-scenario's gebruikt u berichtkiezers.
Filters
Service Bus ondersteunt drie typen filters:
- SQL-filters
- Booleaanse filters
- Correlatiefilters
In de volgende secties vindt u meer informatie over deze filters.
SQL-filters
Een SqlFilter bevat een SQL-achtige voorwaardelijke expressie die in de broker wordt geëvalueerd op basis van de door de gebruiker gedefinieerde eigenschappen en systeemeigenschappen van de binnenkomende berichten. Alle systeemeigenschappen moeten worden voorafgegaan door sys.
de voorwaardelijke expressie. De SQL-taalsubset voor filtervoorwaardentests voor het bestaan van eigenschappen (), null-waarden (IS NULL
EXISTS
), logischeNOT
//AND
OR
, relationele operatoren, eenvoudige rekenkundige berekeningen en eenvoudige tekstpatronen die overeenkomen met .LIKE
Hier volgt een .NET-voorbeeld voor het definiëren van een SQL-filter:
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;")
}
Booleaanse filters
Met TrueFilter en FalseFilter worden alle binnenkomende berichten (true) of geen van de binnenkomende berichten (onwaar) geselecteerd voor het abonnement. Deze twee filters zijn afgeleid van het SQL-filter.
Hier volgt een .NET-voorbeeld voor het definiëren van een Booleaanse filter:
// 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()));
Correlatiefilters
Een CorrelationFilter bevat een set voorwaarden die overeenkomen met een of meer van de gebruikers- en systeemeigenschappen van een binnenkomend bericht. Een veelvoorkomend gebruik is om overeen te komen met de eigenschap CorrelationId , maar de toepassing kan er ook voor kiezen om overeen te komen met de volgende eigenschappen:
ContentType
Label
MessageId
ReplyTo
ReplyToSessionId
SessionId
To
- door de gebruiker gedefinieerde eigenschappen.
Er bestaat een overeenkomst wanneer de waarde van een binnenkomend bericht voor een eigenschap gelijk is aan de waarde die is opgegeven in het correlatiefilter. Voor tekenreeksexpressies is de vergelijking hoofdlettergevoelig. Als u meerdere overeenkomsteigenschappen opgeeft, worden deze door het filter gecombineerd als een logische AND-voorwaarde, wat betekent dat het filter overeenkomt, moeten alle voorwaarden overeenkomen.
Hier volgt een .NET-voorbeeld voor het definiëren van een correlatiefilter:
// 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"} ));
Gebruik de CorrelationRuleFilter
constructor die een String
argument gebruikt om een correlatiefilter te maken met een correlatie-id.
Wanneer u de CorrelationRuleFilter
standaardconstructor gebruikt, kunt u systeemeigenschappen (ContentType
, , MessageId
ReplyToSessionId
Label
ReplyTo
, SessionId
) To
en door de gebruiker gedefinieerde eigenschappen toewijzen voor filteren. Als u door de gebruiker gedefinieerde eigenschappen voor correlatiefilter wilt opgeven, gebruikt u de eigenschap Properties
van het type IDictionary <string, object>
. Sleutels voor deze woordenlijst zijn de door de gebruiker gedefinieerde eigenschappen om op te zoeken naar berichten. Waarden die zijn gekoppeld aan sleutels zijn de waarden waarop moet worden gecorreleerd. Hier volgt een voorbeeld.
var filter = new CorrelationFilter();
filter.Label = "abc";
filter.ReplyTo = "xdeu@hotmail.com";
filter.Properties["prop1"] = "abc";
filter.Properties["prop2"] = "xyz";
Notitie
- Alle filters evalueren berichteigenschappen. Filters kunnen de hoofdtekst van het bericht niet evalueren.
- Voor complexe filterregels is verwerkingscapaciteit vereist. Het gebruik van SQL-filterregels zorgt met name voor een lagere totale berichtdoorvoer op abonnements-, onderwerp- en naamruimteniveau. Waar mogelijk moeten toepassingen correlatiefilters kiezen boven SQL-achtige filters, omdat ze veel efficiënter zijn in de verwerking en minder invloed hebben op de doorvoer.
Acties
Met SQL-filtervoorwaarden kunt u een actie definiëren die aantekeningen kan toevoegen aan het bericht door eigenschappen en de bijbehorende waarden toe te voegen, te verwijderen of te vervangen. De actie maakt gebruik van een SQL-achtige expressie die losjes leunt op de syntaxis van de SQL UPDATE
instructie. De actie wordt uitgevoerd op het bericht nadat het is vergeleken en voordat het bericht in het abonnement is geselecteerd. De wijzigingen in de berichteigenschappen zijn privé voor het bericht dat in het abonnement is gekopieerd.
Hier volgt een .NET-voorbeeld waarmee een SQL-regel wordt gemaakt met een actie om de hoeveelheid bij te werken wanneer de kleur Rood is.
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;")
}
Belangrijk
Wanneer u systeemeigenschappen bijwerkt via regelacties, moet u er rekening mee houden dat het verwachte gedrag mogelijk wordt gewijzigd. Sommige eigenschappen worden alleen geëvalueerd wanneer een bericht wordt ontvangen in een wachtrij of een onderwerp. Daarom worden ze genegeerd wanneer u deze eigenschappen bijwerkt in een regelactie en deze vervolgens in een abonnement levert. Hoewel, wanneer automatisch doorsturen naar een andere wachtrij of een ander onderwerp, ze opnieuw worden geëvalueerd.
- ScheduledEnqueueTime: Wanneer u deze eigenschap instelt of bijwerkt, wordt deze genegeerd voor het abonnement.
- MessageID met ontdubbeling: er wordt geen ontdubbeling uitgevoerd in het abonnement wanneer de MessageID wordt bijgewerkt en resulteert in een duplicaat.
- SessionID met partitionering: In dit scenario is de sessie-id de partitiesleutel voor gepartitioneerde entiteiten en wordt gebruikt om te bepalen naar welke partitie het bericht wordt verzonden. Als u de sessie-id wijzigt in een regelactie, betekent dit dat de partitiesleutel wordt gewijzigd nadat een bericht in een partitie is terechtgekomen. Als gevolg hiervan ontvangt de consument mogelijk geen enkele van deze berichten in de sessie. Zelfs als de consument het bericht ontvangt, lijkt het alsof deze afkomstig zijn van de verkeerde partitie vanwege de gewijzigde partitiesleutel.
Gebruikspatronen
Broadcast-patroon
Het eenvoudigste gebruiksscenario voor een onderwerp is dat elk abonnement een kopie ontvangt van elk bericht dat naar een onderwerp wordt verzonden, waardoor een broadcast-patroon mogelijk is.
Partitioneringspatroon
Partitionering maakt gebruik van filters voor het distribueren van berichten over verschillende bestaande onderwerpabonnementen op een voorspelbare en wederzijds exclusieve manier. Het partitioneringspatroon wordt gebruikt wanneer een systeem wordt uitgeschaald om veel verschillende contexten in functioneel identieke compartimenten te verwerken die elk een subset van de algemene gegevens bevatten; Bijvoorbeeld klantprofielgegevens. Bij partitionering verzendt een uitgever het bericht naar een onderwerp zonder dat u kennis hoeft te hebben van het partitioneringsmodel. Het bericht wordt vervolgens verplaatst naar het juiste abonnement waaruit het vervolgens kan worden opgehaald door de berichthandler van de partitie.
Routeringspatroon
Routering maakt gebruik van filters voor het distribueren van berichten over onderwerpabonnementen op voorspelbare wijze, maar niet noodzakelijkerwijs exclusief. In combinatie met de functie voor automatisch doorsturen kunnen onderwerpfilters worden gebruikt om complexe routeringsgrafieken te maken binnen een Service Bus-naamruimte voor berichtdistributie binnen een Azure-regio. Met Azure Functions of Azure Logic Apps die fungeren als een brug tussen Azure Service Bus-naamruimten, kunt u complexe wereldwijde topologieën maken met directe integratie in Line-Of-Business-toepassingen.
Notitie
Omdat De Azure-portal nu ondersteuning biedt voor De functionaliteit van Service Bus Explorer, kunnen abonnementsfilters worden gemaakt of bewerkt vanuit de portal.
Volgende stappen
Zie Service Bus-filtervoorbeelden voor meer voorbeelden.