Verbinding maken met Azure Service Bus vanuit werkstromen in Azure Logic Apps
Van toepassing op: Azure Logic Apps (Verbruik + Standard)
Deze handleiding laat zien hoe u toegang krijgt tot Azure Service Bus vanuit een werkstroom in Azure Logic Apps met behulp van de Service Bus-connector. Vervolgens kunt u geautomatiseerde werkstromen maken die worden uitgevoerd wanneer ze worden geactiveerd door gebeurtenissen in een servicebus of acties uitvoeren om Service Bus-items te beheren, bijvoorbeeld:
- Controleer wanneer berichten binnenkomen (automatisch aanvullen) of worden ontvangen (peek-lock) in wachtrijen, onderwerpen en onderwerpabonnementen.
- Berichten verzenden.
- Onderwerpabonnementen maken en verwijderen.
- Beheer berichten in wachtrijen en onderwerpabonnementen, bijvoorbeeld ophalen, uitstellen, uitstellen, verlaten en dode letter.
- Verleng vergrendelingen voor berichten en sessies in wachtrijen en onderwerpabonnementen.
- Sluit sessies in wachtrijen en onderwerpen.
U kunt triggers gebruiken die antwoorden krijgen van Azure Service Bus en de uitvoer beschikbaar maken voor andere acties in uw werkstromen. U kunt ook andere acties gebruiken om de uitvoer van Service Bus-acties te gebruiken.
Technische naslaginformatie over connectoren
De Service Bus-connector heeft verschillende versies, op basis van het werkstroomtype van de logische app en de hostomgeving.
| Logische apps | Omgeving | Connectorversie |
|---|---|---|
| Verbruik | Multitenant Azure Logic Apps | Beheerde connector, die wordt weergegeven in de galerie met connectors onder Runtime>Shared. Opmerking: Door Service Bus beheerde connectortriggers volgen het lange polling-triggerpatroon, wat betekent dat de trigger periodiek controleert op berichten in de wachtrij of het onderwerpabonnement. Raadpleeg de volgende documentatie voor meer informatie: - Naslaginformatie over beheerde Service Bus-connectors - Beheerde connectors in Azure Logic Apps |
| Standaard | Azure Logic Apps en App Service Environment v3 met één tenant (alleen Windows-abonnementen) | Beheerde connector (door Azure gehost), die wordt weergegeven in de connectorgalerie onder Runtime>Shared en ingebouwde connector, die wordt weergegeven in de connectorgalerie onder Runtime>In App en is gebaseerd op serviceproviders. De triggers van de beheerde Service Bus-connector volgen het lange polling-triggerpatroon, wat betekent dat de trigger periodiek controleert op berichten in de wachtrij of het onderwerpabonnement. De niet-sessietriggers van de Service Bus-connector volgen een doorlopend polling-triggerpatroon dat volledig wordt beheerd door de connector. Dit patroon zorgt ervoor dat de trigger voortdurend controleert op berichten in de wachtrij of het onderwerpabonnement. Sessietriggers volgen het patroon van de lang polling-trigger, maar de configuratie ervan wordt bepaald door de Azure Functions-instelling met de naam clientRetryOptions:tryTimeout. De ingebouwde versie biedt meestal betere prestaties, mogelijkheden, prijzen, enzovoort. |
Raadpleeg de volgende documentatie voor meer informatie: - Naslaginformatie over beheerde Service Bus-connectors - Ingebouwde Service Bus-connectorbewerkingen - Ingebouwde connectors in Azure Logic Apps |
Vereisten
Een Azure-account en -abonnement. Als u nog geen abonnement op Azure hebt, registreer u dan nu voor een gratis Azure-account.
Een Service Bus-naamruimte en berichtenentiteit, zoals een wachtrij. Raadpleeg de volgende documentatie voor meer informatie:
De werkstroom van de logische app waar u verbinding maakt met uw Service Bus-naamruimte en berichtenentiteit. Als u uw werkstroom wilt starten met een Service Bus-trigger, moet u beginnen met een lege werkstroom. Als u een Service Bus-actie in uw werkstroom wilt gebruiken, start u uw werkstroom met een trigger.
Als uw logische app-resource gebruikmaakt van een beheerde identiteit voor het verifiëren van de toegang tot uw Service Bus-naamruimte en berichtenentiteit, moet u ervoor zorgen dat u rolmachtigingen hebt toegewezen op de bijbehorende niveaus. Als u bijvoorbeeld toegang wilt krijgen tot een wachtrij, vereist de beheerde identiteit een rol met de benodigde machtigingen voor die wachtrij.
Elke logische app-resource mag slechts één beheerde identiteit gebruiken, zelfs als de werkstroom van de logische app toegang heeft tot verschillende berichtenentiteiten.
Elke beheerde identiteit die toegang heeft tot een wachtrij of onderwerpabonnement, moet een eigen Service Bus API-verbinding gebruiken.
Service Bus-bewerkingen die berichten uitwisselen met verschillende berichtenentiteiten en waarvoor verschillende machtigingen zijn vereist, moeten hun eigen Service Bus API-verbindingen gebruiken.
Zie Toegang tot Azure-resources verifiëren met beheerde identiteiten in Azure Logic Apps voor meer informatie over beheerde identiteiten.
De ingebouwde Service Bus-connectorbewerkingen zijn standaard staatloos. Zie Stateful modus inschakelen voor stateless ingebouwde connectors om deze bewerkingen uit te voeren in de stateful modus.
Overwegingen voor Azure Service Bus-bewerkingen
Oneindige lussen
Belangrijk
Wees voorzichtig wanneer u zowel een trigger als een actie selecteert met hetzelfde connectortype en deze gebruikt om met dezelfde entiteit te werken, zoals een berichtenwachtrij of een onderwerpabonnement. Deze combinatie kan een oneindige lus maken, wat resulteert in een logische app die nooit eindigt.
Limiet voor opgeslagen sessies in connectorcache
Per Service Bus-berichtenentiteit, zoals een abonnement of onderwerp, kan de Service Bus-connector maximaal 1500 unieke sessies tegelijk opslaan in de connectorcache. Als het aantal sessies deze limiet overschrijdt, worden oude sessies uit de cache verwijderd. Zie Berichtensessies voor meer informatie.
Gecorreleerde berichten in volgorde verzenden
Wanneer u gerelateerde berichten in een specifieke volgorde wilt verzenden, kunt u een werkstroom maken met behulp van de Service Bus-connector en het sequentiële convoypatroon. Gecorreleerde berichten hebben een eigenschap die de relatie tussen deze berichten definieert, zoals de id voor de sessie in Azure Service Bus.
Wanneer u een werkstroom voor logische verbruiks-apps maakt, kunt u de gecorreleerde levering in bestelling selecteren met behulp van de Service Bus-sessiesjabloon , waarmee het sequentiële convoypatroon wordt geïmplementeerd. Zie Verwante berichten op volgorde verzenden voor meer informatie.
Ondersteuning voor grote berichten
Ondersteuning voor grote berichten is alleen beschikbaar voor Standaardwerkstromen wanneer u de ingebouwde Service Bus-connectorbewerkingen gebruikt. U kunt bijvoorbeeld grote berichten ontvangen en grote berichten ontvangen met behulp van respectievelijk de ingebouwde triggers en acties.
Voor de beheerde Service Bus-connector is de maximale berichtgrootte beperkt tot 1 MB, zelfs wanneer u een Service Bus-naamruimte in de Premium-laag gebruikt.
Time-out verhogen voor het ontvangen en verzenden van berichten
In standaardwerkstromen die gebruikmaken van de ingebouwde Service Bus-bewerkingen, kunt u de time-out voor het ontvangen en verzenden van berichten verhogen. Als u bijvoorbeeld de time-out voor het ontvangen van een bericht wilt verhogen, wijzigt u de volgende instelling in de Azure Functions-extensie:
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
"version": "[1.*, 2.0.0)"
},
"extensions": {
"serviceBus": {
"batchOptions": {
"operationTimeout": "00:15:00"
}
}
}
}
Als u de time-out voor het verzenden van een bericht wilt verhogen, voegt u de app-instelling ServiceProviders.ServiceBus.MessageSenderOperationTimeout toe.
Door Service Bus beheerde connectortriggers
Voor de beheerde Service Bus-connector zijn alle triggers lang polling. Dit triggertype verwerkt alle berichten en wacht vervolgens 30 seconden tot meer berichten worden weergegeven in de wachtrij of het onderwerpabonnement. Als er binnen 30 seconden geen berichten worden weergegeven, wordt de trigger-uitvoering overgeslagen. Anders blijft de trigger berichten lezen totdat de wachtrij of het onderwerpabonnement leeg is. De volgende trigger poll is gebaseerd op het terugkeerinterval dat is opgegeven in de eigenschappen van de trigger.
Sommige triggers, zoals wanneer een of meer berichten binnenkomen in een wachtrijtrigger (automatisch aanvullen), kunnen een of meer berichten retourneren. Wanneer deze triggers worden geactiveerd, worden ze geretourneerd tussen één en het aantal berichten dat is opgegeven door de eigenschap Maximum aantal berichten van de trigger.
Notitie
De trigger voor automatisch aanvullen voltooit automatisch een bericht, maar de voltooiing vindt alleen plaats bij de volgende aanroep van Service Bus. Dit gedrag kan van invloed zijn op uw werkstroomontwerp. Vermijd bijvoorbeeld dat u de gelijktijdigheid van de trigger voor automatisch aanvullen wijzigt, omdat deze wijziging kan leiden tot dubbele berichten als uw werkstroom een beperkte status treedt. Als u het gelijktijdigheidsbeheer wijzigt, worden de volgende voorwaarden gemaakt:
Vertraagde triggers worden overgeslagen met de
WorkflowRunInProgresscode.De voltooiingsbewerking wordt niet uitgevoerd.
De volgende triggeruitvoering vindt plaats na het polling-interval.
U moet de duur van de service busvergrendeling instellen op een waarde die langer is dan het polling-interval. Ondanks deze instelling kan het bericht echter nog steeds niet worden voltooid als uw werkstroom in een beperkte status blijft bij het volgende polling-interval.
Als u echter de gelijktijdigheidsinstelling van een Service Bus-trigger inschakelt, is de standaardwaarde voor de
maximumWaitingRunseigenschap 10. Op basis van de instelling voor de vergrendelingsduur van de Service Bus-entiteit en de uitvoeringsduur voor uw werkstroom, kan deze standaardwaarde te groot zijn en kan dit leiden tot een uitzondering voor 'vergrendelen'. Als u de optimale waarde voor uw scenario wilt vinden, begint u te testen met een waarde van 1 of 2 voor demaximumWaitingRunseigenschap. Als u de waarde voor maximale wachtuitvoeringen wilt wijzigen, raadpleegt u De limiet voor wachtende uitvoeringen wijzigen.
Ingebouwde Service Bus-connectortriggers
Voor de ingebouwde Service Bus-connector volgen niet-sessietriggers een doorlopend polling-triggerpatroon dat volledig wordt beheerd door de connector. Dit patroon zorgt ervoor dat de trigger voortdurend controleert op berichten in de wachtrij of het onderwerpabonnement. Sessietriggers volgen het patroon lang pollingtriggers, waarbij de configuratie ervan wordt bepaald door de Azure Functions-instelling met de naam clientRetryOptions:tryTimeout. Momenteel worden de configuratie-instellingen voor de ingebouwde Service Bus-trigger gedeeld tussen de Azure Functions-hostextensie, die is gedefinieerd in het host.json-bestand van uw logische app en de triggerinstellingen die zijn gedefinieerd in de werkstroom van uw logische app, die u kunt instellen via de ontwerpfunctie of codeweergave. In deze sectie worden beide instellingenlocaties behandeld.
In standaardwerkstromen kunnen sommige triggers, zoals wanneer berichten beschikbaar zijn in een wachtrijtrigger , een of meer berichten retourneren. Wanneer deze triggers worden geactiveerd, worden ze tussen één en het aantal berichten geretourneerd. Voor dit type trigger en waarbij de parameter Maximum aantal berichten niet wordt ondersteund, kunt u nog steeds het aantal berichten beheren dat wordt ontvangen met behulp van de eigenschap maxMessageBatchSize in het host.json-bestand . Zie Host- en app-instellingen bewerken voor Standaard logische apps om dit bestand te vinden.
"extensions": { "serviceBus": { "maxMessageBatchSize": 25 } }U kunt ook gelijktijdigheid inschakelen voor de Service Bus-trigger, hetzij via de ontwerpfunctie of in code:
"runtimeConfiguration": { "concurrency": { "runs": 100 } }Wanneer u gelijktijdigheid instelt met behulp van een batch, houdt u het aantal gelijktijdige uitvoeringen groter dan de totale batchgrootte. Op die manier gaan leesberichten niet in een wachtstatus en worden ze altijd opgehaald wanneer ze worden gelezen. In sommige gevallen kan de trigger maximaal twee keer de batchgrootte hebben.
Als u gelijktijdigheid inschakelt, wordt de limiet voor SplitOn beperkt tot 100 items. Dit gedrag geldt voor alle triggers, niet alleen voor de Service Bus-trigger. Zorg ervoor dat de opgegeven batchgrootte kleiner is dan deze limiet voor elke trigger waarin u gelijktijdigheid inschakelt.
Sommige scenario's bestaan waarbij de trigger de gelijktijdigheidsinstellingen kan overschrijden. In plaats van deze uitvoeringen te mislukken, worden deze in Azure Logic Apps in een wachtrij geplaatst totdat ze kunnen worden gestart. De instelling maximumWaitingRuns bepaalt het aantal uitvoeringen dat is toegestaan in de wachtstatus:
"runtimeConfiguration": { "concurrency": { "runs": 100, "maximumWaitingRuns": 50 } }Zorg ervoor dat u met de Service Bus-trigger deze wijzigingen zorgvuldig test, zodat uitvoeringen niet langer wachten dan de time-out voor het vergrendelen van berichten. Zie hier de limieten voor gelijktijdigheid en de batchverwerking voor meer informatie over de standaardwaarden.
Als u gelijktijdigheid inschakelt, bestaat er standaard een vertraging van 30 seconden tussen batchleesbewerkingen. Deze vertraging vertraagt de trigger om de volgende doelen te bereiken:
Verminder het aantal opslagoproepen dat wordt verzonden om het aantal uitvoeringen te controleren waarop gelijktijdigheid moet worden toegepast.
Mimic the behavior of the Service Bus managed connector trigger, which has a 30-second long poll when no messages are found.
U kunt deze vertraging wijzigen, maar zorg ervoor dat u wijzigingen in de standaardwaarde zorgvuldig test:
"workflow": { "settings": { "Runtime.ServiceProviders.FunctionTriggers.DynamicListenerEnableDisableInterval": "00:00:30" } }
Stap 1: Toegang tot Service Bus-naamruimte controleren
Gebruik de volgende stappen om te bevestigen dat uw logische app-resource machtigingen heeft voor toegang tot uw Service Bus-naamruimte:
Open uw Service Bus-naamruimte in Azure Portal.
Selecteer in het naamruimtemenu onder Instellingen het beleid voor gedeelde toegang. Controleer onder Claims of u machtigingen voor deze naamruimte hebt.
Stap 2: Vereisten voor verbindingsverificatie ophalen
Wanneer u later voor het eerst een Service Bus-trigger of -actie toevoegt, wordt u gevraagd om verbindingsgegevens, inclusief het verificatietype voor de verbinding. Op basis van het werkstroomtype van uw logische app, de versie van de Service Bus-connector en het geselecteerde verificatietype hebt u het volgende nodig:
Verificatie van beheerde connectors (verbruiks- en standaardwerkstromen)
| Authentication type | Vereiste informatie |
|---|---|
| Toegangssleutel | De verbindingsreeks voor uw Service Bus-naamruimte. Zie Get verbindingsreeks voor Service Bus-naamruimte voor meer informatie |
| Microsoft Entra geïntegreerd | De eindpunt-URL voor uw Service Bus-naamruimte. Raadpleeg de eindpunt-URL ophalen voor Service Bus-naamruimte voor meer informatie. |
| Beheerde identiteit van Logic Apps | De eindpunt-URL voor uw Service Bus-naamruimte. Raadpleeg de eindpunt-URL ophalen voor Service Bus-naamruimte voor meer informatie. |
Ingebouwde connectorverificatie (alleen standaardwerkstromen)
| Authentication type | Vereiste informatie |
|---|---|
| Verbindingsreeks | De verbindingsreeks voor uw Service Bus-naamruimte. Zie Get verbindingsreeks voor Service Bus-naamruimte voor meer informatie |
| Active Directory OAuth | - De volledig gekwalificeerde naam voor uw Service Bus-naamruimte, bijvoorbeeld <your-Service-Bus-namespace.servicebus.windows.net.> Zie Volledig gekwalificeerde naam ophalen voor Service Bus-naamruimte voor meer informatie. Zie OAuth met Microsoft Entra ID voor de andere eigenschapswaarden. |
| Beheerde identiteit | De volledig gekwalificeerde naam voor uw Service Bus-naamruimte, bijvoorbeeld <your-Service-Bus-namespace.servicebus.windows.net.> Zie Volledig gekwalificeerde naam ophalen voor Service Bus-naamruimte voor meer informatie. |
Verbindingsreeks voor Service Bus-naamruimte ophalen
Als u een verbinding wilt maken wanneer u een Service Bus-trigger of -actie toevoegt, moet u de verbindingsreeks voor uw Service Bus-naamruimte hebben. De verbindingsreeks begint met het voorvoegsel sb://.
Open uw Service Bus-naamruimte in Azure Portal.
Selecteer in het naamruimtemenu onder Instellingen het beleid voor gedeelde toegang.
Selecteer RootManageSharedAccessKey in het deelvenster Beleid voor gedeelde toegang.
Selecteer naast de primaire of secundaire verbindingsreeks de knop Kopiëren.
Notitie
Als u wilt controleren of de tekenreeks voor de naamruimte is, niet voor een specifieke berichtenentiteit, zoekt u in de verbindingsreeks naar de
EntityPathparameter. Als u deze parameter vindt, is de verbindingsreeks voor een specifieke entiteit en is dit niet de juiste tekenreeks die u met uw werkstroom kunt gebruiken.Sla de verbindingsreeks op voor later gebruik.
Eindpunt-URL ophalen voor Service Bus-naamruimte
Als u de beheerde Service Bus-connector gebruikt, hebt u deze eindpunt-URL nodig als u het verificatietype selecteert voor geïntegreerde Microsoft Entra- of Logic Apps Managed Identity. De eindpunt-URL begint met het voorvoegsel sb:// .
Open uw Service Bus-naamruimte in Azure Portal.
Selecteer Eigenschappen in het menu naamruimte onder Instellingen.
Kopieer onder Eigenschappen naast het Service Bus-eindpunt de eindpunt-URL en sla deze op voor later gebruik wanneer u de URL van het Service Bus-eindpunt moet opgeven.
Volledig gekwalificeerde naam voor Service Bus-naamruimte ophalen
Open uw Service Bus-naamruimte in Azure Portal.
Selecteer Overzicht in het menu naamruimte.
Zoek in het deelvenster Overzicht de eigenschap Hostnaam en kopieer de volledig gekwalificeerde naam, die eruitziet als< your-Service-Bus-namespace.servicebus.windows.net.>
Stap 3: optie 1: een Service Bus-trigger toevoegen
In de volgende stappen wordt Azure Portal gebruikt, maar met de juiste Azure Logic Apps-extensie kunt u ook de volgende hulpprogramma's gebruiken om werkstromen voor logische apps te maken:
Werkstromen voor logische apps voor verbruik: Visual Studio of Visual Studio Code
Standaardwerkstromen voor logische apps: Visual Studio Code
Open in Azure Portal de resource van de logische app Verbruik met een lege werkstroom in de ontwerpfunctie.
Volg deze algemene stappen in de ontwerpfunctie om de gewenste Azure Service Bus-trigger toe te voegen.
In dit voorbeeld wordt de trigger voortgezet met de naam Wanneer een bericht wordt ontvangen in een wachtrij (automatisch aanvullen).
Als u hierom wordt gevraagd, geeft u de volgende informatie op voor uw verbinding. Selecteer Maken als u klaar bent.
Eigenschappen Vereist Beschrijving Verbindingsnaam Ja Een naam voor uw verbinding Verificatietype Ja Het type verificatie dat moet worden gebruikt voor toegang tot uw Service Bus-naamruimte. Raadpleeg de verificatie van beheerde connectors voor meer informatie. Verbindingsreeks Ja De verbindingsreeks die u eerder hebt gekopieerd en opgeslagen. Deze verbinding maakt bijvoorbeeld gebruik van toegangssleutelverificatie en biedt de verbindingsreeks voor een Service Bus-naamruimte:
Nadat het triggerinformatievak wordt weergegeven, geeft u de benodigde informatie op, bijvoorbeeld:
Eigenschappen Vereist Beschrijving Wachtrijnaam Ja De geselecteerde wachtrij voor toegang Wachtrijtype Nee Het type voor de geselecteerde wachtrij Hoe vaak wilt u controleren op items? Ja Het polling-interval en de frequentie om de wachtrij voor items te controleren 
Als u andere beschikbare eigenschappen aan de trigger wilt toevoegen, opent u de lijst nieuwe parameters toevoegen en selecteert u de gewenste eigenschappen.
Voeg alle acties toe die uw werkstroom nodig heeft.
U kunt bijvoorbeeld een actie toevoegen waarmee e-mail wordt verzonden wanneer er een nieuw bericht binnenkomt. Wanneer uw trigger uw wachtrij controleert en een nieuw bericht vindt, voert uw werkstroom de geselecteerde acties voor het gevonden bericht uit.
Sla uw werkstroom op als u gereed bent. Selecteer in de werkbalk van de ontwerper Opslaan.
Stap 3: optie 2: een Service Bus-actie toevoegen
In de volgende stappen wordt Azure Portal gebruikt, maar met de juiste Azure Logic Apps-extensie kunt u ook de volgende hulpprogramma's gebruiken om werkstromen voor logische apps te maken:
Werkstromen voor logische apps voor verbruik: Visual Studio of Visual Studio Code
Standaardwerkstromen voor logische apps: Visual Studio Code
Open in Azure Portal uw logische app voor verbruik en werkstroom in de ontwerpfunctie.
Volg deze algemene stappen in de ontwerpfunctie om de gewenste Azure Service Bus-actie toe te voegen.
In dit voorbeeld wordt de actie Bericht verzenden voortgezet.
Als u hierom wordt gevraagd, geeft u de volgende informatie op voor uw verbinding. Selecteer Maken als u klaar bent.
Eigenschappen Vereist Beschrijving Verbindingsnaam Ja Een naam voor uw verbinding Verificatietype Ja Het type verificatie dat moet worden gebruikt voor toegang tot uw Service Bus-naamruimte. Raadpleeg de verificatie van beheerde connectors voor meer informatie. Verbindingsreeks Ja De verbindingsreeks die u eerder hebt gekopieerd en opgeslagen. Deze verbinding maakt bijvoorbeeld gebruik van toegangssleutelverificatie en biedt de verbindingsreeks voor een Service Bus-naamruimte:
Nadat het actie-informatievak wordt weergegeven, geeft u de benodigde informatie op, bijvoorbeeld:
Eigenschappen Vereist Beschrijving Wachtrij-/onderwerpnaam Ja De geselecteerde wachtrij- of onderwerpbestemming voor het verzenden van het bericht Sessie-id Nee De sessie-id als het bericht wordt verzonden naar een sessiebewuste wachtrij of onderwerp Systeemeigenschappen Nee - Geen
- Details van uitvoering: Voeg informatie over metagegevenseigenschap toe over de uitvoering als aangepaste eigenschappen in het bericht.
Als u andere beschikbare eigenschappen aan de actie wilt toevoegen, opent u de lijst nieuwe parameters toevoegen en selecteert u de gewenste eigenschappen.
Voeg eventuele andere acties toe die uw werkstroom nodig heeft.
U kunt bijvoorbeeld een actie toevoegen waarmee e-mail wordt verzonden om te bevestigen dat uw bericht is verzonden.
Sla uw werkstroom op als u gereed bent. Selecteer in de werkbalk van de ontwerper Opslaan.
App-instellingen voor ingebouwde Service Bus-connector
In een standaardresource voor logische apps bevat de ingebouwde Service Bus-connector app-instellingen waarmee verschillende drempelwaarden worden beheerd, zoals time-out voor het verzenden van berichten en het aantal afzenders van berichten per processorkern in de berichtengroep. Raadpleeg Referentie voor app-instellingen - local.settings.json voor meer informatie.
Berichten lezen uit wachtrijen met dead-letter met ingebouwde Service Bus-triggers
Als u in standaardwerkstromen een bericht wilt lezen uit een wachtrij met dode letters in een wachtrij of een onderwerpabonnement, volgt u deze stappen met behulp van de opgegeven triggers:
Voeg in uw lege werkstroom, op basis van uw scenario, de ingebouwde Service Bus-connectortrigger toe met de naam Wanneer berichten beschikbaar zijn in een wachtrij of wanneer een bericht beschikbaar is in een onderwerpabonnement (peek-lock).
Stel in de trigger de volgende parameterwaarden in om de standaard wachtrij of wachtrij voor het onderwerpabonnement op te geven, waartoe u net als elke andere wachtrij toegang hebt:
Wanneer berichten beschikbaar zijn in een wachtrijtrigger : stel de parameter Wachtrijnaam in op queuename/$deadletterqueue.
Wanneer een bericht beschikbaar is in een onderwerpabonnement (peek-lock): stel de parameter Onderwerpnaam in op topicname/Subscriptions/subscriptionname/$deadletterqueue.
Zie het overzicht van wachtrijen met dead-letter van Service Bus voor meer informatie.
Probleemoplossing
Vertragingen in updates van uw werkstroom die van kracht worden
Als het polling-interval van een Service Bus-trigger klein is, zoals 10 seconden, worden updates van uw werkstroom mogelijk maximaal 10 minuten doorgevoerd. U kunt dit probleem omzeilen door de resource van de logische app uit te schakelen, de wijzigingen aan te brengen en vervolgens de resource van de logische app opnieuw in te schakelen.
Er is geen sessie beschikbaar of kan worden vergrendeld door een andere ontvanger
Soms produceren bewerkingen zoals het voltooien van een bericht of het vernieuwen van een sessie de volgende fout:
{
"status": 400,
"error": {
"message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'."
}
}
Af en toe kan een trigger op basis van een sessie mislukken met de volgende fout:
{
"status": 400,
"error": {
"message": "Communication with the Service Bus namespace 'xxxx' and 'yyyy' entity failed. The requested session 'zzzz' cannot be accepted. It may be locked by another receiver."
}
}
De Service Bus-connector maakt gebruik van cache in het geheugen om alle bewerkingen te ondersteunen die zijn gekoppeld aan de sessies. De Service Bus-berichtontvanger wordt in de cache opgeslagen in het geheugen van het rolexemplaren (virtuele machine) dat de berichten ontvangt. Als u alle aanvragen wilt verwerken, worden alle aanroepen voor de verbinding doorgestuurd naar hetzelfde rolexemplaren. Dit gedrag is vereist omdat voor alle Service Bus-bewerkingen in een sessie dezelfde ontvanger is vereist die de berichten voor een specifieke sessie ontvangt.
Vanwege redenen zoals een infrastructuurupdate, connectorimplementatie, enzovoort, bestaat de mogelijkheid dat aanvragen niet naar hetzelfde rolexemplaren worden gerouteerd. Als deze gebeurtenis plaatsvindt, mislukken aanvragen om een van de volgende redenen:
De ontvanger die de bewerkingen in de sessie uitvoert, is niet beschikbaar in het rolexemplaren dat de aanvraag dient.
Het nieuwe rolexemplaren proberen de sessie te verkrijgen, die een time-out heeft opgetreden in het oude rolexemplaren of niet is gesloten.
Zolang deze fout slechts af en toe optreedt, wordt de fout verwacht. Wanneer de fout optreedt, blijft het bericht behouden in de servicebus. De volgende trigger of werkstroomuitvoering probeert het bericht opnieuw te verwerken.