Wichtige Aspekte bei der CI-Migration von Neo nach CF

Vor Kurzem haben wir eine erfolgreiche Migration von der Neo- in die Cloud Foundry (CF) Umgebung durchgeführt. In diesem Blogbeitrag beschreibe ich unsere gesamte Migrationsreise: welche Herausforderungen uns begegnet sind, unsere Learnings, Empfehlungen und die Schlüsselfaktoren, die zu einer reibungslosen Migration geführt haben.

Ein kompetenter Architekt (auf Kundenseite) macht die Migration einfach. Genau das war auch bei uns der Fall. Wer lange im System unterwegs ist, kennt die Schmerzpunkte der Integration und versucht stets, sie zu optimieren.

Dokumentation

Bestehende Integrationen lassen sich über die vorhandenen Dokumente nachvollziehen. Fehlende Dokumentation kann zu deutlich höherem Aufwand bei der Systemanalyse führen.

Ein detaillierter Integrationstracker vom Kunden war unsere Rettung. Der Tracker erfasste jedes einzelne Detail: Sender, Empfänger, Abhängigkeiten, Scope, Kontakt beim Drittanbieter und mehr.

Laufende Aufgabe -> Das Team ist angehalten, den Tracker zu pflegen. Er half dabei, den Deployment-Fortschritt in den Sterr Co. Meetings darzustellen.

Ein detailliertes Cut-over-Sheet dient als Playbook.

Empfehlung - Nutzen Sie vorhandene Vorlagen. Greifen Sie auf bewährte Templates aus früheren Projekten zurück. Um den Gesamtprojektstatus zu verfolgen, sollte das Team einen zentral abgelegten Entwicklungstracker pflegen.

Identifikation der Komplexität: einfach/mittel/komplex

Die korrekte Größeneinschätzung der Schnittstellen half dabei, die Aufwände zu prognostizieren. Für diese Einordnung kann jedes beliebige Drittanbieter-Tool eingesetzt werden.

Denken Sie daran: Einige Schnittstellen können zu den sensiblen Prozessen zählen, etwa im Bereich Audit-Compliance wie SOX oder DSGVO. In unserem Fall hat der Architekt des Kunden dem Team geholfen, diese sensiblen Prozesse zu identifizieren.

Empfehlung - Der Integration Lead beziehungsweise Architekt sollte tief einsteigen, um den Komplexitätsgrad zu prüfen.

Das richtige Team und die richtige Teamgröße

Eine passende Teamstruktur ist entscheidend für einen reibungslosen Projektübergang. Bei einem großen Projekt kann das schnelle Upskilling technischer PI/PO-Ressourcen auf CI (Cloud Integration) den Unterschied machen.

Ein Projektmanager ist der Kapitän des Schiffs, unterstützt von einem Integrationsarchitekten beziehungsweise Integration Lead.

Ein Scrum Master und ein Release Master sind wie die Navigatoren des Schiffs und sorgen für ruhige Fahrt.

Integrationsarchitekt und Lead sollten früh genug Warnsignale setzen, damit der Projektmanager und der Architekt auf Kundenseite die nötigen Maßnahmen ergreifen können.

Empfehlung - Organisieren Sie Wissensaustausch-Sessions im Team, um Nacharbeiten zu minimieren. In unserem Fall hat der Architekt des Kunden einige Workshops zur Funktionsweise des Custom Adapters durchgeführt.

Artefakt-Migration von Neo nach CF

Für die Migration von iFlows aus der Neo- in die CF-Umgebung stellt SAP eine Reihe von POSTMAN Collections bereit. Mit den POSTMAN Collections lässt sich die Migration der Packages automatisieren.

Link zum Download der POSTMAN Collection - hier klicken

Link zur SAP-Hilfe, wie die POSTMAN Collection ausgeführt wird - hier klicken

Empfehlung - Pflegen Sie saubere Versionen und Kommentare, das hilft bei der Migration von Retro-Änderungen.
Hinweis: Security Materials (Zertifikate, Secure Parameter, OAuth2 Client Credentials, User Credentials, SSH Known Hosts) und PGP-Keys müssen manuell gepflegt werden.

Aufbau der Verbindungen

Einige Drittanbieter müssen unter Umständen die IP-Ranges der CF-Umgebung freischalten.

Link zu den IP-Ranges je nach CF-Rechenzentrum: - hier klicken

Teilen Sie den Drittanbietern die neuen Endpunkte von CI oder APIM zusammen mit einer neuen Client ID und neuen Secret Keys mit.

Empfehlung - Prüfen Sie die Konnektivität von SFTP, FTP, SCC, SMTP und Ähnlichem frühzeitig. Unvorhergesehene Verbindungsprobleme lassen sich so zu Beginn der Migration beheben.

Entwicklung/Migration (CI)

Werden in Groovy-Skripten Neo-Umgebungsvariablen verwendet, müssen diese nach der Migration nach CF angepasst werden (sofern zutreffend).

Behalten Sie laufende Entwicklungen in der Neo-Umgebung im Blick, denn diese müssen später nach CF migriert werden (Retro-Änderungen). Führen Sie für solche Fälle einen Retro-Tracker, um den Überblick zu behalten.

Empfehlung - Bleiben Sie bei der Versionsnummer aus der Neo-Produktion, sofern es sich nicht um eine Retro-Änderung handelt. Das hilft bei der späteren Nachverfolgung und bei Audits. Vergessen Sie nicht, die Kommentare zu pflegen.

Entwicklung/Migration (APIM), sofern zutreffend

Die neuen Endpunkte von CF-APIM und die Secret Keys sind mit den API-Konsumenten zu teilen; geben Sie die IP-Ranges von NEO zur Freischaltung weiter (falls vorhanden). Importieren Sie Zertifikate (falls vorhanden).

Empfehlung - Die Wiederverwendung bestehender POSTMAN Collections kann Testzeit sparen. Verbindungstests lassen sich frühzeitig durchführen, um zu prüfen, ob Postman-Aufrufe den Proxy-Endpunkt erfolgreich erreichen. Bleiben Sie möglichst bei denselben Namenskonventionen für die Security Materials.

Drittanbieter-Adapter (falls vorhanden)

Falls Drittanbieter-Adapter im Einsatz sind, etwa Advantco für die Anbindung von SFDC, Azure Blob, NoSQL und Ähnliches, müssen diese neu konfiguriert werden, da sich die Umgebung von Neo nach CF ändert.

Prüfen Sie das Deployment des Drittanbieter-Adapters in der neuen Umgebung (CF) mitsamt den erforderlichen Zertifikaten (im Known Host hinterlegt).

Eine neuere Version eines Drittanbieter-Adapters kann die Namespaces ändern. Das kann sich auf den XPath auswirken. Vergleichen Sie die Mapping-Ergebnisse (Neo und CF).

Empfehlung - Lesen Sie die Dokumentation des Custom Adapters.

Unit-Test und SIT

Drittanbieter-Tools wie IFTT INT4 können genutzt werden, um komplexe Message-Mapping-Logik zu vergleichen (Payload-Vergleich von CF und Neo).

Empfehlung - Halten Sie Testnachweise als Beleg für die erfolgreiche Migration fest. Darauf lässt sich später bei etwaigen Problemen nach der Migration zurückgreifen.

User Acceptance Testing und Abnahme

Die Einbindung der Integrationspartner auf Drittanbieterseite ist entscheidend, um die UAT-Abnahme zu erhalten. Nehmen Sie frühzeitig Kontakt auf.

Um Testzeit zu sparen, versuchen Sie, vorhandene Testfälle wiederzuverwenden. Testtools (wie HPQC oder andere) können zur Nachverfolgung der Tests genutzt werden.

Empfehlung - Proaktives und klares Vorgehen räumt die meisten der später auftretenden Testprobleme von vornherein aus. Holen Sie den Fachbereich ins Boot, denn es handelt sich um eine technische Migration.

Produktions-Cut-over und Go-live

Eine detaillierte Cut-over-Vorlage kann einen erfolgreichen Produktionsgang sicherstellen.

Das Cut-over-Playbook sollte enthalten: detaillierte Ausführungsschritte in der richtigen Reihenfolge, abhängige Schritte, Rollback-Plan, Verbindungsdetails und Kontaktdaten.

Der Release Manager sollte alle wichtigen Stakeholder regelmäßig informieren.

Empfehlung - Besprechen Sie das Cut-over-Sheet mit den Integrationspartnern. Überwachen Sie den Integrationsbetrieb nach dem Deployment durchgängig End-to-End.

Hypercare-Support und Übergabe an das Support-Team

Teilen Sie beim Knowledge Transfer die Herausforderungen aus Migration und Test samt den wahrscheinlichen Lösungen, damit das Support-Team nach dem Hypercare reibungslos arbeiten kann.

JMS-Queues (falls vorhanden) sind auf ein starkes Auflaufen fehlgeschlagener Nachrichten zu überwachen, da dies die Gesamtperformance des Tenants beeinträchtigen kann.

Geben Sie dem Support-Team alle notwendigen Unterlagen weiter, zum Beispiel Testergebnisse, Integrationsdesign und Ähnliches.

Empfehlung - Besprechen Sie die Test-Herausforderungen, Issues und gemeldeten Bugs.

Empfehlungen

Kompetentes Team - Das richtige Team vor Ort ist der Schlüssel für jede Mission. Beratende sollten flexibel und proaktiv sein.

Tägliches Standup - Zur Nachverfolgung des Sprint-Fortschritts.

Authentifizierung - Ersetzen Sie Basic Auth durch OAuth2.0. Minimieren Sie zertifikatsbasierte Authentifizierung, da sie beim Ablauf der Zertifikate künftig Support erfordern kann.

Kommunikation - Sprechen Sie Drittanbieter frühzeitig an, damit die passenden Testerinnen und Tester zu Ihren Projektterminen eingeplant werden können. Empfehlung: ein beispielhaftes Integrationsdiagramm für den ersten Call, mit betroffenen Systemen, Endpunkt-Änderungen (falls vorhanden), neuen Credentials oder Zertifikatsänderungen.

Tools - HPQC (zur Dokumentation von Testfällen), MS-SP für die Dokumentation. IFTT @INT4 (für den Payload-Vergleich), POSTMAN (zum Senden von Test-Payloads bei Verbindungstests, besonders relevant für das Testen von APIM-Endpunkten), CPI-Helper Plugin @figaf, um den Trace aus dem Entwicklungsfenster zu aktivieren, CLDM @Integrtr (zum Logging geschäftskritischer Nachrichten für eine 360-Grad-Sicht auf die Daten).

Zugriffe - Das Migrationsteam sollte keinen Entwicklerzugriff auf CF-Tenants und Neo-Produktivtenants haben.

Inventory-Tracker - Ein Inventory-Tracker sollte alle notwendigen Angaben enthalten, Reiter Integration -> (Package, Schnittstellenname, Gruppe, Untergruppe, Details zum Drittanbieter, genutzte Channels, Termine, Entwickler, Status und mehr).

Credentials - Pflegen Sie Credentials an einer zentralen Stelle, damit das Entwicklungsteam darauf zugreifen kann (passwortgeschützt). Empfehlung: Verbindungstests sollten in der Anfangsphase des Projekts durchgeführt werden, um Auswirkungen im SIT zu vermeiden.

Schlüsselkontakte - Eine der entscheidenden Angaben, und zwar zu 100 Prozent korrekt, damit das Entwicklungsteam sie in der SIT/UAT-Phase erreichen kann. Nach unserer Erfahrung nimmt die UAT-Phase die meiste Zeit in Anspruch. Fehlende Schlüsselkontakte führen zu ständigem Nachfassen und damit zu Auswirkungen auf die Termine.

Utilities - Entwicklungs-Utilities sind immer eine wertvolle Ergänzung des vorhandenen Arsenals. Zum Beispiel APIs zum Abruf der Message Persistence (schauen Sie sich den SAP Business Accelerator Hub an), Ad-hoc-Integrationsflows, die im Produktionssupport bei fehlenden Daten bei Bedarf laufen, oder das erneute Anstoßen fehlgeschlagener Nachrichten.

Damit sind wir am Ende des Blogbeitrags. Mit den obigen Hinweisen kommen Sie auf Ihrer Migrationsreise von Neo nach CF hoffentlich gut voran. Teilen Sie gerne Ihre Erfahrungen.