Die Standard-Variante wird auf der Azure Function Runtime gehostet, somit werden die Workflows performanter (abhängig vom App Service Plan). Zudem ist es möglich mehrere Workflows in einer Standard Logic App zu haben, sodass man die Standard Logic Apps auch als Container betrachten kann.
Bei den Workflows unterscheidet man zwischen zwei möglichen Typen:
- Stateless Workflow:
‚Stateless‘ Workflows können nur im ‚synchronous pattern‘ arbeiten und geben immer einen 202 ACCEPTED response zurück. Außerdem werden keine Run Histories zur Verfügung gestellt (zum debuggen kann dieser ‚aktiviert‘ werden). Dafür haben die Runs eine schnellere Response Time, schnellere Performance im Vergleich zum Stateless Typ, höheren throughput und geringere Laufzeitkosten, weil die Run Details und die History nicht in einem externen Storage gespeichert werden. Bei Ausfällen muss der Caller (Client) die unterbrochenen Runs manuell resubmitten. Stateless Workflows eignen sich nicht für Laufzeiten, die länger als 5 Minuten benötigen.
- Stateful Workflow:
‚Stateful‘ Workflows können im ,asynchronous pattern’ arbeiten. Per Default hat man hier immer die Run History zur Verfügung und fehlgeschlagene Runs können direkt resubmitted werden. Stateful Workflows eignen sich auch für längere Laufzeiten im Vergleich zu Stateless Workflows.
Auf die Frage „Wie kann ich eine Logic App Standard Lösung in meine Interfaces am besten integrieren?“, haben wir uns zwei unterschiedliche Möglichkeiten überlegt:
- Container Lösung:
In dieser Variante werden Workflows implementiert, die man eigentlich in einer Consumption based Logic App entwickeln könnte, man hat sich aber aus verschiedenen Gründen gegen Consumption entschieden (s. Tabelle: Logic App - Standard vs. Consumption). Hier muss dann ein gutes Naming Convention – Konzept angewendet werden, um nicht den Überblick zu verlieren. Zudem muss man sich überlegen, ab welcher Anzahl an Workflows man eine zweite Container Logic App beginnt.
(Bspws: Logic App Name: logic-<functionalGroup>-<environment>-<index>,
logic-erp-dev-001)
(Bspws: Workflow Name: <interfaceCode>-<description>-<destination>,
sap100-dosomething-tosalesforce)
- Stand Alone Lösung:
Hier wird eine komplette Logic App für ein komplexeres interface genutzt. Bei der man mehr als nur einen Workflow benötigt (parent-child). Man kann unter anderem Prozesse in Workflows ausgliedern, um diese wiederzuverwenden, welches bspw. praktisch ist beim Pushen von Daten. Bei dieser Variante ist ess dann auch wichtig, das Naming zum Container zu unterscheiden.
(Bspw. Logic App Name: logic-<functionalGroup>-<description><Destination>-<environment>, logic-erp-complexprocesstosalesforce-dev)
(Workflow Name: main-workflow: <trigger>-<verb><Description>, sb-dosomething;
sub-workflow: <verb><Description>, processsomething)
Da wir jetzt eine gute Übersicht haben, welche Änderungen und neuen Features es zu den Logic Apps (Standard) gibt und nun eine Vorstellung haben, wie man diese neue Ressource nutzen kann, kommen wir zum direkten Vergleich von Standard zu Consumption - Logic Apps.
Ich hoffe mit diesem Artikel euch einen guten Überblick zum Thema Logic App (Standard) verschafft haben zu können, sowie den direkten Vergleich zu den Consumption Logic Apps.In meinem nächsten Artikel werde ich euch zeigen, wie man am besten eine Logic App (Standard) in einer yaml ci/cd pipeline mit einem service bus trigger (api-connection) automatisiert und deployed.
Viele Grüße aus Stuttgart,
Armin.
https://docs.microsoft.com/en-us/azure/logic-apps/single-tenant-overview-compare
