CONNECTED Conference 2023 - Aufzeichnungen jetzt hier verfügbar +++                     

Suche

über alle News und Events

 

Alle News

 

Für Entwickler, Architekten, Projektleiter und...

Read more

In der Welt der Softwareentwicklung ist die...

Read more

QUIBIQ spendet für den guten Zweck – und für...

Read more

Eine bestimmte Antwort auf einen HTTP Request zu...

Read more

In einer Welt, die von stetigem Wandel geprägt...

Read more

In einem unserer Kundenprojekte, war das Ziel eine...

Read more

QUIBIQ Hamburg wird mit dem Hamburger...

Read more

Zwei Tage lang wurde vom 14.-15.11 wieder das...

Read more

Was ist ein Excel-Plugin – und wann ist es...

Read more

Wir expandieren, bringen Kunden und Talente besser...

Read more

How-to: Logic App Standard - ServiceBus: Ein Vergleich zwischen Managed und Built-In

Azure bietet in Workflows auf einer LogicApp Standard zwei unterschiedliche Kategorien an Connectoren an: Built-In und Azure. Kategorieübergreifend lassen sich dadurch zahlreiche Systeme anbinden und innerhalb eines Workflows nutzen. Einige Systeme – insbesondere Azure-Komponenten – kommen dabei in beiden Kategorien vor und haben spezifische Vor- und Nachteile. Dieser Artikel gibt einen Überblick über die beiden Service Bus Connectoren in LogicApp Standard.

Überblick Service Bus Built-in

Der Built-in Service Bus Connector ist in vielen Fällen die erste Wahl in einem Standard-LogicApp Workflow, da dieser in den meisten Fällen höhere Leistung bei geringeren Kosten mit sich bringt. Innerhalb einer Standard LogicApp fallen keine Mehrkosten bei Built-in Connectoren an (siehe hier).

Folgende Tabelle gibt uns einen Überblick über Trigger und Actions in diesem Zusammenhang:

Die kursiv und blau hinterlegten Einträge in der Tabelle 1 stehen nur innerhalb eines Stateless Workflows zur Verfügung. Im üblichen Stateful Workflow stehen uns lediglich Basisfunktionalitäten zur Verfügung. Dazu später mehr im Vergleich zwischen Built-In und Azure. 

Mit diesem Toolset lassen sich bereits die meisten weniger komplexen Integrationslösungen mit LogicApp Workflows umsetzen. Nicht möglich mit einem Stateful Workflow in Verbindung mit dem Built-in Connector sind u.a. folgende Konzepte:

  • Peek-Lock Verarbeitung
  • Automatisiertes Retrying mit Verwendung der Dead-Letter-Queue

Beide Konzepte lassen sich jedoch mit einem Stateless-Workflow, mit dem Nachteil der fehlenden Run-History, umsetzen. Weitere Details finden sich hier.

Unglücklicherweise ist es momentan in Azure nicht möglich einen Stateless Workflow mit der Standardeigenschaft splitOn über den Built-in Connector zu triggern. Dieses Setting wird vom Designer automatisch auf den Body der ServiceBus-Inputs gesetzt und muss händisch in der Code-View entfernt werden. Dadurch ist es nicht mehr möglich Einzelnachrichten zu verarbeiten. Stattdessen muss die Verarbeitung eines Arrays hier eingeplant werden.

Überblick ServiceBus Azure

In der Kategorie Azure findet sich der sogenannte Managed Connector für den ServiceBus. Managed Connectoren laufen separat von unserer Maschine in Azure. Zur erkennen sind diese später anhand ihrer Einträge unter den API Connections (bzw. Block managedApiConnections in der connections.json). Neben den Triggern und Actions in Tabelle 1 gibt es hiermit zusätzlich noch die Möglichkeit Nachrichten zu verzögern (defer Message).

Abgerechnet wird der Managed Connector per API-Call. Wichtig dabei ist, dass jede Kommunikation zwischen LogicApp und ServiceBus als API-Call gerechnet wird, unabhängig davon, ob neue Nachrichten vorliegen, oder nicht. Mit dem Standardintervall von 15s kommen wir so pro Workflow bereits auf 5760 Calls pro Tag. Dies sollte im Architekturdesign in der Kostenplanung berücksichtigt werden.

Mithilfe des Managed Connectors stehen uns im Stateful Workflow alle Vorteile der Peek-Lock Verarbeitung zur Verfügung, sodass beispielsweise automatisch Nachrichten im Fehlerfall in die erneute Verarbeitung kommen, bzw. über die Dead-Letter-Queue in die Ausnahmebehandlung wandern können. Dadurch sind robustere und schlankere Workflows möglich.

Bei Verwendung des Managed Connectors sinkt die Anzahl der pro Sekunde abrufbaren Nachrichten erheblich im Vergleich zum Built-In Connector, da hier kein Look-ahead auf die Queue stattfindet. Der Connector prüft dabei nicht ab, wie viele Nachrichten auf dem ServiceBus noch warten. Dadurch kann es zu keiner automatischen Skalierung in der LogicApp kommen und die Verarbeitungsgeschwindigkeit ist relativ niedrig.

​​​​​​​Gegenüberstellung ServiceBus Built-in und Azure

Vergleicht man den Standardconnector mit dem Managed Connector, so ist abhängig vom Szenario mal der eine, mal der andere Connector überlegen.

Der Standard-Connector in einem Stateful Workflow ist prädestiniert, wenn ein automatischer Retry von fehlgeschlagenen Runs nicht vorgesehen ist, bzw. an neuralgischen Punkten innerhalb eines Runs eine robuste Ausnahmebehandlung implementiert ist, da uns hier kein Peek-Lock Verfahren angeboten wird.

Der Standard-Connector in einem Stateless Workflow eignet sich aufgrund der Möglichkeit auf Peek-Lock zurückgreifen zu können sehr für die Massenverarbeitung von Datensätzen. Bei der Implementierung muss jedoch berücksichtigt werden, dass es nicht möglich ist je Message einen separaten Run zu starten, sondern bis zu 1000 Nachrichten in einem Array gebündelt werden. Hinzu kommt noch das Fehlen der Run-History, so dass diese Lösung eher im Ausnahmefall zu empfehlen ist.

​​​​​​​Eigene Ausnahmebehandlung

Da zum heutigen Zeitpunkt noch keine Peek-Lock-Verarbeitung mit dem Standard-Connector innerhalb eines Stateful Workflow möglich ist, bietet es sich an, das Verhalten selbst zu implementieren. Mithilfe der User-Properties wäre es jedoch möglich, einen eigenen Delivery-Count einer Nachricht mitzuschleifen und diese Information für ein manuelles Retrying zu verwenden. Ein abschließendes ablegen der Nachricht auf der Dead-Letter-Queue ist mit dem Built-In Connector jedoch nicht möglich.

Aufgrund der Einschränkungen im Built-In Connector ist dieses Vorgehen jedoch mit Vorsicht zu genießen. Da bis Ende Q3 2023 jedoch ein neuer Release des Built-In Connectors inklusive Peek-Lock Verfahren zu erwarten ist, kann es sich auszahlen, diesen abzuwarten (siehe hier) .

Eine mögliche Implementierung des Workarounds könnte bis dahin folgendermaßen aussehen.

Sobald der Release der nächsten Version des Built-In Connectors erfolgt ist, werde ich zu diesem Thema einen weiteren Artikel einplanen. Dort werden wir uns dann auch ausführlicher den Unterschieden in Laufzeiten, Transaktionssicherheit, Ausnahmebehandlung und Kosten zwischen Managed- und Built-In-Connector widmen.

Danke für diesen quiTeq-Tipp an Adrian, QUIBIQ Stuttgart.

 

Ihre Kontaktmöglichkeiten

Sie haben eine konkrete Frage an uns


 

Bleiben Sie immer auf dem Laufenden


 

Mit meinem "Ja" erkläre ich mich mit der Verarbeitung meiner Daten zur Zusendung von Informationen einverstanden. Ich weiß, dass ich diese Erklärung jederzeit durch einfache Mitteilung widerrufen kann. Bei einem Nein an dieser Stelle erhalte ich zukünftig keine Informationen mehr.

© QUIBIQ GmbH · Impressum · Datenschutz