> Termékadatok szinkronja SAP vagy Infor, Pimcore és webshop között: delta és full sync, változásdetektálás, idempotens importok, Messenger, tulajdonlás, replay. > > Web page: https://balazscsorba.com/hu/blog/pimcore-erp-delta-sync · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/pimcore-erp-delta-sync.md) · [Deutsch](https://balazscsorba.com/de/blog/pimcore-erp-delta-sync.md) > Author: Balázs Csorba · Published: 2026-10-02 · Keywords: Pimcore ERP delta sync, Pimcore developer, Pimcore SAP integration, PIM ERP Schnittstelle, Pimcore SAP Schnittstelle, PIM ERP sync best practices, Pimcore Symfony Messenger, delta sync vs full sync, idempotent import Pimcore, Pimcore Infor integration [Blog](https://balazscsorba.com/hu/blog)/Webfejlesztés # Pimcore ERP delta szinkron: termékadatok SAP vagy Infor, PIM és webshop között Termékadatok szinkronja SAP vagy Infor, Pimcore és webshop között: delta és full sync, változásdetektálás, idempotens importok, Messenger, tulajdonlás, replay. [Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 2.·12 perc olvasás - Pimcore - SAP integration - PIM ERP sync - Symfony Messenger ![Ábra: a termékadatok egy SAP vagy Infor ERP-ből delta kinyerésen és üzenetsoron át a Pimcore-ba folynak, ahol minőségi kapuk futnak, majd tovább a webshopba.](https://balazscsorba.com/images/blog/pimcore-erp-delta-sync/cover.webp?v=58260af2c2) ## A lényeg röviden - Attribútumonként döntsd el, ki a tulajdonos, mielőtt importot írsz: az ERP birtokolja a kereskedelmi és logisztikai adatokat, a PIM a tartalmat és az osztályozást, és egy mezőt sem ír két rendszer. - A mindennapi folyamathoz delta szinkront használj, a full sync pedig legyen ütemezett egyeztetés, ne a normál út. A változást a forrásnál észleld (SAP change pointer, Infor Sync BOD, CDC), és erősítsd meg tartalom-hash-sel. - Az üzenetek legalább egyszer kerülnek kézbesítésre, ezért minden handlernek idempotensnek kell lennie: stabil kulcs üzleti eseményenként, upsert insert helyett, és hash-ellenőrzés írás előtt. - Tegyél üzenetsort az ERP és a PIM közé. A Pimcore-ban ez a Symfony Messenger a pimcore\_core sorral és egy failure transporttal, élesben lehetőleg RabbitMQ-n. - A minőségi kapuk, egy figyelt hibasor és egy replay parancs teszi a törékeny importot üzemeltethető pipeline-ná. Építés előtt ellenőrizd az aktuális Pimcore verziót, kiadást és támogatási időszakot. Ezen az oldalon 1. [Miért nehezebb ez a szinkron, mint amilyennek látszik](https://balazscsorba.com/#why-it-is-hard) 2. [Először döntsd el, ki melyik attribútum tulajdonosa](https://balazscsorba.com/#ownership) 3. [Az adatfolyam](https://balazscsorba.com/#data-flow) 4. [Full vagy delta sync, és hogyan észlelj változást](https://balazscsorba.com/#delta-vs-full) 5. [Idempotens importok](https://balazscsorba.com/#idempotent-imports) 6. [Üzenetsorok: Symfony Messenger a Pimcore-ban](https://balazscsorba.com/#queues) 7. [Adatminőségi kapuk](https://balazscsorba.com/#quality-gates) 8. [Monitoring és replay](https://balazscsorba.com/#monitoring-replays) 9. [Mit ellenőrizz a Pimcore-ról 2026-ban](https://balazscsorba.com/#verify-2026) 10. [Hogyan állok hozzá projektekben](https://balazscsorba.com/#my-approach) 11. [Források](https://balazscsorba.com/#sources) 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](https://balazscsorba.com/hu/blog/agentic-commerce-protocols-ucp-acp-guide), mind a [generative engine optimization](https://balazscsorba.com/hu/blog/generative-engine-optimization-audit). ## 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. Attribútumcsoport Tulajdonos Irány Szabály Cikkszám, alapmennyiségi egység, státusz, súlyok, GTIN ERP ERP → PIM A PIM szerkesztőfelületén csak olvasható Árak, készlet, elérhetőség, ügyfélspecifikus feltételek ERP ERP → shop Gyakran megkerüli a PIM-et, vagy élőben kérdezik le Címek, leírások, képek, dokumentumok, fordítások PIM PIM → shop Gondozás után már nem importálják az ERP-ből Osztályozás, szűrhető attribútumok, variánsok, cross-sell PIM PIM → shop Egyszer az ERP-ből feltöltve, utána a PIM birtokolja Rendezés, SEO URL, merchandising jelzők Shop A shopban marad Nem szinkronizálják vissza 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. A szinkron mint lánc, középen üzenetsorral. A hibaút, a replay eszközök és az egyeztetés mellette futnak, és a terv részei, nem utólagos ötlet. 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. Jel Működés Erősség Gyengeség Módosítási időbélyeg Az utolsó vízjel óta módosított rekordok lekérdezése Könnyű megépíteni Óraeltérés, visszadátumozott módosítások, nincs információ a törlésekről Forrásoldali események Az SAP change pointerek IDoc-okat állítanak elő; az Infor ION Sync BOD-okat publikál az adat tulajdonosától Magát a változást jelzi, a törléseket is Beállítást és karbantartást igényel az ERP-n Change data capture Egy eszköz, például a Debezium, sorszintű változásokat streamel commit sorrendben Teljes és rendezett Táblaszinten működik, nem üzleti szinten Tartalom-hash A normalizált, releváns attribútumokat hasheled és összehasonlítod Figyelmen kívül hagyja a lényegtelen érintéseket, ismételhető Te számolod és tárolod 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. **Ne tedd a teljes ERP-rekordot az üzenetbe** Küldj kis üzenetet kulccsal, forrásverzióval és hash-sel, és hagyd, hogy a handler szükség esetén lekérje a teljes rekordot. A nagy payload felduzzasztja a sort, és mire az újrapróbálás lefut, a payload már elavult lehet. Egy vékony üzenet és friss olvasás könnyebben újrajátszható és könnyebben átlátható. 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](https://balazscsorba.com/hu/blog/llm-evals-for-product-features) 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](https://balazscsorba.com/hu/references) 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](https://balazscsorba.com/hu/expertise/b2b-ecommerce-developer). 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](https://docs.pimcore.com/platform/Getting_Started/Installation/Advanced_Installation_Topics/Symfony_Messenger/) 2. [Pimcore docs: Platform Versions](https://docs.pimcore.com/platform/Pimcore_Platform/Platform_Versions/) 3. [Pimcore docs: Pimcore Editions](https://docs.pimcore.com/platform/Pimcore_Platform/Pimcore_Editions/) 4. [Pimcore docs: Data Importer](https://docs.pimcore.com/platform/Data_Importer/) 5. [Pimcore on GitHub: Release 2026.3.0](https://github.com/pimcore/pimcore/releases/tag/v2026.3.0) 6. [Symfony docs: Messenger, Sync & Queued Message Handling](https://symfony.com/doc/current/messenger.html) 7. [SAP Library: Change Pointer (Master Data Distribution)](https://help.sap.com/doc/saphelp_nw73ehp1/7.31.19/en-us/4a/bb1e253536478be10000000a421937/content.htm?no_cache=true) 8. [SAP Library: Change Pointer (IDoc Interface/ALE)](https://help.sap.com/doc/saphelp_em700_ehp01/7.0.1/en-US/12/83e03c19758e71e10000000a114084/content.htm?no_cache=true) 9. [Infor docs: Infor ION and M3 BODs](https://docs.infor.com/m3cs/10.2.3/en-us/m3csbom/fabsog/goi1495809108914.html) 10. [Infor Developer Portal: Integration with ION](https://developer.infor.com/tutorials/integration-with-ion) 11. [Debezium: open source distributed platform for change data capture](https://debezium.io/) ## Gyakori kérdések Hogyan szinkronizálok termékadatokat SAP-ból Pimcore-ba? A változásokat eseményként vedd ki az SAP-ból ahelyett, hogy minden alkalommal a teljes anyagtörzset olvasnád, például change pointerekkel (a BD61 tranzakcióban aktiválva, az RBDMIDOC riport dolgozza fel), amelyek IDoc-okat állítanak elő. Tedd az üzeneteket üzenetsorba, importáld őket idempotens handlerrel, amely cikkszám alapján upsertel, és kihagyja azokat a rekordokat, amelyek tartalom-hash-e nem változott, és tarts meg egy ütemezett full egyeztetést biztonsági hálóként. Mi a különbség a full sync és a delta sync között? A full sync minden futásnál az összes rekordot beolvassa és összehasonlítja. Egyszerű és önjavító, de lassú, és terheli az ERP-t. A delta sync csak azt viszi át, ami az utolsó futás óta változott: gyors és olcsó, de észrevétlenül elcsúszhat, ha egy változás kimarad. A mindennapokban deltát futtatok, hetente vagy éjszakánként pedig full egyeztetést az elcsúszás kiszűrésére. Hogyan észlelem a megváltozott rekordokat ERP és PIM között? Négy lehetőség van: módosítási időbélyeg, forrásoldali események (SAP change pointer, Infor Sync BOD), change data capture az adatbázison, és egy magad számolt tartalom-hash. Az időbélyeg és az események megmondják, hová nézz, a hash pedig azt, hogy valóban változott-e valami lényeges. Az esemény vagy időbélyeg és a hash kombinációja adja a legjobb eredményt. Használhat a Pimcore üzenetsort importokhoz? Igen. A Pimcore a Symfony Messengert használja, és definiálja a háttérfeladatokhoz a pimcore\_core sort, valamint egy opcionális pimcore\_failed\_jobs transportot a hibákhoz. Az alapértelmezett backend a Doctrine, támogatott még az AMQP (RabbitMQ) és a Redis. A dokumentáció élesben RabbitMQ-t javasol, a workerek indítása: bin/console messenger:consume pimcore\_core. Mit nyújt a Pimcore Data Importer delta importokhoz? A Data Importer CSV, JSON, XML, XLSX és SQL forrásokat olvas, ütemezve, parancssorból vagy üzenetsoron keresztüli push-ra fut, és tartalmaz egy delta ellenőrzést, amely kihagyja a változatlan rekordokat, valamint egy cleanup funkciót, amely törli a forrásból kikerült objektumokat. Fájlalapú feedekhez jól illik. Eseményvezérelt ERP-folyamatokhoz, attribútumonkénti szabályokkal általában saját Messenger handlereket adok hozzá. Hogyan találok Pimcore fejlesztőt SAP vagy ERP integrációhoz? Olyat keress, aki élesben működő szinkront szállított, nem csak demót: kérdezd meg, hogyan kezeli az attribútumonkénti tulajdonlást, az idempotenciát, a hibás üzeneteket és a replayt. A Symfony Messenger, az ERP oldal (IDoc, BOD, OData vagy REST) és a másik végén lévő webshop ismerete többet számít bármelyik eszköznél. Írta: Csorba Balázs Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket. [B2B e-kereskedelem és PIM →](https://balazscsorba.com/hu/expertise/b2b-ecommerce-developer)[Rólam →](https://balazscsorba.com/hu/about) ## További cikkek - [European Accessibility Act B2B webshopoknál: mit kell javítaniuk a Spryker, Pimcore és TYPO3 csapatoknak](https://balazscsorba.com/hu/blog/european-accessibility-act-b2b-shop) - [Headless B2B termékkonfigurátor: szabályok, árazás és Nuxt egy commerce API-n](https://balazscsorba.com/hu/blog/headless-product-configurator-b2b) - [Core Web Vitals Nuxt oldalakhoz és webshopokhoz: LCP, INP és CLS javítása](https://balazscsorba.com/hu/blog/nuxt-core-web-vitals-performance) - [Töltés EPEX ausztriai árakon: mennyit spórol a Home Assistant appom](https://balazscsorba.com/hu/blog/home-assistant-ev-charging-energy-manager) ## Pont erre van szükséged? Írj a projektedről vagy a pozícióról – szívesen hallok felőled. [Beszélgetés kérése](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)