In dit artikel wordt uitgelegd hoe door opnieuw na te denken over de uitbreidbaarheid van Adobe Commerce door Adobe Developer App Builder en de vervanging van grote delen van aangepaste PHP met een schaalbaardere architectuur de schaalbaarheid, stabiliteit en onderhoudsvriendelijkheid kunnen worden verbeterd, ontworpen voor groei op lange termijn in een echte productieomgeving.

Inleiding

PHP-uitbreidbaarheid is al jaren de ruggengraat van Adobe Commerce-aanpassingen. Maar terwijl cloudnative architecturen volwassen worden, doen betere alternatieven dat ook. In een recente implementatie voor een toonaangevende Europese aanbieder van mobiliteit en financiële diensten hebben we een aanzienlijk deel van de traditionele ontwikkeling van Adobe Commerce-modules vervangen door het App Builder: het cloudnative uitbreidingsplatform van Adobe App Builder. We hebben dit bereikt door runtimeacties (serverloze functies), gebeurtenissen en API's te gebruiken voor een schaalbaardere en onderhoudsvriendelijkere oplossing. In dit artikel worden de redenen voor die beslissing, de architectuurstructuur en de lessen uitgelegd.

Overzicht

Een API-gerichte aanpak met Adobe Commerce kan geleidelijk steeds meer worden toegepast door te evalueren welke functies het meest geschikt zijn als cloudnative apps buiten het Adobe Commerce-kernplatform en door deze functies eerst te migreren.

Dit proces heeft tot een duidelijk resultaat geleid:

• ~70% van de functionaliteit is geïmplementeerd met App Builder

• ~30% resteert als native Adobe Commerce PHP-aanpassingen

Dankzij deze balans konden we een native en kassagerelateerde logica dicht bij Commerce houden terwijl we integraties, validatie, achtergrondverwerking en orkestratie konden afwentelen op App Builder, waar schaalbaarheid, isolatie en implementatieflexibiliteit het beste werken.

De resulterende architectuur (zie het onderstaande diagram, waarin alleen App Builder-extensies worden weergegeven) weerspiegelt deze hybride aanpak: Adobe Commerce blijft de transactionele kern, terwijl App Builder fungeert als integratie- en automatiseringsruggengraat fungeert. Met deze strategie worden identiteit (SSO), PIM, ERP, externe diensten en aangepaste bedrijfslogica verbonden door middel van door gebeurtenissen aangestuurde flows en API Mesh (de API Orchestration-service van Adobe).

Architectuur doorlopen: Zo werkt het hybride model

Adobe Commerce bevindt zich in de kern van de oplossing en doet waar het goed in is: catalogus, prijzen, winkelwagen, afrekenen en bestellingen plaatsen. We hebben de transactionele kern bewust schoon en stabiel gehouden, zonder onnodige aanpassingen binnen de Commerce-runtime.

Alles rondom die kern - identiteit, gegevensvalidatie, beschikbaarheidslogica, achtergrondverwerking en externe integraties - wordt afgehandeld door App Builder en Adobe API Mesh.

De ervaring van winkelbezoekers is gebouwd op de nieuwe Commerce Storefront (aangestuurd door Edge Delivery Services).

1. Invoerlaag: CDN, Commerce Storefront en Identity

Al het verkeer van geregelde websitebezoekers komt eerst bij de CDN + Edge Delivery Service voor optimale prestaties, veiligheid en wereldwijde levering voordat aanvragen bij de back-endsystemen aankomen.

Verificatie wordt afgehandeld door Keycloak SSO, geïntegreerd via:

• Een App Builder SSO-integratie

• Een standaard Adobe Commerce PHP-module van de Marketplace voor de kernconfiguratie en -installatie van SSO

• Dankzij deze installatie kunnen we stabiliteit van het platform combineren met flexibiliteit in de cloud.

De belangrijkste voordelen van deze aanpak

• Gecentraliseerd identiteitsbeheer via een bewezen Marketplace-module

  We baseren ons op een goed ondersteunde Adobe Commerce-extensie voor SSO-configuratie, gebruikerstoewijzing en kernverificatieflows, waardoor geen aangepaste verificatielogica binnen de Commerce-runtime hoeft te worden onderhouden.

• Minimale wijzigingen, maximale veiligheid

  In plaats van de SSO-module te herschrijven of te splitsen passen we alleen kleine, doelgerichte extensies toe via App Builder, zodat de oorspronkelijke module volledig upgradebaar blijft.

• API-gericht integratiemodel

  Aangezien alle communicatie strikt op SSO-API's is gebaseerd, worden we losgekoppeld van interne implementatiedetails van de PHP-module. Ook als de module intern verandert, blijft onze integratie stabiel zolang het API-contract geldt.

2. Orkestratielaag: Adobe API Mesh

In de kern van onze integratiearchitectuur bevindt zich Adobe API Mesh, dat fungeert als centrale orkestratie- en communicatiehub tussen alle bedrijfssystemen die bij het platform betrokken zijn:

• Commerce Storefront (als front-end)

• Adobe Commerce

• PIM

• ERP

• services voor externe validatie

• en alle App Builder-toepassingen

In plaats van EDS Frontend of Adobe Commerce directe, rechtstreekse integratie met elk van deze systemen te laten bewerkstelligen wordt alle communicatie gerouteerd via API Mesh.

Belangrijkste voordelen van het gebruik van Adobe API Mesh

• Enkelvoudig integratieoppervlak
  Systemen hoeven maar één back-end-integratie-eindpunt te kennen: de Mesh. Elke externe afhankelijkheid is verborgen achter een uniforme API-gateway.

• Consistente API-contracten
  Alle systemen communiceren via goed-gedefinieerde en geversioneerde contracten, waardoor verborgen koppelingen niet meer nodig zijn en de kans op wijzigingen die de structuren verbreken, drastisch wordt verkleind.

• Volledige ontkoppeling tussen back-endsystemen
  PIM, ERP, de validatieservices en App Builder-apps zijn volledig van elkaar geïsoleerd. Elk systeem kan zelfstandig evolueren zonder wijzigingen in het hele landschap te forceren.

• Gecentraliseerde beveiliging en governance
  Verificatie, autorisatie en verkeersbeheer worden afgedwongen op het niveau van de Mesh, en niet verspreid over meerdere aangepaste integraties.

• Vereenvoudigde Commerce codebase
  Adobe Commerce en Frontend bevatten geen complexe integratielogica meer. Ze verbruiken gewoon API's die door de Mesh worden weergegeven, waardoor de PHP-laag schoon en transactioneel blijft.

3. De App Builder-services die door de Storefront- en SSO-laag worden gebruikt

Deze services worden rechtstreeks verbruikt door de Commerce Storefront- en SSO-laag, niet door Adobe Commerce, waardoor kritieke bedrijfslogica onafhankelijk van de Commerce-runtime kan werken.

Customer Data Receiver (SSO → App Builder)

Deze service ontvangt en synchroniseert klantgegevens van de SSO-laag zonder invloed op de prestaties van Storefront of Commerce. Het gebruik van App Builder zorgt voor veilige verwerking, asynchrone schaalbaarheid en nul implementatieafhankelijkheid van Adobe Commerce.

Productbeschikbaarheid per klant (Storefront → App Builder → PIM)

Productbeschikbaarheid wordt in real time opgelost op basis van de klantcontext en PIM-gegevens aanvragen Commerce bereiken. Met App Builder kan deze logica onafhankelijk schalen en beschermt Commerce tegen een zware belasting van externe afhankelijkheid.

Bevestiging van bedrijfsvalidatie (Dun & Bradstreet) (Storefront → App Builder → externe partij)

Validatie wordt direct geactiveerd vanaf de store-interface via App Builder + API Mesh en geverifieerd via externe services, waardoor de latentie en mislukkingen van externe services volledig van Adobe Commerce geïsoleerd blijven.

External ID Redirect Engine (Storefront → App Builder)

Binnenkomend verkeer van externe systemen wordt verwerkt en in kaart gebracht via App Builder alvorens naar de store-interface te gaan, die een veilige verkeersnormalisatie, flexibele omleidingsregels en nul risico voor de kern van Commerce mogelijk maakt.

4. Commerce Storefront Prerendering: SEO zonder beïnvloeding van de UX

De AEM Commerce-store-interface is een moderne, door front-end aangestuurde toepassing die sterk afhankelijk is van JavaScript om productgegevens in de browser te laden. Terwijl dit een uitstekende gebruikerservaring oplevert, gaat het wel gepaard met een klassieke SPA-uitdaging:

Zoekmachinecrawlers en browserloze systemen ontvangen vaak bijna lege HTML, aangezien ze JavaScript niet altijd betrouwbaar uitvoeren.

Om dit op te lossen hebben we AEM Commerce Prerendering geïmplementeerd, een officiële Adobe-oplossing op basis van App Builder.

Zo werkt prerendering in onze architectuur

De prerendertoepassing van App Builder:

• Leest productgegevens rechtstreeks van de Adobe Commerce Catalog-service

• Genereert volledig gehydrateerde HTML-pagina's op basis van vooraf gedefinieerde sjablonen

• Slaat de geprerenderde uitvoer op in een eigen blobopslag

Commerce Storefront wordt vervolgens geconfigureerd om deze opslag te gebruiken als overlaybron. Wanneer ofwel

• een zoekmachinecrawler

• of een browserloze client een product-URL aanvraagt,

ontvangt deze ontvangt onmiddellijk een volledig gerenderde HTML-reactie met echte productgegevens, zonder dat er JavaScript wordt uitgevoerd.

Tegelijkertijd:

• Geregelde gebruikers ontvangen nog steeds de standaard SPA-ervaring met live PDP die in de browser rendert.

Waarom is App Builder hier de kern-enabler?

App Builder is het centrale beheergebied voor het volledige prerenderingproces. Hiermee kunnen we het volgende definiëren:

• Frequentie voor ophalen van gegevens

• Welke producten en landinstellingen zijn inbegrepen

• HTML- en JSON-LD-structuur

• SEO-metagegevensgeneratie

Dit kan allemaal worden aangepast door kleine configuratiewijzigingen in App Builder, zonder uitvaltijd voor de voornaamste store-interface of Adobe Commerce.

Adobe heeft ook een startkit voor de App Builder-prerendertoepassing, we de oplossing in heel korte tijd productieklaar konden maken en een directe SEO-stijging bereikten.

Belangrijkste voordelen van deze aanpak

• Grote SEO-verbetering
  Crawlers ontvangen volledig gerenderde productpagina's met gestructureerde gegevens in plaats van lege HTML.

• Geen invloed op de prestaties van de store-interface
  Geregelde gebruikers behouden de snelle, dynamische SPA-ervaring.

• Risicoloos implementatiemodel
  Alle prerenderende logica wordt uitgevoerd buiten de runtime van Adobe Commerce en Storefront.

  - Volledige controle via App Builder
  Prerenderingregels, gegevensmodellen en schema's kunnen worden aangepast zonder nieuwe implementatie van platformen.

**### 5. Synchronisatie van bestellingen en ERP: bewust asynchroonAfrekenen en het plaatsen van bestellingen worden nog steeds volledig verwerkt binnen Adobe Commerce, zodat de gegevensintegriteit en de consistentie van transacties behouden blijven. Zodra een bestelling wordt gemaakt, wordt het exportproces overgenomen door een speciale Scheduled Order Exporter die is gemaakt op basis van App Builder.Deze exporter synchroniseert bestellingen asynchroon met ERP, buiten de levenscyclus van aanvragen van de store-interface en Commerce.#### Belangrijkste voordelen van deze aanpak- Storefront-bedrijfstijd is volledig losgekoppeld van ERP-beschikbaarheid
Zelfs als ERP traag of tijdelijk niet beschikbaar is, kunnen klanten zonder onderbreking bestellingen blijven plaatsen.

• Geen blokkering van afrekenen vanwege downstreamproblemen
  Het maken van bestellingen is niet meer afhankelijk van ERP-reacties in real time, wat een belangrijke bron van conversierisico's uitschakelt.

• Veilig opnieuw proberen en gecontroleerde gegevensstroom
  App Builder maakt geplande uitvoering, mechanismen voor opnieuw proberen en de afhandeling van fouten mogelijk zonder invloed op de prestaties van Commerce.

• Onafhankelijk schalen en implementeren
  Synchronisatie van bestellingen kan worden geschaald op basis van volume zonder hernieuwde implementatie of prestatie-effecten voor Adobe Commerce.**

Waarom geen volledige overstap naar App Builder?

Een van de vroegste en belangrijkste architecturele beslissingen was om App Builder niet te behandelen als een totale vervanging voor PHP-modules, en ook niet om alles standaard in te stellen op PHP "omdat dat altijd zo is gedaan".

In plaats daarvan werd elke eis door een eenvoudig filter gehaald:

Dit is in PHP gebleven (30%)

We behielden alleen PHP-aanpassingen wanneer ze er echt thuishoren:

• Aanpassingen voor afrekenen en plaatsing van bestellingen

• Prijzen, winkelwagen en logica voor aanhalingstekens

• Deep GraphQL en prestatiegevoelige hooks

• Gebieden waar latentie bijna nul en volledig synchroon moet zijn

Dit zijn plaatsen waar directe databasetoegang, strakke koppeling met Commerce-internals en beheer van de levenscyclus van aanvragen nog steeds absoluut gerechtvaardigd zijn.

Dit is naar App Builder verplaatst (70%)

Alle andere onderdelen zijn verplaatst:

• Identiteit en SSO-orkestratie

• Validatie van klanten en bedrijven

• Beslissing over productbeschikbaarheid

• Extern-systeemcoördinatie

• ERP en integratie van derden

• Doorstuur-engines en automatisering

• Achtergrondtaken en -planners

Dit zijn allemaal gebieden waar PHP-modules historisch onder lijden:

• strakke koppeling

• harde implementaties

• slechte isolatie van fouten

• en beperkte schaalbaarheid

Belangrijkste gewonnen voordelen:

Door ruwweg 70% van de bedrijfs en integratielogica naar App Builder te verschuiven, brachten we een fundamentele verandering aan in de manier waarop het platform was gebouwd, geïmplementeerd en bediend. De impact was niet alleen zichtbaar in architectuurkwaliteit, maar ook in leveringssnelheid, systeemstabiliteit, en kostenbeheersing op lange termijn.

Onafhankelijke implementaties

Wanneer App Builder het grootste deel van de integratie- en bedrijfsworkflows verwerkt, is voor de meeste wijzigingen geen volledige Adobe Commerce-herimplementatie meer vereist. Updates, validaties en achtergrondprocessen van de integratie kunnen onafhankelijk worden geïmplenteerd, wat een drastische verlaging betekent van het volgende:

• risico van vrijgave

• implementatievensters

• coördinatieoverhead tussen teams

Dit alleen al werd een van de grootste productiviteitswinsten in de dagelijkse activiteiten.

Betere schaalbaarheid waar dat het belangrijkst is

Vroeger leidden verkeerspieken in:

• beschikbaarheidscontroles

• bedrijfsvalidatie

• of externe API-aanroepen

rechtstreeks tot slechtere prestaties van Commerce.

Nu worden deze werklasten onafhankelijk geschaald in App Builder. Als gevolg daarvan gebeurt dit:

• prestaties bij afrekenen blijven stabiel

• Commerce-resources zijn alleen gereserveerd voor transactionele werklasten

• en er is geen onvoorspelbaar extern verkeer meer dat de conversiepercentages bedreigt

Echte isolatie van fouten

Een van de meest kritieke verbeteringen is het isoleren van fouten. Wanneer externe systemen latentie, degradatie of uitval ervaren, gebeurt het volgende:

• App Builder absorbeert de impact op

• logica voor opnieuw proberen en alternatieven wordt daar toegepast

• en Adobe Commerce blijft volledig operationeel

Dit heeft effectief een hele klasse incidentscenario's geëlimineerd die vroeger leidde tot gedeeltelijke of volledige uitval van de store-interface.

Duidelijkere code-eigendom en duidelijke verantwoordelijkheden

Het platform heeft nu duidelijke architecturale grenzen:

• Adobe Commerce → transactielogica, afrekenen, prijzen, winkelwagen

• App Builder → Integraties, orkestratie, validatie, achtergrondtaken

Deze scheiding:

• vereenvoudigt onboarding van nieuwe ontwikkelaars

• vermindert afhankelijkheid tussen teams

• en voorkomt de geleidelijke uitholling van de kern van Commerce door aangepaste, zware integratiecode.

Bewust toekomstbestendig

Deze hybride architectuur is volledig op een lijn met de langetermijnstrategie van SaaS, API-gerichtheid en samenstelbare commerce. Door de meeste aangepaste logica te externaliseren gebeurt er dit:

• platformupgrades worden veiliger

• beperkte vendor lock-in op codeniveau

• en de oplossing is al voorbereid op een verplaatsing naar Adobe Commerce as a Cloud Service

We hebben niet alleen de eisen van vandaag opgelost, we hebben een platform gebouwd dat structureel klaar is voor de richting waarin Adobe Commerce zich ontwikkelt.