Ansätze für die Migration von BizTalk Server zu Azure Logic Apps
In diesem Leitfaden werden Migrationsstrategien und -ressourcen sowie Planungsüberlegungen und bewährte Methoden behandelt, die Ihnen helfen, erfolgreiche Migrationslösungen bereitzustellen.
Hinweis
Eine Migrationsübersicht und einen Leitfaden zur Auswahl von Diensten in Azure für Ihre Migration finden Sie in der folgenden Dokumentation:
Strategieoptionen
Im folgenden Abschnitt werden verschiedene Migrationsstrategien zusammen mit ihren Vor- und Nachteilen beschrieben:
Big Bang
„Big-Bang“- oder „Direct Changeover“ sind Ansätze, die viel Planung erfordern und für Organisationen, die mit Azure Logic Apps nicht vertraut sind oder große Systeme oder Lösungen migrieren müssen, nicht zu empfehlen sind. Wenn eine Organisation einen neuen Technologiestapel implementiert, ergeben sich häufig neue Erkenntnisse. Wenn Sie zu früh oder zu viel investieren, haben Sie nicht die Möglichkeit, von den gewonnenen Erkenntnissen zu profitieren und Anpassungen vorzunehmen, ohne erhebliche Überarbeitungen zu riskieren.
Bei diesem Ansatz kann es auch länger dauern, bis sich der Nutzen einstellt bzw. zunimmt. Wenn Sie bereits einige Migrationsaktivitäten abgeschlossen haben, diese aber aufgrund anderer anstehender oder laufender Arbeiten noch nicht in Produktion gegeben haben, generieren Ihre migrierten Artefakte keinen Mehrwert für Ihre Organisation.
Es wird empfohlen, diesen Ansatz nur zu erwägen, wenn Sie über kleine BizTalk-Workloads mit geringer Komplexität, Fachleute (SMEs), die Ihre BizTalk-Umgebung kennen, und direkte Zuordnungen zwischen den derzeit verwendeten BizTalk-Features und Azure Logic Apps verfügen. Erfahrung mit Azure Logic Apps reduziert die Risiken dieses Ansatzes auch erheblich.
Iterativ oder wellenbasiert (empfohlen)
Dieser Ansatz bietet Ihrer Organisation die Möglichkeit, schrittweise einen Mehrwert zu erzielen, und zwar früher, als es sonst der Fall wäre. Ihr Projektteam kann durch Retrospektiven frühzeitig mehr über den Technologiestapel erfahren. So können Sie beispielsweise eine vorhandene BizTalk-Schnittstelle oder ein Projekt für die Produktion bereitstellen und sich dann über die Anforderungen der Lösung informieren, die Verwaltung, Skalierbarkeit, Vorgänge und Überwachung umfassen. Nachdem Sie dieses Wissen erlangt haben, können Sie Sprints planen, um vorhandene Funktionen zu optimieren oder neue Muster einzuführen, die Sie anschließend bei Ihrer zukünftigen Arbeit verwenden können.
Unabhängig von Ihrem Ansatz sollten Sie, wenn Sie einen Wechsel zu Azure Logic Apps oder Azure im Allgemeinen planen, unbedingt ein Refactoring Ihrer BizTalk Server-Lösungen in serverlose oder cloudnative Lösungen in Betracht ziehen, bevor Sie Ihre Serverinfrastruktur außer Betrieb nehmen. Diese Entscheidung ist eine ausgezeichnete Strategie, wenn Ihre Organisation das Geschäft vollständig in die Cloud transformieren möchte.
BizTalk Server und Azure Logic Apps haben unterschiedliche Architekturen. Zum Weitermodernisieren Ihre Lösungen können Sie Azure-Integrationsdienste verwenden, um die Funktionen in Azure Logic Apps zu erweitern, die die wichtigsten Anforderungen an die Kundenintegration erfüllen.
Für eine höhere Rendite (ROI) empfehlen wir, dass jede BizTalk-Migration die nativen Kernfunktionen in Azure Logic Apps (Standard) so weit wie möglich nutzt und bei Bedarf mit anderen Azure-Integrationsdiensten erweitert wird. Diese Kombination ermöglicht zusätzliche Szenarien, z. B.:
- Cloudnative Hybridfunktionen mit Azure Logic Apps (Standard) mit Hybridbereitstellung
- Statusbehaftete oder statusfreie Workflowfunktionen in Azure Logic Apps (Standard)
- Native, integrierte (In-App-)Mainframe- und Midrange-Integration mit Connectors in Azure Logic Apps (Standard)
- Pub-Sub-Messaging mit Azure Service Bus
- Erweiterte SOAP-Funktionen in Azure API Management
Bereitstellen eines BizTalk-Migrationsprojekts
Um ein solches Projekt abzuschließen, empfehlen wir Ihnen, den iterativen oder wellenbasierten Ansatz zu befolgen und den Scrum-Prozess zu verwenden. Während Scrum kein Sprint-Zero-Konzept (Sprint 0) für Pre-Sprint-Aktivitäten enthält, empfehlen wir Ihnen, ihren ersten Sprint auf die Teamausrichtung und technische Ermittlung zu konzentrieren. Folgen Sie nach Sprint 0 der Ausführung mehrerer Migrations-Sprints und konzentrieren Sie sich auf die Freigabe von Features für ein Minimum Viable Product (MVP).
Sprint 0
Während dieses Sprints wird empfohlen, BizTalk Server-Umgebungsermittlung mit Wellenplanung auszuführen. Das Verständnis der Breite und Tiefe des Projekts ist für den Erfolg von entscheidender Bedeutung. Die folgende Liste enthält die während Sprint 0 zu behandelnden Bereiche:
| Bereich | Beschreibung |
|---|---|
| Ermittlung | Erfassen Sie Daten über alle Ihre Schnittstellen und Anwendungen, um die Anzahl der Schnittstellen und Anwendungen zu ermitteln, die Sie migrieren müssen. Außerdem müssen Sie jeder Schnittstelle oder jedem Prozess Komplexität zuweisen. Sammeln Sie während dieses Katalogisierungsprozesses die folgenden Informationen, um den Arbeit einen Rang zuzuweisen: – Verwendete Adapter – Verwendete BizTalk Server-Funktionen wie Geschäftsaktivitätsüberwachung, Geschäftsregel-Engine, EDI und so weiter – Benutzerdefinierter Code, z. B. Ausdrücke, Zuordnungen und Pipelinekomponenten – Nachrichtendurchsatz – Nachrichtengrößen – Abhängigkeiten Anwendungs- und Systemabhängigkeiten |
| Architektur | Erstellen Sie die allgemeine Architektur, die als Schwerpunkt für die Migration verwendet werden soll. Dieses Design enthält Elemente, die allgemeine funktionale und nicht funktionale Anforderungen erfüllen. |
| Definition des Minimum Viable Products (MVP) | Definieren Sie die ersten Wellenfeatures. Mit anderen Worten, die Prozesse, die nach Abschluss der ersten Welle Unterstützung benötigen. |
| Erster Migrationsworkload-Rückstand | Definieren Sie die ersten Wellenfeatures und ihre Arbeitselemente mit der technischen Ausarbeitung. |
Ermittlungstools
Um Ihnen bei der Migrationsermittlung zu helfen, können Sie das Befehlszeilentool Azure Integration Migrator verwenden, auch als BizTalk-Migrationstool bezeichnet, bei dem es sich um ein Open-Source-Projekt von Microsoft handelt. Dieses Tool verwendet einen phasenweisen Ansatz, mit dem Sie nützliche Erkenntnisse und Strategien für die Migration Ihrer Lösungen in die Cloud ermitteln können. Wir empfehlen die Verwendung des Migrationstools nur für die Ermittlung und Berichtsgenerierung. Möglicherweise sollten Sie auch andere Produkte für die Ermittlung von Partnern verwenden, die Lösungen in diesem Bereich bereitstellen.
Für eine weitere Möglichkeit zum Generieren eines Inventars mit BizTalk Server-Elementen können Sie den BizTalk-Dokumentierer verwenden, der von Mark Brimble entwickelt wird. Dieses Tool funktioniert mit BizTalk Server 2020, obwohl angegeben wird, dass nur BizTalk Server 2016 unterstützt wird.
Architektur
Während Azure Logic Apps Funktionen bietet, mit denen Sie BizTalk Server-Ressourcen wiederverwenden können, müssen Sie über ein modernes Architekturdesign verfügen, um die Vorteile modernerer Funktionen zu nutzen. Verwenden Sie aus funktionaler Sicht Ihre Geschäftslogik so weit wie möglich. Verwenden Sie aus Produktmodernisierungssicht Azure-Integrationsdienste so weit wie möglich. Für Qualitäts- und übergreifende Bedenken empfehlen wir, das Azure Well-Architected Frameworkzu verwenden.
Unter diesem Framework sind BizTalk-Migrationen unternehmenskritische Workloads. Dieser Begriff beschreibt Sammlungen von Anwendungsressourcen, die eine hohe Verfügbarkeit auf der Plattform erfordern, was bedeutet, dass sie immer verfügbar, betriebsbereit und resilient gegen Fehler sein müssen.
Um das Architekturdesign für Ihre BizTalk-Migration abzuschließen, befolgen Sie Designmethodik für unternehmenskritische Workloads in Azure. Überprüfen und verwenden Sie für eine anfängliche Architektur und Topologie die Referenzarchitektur, die in Einfache Unternehmensintegration in Azure im Azure Architecture Center beschrieben wird.
Um Ihre anfängliche Umgebung einzurichten, verwenden Sie den Zielzonenbeschleuniger der Azure-Integrationsdienste, der für das Erstellen und Bereitstellen einer Integrationsplattform mit einem typischen Design für die Zielzone des Unternehmens vorgesehen ist.
Definition des Minimum Viable Projects (MVP)
Ein MVP ist eine Produktversion, die gerade über genügend kundenfreundliche Features verfügt. Diese Version zeigt die Möglichkeiten des Produkts und das Potenzial, Kundenfeedback zu sammeln und die Arbeit fortzusetzen. Bei einer BizTalk-Migration spiegelt Ihre MVP-Definition die Iterationen, Wellen oder Gruppen von Sprints wider, die Sie benötigen, um Fortschritte in Richtung Arbeitsfeatures und Erfüllung der anfänglichen Integrationsworkloads zu machen.
Wir empfehlen, dass Ihre MVP-Definition die folgenden Geschäftsergebnisse enthält, die in der Scrum-Terminologie als Epics bezeichnet werden:
Geschäftsergebnisse (Epics)
- Was ist das Hauptziel, das Sie erreichen möchten?
- Welche Funktionen oder Features müssen Sie für diesen MVP in Angriff nehmen?
- Was sind die Geschäftsprozessflows? Diese Frage bietet die Möglichkeit, vorhandene Prozesse zu optimieren, die von BizTalk Server unterstützt werden.
- Was sind die Geschäftsentscheidungen, z. B. Geschäftsergebnisse, die sich auf das MVP auswirken, oder was ist die Verfügbarkeit der ESource?
Wir empfehlen, dass Ihr MVP die folgenden Prozesse im Geltungsbereich enthält, die in der Scrum-Terminologie als Features bezeichnet werden:
Prozesse im Geltungsbereich (Features)
| Funktion | Beschreibung |
|---|---|
| Allgemeine Systemfunktionalität | Sie können diese Informationen mithilfe der Ermittlungstools extrahieren und die Beschreibungen in Bezug auf Features ausdrücken. |
| Akteur*innen oder Personas | Verwenden Sie diese Informationen, um die von den unterstützten Szenarien des MVPs betroffenen Personen zu ermitteln. |
| Orchestrierungen | Sie können diese Informationen mithilfe der Ermittlungstools extrahieren. |
| Datenentitäten und Nachrichten | Diese Elemente bieten Ihnen die Möglichkeit, zu erfahren, ob Sie weitere Verbesserungen an den von der BizTalk Server-Umgebung ausgetauschten Daten einbeziehen können. |
| Datenzuordnungen | Die heutige Welt basiert auf JSON. BizTalk Server verwendet jedoch XML. Dieser Moment ist eine großartige Gelegenheit, das Datenformat und die Konvertierungsanforderungen für die neue Plattform festzulegen. |
| Geschäftsregeln | Diese datenorientierten Regeln bieten Ihnen die Möglichkeit, ihren Ansatz zu überdenken oder sie wiederzuverwenden, indem Sie Azure Logic Apps-Funktionen verwenden. |
| Datenschutzaspekte | Datenschutz muss ihre oberste Priorität sein. Sofern Ihre Kund*innen nicht das Hybridbereitstellungsmodell in Azure Logic Apps (Standard) auswählen, müssen Sie diesen Bereich in jeder Welle aufgrund potenzieller Änderungen der Bereitstellungsumgebung behandeln. |
| Überlegungen zu gesetzlichen Vorschriften | Dieser Aspekt ist relevanter, wenn Ihre Kund*innen nicht über cloudbasierte Workloads verfügen. |
| Entwerfen von "Schützen" | Sie müssen jedes Feature unter Berücksichtigung der Sicherheit entwerfen. |
| Vorgeschlagene Features für Koexistenz | Wenn Sie jede Welle liefern, haben Sie ein gewisses Maß an Koexistenz. Sie müssen diese Hybridarchitektur auf vorhandene Service Level Indicators (SLIs) und Service Level Objectives (SLOs) ausrichten. |
| Nicht funktionale Überlegungen | Geschäftsprozesse können unterschiedliche nicht funktionale Anforderungen haben. Nicht alles muss in Echtzeit geschehen. Umgekehrt ist nicht alles ein Stapelverarbeitungsvorgang. |
| Geschäftsmetriken | Eine optionale Gelegenheit zum Anzeigen des Fortschritts für die Migrationsarbeit. |
Sie möchten auch die verschiedenen Variablen außerhalb des Geltungsbereichs identifizieren und auflisten, die den Bereich Ihrer MVP-Arbeit beeinflussen, z. B.:
- Ressourcenverfügbarkeit
- Risiken
- Dokumentation
- Markteinführungszeit
Anfänglicher Backlog
Der anfängliche Backlog ist eine Reihe von User Storys, die Sie in Features gruppieren, um die Prozesse im Geltungsbereich für Ihre MVP zu erstellen. Mit anderen Worten, ein MVP wird durch Scrum-Elemente dargestellt, die als Epics, Features und User Storys bezeichnet werden. Im Idealfall umfasst jedes Epic eine Gruppe von BizTalk-Anwendungen oder BizTalk-Projekten. Sie können die einfache Regel verwenden, die einer BizTalk-Anwendung oder einem BizTalk-Projekt ein Feature zuordnet.
Angenommen, Sie haben beispielsweise ein BizTalk Server-Projekt mit einer Orchestrierung namens „LoanRequests“, die Kund*innen zum Anfordern von Bankkrediten verwenden. Sie haben also das folgende vorgeschlagene Feature und die folgende vorgeschlagene User Story:
Feature: Kreditverarbeitung
User Story: „Als Kund*in möchte ich einen Kreditantrag einreichen, damit die Bank Geld zu meinem sicheren Konto hinzufügen kann.“
Diese User Story, die derzeit als Implementierung in BizTalk Server vorhanden sein kann, hat die folgenden Aufgaben, um die Verwendung von Azure Logic Apps und Azure-Integrationsdiensten zu implementieren:
- Sammeln Sie wiederverwendbare Artefakte von BizTalk.
- Erstellen Sie einen Kreditanforderungsworkflow mit Azure Logic Apps.
- Konfigurieren Sie asynchrones Messaging mit Azure Service Bus oder IBM MQ.
- Zuordnen von JSON zu XML-Daten mithilfe eines Azure Logic Apps-Workflows.
- Passen Sie Azure-Integrationsdienste nach Bedarf für Messagingmuster an.
Das folgende Diagramm zeigt die vorgeschlagenen Dauern für Epics, Features, User Storys und Tasks, die User Storys unterteilen. Obwohl Implementierungsentscheidungen sich auf diese Dauer auswirken, gehen sie davon aus, dass Sie vorhandene BizTalk-Artefakte in Azure Logic Apps verwenden. Erstellen Sie Ihre Standardworkflows mithilfe der vordefinierten Workflowvorlagen so weit wie möglich.
Migrationswellen (Sprints)
Nachdem Ihr Team Sprint 0 abgeschlossen hat, sollten Sie eine klare Idee vom MVP haben, dass Sie erstellen. Eine Welle ist eine Reihe an Sprints. Ihr anfänglicher Backlog sollte Arbeitselemente enthalten, die dem nächsten Diagramm so weit wie möglich folgen:
Während einer Welle schließt Ihr Team die Aktivitäten zum Migrieren, Testen und Freigeben zur Produktion ab. Lassen Sie uns genauer untersuchen, was in jeder Welle geschieht.
Migrieren
Während jeder Welle konzentriert sich die Migration auf die vereinbarten User Storys. In der ersten Welle konzentriert sich Ihr Team auf den anfänglichen Backlog. Technologieentscheidungen müssen die Informationen in der Zuordnung der BizTalk Server-Features verwenden, die in Featureabgleich – Migrieren von BizTalk Services zu Azure Logic Apps beschrieben werden.
Das folgende Diagramm zeigt die Ereignisse, die während der Migrationswellen geschehen sollten:
| Schritt | Beschreibung |
|---|---|
| 1 | Entdecken Sie vorhandene BizTalk-Apps und -Schnittstellen. Obwohl sie in Sprint 0 eingeführt wurde, sollte diese Aktivität am Beginn jeder Welle geschehen. Kund*innen können möglicherweise weiterhin Änderungen an Ihrer BizTalk-Umgebung vornehmen. Ressourcen: - BizTalk-Migrationstool - BizTalk-Dokumentiertool |
| 2 | Richten Sie Ihre anfängliche Migrationsumgebung ein. Sie können den Zielzonenbeschleuniger der Azure-Integrationsdienste verwenden, bei dem es sich um ein Cloud Adoption Framework zum Erstellen und Bereitstellen einer Integrationsplattform handelt, die über ein typisches Design für die Zielzone des Unternehmens verfügt. Als Workloadbesitzer*in können Sie Ihren technischen Zielzustand sicher erreichen, indem Sie die bereitgestellten Architekturleitfäden und BizTalk-Migrationsressourcenverwenden. Eine Beispielarchitektur finden Sie unter Beispielmigrationsumgebung. |
| 3 | Erstellen und testen Sie Workflows der Standard-Logik-App, die in Azure Logic Apps mit einem einzelnen Mandanten entweder über das Azure-Portal oder Visual Studio Code mit der Erweiterung Azure Logic Apps (Standard) ausgeführt werden. Mit Visual Studio Code können Sie Ihr Logik-App-Projekt lokal mithilfe eines beliebigen Quellcodeverwaltungssystems entwickeln, testen und speichern. Weitere Informationen finden Sie in der folgenden Dokumentation: - Erstellen eines Beispiels für einen Workflow der Standard-Logik-App mithilfe des Azure-Portals - Erstellen eines Beispiels für einen Workflow der Standard-Logik-App mithilfe von Visual Studio Code Ein Diagramm, das eine Beispiel-Logik-App und -Verbindungen zeigt, finden Sie unter Beispielmigrationsumgebung. |
| 4 | Um jedoch alle Vorteile der einfachen und konsistenten Bereitstellung von Workflows Ihrer Standard-Logik-App in verschiedenen Umgebungen und Plattformen zu erzielen, müssen Sie auch Ihren Build- und Bereitstellungsprozess automatisieren. Die Erweiterung Azure Logic Apps (Standard) für Visual Studio Code bietet Tools zum Erstellen und Verwalten automatisierter Build- und Bereitstellungsprozesse mithilfe von Azure DevOps. Weitere Informationen finden Sie unter Automatisieren der Erstellung und Bereitstellung für Logik-App-Standardworkflows mit Azure DevOps. |
| 5 | Um unternehmenskritische Standard-Logik-Apps bereitzustellen, die auch während Updates oder Wartungen immer verfügbar und reaktionsfähig sind, aktivieren Sie die Bereitstellung ohne Downtime, indem Sie Bereitstellungsslots erstellen und verwenden. Ohne Downtime bedeutet, dass für Endbenutzer bei der Bereitstellung neuer Versionen Ihrer App keine Unterbrechung oder Downtime auftreten sollte. Weitere Informationen finden Sie unter Einrichten von Bereitstellungsslots zur Ermöglichung der Bereitstellung ohne Downtime in Azure Logic Apps |
Das folgende Diagramm zeigt ein Beispiel für eine anfängliche Migrationsumgebung mit einer Standard-Logik-App, die Workflows koordiniert, die mit APIs, Diensten, Hybridlösungen und lokalen Ressourcen kommunizieren:
Testen
Jede Welle verfügt über eigene Testaktivitäten, die in jeder User Story eingebettet sind. Wenn Sie shift-left testing verwenden möchten, stellen Sie sicher, dass Sie die folgenden Aufgaben ausführen:
Automatisieren Sie Ihre Tests.
Azure Logic Apps (Standard) bietet die Möglichkeit, automatisierte Tests durchzuführen. Die folgende Liste enthält weitere Informationen und Ressourcen, die kostenlos auf GitHub verfügbar sind:
Automatisierte Tests mit Azure Logic Apps (Standard) vom Azure Logic Apps-Team
Mit Azure Logic Apps (Standard) sind automatisierte Tests dank der zugrunde liegenden Architektur, die auf der Azure Functions-Runtime basiert und überall dort ausgeführt werden kann, wo Azure Functions ausgeführt werden kann, nicht mehr schwer durchzuführen. Sie können Tests für Workflows schreiben, die lokal oder in einer CI/CD-Pipeline ausgeführt werden. Weitere Informationen finden Sie im Beispielprojekt für das Azure Logic Apps Test Framework.
Dieses Testframework umfasst die folgenden Funktionen:
- Schreiben automatisierter Tests für End-to-End-Funktionen in Azure Logic Apps
- Durchführen differenzierter Validierungen auf den Workflowausführungs- und Aktionsebenen
- Einchecken von Tests in ein Git-Repository und Ausführung entweder lokal oder innerhalb von CI/CD-Pipelines
- Simulieren von Testfunktionen für HTTP-Aktionen und Azure-Konnektoren
- Konfigurieren von Tests zur Verwendung anderer Einstellungswerte als in der Produktion
Integrationsplaybook: Standardtests für Logic Apps von Michael Stephenson, Microsoft MVP
Das Testframework des Integrationsplaybooks baut auf dem von Microsoft bereitgestellten Testframework auf und unterstützt zusätzliche Szenarien:
- Herstellen einer Verbindung mit einem Workflow in einer Standard-Logik-App
- Abrufen der Rückruf-URL, damit Sie den Workflow in einem Test auslösen können
- Überprüfen der Ergebnisse der Workflowausführung
- Überprüfen der Vorgangseingaben und -ausgaben im Ausführungsverlauf des Workflows
- Einfügen automatisierter Testframeworks, die Logik-App-Entwickler möglicherweise verwenden
- Einfügen von SpecFlow, um die verhaltensgesteuerte Entwicklung (BDD) für Logik-Apps zu unterstützen
Unabhängig davon, welche Automatisierungsansätze oder -ressourcen Sie verwenden, sind Sie auf dem besten Weg, wiederholbare, konsistente und automatisierte Integrationstests durchzuführen.
Richten Sie Pseudotests für simulierte Antworten mithilfe statischer Ergebnisse ein.
Unabhängig davon, ob Sie automatisierte Tests einrichten, können Sie die Funktion für statische Ergebnisse in Azure Logic Apps verwenden, um vorübergehend simulierte Antworten auf der Aktionsebene festzulegen. Mit dieser Funktionalität können Sie das Verhalten eines bestimmten Systems emulieren, das Sie aufrufen möchten. Sie können dann einige erste Tests isoliert durchführen und die Datenmenge reduzieren, die Sie in Branchensystemen erstellen würden.
Führen Sie parallele Tests aus.
Im Idealfall verfügen Sie bereits über Baseline-Integrationstests für Ihre BizTalk Server-Umgebung und etablierte automatisierte Tests für Azure Logic Apps. Sie können dann die Tests parallel ausführen, um Ihre Schnittstellen mit denselben Datensätzen zu überprüfen und die Genauigkeit der Tests insgesamt zu verbessern.
Freigabe zur Produktion
Erwägen Sie, nachdem Ihr Team fertig ist und die „Definition of Done“ für die User Storys erfüllt, die folgenden Aufgaben:
Erstellen Sie einen Kommunikationsplan für Ihre Freigabe zur Produktion.
Erstellen Sie einen Übernahmeplan.
Ein Übernahmeplan umfasst die Details zu den Aufgaben und Aktivitäten, die für den Wechsel von der aktuellen Plattform zur neuen Plattform erforderlich sind, einschließlich der Schritte, die Ihr Team auszuführen plant. Schließen Sie die folgenden Überlegungen in Ihren Übernahmeplan ein:
- Erforderliche Schritte
- Generalprobe
- Personen
- Planen von Schätzungen
- Deaktivieren von Schnittstellen auf der alten Plattform
- Aktivieren von Schnittstellen auf der neuen Plattform
- Validierungstests
Legen Sie einen Zurücksetzungsplan fest.
Führen Sie Validierungstests aus.
Planen Sie Support für den Betrieb oder die Produktion.
Wählen Sie „Go oder No-Go“-Kriterien für die Freigabe in die Produktion.
Feiern Sie den Erfolg Ihres Teams.
Halten Sie eine Retrospektive ab.
Bewährte Methoden für eine BizTalk-Migration
Auch wenn die bewährten Methoden von Organisation zu Organisation variieren können, sollten Sie sich bewusst um Konsistenz bemühen, um unnötigen Aufwand, der „das Rad neu erfindet“, und die Redundanz ähnlicher gängiger Komponenten zu vermeiden. Wenn Sie die Wiederverwendbarkeit fördern, kann Ihre Organisation schneller Schnittstellen erstellen, die einfacher zu unterstützen sind. Die Zeit bis zur Markteinführung ist ein wichtiger Faktor für die digitale Transformation, daher hat das Verringern unnötiger Reibungspunkte für Entwickler und Supportteams oberste Priorität.
Wenn Sie Ihre eigenen bewährten Methoden festlegen, sollten Sie sich an folgendem Leitfaden orientieren:
Allgemeine Namenskonventionen für Azure-Ressourcen
Achten Sie darauf, gute Namenskonventionen für alle Azure-Ressourcen – von Ressourcengruppen bis hin zu den einzelnen Ressourcentypen – einzurichten und konsequent anzuwenden. Um eine solide Grundlage für die Auffindbarkeit und Supportfähigkeit zu schaffen, vermittelt eine gute Namenskonvention den Zweck. Der wichtigste Punkt bei Namenskonventionen ist, dass Sie sie haben und dass Ihre Organisation sie versteht. Jede Organisation hat Nuancen, die sie berücksichtigen muss.
Einen Leitfaden zu dieser Vorgehensweise finden Sie in den folgenden Microsoft-Empfehlungen und -Ressourcen:
- Abkürzungsbeispiele für Azure-Ressourcen
- Das Azure Naming Tool, welches mit Azure kompatible Namen generiert, hilft Ihnen bei der Standardisierung von Namen und automatisiert Ihren Benennungsprozess.
Namenskonventionen für Azure Logic Apps-Ressourcen
Der Entwurf für Ihre Logik-App und Ihren Workflow ist ein wichtiger Ausgangspunkt, da dieser Bereich den Entwicklern die Flexibilität bietet, eindeutige Namen zu erstellen.
Namen von Logik-App-Ressourcen
Zur Unterscheidung zwischen Verbrauchs- und Standard-Logik-App-Ressourcen können Sie unterschiedliche Abkürzungen verwenden, z. B.
- Verbrauch: LAVerb
- Standard: LAStd
Aus organisatorischer Sicht könnten Sie ein Benennungsmuster entwerfen, das die Geschäftseinheit, die Abteilung, die Anwendung und optional die Bereitstellungsumgebung enthält, z. B. DEV, UAT, PROD usw.
LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>
Angenommen, Sie haben eine Standard-Logik-App in der Entwicklung, die Workflows für die Personalabteilung in der Geschäftseinheit „Corporate Services“ implementiert. Sie können der Logik-App-Ressource den Namen LAStd-CorporateServices-HR-DEV geben und die Pascal-Schreibweise verwenden, sofern dies aus Konsistenzgründen angebracht ist.
Namen von Logik-App-Workflows
Die Ressource einer verbrauchsbasierten Logik-App wird immer nur einem Workflow zugeordnet, sodass Sie nur einen einzigen Namen benötigen. Eine Standard-Logik-App-Ressource kann mehrere Workflows enthalten. Entwerfen Sie daher eine Namenskonvention, die Sie auch auf Memberworkflows anwenden können. Erwägen Sie für diese Workflows eine Namenskonvention auf der Grundlage des Prozessnamens, zum Beispiel:
Process-<*process-name*>
Wenn Sie also einen Workflow haben, der Aufgaben zum Onboarding von Mitarbeitern implementiert, z. B. die Erstellung eines Mitarbeiterdatensatzes, könnten Sie den Workflow Prozess-MitarbeiterOnboarding nennen.
Hier finden Sie weitere Überlegungen zum Entwerfen Ihrer Namenskonvention für Workflows:
- Folgen Sie dem Übergeordnet-Untergeordnet-Muster für Workflows, wenn Sie eine Beziehung zwischen einem oder mehreren Workflows hervorheben möchten.
- Berücksichtigen Sie, ob ein Workflow eine Nachricht veröffentlicht oder nutzt.
Namen von Workflowvorgängen
Wenn Sie Ihrem Workflow einen Auslöser oder eine Aktion hinzufügen, weist der Designer automatisch den allgemeinen Standardnamen für diesen Vorgang zu. Da Vorgangsnamen jedoch innerhalb Ihres Workflows eindeutig sein müssen, fügt der Designer an nachfolgende Vorgangsinstanzen fortlaufende numerische Suffixe an, was die Lesbarkeit und die Entschlüsselung der ursprünglichen Absicht des Entwicklers erschwert.
Um die Namen von Vorgängen aussagekräftiger und verständlicher zu machen, können Sie nach dem Standardtext eine kurze Aufgabenbeschreibung hinzufügen und aus Gründen der Konsistenz die Pascal-Schreibweise verwenden. Für die Aktion „JSON parsen“ können Sie zum Beispiel einen Namen wie JSON parsen-MitarbeiterdatensatzÄndern verwenden. Mit diesem oder einem ähnlichen Ansatz werden Sie sich weiterhin daran erinnern, dass es sich bei der Aktion um JSON parsen und den spezifischen Zweck der Aktion handelt. Wenn Sie also die Ergebnisse dieser Aktion später in nachgeschalteten Workflow-Aktionen verwenden müssen, können Sie diese Ergebnisse leichter identifizieren und finden.
Hinweis
Organisationen, die häufig Ausdrücke verwenden, sollten eine Namenskonvention in Betracht ziehen, die die Verwendung von Leerzeichen („ “) nicht fördert. Die Ausdruckssprache in Azure Logic Apps ersetzt Leerzeichen durch Unterstriche („_“), was die Erstellung von Ausdrücken erschweren kann. Indem Sie Leerzeichen von vornherein vermeiden, tragen Sie dazu bei, Probleme bei der Erstellung von Ausdrücken zu verringern. Verwenden Sie stattdessen einen Gedankenstrich oder Bindestrich („-“), der die Lesbarkeit verbessert und die Erstellung von Ausdrücken nicht beeinträchtigt.
Um spätere Überarbeitungen und Probleme mit nachgelagerten Abhängigkeiten zu vermeiden, die bei der Verwendung von Vorgangsausgaben erstellt werden, benennen Sie Ihre Vorgänge sofort um, wenn Sie sie Ihrem Workflow hinzufügen. In der Regel werden nachgelagerte Aktionen automatisch aktualisiert, wenn Sie einen Vorgang umbenennen. Azure Logic Apps benennt jedoch nicht automatisch benutzerdefinierte Ausdrücke um, die Sie erstellt haben, bevor Sie die Umbenennung ausführen.
Namen von Verbindungen
Wenn Sie eine Verbindung in Ihrem Workflow erstellen, erhält die zugrundeliegende Verbindungsressource automatisch einen generischen Namen, z. B. sql oder office365. Wie die Namen der Vorgänge müssen auch die Verbindungsnamen eindeutig sein. Nachfolgende Verbindungen desselben Typs erhalten ein fortlaufendes numerisches Suffix, z. B. sql-1, sql-2 und so weiter. Solche Namen stellen keinen Kontext bereit, der die Unterscheidung und Zuordnungsverbindungen zu ihren Workflows äußerst schwierig macht, insbesondere für Entwickler*innen, die den Lösungsbereich nicht kennen und diese Workflows verwalten müssen.
Daher sind aussagekräftige und konsistente Verbindungsnamen aus den folgenden Gründen wichtig:
- Lesbarkeit
- Einfachere(r) Wissenstransfer und Unterstützbarkeit
- Governance
Auch hier ist eine Namenskonvention wichtig, obwohl das Format nicht übermäßig wichtig ist. Sie können beispielsweise das folgende Muster als Richtlinie verwenden:
CN-<*connector-name*>-<*logic-app-or-workflow-name*>
Als konkretes Beispiel können Sie eine Service Bus-Verbindung in einem OrderQueue-Logik-App-Workflow mit CN-ServiceBus-OrderQueue als neuen Namen umbenennen. Weitere Informationen finden Sie im Blogbeitrag Turbo360 (früher Serverless360) Bewährte Methoden für Logik-App, Tipps und Tricks: #11 Konnektor Benennungskonvention.
Behandeln von Ausnahmen mit Bereichen und „Ausführen nach“-Optionen
Bereiche bieten die Möglichkeit, mehrere Aktionen zu gruppieren, sodass Sie das Try-Catch-Finally-Verhalten implementieren können. Im Designer können Sie den Inhalt eines Bereichs reduzieren und erweitern, um die Produktivität der Entwickler zu verbessern.
Wenn Sie dieses Muster implementieren, können Sie auch angeben, wann die Bereichsaktion und die darin enthaltenen Aktionen ausgeführt werden sollen, und zwar auf der Grundlage des Ausführungsstatus der vorhergehenden Aktion, der Succeeded (Erfolgreich), Failed (Fehlgeschlagen), Skipped (Übersprungen) oder TimedOut (Zeitüberschreitung) sein kann. Verwenden Sie zum Einrichten dieses Verhaltens die Optionen Ausführen nach (runAfter) der Bereichsaktion:
- Ist erfolgreich
- Ist fehlgeschlagen
- Ist übersprungen
- Hat Zeit überschritten
Konsolidieren gemeinsam genutzter Dienste
Wenn Sie Integrationslösungen entwickeln, sollten Sie die Erstellung und Verwendung freigegebener Dienste für gängige Aufgaben in Betracht ziehen. Sie können Ihr Team eine Sammlung von freigegebenen Diensten erstellen und bereitstellen lassen, die Ihr Projektteam und andere nutzen können. Alle Beteiligten profitieren von höherer Produktivität, Einheitlichkeit und der Möglichkeit, die Governance für die Lösungen Ihrer Organisation durchzusetzen. In den folgenden Abschnitten werden einige Bereiche beschrieben, in denen Sie die Einführung freigegebener Dienste in Betracht ziehen könnten:
| Freigegebener Dienst | Ursachen |
|---|---|
| Zentralisierte Protokollierung | Stellen Sie allgemeine Muster bereit, wie Entwickler ihren Code mit entsprechender Protokollierung instrumentieren. Anschließend können Sie Diagnoseansichten einrichten, mit denen Sie die Integrität und Unterstützbarkeit von Schnittstellen ermitteln können. |
| Geschäftsnachverfolgung und Überwachung von Geschäftsaktivitäten | Erfassen Sie Daten und machen Sie sie verfügbar, damit Experten den Status ihrer Geschäftstransaktionen besser verstehen und selbst analytische Abfragen durchführen können. |
| Konfigurationsdaten | Trennen Sie Ihre Anwendungskonfigurationsdaten von Ihrem Code, damit Sie Ihre Anwendung einfacher zwischen Umgebungen verschieben können. Achten Sie darauf, einen einheitlichen, konsistenten und leicht reproduzierbaren Ansatz für den Zugriff auf Konfigurationsdaten bereitzustellen, damit sich die Projektteams auf die Lösung des Geschäftsproblems konzentrieren können, anstatt Zeit auf die Anwendungskonfigurationen für die Bereitstellung zu verwenden. Andernfalls können Sie nicht von Skaleneffekten profitieren, wenn jedes Projekt diese Trennung auf seine eigene Art und Weise vornimmt. |
| Benutzerdefinierte Connectors | Erstellen Sie benutzerdefinierte Konnektoren für interne Systeme ohne vordefinierte Konnektoren in Azure Logic Apps, um die Arbeit Ihres Projektteams und anderer zu vereinfachen. |
| Allgemeine Datasets oder Datenfeeds | Stellen Sie allgemeine Datasets und Feeds als APIs oder Konnektoren zur Verfügung, damit Projektteams sie nutzen können und das Rad nicht neu erfinden müssen. Jede Organisation verfügt über allgemeine Datasets, die sie benötigen, um Systeme in eine Unternehmensumgebung zu integrieren. |
Nächste Schritte
Sie haben nun mehr über verfügbare Migrationsansätze und bewährten Methoden zum Verschieben von BizTalk Server-Workloads zu Azure Logic Apps erfahren. Um detailliertes Feedback zu diesem Leitfaden zu geben, können Sie das folgende Formular verwenden: