Umstieg von Shopware 5 auf 6: vorausschauend planen und Geld sparen

Shopware

Im folgenden Beispiel werden wir Ihnen aufzeigen, wie wir die in etwa zwei Jahren geplante Migration eines unserer Kunden auf Shopware 6 bereits beim aktuellen Shop-Relaunch mit SW 5 mit einkalkuliert haben.

Seit Shopware im Januar 2020 sein neuestes Shopsystem auf den Markt gebracht hat, denken viele Onlinehändler über einen Wechsel von Shopware 5 auf Shopware 6 nach. Für Nutzer von Shopware 5 ist der Umstieg auf die neue Version langfristig nicht zu umgehen und im Hinblick auf die interessanten neuen Features auch lohnenswert. Wer allerdings bei einem aktuellen Shop-Launch bzw. Relaunch noch auf sein bewährtes System setzen möchte, kann den Wechsel auf Shopware 6 beruhigt erst in ein bis zwei Jahren vollziehen.

Denn: Shopware 5 und Shopware 6 sind technisch nicht kompatibel zueinander. Durch den Einsatz neuester Technologien und die komplett neu entwickelten Kernfunktionalitäten wird es bei dem Wechsel von Version 5 auf 6 also nicht wie vorher die Möglichkeit geben, ein “Auto-Update” durchzuführen. Auch vorhandene Plugins der Version 5 werden nicht mit Shopware 6 kompatibel sein und werden von den jeweiligen Anbietern überarbeitet.

Komplexe Feature Releases mit Blick in die Zukunft

Auf den ersten Blick scheint diese Situation zu einem ernsten Dilemma zu führen. Umfangreiche neue Funktionen für Shopware 5 scheinen sich nicht mehr zu lohnen, wenn man ja sowieso in den kommenden Monaten mit der Migration auf eine neue Plattform beginnen wird. Nun kann es für ambitionierte Händler jedoch auch keine Option sein, die Weiterentwicklung auf Eis zu legen.

Im beschriebenen Fall geht es um eine sehr umfangreiche und tiefe Integration des ERP Dynamics 365 Business Central (früher: Navision) mit Hilfe eines XML Webservice aufseiten Business Central.

Damit zwischen Shopware und dem ERP ein Datenaustausch stattfinden kann, müssen entsprechende Mappings und Datenumwandlungen implementiert werden. Der Business Central Webservice muss bidirektional mit Shopware kommunizieren können.
Wer die Welt der ERP-Integrationen auf grüner Wiese kennt, weiß, dass dies mitunter ein sportliches Unterfangen sein kann.

Eine Middleware als Brücke

Für diese Mappings nutzen wir einen XSLT-Prozessor, d.h. einen Ansatz zur Transformation von XML-Dokumenten. Mithilfe des XSLT-Prozessors können nun so gut wie alle Entitäten (d. h. Kunden- und Adressdaten, Bestellungen usw.) vollautomatisiert transformiert, in die Shopware-Struktur integriert und mit dem ERP synchronisiert werden.

Typischerweise kann man für eine solche Schnittstelle zwei Ansätzen folgen. Die ausschließliche Kommunikation über die Shopware Webservices ist aufgrund der erforderlichen Datentransformationen kein gangbarer Weg. Verbleibt nun der typische Ansatz einer Art Middleware.

Der Clou dabei: Anstatt die Schnittstelle direkt tief in Shopware selbst zu programmieren, lagern wir signifikante Teile des Programmcodes, d.h. wiederkehrende Kernfunktionalitäten, in eine eigens dafür geschaffene Composer Library aus.

Lediglich einzelne, sehr systemspezifische Funktionen programmieren wir direkt in Shopware. Alle in die Bibliothek ausgelagerten Codes funktionieren hingegen unabhängig vom Shopsystem und können daher ganz einfach in Shopware 6 bzw. jedes andere beliebige System integriert werden.

In der Library sammeln wir sämtliche Codes bzw. Grundfunktionalitäten zur Kommunikation zwischen Onlineshop und ERP-System. So entsteht ein solides Grundgerüst, das für jedes Shopsystem flexibel und dynamisch transformiert werden kann. Die Middleware stellt dabei kein eigenständig lauffähiges Programm dar, sondern ist vielmehr ein Verzeichnis für Codes, die vom Shopsystem angefordert werden können. Entscheidend ist hier die Transformation der XML-Dokumente, d. h. deren “Übersetzung”, sodass das jeweilige Shopsystem und das ERP miteinander synchronisiert werden können.

Bei der Implementierung haben wir uns die Freiheit gelassen, den kompletten Kommunikations-Stack variabel zu halten. So muss nur das in der Bibliothek beiliegende „Driver“ Interface implementiert werden und jede beliebige HTTP Bibliothek/Erweiterung kann verwendet werden. Wir haben uns hierbei für Guzzle entschieden, da diese äußerst flexibel ist.

Die Vorteile dieser Lösung liegen auf der Hand:

  • Redundanzen bei der Programmierung werden vermieden: Wenn unser Kunde auf das neue Shopsystem wechselt, muss lediglich der Shopware-6-spezifische Teil neu programmiert werden.
  • Der restliche Datenaustausch läuft weiterhin direkt von der allgemeinen Funktionsbibliothek ins ERP-System.
  • Unser Kunde spart dadurch bei der Migration von SW 5 zu SW 6 jede Menge Zeit und Geld.