Man kann nicht sagen, dass man ein echter SAP Commerce (Hybris)-Entwickler ist, bevor man nicht seine erste Migration durchgeführt hat. Jeder Entwickler, der an einer solchen Aufgabe gearbeitet hat, hat Narben zu zeigen und eine Kriegsgeschichte zu erzählen.
Da jeder Kunde seine eigenen Bedürfnisse hat, ist eine Anpassung der Standard-Beschleuniger notwendig, und das ist die Hauptquelle für Kopfschmerzen Es gibt zahlreiche Anleitungen zur Durchführung eines Upgrades, aber keine, die Ihnen zeigt, wie Sie Ihre benutzerdefinierten Funktionen migrieren können.
Dies ist nicht nur ein weiterer Artikel über den Umgang mit Upgrades, sondern wir werden uns darauf konzentrieren, wie Sie sich richtig darauf vorbereiten können, indem Sie die Upgrade-Fähigkeit von Anfang an in Angriff nehmen.
Ein bisschen Theorie
Lasst uns mit den Grundlagen beginnen. Architektonische Merkmale, auch bekannt als nichtfunktionale Anforderungen, sind ein entscheidender Bestandteil des Gesamterfolgs der Architektur und damit des Projekts. Leider liegt der Fokus meist auf der Funktionalität und diese wird entweder übersehen oder zu spät berücksichtigt, was zu einem erheblichen Mehraufwand führen kann.
Was sind also die architektonischen Merkmale, die man bei einem SAP Commerce (hybris) Projekt berücksichtigen sollte?
Wenn mir jemand vor ein paar Jahren diese Frage gestellt hätte, wäre mir als allererstes die Performance aufgekommen. Dann erfährt man, dass auch Skalierbarkeit und Konfigurierbarkeit wichtig sind. Dann sagt einem jemand, dass die Verfügbarkeit wichtiger ist als die Leistung. Am Ende stellt man fest, dass es viele Antworten auf diese Frage gibt, aber es gibt kein Richtig oder Falsch, sondern alles hängt vom Kontext ab, da es immer Kompromisse geben wird, die von der Domäne, dem Zeitplan, der Verfügbarkeit des Teams und den Kenntnissen des Technologie-Stacks, dem Budget usw. abhängen.
Es gibt jedoch ein Architekturmerkmal, das bei jedem SAP Commerce Cloud (Hybris)-Projekt berücksichtigt werden sollte, und das ist die Upgradefähigkeit.
Um den Geschäftsanforderungen gerecht zu werden, muss sich ein Projekt weiterentwickeln, und das kann durch ein Upgrade geschehen. Diese Bemerkung gilt für jedes Projekt, insbesondere für ein auf der SAP Commerce (Hybris) Plattform basierendes Projekt.
Aktualisierbarkeit bezieht sich auf die Fähigkeit, einfach/schnell von einer früheren Version dieser Anwendung/Lösung auf eine neuere Version auf Servern und Clients zu aktualisieren.
Grundlagen der Softwarearchitektur von Mark Richards und Neal Ford
Warum sollten Sie also ein Upgrade durchführen? Dies hängt von vielen Faktoren ab, aber die Hauptgründe für ein Upgrade der verwendeten Plattform- und Beschleunigerversionen sind:
- Ermöglichung neuer Funktionen
- Supportfähigkeit
Die Entscheidung für ein Upgrade auf eine neue Plattform oder eine bestimmte Accelerator-Version muss in der Tat gut überlegt werden. Es gibt viele geschäftliche Gründe, die für ein Upgrade sprechen, aber ich werde sie im Rahmen dieses Artikels ausklammern. Mein Fazit, das ich ebenfalls auf die harte Tour gelernt habe, lautet: sei kein Beta-Tester. Vermeide es, der Erste zu sein, der versucht, auf die neue, glänzende Version zu aktualisieren, da man normalerweise auf eine Menge unvorhergesehener Probleme stoßen kann. Andererseits empfiehlt Hybris, nicht gegen Windmühlen zu kämpfen, d. h. sicherzustellen, mit Versionen arbeiten, die nicht älter als 2 Jahre sind.
Von Theorie zu Praxis
SAP Commerce Cloud (Hybris) wird mit verschiedenen Accelerators ausgeliefert, die in der Regel für einen bestimmten Bereich wie B2C, B2B oder eine bestimmte Branche wie Telekomm, Reisen, Einzelhandel usw. entwickelt wurden. Der Zweck dieser Accelerators ist es, eine Reihe von vordefinierten Funktionalitäten anzubieten, um die Zeit bis zum Go-Live zu verkürzen. Das Problem bei diesem Ansatz ist, dass, sobald man die Accelerator-Erweiterungen (über ant modulegen) generiert und eine einzige Änderung an dem generierten Code vornimmt, benutzerdefinierten Code erstellt haben. Jede weitere Änderung, die man an den generierten Accelerator-Erweiterungen vornimmt, erhöht den Grad der Anpassung und implizit auch den Upgrade-Aufwand.
Wie können Sie und Ihre Kunden also die neuen Funktionen der neuesten Versionen nutzen, ohne zu viel Zeit für die Portierung von benutzerdefiniertem Code aufwenden zu müssen? Wie können Sie die sofortige Übernahme künftiger Versionen sicherstellen, in einem Wort: Upgradability?
Die traditionellen Schritte zur Durchführung einer funktionalen Migration wären:
- Aktualisierung des Plattformcodes auf die neue Version
- Neugenerierung von benutzerdefinierten Erweiterungen auf der Grundlage der neuesten Beschleuniger-Vorlage (ant modulegen)
- Identifizierung und Portierung des benutzereigene Codes
- Technische Migration der Konfiguration und der Datenbank, um mit der Version der Zielbinärdateien kompatibel zu sein
Nachdem ich dies ein paar Mal gemacht habe, habe ich gelernt, dass die meiste Zeit während der Migration für die Identifizierung des benutzerdefinierten Codes verwendet wird. Eine unter den SAP Commerce-Projekten weit verbreitete Idee ist es, eine bestimmte Namenskonvention zu übernehmen, um den benutzerdefinierten Code zu isolieren, z. B. den Projektnamen als Präfix zu verwenden. Das Problem bei diesem Ansatz ist, dass Namenskonventionen fehleranfällig sind, die Identifizierung der Anpassungen Zeit und in der Regel ein gewisses Maß an Wissen und Erfahrung im Projekt erfordert.
Meine Haupterfahrung mit SAP Commerce-Projekten liegt im Bereich Telekommunikation, auch Telcos genannt. Wenn man Release Notes von SAP Commerce verfolgt haben, sieht man gesehen, dass der Telco Accelerator in den letzten Jahren bemerkenswert Entwickelt hat. Mit Spannung erwartete Funktionen wie Berechtigung, Kompatibilität, zusammengesetzte Preise, TM Forum APIs wurden jedes Quartal veröffentlicht. Wir wollten unsere Implementierung auf diese Funktionen abstimmen, und unser Kunde wollte ebenfalls einen Wettbewerbsvorteil haben, so dass das Einzige, was noch zu tun war, ein kontinuierliches Upgrade war. Das ist leider leichter gesagt als getan.
Das erste Problem, über das wir jedes Mal stolperten, war, die richtige Person für diese Aufgabe zu finden, eine Person, die über die nötige Erfahrung und ein tiefes Verständnis des Projekts verfügt, um die mühsame und wichtige Aufgabe der Identifizierung der Anpassungen und deren Portierung durchzuführen.
Genau wie beim Kochen wird man, nachdem man ein Rezept mehrmals nachgekocht hat, selbstbewusst genug und möchte dem klassischen Rezept eine persönliche Note verleihen. So war es auch in unserem Fall. Genauer gesagt haben wir verstanden, dass wir uns das Leben später sehr viel einfacher machen können, wenn wir von Anfang an einige grundlegende Prinzipien der Softwareentwicklung anwenden.
Während der Einrichtung eines SAP Commerce-Projekts werden die Vorlagenerweiterungen geklont und die abgeleiteten Erweiterungen als benutzerdefinierter Code behandelt. Der Schlüssel zur Erstellung von wartbarem Code und zur Gewährleistung der Unterstützung von Upgrades liegt jedoch darin, von Anfang an auf eine geringe Kopplung und einen hohen Zusammenhalt zu achten.
Das folgende Diagramm beschreibt einen Ansatz, um die Kopplung auf ein Minimum zu reduzieren. Im Grunde sollte der Entwurf des Projekts das Ergebnis der folgenden Schritte sein:
- Generierung der Accelerator-Erweiterungen (in blau) auf der Grundlage eines SAP Commerce Accelerators (in grau) mit ant modulegen
- für Core, Facades und Storefront eine separate Erweiterung/Addon mit ant yempty/ant yaddon generieren, um die Logik zu isolieren (in grün)
- Generierung einer neuen Erweiterung für die Integrationsschicht – in einigen Fällen wäre es sinnvoll, für jede Integration eine eigene Erweiterung zu haben (in grün)
- Berücksichtigung der funktionalen Kohäsion (alle Funktionen, die sich auf ein einzelnes Feature beziehen, in einer separaten Erweiterung unterbringen) (in grün)
Ab hier sollten alle Änderungen im grünen Bereich vorgenommen werden. Die generierten Accelerator Erweiterungen (in blau) können entweder in einem anderen Repository versioniert oder in einen Binary Repository Manager (z.B. Artifactory) hochgeladen werden, um der Versuchung zu entgehen, direkt den generierten Code anstelle der „leeren“ Erweiterungen zu ändern. Natürlich bringt dieser Ansatz eine zusätzliche Komplexitätsebene mit sich, aber in unserem Fall hat er sich als lohnend erwiesen.
Wenn das oben beschriebene Rezept befolgt wird, wären die Schritte zur Durchführung einer funktionalen Migration wie folgt:
- Aktualisierung des Plattformcodes auf die neue Version
- Neugenerierung benutzerdefinierter Erweiterungen auf der Grundlage der neuesten Beschleunigervorlage (ant modulegen) und Hochladen in einen Binary Repository Manager
- Technische Migration der Konfiguration und der Datenbank, um mit der Version der Zielbinärdateien kompatibel zu sein
Eine Sache lässt sich jedoch nicht vermeiden, und zwar das Refactoring des benutzerdefinierten Codes, wenn er überflüssig wird, da er bereits von der Standardlösung geliefert wird. Bevor eine Entscheidung getroffen wird, muss eine Gap-Analyse durchgeführt werden, aber selbst diese kann gemildert werden, wenn der benutzerdefinierte Code einige grundlegende Prinzipien folgt.
Auch wenn sich dar Projekt bereits in einem fortgeschrittenen Stadium befindet, vielleicht sogar schon in der Produktion eingesetzt wird, würde ich empfehlen, etwas Zeit zu investieren, um die passende Erweiterungsarchitektur zu finden. Es wird sich auf jeden Fall auszahlen, auch wenn man nicht öfter als ein- oder zweimal pro Jahr auf die neueste Accelerator-Version aktualisiert.
Schlussfolgerungen
Das erste Gesetz der Softwarearchitektur besagt, dass alles in der Softwarearchitektur ein Kompromiss ist. Versuchen Sie von Anfang an zu verstehen, ob die Aufrüstbarkeit eine wichtige Anforderung des Kunden ist, da sie einige strukturelle Aspekte des Designs beeinflussen kann. Selbst wenn diese Anforderung nicht vom Kunden kommt, ist es Ihre Aufgabe, darauf hinzuweisen, wie wichtig es ist, zu Beginn des Projekts etwas mehr Zeit für die Definition einer angemessenen und skalierbaren Erweiterungsarchitektur aufzuwenden, die sich langfristig auch als kosteneffizient erweisen wird.
Als Faustregel gilt: Vermeiden Sie es, die generierten Accelerator-Erweiterungen zu berühren, denn eine geringe Kopplung und ein hoher Zusammenhalt verbessern letztendlich die Wartbarkeit, Aktualisierbarkeit und Codequalität.