Migrationsansätze für BizTalk Server zu Azure Integration Services
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:
Lift & Shift
In Azure Marketplace finden Sie die Option zum Bereitstellen virtueller Computer, die BizTalk-Lizenzierung mit dem nutzungsbasierten Bezahlungsmodell enthalten. Dieses Angebot bietet den Vorteil der Nutzung der Infrastructure-as-a-Service-Funktionen (IaaS) von Microsoft über ein verbrauchsbasiertes Preismodell. Die Verwendung dieser VMs kann zwar einige Herausforderungen bei der Verwaltung der BizTalk Server-Infrastruktur verringern, dieser Ansatz berücksichtigt jedoch nicht die Zeitpläne und Fristen des Supportlebenszyklus für BizTalk Server.
Da Organisationen die digitale Transformation durch den Umstieg auf oder die Einführung in die Cloud nutzen, haben viele die gemeinsamen Aufgaben, ihre VMware-, Hyper-V- oder physische Serverinfrastruktur einzustellen und diese Funktionalität zu IaaS in Azure zu migrieren. Diese Entscheidung trägt dazu bei, die zuvor genannten Herausforderungen zu verringern, betrifft aber nicht die BizTalk-Codebasis.
Mit BizTalk Server 2013 und höher können Sie Ihre BizTalk-Server wie zuvor lokal oder auf einem virtuellen Server in Azure ausführen. Die Ausführung Ihrer BizTalk Server-Umgebung in der Cloud bietet die folgenden Vorteile:
- Sie benötigen keine eigene Hardware oder Infrastruktur, daher keine Hardwarewartung.
- Erhöhte Verfügbarkeit für Ihre Serverinfrastruktur, die mehrere Rechenzentren umfassen kann oder in Verfügbarkeitszonen repliziert werden kann.
- Greifen Sie von überall aus über das Internet auf Ihre Server zu.
- Microsoft sichert Ihre Images.
- Schnelle Bereitstellung für neue Server mit integrierten Images, die in Azure Marketplace verfügbar sind.
- Schnelles Hochskalieren für Ihre Server durch Ändern der VM-Größen, um Arbeitsspeicher und CPU hinzuzufügen, Festplatten hinzuzufügen usw.
- Verbesserte Sicherheit für Ihre Umgebung durch Azure Security Center. Dieser Dienst identifiziert Sicherheitsbedrohungen und bietet Ihnen einen Untersuchungspfad, wenn Sicherheitsvorfälle auftreten.
Hybridintegration
Obwohl sich BizTalk Server- und Azure Integration Services-Funktionen überschneiden, funktionieren sie besser, wenn Sie sie gemeinsam verwenden. Die meisten Organisationen, die nicht ihre gesamte Infrastruktur in die Cloud verschieben, haben hauptsächlich die folgenden Gründe:
- Unternehmensrichtlinien
- Länderspezifische/regionale Richtlinien
- Branchenspezifische Richtlinien
Außerdem sind nicht alle Funktionen oder Anwendungen in der Cloud vorhanden, oder einige verfügbare Funktionen sind möglicherweise nicht so stabil wie die lokalen Versionen. Um jedoch mit der Cloudrevolution Schritt zu halten und die Geschäftsfunktionen zu erweitern, nutzen viele Organisationen zunächst SaaS-Angebote zusammen mit ihren lokalen Systemen. Viele Geschäftsprozesse können von cloudbasierten Entwicklungs- und Implementierungsstrategien profitieren.
Durch die Einführung einer Hybridintegrationsstrategie können Sie weiterhin von den Technologieinvestitionen in die Systeme profitieren, von denen Ihre Organisation abhängig ist, aber dennoch von neuen Funktionen, verbesserter Leistung und geringerer Kostenstruktur cloudbasierter Anwendungen wie Azure profitieren.
Mit BizTalk Server 2016 bot ihnen das separate Release von Microsoft BizTalk Server Adapter für Logic Apps die Möglichkeit, einen Teil Ihrer Integrationslogik als Dienst in Azure zu implementieren, indem Azure Logic Apps zum Verbinden von Hunderten von Clouddiensten genutzt wird. Dieser Adapter hat sowohl bei lokalen Integrationen als auch bei Hybridintegrationen geholfen, indem er die folgenden Funktionen bietet:
Integrieren von Clouddiensten mit BizTalk Server mithilfe integrierter Adapter wie Azure Logic Apps, Azure Service Bus, Azure Event Hubs, Azure Blob Storage und Office 365 Mail, Zeitplan und Kontakte
Verwenden des BizTalk Server-Connector in Azure Logic Apps, um eine Verbindung zwischen Azure Logic Apps und BizTalk Server herzustellen
Veröffentlichen von BizTalk Server-Endpunkten mithilfe von Azure API Management, damit Organisationen Endpunkte für interne Entwickler und externe Partner verfügbar machen können
Bei BizTalk Server 2020 umfasste die Installation automatisch den Adapter für Azure Logic Apps zusammen mit den integrierten Adaptern für die einfache Verbindung mit der Cloudumgebung.
Big Bang
Ein „Big-Bang“-Ansatz erfordert viel Planung und ist für Organisationen, die mit Azure Logic Apps nicht vertraut sind oder große Systeme oder Lösungen zu migrieren haben, nicht zu empfehlen. 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.
Iterativ (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 Integration Services 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.
Planen der Migration
Der folgende Abschnitt enthält Leitfäden zur Planung der Migration und zu den zu berücksichtigenden Bereichen.
Bereitschaftsplanung
Bereitschaft stellt einen wichtigen Teil Ihres Planungsprozesses dar. Wenn Sie den Umfang und die Tiefe Ihres Projekts verstehen, verbessert sich die Vorhersagbarkeit in mehreren Dimensionen, wie z. B. Kosten, Komplexität, Zeitrahmen und Gesamterfolg Ihres Projekts. Die folgende Liste enthält bestimmte Bereiche, die im Rahmen der Projektcharta geprüft und berücksichtigt werden sollten.
| Bereich | BESCHREIBUNG |
|---|---|
| Inventarisierung | Erfassen Sie Daten über alle Ihre Schnittstellen und Anwendungen, um die Anzahl der Schnittstellen und Anwendungen zu ermitteln, die Sie migrieren müssen. Sammeln Sie während dieses Katalogisierungsprozesses die folgenden Informationen, um den Kontext zu ermitteln: – 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 |
| Komplexität | Um den Grad der Komplexität Ihrer Schnittstellen zu ermitteln, untersuchen Sie die Arten von Geschäftsregeln in diesen Schnittstellen und die technischen Anforderungen, die angepasst werden müssen, um ihre Bedürfnisse oder Leistungsanforderungen zu erfüllen. |
| Wert | Beurteilen Sie den Wert Ihrer Schnittstellen, damit Sie die Priorität für die Neuimplementierung von Schnittstellen festlegen können. Es kann zwar sinnvoll sein, mit Schnittstellen mit geringem Risiko zu beginnen, aber nachdem Sie sich mit Azure Integration Services vertraut gemacht haben, sollten Sie sich zunächst auf die Arbeit mit dem höchsten Wert konzentrieren. |
| Kosten | Legen Sie den Projektumfang fest und schätzen Sie die Kosten, denn ein Migrationsprojekt erfordert Kapital, um mit der Durchführung zu beginnen. Sichern Sie das Projektbudget, sei es durch Kapital- oder Betriebsbudgetplanung, und verwalten Sie den Projektumfang während der Durchführung. |
| Anwendungs- und Systemabhängigkeiten | Ermitteln und berücksichtigen Sie diese Abhängigkeiten bereits bei der Projektplanung, damit Sie bei der Projektdurchführung keine Überraschungen erleben. |
| Risikoregistrierung | Erstellen und verwenden Sie dieses Artefakt, um alle Risiken zu ermitteln und zu verfolgen, die bei der Projektplanung auftauchen. Wenn Sie die Risiken verstehen, können Sie sie proaktiv entschärfen und der Leitung mitteilen. Außerdem können Sie Hindernisse frühzeitig aus dem Weg räumen, wenn deren Beseitigung weniger kostspielig ist. |
Migrationstools
Das Befehlszeilentool „Azure Integration Migrator“, auch BizTalk Migration-Tool genannt, ist ein Open-Source-Projekt von Microsoft, das Sie bei der Planung und Ausführung Ihres Migrationsprojekts sowie beim Verschieben von BizTalk Server-Anwendungen zu Azure Integration Services unterstützen kann. Sie können dieses Tool auch verwenden, um nützliche Erkenntnisse und Strategien für die Migration Ihrer Lösungen in die Cloud zu gewinnen.
Dieses Tool durchläuft die folgenden Phasen:
Entdecken
Pullt BizTalk Server Ressourcen und identifiziert die zu migrierenden BizTalk-Artefakte. Liest die Assemblys und Bindungsdateiinformationen.
Anforderungen: Die MSI für die Biztalk Server-Anwendung und alle BizTalk Server-Anwendungen, auf die verwiesen wird
Parse
Liest die BizTalk Server-Artefakte und erstellt ein Quelldatenmodell für die BizTalk Server-Anwendung.
Analysieren
Erstellt ein Azure Integration Services-Zieldatenmodell mithilfe des Quelldatenmodells aus der Phase „Parsen“. Grundsätzlich überprüft das Tool die BizTalk Server-Ressourcen, identifiziert, welche Elemente migriert werden können, und erstellt ein Datenmodell des Azure Integration Services-Ziels.
Report
Generiert einen Bericht, in dem die gefundenen BizTalk Server-Ressourcen und die Elemente, die migriert werden können, aufgeführt sind. Der Bericht enthält auch detaillierte Informationen über die Inhalte in den Quell- und Zielanwendungen sowie Details über mögliche Probleme bei der Konvertierung.
Konvertieren
Generiert Azure Resource Manager-Vorlagen und Azure-CLI-Skripte, die Sie verwenden können, um die Anwendungen in Azure unter Verwendung des Zieldatenmodells zu erstellen.
Überprüfen
Diese Phase ist derzeit nicht in das Tool integriert, aber Sie führen die Installationsskripts aus, um Ihre Anwendung in Azure bereitzustellen. Anschließend können Sie beurteilen, ob die generierte Anwendung dieselbe Funktionalität bietet wie Ihre lokale BizTalk Server-Anwendung.
Das folgende Diagramm zeigt die Phasen, die das Azure Integration Migrator-Tool durchläuft:
Wichtige Teamrollen und Fertigkeiten für eine erfolgreiche Migration
Für eine erfolgreiche Migration von Integrationsworkflows von BizTalk Server zu Azure Integration Services sollten Sie ein Team zusammenstellen, das über die folgenden wichtigen Rollen und Fertigkeiten verfügt, die mehrere Disziplinen umfassen:
| Rolle | Fähigkeiten |
|---|---|
| Projektmanager | Verantwortlich für die Leitung des Gesamtprojekts und die Einhaltung des vereinbarten Projektumfangs innerhalb der Zeit- und Budgetvorgaben. |
| Scrum-Leiter | Verwaltet aktiv den Rückstand und unterstützt die Priorisierung der Projektaktivitäten. |
| Architekten | Stellen sicher, dass das Projekt an Prinzipien der Unternehmensarchitektur ausgerichtet ist, und geben Hinweise zum Umgang mit Unsicherheiten und Hindernissen. |
| Entwickler | Arbeiten aktiv an der Migration von Komponenten von BizTalk Server zu Azure Integration Services. |
| Qualitätssicherungstester | Erstellen Testpläne und führen Tests für diese Pläne aus. Verfolgen, kommunizieren und selektieren Fehler im Rahmen der Projektsprintplanung. |
| Benutzerakzeptanztester (UAT) | Stellen die Projektbeteiligten zur Verfügung, die sicherstellen, dass bei der Umstellung von Schnittstellen von einer vorhandenen Plattform auf eine neue Plattform keine Regression erfolgt. |
| Change Management-Spezialisten | Bewerten die Auswirkungen auf vorhandene Prozesse und Rollen. Erstellen einen Plan, um wahrgenommene Probleme zu entschärfen, bevor sie auftreten. |
Um einige oder alle der zuvor beschriebenen Ressourcen bereitzustellen, sollten Sie Partner in Betracht ziehen, die Erfahrung mit der Durchführung von Migrationen haben. Als Teammitglieder können sie dazu beitragen, das Risiko zu verringern, die Markteinführung zu beschleunigen und das Projekt mit ihren Fertigkeiten und ihrem Fachwissen berechenbarer zu machen.
Buildprozessplanung
Für die Buildplanung empfiehlt Microsoft, Sprints und Arbeitselemente für grundlegende Dienste wie Authentifizierung, Protokollierung, Ausnahmebehandlung usw. einzubeziehen. Diese Einbeziehung hilft, spätere Nacharbeiten in den Entwicklungszyklen zu vermeiden, die dadurch entstehen, dass grundlegende Anforderungen nicht berücksichtigt werden. Außerdem möchten Sie vermeiden, dass Entwickler aufgrund von Entscheidungen, die andere Beteiligte treffen müssen, blockiert werden.
Die folgende Liste umfasst nur einige Bereiche, die berücksichtigt werden sollten:
| Bereich | BESCHREIBUNG |
|---|---|
| Authentifizierung | Beantworten Sie die folgenden und andere Fragen zur Authentifizierung, bevor Sie zu tief in die Entwicklungszyklen einsteigen. – Gibt es in Ihrer Organisation Standards für Authentifizierungsverfahren? – Können Sie verwaltete Identitäten und Dienstprinzipale in Azure verwenden? – Sind Standardauthentifizierungs- und API-Schlüssel zulässig oder nicht? Diese Aktivität kann eine gute Gelegenheit sein, Ihre Unternehmensarchitekten einzubringen, die sicherstellen können, dass klare Vereinbarungen über die zu verwendenden Authentifizierungsschemata getroffen werden. |
| Protokollierung | Erwägen Sie das Sammeln und Speichern von Telemetriedaten in einem zentralen Datenrepository. Dies ist ein beliebtes Muster, das Integrationslösungen verwenden. Beispielsweise kann Azure Logic Apps (Standard) Telemetriedaten per Push an Application Insights in Azure Monitor übertragen. Azure Logic Apps (Verbrauch) kann Telemetriedaten per Push an Log Analytics übertragen, auch in Azure Monitor. Sie können auch nachverfolgte Eigenschaften einbeziehen, damit Entwickler mehr Kontext einbeziehen können, wenn Nachrichten durch die Integrationsplattform fließen. Diese Daten können beispielsweise Arbeitsauftragsnummern, Bestellinformationen oder andere Informationen enthalten, die für Ihre Organisation nützlich, hilfreich und relevant sein könnten. Die Lösung jeder Organisation kann sich je nach den Anforderungen der Organisation unterscheiden. Manche Organisationen möchten zum Beispiel die volle Kontrolle darüber haben, welche Daten wann protokolliert werden. In diesem Fall könnten Sie APIs oder benutzerdefinierte Konnektoren erstellen und Ihren Code dann auf der Grundlage bestimmter Meilensteine instrumentieren. Unabhängig davon, welchen Ansatz Sie wählen, stellen Sie sicher, dass Ihre Entwickler die Erwartungen klar verstehen, um künftige Nacharbeiten zu vermeiden. |
| Ausnahmebehandlung | Legen Sie frühzeitig eine Strategie und ein konsistentes Muster für den Umgang mit Ausnahmen und Fehlern fest, um spätere Nacharbeiten zu vermeiden. Stellen Sie sicher, dass Sie frühzeitig Klarheit in diesem Bereich schaffen, bevor Sie Logik-Apps erstellen. Die folgende Liste enthält einige Fragen, die Sie beantworten sollten, wenn Sie sich mit der Behandlung von Ausnahmen befassen: – Wie verwenden Sie Bereiche und Einstellungen für „Ausführen nach“, um Ausnahmen zu erkennen? – Wie können Sie den result()-Ausdruck verwenden, um besser zu verstehen, wo eine Ausnahme in einem Workflow auftritt, und um weitere Informationen zur zugrunde liegenden Ursache zu finden? – Wie möchten Sie diese Daten protokollieren und an die Beteiligten kommunizieren, nachdem Sie entschieden haben, wie Ausnahmen erfasst werden sollen? Achten Sie darauf, dass diese Entscheidungen wie bereits erwähnt mit Ihrer Protokollierungsstrategie übereinstimmen. Im Idealfall haben Sie einen Prozess eingerichtet, der aktiv nach neuen Fehlerereignissen in Ihrem Protokollierungsdatenspeicher sucht. Von dort aus können Sie auf diese Ereignisse reagieren und einen Ausnahmeprozess orchestrieren. Möglicherweise müssen Sie doppelte Fehlerereignisse herausfiltern oder zusammenfassen, ein Ticket in der IT-Dienstverwaltungslösung Ihrer Organisation erstellen und entscheiden, wie Sie Benachrichtigungen versenden. Je nach Schweregrad des Problems und Tageszeit können Sie verschiedene Pfade für Benachrichtigungen wählen. Sie können Flexibilität erreichen, indem Sie einen Workflow zur Verwaltung dieses Prozesses erstellen. |
| Analyse | Um Ihren Projektbeteiligten den Gesamtzustand und die Hygiene Ihrer Lösung zu demonstrieren, sollten Sie die verschiedenen Blickwinkel Ihrer Projektbeteiligten berücksichtigen: – Führungskräfte interessieren sich vielleicht eher für den Gesamtzustand, die Anzahl der Transaktionen oder das Transaktionsvolumen und den geschäftlichen Wert, den diese Transaktionen generieren, nicht aber für die technischen Details im Allgemeinen. – Ein Frontline-Manager ist vielleicht eher am allgemeinen Zustand interessiert, könnte sich aber auch für technische Details wie Leistungsmerkmale interessieren, um sicherzustellen, dass die SLAs eingehalten werden. – Supportanalysten interessieren sich wahrscheinlich für den allgemeinen Zustand des Diensts, Ausnahmen und Leistungsengpässe. Bei der Ausarbeitung Ihrer Analysestrategie sollten Sie sich Gedanken über Ihre Projektbeteiligten und die Art der Daten machen, die sie interessieren. Diese Überlegungen helfen Ihnen, sicherzustellen, dass Sie nützliche und hilfreiche Informationen erfassen und diese Daten für die Berichterstattung zugänglich machen. Wenn Sie Erfassungslücken feststellen, müssen Sie möglicherweise Ihre protokollierungsbezogenen Arbeitselemente überarbeiten und geeignete Aufgaben hinzufügen, um diese Lücken zu schließen. |
| Ablaufplan | Wenn Sie Ihre Integrationsprojekte ausliefern und aus diesen Erfahrungen lernen, sollten Sie sicherstellen, dass Sie die Erkenntnisse festhalten, die sich unweigerlich ergeben. Planen Sie frühzeitig Sprints oder Zyklen zur Behebung von Problemen, damit Sie den Kurs frühzeitig korrigieren können, bevor die Kosten zu hoch werden. Auf diese Weise können Sie vermeiden, zu viele technische Schulden in Ihre neue Plattform einzubringen. |
Bereitstellungsplanung
Wenn Sie einen Bereitstellungsplan vorhersehen und erstellen, erhöhen Sie Ihre Chancen auf eine erfolgreiche Bereitstellung. Nachdem Sie mit BizTalk Server die gesamte Infrastruktur und die Umgebungen erstellt hatten, konzentrierten Sie sich auf die Bereitstellung der Lösung.
Bei Azure ist dies anders. Hier müssen Sie zunächst einige Aktivitäten berücksichtigen, z. B. die Bereitstellung der Infrastruktur zwischen verschiedenen Umgebungen, die beispielsweise verschiedene Azure-Abonnements, Azure-Ressourcengruppen oder eine Kombination davon umfassen können, beispielsweise:
- Azure Key Vault: Geheimnisse und Zugriffsrichtlinien
- Azure Service Bus: Warteschlangen, Themen, Abonnements, Filter und Zugriffsrichtlinien
- Azure App Service: Pläne, Netztechnologie und Authentifizierung
Anschließend können Sie sich auf die Lösungsbereitstellung zwischen verschiedenen Umgebungen konzentrieren.
Testplanung
Um sicherzustellen, dass Ihre Projektbeteiligten mit der von Ihnen bereitgestellten Lösung zufrieden sind, sind Tests für jedes Migrationsprojekt wichtig. Eine neue Lösung sollte im Vergleich zur vorherigen Lösung einen höheren Nutzen bieten, ohne dass es zu Regressionen kommt, die sich auf das Geschäft auswirken könnten.
Berücksichtigen Sie die folgenden Testempfehlungen für Ihr Migrationsprojekt:
Richten Sie Ihre Baseline ein, indem Sie die folgenden Fragen beantworten:
- Gibt es bereits Tests?
- Werden die Tests fehlerfrei ausgeführt?
- Sind die Testergebnisse genau?
Um sicher zu sein, dass Ihr Team keine Regressionen eingeführt hat, müssen Sie die Ergebnisse der neuen Plattform mit zuverlässigen Tests Ihrer vorhandenen Plattform vergleichen können. Wenn Sie also noch keine Baseline haben, sollten Sie eine erstellen.
Natürlich möchten Sie nicht viele Ressourcen aufwenden, um Tests mit einer Plattform durchzuführen, die eingestellt wird, aber Sie müssen die Frage beantworten: „Woher weiß ich, dass alles erfolgreich funktioniert?“ Wenn Sie sich in dieser Situation befinden, sollten Sie mit der Erstellung einer Baseline auf der Grundlage von Prioritäten beginnen und einen Plan erstellen, um die Bereiche zu entschärfen, die Lücken aufweisen.
Richten Sie Ihre Teststrategie für die neue Plattform ein.
Wenn Sie mit Ihrer Baseline zufrieden sind, können Sie sich nun überlegen, wie Sie Ihre neue Plattform testen möchten. Wenn Sie Probleme bei der Erstellung Ihrer Baseline hatten, nutzen Sie die Gelegenheit, eine starke Grundlage für Ihre neue Plattform einzurichten.
Wenn Sie über Tests für Ihre neue Plattform nachdenken, sollten Sie die Automatisierung im Auge behalten. Auch wenn Sie mit einer Plattform in der Lage sind, Schnittstellen schnell zu erstellen, werden diese Produktivitätsgewinne durch manuelle Tests wieder zunichte gemacht.
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 Ansätze oder Ressourcen Sie verwenden, sind Sie auf dem besten Weg, wiederholbare, konsistente 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 Integration Services. 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.
Live schalten
Nachdem Ihr Team die Tests abgeschlossen hat, denken Sie über die notwendigen Aufgaben nach, um Ihre neue Integrationsplattform in Produktion zu bringen:
Erstellen Sie einen Kommunikationsplan.
Auch wenn Sie vielleicht nur ein kleines Team haben, das die technischen Aspekte und Details eines Projekts zur Modernisierung einer Integrationsplattform umsetzt, gibt es wahrscheinlich viele Beteiligte, die Sie über das Migrationsprojekt auf dem Laufenden halten müssen. Wenn Sie keine klare Kommunikationsstrategie haben, verunsichern Sie die anderen Beteiligten. Berücksichtigen Sie auch die externen Beteiligten, die Sie in Ihren Kommunikationsplan einbeziehen müssen. So sollten Sie beispielsweise auch andere Handelspartner oder Kunden einbeziehen, die von bevorstehenden Ereignissen betroffen sein könnten. Vergessen Sie auch diese Beteiligten nicht.
Kommunizieren Sie also frühzeitig und häufig, indem Sie in den Bereichen, die Ihre Projektbeteiligten betreffen, für Klarheit sorgen, z. B. was Sie von ihnen erwarten, wann sie gebraucht werden, wie lange sie gebraucht werden und so weiter. Durch die Vorlage eines präzisen und klaren Plans schaffen Sie Vertrauen bei den Beteiligten und sorgen für eine positive Energie rund um Ihr Projekt. Beseitigen Sie alle Zweifel, indem Sie sicherstellen, dass Ihr Team zur Ausführung bereit ist. Andernfalls riskieren Sie, dass die Moral aufgrund von Wahrnehmungen, Spekulationen und Gerüchten über ein mögliches Scheitern Ihres Projekts leidet.
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
Bestimmen Sie die Maßnahmen, die Sie im Voraus durchführen können oder müssen, damit Sie nicht alles auf den Tag der Übernahme verschieben. Ein Umstieg auf eine neue Integrationsplattform bedeutet in der Regel, dass Sie eine „Green Field“-Bereitstellung haben, sodass Sie viele Komponenten und Konfigurationen schon früh im Zyklus bereitstellen können. Je mehr Sie vor dem Wartungsfenster Ihrer ursprünglichen Plattform fertigstellen können, desto mehr Ärger können Sie vermeiden und das Gesamtergebnis des Übernahmeprozesses verbessern.
Generalprobe
Die Projektbeteiligten wünschen sich in der Regel eine gewisse Vorhersagbarkeit für die bevorstehenden Ereignisse. Wie bieten Sie also Vorhersagbarkeit für etwas, das Sie noch nie zuvor getan haben? Indem Sie eine Generalprobe durchführen, bei der Ihre Integrationsplattform in einer Vorproduktionsumgebung bereitgestellt wird, können Sie Ihren Übernahmeplan und den voraussichtlichen Zeitplan für jeden Prozessschritt überprüfen.
Andernfalls kann eine Unterschätzung der Zeit, die ein Schritt in Anspruch nehmen kann, zu einem Welleneffekt von Verzögerungen führen. In der Summe können diese Verzögerungen viel Zeit kosten und das Geschäft stören. Wenn Sie eine Generalprobe durchführen, können Sie Ihren Zeitplan auf die tatsächlichen Daten stützen. Möglicherweise findet Ihr Team auch Probleme, die bei der Inbetriebnahme in der Produktion zu Problemen geführt hätten. Wenn Ihr Team Probleme frühzeitig erkennt und dokumentiert, ist es besser vorbereitet und riskiert weniger Überraschungen bei der tatsächlichen Übernahme.
Personen
Stellen Sie sicher, dass eine klare Verantwortlichkeit dafür besteht, welche Person für jeden einzelnen Schritt des Plans zuständig ist. Eine kluge Strategie zur Schadensbegrenzung besteht darin, Ersatzpersonen für den Fall zu bestimmen und vorzubereiten, dass die Hauptperson aufgrund unerwarteter Umstände nicht in der Lage ist, die Aufgabe zu erfüllen.
Planen von Schätzungen
Nach einer Probe sollte Ihr Team eine bessere Vorstellung davon haben, wie lange jede Aufgabe dauern könnte. Anhand dieser Schätzungen können Sie einen Zeitplan erstellen, sodass die Mitarbeiter wissen, wann Sie sie brauchen und wie viel Zeit sie ungefähr für die Erledigung ihrer Aufgabe haben.
Deaktivieren von Schnittstellen auf der alten Plattform
Vorausgesetzt, Sie kennen alle bestehenden Abhängigkeiten, können Sie damit beginnen, Schnittstellen auf Ihrer alten Integrationsplattform zu deaktivieren, bevor Sie Schnittstellen auf der neuen Plattform aktivieren. Bei einigen komplexen Architekturen kann es erforderlich sein, dass Sie aufeinanderfolgende Schnittstellen in einer bestimmten Reihenfolge deaktivieren, um Überraschungen zu vermeiden. Je nach Art der Schnittstelle können Sie möglicherweise auch nicht alle Schnittstellen auf Ihrer alten Integrationsplattform deaktivieren. Wenn Sie beispielsweise über ein Branchensystem verfügen, das Nachrichten per Push an Ihre Integrationsplattform sendet, sollten Sie diese Situationen in Ihrem Übernahmeplan berücksichtigen.
Aktivieren von Schnittstellen auf der neuen Plattform
Ähnlich wie bei sequenziellen Schnittstellen, die sie in einer bestimmten Reihenfolge deaktivieren müssen, verfügen Sie möglicherweise über neue sequenzielle Schnittstellen, die Sie in der gleichen Reihenfolge aktivieren müssen. Bevor Sie mit dem Aktivieren von Schnittstellen beginnen, stellen Sie sicher, dass Sie alle Abhängigkeiten verstehen und die erforderliche Reihenfolge für die Aktivierung neuer sequenzieller Schnittstellen ermittelt haben.
Hinweis
Achten Sie darauf, dass Sie Schritte ausführen, um Schnittstellen methodisch und systematisch zu aktivieren, um Fehltritte zu vermeiden, die den Erfolg Ihres Projekts gefährden.
Validierungstests
Diese Aktivität ist äußerst wichtig, nehmen Sie daher diese Arbeit in Ihren Übernahmeplan auf. Nachdem Sie Ihre Schnittstellen aktiviert haben, sollten Sie sich vergewissern, dass die Schnittstellen wie erwartet funktionieren, bevor Sie zur Phase „Go oder No-Go“ übergehen. Im Idealfall können Sie Validierungstests ausführen, die keine Auswirkungen auf die Kerngeschäftsdaten haben. Dieser Leitfaden enthält in einem späteren Abschnitt weitere Informationen über Validierungstests für Ihre neuen Schnittstellen.
Legen Sie einen Zurücksetzungsplan fest.
Hoffentlich haben Sie jetzt einen strukturierten und detaillierten Ansatz für die Implementierung Ihrer neuen Integrationsplattform. Es kann jedoch zu Überraschungen kommen. Legen Sie daher die notwendigen Schritte fest, um zu Ihrer vorherigen Integrationsplattform zurückzukehren. Auf diese Weise haben Sie einen Plan für den Fall der Fälle parat.
Denken Sie bei der Planung dieser Schritte auch an die Ereignisse, die eine Zurücksetzung auslösen könnten. Stimmen Sie Ihren Plan auch mit den Personen ab, die die Entscheidung über eine Zurücksetzung treffen müssen. Dieser Leitfaden enthält weitere Informationen im Abschnitt zum Treffen der Entscheidung „Go oder No-Go“.
Führen Sie Validierungstests aus.
Ihr Übernahmeplan sollte die Details für diese Arbeit enthalten. Nachdem Sie Ihre Schnittstellen aktiviert haben, sollten Sie sich vergewissern, dass die Schnittstellen wie erwartet funktionieren, bevor Sie zur Phase „Go oder No-Go“ übergehen. Im Idealfall können Sie Validierungstests ausführen, die keine Auswirkungen auf die Kerngeschäftsdaten haben.
Im Idealfall können Ihre Validierungstests zwar Daten aus einem Branchenproduktionssystem lesen, aber keine Daten schreiben, was ein Complianceproblem darstellt. Andernfalls müssen Sie warten, bis ein Geschäftsvorgang durch Ihre Schnittstellen fließt, um zu überprüfen, ob alles so funktioniert, wie Ihr Team es erwartet.
Planen Sie Support für den Betrieb oder die Produktion.
Obwohl der Aufwand für die Migration von Schnittstellen zwischen Plattformen in der Regel die meisten Projektressourcen verbraucht, sollten Sie auch den laufenden Support für Ihre Schnittstellen und die neue Plattform berücksichtigen.
Stellen Sie sicher, dass Sie den entsprechenden Wissensstand zwischen dem Projektteam und dem Betriebsteam teilen.
Erstellen und führen Sie eine aktuelle Kontaktliste, die sowohl technische als auch geschäftliche Kontaktdaten enthält, damit jeder bei Bedarf die entsprechenden Teammitglieder erreichen kann.
Um eine reibungslosere und zeitnahe Reaktion auf Kundenanfragen zu ermöglichen, sollten Sie Ihre Supportprozesse und -dokumentation bereits vor der Inbetriebnahme bereithalten. Sie können den Stress für Kunden, Ihr Supportteam und Ihr Projektteam verringern, wenn Sie vermeiden können, dass ein Supportmitglied versucht, alles herauszufinden, wenn ein tatsächlicher Vorfall auftritt.
Wählen Sie „Go oder No-Go“ für den Übergang zur Produktion.
In diesem Schritt arbeiten Sie mit den relevanten Stakeholdern zusammen, um zu entscheiden, ob das Projekt in die Produktion gehen kann. Zu diesen Stakeholdern können beispielsweise die Leitung, das Projektmanagement, der Betrieb und Vertreter des Unternehmens gehören.
Feiern Sie den Erfolg Ihres Teams.
Herzlichen Glückwunsch! Nachdem Sie ein Projekt abgeschlossen haben, das sich positiv auf Ihre Organisation oder Ihr Unternehmen auswirkt, ist es an der Zeit, Ihr Team für seine harte Arbeit zu würdigen und einen großartigen Meilenstein zu feiern! Achten Sie darauf, dass Sie Ihrem Team auf angemessene und sinnvolle Weise Anerkennung zollen. Keine Anerkennung ist eine sichere Möglichkeit, die Moral zu ruinieren.
Halten Sie eine Retrospektive ab.
Wie bei jeder technischen Tätigkeit gewinnt Ihr Team wertvolle Erkenntnisse und erweitert sein Wissen, indem es aus Erfahrungen lernt. Treffen Sie sich mit Ihrem Team, um die Bereiche zu besprechen und festzuhalten, die gut und nicht gut gelaufen sind und die sich noch verbessern lassen. Achten Sie darauf, dass dieses Gespräch in einer entspannten und kollegialen Atmosphäre stattfindet, und konzentrieren Sie sich auf das Ziel, zu lernen und zu wachsen, nicht auf Schuldzuweisungen. Teilen Sie Ihre Erkenntnisse mit Ihren Führungskräften und anderen interessierten Beteiligten. Diese Übung schafft Vertrauen im gesamten Team und steht für technische Reife.
Bewährte Methoden für die 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 Logik-Apps, 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 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 haben keinen Kontext und machen die Unterscheidung und Zuordnung von Verbindungen zu ihren Logik-Apps zu einer großen Herausforderung, insbesondere für Entwickler, die mit diesem Bereich nicht vertraut sind und die Wartung dieser Logik-Apps übernehmen 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 einer OrderQueue-Logik-App oder einem 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. Die Funktionalität der Bereichsaktion ähnelt dem Konzept Region in Visual Studio. 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. |
Überprüfen, Reflektieren und Lernen
Beurteilen und bewerten Sie von Zeit zu Zeit Ihre vorhandenen Logik-Apps, insbesondere dann, wenn Fehler auftreten. Analysieren Sie nicht nur den Geschäftsprozess, um zu ermitteln, was und wo Sie verbessern können, sondern analysieren Sie auch den Ausführungsverlauf Ihres Workflows, um aus Fehlschlägen und Fehlern zu lernen, die aufgetreten sind. Azure Logic Apps bietet einen so umfangreichen Ausführungsverlauf, dass Sie darin mit hoher Wahrscheinlichkeit neue Dinge über Ihre App entdecken. Wie immer bei der Codeentwicklung können einige Edge oder Corner Cases auftreten. Aktualisieren Sie während der Ermittlungen Ihre Schnittstellen, um diese Situationen zu berücksichtigen, und verbessern Sie die allgemeine Zuverlässigkeit Ihrer Lösungen.
Eine Tatsache für Projektteams ist, dass Entwickler versuchen, Fehler allgemein zu erfassen, um zumindest einen gewissen Schutz vor Problemen zu erhalten. Wenn Ihr Team herausfindet und besser versteht, wo Dinge schief gehen könnten, können Sie sich genauer darüber informieren, wie Sie sich vor Problemen schützen können.
Ähnlich wie Organisationen regelmäßig „Red Team“-Übungen" durchführen, z. B. Penetrationstests oder Phishingversuche, ist Sicherheit keine Aktivität mit einmaliger Konfiguration („set and forget“). Wenn neue Authentifizierungsverfahren und -ansätze verfügbar werden, sollten Sie Ihre Schnittstellen regelmäßig überprüfen, Ihre Sicherheitsmaßnahmen überdenken und relevante und geeignete neue Entwicklungen integrieren, die die sichersten Ansätze bieten.
DevOps ist ein weiterer Bereich, den Sie in regelmäßigen Abständen überprüfen sollten. Wenn Microsoft oder die Community neue Vorlagen oder Ansätze einführt, bewerten Sie diese Aktualisierungen, um festzustellen, ob Sie weitere Vorteile daraus ziehen können.
Nächste Schritte
Sie haben nun mehr über verfügbare Migrationsansätze, Planungsüberlegungen und bewährte Methoden für das Verschieben von BizTalk Server-Workloads zu Azure Integration Services erfahren. Um detailliertes Feedback zu diesem Leitfaden zu geben, können Sie das folgende Formular verwenden: