Migrieren von BizTalk Server zu Azure Logic Apps?

Dieses Handbuch enthält eine Übersicht über die Gründe und Vorteile, Funktionen und andere Informationen, die Ihnen bei der Migration von BizTalk Server zu Azure Logic Apps helfen. Im Anschluss an diesen Leitfaden finden Sie weitere Leitfäden, die Migrationsstrategien, Planungsüberlegungen und bewährte Methoden abdecken, die Ihnen helfen, erfolgreiche Ergebnisse zu erzielen.

Gründe und Vorteile

Durch die Migration Ihrer Integrationsworkloads zu Azure Logic Apps können Sie die folgenden Hauptvorteile nutzen:

Wie funktioniert BizTalk Server?

BizTalk Server verwendet eine Messaging-Engine-Architektur zum Veröffentlichen und Abonnieren mit der MessageBox-Datenbank als Herzstück. MessageBox ist für das Speichern von Nachrichten, Nachrichteneigenschaften, Abonnements, den Orchestrierungsstatus, das Nachverfolgen von Daten und andere Informationen zuständig.

Wenn BizTalk Server eine Nachricht empfängt, übergibt und verarbeitet der Server die Nachricht über eine Pipeline. Mit diesem Schritt wird die Nachricht normalisiert und in MessageBox veröffentlicht. BizTalk Server wertet dann vorhandene Abonnements aus und bestimmt den beabsichtigten Empfänger der Nachricht basierend auf den Nachrichtenkontexteigenschaften. Schließlich leitet BizTalk Server die Nachricht basierend auf Abonnements oder Filtern an den beabsichtigten Empfänger weiter. Bei diesem Empfänger handelt es sich entweder um eine Orchestrierung oder einen Sendeport. Dies ist ein Ziel, an das BizTalk Server Nachrichten sendet, oder eine Quelle, von der BizTalk Server Nachrichten empfangen kann. BizTalk Server überträgt Nachrichten über einen Sendeport, indem sie über eine Sendepipeline übergeben werden. Die Sendepipeline serialisiert die Nachrichten in das vom Empfänger erwartete native Format, bevor die Nachrichten über einen Adapter gesendet werden.

Die MessageBox-Datenbank verfügt über die folgenden Komponenten:

• Messaging-Agent

  BizTalk Server interagiert mit MessageBox mithilfe dieses Agents, der Schnittstellen zum Veröffentlichen von Nachrichten, Abonnieren von Nachrichten, Abrufen von Nachrichten usw. bietet.

• Mindestens eine SQL Server-Datenbank

  Diese Datenbanken bieten einen Persistenzspeicher für Nachrichten, Nachrichtenteile, Nachrichteneigenschaften, Abonnements, den Orchestrierungsstatus, Nachverfolgungsdaten, Hostwarteschlangen für das Routing und vieles mehr.

Die folgende Abbildung zeigt, wie das BizTalk Server Messaging-Modul funktioniert:

Nachdem ein Empfangsport eine Nachricht empfangen hat, speichert MessageBox diese Nachricht für die Verarbeitung durch Geschäftsprozesse oder für das Routing an beliebige Sendeports, die über Abonnements für bestimmte Nachrichten verfügen.

Weitere Informationen finden Sie unter Architektur zum Veröffentlichen und Abonnieren weiter unten in diesem Leitfaden.

Azure Logic Apps: Nachfolger von BizTalk

Azure Logic Apps ist die Workflow-Orchestrierungs- und Integrationsplattform auf Unternehmensniveau von Microsoft. Diese Plattform ist für deterministische, langlebige, zustandsbehaftete Prozesse in Cloud- und Hybridumgebungen konzipiert. Der wichtigste Unterscheidungsmerkmal kombiniert Low-Code-Workflows mit visuellen Abläufen und erstklassigen Funktionen der Azure-Plattform: Sicherheit, Identität, Netzwerk, Überwachung und Governance. Azure Logic Apps unterstützt mehrere Bereitstellungsmodelle (Consumption, Standard, Hybrid), mit denen Kunden Workflows vollständig in Azure verwaltet oder in der Nähe von lokalen Systemen ausführen können, während Zuverlässigkeit, Zustandsverwaltung und auditierbare Ausführung beibehalten werden. Diese Flexibilität macht die Plattform zum natürlichen Rückgrat für die Modernisierung von BizTalk Server-Immobilien, die Orchestrierung von B2B/EDI-Integrationen und das Verbinden von SaaS-, ERP-, CRM- und Legacysystemen, bei denen Haltbarkeit und Observierbarkeit nicht verhandelbar sind.

Azure Logic Apps ist jedoch nicht nur auf "Low-Code" beschränkt. Kunden verwenden routinemäßig die Pro-Code-Erweiterbarkeit zusammen mit visuellen Workflows: Inline C#, JavaScript und PowerShell, benutzerdefinierter Code über lokale Funktionen, die in Azure Logic Apps ausgeführt werden, und benutzerdefinierte Connectors. Mit dieser Erweiterbarkeit können Teams komplexe Geschäftslogik, Transformationen, Protokollverarbeitung und Validierung direkt in Orchestrierungen einbetten, ohne das Workflowmodell zu unterbrechen. In realen Szenarien, z. B. Forderungsverarbeitung, Onboarding, Compliancepipelines, Mainframe- und Gesundheitsintegrationen, verlassen sich Kunden auf Azure Logic Apps, um als kontrollierte Ausführungsschicht zu fungieren, die deterministische Orchestrierung mit benutzerdefiniertem Code und zunehmend KI-unterstützten Entscheidungen kombiniert, während Governance, Sicherheit und betriebliches Vertrauen im Großen und Ganzen beibehalten werden.

In Azure Logic Apps können Sie ausführbare Geschäftsprozesse und Anwendungen als Logik-App-Workflows erstellen, indem Sie eine "Baustein"-Methode für die Programmierung mit einem visuellen Designer und vordefinierten Vorgängen aus Hunderten von Connectors erstellen, die minimalen Code erfordern. Ein Logik-App-Workflow beginnt mit einem Triggervorgang, gefolgt von mindestens einem Aktionsvorgang, wobei jeder Vorgang als logischer Schritt im Workflowimplementierungsprozess funktioniert. Ihr Workflow kann Aktionen verwenden, um externe Software, Dienste und Systeme aufzurufen. Einige Aktionen führen Programmieraufgaben aus, z. B. Bedingungen, Schleifen, Datenvorgänge, Variablenverwaltung und vieles mehr.

Azure Logic Apps bietet z. B. die folgenden Vorteile:

• Designer First (deklarativ)

  Entwerfen Sie komplexe Prozesse, indem Sie einfach zu verstehende Entwurfstools verwenden, um Muster und Workflows zu implementieren, die sonst nur schwer mit Code umgesetzt werden könnten.

• Code-First-Entwicklung

  Erstellen Sie umfassende codebasierte Lösungen mit Visual Studio Code, sodass Sie vorhandenen älteren .NET Framework-Code wiederverwenden und die neuesten .NET-Versionen integrieren können.

• Flexibel und skalierbar

  Azure Logic Apps ist ein cloudbasierter, serverloser, hoch skalierbarer Computerdienst, der sich automatisch skaliert und an die sich entwickelnden Geschäftsanforderungen anpasst.

Entwicklererfahrungen

In diesem Abschnitt wird zusammengefasst, wie sich die Entwicklungstools beim Migrieren von BizTalk Server (Visual Studio–centric) zu Azure Logic Apps (Visual Studio Code-centric) ändern und warum viele Teams das Azure Logic Apps-Workflowmodell schneller erstellen und verwalten können.

• Tools und Authoringmodell

  Mit BizTalk erfolgt die tägliche Integration in Visual Studio und verteilt sich auf mehrere Artefakttypen, z. B. Schemas, Karten, Orchestrierungen und Pipelines sowie Bereitstellungspaketierung (MSI/Bindungen) auf freigegebene Serverumgebungen.

  Mit Azure Logic Apps wechseln viele Teams zu Visual Studio Code zum Bearbeiten von Workflowdefinitionen und verwandten Dateien, indem sie einen einfacheren Ansatz "Workflow + Connectors" verwenden, der die Lösungskomplexität reduziert und kleinere, inkrementelle Änderungen fördert. Es ist in der Regel in der Praxis schneller, Visual Studio Code zu installieren, zu aktualisieren und zu standardisieren, als die Ausrichtung der BizTalk- und Visual Studio-Versionen beizubehalten. Textbasierte Workflowdefinitionen neigen dazu, Git-Diff- und Zusammenführung, Codeüberprüfungen und -wiederverwenden im Vergleich zu großen, kompilierten BizTalk-Lösungen zu verbessern.

• Was macht den Umstieg auf Azure Logic Apps zu einer Verbesserung

  Azure Logic Apps koppelt Visual Studio Code-basierte Entwicklung mit cloudeigener Diagnose. Sie können Workflows schnell validieren und aktualisieren und dann den Verlauf der Workflowausführung verwenden, um Eingaben und Ausgaben anzuzeigen, ohne sich auf serverseitige Konsolen und die Fehlerbehebung von Hostinstanzen zu verlassen. In Migrationsprojekten beschleunigt dieser Vorteil in der Regel die Iteration (Bearbeiten, Bereitstellen, Aktualisieren, Überprüfen), verbessert die Zusammenarbeit, da Workflows einfacher zu überprüfen und zu versionieren sind und eine sauberere Umgebungstrennung durch externe Verbindungen und Einstellungen unterstützt, wodurch die Konfigurationsabweichung "es funktioniert auf diesem Server" reduziert wird.

Connectors

Connectors stellen Vorgänge bereit, die Sie als Schritte in Ihren Workflows verwenden können. Wenn Sie Workflows mit Azure Logic Apps erstellen, helfen Connectors Ihnen bei der Arbeit mit Daten, Ereignissen und Ressourcen über Apps, Dienste, Systeme, Protokolle und Plattformen hinweg, ohne Code zu schreiben. Sie können Integrationslösungen für Dienste und Systeme sowohl von Microsoft als auch von Partnern erstellen, darunter BizTalk Server, Salesforce, Office 365, IBM Mainframes, SQL-Datenbanken und viele Azure-Dienste wie Azure Functions, Azure Storage und Azure Service Bus sowie lokale Apps, SaaS und APIs. Wenn kein vordefinierter Connector für die Ressource vorhanden ist, auf die Sie zugreifen möchten, können Sie den generischen HTTP-Vorgang verwenden, um mit dem Dienst zu kommunizieren, oder Sie können einen benutzerdefinierten Connector erstellen.

Technisch gesehen ist ein Connector ein Proxy oder Wrapper um eine API, die der zugrunde liegende Dienst oder das System zur Kommunikation mit Azure Logic Apps verwendet. Connectors stellen die Konnektivitätsfunktionen in Azure Logic Apps bereit und bieten eine Abstraktion über APIs, die sich normalerweise im Besitz des zugrunde liegenden SaaS-Systems befinden. Um das Aufrufen dieser APIs zu vereinfachen, verwenden Connectors Metadaten, um den Messagingvertrag zu beschreiben, sodass Entwickler wissen, welche Daten in der Anforderung und in der Antwort erwartet werden. Der Connector macht dann Vorgänge als Trigger oder Aktionen mit konfigurierbaren Eigenschaften verfügbar. Für einige Trigger und Aktionen müssen Sie zuerst eine Verbindung mit dem zugrunde liegenden Dienst oder System erstellen und konfigurieren und den Zugriff auf ein Benutzerkonto authentifizieren.

Die meisten Connectors in Azure Logic Apps sind entweder integriert oder verwaltet. Einige Konnektoren sind in beiden Versionen verfügbar. Die Verfügbarkeit ist davon abhängig, ob Sie einen Workflow für die Consumption- oder Standard-Logik-App erstellen. Für BizTalk Server-Migrationsszenarien werden Standardlogik-App-Workflows empfohlen, da BizTalk-Migrationsfunktionen auf Standardebene verfügbar sind.

Bei vielen BizTalk-Migrationen werden die von Ihnen ausgewählten Connectors durch allgemeine Integrationsanforderungen wie lokale Konnektivität, Dateiübertragung wie SFTP, Messagingsysteme und Branchensysteme gesteuert.

• Integrierte Connectors werden nativ auf der Azure Logic Apps Runtime ausgeführt. Im Vergleich zu verwalteten Connectors verringern integrierte Connectors in der Regel die Latenz und vermeiden pro Verbindung Aufrufe an den verwalteten Connectordienst, je nach Connector und Szenario.

• Verwaltete Connectors werden von Microsoft bereitgestellt, gehostet und verwaltet. Diese Konnektoren bieten Trigger und Aktionen für Cloud-Dienste, lokale Systeme oder beides.

Im Konnektorkatalog des Designers werden integrierte Konnektoren unter der Beschriftung Integriert angezeigt, während verwaltete Konnektoren unter der Beschriftung Geteilt angezeigt werden. Bei Workflows für Consumption-Logik-Apps folgen verwaltete Konnektoren entweder dem "Standard"- oder "Enterprise"-Preismodell.

• Mit benutzerdefinierten Connectors können Sie REST-APIs umschließen, häufig mithilfe einer OpenAPI-Definition oder SOAP-APIs mithilfe einer WSDL, wenn kein vordefinierter Connector vorhanden ist. Wenn keine vordefinierten Connectors für die APIs vorhanden sind, die Sie verwenden möchten, können Sie einen benutzerdefinierten Connector erstellen und über Logik-App-Workflows mit den entsprechenden Berechtigungen auf diesen Connector zugreifen.

Bei REST-APIs beschreiben Sie die API in der Regel mithilfe einer OpenAPI-Definition. Für SOAP-APIs verwenden Sie eine WSDL. Der benutzerdefinierte Connector erstellt einen Vertrag zwischen Azure Logic Apps und der API, mit dem Sie Anforderungsnachrichten zusammenstellen und typierte Antworten empfangen können, die Sie in downstream-Aktionen verwenden können. Benutzerdefinierte Connectors können auf öffentliche APIs oder private APIs verweisen, einschließlich APIs in Ihrem lokalen Netzwerk.

Wenn Sie einen benutzerdefinierten Connector implementieren, stellen Sie eine allgemeine Schnittstelle zum Senden von Anforderungen und Empfangen von typierten Antworten bereit, wodurch die Entwicklungsumgebung vereinfacht wird.

Weitere Informationen finden Sie unter:

• Übersicht über integrierte Connectors
• Übersicht über verwaltete Connectors
• In Azure Logic Apps verfügbare verwaltete Connectors
• Kundenspezifische Connectoren und APIs

Datenstrukturierung und Artefakte

Wenn Sie Integrationen zu Azure Logic Apps migrieren, benötigen Sie in der Regel Folgendes:

• In-Workflow-Datenstrukturierung, z. B. Analysieren, Verfassen und Zuordnen.

• Eine klare Strategie zum Speichern und Bereitstellen wiederverwendbarer Artefakte wie Schemas, Karten, Vorlagen und Assemblys.

In den folgenden Abschnitten werden die wichtigsten integrierten Optionen für Transformationen und die allgemeinen Orte zusammengefasst, an denen die unterstützenden Artefakte für Standardworkflows und freigegebene B2B-Szenarien gespeichert werden.

• Datenstrukturierung in Workflows: Datenvorgänge, Ausdrücke und Liquid-Vorlagen

  Verwenden Sie für die meisten JSON-Transformationen in Logik-App-Workflows integrierte Datenvorgänge, z. B. die JSON-Aktionen verfassen und analysieren, zusammen mit Ausdrücken und Workflowsteuerungsaktionen wie Bedingungen und Schleifen, um Daten zu shapen. Für komplexere Zuordnungsszenarien, insbesondere, wenn Sie eine wiederverwendbare Vorlage für Transformationen wie JSON-zu-JSON, JSON-zu-Text, XML-zu-JSON oder XML-zu-Text wünschen, können Sie eine Liquid-Vorlage verwenden. Liquid-Vorlagen beschreiben Zuordnungen mithilfe der Open-Source Liquid-Vorlagensprache. Sie können Vorlagen als Artefakte versionieren und zusammen mit Ihrem Workflow bereitstellen.

• Schemabasierte XML-Vorgänge: Analysieren von XML und Verfassen-XML

  Für XML-Erstellungs- und Validierungsszenarien in Logik-App-Workflows können Sie integrierte XML-Vorgänge wie das Verfassen-XML mit Schema - und Analyse-XML mit Schemaaktionen verwenden. Diese Aktionen sind die nützlichsten, wenn Sie eine stark typierte XML-Verarbeitung (XSD-basiert) benötigen, anstatt die Nutzlast als Nur-Text zu behandeln. Beispielsweise benötigen Sie konsistente Elementnamen, Datentypen und Struktur in mehreren Workflows.

• Speichern von Artefakten in Standardlogik-Apps

  Bei Standardlogik-App-Workflows können Sie Integrationsartefakte in der Logik-App-Ressource selbst speichern. Im Azure-Portal können Sie Karten und Schemas direkt in die Standardlogik-App-Ressource hochladen. Wenn Sie in Visual Studio Code arbeiten, können Sie den entsprechenden Ordnern im Artefaktverzeichnis des Projekts Schemas, Zuordnungen und Vorlagen hinzufügen und zusammen mit dem Workflow bereitstellen. Diese Funktion macht es Ihnen einfacher, Artefakte in der Quellcodeverwaltung zu behalten.

  Standard-Workflows unterstützen das Aufrufen benutzerdefinierter, kompilierter Assemblys, wie z.B. .NET-Framework-Assemblys, aus XSLT-Zuordnungen. Diese Unterstützung hilft Ihnen bei BizTalk-Migrationsszenarien, die auf vorhandene Transformationslogik basieren.

• Speichern geteilter B2B-Artefakte in einem Integrationskonto

  Ein Integrationskonto ist eine Azure-Ressource, die zentralen Zugriff auf wiederverwendbare B2B- und Integrationsartefakte bietet, die von mehreren Workflows geteilt werden können. Artefakte können Handelspartner, Vereinbarungen, XSD-Schemas, XSLT-Karten, liquide vorlagenbasierte Karten, Zertifikate, Batchkonfigurationen und .NET Framework-Assemblys umfassen.

  Häufig verwenden Sie Integrationskonten in B2B/EDI-Szenarien, in denen Sie einen freigegebenen, gesteuerten Artefaktspeicher getrennt von jedem einzelnen Workflow benötigen. Bei Standardworkflows können Sie häufig ein Integrationskonto vermeiden, indem Sie Schemas, Karten und Vorlagen mit dem Standardlogik-App-Projekt verpacken und zusammen bereitstellen. Standardworkflows unterstützen auch das Aufrufen von .NET Framework-Assemblys aus XSLT-Transformationen, die beim Portieren vorhandener BizTalk-Karten und Hilfsbibliotheken helfen können. Wenn Sie einen projektbasierten Ansatz bevorzugen, fügen Sie Schemas, Karten und Assemblys in Visual Studio Code hinzu und stellen Sie dann in Azure bereit.

• EDI-Schemas: Spezialisierte XSD-Artefakte für B2B-Integrationen

  EDI-Dokumentschemas definieren die Struktur oder den Text für einen EDI-Transaktionsdokumenttyp. In BizTalk-Migrationsprojekten beginnen Teams häufig, indem sie dieselben XSD-Definitionen wiederverwenden und dann iterativ vertriebspartnerspezifische Variationen überprüfen. Für Workflows in Azure Logic Apps sind viele BizTalk EDI-Schemas im GitHub-Repository der Microsoft Integration öffentlich für Sie verfügbar. Basierend auf Ihrem Implementierungsansatz können Sie diese Schemas entweder zusammen mit einer Standardlogik-App als Projektartefakte oder zentral in einem Integrationskonto für die Wiederverwendung über mehrere Workflows hinweg speichern.

Connectivity

Das Konnektivitätsmodell in Azure Logic Apps unterscheidet sich von BizTalk Server, was teilweise auf die Entwicklung der API-Economy zurückzuführen ist. Da immer mehr Unternehmen den Zugriff auf zugrunde liegende Systeme und Daten freigeben, war ein plattformunabhängiger Ansatz erforderlich. REST ist jetzt der dominierende architektonische Ansatz zum Entwerfen moderner Webdienste.

In Azure Logic Apps ist REST der Standardansatz zum Verbinden von Systemen. Da Microsoft und andere Softwareanbieter RESTful-Dienste zusätzlich zu ihren Systemen und Daten verfügbar machen, kann Azure Logic Apps diese Art von Informationen bereitstellen und nutzen. Die OpenAPI-Spezifikation ermöglicht es sowohl Menschen als auch Computern, die Interaktion zwischen einem Client und einem Server durch Metadaten zu verstehen. Im Rahmen dieses Verständnisses werden sowohl Anforderungs- als auch Antwortnutzdaten abgeleitet. Dies bedeutet, dass Sie dynamische Inhalte verwenden können, um die Eingaben einer Workflowaktion mit Daten aufzufüllen und die Ausgaben aus der Antwort in nachgeschalteten Aktionen zu verwenden.

Basierend auf dem Softwareanbieter, der den zugrunde liegenden Dienst implementiert, den ein Connector aufruft, variieren die Authentifizierungsschemas je nach Connector. Im Allgemeinen umfassen diese Schemas die folgenden Typen:

• Grundlegend
• Clientzertifikat
• Active Directory OAuth
• Raw
• Verwaltete Identität

Microsoft bietet starken Schutz, indem Daten während der Übertragung und im Ruhezustand verschlüsselt werden. Wenn Datenverkehr von Azure-Kunden zwischen Rechenzentren fließt (außerhalb von physischen Grenzen, die nicht von Microsoft oder im Auftrag von Microsoft kontrolliert werden), wird eine Verschlüsselungsmethode für die Sicherungsschicht mit dem Standard IEEE 802.1AE MAC Security (MACsec) von Punkt zu Punkt auf der zugrunde liegenden Netzwerkhardware angewendet.

Microsoft bietet Ihnen die Möglichkeit, das TLS-Protokoll (Transport Layer Security) zum Schutz von Daten zu verwenden, die zwischen Clouddiensten und Kunden übertragen werden. Die Microsoft-Rechenzentren verhandeln eine TLS-Verbindung mit Clientsystemen, die eine Verbindung mit Azure-Diensten herstellen. TLS bietet starke Authentifizierung, Datenschutz von Nachrichten und Integrität,wodurch die Erkennung von Manipulation, Abfangen und Fälschung von Nachrichten ermöglicht wird, sowie Interoperabilität, Algorithmusflexibilität sowie einfache Bereitstellung und Verwendung.

Während sich dieser Abschnitt auf REST-Konnektivität über Connectors konzentriert, können Sie die SOAP-Webdienstkonnektivität über die benutzerdefinierte Connectorumgebung oder mithilfe der API-Verwaltungsoberfläche implementieren, die großartige SOAP-Funktionen bietet. Weitere Informationen finden Sie unter Erhöhen des Geschäftlichen Nutzens durch Integrieren von SOAP-Legacyressourcen in Azure Logic Apps und Azure API Management.

Dauerhaftigkeit von Nachrichten

Azure Logic Apps bietet auf folgende Weise Dauerhaftigkeit von Nachrichten:

• Zustandsbehaftete Workflows in Standard-Logik-Apps speichern den Workflow-Zustand sowie Betriebseingaben und -ausgaben mithilfe von Prüfpunkten im Speicher. Diese Persistenz bietet einen dauerhaften Ausführungsverlauf und einen umfassenden Verlauf der Workflowausführung, sodass Sie detaillierte Vorgangseingaben und -ausgaben überprüfen können.

• Sie können einen Workflow erneut senden oder erneut ausführen, der im Azure-Portal oder mithilfe von APIs ausgeführt wird.

  Die erneute Übermittlung könnte dazu führen, dass der Workflow dieselbe Nachricht erneut verarbeitet. Stellen Sie daher sicher, dass Ihre Designs die "mindestens-einmal-Verarbeitung" voraussetzen und Idempotenz implementieren. Sie können beispielsweise Deduplizierungsschlüssel, Upserts oder Genau-Einmal-Effekte beim Ziel verwenden.

  Basierend auf dem Workflowtyp und der Konfiguration können Sie auch von einem bestimmten Punkt in der Ausführung erneut übermitteln. Stellen Sie jedoch sicher, dass Ihre downstream-Systeme Wiederholungen und potenzielle Duplikate sicher verarbeiten können.

• Mit Peek-Lock-Messaging in Azure Service Bus kann ein Empfänger eine Nachricht verarbeiten und diese Nachricht dann explizit begleichen. Beispielsweise kann der Empfänger die Nachricht verarbeiten und dann aus der Warteschlange entfernen, oder der Empfänger kann die Nachricht abbrechen und zur erneuten Zustellung verfügbar machen.

  Verwenden Sie den Azure Service Bus-Connector, um diese Funktion in Azure Logic Apps zu verwenden. Der Peek-Lock-Modus verbessert die Zuverlässigkeit und unterstützt Wiederholungs- oder erneute Zustellmuster. Jedoch erfordert die durchgängige Genau-Einmal-Verarbeitung in der Regel Idempotenz in nachgelagerten Systemen.

• Mit RabbitMQ können Sie häufig eine Haltbarkeit erzielen, indem Sie dauerhafte Warteschlangen verwenden oder zusammen mit persistenten Nachrichten austauschen und sich auf Verbraucherbestätigungen verlassen, damit das System Nachrichten erneut senden kann, wenn die Verarbeitung fehlschlägt, bevor eine Bestätigung gesendet wird. Wenn Sie den RabbitMQ-Connector integrieren, wenden Sie dasselbe Designprinzip wie bei anderen Brokern an: Gehen Sie von Wiederholungen und potenziellen Duplikaten aus und gestalten Sie die nachgelagerte Verarbeitung idempotent.

• Mit IBM MQ können Sie in der Regel Dauerhaftigkeit und zuverlässige Bereitstellung behandeln, indem Sie persistente Nachrichten und eine transaktionale Verarbeitung (Arbeitseinheiten) verwenden. Anschließend können Sie empfangene Nachrichten und nachgelagerte Arbeiten zusammen übergeben oder zurücknehmen. Wenn ein Fehler auftritt, bevor die Arbeit abgeschlossen ist oder eine Nachricht angenommen wird, kann die Nachricht zur erneuten Zustellung verfügbar werden.

  Wenn Sie den IBM MQ-Connector verwenden, planen Sie eine mindestens einmalige Zustellung ein und bearbeiten Sie mögliche Duplikate an der Zieladresse. In BizTalk-Migrationsszenarien dient dieses Muster in der Regel dazu, den Logik-App-Workflow und die nachgelagerten Endpunkte für eine sichere erneute Verarbeitung zu entwerfen, z. B. durch die Verwendung von Korrelations-IDs, Deduplizierung und idempotenten Schreibvorgängen, statt sich allein auf den Broker für ein durchgängiges Genau-Einmal-Verhalten zu verlassen.

Architektur zum Veröffentlichen und Abonnieren

Im Vergleich zum BizTalk Server-Messagingmodul verwendet Azure Logic Apps Connectors und externe Messagingdienste, um Messagingmuster zusammen mit der Workflow-Orchestrierung zu implementieren. Bei Publish-Subscribe-Mustern (pub-sub) mit Azure Logic Apps umfassen gebräuchliche Brokeroptionen Azure Service Bus (Topics und Abonnements) und RabbitMQ. Azure Service Bus ist ein vollständig verwalteter Unternehmensnachrichtenbroker mit Warteschlangen und Pub-Sub-Themen, die Sie zum Decoupieren von Anwendungen und Diensten verwenden können, was die folgenden Vorteile bietet:

• Übergreifender Lastenausgleich für konkurrierende Worker.
• Sicheres Routen und Übertragen von Daten sowie Kontrolle über Dienst- und Anwendungsgrenzen hinweg.
• Koordinieren von Transaktionsaufgaben mit hohen Anforderungen an Zuverlässigkeit.

Azure Logic Apps enthält einen Azure Service Bus-Connector, den Sie zum Veröffentlichen und Abonnieren von Nachrichten verwenden können. Der Vorteil besteht darin, dass Sie Nachrichten unabhängig von Ihrem Workflow verwenden können. Im Gegensatz zu BizTalk Server wird Messaging vom Workflowmodul entkoppelt. Sie können Nachrichtenabonnements in Azure Service Bus erstellen und Nachrichteneigenschaften (Benutzereigenschaften) als Schlüsselwertpaare verwenden, die von Filtern in einem Themenabonnement ausgewertet werden. Sie definieren diese Benutzereigenschaften, wenn Sie einen Azure Service Bus-Vorgang einrichten, indem Sie mindestens ein Schlüssel-Wert-Paar hinzufügen. Eine Demonstration finden Sie im Video: Pub Sub Messaging mit Azure Integration Services – Teil 2 inhaltsbasiertes Routing.

Azure Logic Apps mit Standardworkflows umfassen auch einen integrierten RabbitMQ-Connector, den Sie zum Senden und Empfangen von Nachrichten verwenden können. In RabbitMQ implementieren Sie häufig das Pub-Sub-Muster, indem Sie Nachrichten in einem Exchange veröffentlichen und mehrere Konsumenten Nachrichten über separate Warteschlangen erhalten, die an diesen Exchange gebunden sind, häufig mithilfe von Routingschlüsseln oder Routing auf Header-Basis, abhängig vom Typ des Exchanges. Dieser Ansatz unterstützt Auffächerungs- und Routenplanungs-basierte Verteilungsmuster ähnlich Service Bus-Themen und Abonnementregeln, wird jedoch mittels RabbitMQ-Austauschvorgängen, Bindungen und Warteschlangeneinstellungen konfiguriert. RabbitMQ ist häufig eine starke Option, wenn Sie über ein vorhandenes lokales RabbitMQ-Anwesen verfügen, Brokerfunktionen in Umgebungen benötigen, in denen Azure Service Bus nicht verfügbar ist, oder das Messaging lokal im Netzwerk halten möchten, in dem Produzenten und Verbraucher laufen. Erstellen Sie das Design, wie bei jeder brokerbasierten Integration, im Hinblick auf Wiederholungen und potenzielle Duplikate, indem Sie beispielsweise Bestätigungen, dauerhafte Warteschlangen und persistente Nachrichten wie zutreffend verwenden, und machen Sie die nachgelagerte Verarbeitung idempotent.

Für viele BizTalk-Migrationsprojekte ist Azure Service Bus die gängige Standardoption für cloudneigene pub-sub, da der Dienst vollständig verwaltet wird und integrierte Themen- und Abonnementsemantik mit Filterung bereitstellt. Für lokale Pub-Sub-Anforderungen kann RabbitMQ besser geeignet sein, insbesondere mit dem Hybridbereitstellungsmodell für Azure Logic Apps, da Azure Service Bus ein Clouddienst ist und keine lokale Bereitstellungsoption hat. Standardisieren Sie in diesen Fällen hinsichtlich Dauerhaftigkeit und Wiederholungssemantik, und wenden Sie Idempotenz an den Workflow- und Endpunktgrenzen an.

Geschäftsregel-Engine

Azure Logic Apps enthält das Azure Logic Apps Rules Engine. Diese Regel-Engine enthält die BizTalk-Geschäftsregel-Engine(BRE)-Runtime, sodass Sie vorhandene BizTalk-BRE-Richtlinien wiederverwenden können. Derzeit gibt es nur Unterstützung für XML- und .NET Framework-Fakten.

Vernetzung

Für eingehende und ausgehende Verbindungen bietet Azure mehrere Möglichkeiten, ihre Dienste innerhalb einer Netzwerkgrenze zu isolieren und lokale und Cloudworkloads zu verbinden. In der folgenden Liste werden verschiedene Möglichkeiten beschrieben, wie Sie Azure-Ressourcen in Ressourcen innerhalb eines Netzwerkumkreises integrieren können:

• Hybridverbindungen

  Sowohl ein Azure-Dienst als auch ein Feature in Azure App Service, Hybrid Connections unterstützt Szenarien und bietet Funktionen, die über die in Azure App Service hinausgehen. Weitere Informationen zur Verwendung außerhalb von Azure App Service finden Sie unter Hybridverbindungen in Azure Relay. In Azure App Service können Sie Hybridverbindungen verwenden, um auf Anwendungsressourcen in jedem Netzwerk zuzugreifen, das ausgehende Anrufe an Azure über Port 443 tätigen kann. Hybridverbindungen ermöglichen den Zugriff von Ihrer App auf einen TCP-Endpunkt, sie bieten keine neue Möglichkeit, um auf Ihre App zuzugreifen. In Azure App Service entspricht jede Hybridverbindung einer Kombination aus einem einzelnen TCP-Host und einem Port. Durch diese Funktion können Ihre Apps auf Ressourcen unter jedem beliebigen Betriebssystem zugreifen, sofern ein TCP-Endpunkt vorhanden ist. Hybridverbindungen kennen das Anwendungsprotokoll nicht und wissen auch nicht, worauf Sie zugreifen möchten. Dieses Feature ermöglicht lediglich den Netzwerkzugriff.

• Integration in ein virtuelles Netzwerk

  Durch die Integration von Azure Virtual Network können Sie Ihre Azure-Ressource mit einem in Azure konfigurierten virtuellen Netzwerk verbinden, sodass Ihre App auf Ressourcen in diesem virtuellen Netzwerk zugreifen kann. Die Integration virtueller Netzwerke in Azure Logic Apps wird nur für ausgehende Aufrufe von Ihrer Azure-Ressource an Ihr virtuelles Netzwerk verwendet.

  Mit Peering virtueller Netzwerke können Sie Ihre lokalen Netzwerke mit Azure verbinden. Dies bietet bidirektionale Konnektivität zwischen lokalen Ressourcen und Azure-Diensten. Azure Integration Services bietet virtuelle Netzwerkkonnektivität, die Hybridintegration ermöglicht.

  Die folgende Abbildung zeigt eine Logik-App-Standardressource mit geöffneter Seite „Netzwerk“ und aktivierter Integration virtueller Netzwerke, wie im Feld Ausgehender Datenverkehr hervorgehoben. Diese Konfiguration stellt sicher, dass der gesamte ausgehende Datenverkehr aus diesem virtuellen Netzwerk stammt.

  

• Private Endpunkte

  Ein privater Endpunkt ist eine Netzwerkschnittstelle, die eine private IP-Adresse aus Ihrem virtuellen Netzwerk verwendet. Diese Netzwerkschnittstelle bietet eine private und sichere Verbindung mit einer von Azure Private Link unterstützten Azure-Ressource. Indem Sie einen privaten Endpunkt aktivieren, integrieren Sie diese Azure-Ressource in Ihr virtuelles Netzwerk und ermöglichen Ressourcen im Netzwerk eingehende Aufrufe Ihrer Azure-Ressource.

Benutzerdefinierter Code

In Azure Logic Apps können Sie .NET-Code in Ihrem Standardlogik-App-Workflow erstellen und ausführen. Hierfür müssen Sie Visual Studio Code mit der Erweiterung von Azure Logic Apps (Standard) verwenden.

Der InlineCode Operations-Connector stellt die Aktionen " Execute JavaScript Code", "Execute CSharp Script Code" und "Execute PowerShell Code" bereit. Sie können diese Aktionen verwenden, um Code hinzuzufügen, der dynamische Inhaltseingaben und -ausgaben unterstützt. Das Azure Logic Apps-Modul erwartet, dass dieser Code kurze Ausführungszeiten hat. Nachdem der Code die Ausführung abgeschlossen hat, ist die Ausgabe für nachgeschaltete Aktionen verfügbar, die im Workflow verwendet werden sollen.

Wie bereits erwähnt, ist die Unterstützung für das Aufrufen von .NET Framework-Assemblys aus einer XSLT-Zuordnung derzeit in Logik-App-Workflows verfügbar, wenn Sie diese Assemblys in ein Integrationskonto hochladen. Diese Funktion unterstützt benutzerdefinierte Datentransformationsregeln. Für Standard-Logik-App-Workflows können Sie .NET Framework-Code aus XSLT-Maps ohne ein Integrationskonto aufrufen. Sie können einem Logik-App-Standardprojekt auch Assemblys und Zuordnungen in Visual Studio Code hinzufügen und anschließend in Azure bereitstellen. Weitere Informationen finden Sie unter .NET Framework-Assemblyunterstützung zu XSLT-Transformationen in Azure Logic Apps (Standard) hinzugefügt.

Anwendungsgruppen

In Azure Logic Apps können Sie mehrere Workflows in eine Standard-Logik-App-Ressource einfügen und ausführen, was zu einer 1:n-Beziehung führt. Wenn Sie lokal an einem Logik-App-Standardprojekt in Visual Studio Code arbeiten, wird Ihre Logik-App-Ressource diesem einzelnen Projekt zugeordnet. Mit diesem Ansatz können Sie verwandte Workloads, Code und Artefakte im selben Projekt einfach und logisch gruppieren und dieses Projekt als einzelne Einheit bereitstellen.

Cloudarchitekturen funktionieren anders als serverbasierte Paradigmen wie BizTalk. Azure Logic Apps (Standard) verwendet ein Pullmodell, um Code und Artefakte einzubringen. Daher kopieren Sie alle zusätzlichen erforderlichen Artefakte in Ihr Projekt und stellen sie anschließend mit Ihrem Code und anderen Artefakten bereit. In einigen Fällen sollten Sie vermeiden, dass Sie den erforderlichen Code und Artefakte kopieren müssen. In diesem Fall können Sie diese Funktionalität in einen Dienst umwandeln, den Sie separat verwalten, aber aus einem Workflow aufrufen können.

Angenommen, Sie verfügen über eine Datentransformation, die von Ihrer Organisation häufig verwendet wird. Anstatt die Zuordnung für die Transformation über mehrere Logik-App-Projekte hinweg einzubinden, können Sie eine Schnittstelle implementieren, die die Transformation als Dienst bereitstellt. Anschließend können Sie den Lebenszyklus für diesen Dienst getrennt von Ihren Logik-App-Projekten verwalten und diesen Dienst aus Ihren Workflows aufrufen.

Mit der Möglichkeit, mehrere Workflows in ein Logik-App-Standardprojekt einzubinden, fragen Sie sich möglicherweise, wie Sie diese Workflows innerhalb eines Projekts oder über mehrere Projekte hinweg organisieren würden. Die Antwort hängt in der Regel von Ihren Anforderungen ab, beispielsweise:

• Geschäftsprozessaffinität
• End-to-End-Überwachung und -Support
• Sicherheit, rollenbasierte Zugriffssteuerung und Netzwerkisolation
• Leistung und Wichtigkeit für das Unternehmen
• Geostandort und Georedundanz

Weitere Informationen finden Sie unter Organisieren von Logik-App-Workflows in Azure Logic Apps (Standard).

Sicherheit und Governance

Azure Logic Apps unterstützt die folgenden Sicherheitsfunktionen:

• Azure-Schlüsseltresor

  Sie können Anmeldeinformationen, Geheimnisse, API-Schlüssel und Zertifikate mithilfe von Azure Key Vault speichern. In Azure Logic Apps können Sie mithilfe des Azure Key Vault-Connectors auf diese Informationen zugreifen und sie aus den Protokollen der Plattform und dem Ausführungsverlauf ausschließen, indem Sie die Funktion für sichere Ein- und Ausgaben verwenden.

  Weiter unten im Abschnitt Nachverfolgung wird in diesem Leitfaden die Ausführungsverlaufsfunktion beschrieben, die eine schrittweise Wiedergabe der Ausführung eines Workflows bereitstellt. Obwohl Azure Logic Apps den Vorteil bietet, dass jede Eingabe und Ausgabe in einer Workflowausführung erfasst wird, müssen Sie manchmal den Zugriff auf sensible Daten differenzierter verwalten. Sie können Obfuskation für diese Daten einrichten, indem Sie die Funktion für sichere Eingaben und Ausgaben für Trigger und Aktionen verwenden, um solche Inhalte aus dem Ausführungsverlauf auszublenden und das Senden dieser Daten an Azure Monitor (insbesondere an Log Analytics und Application Insights) zu verhindern. Die folgende Abbildung zeigt ein Beispielergebnis für das Aktivieren von sicheren Ein- und Ausgaben im Ausführungsverlauf.

  

• OAuth-basierte Integration

  Die meisten Connectors verwenden diesen Authentifizierungstyp beim Herstellen von Verbindungen. Dieser Ansatz macht die Integration in viele SaaS-Dienste so einfach wie das Angeben Ihrer E-Mail-Adresse und Ihres Kennworts. Azure API Management unterstützt auch OAuth, sodass Sie beide Dienste zusammen verwenden können, indem Sie ein einheitliches Authentifizierungsschema bereitstellen.

  Diese Funktion ist in BizTalk Server nicht nativ verfügbar.

• Verwaltete Identitäten

  Azure Logic Apps (Standard) können den Zugriff auf Speicherkonten mithilfe einer verwalteten Identität authentifizieren. Einige Connectors unterstützen außerdem die Verwendung verwalteter Identitäten für die Authentifizierung des Zugriffs auf Ressourcen, die durch Microsoft Entra ID geschützt sind. Wenn Sie eine verwaltete Identität für die Authentifizierung Ihrer Verbindung verwenden, müssen Sie keine Anmeldeinformationen, Geheimnisse oder Microsoft Entra-Token bereitstellen.

Anwendungs- und Zugriffsverwaltung

Das Azure-Portal ist ein gängiges Tool, das Administratoren und Supportmitarbeiter verwenden, um die Integrität von Schnittstellen anzuzeigen und zu überwachen. Für Azure Logic Apps umfasst diese Benutzeroberfläche umfangreiche Transaktionsablaufverfolgungen, die über den Ausführungsverlauf verfügbar sind. Granulare rollenbasierte Zugriffssteuerungen (Role-Based Access Controls, RBAC) sind ebenfalls verfügbar, sodass Sie den Zugriff auf Azure-Ressourcen auf verschiedenen Ebenen verwalten und einschränken können.

Lagerung

Azure Logic Apps nutzt Azure Storage zum Speichern und automatischen Verschlüsseln von ruhenden Daten. Diese Verschlüsselung schützt Ihre Daten und unterstützt Sie beim Einhalten der Sicherheits- und Complianceanforderungen Ihrer Organisation. Azure Storage verwendet standardmäßig von Microsoft verwaltete Schlüssel, um Ihre Daten zu verschlüsseln. Weitere Informationen finden Sie unter Azure Storage-Verschlüsselung für ruhende Daten.

Wenn Sie mit Azure Storage im Azure-Portal arbeiten, werden alle Transaktionen über HTTPS ausgeführt. Sie können auch mit Azure Storage arbeiten, indem Sie die Storage-REST-API über HTTPS verwenden. Um die Verwendung von HTTPS beim Aufruf der REST-APIs für den Zugriff auf Objekte in Speicherkonten zu erzwingen, aktivieren Sie die sichere Übertragung, die für das Speicherkonto erforderlich ist.

Das Hybridbereitstellungsmodell von Azure Logic Apps (Standard) basiert auf SQL Server. Mit dieser Abhängigkeit können Sie vorhandene lokale SQL Server-Umgebungen mit BizTalk Server verwenden.

Verarbeitung großer Dateien

Einige grundlegende Unterschiede bestehen zwischen der Verarbeitung großer Dateien mit BizTalk Server und Azure Logic Apps. Untersuchen Sie beispielsweise die Szenarien für große Nachrichten sorgfältig, um die richtige Lösung zu finden, denn es gibt potenziell verschiedene Möglichkeiten, dieses Problem in einer modernen Cloudumgebung zu lösen.

Dateigrößenbeschränkungen

In Azure gibt es Dateigrößenbeschränkungen, um konsistentes und zuverlässiges Verhalten zu gewährleisten. Um Ihr Szenario zu überprüfen, lesen Sie unbedingt die Dokumentation zu Dienstgrenzwerten für Azure Logic Apps. Einige Connectors unterstützen Nachrichtensegmentierung (Blockerstellung) für Nachrichten, die den Standardgrenzwert für Nachrichten überschreiten, der je nach Connector unterschiedlich ist. Nachrichtensegmentierung funktioniert, indem eine große Nachricht in kleinere Nachrichten aufgeteilt wird.

Azure Logic Apps ist nicht der einzige Dienst, der Grenzwerte für die Nachrichtengröße aufweist. Beispielsweise weist Azure Service Bus auch solche Grenzwerte auf. Weitere Informationen zur Verarbeitung großer Nachrichten in Azure Service Bus finden Sie unter Unterstützung für umfangreiche Nachrichten.

Um Dateigrößeneinschränkungen zu vermeiden, können Sie das Anspruchsprüfungsmuster implementieren, mit dem eine große Nachricht in eine Anspruchsprüfung und Nutzdaten aufgeteilt werden kann. Sie senden die Anspruchsprüfung an die Messagingplattform und speichern die Nutzdaten in einem externen Dienst. Auf diese Weise können Sie große Nachrichten verarbeiten, während Sie den Nachrichtenbus und den Client vor Überlastung schützen. Dieses Muster trägt auch zur Kostensenkung bei, weil Speicher in der Regel günstiger ist als die von der Messagingplattform verwendeten Ressourceneinheiten.

Überwachung und Warnungen

In Azure Logic Apps können Sie die Unterstützung von Application Insights aktivieren, die kuratierte Visualisierungen als Grundlage für die Überwachung von Azure-Diensten bereitstellt. Diese Visualisierungen helfen Ihnen, Standardworkflows effektiver zu überwachen, indem Sie Dashboards verwenden, die speziell für Azure Logic Apps (Standard) entwickelt wurden. Der Dashboardbereich deckt die Workflows in einer Standard-Logik-App ab. Das Dashboard basiert auf Azure-Arbeitsmappen und bietet verschiedene Visualisierungen. Sie können diese Arbeitsmappen ganz einfach erweitern und anpassen, um bestimmte Anforderungen zu erfüllen.

Serverless 360 ist eine externe Lösung von Kovai, die Überwachung und Verwaltung durch Zuordnung von Azure-Diensten wie Azure Logic Apps, Azure Service Bus, Azure API Management und Azure Functions bereitstellt. Sie können Nachrichten erneut verarbeiten, indem Sie Warteschlangen für unzustellbare Nachrichten in Azure Service Bus verwenden, die Selbstreparatur aktivieren, um zeitweilige Dienstunterbrechungen zu beheben, und proaktive Überwachung durch synthetische Transaktionen einrichten.

Sie können benutzerdefinierte Überwachungsregeln konfigurieren und Protokolle in einer Portalumgebung anzeigen. Sie können Benachrichtigungen über verschiedene Kanäle senden, z. B. über E-Mail, Microsoft Teams und ServiceNow. Es sind Dienstzuordnungen verfügbar, um die Integrität Ihrer Schnittstellen visuell zu bestimmen.

Geschäftsaktivitätsüberwachung

Für Fachkräfte in der Entwicklung oder Business Analysten, die an Lösungen arbeiten, die Dienste und Systeme mithilfe verschiedener Azure-Ressourcen integrieren, kann es schwierig sein, die Beziehung zwischen den technischen Komponenten der Lösung und dem Geschäftsszenario zu visualisieren. Um Geschäftskontexte zu den Azure-Ressourcen in Ihre Lösung einzubeziehen, können Sie Geschäftsprozesse erstellen, die die von diesen Ressourcen implementierte Geschäftslogik visuell darstellen. In Azure Business Process Tracking ist ein Geschäftsprozess eine Reihe von Phasen, die die Aufgaben darstellen, die ein reales Geschäftsszenario umfasst.

Eine weitere Option besteht darin, eine externe Lösung von Kovai mit dem Namen Serverless 360 zu verwenden. Zusammen mit der Überwachungsplattform können Sie das Feature zur Überwachung von Geschäftsaktivitäten verwenden, das eine End-to-End-Nachverfolgung für Geschäftsprozessabläufe über cloudnative und hybride Integrationen hinweg bereitstellt. Dieses Feature enthält einen verwalteten Connector, mit dem Entwickler Code instrumentieren und wichtige Geschäftsdaten erfassen können. Administratoren können anschließend Dashboards erstellen und für Business Analysts freigeben.

Tracking

Azure Logic Apps bietet detaillierte Verlaufsprotokolle von Workflows, sodass Entwickler und Supportanalysten die Telemetrie zu Aktionen einsehen können, einschließlich aller verarbeiteten Eingaben und Ausgaben. Um vertrauliche Daten zu schützen, können Sie sichere Eingaben und Ausgaben für einzelne Aktionen in Workflows aktivieren. Diese Funktion verschleiert oder blendet die Daten in Protokollen und Workflowausführungsverläufen aus, um Datenlecks zu vermeiden.

Über die Datenverschleierung hinaus können Sie Azure RBAC-Regeln verwenden, um den Datenzugriff zu schützen. Azure RBAC enthält bestimmte integrierte Rollen für Azure Logic Apps (Standard). Über Azure RBAC hinaus können Sie den Zugriff auf den Ausführungsverlauf in Azure Logic Apps nach IP-Adressbereich einschränken.

Hosting

• Hostingpläne

  In Azure Logic Apps mit einem einzigen Mandanten können Sie einen einzigen Workflowdienstplan verwenden, um mehrere Standardlogik-Apps zu hosten. Dies bedeutet, dass Sie nicht alle Workflows in einer einzigen Standardlogik-App-Ressource bereitstellen müssen. Stattdessen können Sie diese Workflows in logischen Gruppen (Logik-Apps) organisieren, um andere Aspekte Ihrer Lösung besser verwalten zu können. Dieser Ansatz hilft Ihnen, Ihren Workflowdienstplan optimal zu nutzen und Ihre Anwendungen zukunftssicher zu machen, die Sie implementieren können, damit sie individuell skaliert werden können.

  Für eine Standard-Logik-App sind die folgenden Tarife verfügbar: WS1, WS2 und WS3. Funktionell bietet jede Dienstebene die gleichen Funktionen. Ihre Anforderungen für Compute und Arbeitsspeicher bestimmen, was für Ihr Szenario am besten geeignet ist, z. B.:

  Tarif	Virtuelle CPU (vCPU)	Arbeitsspeicher (GB)
  WS1	1	3,5
  WS2	2	7
  WS3	4	14

  Weitere Informationen finden Sie unter Preisniveaus im Standardmodell.

• Hybridbereitstellungsmodell

  Azure Logic Apps bietet ein Hybridbereitstellungsmodell, sodass Sie Standardlogik-App-Workflows in Szenarien lokal, mit privater oder mit öffentlicher Cloud bereitstellen und hosten können. Dieses Modell bietet Ihnen die Funktionen zum Hosten von Integrationslösungen in teilweise verbundenen Umgebungen, wenn Sie lokale Verarbeitung, Datenspeicher und Netzwerkzugriff verwenden müssen. Mit der Hybridoption haben Sie die Freiheit und Flexibilität, die beste Umgebung für Ihre Workflows auszuwählen. Weitere Informationen finden Sie unter Einrichten Ihrer eigenen Infrastruktur für Standardlogik-Apps mithilfe der Hybridbereitstellung.

• Verfügbarkeit und Redundanz

  In Azure bieten Verfügbarkeitszonen Resilienz, verteilte Verfügbarkeit und Aktiv-Aktiv-Aktiv-Zonenskalierbarkeit. Um die Verfügbarkeit für Ihre Logik-App-Workloads zu erhöhen, können Sie Unterstützung von Verfügbarkeitszonen aktivieren, aber nur, wenn Sie Ihre Logik-App erstellen. Sie benötigen mindestens drei separate Verfügbarkeitszonen in jeder Azure-Region, die Zonenredundanz unterstützt und ermöglicht. Die Azure Logic Apps-Plattform verteilt diese Zonen und Logik-App-Workloads auf diese Zonen. Diese Funktion ist eine wesentliche Voraussetzung für die Aktivierung resilienter Architekturen und die Bereitstellung von Hochverfügbarkeit, wenn in einer Region Rechenzentrumsausfälle auftreten. Weitere Informationen finden Sie unter Erstellen von Lösungen für Hochverfügbarkeit mit Verfügbarkeitszonen.

• Isolierte und dedizierte Umgebung

  Für Standard-Logik-Apps besteht die Option, eine App Service-Umgebung (ASE) v3 für Ihre Bereitstellungsumgebung auszuwählen. Mit einer ASE v3 erhalten Sie eine vollständig isolierte und dedizierte Umgebung, um Anwendungen in hoher Skalierung mit vorhersagbaren Preisen auszuführen. Sie zahlen nur für den ASE-App Service-Plan, unabhängig von der Anzahl der Logik-Apps, die Sie erstellen und ausführen

Szenarien, die zusätzliche Azure-Integrationsdienste erfordern, finden Sie in der folgenden Dokumentation:

• Premium- und Standard-Messagingebenen von Azure Service Bus
• Azure API Management – Featurebasierter Ebenenvergleich

Bereitstellung

Azure Logic Apps unterstützt Infrastruktur als Code (IaC), indem sie die Möglichkeit zum Erstellen von Infrastrukturressourcen mithilfe von Azure-Ressourcenverwaltungsvorlagen bereitstellt. Obwohl ARM-Vorlagen komplex erscheinen können, wenn es darum geht, sie zu verstehen und als einheitliche Lösung zu implementieren, können Sie Abstraktionstools wie Bicep, Terraform oder Pulumi verwenden, die eine codeähnliche Umgebung für die Erstellung Ihrer Infrastrukturdefinition bieten. Obwohl diese Tools Abstraktionsebenen über ARM-Vorlagen bereitstellen, generieren die Tools letztendlich ARM-Vorlagen und können diese Vorlagen für Sie bereitstellen.

Wenn Ihre Infrastruktur eingerichtet ist, können Sie die Logik bereitstellen, die Ihre End-to-End-Workflows implementiert. Da Azure Integration Services eine Sammlung von Tools zum Implementieren Ihrer Integrationsworkflows bietet, müssen Sie jede Komponente bereitstellen. Bei Lösungen, die mit Azure Integration Services erstellt wurden, basieren CI/CD-Pipelines in der Regel auf der Bereitstellung einer Orchestrierung von Komponenten. DevOps-Entwickler können integrierte Aktionen verwenden, die Bereitstellungsaktivitäten abstrahieren, oder generische Aktionen, die entweder CLI-Befehle oder Automatisierungsskripts wie PowerShell und Bash ausführen. In den meisten Fällen passen technische Fachkräfte Pipelines an die Anforderungen der Anwendung an, lesen die Anleitungen aus der offiziellen Dokumentation und verwenden Beispielrepositorys als Ausgangspunkt.

Um jede Komponente auf die Bereitstellung vorzubereiten, sind in der Regel die folgenden Schritte zu berücksichtigen:

• Continuous Integration-Phase

  1. Abrufen der neuesten Version des Quellcodes.

  2. Vorbereiten des Codes mit der umgebungsspezifischen Konfiguration.

     Die Details für diesen Schritt hängen von der Unterstützung der einzelnen Technologien für externe Einschleusung von Umgebungsvariablen ab. Die grundlegende Prämisse ist, dass umgebungsbasierte Konfigurationsinformationen (z. B. Verbindungszeichenfolgen und Verweise auf externe Ressourcen) abstrahiert werden, um auf ein Repository für Anwendungseinstellungen zu verweisen. In diesem Szenario würden Sie also Verweise, die als Klartext vorhanden sind, direkt im Repository für die Anwendungseinstellungen speichern, sensible Werte wie Geheimnisse jedoch als Verweiszeiger auf Einträge in einem Geheimnisspeicher (z. B. einem Azure-Schlüsseltresor).

     Azure Logic Apps ermöglicht diesen Ansatz für eine Logik-App-Standardressource, indem Verweise auf das Repository für die Anwendungseinstellungen unterstützt werden. Sie können dann Name-Wert-Paare Einträgen in Ihrem Schlüsseltresor zuordnen.

  3. Packen Sie den Code für die Bereitstellung in verschiedenen Umgebungen.

• Continuous Deployment-Phase

  1. Stellen Sie gepackten Code in der Zielumgebung bereit.

  2. Aktualisieren Sie das Repository für die Anwendungseinstellungen mit den richtigen Umgebungswerten, entweder als Klartext oder als Verweise auf Einträge in Ihrem Schlüsseltresor.

  3. Aktualisieren Sie alle erforderlichen Berechtigungen, die vom Code abhängen.

  4. Bereiten Sie Ihre Anwendung bei Bedarf auf die Ausführung vor.

Featureabgleich

Die folgende Tabelle und das folgende Diagramm zeigt, wie Ressourcen, Artefakte, Features und Funktionen zwischen BizTalk Server, Azure Logic Apps (Standard) und anderen Diensten verglichen und übereinstimmen. Versuchen Sie, Azure Logic Apps-Features so weit wie möglich zu verwenden, um eine einheitliche, kostengünstigere Lösung zu erstellen.

Azure Logic Apps Standard (Cloud)

Azure Logic Apps Standard Hybrid (lokal)

Um über die neuesten Investitionen auf dem Laufenden zu bleiben, abonnieren Sie den Blog der Tech Community zu Integrationen in Azure.

Nächste Schritte

Sie haben mehr darüber erfahren, wie Azure Logic Apps mit BizTalk Server verglichen werden. Überprüfen Sie als Nächstes vorgeschlagene Ansätze und Ressourcen, Planungsüberlegungen und bewährte Methoden für Ihre Migration.