Blog/Webfejlesztés

Headless B2B termékkonfigurátor: szabályok, árazás és Nuxt egy commerce API-n

Így építs headless B2B termékkonfigurátort: szabálymotor vagy solver, hol éljenek a szabályok, szerveroldali árazás, Nuxt commerce API-n, TYPO3, 100 ezer+ variáns.

Balázs Csorba·2026. október 2.·12 perc olvasás

Product configurator
B2B e-commerce
Nuxt
Headless commerce

A lényeg röviden

A konfigurátort kezeld kis szolgáltatásként három feladattal (mi megengedett, mennyibe kerül, mi kell a webshopnak az eladáshoz), ne beépített szabályokkal teli front end widgetként.
Kezdj deklaratív szabálymotorral; constraint solverhez akkor nyúlj, ha a szabályok annyira összefüggnek, hogy az érvényes kombinációkat nem tudod felsorolni vagy az ütközést nem tudod megmagyarázni.
A szabályok oda tartoznak, ahol a termékadatot karbantartják (általában a PIM), az árak oda, ahol felelnek értük (általában az ERP); a webshop csak validált eredményt kap.
A böngésző mutathat előnézetet, de a szervernek a kosárba tételkor és az ajánlatkor újra validálnia és árazni kell, mert a kliensoldali validáció triviálisan kikerülhető.
100 000+ variánsnál soha nem küldöd ki a variánslistát: a szervertől kéred a következő érvényes opciókat, és ezt a párbeszédet billentyűzettel és képernyőolvasóval is használhatóvá teszed.

A termékkonfigurátor front end problémának látszik, amíg meg nem érkezik az első valódi katalógus. Akkor kiderül, hogy adatprobléma (honnan jönnek a szabályok?), árazási probléma (ki mondhatja meg, mennyibe kerül?) és bizalmi probléma (el tudja-e adni a shop pontosan azt, amit a vevő konfigurált?). B2B-ben, ahol egy rossz kombináció rossz alkatrészt jelent egy gépben, az utolsó a legfontosabb.

Így építenék 2026-ban B2B termékkonfigurátort (egy „CPQ-lite"-ot: konfigurálás, árazás, ajánlat a teljes CPQ-csomag nélkül) headless módon. Alapja egy több mint 100 000 precíziós gépgyártási cikkhez épített, vezetett konfigurátor automatikus árazással, Nuxt.js-sel a Spryker Glue API-n (lásd a Meusburger referenciát). A cikk az architektúránál és a mérlegeléseknél marad, és a projektet ennél részletesebben nem írja le.

Mit kell valójában tudnia egy B2B konfigurátornak

A felületet levéve a konfigurátor négy dolgot csinál. Korlátozza a választásokat, hogy csak érvényes kombinációk legyenek elérhetők. Levezet értékeket, amelyeket a vevőnek nem kell begépelnie (cikkszám, tömeg, szállítási idő). Árazza az eredményt, gyakran sávos vagy szerződéses árakkal. És átad egy konfigurációt, amelyet a vállalat többi része használni tud: kosártételt, ajánlatot, rajzkérést.

A visszatérő hiba, hogy mind a négyet a front endbe teszik, mert ott készül a demó. Az eredmény: böngésző nélkül tesztelhetetlen szabályok, árak, amelyeket a kliens lát és ami még rosszabb, befolyásol, és egy shop, amelynek el kell hinnie bármit, ami megérkezik. Én a rendszert vékony felületre és egy konfigurációs szolgáltatásra bontanám, amely az első három feladatot birtokolja, a negyediket pedig a commerce platformra hagynám.

Szabálymotor vagy constraint solver

Történetileg a konfigurátorok produkciós szabályokkal indultak; a később megjelent modellalapú, constraint-alapú megközelítések szétválasztják a termékismeretet a megoldási stratégiától, így az egyik változása nem töri el a másikat, ahogy a Wikipedia tudásalapú konfigurálásról szóló cikke leírja. A gyakorlati tanulság: bármelyik technikát választod, a szabályok legyenek adatok, ne kódutak.

Egy deklaratív szabálymotor olyan feltételeket értékel ki az aktuális választáson, mint „ha az anyag X, az Y feletti átmérők nem engedélyezettek". Könnyen elmagyarázható a termékmenedzsereknek, jól unit tesztelhető (választás be, megengedett opciók ki) és gyors. Egy constraint solver, például az OR-Tools CP-SAT, a terméket változókként és kényszerekként kezeli, és érvényes kiosztásokat keres; egész számokon dolgozik, ezért a tizedes méreteket skálázni kell. Akkor jeleskedik, ha a kényszerek úgy hatnak egymásra, hogy kézzel nem rendezheted őket, és ha a „mi a legközelebbi érvényes konfiguráció?" kérdésre kell válaszolnod.

Az alapértelmezésem a szabálymotor, olyan formátumú szabályokkal, amelyeket később egy solver is fel tudna dolgozni. A legtöbb katalóguscikk valójában termékcsalád néhány tucat egymásra ható paraméterrel, és egy szabály magyarázhatósága („ez az opció a 42. szabály miatt tiltott") többet ér a supportnak, mint a solver általánossága. Az alábbi táblázat a döntési segédletem.

Helyzet	Választás	Miért	Mire figyelj
Termékcsaládok paramétertartományokkal és néhány tucat függőséggel	Szabálymotor	Átlátható, tesztelhető, a termékmenedzsment karbantarthatja	Szabálysorrend és átfedő szabályok; legyenek deklaratívak és unit tesztelve
Sok egymásra ható opció, nincs egyértelmű kiértékelési sorrend	Constraint solver	Kézzel írt sorrend nélkül talál érvényes kiosztásokat és ütközéseket	Egész számos modellezés, válaszidő, a hibák elmagyarázása a felhasználóknak
Válaszolni kell: „semmi sem érvényes, mi a legközelebbi?"	Constraint solver	Kényszereket lazíthat és alternatívákat kereshet	Világos célfüggvény kell arra, mit jelent a „legközelebbi"
Többnyire fix variánsok, a választás egy szűrő	Fazettás keresés, motor nélkül	A variánsok már léteznek cikkekként; szűrd és rendezd őket	Ne építs konfigurátort ott, ahol egy keresőoldal elég
A szabályok nem fejlesztőké, akik hetente módosítják őket	Szabálymotor szerkesztővel	Szabályok adatként, verziózással és review-val	Governance: ki publikálhat szabályt, és hogyan tesztelik

Építés előtt ellenőrizd, kell-e egyáltalán konfigurátor. Ha a variánsok eladható cikkekként léteznek, egy jó, szűrhető katalógus olcsóbb és robusztusabb. A konfigurátor ott éri meg, ahol a kombinációs tér túl nagy a felsoroláshoz, vagy az értékeket levezetik, nem választják.

Hol élnek a szabályok: PIM, ERP vagy webshop

A második évben a karbantartási költséget nem a motor dönti el, hanem az, hogy ki birtokolja a tudás egyes fajtáit. Az ökölszabályom: a szabályok az őket indokló termékadat mellett élnek (jellemzően a PIM-ben), az árak ott, ahol felelnek értük (jellemzően az ERP-ben, a shop gyorsítótárazza), a shop pedig soha nem birtokol konfigurációs logikát. Övé a kosár, a pénztár és az ügyfélkapcsolat.

Az alábbi architektúra egy konfigurációs szolgáltatást tesz a Nuxt front end és a commerce API közé. A szolgáltatás attribútumokat és szabályokat olvas a PIM-ből, árakat és elérhetőséget az ERP-ből, és opciókat, levezetett értékeket, árat és validációs eredményt ad vissza. A commerce API csak olyan konfigurációt kap, amelyet ez a szolgáltatás validált.

A konfigurációs szolgáltatás az egyetlen hely, amely a szabályokat, az árakat és a validációt összeköti. A böngésző előnézetet mutat; a commerce API csak validált konfigurációt kap.

Ebből a szétválasztásból három következmény adódik.

Egy forrás tényenként. Ha egy szabály a PIM-ben és még egyszer a shopban is él, az egyik negyedéven belül hibás lesz. A szabályokat a PIM-ből publikáld a szolgáltatásba (például verziózott artefaktként), ne vidd fel újra.
A szolgáltatás állapotmentes egy választás fölött. Minden hívás a teljes választást és a kontextust (vevő, árlista, nyelv) hordozza. Ettől gyorsítótárazható, tesztelhető és vízszintesen skálázható.
A shop eredményt lát, nem folyamatot. A Spryker például dokumentál egy Product Configuration featuret Glue API modulokkal, amelyek konfigurációs adatot visznek a kosártételeken (Spryker dokumentáció). Bármelyik platformot használod, nézd meg, hogyan tárol egy konfigurációt a kosártételen és tudja-e árazni, mielőtt saját formátumot tervezel.

Árazási logika kiszivárogtatás nélkül

A B2B árak ritkán egyetlen szám. Alapárat, opciópótlékokat, mennyiségi sávokat, vevőspecifikus megállapodásokat és olykor megmunkálási vagy beállítási költséget kombinálnak. Én az árszámítást a szerveren, a konfigurációs szolgáltatásban tartanám, a választás, a mennyiség és a vevői kontextus tiszta függvényeként, amely az ERP-t vagy az ERP által karbantartott árlistát hívja.

A front end ezután egy, a szerver által visszaadott árat mutat, és annak is jelöli. Ha a vevő mennyiséget változtat, kérdezz újra. A végső árat soha ne a böngészőnek küldött számokból számold; ezek a számok megjelenítési, nem rendelési bemenetek.

Két gyakorlati pont. Először: döntsd el korán, hogy a konfigurátor kötelező vagy tájékoztató árat mutat; ha egyes tételekhez kézi ajánlat kell (különleges tűrések, nagy mennyiségek), ezt explicit kimenetként modellezd („ajánlatkérés"), ne hiányzó árként. Másodszor: a kerekítést, a pénznemet és az adószabályokat egy helyen tartsd, különben a konfigurátor, a kosár és a számla fillérekkel eltér, és napokig keresed az okot.

A Nuxt front end egy commerce API-n

A front enden a konfigurátort a szerver fölötti vezetett párbeszédként építeném, nem olyan kliensoldali állapotgépként, amely ismeri a szabályokat. Minden lépés elküldi az aktuális választást a konfigurációs szolgáltatásnak, és kirajzolja a visszajövő opciókat, a tiltott opciók pedig indokot hordoznak. A Nuxt jól illik, mert a szerver route-ok (Nitro) backend-for-frontendként működhetnek: a böngésző a saját végpontjaiddal beszél, amelyek viszont olyan hitelesítő adatokkal hívják a konfigurációs szolgáltatást és a commerce API-t, amelyek soha nem jutnak a klienshez.

A választás az URL-ben. Kódold a választást a query stringben, hogy a konfiguráció megosztható, könyvjelzőzhető és visszaállítható legyen. A tesztelést is megkönnyíti: egy URL egy tesztesetet jelent.
Szerver által vezérelt lépések. A szerver adja a következő lépést, az érvényes opciókat és a tiltottak indokait. Egy paraméter hozzáadása adatváltozás, nem release.
Optimista előnézet, mérvadó eredmény. Mutass azonnal olcsó helyi visszajelzést, de a szerver válaszát tekintsd igazságnak, és egyeztess.
Átadás a commerce API-n át. A végén a BFF-et hívod, amely még egyszer validál, majd a platform API-n (Sprykernél a Glue API) át kosárba vagy ajánlatba írja a konfigurációt.

Ha MI asszisztenst is szeretnél, amely segít a vevőknek leírni, mire van szükségük („egy lemez szerszámhoz, edzett, 300 mm"), hagyd, hogy választást javasoljon, és futtasd át ugyanazon a szolgáltatáson. A modell javasol, a szabályok döntenek. Az ügynökoldalhoz lásd az agentic commerce protokollokat, a folyamat böngészőügynököknek való kitételéhez a WebMCP-t. Ha asszisztenst szállítasz, értékeld úgy, mint bármely más termékfunkciót, például az LLM eval-ok termékfunkciókhoz cikk szerint.

Integráció TYPO3-mal vagy más CMS-sel

A „Produktkonfigurator TYPO3" keresések általában olyan cégektől jönnek, amelyek a marketingoldalt már TYPO3-mal üzemeltetik, és a konfigurátort is abba szeretnék. A tiszta minta a munkamegosztás: a CMS birtokolja a tartalmat, a navigációt, a landing oldalakat és a SEO-t; a konfigurátor birtokolja a konfigurációt. A TYPO3 rendereli az oldalt és beágyazza a konfigurátort, vagy beágyazott Nuxt appként, vagy olyan extension pluginként, amely ugyanazt a konfigurációs szolgáltatást hívja.

A TYPO3-nak csak kontextust kell átadnia: nyelvet, vevőcsoportot, termékcsalád-azonosítót. Szabályokat vagy árakat ne tartson. Amint egy szabály egy tartalomelemben vagy egy TypoScript feltételben él, a termékmenedzserek nem tudják tesztelni, a fejlesztők pedig nem találják meg. Ez bármely más CMS-re és a beágyazás kontra teljesen headless front end választására is igaz: minél többet birtokol az oldalból a konfigurátor, annál egységesebb az élmény, de annál inkább lemondasz a CMS előnézeti munkafolyamatról, amelyet a szerkesztőid szeretnek.

Teljesítmény 100 000+ variánssal

A 100 000+ cikkes katalógus megváltoztatja, hogyan gondolkodsz a teljesítményről, mert nincs kirajzolandó lista. Az elv egyszerű: soha ne küldd ki a variánslistát a böngészőnek; kérdezd meg a szervert, mi érvényes legközelebb.

A terméket modellezd, ne a variánsokat. Az attribútumok és a szabályok írják le a teret; a variánsok csak szükség esetén jönnek létre (cikkszám, ár).
Indexelj a lekérdezéshez. A kereshető attribútumok keresőmotorba kerülnek, így a „mely opciók maradtak?" indexlekérdezés, nem táblaolvasás.
Gyorsítótárazz választás szerint. Ugyanarra a választásra és kontextusra az opciólekérdezések azonosak; gyorsítótárazd őket az edge-en vagy a szolgáltatásban, és a cache kulcsa tartalmazza a szabályrendszer és az árlista verzióját.
Tartsd kicsin a payloadot. Csak a következő lépést add vissza, ne a teljes fát, és tömörítsd.
Virtualizáld, ami hosszú. Ha egy lépéshez valóban hosszú lista kell (például több száz átmérő), csak a látható ablakot rajzold ki: a virtualizálás újrahasznosítja a nézetből kikerülő DOM csomópontokat, így a kirajzolt elemek száma az ablakot követi, nem az adatot.
Mérd az egész párbeszédet. A mutató a „kattintástól a frissített, érvényes opciókig" idő, p95, az ERP-s árlekérdezéssel együtt. Költségvetezd, és valós választásokkal teszteld.

Szerveroldali validáció, mentés és ajánlatok

Amit a böngésző érvényesít, azt a szervernek újra érvényesítenie kell. Az OWASP Input Validation Cheat Sheet egyértelműen kimondja, hogy a bemenet validációját a szerveroldalon kell megvalósítani, mert a kliensoldali validáció könnyen kikerülhető, és az allow-listet részesíti előnyben: pontosan meg kell határozni, mi megengedett. Egy konfigurátornál ez azt jelenti, hogy a szerver csak olyan választást fogad el, amely az aktuális szabályrendszer szerint érvényes, a levezetett értékeket és az árat pedig újraszámolja ahelyett, hogy a kapottaknak hinne.

A konfigurációt kezeld megváltoztathatatlan, verziózott dokumentumként. Egy kompakt forma jól működik:

Azonosság: konfigurációs azonosító, termékcsalád, létrehozó vevő és időbélyeg.
Választás: a kiválasztott paraméterértékek, semmi levezetett.
Verziók: a létrehozáskor használt szabályrendszer- és árlista-verzió.
Eredmény: levezetett értékek, árbontás, valamint a cikkszám vagy egy „kézi ellenőrzés szükséges" jelző.

A mentés ezután ennek a dokumentumnak a megírása; az ajánlatadás a befagyasztása érvényességi idővel és az ajánlathoz kötve. Ha egy ajánlatot elfogadnak, rendelés előtt validáld újra az aktuális szabályokkal: ha közben változott egy szabály, a vevő hamarabb tudja meg, mint a gyártás. Hogy a dokumentumot a konfigurációs szolgáltatásban vagy a commerce platformon tartod, másodlagos ahhoz képest, hogy teljes és újrajátszható legyen.

A hozzáférhetőség konfigurátor-követelmény

A konfigurátor sűrű, dinamikus űrlap, és a hozzáférhetőség általában itt törik el. A gyakorlati ok egyszerű: az a vevő, aki nem tudja kezelni a konfigurátorodat, nem tud rendelni. Ezeket az ellenőrzéseket alkalmazom, a WCAG 2.2-höz rendelve:

Szövegben mondd meg, mi a hiba. A 3.3.1 sikerkritérium megköveteli, hogy a beviteli hibát azonosítsák és szövegben leírják. „Ez az átmérő edzett acéllal nem elérhető" többet ér, mint egy piros keret.
Jelentsd be a változásokat a fókusz elvétele nélkül. Amikor az ár vagy az opciólista frissül, a 4.1.3 Állapotüzenetek azt várja, hogy a változás programozottan megállapítható legyen, például role="status" a frissítésekhez és role="alert" a hibákhoz, hogy a képernyőolvasók a fókusz mozgatása nélkül bemondják.
Elég nagy célpontok. A 2.5.8 a mutatós célpontokra 24 x 24 CSS pixel minimumot ír elő, kivételekkel; a színminták és a kis léptetők azok a helyek, ahol a konfigurátorok elbuknak.
Használj bevált mintákat. Részesítsd előnyben a natív rádiógombokat, select és szám mezőket; ahol kereshető opciólista kell, kövesd az ARIA combobox mintát a billentyűzetkezelésével együtt.
A tiltott opciókhoz indok kell. Egy pusztán elszürkített opció a képernyőolvasót használónak zsákutca; add meg az okot szövegben.

Az automatikus ellenőrzők ennek csak egy részét találják meg. Mielőtt késznek nevezed, játszd végig a teljes folyamatot billentyűzettel és legalább egy képernyőolvasóval.

Éles indulás előtti ellenőrzőlista

Mielőtt egy konfigurátor élesedik, ezek mindegyikére igent szeretnék:

Minden szabály adat, felelőssel, verzióval és unit teszttel.
A szabályok egy forrásból jönnek (általában a PIM-ből), és egy szabályrendszer publikálása felülvizsgált lépés.
Az árakat a szerver számolja verziózott árlistából; a böngésző soha nem dönt árról.
A kosárba tétel és az ajánlat újra validál és újra árazik; a meghamisított kérést elutasítják.
Minden mentett konfiguráció rögzíti a szabályrendszer-verziót, az árlista-verziót és a bemeneteket, és újraszámolható.
Az automatikusan nem árazható esetek explicit „ajánlatkéréssel" végződnek, nem hibával.
A „kattintástól az érvényes opciókig" idő 95. percentilisét valós választásokon mérik.
A teljes folyamat működik billentyűzettel és képernyőolvasóval, a hibákat és az állapotváltozásokat szövegben jelentik be.

Ha először csak három dolgot tudsz megtenni, az elsőt, a harmadikat és a negyediket válaszd.

Mi következik ebből

A visszatérő téma a szétválasztás. Szabályok adatként, egy helyen birtokolva; az árak annál a rendszernél, amely felel értük; vékony front end, amely kérdez, nem tud; commerce platform, amely validált eredményt kap. Ettől lesz a konfigurátor elég stabil a bővítéshez, akár új termékcsalád, ajánlati munkafolyamat vagy egy ráépülő asszisztens a következő lépés.

A Nuxt.js-sel a Spryker Glue API-n épített vezetett konfigurátor a referenciáim között szerepel. Ha te is tervezel egyet, és át akarod beszélni a szabálymotor vagy solver döntést, illetve a PIM és az ERP közötti felosztást, a B2B e-commerce fejlesztő oldalamon megtalálod a részleteket.

Források

Gyakori kérdések

Mi az a B2B termékkonfigurátor?

A B2B termékkonfigurátor végigvezeti a vásárlót egy konfigurálható termék opcióinak érvényes kombinációján, például méreteken, anyagokon és tűréseken, megmutatja az árat és a szállítási időt, és az eredményt átadja a kosárnak vagy az ajánlatnak. A fogyasztói konfigurátorokhoz képest a szabályok szigorúbbak, a katalógus nagyobb, az ár pedig gyakran szerződéses feltételektől függ.

Szabálymotor vagy constraint solver egy termékkonfigurátorhoz?

Kezdj deklaratív szabálymotorral: könnyű elmagyarázni, tesztelni, és a termékmenedzserek is karbantarthatják. Válts constraint solverre, ha a szabályok annyira összefüggnek, hogy az érvényes kombinációk nem sorolhatók fel vagy nem rendezhetők kézzel, vagy ha meg kell magyaráznod, miért lehetetlen egy választás, és meg akarod találni a legközelebbi érvényes alternatívát.

Hol éljenek a konfigurátor szabályai: PIM, ERP vagy webshop?

A szabályokat tartsd az őket indokló termékadat mellett, ez általában a PIM, az árakat pedig ott, ahol felelnek értük, általában az ERP-ben. A webshop validált konfigurációt fogyasszon, ne ő birtokolja a szabályokat, különben a szabályok duplán élnek a shopban és az ERP-ben, és szétcsúsznak.

Hogyan építs Produktkonfigurator-t TYPO3-mal?

A TYPO3 birtokolja a tartalmat, a landing oldalakat és a navigációt, a konfigurátort pedig headless appként vagy egy külön konfigurációs szolgáltatással beszélő pluginként illeszd be. A TYPO3 csak kontextust ad át, például nyelvet, vevőcsoportot és termékazonosítót; a szabályok, az árak és a validáció a CMS-en kívül maradnak.

Hogyan kezelj 100 000+ variánst egy konfigurátorban?

Soha ne tölts be és ne rendelj meg minden variánst. Modellezd a terméket attribútumokként és szabályokként, a szerver csak az aktuális választásra még érvényes opciókat adja vissza, a kereshető attribútumokat indexeld keresőmotorban, gyorsítótárazd az opciólekérdezéseket, és virtualizálj minden hosszú listát, amit meg kell jeleníteni.

Hogyan tegyél hozzáférhetővé egy konfigurátort?

Használj natív űrlapelemeket vagy jól tesztelt ARIA mintákat, az ár- és validációs változásokat állapotüzenetként jelentsd be a fókusz mozgatása nélkül, a hibákat szövegben írd le a mező mellett, és tartsd a célpontokat legalább 24 x 24 CSS pixelesre. A teljes folyamatot billentyűzettel és képernyőolvasóval is teszteld, ne csak automatikus ellenőrzővel.