I den här artikeln beskrivs hur omtänkande av Adobe Commerce-utbyggbarheten, genom Adobe Developer App Builder, och ersättning av stora delar av anpassad PHP med en mer skalbar arkitektur, kan förbättra skalbarhet, stabilitet och underhållbarhet. På så sätt är det möjligt att utforma för långsiktig tillväxt i en verklig produktionsmiljö.

Introduktion

I åratal har PHP-utbyggbarheten varit ryggraden i anpassningar med Adobe Commerce. Men när de molnbaserade arkitekturerna är redo finns det bättre alternativ. I en nyligen genomförd implementering för en ledande Europeisk leverantör av mobilitet och finansiella tjänster ersatte vi en stor del av den traditionella Adobe Commerce-modulutvecklingen med App Builder – Adobes molnbaserade utbyggbarhetsplattform. Vi åstadkom det här genom att ta vara på exekveringsåtgärder (serverlösa funktioner), händelser och API:er för att leverera en mer skalbar och underhållande lösning. I den här artikeln beskrivs orsakerna till beslutet, arkitekturen och vad vi kunde lära oss.

Översikt

Ett API-centrerat tillvägagångssätt med Adobe Commerce kan tillämpas stegvis genom att utvärdera vilka funktioner som skulle vara mest fördelaktiga om de körs som molnbaserade appar utanför Adobe Commerce-kärnplattformen och sedan migrera dessa funktioner först.

Den här processen ledde till ett tydligt resultat:

• Cirka 70 % av funktionaliteten implementerades med App Builder

• Cirka 30 % förblev som inbyggda Adobe Commerce PHP-anpassningar

Den här balansen gjorde att vi kunde hålla den inbyggda och utcheckningsrelaterade logiken nära Commerce, samtidigt som vi kunde avlasta integreringar, validering, bakgrundsbearbetningen och samordningen till App Builder. Där kan skalbarhet, isolering och driftsättningsflexibiliteten fungera som bäst.

Arkitekturen (se bilden nedan som endast visar App Builder-tillägg) återspeglar den här hybrida strategin: Adobe Commerce är fortfarande den transaktionella grunden medan App Builder fungerar som integrerings- och automatiseringsryggraden. Den här strategin länkar samma identitet (SSO), PIM, ERP, tredjepartstjänster och anpassad affärslogik via händelsestyrda flöden och API Mesh (Adobe API Orchestration-tjänster).

Genomgång av arkitekturen: Så fungerar hybrida modeller

Kärnan i lösningen är Adobe Commerce, som gör det den gör bäst: Katalogisering, prissättning, kundvagn, utcheckning och orderplacering. Vi höll avsiktligt den transaktionella grunden ren och stabil för att undvika onödig anpassning i Commerce-körningar.

Allt kring kärnan – identitet, datavalidering, tillgänglighetslogik, bakgrundsbearbetning och tredjepartsintegreringar – hanteras via App Builder och Adobe API Mesh.

Köparupplevelsen bygger på vår nya Commerce-webbutik (drivs av tjänster för edge-leverans).

1. Startlager: CDN, Commerce-webbutik och identitet

All trafik från vanliga webbplatsbesökare kommer först till CDN + tjänsten för edge-leverans vilket erbjuder optimal prestanda, säkerhet och global leverans innan någon begäran når serversystemet.

Autentiseringen hanteras via Keycloak SSO som är integrerad via:

• En integrering med App Builder SSO

• En Adobe Commerce PHP-standardmodul från Marketplace för konfigurationen av SSO

• Med den här konfigurationen kan vi kombinera plattformsstabilitet med molnbaserad flexibilitet.

Viktiga fördelar med den här metoden

• Centraliserad identitetshantering via en beprövad Marketplace-modul

  Vi förlitar oss på ett Adobe Commerce-tillägg som stöds för SSO-konfiguration, användarmappning och kärnautentiseringsflöden, vilket gör att det inte går att underhålla anpassad autentiseringslogik i Commerce.

• Minimala ändringar, maximal säkerhet

  I stället för att skriva om eller förgrena SSO-modulen tillämpar vi endast små och målinriktade tillägg via App Builder, vilket gör att den ursprungliga modulen kan uppgraderas helt.

• API-baserad integreringsmodell

  Eftersom all kommunikation bygger enbart på SSO-API:er är vi inte längre kopplade till den interna implementeringsinformationen i PHP-modulen. Även om modulen ändras internt är integreringen stabil så länge som API-avtalet gäller.

2. Samordningslager: Adobe API Mesh

I grunden ligger vår integreringsarkitektur i Adobe API Mesh, som fungerar som en central samordnings- och kommunikationshubb mellan alla affärssystem som är involverade i plattformen:

• Commerce-webbutik (lokalt)

• Adobe Commerce

• PIM

• ERP

• externa valideringstjänster

• och alla App Builder-appar

Istället för att EDS Frontend eller Adobe Commerce upprättar direkta punkt till punkt-integreringar med vart och ett av dessa system, dirigeras all kommunikation via API Mesh.

Viktiga fördelar med Adobe API Mesh

• En integrationsyta
  System behöver bara känna till en slutpunkt för serverintegrering: Mesh. Alla externa beroenden döljs bakom en enhetlig API-gateway.

• Konsekventa API-avtal
  Alla system kommunicerar genom väldefinierade och versionshanterade avtal, vilket eliminerar dolda kopplingar och minskar risken dramatiskt för att ändringarna bryts.

• Fullständig frikoppling mellan serversystem
  PIM, ERP, valideringstjänster och App Builder-appar är helt isolerade från varandra. Alla system kan utvecklas oberoende av varandra utan att man behöver göra ändringar över hela systemet.

• Centraliserad säkerhet och hantering
  Autentisering, auktorisering och trafikkontroll används på Mesh-nivå istället för att vara spridda över flera anpassade integreringar.

• Förenklad Commerce-kodbas
  Adobe Commerce eller Frontend innehåller inte längre någon komplex integreringslogik. De använder helt enkelt API:er som exponeras av Mesh, vilket håller PHP-lagret enkelt och transaktionellt.

3. App Builder-tjänster som används av webbutiken och SSO-lager

Dessa tjänster används direkt av Commerce-webbutiken och SSO, inte av Adobe Commerce, vilket gör att viktig affärslogik kan användas oberoende av Commerce.

Kunddatamottagare (SSO → App Builder)

Den här tjänsten tar emot och synkroniserar kunddata från SSO-lagret utan att påverka webbutiken eller Commerce-prestandan. Med App Builder får du säker bearbetning, asynkron skalbarhet och inget driftsättningsberoende för Adobe Commerce.

Produkttillgänglighet per kund (Webbutik → App Builder → PIM)

Produkttillgängligheten löses i realtid baserat på kundsammanhang och PIM-data innan förfrågningar når Commerce. App Builder gör att logiken kan skalas oberoende och skyddar Commerce från en stor extern beroendebelastning.

Verifiering av företagsdata (Dun & Bradstreet) (Webbutik → App Builder → Tredje part)

Valideringen aktiveras direkt från butiken via App Builder + API Mesh och verifieras med tredjepartstjänster, vilket gör att den externa tjänstens svarstid och fel hålls helt isolerade från Adobe Commerce.

Omdirigeringsmotor för externt ID (Webbutik → App Builder)

Inkommande trafik från externa system bearbetas och mappas via App Builder innan de når webbutiken, vilket möjliggör säker trafiknormalisering, flexibla omdirigeringsregler och ingen risk för Commerce-kärnan.

4. Commerce Prerendering för webbutiken: SEO utan att kompromissa med användarupplevelsen

AEM Commerce-webbutiken är ett modernt och lokalt drivet program som är starkt beroende av JavaScript för att läsa in produktdata i webbläsaren. Det här är en utmärkt användarupplevelse men introducerar en klassisk SPA-utmaning:

Sökmotorers spindlar och system utan webbläsare får ofta nästan tomma HTML-filer eftersom de inte kör JavaScript på ett tillförlitligt sätt.

För att lösa det här implementerade vi AEM Commerce Prerendering, en officiell Adobe-lösning som bygger på App Builder.

Så här fungerar förrendering i vår arkitektur

App Builder-appen för förrendering:

• Läser produktdata direkt från Adobe Commerce Catalog-tjänsten

• Skapar fullständigt implementerade HTML-sidor baserat på fördefinierade mallar

• Lagrar förrenderade utdata i sin egen blob storage

Commerce-webbutiken är sedan konfigurerat att använda det här lagringsutrymmet som en överläggskälla. När antingen:

• En sökmotors spindel

• Alla webbläsarlösa klienter begär en produkt-URL

Det får omedelbart ett fullständigt renderat HTML-svar med verkliga produktdata, utan att något JavaScript behöver köras.

Samtidigt:

• Vanliga användare får fortfarande den vanliga SPA-upplevelsen med aktiv PDP-rendering i webbläsaren.

Därför är App Builder den centrala leverantören här

App Builder är den centrala kontrollen för hela förrenderingen. Det här låter oss definiera:

• Frekvens för datainhämtning

• Vilka produkter och språk som ingår

• HTML- och JSON-LD-strukturer

• Generering av SEO-metadata

Allt det här kan justeras genom små konfigurationsändringar i App Builder helt utan driftstopp för huvudwebbutiken eller Adobe Commerce.

Adobe har också ett startpaket för App Builder-appen för förrendering som gör att vi kan skapa lösningen på en mycket kort tid och få en direkt SEO-uppgradering.

Viktiga fördelar med den här metoden

• Enorm SEO-förbättring
  Spindlar tar emot fullständigt återgivna produktsidor med strukturerade data i stället för tomma HTML-filer.

• Ingen påverkan på webbutikens prestanda
  Vanliga användare behåller den snabba och dynamiska SPA-upplevelsen.

• Driftsättningsmodell med noll risk
  All återgivningslogik körs utanför Adobe Commerce och webbutikens miljö.

• Fullständig kontroll via App Builder
  Regler för förrendering, datamodeller och scheman kan justeras utan nya driftsättningar av plattformen.

5. Order- och ERP-synkronisering: designad som asynkron

Utcheckning och ordrar hanteras utan problem i Adobe Commerce vilket bevarar dataintegriteten och transaktionskonsekvensen. När en order har skapats tas exporten över av en dedikerad exportör som bygger på App Builder.

Den här exporteraren synkroniserar beställningar till ERP helt asynkront, utanför webbutiken och livscykler för Commerce-begäranden.

Viktiga fördelar med den här metoden

• Webbutikens drifttid är helt oberoende av ERP-tillgängligheten
  Även om ERP-leverantören är långsam eller tillfälligt otillgänglig kan kunderna fortsätta lägga ordrar utan avbrott.

• Ingen utcheckningsblockering på grund av efterföljande fel
  Beställningsgenerering är inte längre beroende av ERP-svar i realtid, vilket eliminerar en stor källa till konverteringsrisk.

• Säkra återförsök och kontrollerat dataflöde
  App Builder tillåter schemalagd körning, återförsöksmekanismer och felhantering utan att påverka Commerce-prestandan.

• Oberoende skalning och driftsättning
  Ordersynkroniseringen kan skalas baserat på volym utan nya driftsättningar eller sidoeffekter gällande Adobe Commerce-prestandan.

Varför inte ta steget till App Builder?

Ett av de tidigaste och viktigaste arkitektoniska besluten var inte att behandla App Builder som en total ersättning för PHP-moduler och inte heller att göra allt till PHP ”eftersom det är så det alltid har gjorts”.

I stället gick alla krav igenom ett enkelt filter:

Vad som blev kvar i PHP (30 %)

Vi behöll endast PHP-anpassningar där de verkligen hör hemma:

• Utcheckning och orderjusteringar

• Prissättning, kundvagn och offertlogik

• Djupgående GraphQL- och prestandakänsliga krokar

• Områden där latensen måste vara nära noll och helt synkron

Det är här som direkt databasåtkomst, komplett integrering av interna Commerce-strukturer och krav på livscykelkontroll fortfarande är absolut befogade.

Vad som flyttades över till App Builder (70 %)

Allt annat har flyttats över:

• Identitets- och SSO-samordning

• Kund- och företagsvalidering

• Produkttillgänglighet

• Koordinering med externa system

• ERP och integreringar från tredje part

• Omdirigeringsmotorer och automatisering

• Bakgrundsjobb och schemaläggare

Det här är områden där PHP-moduler historiskt sett lider av:

• täta integreringar

• svåra driftsättningar

• dålig felisolering

• begränsad skalbarhet.

Viktiga fördelar som kan tas vara på

Genom att flytta över ungefär 70 % av affärs- och integreringslogiken till App Builder ändrade vi i grunden hur plattformen byggs, driftsätts och används. Effekten blev synlig när det gäller arkitekturens kvalitet men även på leveranshastigheten, systemstabiliteten och långsiktiga kostnadskontroller.

Oberoende driftsättningar

App Builder hanterar de flesta integreringar och arbetsflöden, och de flesta förändringar kräver inte längre en fullständig ny driftsättning till Adobe Commerce. Integrationsuppdateringar, valideringar och bakgrundsprocesser kan driftsättas oberoende av varandra, vilket drastiskt reducerar:

• versionsrisker

• driftsättningsfönster

• samordningskostnader mellan team.

Enbart det här blev en av de största produktivitetsvinsterna i den dagliga verksamheten.

Bättre skalbarhet där det betyder som mest

Tidigare ökade trafiken vid:

• tillgänglighetskontroller

• företagsvalidering

• externa API-anrop

som direkt påverkar Commerce-prestandan.

Nu kan dessa arbetsbelastningar skalas separat i App Builder. Resultatet blir:

• stabil prestanda för utcheckning

• Commerce-resurser reserveras för endast transaktionella arbetsbelastningar

• oförutsägbar trafik från tredje part hotar inte längre konverteringsgraden.

Isolering av verkliga fel

En av de viktigaste förbättringarna är felinneslutning. När system från tredje part upplever fördröjningar, försämringar eller avbrott:

• App Builder absorberar effekten

• återförsöks- och backuplogik används

• Adobe Commerce fortsätter att fungera.

Det här har i princip eliminerat en hel klass med incidentscenarier som tidigare ledde till ett partiellt eller fullständigt driftstopp i webbutiken.

Enklare kodägarskap och tydligt ansvar

Plattformen har nu tydliga arkitektoniska gränser:

• Adobe Commerce → transaktionell logik, utcheckning, prissättning och kundvagn

• App Builder → integrationer, samordning, validering och bakgrundsjobb

Den här separationen:

• förenklar introduktionen av nya utvecklare

• minskar beroenden mellan team

• förhindrar att Commerce-kärnan gradvis urholkas genom integrationskrävande egen kod.

Framtidssäkra genom design

Den här hybrida arkitekturen är helt i linje med Adobe långsiktiga SaaS, API-först och komponerbara e-handelsstrategi. Genom att externalisera större delen av den anpassade logiken:

• blir plattformsuppgraderingar säkrare

• har leverantörslåsning på kodnivån reducerats

• är lösningen redan förberedd för en övergång till Adobe Commerce as a Cloud Service.

Vi hanterade inte bara dagens krav – vi byggde en plattform som är strukturellt redo för det som Adobe Commerce håller på att transformeras till.