Senden von korrelierten Nachrichten in der richtigen Reihenfolge mithilfe eines sequenziellen Konvois - Azure Logic Apps

Artikel
01/04/2024

Gilt für: Azure Logic Apps (Verbrauch)

Wenn Sie korrelierte Nachrichten in einer bestimmten Reihenfolge senden müssen, können Sie bei Verwendung von Azure Logic Apps mit dem Azure Service Bus-Connector das Muster für einen sequenziellen Konvoi nutzen. Korrelierte Nachrichten verfügen über eine Eigenschaft zum Definieren der Beziehung zwischen diesen Nachrichten, z. B. die ID für die Sitzung in Service Bus.

Beispiel: Sie verfügen über zehn Nachrichten für die Sitzung „Sitzung 1“ und fünf Nachrichten für die Sitzung „Sitzung 2“, die alle an dieselbe Service Bus-Warteschlange gesendet werden. Sie können eine Logik-App zur Verarbeitung von Nachrichten aus der Warteschlange erstellen, bei der alle Nachrichten aus „Sitzung 1“ von einer einzigen Triggerausführung behandelt und alle Nachrichten von „Sitzung 2“ von der nächsten Triggerausführung behandelt werden.

Allgemeines Muster für einen sequenziellen Konvoi

In diesem Artikel erfahren Sie, wie Sie eine Logik-App erstellen, die dieses Muster unter Verwendung der Vorlage Zustellung korrelierter Nachrichten in der richtigen Reihenfolge mithilfe von Service Bus-Sitzungen implementiert. Mit dieser Vorlage wird ein Logik-App-Workflow definiert, der mit dem Trigger Wenn eine Nachricht in einer Warteschlange empfangen wird (Peek-Lock) des Service Bus-Connectors startet, der Nachrichten aus einer Service Bus-Warteschlange empfängt. In der folgenden Übersicht sind die wichtigsten Schritte aufgeführt, die diese Logik-App ausführt:

Initialisieren einer Sitzung basierend auf einer Nachricht, die der Trigger aus der Service Bus-Warteschlange liest.
Lesen und Verarbeiten aller Nachrichten aus derselben Sitzung in der Warteschlange während der aktuellen Workflowausführung.

Einzelheiten zur JSON-Datei dieser Vorlage finden Sie unter GitHub: service-bus-sessions.json.

Weitere Informationen finden Sie unter Muster für einen sequenziellen Konvoi.

Voraussetzungen

Ein Azure-Abonnement. Falls Sie kein Abonnement besitzen, können Sie sich für ein kostenloses Azure-Konto registrieren.
Ein Service Bus-Namespace und eine Service Bus-Warteschlange (die Messagingentität, die Sie in Ihrer Logik-App verwenden). Diese Elemente und Ihre Logik-App müssen dasselbe Azure-Abonnement verwenden. Stellen Sie sicher, dass Sie beim Erstellen Ihrer Warteschlange die Option Sitzungen aktivieren auswählen. Wenn Sie nicht über diese Elemente verfügen, informieren Sie sich, wie Sie Ihren Service Bus-Namespace und eine Warteschlange erstellen.

Wichtig

Gehen Sie vorsichtig vor, wenn Sie einen Trigger und eine Aktion auswählen, die denselben Connectortyp aufweisen, und damit an derselben Entität arbeiten, z. B. einer Messagingwarteschlange oder einem Themenabonnement. Eine solche Kombination kann eine Endlosschleife bewirken, und Sie erhalten eine nie endende Logik-App.
Grundlegende Kenntnisse zum Erstellen von Logik-Apps. Wenn Sie noch nicht mit Azure Logic Apps vertraut sind, versuchen Sie den Schnellstart, der ein Beispiel für einen Verbrauchs-Logik-App-Workflow in Azure Logic Apps mit mehreren Mandanten erstellt.

Überprüfen des Zugriffs auf den Service Bus-Namespace

Wenn Sie nicht sicher sind, ob Ihre Logik-App über die erforderlichen Berechtigungen für den Zugriff auf Ihren Service Bus-Namespace verfügt, überprüfen Sie diese Berechtigungen.

Melden Sie sich beim Azure-Portal an. Suchen Sie Ihren Service Bus-Namespace, und wählen Sie ihn aus.
Wählen Sie im Menü „Namespace“ unter Einstellungen die Option Freigegebene Zugriffsrichtlinien aus. Stellen Sie im Bereich Ansprüche sicher, dass Sie die Verwaltungsberechtigungen für diesen Namespace besitzen.
Rufen Sie nun die Verbindungszeichenfolge für Ihren Service Bus-Namespace ab. Sie können diese Zeichenfolge später verwenden, wenn Sie aus Ihrer Logik-App eine Verbindung zum Namespace herstellen.
1. Wählen Sie im Bereich Richtlinien für gemeinsamen Zugriff unter Richtlinie den Eintrag RootManageSharedAccessKey aus.
2. Wählen Sie neben der primären Verbindungszeichenfolge die Schaltfläche „Kopieren“ aus. Speichern Sie die Verbindungszeichenfolge für die spätere Verwendung.
Tipp

Um zu überprüfen, ob Ihre Verbindungszeichenfolge mit Ihrem Service Bus-Namespace oder einer Messagingentität (z.B. einer Warteschlange) verknüpft ist, suchen Sie die Verbindungszeichenfolge für den Parameter EntityPath. Wenn Sie diesen Parameter gefunden haben, gilt die Verbindungszeichenfolge für eine bestimmte Entität und stellt nicht die richtige Zeichenfolge für die Verwendung mit Ihrer Logik-App dar.

Erstellen einer Logik-App

In diesem Abschnitt erstellen Sie unter Verwendung der Vorlage Zustellung korrelierter Nachrichten in der richtigen Reihenfolge mithilfe von Service Bus-Sitzungen eine Logik-App, die den Trigger und die Aktionen für die Implementierung dieses Workflowmusters enthält. Darüber hinaus stellen Sie eine Verbindung mit Ihrem Service Bus-Namespace her und geben den Namen für die Service Bus-Warteschlange an, die verwendet werden soll.

Erstellen Sie im Azure-Portal eine leere Logik-App. Wählen Sie auf der Azure-Startseite Ressource erstellen>Integration>Logik-App aus.
Scrollen Sie im Vorlagenkatalog nach unten, und überspringen Sie dabei das Video und die Abschnitte zu gängigen Triggern. Wählen Sie im Abschnitt Vorlagen die Vorlage Zustellung korrelierter Nachrichten in der richtigen Reihenfolge mithilfe von Service Bus-Sitzungen aus.
Wenn das Bestätigungsfeld angezeigt wird, wählen Sie Diese Vorlage verwenden aus.
Wählen Sie im Logik-App-Designer unter Service Bus die Option Weiter und dann das Pluszeichen (+) aus.
Erstellen Sie nun eine Service Bus-Verbindung, indem Sie eine der folgenden Optionen auswählen:
- Zur Verwendung der Verbindungszeichenfolge, die Sie zuvor aus Ihrem Service Bus-Namespace kopiert haben, führen Sie die folgenden Schritte aus:
  1. Wählen Sie Verbindungsinformationen manuell eingeben aus.
  2. Geben Sie in Verbindungsname einen Namen für Ihre Verbindung ein. Fügen Sie in Verbindungszeichenfolge die Verbindungszeichenfolge Ihres Namespace ein, und wählen Sie Erstellen aus. Beispiel:
    
    Tipp
    
    Wenn Sie nicht über diese Verbindungszeichenfolge verfügen, finden Sie unter Ermitteln und Kopieren der Verbindungszeichenfolge für Ihren Service Bus-Namespace Informationen dazu, wo Sie sie finden.
- Zur Auswahl eines Service Bus-Namespace aus Ihrem aktuellen Azure-Abonnement führen Sie folgende Schritte aus:
  1. Geben Sie in Verbindungsname einen Namen für Ihre Verbindung ein. Wählen Sie für Service Bus-Namespace Ihren Service Bus-Namespace aus. Beispiel:
  2. Wählen Sie im nächsten Bereich Ihre Service Bus-Richtlinie und dann Erstellen aus.
Wenn Sie fertig sind, wählen Sie Weiter aus.

Im Logik-App-Designer wird jetzt die Vorlage Zustellung korrelierter Nachrichten in der richtigen Reihenfolge mithilfe von Service Bus-Sitzungen angezeigt, die einen vorab aufgefüllten Workflow mit einem Trigger und Aktionen enthält. U. a. sind zwei Bereiche zur Implementierung der Fehlerbehandlung enthalten, die dem Try-Catch-Muster folgen.

Sie können sich jetzt entweder weiter mit dem Trigger und den Aktionen in der Vorlage vertraut machen oder mit dem Abschnitt zum Angeben der Werte für die Logik-App-Vorlage fortfahren.

Vorlagenzusammenfassung

Nachfolgend finden Sie den allgemeinen Workflow in der Vorlage Zustellung korrelierter Nachrichten in der richtigen Reihenfolge mithilfe von Service Bus-Sitzungen mit reduzierten Details:

Allgemeiner Workflow der Vorlage

Name	BESCHREIBUNG
`When a message is received in a queue (peek-lock)`	Dieser Service Bus-Trigger überprüft basierend auf der festgelegten Wiederholungseinstellung, ob in der angegebenen Service Bus-Warteschlange Nachrichten vorhanden sind. Wenn eine Nachricht in der Warteschlange vorhanden ist, wird der Trigger ausgelöst, sodass eine Workflowinstanz erstellt und ausgeführt wird. Peek-Lock bedeutet, dass der Trigger eine Anforderung zum Abrufen einer Nachricht aus der Warteschlange sendet. Wenn eine Nachricht vorhanden ist, ruft der Trigger die Nachricht ab und sperrt sie, damit keine weitere Verarbeitung für diese Nachricht erfolgt, bis die Sperrfrist abgelaufen ist. Einzelheiten finden Sie unter Initialisieren der Sitzung.
`Init isDone`	Mit dieser Variable initialisieren-Aktion wird eine boolesche Variable erstellt, die auf `false` festgelegt wird und anzeigt, wenn die folgenden Bedingungen erfüllt sind: – In der Sitzung sind keine weiteren Nachrichten verfügbar, die gelesen werden können. – Die Sitzungssperre muss nicht mehr verlängert werden, sodass die aktuelle Workflowinstanz abgeschlossen werden kann. Einzelheiten finden Sie unter Initialisieren der Sitzung.
`Try`	Diese Bereich-Aktion beinhaltet die Aktionen, die zum Verarbeiten einer Nachricht ausgeführt werden. Wenn im Bereich `Try` ein Problem auftritt, wird dieses Problem von der nachfolgenden `Catch`Bereich-Aktion behandelt. Weitere Informationen finden Sie unter Der Bereich „Try“.
`Catch`	Diese Bereich-Aktion umfasst die Aktionen, die bei einem Problem im vorangehenden `Try`-Bereich ausgeführt werden. Weitere Informationen finden Sie unter Der Bereich „Catch“.

Der Bereich „Try“

Nachfolgend ist der allgemeine Flow in der Try-Bereichsaktion mit reduzierten Details beschrieben:

Der Workflow der Bereichsaktion „Try“

Name	BESCHREIBUNG
`Send initial message to topic`	Sie können diese Aktion durch eine beliebige Aktion ersetzen, die die erste Nachricht aus der Sitzung in der Warteschlange behandeln soll. Die Sitzungs-ID gibt die Sitzung an. Bei dieser Vorlage sendet eine Service Bus-Aktion die erste Nachricht an ein Service Bus-Thema. Einzelheiten finden Sie unter Behandeln der ersten Nachricht.
(parallele Verzweigung)	Mit dieser Aktion für eine parallele Verzweigung werden zwei Pfade erstellt: – Branch 1: Verarbeitung der Nachricht fortsetzen. Weitere Informationen finden Sie unter Branch 1: Erste Nachricht in der Warteschlange abschließen. – Branch 2: Nachricht verwerfen, wenn ein Problem auftritt, und zur Aufnahme durch eine andere Triggerausführung freigeben. Weitere Informationen finden Sie unter Branch 2: Erste Nachricht aus Warteschlange verwerfen. Die beiden Pfade werden später in der Aktion Sitzung in einer Warteschlange schließen, erfolgreicher Vorgang zusammengeführt, die in der nächsten Zeile beschrieben wird.
`Close a session in a queue and succeed`	Mit dieser Service Bus-Aktion werden die zuvor beschriebenen Verzweigungen zusammengeführt, und die Sitzung in der Warteschlange wird geschlossen, nachdem eins der folgenden Ereignisse eintritt: – Der Workflow schließt die Verarbeitung verfügbarer Nachrichten in der Warteschlange ab. – Der Workflow verwirft die erste Nachricht, weil ein Fehler aufgetreten ist. Weitere Informationen finden Sie unter Sitzung in einer Warteschlange schließen, erfolgreicher Vorgang.

Branch 1: Erste Nachricht in der Warteschlange abschließen

Name	BESCHREIBUNG
`Complete initial message in queue`	Diese Service Bus-Aktion markiert eine erfolgreich abgerufene Nachricht als abgeschlossen und entfernt die Nachricht aus der Warteschlange, um eine erneute Verarbeitung zu verhindern. Einzelheiten finden Sie unter Behandeln der ersten Nachricht.
`While there are more messages for the session in the queue`	Diese Until-Schleife ruft weiter Nachrichten ab, solange Nachrichten vorhanden sind oder bis eine Stunde vergangen ist. Weitere Informationen zu den Aktionen in dieser Schleife finden Sie unter Wenn weitere Nachrichten für die Sitzung in der Warteschlange vorhanden sind.
`Set isDone = true`	Wenn keine weiteren Nachrichten vorhanden sind, setzt diese Variable festlegen-Aktion`isDone` auf `true`.
`Renew session lock until cancelled`	Mit dieser Until-Schleife wird sichergestellt, dass die Sitzungssperre von dieser Logik-App beibehalten wird, solange Nachrichten vorhanden sind oder bis eine Stunde vergangen ist. Weitere Informationen zu den Aktionen in dieser Schleife finden Sie unter Sitzungssperre bis zum Abbruch verlängern.

Branch 2: Erste Nachricht aus Warteschlange verwerfen

Wenn bei der Aktion, die die erste Nachricht behandelt, ein Fehler auftritt, gibt die Service Bus-Aktion Erste Nachricht aus Warteschlange verwerfen die Nachricht für die Aufnahme und Verarbeitung durch eine andere Workflowinstanzausführung frei. Einzelheiten finden Sie unter Behandeln der ersten Nachricht.

Der Bereich „Catch“

Wenn bei Aktionen im Try-Bereich Fehler auftreten, muss die Logik-App die Sitzung dennoch schließen. Die Catch-Bereichsaktion wird ausgeführt, wenn die Try-Bereichsaktion den Status Failed, Skipped oder TimedOut aufweist. Der Bereich gibt eine Fehlermeldung mit der Sitzungs-ID zurück, bei der das Problem aufgetreten ist, und beendet die Logik-App.

Nachfolgend ist der allgemeine Flow in der Catch-Bereichsaktion mit reduzierten Details beschrieben:

Der Workflow der Bereichsaktion „Catch“

Name	BESCHREIBUNG
`Close a session in a queue and fail`	Diese Service Bus-Aktion schließt die Sitzung in der Warteschlange, sodass die Sitzungssperre nicht erhalten bleibt. Weitere Informationen finden Sie unter Sitzung in einer Warteschlange schließen, Vorgang mit Fehler.
`Find failure msg from 'Try' block`	Mit dieser Array filtern-Aktion wird ein Array aus den Ein- und Ausgaben aller Aktionen innerhalb des `Try`-Bereichs basierend auf den angegebenen Kriterien erstellt. In diesem Fall gibt die Aktion die Ausgaben der Aktionen zurück, die den Status `Failed` aufweisen. Einzelheiten finden Sie unter Fehlermeldung im „Try“-Block finden.
`Select error details`	Mit dieser Auswahl-Aktion wird ein Array mit JSON-Objekten basierend auf den angegebenen Kriterien erstellt. Diese JSON-Objekte werden anhand der Werte des Arrays erstellt, das von der vorherigen Aktion (`Find failure msg from 'Try' block`) erstellt wurde. In diesem Fall gibt diese Aktion ein Array mit einem JSON-Objekt zurück, das anhand der Fehlerdetails erstellt wurde, die von der vorherigen Aktion zurückgegeben wurden. Weitere Informationen finden Sie unter Auswahl der Fehlerdetails.
`Terminate`	Mit dieser Beenden-Aktion wird die Ausführung für den Workflow beendet, alle aktiven Aktionen werden abgebrochen, und alle verbleibenden Aktionen werden übersprungen. Außerdem werden der angegebene Status, die Sitzungs-ID und das Fehlerergebnis der `Select error details`-Aktion zurückgegeben. Einzelheiten finden Sie unter Logik-App-Ausführung beenden.

Abschließen der Vorlage

Führen Sie die folgenden Schritte aus, um die Werte für den Trigger und die Aktionen in der Vorlage Zustellung korrelierter Nachrichten in der richtigen Reihenfolge mithilfe von Service Bus-Sitzungen anzugeben. Bevor Sie Ihre Logik-App speichern können, müssen Sie alle erforderlichen Werte angeben. Diese sind mit einem Sternchen ( * ) gekennzeichnet.

Initialisieren der Sitzung

Geben Sie diese Informationen für den Trigger Wenn eine Nachricht in einer Warteschlange empfangen wird (Peek-Lock) an, damit die Vorlage eine Sitzung unter Verwendung der Eigenschaft Sitzungs-ID initialisieren kann. Beispiel:

Service Bus-Triggerdetails für „Wenn eine Nachricht in einer Warteschlange empfangen wird (Peek-Lock)“

Hinweis

Das Abrufintervall ist anfänglich auf drei Minuten festgelegt, damit die Logik-App nicht häufiger ausgeführt wird als erwartet und keine unerwarteten Kosten entstehen. Idealerweise legen Sie für Intervall und Häufigkeit 30 Sekunden fest, damit die Logik-App umgehend ausgelöst wird, wenn eine Nachricht eingeht.

Eigenschaft	Für dieses Szenario erforderlich	Wert	BESCHREIBUNG
Warteschlangenname	Ja	<Warteschlangenname>	Der Name Ihrer zuvor erstellten Service Bus-Warteschlange. In diesem Beispiel wird „Fabrikam-Service-Bus-Queue“ verwendet.
Warteschlangentyp	Ja	Hauptseite	Ihre primäre Service Bus-Warteschlange
Sitzungs-ID	Ja	Nächste verfügbare	Mit dieser Option wird eine Sitzung für jede Triggerausführung abgerufen, die auf der Sitzungs-ID aus der Nachricht in der Service Bus-Warteschlange basiert. Die Sitzung wird zudem gesperrt, damit keine andere Logik-App und kein anderer Client Nachrichten verarbeiten kann, die mit dieser Sitzung zusammenhängen. Die nachfolgenden Aktionen des Workflows verarbeiten alle Nachrichten, die mit dieser Sitzung zusammenhängen. Dies wird weiter unten in diesem Artikel näher erläutert. Im Folgenden finden Sie weitere Informationen zu den übrigen Optionen von Sitzungs-ID: - Keine: Die Standardoption, bei der keine Sitzungen verwendet werden. Diese Option kann nicht verwendet werden, wenn das Muster für einen sequenziellen Konvoi implementiert werden soll. - Benutzerdefinierten Wert eingeben: Verwenden Sie diese Option, wenn Sie die Sitzungs-ID kennen, die Sie verwenden möchten, und Sie den Trigger immer für diese Sitzungs-ID ausführen möchten. Hinweis: Der Service Bus-Connector kann eine beschränkte Anzahl von eindeutigen Sitzungen von Azure Service Bus im Connectorcache speichern. Wenn die Anzahl der Sitzungen dieses Limit überschreitet, werden alte Sitzungen aus dem Cache entfernt. Weitere Informationen finden Sie unter Austauschen von Nachrichten in der Cloud mit Azure Logic Apps und Azure Service Bus.
Intervall	Ja	<Anzahl von Intervallen>	Die Anzahl von Zeiteinheiten zwischen Wiederholungen, bevor überprüft wird, ob eine Nachricht vorhanden ist.
Frequency	Ja	Sekunde, Minute, Stunde, Tag, Woche oder Monat	Die Zeiteinheit für die Wiederholung, wenn überprüft wird, ob eine Nachricht vorhanden ist. Tipp: Zum Hinzufügen einer Zeitzone oder einer Startzeit wählen Sie diese Eigenschaften aus der Liste Neuen Parameter hinzufügen aus.

Weitere Informationen zu Triggern finden Sie unter Service Bus – Wenn eine Nachricht in einer Warteschlange empfangen wird (Peek-Lock). Der Trigger gibt eine Service Bus-Nachricht aus.

Nach der Initialisierung der Sitzung verwendet der Workflow die Variable initialisieren-Aktion, um eine boolesche Variable zu erstellen, die anfänglich auf false festgelegt ist und anzeigt, wenn die folgenden Bedingungen erfüllt sind:

In der Sitzung sind keine weiteren Nachrichten verfügbar, die gelesen werden können.
Die Sitzungssperre muss nicht mehr verlängert werden, sodass die aktuelle Workflowinstanz abgeschlossen werden kann.

Details der „Variable initialisieren“-Aktion für „Init isDone“

Anschließend führt der Workflow im Try-Block Aktionen für die erste Nachricht aus, die gelesen wird.

Behandeln der ersten Nachricht

Die erste Aktion ist eine Service Bus-Platzhalteraktion (Erste Nachricht an Thema senden), die durch eine beliebige Aktion ersetzt werden kann, die Sie als erste Nachricht aus der Sitzung in der Warteschlange behandeln möchten. Die Sitzungs-ID gibt die Sitzung an, aus der die Nachricht stammt.

Die Service Bus-Platzhalteraktion sendet die erste Nachricht an ein Service Bus-Thema, das in der Eigenschaft Sitzungs-ID angegeben ist. Auf diese Weise werden alle Nachrichten, die einer bestimmten Sitzung zugeordnet sind, an dasselbe Thema weitergeleitet. Alle Sitzungs-ID-Eigenschaften für nachfolgende Aktionen in dieser Vorlage verwenden denselben Sitzungs-ID-Wert.

Details der Service Bus-Aktion für „Erste Nachricht an Thema senden“

Geben Sie in der Service Bus-Aktion Erste Nachricht in der Warteschlange abschließen den Namen Ihrer Service Bus-Warteschlange an, und übernehmen Sie alle weiteren Standardeigenschaftswerte in der Aktion.
Geben Sie in der Service Bus-Aktion Erste Nachricht aus Warteschlange verwerfen den Namen Ihrer Service Bus-Warteschlange an, und übernehmen Sie alle weiteren Standardeigenschaftswerte in der Aktion.

Im nächsten Schritt geben Sie die erforderlichen Informationen für die Aktionen an, die nach der Aktion Erste Nachricht in der Warteschlange abschließen ausgeführt werden. Sie beginnen mit den Aktionen in der Schleife Wenn weitere Nachrichten für die Sitzung in der Warteschlange vorhanden sind.

Wenn weitere Nachrichten für die Sitzung in der Warteschlange vorhanden sind

Diese Until-Schleife führt diese Aktionen aus, solange Nachrichten in der Warteschlange vorhanden sind bzw. bis eine Stunde vergangen ist. Um das Zeitlimit der Schleife zu ändern, bearbeiten Sie den Eigenschaftswert Timeout der Schleife.

Abrufen weiterer Nachrichten aus der Warteschlange, solange Nachrichten vorhanden sind.
Überprüfen der Anzahl von verbleibenden Nachrichten. Wenn noch Nachrichten vorhanden sind, wird die Verarbeitung fortgesetzt. Wenn keine weiteren Nachrichten vorhanden sind, legt der Workflow die isDone-Variable auf truefest und beendet die Schleife.

Until-Schleife – Verarbeiten von Nachrichten in der Warteschlange

Geben Sie in der Service Bus-Aktion Weitere Nachrichten aus Sitzung abrufen den Namen Ihrer Service Bus-Warteschlange an. Übernehmen Sie alle anderen Standardeigenschaftswerte in der Aktion.

Hinweis

Die maximale Anzahl von Nachrichten ist standardmäßig auf 175 festgelegt. Dieses Limit wird jedoch durch die Nachrichtengröße und durch die Eigenschaft für die maximale Nachrichtengröße in Service Bus beeinflusst. Weitere Informationen finden Sie unter Nachrichtengröße für eine Warteschlange.

Im nächsten Schritt wird der Workflow in diese beiden parallelen Verzweigungen unterteilt:
- Wenn beim Überprüfen auf weitere Nachrichten ein Fehler auftritt, legen Sie die isDone-Variable auf true fest.
- Mit der Bedingung Nachrichten verarbeiten, falls vorhanden wird überprüft, ob die Anzahl von verbleibenden Nachrichten Null beträgt. Wenn der Wert „false“ lautet und weitere Nachrichten vorhanden sind, wird die Verarbeitung fortgesetzt. Wenn das Ergebnis „true“ lautet und keine weiteren Nachrichten vorhanden sind, legt der Workflow die isDone-Variable auf true fest.
Im Abschnitt Wenn FALSE verarbeitet eine For each-Schleife die einzelnen Nachrichten in der FIFO-Reihenfolge (First-In, First-Out). In den Einstellungen der Schleife ist die Einstellung Parallelitätssteuerung auf 1 festgelegt, damit jeweils nur eine einzelne Nachricht verarbeitet wird.
Geben Sie für die Service Bus-Aktionen Nachricht in einer Warteschlange abschließen und Nachricht in einer Warteschlange verwerfen den Namen Ihrer Service Bus-Warteschlange an.

Wenn die Schleife Wenn weitere Nachrichten für die Sitzung in der Warteschlange vorhanden sind abgeschlossen wurde, setzt der Workflow die isDone-Variable auf true.

Nun geben Sie die erforderlichen Informationen für die Aktionen in der Schleife Sitzungssperre bis zum Abbruch verlängern an.

Sitzungssperre bis zum Abbruch verlängern

Mit dieser Until-Schleife wird sichergestellt, dass die Sitzungssperre von dieser Logik-App beibehalten wird, solange Nachrichten in der Warteschlange vorhanden sind oder bis diese Aktionen für eine Stunde ausgeführt wurden. Um das Zeitlimit der Schleife zu ändern, bearbeiten Sie den Eigenschaftswert Timeout der Schleife.

Verzögerung von 25 Sekunden oder eine Zeitdauer, die geringer ist als die Timeoutdauer der Sperre für die Warteschlange, die verarbeitet wird. Die kürzeste Sperrdauer beträgt 30 Sekunden, der Standardwert ist also ausreichend. Sie können die Anzahl von Schleifenausführungen jedoch optimieren, indem Sie diesen Wert entsprechend anpassen.
Überprüfen Sie, ob die isDone-Variable auf true festgelegt ist.
- Wenn isDone auf true festgelegt ist, verarbeitet der Workflow weiterhin Nachrichten und verlängert auf diese Weise die Sperre der Sitzung in der Warteschlange und überprüft die Schleifenbedingung erneut.
  
  Sie müssen den Namen Ihrer Service Bus-Warteschlange in der Service Bus-Aktion Sperre für die Sitzung in einer Warteschlange verlängern angeben.
- Wenn isDone auf true festgelegt ist, verlängert der Workflow die Sperre für die Sitzung in der Warteschlange nicht, und die Schleife wird beendet.

Sperre für die Sitzung in einer Warteschlange verlängern

Mit dieser Service Bus-Aktion wird die Sperre für die Sitzung in der Warteschlange verlängert, solange der Workflow Nachrichten verarbeitet.

Geben Sie in der Service Bus-Aktion Sperre für die Sitzung in einer Warteschlange verlängern den Namen Ihrer Service Bus-Warteschlange an.

Nun geben Sie die erforderlichen Informationen für die Service Bus-Aktion Sitzung in einer Warteschlange schließen, erfolgreicher Vorgang an.

Sitzung in einer Warteschlange schließen, erfolgreicher Vorgang

Diese Service Bus-Aktion schließt die Sitzung in der Warteschlange, nachdem der Workflow die Verarbeitung aller verfügbaren Nachrichten in der Warteschlange abgeschlossen hat oder der Workflow die erste Nachricht verwirft.

Geben Sie in der Service Bus-Aktion Sitzung in einer Warteschlange schließen, erfolgreicher Vorgang den Namen Ihrer Service Bus-Warteschlange an.

In den folgenden Abschnitten werden die Aktionen im Bereich Catch beschrieben, die Fehler und Ausnahmen im Workflow behandeln.

Sitzung in einer Warteschlange schließen, Vorgang mit Fehler

Diese Service Bus-Aktion wird immer als erste Aktion im Catch-Bereich ausgeführt und schließt die Sitzung in der Warteschlange.

Geben Sie in der Service Bus-Aktion Sitzung in einer Warteschlange schließen, Vorgang mit Fehler den Namen Ihrer Service Bus-Warteschlange an.

Als Nächstes erstellt der Workflow ein Array, das die Eingaben und Ausgaben aller Aktionen im Try-Bereich umfasst. Anhand dieser Daten kann die Logik-App auf Informationen zum Fehler zugreifen.

Fehlermeldung im „Try“-Block finden

Mit dieser Array filtern-Aktion wird ein Array aus den Ein- und Ausgaben aller Aktionen innerhalb des Try-Bereichs basierend auf den angegebenen Kriterien erstellt. Dazu wird die result()-Funktion verwendet. In diesem Fall gibt diese Aktion die Ausgaben der Aktionen mit dem Status Failed zurück. Zu diesem Zweck werden die equals()-Funktion und die item()-Funktion verwendet.

„Array filtern“-Aktion „Fehlermeldung im ‚Try‘-Block finden“

Nachfolgend ist die JSON-Definition für diese Aktion gezeigt:

"Find_failure_msg_from_'Try'_block": {
   "inputs": {
      "from": "@Result('Try')",
      "where": "@equals(item()['status'], 'Failed')"
   },
   "runAfter": {
      "Close_the_session_in_the_queue_and_fail": [
         "Succeeded"
      ]
   },
   "type": "Query"
},

Im nächsten Schritt erstellt der Workflow ein Array mit einem JSON-Objekt, das die Fehlerinformationen im Array enthält, die von der Find failure msg from 'Try' block-Aktion zurückgegebenen wurden.

Auswahl der Fehlerdetails

Mit dieser Auswählen-Aktion wird ein Array mit JSON-Objekten basierend auf dem Eingabearray erstellt, das von der vorherigen Aktion (Find failure msg from 'Try' block) ausgegeben wurde. Das von dieser Aktion zurückgegebene Array enthält lediglich die angegebenen Eigenschaften für die einzelnen Objekte im Array. In diesem Fall enthält das Array den Aktionsnamen und das Fehlerergebnis.

Auswählen-Aktion „Fehlerdetails auswählen“

Nachfolgend ist die JSON-Definition für diese Aktion gezeigt:

"Select_error_details": {
   "inputs": {
      "from": "@body('Find_failure_msg_from_''Try''_block')[0]['outputs']",
      "select": {
         "action": "@item()['name']",
         "errorResult": "@item()"
      }
   },
   "runAfter": {
      "Find_failure_msg_from_'Try'_block": [
         "Succeeded"
      ]
   },
   "type": "Select"
},

Im nächsten Schritt hält der Workflow die Ausführung der Logik-App an und gibt ihren Status sowie weitere Informationen zum aufgetretenen Fehler zurück.

Logik-App-Ausführung beenden

Mit dieser Beenden-Aktion wird die Ausführung der Logik-App angehalten und Failed als Status der Ausführung zurückgegeben. Außerdem werden die Sitzungs-ID und das Fehlerergebnis der Select error details-Aktion zurückgegeben.

Beenden-Aktion zum Anhalten der Logik-App-Ausführung

Nachfolgend ist die JSON-Definition für diese Aktion gezeigt:

"Terminate": {
   "description": "This Failure Termination only runs if the Close Session upon Failure action runs - otherwise the LA will be terminated as Success",
   "inputs": {
      "runError": {
         "code": "",
         "message": "There was an error processing messages for Session ID @{triggerBody()?['SessionId']}. The following error(s) occurred: @{body('Select_error_details')['errorResult']}"
         },
         "runStatus": "Failed"
      },
      "runAfter": {
         "Select_error_details": [
            "Succeeded"
         ]
      },
      "type": "Terminate"
   }
},

Speichern und Ausführen der Logik-App

Nachdem Sie die Vorlage fertig gestellt haben, können Sie Ihre Logik-App speichern. Wählen Sie auf der Symbolleiste des Designers Speichern aus.

Senden Sie Nachrichten an Ihre Service Bus-Warteschlange, um Ihre Logik-App zu testen.

Nächste Schritte

Weitere Informationen zu den Triggern und Aktionen des Service Bus-Connectors

Verwenden Sie einen sequenziellen Konvoi in Azure Logic Apps mit Azure Service Bus, um verwandte Nachrichten in der richtigen Reihenfolge zu senden

Voraussetzungen

Überprüfen des Zugriffs auf den Service Bus-Namespace

Erstellen einer Logik-App

Vorlagenzusammenfassung

Der Bereich „Try“

Branch 1: Erste Nachricht in der Warteschlange abschließen

Branch 2: Erste Nachricht aus Warteschlange verwerfen

Der Bereich „Catch“

Abschließen der Vorlage

Initialisieren der Sitzung

Behandeln der ersten Nachricht

Wenn weitere Nachrichten für die Sitzung in der Warteschlange vorhanden sind

Sitzungssperre bis zum Abbruch verlängern

Sperre für die Sitzung in einer Warteschlange verlängern

Sitzung in einer Warteschlange schließen, erfolgreicher Vorgang

Sitzung in einer Warteschlange schließen, Vorgang mit Fehler

Fehlermeldung im „Try“-Block finden

Auswahl der Fehlerdetails

Logik-App-Ausführung beenden

Speichern und Ausführen der Logik-App

Nächste Schritte

Zusätzliche Ressourcen