In diesem Artikel wird erläutert, wie die Erweiterung von Adobe Commerce durch Adobe Developer App Builder und das Ersetzen großer Teile von benutzerdefiniertem PHP durch eine besser skalierbare Architektur die Skalierbarkeit, Stabilität und Wartbarkeit verbessern kann, die für langfristiges Wachstum in einer realen Produktionsumgebung entwickelt wurden.

Einführung

Seit Jahren ist die PHP-Erweiterbarkeit das Rückgrat der Adobe Commerce-Anpassung. Doch mit zunehmender Ausgereiftheit der Cloud-nativen Architekturen entstehen auch bessere Alternativen. In einer kürzlich erfolgten Implementierung für einen führenden europäischen Anbieter von Mobilitäts- und Finanzdienstleistungen haben wir einen erheblichen Teil der herkömmlichen Adobe Commerce-Modulentwicklung durch App Builder ersetzt – die Cloud-native Erweiterungsplattform von Adobe. Wir haben dies erreicht, indem wir Laufzeitaktionen (Server-lose Funktionen), Ereignisse und APIs genutzt haben, um eine besser skalierbare und wartbare Lösung bereitzustellen. In diesem Artikel werden die Gründe für diese Entscheidung, die Architektur, die Struktur und die Erkenntnisse erläutert.

Übersicht

Ein API-first-Ansatz mit Adobe Commerce kann inkrementell eingeführt werden, indem bewertet wird, welche Funktionen am vorteilhaftesten als Cloud-native Apps außerhalb der Adobe Commerce-Kernplattform ausgeführt werden, und indem diese Funktionen zuerst migriert werden.

Dieser Prozess hat zu einem klaren Ergebnis geführt:

• ~70 % der Funktionen wurden mit App Builder implementiert

• ~30 % verblieben als native PHP-Anpassungen in Adobe Commerce

Dieses Gleichgewicht ermöglichte es uns, die native und die Checkout-bezogene Logik nahe bei Commerce zu halten und gleichzeitig Integrationen, Validierung, Hintergrundverarbeitung und Orchestrierung an App Builder abzugeben, wo Skalierbarkeit, Isolation und Flexibilität bei der Bereitstellung zum Tragen kommen.

Die resultierende Architektur (siehe Abbildung unten, in der nur App Builder-Erweiterungen skizziert werden) spiegelt diesen hybriden Ansatz wider: Adobe Commerce bleibt der Transaktionskern, während App Builder als Backbone für Integration und Automatisierung fungiert. Diese Strategie verbindet Identität (SSO), PIM, ERP, Drittanbieterdienste und benutzerdefinierte Business-Logik über ereignisgesteuerte Abläufe und API Mesh (API Orchestration Service von Adobe).

Architektur im Überblick: Funktionsweise des Hybrid-Modells

Im Mittelpunkt der Lösung steht Adobe Commerce, das sich um das kümmert, was es am besten kann: Katalog, Preisgestaltung, Warenkorb, Checkout und Bestellplatzierung. Wir haben den Transaktionskern bewusst sauber und stabil gehalten und so unnötige Anpassungen innerhalb der Commerce-Laufzeit vermieden.

Alles rund um diesen Kern – Identität, Datenvalidierung, Verfügbarkeitslogik, Hintergrundverarbeitung und Integrationen von Drittanbietern – wird über App Builder und Adobe API Mesh abgewickelt.

Das Käufererlebnis basiert auf der neuen Commerce Storefront (unterstützt durch Edge Delivery Services).

1. Einstiegsebene: CDN, Commerce Storefront und Identität

Sämtlicher Traffic, der von regulären Website-Besuchenden stammt, landet zunächst beim CDN + Edge Delivery Service. Dies gewährleistet optimale Leistung, Sicherheit und globale Bereitstellung, bevor eine Anfrage die Backend-Systeme erreicht.

Die Authentifizierung erfolgt über Keycloak SSO, integriert über:

• Eine App Builder-SSO-Integration

• Ein Standard-PHP-Modul von Adobe Commerce aus dem Marketplace für die Hauptkonfiguration und Einrichtung von SSO

• Dieses Setup ermöglicht es uns, Plattformstabilität mit Cloud-nativer Flexibilität zu kombinieren.

Die wichtigsten Vorteile dieses Ansatzes

• Zentralisiertes Identitäts-Management über ein bewährtes Marketplace-Modul

  Wir nutzen eine gut unterstützte Adobe Commerce-Erweiterung für die SSO-Konfiguration, die Benutzerzuordnung und die zentralen Authentifizierungsabläufe, wodurch die Pflege einer benutzerdefinierten Authentifizierungslogik innerhalb der Commerce-Laufzeit vermieden wird.

• Minimale Modifikation, maximale Sicherheit

  Anstatt das SSO-Modul neu zu schreiben oder zu formieren, wenden wir nur kleine, zielgerichtete Erweiterungen über App Builder an, sodass das Originalmodul vollständig aktualisierbar bleibt.

• API-first-Integrationsmodell

  Da die gesamte Kommunikation ausschließlich auf SSO-APIs beruht, sind wir von den internen Implementierungsdetails des PHP-Moduls entkoppelt. Selbst wenn sich das Modul intern ändert, bleibt unsere Integration stabil, solange der API-Vertrag Bestand hat.

2. Orchestrierungsebene: Adobe API Mesh

Das Herzstück unserer Integrationsarchitektur ist Adobe API Mesh, das als zentraler Orchestrierungs- und Kommunikations-Hub zwischen allen an der Plattform beteiligten Unternehmenssystemen fungiert:

• Commerce Storefront (als Frontend)

• Adobe Commerce

• PIM

• ERP

• Externe Validierungsdienste

• und alle App Builder-Apps

EDS Frontend oder Adobe Commerce richten keine direkten Punkt-zu-Punkt-Integrationen mit jedem dieser Systeme ein, sondern die gesamte Kommunikation wird über API Mesh geleitet.

Die wichtigsten Vorteile der Verwendung von Adobe API Mesh

• Eine einzige Integrationsoberfläche
  Systeme müssen nur einen Backend-Integrationsendpunkt „kennen“: das Mesh. Jede externe Abhängigkeit ist hinter einem einheitlichen API-Gateway verborgen.

• Konsistente API-Verträge
  Alle Systeme kommunizieren über klar definierte und versionierte Verträge, wodurch verborgene Kopplungen vermieden und das Risiko von wesentlichen Änderungen erheblich reduziert wird.

• Vollständige Entkopplung zwischen Backend-Systemen
  PIM, ERP, Validierungsdienste und App Builder-Apps sind vollständig isoliert voneinander. Jedes System kann sich unabhängig weiterentwickeln, ohne dass Änderungen in der gesamten Landschaft erzwungen werden müssen.

• Zentralisierte Sicherheit und Governance
  Authentifizierung, Autorisierung und Traffic-Steuerung werden auf der Mesh-Ebene erzwungen und sind nicht über mehrere benutzerdefinierte Integrationen verteilt.

• Vereinfachte Commerce-Code-Basis
  Adobe Commerce oder Frontend enthält keine komplexe Integrationslogik mehr. Die Lösungen nutzen einfach APIs, die durch das Mesh verfügbar gemacht werden, um die PHP-Ebene schlank und transaktional zu halten.

3. Von der Storefront- und SSO-Ebene verwendete App Builder-Services

Diese Services werden direkt von der Commerce-Storefront- und SSO-Ebene genutzt, nicht von Adobe Commerce, sodass kritische Business-Logik unabhängig von der Commerce-Laufzeit arbeiten kann.

Kundendatenempfänger (SSO → App Builder)

Dieser Service empfängt und synchronisiert Kundendaten aus der SSO-Ebene, ohne dass die Storefront- oder Commerce-Leistung beeinträchtigt wird. Durch die Verwendung von App Builder wird sichergestellt, dass die Verarbeitung sicher und die Skalierbarkeit asynchron ist und dass keine Bereitstellungsabhängigkeit von Adobe Commerce besteht.

Produktverfügbarkeit pro Kunde bzw. Kundin (Storefront → App Builder → PIM)

Die Produktverfügbarkeit wird in Echtzeit auf der Grundlage von Kundenkontext und PIM-Daten ermittelt, bevor Anfragen überhaupt Commerce erreichen. App Builder ermöglicht die unabhängige Skalierung dieser Logik und schützt Commerce vor einer hohen externen Abhängigkeitslast.

Validierung von Unternehmensdaten (Dun & Bradstreet) (Storefront → App Builder → Drittanbieter)

Die Validierung wird direkt von der Storefront über App Builder + API Mesh ausgelöst und mithilfe von Drittanbieter-Services überprüft, wodurch die Latenz externer Services und Fehler vollständig von Adobe Commerce isoliert bleiben.

Externe ID-Umleitungs-Engine (Storefront → App Builder)

Eingehender Traffic von externen Systemen wird über App Builder verarbeitet und zugeordnet, bevor er in die Storefront aufgenommen wird. Dies ermöglicht eine sichere Traffic-Normalisierung, flexible Umleitungsregeln und Risikofreiheit für den Commerce-Kern.

4. Commerce Storefront Prerendering: SEO ohne Kompromisse bei UX

Die AEM Commerce-Storefront ist ein modernes, Frontend-gesteuertes Programm, das hauptsächlich JavaScript nutzt, um Produktdaten in den Browser zu laden. Dies bietet zwar ein ausgezeichnetes Anwendererlebnis, stellt jedoch eine klassische SPA-Herausforderung dar:

Suchmaschinen-Crawler und Browser-lose Systeme erhalten oft fast leeres HTML, da sie JavaScript nicht zuverlässig ausführen.

Um diese Anforderung zu erfüllen, haben wir AEM Commerce Prerendering implementiert, eine offizielle Adobe-Lösung, die auf App Builder basiert.

Wie das Prerendering in unserer Architektur funktioniert

Die Prerender-App von App Builder:

• Liest Produktdaten direkt aus dem Adobe Commerce Catalog Service

• Generiert vollständig hydrierte HTML-Seiten basierend auf vordefinierten Vorlagen

• Speichert die vorgerenderte Ausgabe in einem eigenen Blob-Speicher

Die Commerce Storefront wird dann so konfiguriert, dass dieser Speicher als Überlagerungsquelle verwendet wird. Wenn entweder:

• Ein Suchmaschinen-Crawler

• Ein Browser-loser Client eine Produkt-URL anfordert

Erhält er sofort eine vollständig gerenderte HTML-Antwort mit echten Produktdaten, ohne dass JavaScript ausgeführt wird.

Gleichzeitig:

• Erhalten normale Benutzende weiterhin das standardmäßige SPA-Erlebnis mit Live-PDP-Rendering im Browser.

Warum App Builder hier der Hauptakteur ist

App Builder ist die zentrale Steuerungsebene für den gesamten Prerendering-Prozess. Damit können wir Folgendes definieren:

• Häufigkeit des Datenabrufs

• Welche Produkte und Gebietsschemata einbezogen werden

• HTML- und JSON-LD-Struktur

• Generierung von SEO-Metadaten

All dies kann durch kleine Änderungen an der App Builder-Konfiguration angepasst werden, ohne dass es zu Ausfallzeiten für die Haupt-Storefront oder Adobe Commerce kommt.

Adobe stellt auch ein Starter-Kit für die Prerendering-App von App Builder zur Verfügung, mit dem wir die Lösung in kürzester Zeit produktionsbereit machen und sofortige SEO-Verbesserungen erreichen konnten.

Die wichtigsten Vorteile dieses Ansatzes

• Erhebliche SEO-Verbesserungen
  Crawler erhalten vollständig gerenderte Produktseiten mit strukturierten Daten anstelle von leerem HTML.

• Keine Auswirkungen auf die Storefront-Leistung
  Regelmäßige Benutzende profitieren weiterhin vom schnellen, dynamischen SPA-Erlebnis.

• Bereitstellungsmodell ohne Risiko
  Die gesamte Prerendering-Logik wird außerhalb von Adobe Commerce und der Storefront-Laufzeit ausgeführt.

• Vollständige Steuerung über App Builder
  Prerendering-Regeln, Datenmodelle und Zeitpläne können ohne Plattform-Neubereitstellungen angepasst werden.

5. Bestellungen und ERP-Synchronisierung: Asynchron per Design

Checkout und Bestellplatzierung werden weiterhin vollständig innerhalb von Adobe Commerce abgewickelt, sodass die Datenintegrität und die Transaktionskonsistenz erhalten bleiben. Sobald eine Bestellung erstellt wurde, wird der Exportvorgang von einem dedizierten Export-Tool für geplante Aufträge übernommen, das auf App Builder basiert.

Dieses Export-Tool synchronisiert Bestellungen asynchron mit dem ERP-System, außerhalb des Zyklus von Storefronts und Commerce-Anfragen.

Die wichtigsten Vorteile dieses Ansatzes

• Die Verfügbarkeit der Storefront ist vollständig von der ERP-Verfügbarkeit entkoppelt
  Selbst wenn das ERP-System langsam oder vorübergehend nicht verfügbar ist, können Kundinnen und Kunden weiterhin ohne Unterbrechung Bestellungen aufgeben.

• Keine Blockierung des Checkouts aufgrund von nachgelagerten Fehlern
  Die Bestellerstellung ist nicht mehr von Echtzeit-ERP-Antworten abhängig, wodurch eine Hauptquelle für Konversionsrisiken beseitigt wird.

• Sichere Wiederholungen und gesteuerter Datenfluss
  App Builder ermöglicht die geplante Ausführung, Wiederholungsmechanismen und die Fehlerbehandlung, ohne dass die Commerce-Leistung beeinträchtigt wird.

• Unabhängige Skalierung und Bereitstellung
  Die Bestllsynchronisierung kann je nach Volumen skaliert werden, ohne dass eine erneute Bereitstellung erforderlich ist oder die Leistung von Adobe Commerce beeinträchtigt wird.

Warum ein vollständiger Wechsel zu App Builder?

Eine der frühesten und wichtigsten architektonischen Entscheidungen war, App Builder nicht als vollständigen Ersatz für PHP-Module zu behandeln und auch nicht alles standardmäßig auf PHP zu setzen, „weil es so schon immer gemacht wurde“.

Stattdessen wurden alle Anforderungen über einen einfachen Filter verarbeitet:

Was verblieb in PHP (die 30 %)

Wir haben PHP-Anpassungen nur dort beibehalten, wo sie wirklich hingehören:

• Anpassungen beim Checkout und bei Bestellplatzierungen

• Preisgestaltung, Warenkorb und Angebotslogik

• Deep GraphQL und leistungsabhängige Hooks

• Bereiche, in denen die Latenz nahe null und vollständig synchron sein muss

Dies sind Orte, an denen direkter Datenbankzugriff, enge Kopplung an Commerce-Interna und die Kontrolle des Anfragezyklus weiterhin absolut gerechtfertigt sind.

Was wurde zu App Builder verschoben (die 70 %)

Alles andere wurde entfernt:

• Identität und SSO-Orchestrierung

• Kunden- und Firmenvalidierung

• Ermittlung der Produktverfügbarkeit

• Externe Systemkoordination

• Integration von ERP und Drittanbietern

• Umleitungs-Engines und Automatisierung

• Aufträge und Planungen im Hintergrund

Dies sind alle Bereiche, in denen PHP-Module seit jeher Probleme haben:

• enge Kopplung

• schwierige Bereitstellungen

• mangelhafte Fehlerisolierung

• und begrenzte Skalierbarkeit

Die wichtigsten Vorteile

Durch die Verlagerung von etwa 70 % der Geschäfts- und Integrationslogik zu App Builder haben wir die Art und Weise grundlegend verändert, wie die Plattform aufgebaut, bereitgestellt und betrieben wird. Die Auswirkungen waren nicht nur bei der Qualität der Architektur sichtbar, sondern auch bei der Geschwindigkeit der Bereitstellung, der Systemstabilität und der langfristigen Kostenkontrolle.

Unabhängige Bereitstellungen

Da App Builder den Großteil der Integrationen und Unternehmens-Workflows verarbeitet, ist für die meisten Änderungen keine vollständige Neubereitstellung von Adobe Commerce mehr erforderlich. Integrationsaktualisierungen, Validierungen und Hintergrundprozesse können unabhängig bereitgestellt werden, wodurch die Anzahl der Fehler erheblich verringert wird:

• Veröffentlichungsrisiko

• Bereitstellungsfenster

• Koordinationsaufwand zwischen Teams

Dies allein führte zu einer der größten Produktivitätssteigerungen im Tagesgeschäft.

Bessere Skalierbarkeit dort, wo es am wichtigsten ist

Bisher hatten Traffic-Spitzen bei:

• Verfügbarkeitsprüfungen

• Unternehmensvalidierungen

• oder externen API-Aufrufen

direkte Auswirkungen auf die Leistung von Commerce.

Diese Arbeitslasten können nun unabhängig in App Builder skaliert werden. Das Ergebnis ist:

• Die Checkout-Leistung bleibt stabil

• Commerce-Ressourcen sind nur für Transaktionsarbeitslasten reserviert

• und unvorhersehbarer Traffic von Drittanbietern stellt keine Bedrohung für die Konversionsraten mehr dar

Echte Fehlerisolierung

Eine der wichtigsten Verbesserungen ist die Fehlereindämmung. Wenn es bei Drittanbietersystemen zu Latenz, Leistungsbeeinträchtigung oder Ausfällen kommt, geschieht Folgendes:

• App Builder fängt die Auswirkungen ab

• Es wird eine Wiederholungs- und Fallback-Logik angewendet

• und Adobe Commerce ist weiterhin voll funktionsfähig

Dadurch wurde eine ganze Reihe von Vorfallsszenarien beseitigt, die zuvor zu teilweisen oder vollständigen Ausfallzeiten der Storefront geführt hatten.

Klarere Code-Verantwortlichkeiten und klare Zuständigkeiten

Die Plattform hat jetzt klare architektonische Grenzen:

• Adobe Commerce → Transaktionslogik, Checkout, Preisgestaltung, Warenkorb

• App Builder → Integrationen, Orchestrierung, Validierung, Hintergrundaufträge

Diese Trennung:

• vereinfacht das Onboarding von neuen Entwickelnden

• verringert Team-übergreifende Abhängigkeiten

• und verhindert die allmähliche Erosion des Commerce-Kerns durch integrationsintensiven benutzerdefinierten Code.

Zukunftssicher per Design

Diese Hybridarchitektur ist vollständig auf die langfristige SaaS-, API-first- und Composable-Commerce-Strategie von Adobe abgestimmt. Durch die Externalisierung der meisten benutzerdefinierten Logik geschieht Folgendes:

• Plattformaktualisierungen werden sicherer

• Die Zwangsbindung auf Code-Ebene wird reduziert

• Die Lösung ist bereits für einen Wechsel zu Adobe Commerce as a Cloud Service vorbereitet

Wir haben nicht nur die heutigen Anforderungen gelöst, sondern eine Plattform geschaffen, die strukturell bereit für die zukünftige Entwicklung von Adobe Commerce ist.