Akeneo 4.0 bringt frischen Wind in die Community
Wir verwenden Akeneo bereits seit Version 1.3 und haben seit Version 1.7 eine dockerisierte Umgebung dafür entwickelt, welche mit der Zeit mit einigen Komfortfunktionen ausgestattet wurde. Seitdem brachten uns die neuen Versionen stets Veränderungen.
- So wurden in den 2er Versionen die Varianten Gruppen umgewandelt in Produkt Modelle und Familien Varianten.
- In den 3er Versionen wurden die Namespaces der Akeneo Bundles und deren Speicherort umstrukturiert, um die weitere Entwicklung verständlicher zu machen.
- In der aktuellsten Version wurde nun zugunsten des Symfony Flex Design Patterns die allgemeine Struktur und Arbeitsweise von Akeneo geändert, um von den Vorteilen, die Symfony Flex bietet, profitieren zu können.
Durch diese Änderung, haben wir unser Docker Setup nochmal überarbeitet und konnten uns dabei sowohl in die neuen Strukturen einarbeiten, als auch einige Verbesserungspotenziale für Akeneo feststellen. Sobald wir neben unseren Projekten wieder mehr Zeit für F&E haben, werden wir die Akeneo-Community hier gern mit Input und Entwicklung unterstützen.
Was ist neu?
Neuerungen bei MySQL & Elasticsearch
Services, welche für Akeneo gebraucht werden, müssen in aktuellen Versionen verwendet werden. So wird nun MySQL Version 8.0.18 oder höher erwartet. Auch Elasticsearch benötigt die relativ neue Version 7.5.2. Durch die neuen Versionen sind die Performance und Features verbessert worden. Sie benötigten aber einige Anpassungen. Bei MySQL mussten wir das Authentifizierungs-Plugin auf das native Passwort setzen (mysql_native_password). Dies ist notwendig, da die PHP Images von 7.3 das standardmäßig genutzte Plugin von MySQL 8 (caching_sha2_password) nicht unterstützen und die Unterstützung erst in künftigen PHP Versionen gegeben ist.
Docker Compose Konfiguration für MySQL
# Konfiguration für den Datenbank Service
...
mysql:
image: mysql
command: --default-authentication-plugin=mysql_native_passwordBei den verwendeten Elasticsearch Images hingegen geht Elasticsearch nun immer von einem Cluster aus und bedarf einiger Node Einstellungen, selbst wenn es nur einen Node gibt. Seit der Elasticsearch Version von Akeneo 3, war es zum Glück nicht mehr notwendig, eine Basic Lizenz von Elasticsearch zu beantragen. Vorher musste man eine neu hochgefahrene Instanz mit einer Datei aktivieren, da sonst nach 30 Tagen die Probe-Lizenz ablief.
Viele Änderungen innerhalb der Prozesse kommen von Symfony Flex selbst. Akeneo hat zusätzlich noch einige Komfortfunktionen hinzugefügt. Das übersichtliche Design ist dabei aber erhalten geblieben.
Symfony Flex Workflow
Um ein neues Bundle zu aktivieren, musste man bislang den Bundle-Namespace in die AppKernel Klasse eintragen. Nun existiert unter “config/bundles.php” eine Datei, welche lediglich die zu aktivierenden Bundle-Namespaces als Array beinhaltet.
Beispiel einer bundles.php
<?php
return [
// Add your bundles here with the associated env.
// Ex:
// Acme\Bundle\AppBundle\AcmeAppBundle::class => ['dev' => true, 'test' => true, 'prod' => true]
Netresearch\Bundle\UiBundle\NetresearchUiBundle::class => [‘dev’ => true, ‘prod’ => true],
];In Akeneo 4 befinden sich die Konfigurationen, wie Dateipfade, Datenbank Zugangsdaten oder Mailer URL nicht mehr in einer “parameters.yml”, sondern entweder als Umgebungsvariablen in der “.env” Datei im Projekt Hauptverzeichnis, oder auch in einer eigenen YAML Datei innerhalb des Verzeichnisses “config/services/*.yml”. Wurden früher Dateien mit bestimmten Suffixen gesucht, wie “parameters_dev.yml”, ist es nun in die jeweiligen Unterverzeichnisse unterteilt.
So kann man eine Konfiguration für eine Entwicklungsumgebung in einer YAML Datei definieren, welche hier liegt: “config/services/dev/*.yml”. Die gleiche Logik trifft auch auf die routing.yml und config.yml zu. Die Pfade können in der neuen Kernel Klasse “src/Kernel.php” nachgelesen werden.
Um während der Installation Beispieldaten aus einem Fixture Bundle zum System hinzuzufügen, reichte es, eine Konfiguration in “parameters.yml” zu ergänzen (installer_data: PimInstallerBundle:minimal). Jetzt ist die Festlegung programmatischer. Es wird erwartet, dass beim Aufruf des Installationsbefehls der Parameter ”catalog” mitgegeben wird, welcher entweder ein absoluter Pfad oder wie früher ein Package-Pfad des Fixtures ist. Außerdem ist zu beachten, dass seit der Akeneo Version 3 kein Standardnutzer admin:admin bei den minimalen Fixtures angelegt wird. Dies erhöht die Sicherheit, muss aber auch bei etwaigen automatischen Prozessen beachtet werden.
Neues Feature: Connections
Neben der gesteigerten Performance ist das neue Feature Connections sehr interessant. Akeneo ist meistens nur ein Bindeglied, welches Informationen bekommt, diese verfeinert und dann an die Zielsysteme weiterreicht. Dafür war bislang auch immer eine Entwicklung notwendig, die entsprechende Systeme anschließt. Durch das neue Feature ist es möglich, bestimmte Systeme direkt durch das Konfigurieren der Endpunkte zu verbinden, was eine Entwicklung überflüssig machen könnte. Wir sind gespannt, es im nächsten passenden Projekt testen zu können.
Integrierte DAM
Nutzer der Enterprise Edition können nun mit einer integrierten DAM Lösung das Problem der Medienhaltung lösen, welches bisher meist durch eine Eigenlösung umgesetzt werden musste.
Was funktioniert anders als gedacht?
Bei einigen Punkten der Entwicklung sind uns Stellen aufgefallen, wo wir entweder noch nicht wissen, wie es besser umsetzbar ist, oder wo einfach noch Verbesserungspotenzial zu finden ist.
So muss man bei der Mit-Installation von Beispieldaten den Parameter “catalog” mitsenden. Allerdings ist dieser Parameter nur im Befehl “pim:installer:db” definiert. Somit kann man nicht den grundsätzlichen Befehl “pim:install” aufrufen, da dort immer der Standardwert ausgewählt wird.
Weiterhin kann man zwar anstatt die Datei “.env” zu befüllen, auch direkt mit Umgebungsvariablen arbeiten, allerdings gibt es einige Prozesse, welche diese ignorieren und nur die Einträge aus der Datei nehmen. Ein Beispiel dafür ist das Versenden von E-Mails innerhalb des Swiftmailer Bundles.
Grundsätzlich ist es über Symfony Flex möglich, Bundles automatisch zu den Routen und aktivierten Bundles hinzuzufügen. Allerdings konnten wir das bisher nicht erreichen. Entweder, weil uns ein sogenanntes Rezept für Flex fehlt oder weil Akeneo es nicht zulässt bzw. eine andere Struktur erwartet. Somit fügen wir weiterhin mittels Skripten unsere Bundle-Informationen (Namespace, Routen, Konfigurationen) in die entsprechenden neuen Verzeichnisse.
Die offiziellen PHP Images von Akeneo laufen noch auf Debian Stretch, lediglich ein Developer Image verwendet Debian Buster. Dies ist relevant, da es Bibliotheken gibt, welche eine Version erwarten, die erst ab Buster verfügbar sind. Da aber das Developer Image etwas anders funktioniert als die bisherigen, mussten wir noch Anpassungen vornehmen.
Generell habe ich persönlich das Gefühl, dass der jetzige Aufbau eher für die eigene Akeneo Cloud Lösung vorbereitet wurde. Auch die Probleme und Fragen innerhalb der Slack Channel beziehen sich oftmals auf Umgebungen, welche mittels vorhandener Akeneo Cloud Hosting Lösungen hochgefahren wurden. Entsprechend findet man im Netz wenig Informationen über die oben aufgeführten Feinheiten des Einrichtens außerhalb einer existierenden Cloud Lösung.
Mein Fazit zu Akeneo 4
Abgesehen von diesen Kleinigkeiten fühlt es sich weiterhin gut an, mit Akeneo zu arbeiten und Teil der Community zu sein. Man sieht, wie viel Kraft in das Produkt gesteckt wird und wir sind gespannt zu sehen, was zukünftig passieren wird.
