Pimcore ERP delta szinkron: termékadatok SAP vagy Infor, PIM és webshop között

Szinte minden B2B kereskedelmi projekt, amelyen dolgozom, ugyanarra a gerincre épül: egy ERP, például SAP vagy Infor, tartja a cikkek, árak és készletek igazságát, egy PIM, például a Pimcore, ebből az ügyfél számára érthető tartalmat csinál, a webshop pedig eladja. A három rendszer hétfőn egyetért, péntekre már nem. Amikor az értékesítő megkérdezi, miért mutat a shop régi árat, a válasz szinte soha nem az, hogy „elromlott a szinkron”. Hanem az, hogy senki nem döntötte el, kié a mező, mi számít változásnak, és mi történik, ha egy üzenet hibára fut.

Ez a cikk azt a felépítést mutatja, amelyet ma használnék az ERP, a Pimcore és a webshop közötti szinkronhoz: először a tulajdonlás, aztán egy delta folyamat mellé tett full egyeztetés, olyan változásdetektálás, amely nem egyetlen jelre épít, idempotens handlerek egy üzenetsor mögött, minőségi kapuk, valamint a monitoring és replay eszközök, amelyektől üzemeltethető lesz. A végén rövid lista arról, mit ellenőrizz a Pimcore verzióival és kiadásaival kapcsolatban, mielőtt elköteleződsz, mert ez a terep 2026-ban mozgott.

Ha AI réteget terveznél a tiszta termékadatokra, ugyanaz az alap számít: a strukturált, megbízható katalógusadatra épül mind az agentic commerce protokollok, mind a generative engine optimization.

Miért nehezebb ez a szinkron, mint amilyennek látszik

Papíron egy cső: olvasás az ERP-ből, írás a PIM-be, publikálás a shopba. A gyakorlatban négy probléma lapul benne. Az első a mennyiség és a ritmus: egy több százezer rekordos anyagtörzset nem lehet néhány percenként újraolvasni, de az árak és készletek folyamatosan változnak. A második, hogy a „változott” kétértelmű: egy ERP-rekordhoz hozzá lehet nyúlni anélkül, hogy a shop számára lényeges attribútum változna. A harmadik, hogy a rendszerek félúton elhasalnak: egy hálózati timeout, egy zárolt objektum vagy egy validációs hiba részben frissített, részben frissítetlen rekordokat hagy. A negyedik, hogy gyakran két rendszer írja ugyanazt a mezőt, és az utolsó írás véletlenül nyer.

Mindegyikre van egy unalmas, jól ismert válasz. Az alábbi felépítés lényege, hogy ezeket következetesen alkalmazza, így a szinkron egy oldalon elmagyarázható és tíz perc alatt debugolható.

Először döntsd el, ki melyik attribútum tulajdonosa

Mielőtt importkódot írnék, leírok egy tulajdonlási táblát: minden attribútumcsoportot, azt, hogy melyik rendszer az egyetlen író, és milyen irányba folyik az adat. Egy mezőnek pontosan egy tulajdonosa van. A többi rendszer olvashatja, megjelenítheti vagy gyorsítótárazhatja, de soha nem írhatja vissza. Ez az egy szabály kiküszöböli a legtöbb „pingpong” hibát, amikor egy import felülír egy kézi szerkesztést, vagy egy szerkesztő kijavít egy értéket, amelyet másnap éjjel megint felülírnak.

Ez a felosztás tipikus, nem általános. Egyes cégek a hosszú szövegeket az ERP-ben tartják, mások a méreteket a PIM-ben. Az számít, hogy a táblád létezik, hogy a kód érvényesíti (az importnak egyszerűen nincs leképezése azokra a mezőkre, amelyek nem az övéi), és hogy a PIM felülete csak olvashatónak jelöli az ERP-s mezőket, hogy a szerkesztők ne próbálják módosítani őket. A szürke zónára, például egy névre, amely az ERP-ben indul és a PIM-ben csiszolódik, tedd egyértelművé az átadást: az ERP értéke egyszer feltölti a mezőt, és egy jelző rögzíti, hogy attól kezdve a PIM a tulajdonos.

Az adatfolyam

Az általam használt forma egy rövid lánc, középen egy üzenetsorral és mellette egy hibaúttal. Az ERP oldal változásesemények állít elő; egy vékony kinyerő lépés normalizálja őket; az üzenetsor leválasztja az ERP sebességét a Pimcore sebességéről; a Pimcore ellenőriz, dúsít és tárol; a publikáló lépés pedig kiszolgálja a shopot.

Három részlet teszi működőképessé ezt a formát. Először: a kinyerő lépés az egyetlen hely, amely ismeri az SAP-t vagy az Inforot: IDoc-ot, BOD-ot, OData-t vagy REST-et beszél, és egyetlen belső üzenetformátumot ad ki. Az ERP cseréje vagy egy második ERP így egyetlen komponenst érint. Másodszor: az üzenetsor valódi üzenetsor, nem egy tábla, amelyet pollozol, így a back-pressure-t és az újrapróbálkozásokat olyan infrastruktúra kezeli, amelyet nem te írtál. Harmadszor: a PIM nem publikál vakon: visszatart egy rekordot, ha elbukik egy kapun, és a shop csak azt látja, ami átment.

Full vagy delta sync, és hogyan észlelj változást

A full sync minden futásnál minden rekordot beolvas, és összehasonlít a meglévővel. Egyszerű, önjavító, és ez a megfelelő eszköz az első betöltéshez és az időszakos egyeztetéshez. Ugyanakkor lassú, és terheli az ERP-t. A delta sync csak azt viszi át, ami az utolsó sikeres futás óta változott. Gyors, de van egy hibamódja, amelyet a full sync nem ismer: ha egy változás kimarad, kimaradva is marad. Ezért mindkettőt használom: deltát a mindennapokra, ütemezett full egyeztetést az elcsúszás kiszűrésére.

A nehezebb kérdés az, honnan tudod, hogy valami változott. Négy gyakori jel van, és egyik sem elég önmagában.

Az SAP oldalon a change pointerek az alapvető mechanizmus törzsadatokhoz. A BD61 tranzakcióban általánosan, majd üzenettípusonként aktiválják őket, például MATMAS az anyagokhoz. Az RBDMIDOC riport (BD21 tranzakció) beolvassa a feldolgozatlan pointereket, IDoc-okat generál, és feldolgozottnak jelöli a pointereket, az RBDCPCLR (BD22) pedig eltávolítja a feldolgozottakat, hogy a BDCP és BDCPS táblák kicsik maradjanak. Mindkét jobot tervezd be; egy soha nem takarított delta feed saját teljesítményproblémává válik. Az Infor oldalon az ION business object documenteket irányít, a Sync BOD-ot pedig az adat tulajdonosa küldi minden olyan alkalmazásnak, amelynek szüksége van a változásra.

Az alapértelmezésem ezért egy kétlépéses ellenőrzés: egy esemény vagy vízjel megmondja, mely rekordokat nézzem meg, a normalizált, saját attribútumok hash-e pedig azt, hogy írjak-e. Hashelés előtt normalizálj: szóközök levágása, számformátumok és tizedesjegyek egységesítése, listák rendezése, és hagyd el azokat a mezőket, amelyekhez az ERP üzleti jelentés nélkül hozzányúl. Különben egy időbélyeg-frissítés az ERP-ben ezernyi értelmetlen írást és újraindexelést vált ki a Pimcore-ban.

Idempotens importok

Az üzenetküldő rendszerek legalább egyszer kézbesítenek. A Symfony egyértelműen dokumentálja: egy üzenet többször is kézbesíthető, ezért a handlereknek ismételten is biztonságosan kell futniuk. Újrapróbálkozással, worker-újraindítással és replayjel előbb-utóbb minden rekord kétszer feldolgozásra kerül. Az idempotencia nem optimalizáció, hanem követelmény.

• Stabil kulcs üzleti eseményenként. A kulcsot az üzleti jelentésből képezd (cikkszám plusz ERP változásszám vagy tartalom-hash), soha nem a küldéskor generált véletlen azonosítóból.
• Upsert természetes kulcs alapján. Keresd meg a Pimcore objektumot cikkszám alapján, és egyetlen handlerben frissítsd vagy hozd létre. Soha ne hozz létre vakon.
• Hash írás előtt. Ha a beérkező saját attribútumok hash-e megegyezik a tárolttal, ne csinálj semmit. Ez az újraindexelést és a cache-érvénytelenítési viharokat is megállítja.
• Sorrendtűrés. Vigyél magaddal a forrásból egy verziót vagy időbélyeget, és hagyd figyelmen kívül a tároltnál régebbi üzenetet. Az üzenetsorok nem garantálnak globális sorrendet.
• A törlés mint állapot. A deaktiválást és a törlést forrásverziós státuszváltásként modellezd, ne hiányzó rekordként, hogy túlélje a replayt.
• Adatbázis-megkötés mint utolsó védvonal. A cikkszámon lévő egyedi kulcs a két worker közötti versenyhelyzetből látható hibát csinál.

A Pimcore Data Importer fájlalapú feedeknél ugyanezt az elvet követi: a resolvere eldönti, hogy egy rekord meglévő objektumot frissít-e vagy újat hoz létre, a delta ellenőrzés pedig kihagyja a változatlan rekordokat. Ha a feeded egy CSV vagy JSON az ERP-ből, ez talán elég is. Saját handlerhez akkor nyúlok, ha a folyamat eseményvezérelt, ha a tulajdonlás attribútumonként logikát igényel, vagy ha egy ERP-üzenet több Pimcore objektumra bomlik szét.

Üzenetsorok: Symfony Messenger a Pimcore-ban

A Pimcore a Symfony Messengert használja háttérmunkához. A dokumentáció a pimcore_core sort definiálja a háttérfeladatokhoz, és egy opcionális pimcore_failed_jobs transportot a hibás üzenetekhez. A backendet a PIMCORE_MESSENGER_TRANSPORT_DSN_PREFIX környezeti változó választja: az alapértelmezett a Doctrine, támogatott az AMQP (RabbitMQ) és a Redis. A dokumentáció szerint élesben a RabbitMQ az ajánlott üzenetsor, a workerek pedig `bin/console messenger:consume pimcore_core` paranccsal futnak, supervisor vagy systemd felügyeletével.

ERP szinkronhoz a pimcore_core mellé külön transportot vennék fel, hogy az árfrissítések hulláma ne éheztesse ki a szerkesztők saját háttérfeladatait, és sorokként méreteznék a workereket. A Symfony oldalon az újrapróbálkozást transportonként állítják (max_retries, delay, multiplier, max_delay, jitter); alapértelmezés szerint egy üzenetet háromszor próbálnak újra exponenciális visszalépéssel, mielőtt a failure transportba kerül. Gondold végig, mely hibák érdemelnek újrapróbálkozást: egy zárolt objektum vagy timeout igen, egy validációs hiba nem, mert az újrapróbálás csak a riasztást késlelteti.

Tartsd őszintén a sort. A messenger:stats megmutatja, hány üzenet vár transportonként, a failure transport pedig csak akkor ér valamit, ha valaki ránéz, és ezzel már a monitoringnál tartunk.

Adatminőségi kapuk

Az a szinkron, amely hűen másolja a rossz adatot, rosszabb annál, amelyik megáll. Kapukat teszek a „megérkezett” és a „publikált” közé, és az a rekord, amely elbukik egy kapun, visszatartva és jelentve van, sem eldobva, sem publikálva nem lesz.

• Szerkezeti kapu: kötelező mezők megvannak, típusok és egységek érvényesek, a hivatkozott objektumok (márka, kategória, egység) léteznek.
• Üzleti kapu: értelmes tartományok (az ár nulla felett, a súly nem a medián tízezerszerese), értelmes státuszátmenetek, nincs hirtelen tömeges deaktiválás.
• Teljességi kapu: egy termék csak akkor kerül a shopba, ha a kötelező tartalom (cím, kép, fordítás) minden szükséges nyelven megvan.
• Mennyiségi kapu: ha egy futás a szokásosnál jóval több rekordot módosítana vagy törölne, állj meg és kérj megerősítést ahelyett, hogy alkalmaznád. Így elkapsz egy ERP-félrekonfigurálást, mielőtt kiüríti a shopodat.

A kapuk egyértelmű státuszmodellt adnak: megérkezett, érvényes, dúsított, publikált, visszatartott. Ha LLM-et használsz dúsításra, például leírásvázlatokhoz vagy osztályozáshoz, a kimenetét kezeld újabb kapubemenetként, és teszteld úgy, mint bármely modellfunkciót, ahogy az LLM evalok termékfunkciókhoz című cikkben leírtam.

Monitoring és replay

A szinkron mércéje nem az, hogyan viselkedik jó napokon, hanem hogy milyen gyorsan épülsz fel egy rossz napon. Éles indulás előtt négy dolgot akarok a helyén látni.

1. Hibasor gazdával. A hibás üzenetek külön transportba kerülnek (a Pimcore-ban pimcore_failed_jobs). Megtekintés: messenger:failed:show, újrafuttatás: messenger:failed:retry, elvetés: messenger:failed:remove. Riaszts, ha a darabszám egy megadott időnél tovább nulla felett van.
2. Késés és átbocsátás. Sormélység transportonként, a legrégebbi üzenet kora és rekord per perc. Egy lapos vonal ugyanolyan gyanús, mint egy kiugrás.
3. Replay parancs. Egy cikkszám, időablak vagy ERP változásszám alapján újra kinyerni és újraküldeni. Mivel a handlerek idempotensek, a replay biztonságosan futtatható élesben.
4. Egyeztetési riport. A teljes összehasonlítás ERP és PIM között, amely a különbségeket listázza, nem csak megfelelt vagy nem. Éjszakánként vagy hetente futtasd, és nézd a trendet: a növekvő eltérésszám azt jelenti, hogy egy delta jel kimarad.

Üzenetenként naplózz egy strukturált sort: kulcs, forrásverzió, hash, eredmény (írva, változatlanként kihagyva, kapu által visszatartva, hibás) és időtartam. A legtöbb támogatási kérdés ezután keresés lesz, nem nyomozás.

Mit ellenőrizz a Pimcore-ról 2026-ban

A Pimcore nemrég megváltoztatta a kiadási modelljét, és ennek egy része a tervezést is érinti. Ezeket a pontokat a projekt indulása előtt az aktuális dokumentációval vetném össze, nem emlékezetből feltételezném.

1. Platformverzió és támogatási időszak. A Pimcore verziók Major.Minor sémát követnek, a minor verziók nagyjából negyedévente jelennek meg, és a 2026.1 óta minden modul a platform verziószámát viseli. A 2026.3 kiadás 2026. szeptember 29-én jelent meg, és nem LTS. Egy platformverzió közösségi támogatása a következő kiadásával ér véget.
2. LTS cél. A dokumentáció a 2025.4-et 2028 decemberéig, a 2024.4-et 2026 decemberéig LTS-ként sorolja fel. Egy hosszú életű B2B shophoz LTS vonalra terveznék, vagy rendszeres minor frissítéseket költségvetnék.
3. Kiadás és modulok. A Data Hub és a Data Importer a Community kiadásban szerepel; a Professional a TinyMCE szerkesztőt adja hozzá; az Enterprise minden modult tartalmaz, például a Workflow Designert és az E-Commerce Frameworköt. Ellenőrizd, a terved ténylegesen mely modulokra épül, és ezekhez milyen kiadás és licenc kell.
4. Release notes, nem csak verziószámok. A 2026.3 jegyzetei biztonsági javításokat és a régi admin controllerek Studio API javára történő eltávolítását említik. Ha saját admin kódod vagy integrációid vannak, előbb olvasd el az upgrade notesokat.
5. Messenger beállítás. Ellenőrizd a transport DSN prefixet, a failure transport konfigurációt, és azt, hogyan felügyelik a workereket a hostingodon, mert itt dől el a szinkron megbízhatósága.

Árakat és támogatási szerződési részleteket szándékosan nem idézek: ezek a Pimcore-ral vagy a partnereddel kötött megállapodásodtól függenek, és változnak.

Hogyan állok hozzá projektekben

Ez a felépítés az, ahogy egy Pimcore és SAP delta szinkronra gondolok, és van egy Pimcore plusz SAP delta-szinkron referenciaprojektem, amelyet a referenciák oldalon találsz. Ha Pimcore fejlesztőt keresel SAP vagy Infor integrációhoz, PIM-ERP interfészhez, vagy egy elcsúszó szinkron átvizsgálásához, nézd meg a B2B e-commerce fejlesztő profilomat.

A tanácsom röviden: írd meg először a tulajdonlási táblát, tegyél minden handlert idempotenssé, hasheld, ami a tiéd, tegyél üzenetsort és hibautat a közepére, és gyakorold a replayt, mielőtt szükséged lenne rá.

Források

1. Pimcore docs: Symfony Messenger
2. Pimcore docs: Platform Versions
3. Pimcore docs: Pimcore Editions
4. Pimcore docs: Data Importer
5. Pimcore on GitHub: Release 2026.3.0
6. Symfony docs: Messenger, Sync & Queued Message Handling
7. SAP Library: Change Pointer (Master Data Distribution)
8. SAP Library: Change Pointer (IDoc Interface/ALE)
9. Infor docs: Infor ION and M3 BODs
10. Infor Developer Portal: Integration with ION
11. Debezium: open source distributed platform for change data capture