Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure Logic Apps ist der Nachfolger von BizTalk Server. Azure Logic Apps Standard bietet Workflow-Orchestrierung, Unternehmensintegration und Erweiterbarkeit für Cloud- und Hybridlösungen. Dieser Artikel fasst die Gründe für eine Migration, die verfügbaren Hosting-Optionen und die BizTalk-Funktionen zusammen, die Sie bewerten müssen.
Für Migrationsstrategien, Planungsüberlegungen und Bereitstellungsanleitungen siehe Migrate BizTalk Server with Azure Logic Apps Migration Agent.
BizTalk Server-Lebenszyklus
BizTalk Server 2020 ist die letzte Version von BizTalk Server. Microsoft erwartet, dass der Verkauf von BizTalk Server 2020 am 31. März 2027 endet. Der Mainstream-Support läuft bis zum 12. April 2028, danach unterliegt das Produkt weiterhin der Microsoft Fixed Lifecycle Policy.
Microsoft plant außerdem, berechtigten Kunden vom 13. April 2028 bis zum 10. April 2030 optionalen, kostenpflichtigen Extended-Mainstream-Support anzubieten. Dieses Angebot ist als temporäre Migrationsdeckung gedacht, wird voraussichtlich einige BizTalk-Funktionen ausschließen und bleibt der endgültigen Berechtigung, Deckung, Preisgestaltung und Kaufbedingungen unterworfen.
Beginnen Sie frühzeitig mit der Migrationsplanung, insbesondere wenn Ihre Lösungen auf Business Activity Monitoring (BAM), dem Enterprise Service Bus (ESB) Toolkit, Industrie-Beschleunigern, alten Enterprise-Adaptern, BizTalk-spezifischen Anwendungslebenszyklus-Management-Tools oder Visual Studio-Versionen nach Visual Studio 2022 basieren. Diese Fähigkeiten werden voraussichtlich vom bezahlten Extended-Mainstream-Support ausgeschlossen oder müssen möglicherweise neu gestaltet werden.
Für die neuesten Daten und Termine siehe:
- Microsoft BizTalk Server Produktlebenszyklus-Update
- BizTalk Server 2020 End-of-Sale-Ankündigung
- Microsoft Fixed Lifecycle Policy
Warum Logic Apps Standard für BizTalk-Workloads geeignet ist
BizTalk-Anwendungen kombinieren häufig robuste Orchestrierung, Messaging, Transformationen, Business-to-Business-(B2B)-Verarbeitung, benutzerdefinierten Code und Zugang zu privaten Systemen. Azure Logic Apps Standard bietet diese Integrationsfunktionen in einer Laufzeitumgebung mit einem einzelnen Tenant und unterstützt sowohl stateful als auch stateless workflows. Im Gegensatz zu einer Consumption-Logik-App kann eine Standard-Logik-App mehrere Workflows enthalten, die Rechenleistung, Speicher, Netzwerk und Konfiguration teilen.
Die folgenden Fähigkeiten machen Standard zum bevorzugten Logic Apps-Ressourcentyp für die meisten BizTalk-Modernisierungsprojekte:
| BizTalk-Anforderung | Logic Apps Standard-Funktionalität |
|---|---|
| Dauerhafte, langjährige Geschäftsprozesse | Zustandsbehaftete Workflows speichern den Ausführungszustand und können unterbrochene Ausführungen wiederherstellen. Zustandslose Workflows unterstützen eine In-Memory-Verarbeitung mit geringerer Latenz, wenn keine Persistenz erforderlich ist. |
| Verwandte Integrationsprozesse | Mehrere Workflows können in einer Standardlogikanwendung ausgeführt werden und Ressourcen, Konfiguration und Bereitstellungsgrenzen teilen. |
| Unternehmensmessaging und Datenformate | Eingebaute Connectors und Aktionen unterstützen Dienste wie Azure Service Bus, Event Hubs, SQL Server, XML, Flatfiles, Transformationen und B2B-Szenarien. |
| Benutzerdefinierte Implementierungslogik | Lokale .NET-Funktionen führen workflowbezogenen Code zusammen mit Workflows innerhalb derselben Projekt- und Anwendungsgrenzen aus. Inline-Skripte, individuell eingebaute Steckverbinder und externe Dienste bieten weitere Erweiterbarkeitsoptionen. |
| Private und lokale Anbindung | Die dedizierte Ausführung mit einem einzelnen Tenant unterstützt die Integration virtueller Netzwerke und private Endpunkte. Die hybride Bereitstellung führt Workflows auf kundenverwalteter Infrastruktur aus, wenn lokale Verarbeitung erforderlich ist. |
| Anwendungslebenszyklusverwaltung | Visual Studio Code-Entwicklung, lokale Tests, Infrastructure as Code und CI/CD trennen die Bereitstellung von Workflow-Anwendungen von der Infrastrukturbereitstellung. |
| Bereitstellungsoption | Verwenden Sie Workflow Service Plan für verwaltetes Azure-Hosting, App Service-Umgebung v3 für isoliertes Azure-Hosting oder Hybrid für kundenverwaltete Kubernetes-Umgebungen. |
Logic Apps Standard stellt die meisten Kernfunktionen bereit, die zur Modernisierung von BizTalk-Lösungen erforderlich sind, und dient als primäre Orchestrierungs- und Integrationsplattform für die Zielarchitektur, egal ob sie in Azure gehostet oder in einer hybriden Umgebung bereitgestellt wird. Andere Dienste sind standardmäßig nicht erforderlich. Für von Azure gehostete Lösungen fügen Sie Azure-Dienste wie Azure Service Bus, Azure API Management oder Azure Event Grid nur dann hinzu, wenn die refaktorierte Lösung unabhängiges Nachrichtenvermittlung, API-Lebenszyklusmanagement oder Ereignisverteilung erfordert. Für hybride Deployments verwenden Sie kompatible, kundenverwaltete Services für alle Fähigkeiten oder architektonischen Grenzen, die die Lösung außerhalb des Logic Apps Standard erfordert.
Gründe für die Migration
| Vorteil | BESCHREIBUNG |
|---|---|
| Moderne Integrationsplattform | Baue Workflows mit verwalteter Orchestrierung, Enterprise-Connectoren, B2B-Fähigkeiten, API-Integration sowie cloud-nativer Sicherheit und Überwachung. Bewerten Sie KI-unterstützte und agentische Automatisierung, wo sie unterstützt werden. |
| Bewahren Sie ausgewählte Investitionen | Verwenden oder passen Sie viele BizTalk-Schemata, Zuordnungen, Regeln, Assemblies und benutzerdefinierte .NET-Komponenten wieder an, anstatt jedes Artefakt neu zu erstellen. |
| Flexibles Hosting | Führen Sie Standard-Workflows in Azure aus oder verwenden Sie eine hybride Bereitstellung für lokale Verarbeitung, Netzwerkzugang, Datenaufenthalt oder regulatorische Anforderungen. |
| Low-Code- und Pro-Code-Entwicklung | Kombinieren Sie den visuellen Workflow-Designer mit quellengesteuerten Workflow-Definitionen, Inline-Skripten, lokalen .NET-Funktionen, benutzerdefinierten Connectors und externen Services. |
| Moderne Vorgänge | Verwenden Sie Azure rollenbasierte Zugriffskontrolle (Azure RBAC), Infrastruktur als Code und automatisierte Pipelines. Azure-gehostete Workflows integrieren sich mit Azure Monitor und Application Insights, während hybride Deployments OpenTelemetry verwenden und unterschiedliche Funktionseinschränkungen aufweisen. |
| Kostenkontrollen | Teilen Sie die Kapazität über verwandte Arbeitsabläufe hinweg, wählen Sie ein Hosting-Modell, das dem Workload-Bedarf entspricht, und nutzen Sie so weit wie möglich integrierte Operationen und lokale Funktionen. |
Bauen Sie eine kosteneffiziente Zielarchitektur
Die Kosteneffizienz hängt vom Arbeitsvolumen, der erforderlichen Isolation, der vorhandenen Infrastruktur, der Nutzung von Verbindern und den operativen Verantwortlichkeiten ab. Vergleichen Sie die Gesamtkosten des Besitzes und nicht nur die Hosting-Kosten von Logic Apps. Eine BizTalk-Basislinie kann BizTalk Server-, Windows Server- und SQL Server-Lizenzen; Rechenleistung und Speicher; hohe Verfügbarkeit und Notfallwiederherstellung; Patching; Überwachung; Bereitstellungswerkzeuge; sowie spezialisierte operative Unterstützung umfassen.
Verwenden Sie beim Erstellen des Zielkostenmodells folgende Praktiken:
- Gruppiere verwandte Arbeitsabläufe mit kompatiblen Sicherheits-, Lebenszyklus- und Skalierungsanforderungen in derselben Standard-Logik-App, damit sie reservierte Rechenleistungen und unterstützende Ressourcen teilen können. Halte die Arbeitslasten getrennt, wenn sie unabhängige Skalierung, Isolierung, Bereitstellung oder Eigentum benötigen.
- Bevorzugen Sie integrierte Connector-Operationen, wenn Sie Ihren Anforderungen entsprechen. Das Standardmodell umfasst unbegrenzte integrierte Operationsausführungen, während verwaltete Connector-Operationen pro Aufruf abgerechnet werden.
- Belassen Sie auf den Workflow beschränkten .NET-Code gegebenenfalls in lokalen Funktionen. Lokale Funktionen verwenden die Anwendungsgrenze des Logic Apps Standard und benötigen keine separate Function App, Endpunkt, Authentifizierungsfluss, Bereitstellungspipeline oder Überwachungsgrenze. Der Code verbraucht weiterhin Kapazität im Standard-Plan.
- Dimensionieren Sie die Kapazität des Workflow Service Plans bedarfsgerecht, und überprüfen Sie die Auslastung, wenn Migrationswellen in die Produktion übergehen. Der Plan wird auch dann für die reservierte Kapazität in Rechnung gestellt, wenn die Workflows inaktiv sind.
- Verwenden Sie App Service-Umgebung v3, wenn Anforderungen an Isolation, dediziertes Netzwerk, Compliance oder Konsolidierung einen Isolated v2 App Service Plan rechtfertigen. Gehe nicht davon aus, dass ASE v3 die kostengünstigste Option für kleinere Arbeitslasten ist.
- Verwenden Sie Hybrid, wenn lokale Ausführung, Datenresidenz oder bestehende Infrastruktur ausreichenden Mehrwert bieten. Beziehen Sie die Azure Arc-fähige Kubernetes-Umgebung, SQL Server-Lizenzen, SMB-Speicher, Netzwerke, Operationen und die vCPU-Nutzung von Logic Apps in die Berechnung ein.
- Berücksichtigen Sie Speicheroperationen, Integrationskonten, Netzwerke, Überwachung und die vorübergehenden Kosten für den parallelen Betrieb von BizTalk und Logic Apps während der Migration.
Für Preisinformationen siehe Azure Logic Apps Preis- und Abrechnungsmodelle sowie die Preisseite zu Azure Logic Apps.
Auswählen einer Hostingoption
Azure Logic Apps hat getrennte Verbrauchs- und Standard-Ressourcentypen. Für die BizTalk-Migration verwenden Sie die Standard-Funktionen von Azure Logic Apps und wählen Sie basierend auf Ihren Anforderungen eine Azure-gehostete oder hybride Hosting-Option.
Important
Wenn Sie derzeit Azure Logic Apps Consumption verwenden und planen, BizTalk Server-Workloads zu migrieren, müssen Sie auf Azure Logic Apps Standard migrieren. BizTalk-Migrationsfunktionen werden für Konsum-Workflows nicht unterstützt.
| Hostingoption | Beste Passform | Kosten und Eigentum | Wichtige Überlegungen |
|---|---|---|---|
| Workflowdienstplan | Die Standardwahl für Azure-gehostete BizTalk-Migrationen, die dedizierte Standardkapazität und verwaltete Azure-Funktionen benötigen. | Reservierte WS1-, WS2- oder WS3-Kapazität in einer von Microsoft verwalteten Umgebung. | Unterstützt mehrere Workflows pro Logik-App, die Integration in virtuelle Netzwerke, private Endpunkte und den Zugriff auf Azure-Überwachungsfunktionen. |
| App Service-Umgebung v3 | Workloads, die isoliertes Azure-Hosting, dediziertes Netzwerk, Compliance-Grenzen oder eine Konsolidierung mit anderen App-Service-Workloads erfordern. | Isolierte v2 App Service Plan-Instanzen in einer dedizierten Umgebung. | Erfordert eine bestehende oder neue ASE v3 und sollte durch Anforderungen an Isolierung, Skalierung oder Konsolidierung gerechtfertigt werden. |
| Hybrid | Workloads, die lokale Verarbeitung, latenzarmen Zugriff auf lokale Systeme, Datenresidenz, Bereitstellung am Edge oder kundenverwaltete Infrastruktur erfordern. | Logic Apps vCPU-Nutzung sowie kundenverwaltetes Kubernetes, SQL Server, SMB-Speicher, Netzwerke und Betrieb. | Verwendet Azure Arc-fähiges Kubernetes mit der Azure Container Apps-Erweiterung und benötigt ausgehende Azure-Konnektivität. Einige Cloud-Funktionen werden nicht unterstützt. |
Überlegungen zur hybriden Bereitstellung
Die hybride Bereitstellung ist teilweise verbunden, nicht luftspaltet. Die Umgebung benötigt ausgehende Konnektivität für Azure Arc- und Azure-Management-Operationen. Cloud-gehostete Managed Connectors erfordern ebenfalls eine Verbindung zu Azure. Vorübergehende Konnektivitätsunterbrechungen stoppen nicht zwangsläufig die lokale Workflow-Verarbeitung, können aber Management, Telemetrie und cloudabhängige Abläufe beeinträchtigen.
Für erforderliche Infrastruktur, unterstützte Konfigurationen, Preise und aktuelle Einschränkungen siehe Einrichten Ihrer eigenen Infrastruktur für Standard-Logik-Anwendungen mit hybrider Bereitstellung.
BizTalk-Funktionen Logic Apps zuordnen
BizTalk Server und Azure Logic Apps verwenden unterschiedliche Architekturen. Nutzen Sie den Migration Agent, um jede BizTalk-Anwendung zu inventarisieren, deren Artefakte und Integrationsmuster den Fähigkeiten von Logic Apps zuzuordnen und Komponenten zu identifizieren, die Sie wiederverwenden, refaktorisieren, ersetzen oder neu entwerfen müssen.
| BizTalk-Funktionalität | Modernisierungsweg von Logic Apps | Typische Beurteilung | Verwandte Leitfäden |
|---|---|---|---|
| Orchestrierungen | Zustandsbehaftete oder zustandslose Standard-Workflows | Refactore die Logik von Geschäftsprozessen in Workflows. | Erstellen Sie einen Standard-Workflow |
| Pipelines und Hilfscode | Workflow-Aktionen, .NET-lokale Funktionen, Inline-Code, benutzerdefinierte Connectors oder externe Dienste | Die Wiederverwendung oder Umgestaltung richtet sich nach dem erforderlichem Lebenszyklus und der Skalierungsgrenze. | Erstellen und ausführen Sie .NET-lokale Funktionen |
| MessageBox-Weiterleitung | Azure Service Bus-Themen und -Abonnements, RabbitMQ-Exchanges, Apache Kafka-Themen oder Workflow-Routing | Überarbeite die Nachrichten unabhängig vom Workflow-Runtime. | Service Bus-Warteschlangen, -Themen und -Abonnements |
| Schemas und Karten | Project-Artefakte, XSLT-Karten, Liquid-Vorlagen und Data Mapper | Kompatible Artefakte wiederverwenden und Transformationen validieren. | Schemata und Abbildungen |
| Geschäftsregeln | Azure Logic Apps-Regel-Engine | Unterstützte Richtlinien der BizTalk Business Rules Engine wiederverwenden oder nicht unterstützte Fakten umgestalten. | Übersicht über das Regelmodul in Azure Logic Apps |
| EDI und B2B | Standard-Workflows, Connectors und Integrationskonten | Bewerten Sie Partner, Vereinbarungen, Zertifikate, Schemata und Protokollanforderungen. | B2B-Unternehmensintegrationsworkflows |
| Adapter | Eingebaute, verwaltete oder benutzerdefinierte Connectoren und APIs | Bestätigen Sie die Verfügbarkeit des Connectors, die Authentifizierung, den Durchsatz und die Unterstützung für das Hosting. | Übersicht über Konnektoren |
| BAM | Azure-Nachverfolgung von Geschäftsprozessen für unterstützte, in Azure gehostete Lösungen oder ein externes Observability-Konzept | Neugestaltung für hybride Bereitstellung, bei der Azure Business Prozess Tracking nicht unterstützt wird. | Übersicht über Azure Business Prozess Tracking |
| Nachverfolgung und Überwachung | Ausführungsverlauf, nachverfolgte Eigenschaften, Azure Monitor, Application Insights und OpenTelemetry | Überarbeiten Sie das Betriebs- und Supportmodell. | Überwachen Sie Logik-Apps und -Workflows |
Das folgende Diagramm bietet eine weitere Ansicht der gängigen BizTalk Server-Fähigkeiten und ihrer von Azure gehosteten Modernisierungspfade:
Für detaillierte Funktionsverfügbarkeit siehe Azure Logic Apps Connectors, Enterprise Integration Overview und Azure Logic Apps Limits and Configuration.
Wichtige Überlegungen zur Migration
Architektur und Zuverlässigkeit
- Beginnen Sie mit Azure Logic Apps Standard als Zielanwendung. Verwenden Sie nativen Workflow-Funktionen, integrierte Connectors und lokale Funktionen, wo es angebracht ist, und fügen Sie andere Azure Integration Services nur dann hinzu, wenn eine spezifische architektonische Anforderung dies rechtfertigt.
- Für Publish-Subscribe-Muster verwenden Sie einen Nachrichtenbroker wie Azure Service Bus, RabbitMQ oder Apache Kafka, anstatt das BizTalk MessageBox innerhalb eines Workflows zu reproduzieren.
- Entwerfen Sie für Wiederholungen und mindestens einmalige Bearbeitung. Verwenden Sie Idempotenz, Deduplizierung und sichere Schreibvorgänge, um doppelte Effekte bei erneuten Operationen oder erneuten Einreichungen zu verhindern.
- Überprüfe die Grenzwerte für Nachrichten und Verbinder. Für große Nutzlasten verwenden Sie Connector-Chunking, wo es unterstützt wird, oder implementieren Sie das Claim-Check-Muster.
- Verwenden Sie VPN Gateway, ExpressRoute oder ein anderes hybrides Konnektivitätsdesign, um lokale Netzwerke mit Azure zu verbinden. Virtuelles Netzwerk-Peering verbindet virtuelle Azure-Netzwerke; es verbindet nicht allein ein On-Premises-Netzwerk mit Azure.
Benutzerdefinierter Code
Benutzerdefinierten Code in einer BizTalk-Lösung bedeutet nicht automatisch, dass die Zielarchitektur eine separate Azure Functions-Ressource benötigt. Verwenden Sie .NET-lokale Funktionen für Code, der zu einem Integrationsworkflow gehört. Lokale Funktionen befinden sich im selben Projekt wie die Workflows und laufen innerhalb der Anwendungsgrenze von Logic Apps Standard. Die Arbeitsabläufe, Connectors, Konfigurationen und Code können gemeinsam gebaut, bereitgestellt, skaliert und betrieben werden.
Lokale Funktionen eignen sich für workflow-gefasste Nachrichtenvalidierung, Anreicherung, Berechnungen, benutzerdefiniertes Parsing, Formatierung und geschäftsspezifische Verarbeitung. Sie können auch helfen, BizTalk-Hilfsassemblies, Orchestrationsprogramme und pipeline-nahe Logik zu modernisieren, wenn dieser Code zu einer bestimmten Integrationsanwendung gehört. Dieser Ansatz vermeidet die Einführung eines separaten Endpunkts, eines Authentifizierungsflusses, einer Hosting-Ressource, einer Bereitstellungspipeline und einer Überwachungsgrenze, um nur workflow-spezifischen Code auszuführen.
Verwenden Sie die folgende Anleitung, um das passende Code-Hosting-Modell auszuwählen:
| Lokale Funktionen verwenden, wenn | Verwenden Sie eine separate Azure Functions-Ressource, wenn |
|---|---|
| Der Code ist spezifisch für eine Logic Apps Standard-Anwendung. | Der Code wird von mehreren Anwendungen, Arbeitsabläufen oder Teams geteilt. |
| Der Code validiert, bereichert, parst, formatiert oder berechnet Daten innerhalb eines Workflows. | Der Code bietet eine unabhängig verwaltete API, einen Dienst oder eine ereignisgesteuerte Rechenfähigkeit. |
| Der Workflow und der Code sollten zusammen bereitgestellt, skaliert und betrieben werden. | Der Code erfordert eine unabhängige Skalierung, Versionierung, Bereitstellung oder operative Eigenverantwortung. |
| Der Code benötigt keinen separaten Netzwerkendpunkt oder Authentifizierungsgrenze. | Der Code muss seine eigene Endpunkt- oder Identitätsgrenze offenlegen und sichern. |
| BizTalk-Hilfslogik oder pipelinebezogene Logik ist Teil des migrierten Integrationsflusses. | Der Code ist die primäre Rechenarbeitslast, und der Logic Apps-Workflow ist nur ein Nutzer. |
Lokale Funktionen verbrauchen die Rechenkapazität, die der Standard-Logik-App zugewiesen ist, und ersetzen nicht jede eigenständige Funktion oder jeden Dienst. Ihr Kosten- und Betriebsvorteil ergibt sich daraus, eine unnötige Ressourcengrenze zu vermeiden, wenn der Code Teil des Workflows ist. Standard-Workflows unterstützen außerdem Inline-JavaScript, C# und PowerShell für kurzfristigen Code sowie benutzerdefinierte Connectors und Aufrufe zu externen APIs. Für architektonische Hinweise siehe Coding with Logic Apps Standard: Local Functions.
Sicherheit und Identität
Verwenden Sie Microsoft Entra ID, Azure RBAC, Azure Key Vault, private Netzwerke sowie sichere Eingaben und Ausgaben, um Workflows und Daten zu schützen. OAuth-Verbindungen verwenden tokenbasierte Autorisierung und erfordern möglicherweise interaktive Anmeldung und Zustimmung. Behandeln Sie OAuth nicht so, als würden Sie die E-Mail-Adresse und das Passwort eines Benutzers im Workflow speichern.
Für unterstützte Konnektoren in in Azure gehosteten Standard-Workflows machen verwaltete Identitäten es überflüssig, Zugangsdaten oder Zugriffstoken zu speichern. Während der lokalen Entwicklung kann die Azure Logic Apps Standard-Erweiterung die angemeldete Entwickleridentität über die Azure Identity-Credential-Kette verwenden, während der bereitgestellte Workflow seine system- oder benutzerzugewiesene verwaltete Identität verwendet. Beide Identitäten benötigen entsprechende Berechtigungen für die Zielressource. Diese Visual Studio Code-Funktion ändert nichts an der aktuellen hybriden Einschränkung für die Authentifizierung der verwalteten Identität bei Connector-Operationen. Weitere Informationen finden Sie unter Verwenden von Connectors mit verwalteter Identität in der Logic Apps Standard-Erweiterung.
Bereitstellung und Betrieb
Workflow-Definitionen, Konfigurationen und Artefakte in der Quellcodeverwaltung speichern und automatisierte Build- und Bereitstellungspipelines verwenden. Bicep wird in Azure Resource Manager-Vorlagen kompiliert. Terraform und Pulumi sind alternative Infrastructure-as-Code-Tools, die Azure-Ressourcen über ihre jeweiligen Anbieter verwalten.
Planen Sie Überwachung, Zugriffskontrolle, Umgebungskonfiguration, Notfallwiederherstellung und Zuständigkeiten für den Support vor der ersten Produktionsmigration. Sichere sensible Aktionsein- und -ausgaben, damit sie nicht im Laufverlauf oder in der Telemetrie erscheinen.
Nächste Schritte
Verwenden Sie einen iterativen Migrationsansatz für Bestandsabhängigkeiten, priorisieren Sie Workloads, validieren Sie Zieldesigns und veröffentlichen Sie in handhabbaren Wellen. Der Azure Logic Apps Migration Agent kann bei Entdeckung, Analyse, Planung, Umwandlung, Validierung und Bereitstellung helfen, während Sie die Kontrolle über Architektur- und Implementierungsentscheidungen behalten.