> Rendelések szinkronizálása B2B webshop és ERP között: SAP OData, IDoc és BAPI, az outbox minta, idempotenciakulcsok és rendszeres egyeztetés. > > Web page: https://balazscsorba.com/hu/blog/b2b-order-sync-erp · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/b2b-order-sync-erp.md) · [Deutsch](https://balazscsorba.com/de/blog/b2b-order-sync-erp.md) > Author: Balázs Csorba · Published: 2026-10-08 · Keywords: order sync between shop and ERP, sap sales order api, odata sales order s/4hana, idoc orders05, transactional outbox pattern, idempotency key, erp reconciliation report, sap event mesh sales order created, bapi_salesorder_createfromdat2, shop erp order integration [Blog](https://balazscsorba.com/hu/blog)/Webfejlesztés # Rendelésszinkron a webshop és az ERP között: SAP API-k, idempotencia és egyeztetés Rendelések szinkronizálása B2B webshop és ERP között: SAP OData, IDoc és BAPI, az outbox minta, idempotenciakulcsok és rendszeres egyeztetés. [Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 8.·8 perc olvasás - ERP integration - SAP - Idempotency - Outbox pattern - Reconciliation ![Két doboz nyílkörrel összekötve, rajta egy boríték és egy bizonylat.](https://balazscsorba.com/images/blog/b2b-order-sync-erp/cover.webp?v=189dd9c716) ## A lényeg röviden - A rendelésszinkron tranzakciós bizonylatok köre: a webshop rendeléséből ERP vevői rendelés lesz, a visszaigazolások, szállítások és számlák visszafelé áramlanak; a sztornók és visszáruk új bizonylatok, nem törlések. - Az SAP-ban a fő útvonalak a vevői rendelés OData API-ja, az ORDERS üzenettípusú és ORDERS05 alaptípusú IDocok, valamint a BAPI\_SALESORDER\_CREATEFROMDAT2, amelyhez kifejezett BAPI\_TRANSACTION\_COMMIT kell. - A rendelést és egy outbox-sort egyetlen adatbázis-tranzakcióban írja, fogadja el, hogy a továbbító kétszer is közzéteheti, és tegye az ERP-írót idempotenssé a webshop rendelési hivatkozására. - A pontosan egyszeri kézbesítés ritkán éli túl az ERP határát; a Kafka alapértelmezésben legalább egyszer kézbesít, ezért a duplikátumokra tervezzen, ne azok elkerülésében bízzon. - Az egyeztetés rutinmunka: rendszeresen vesse össze a webshop és az ERP állapotát, sorolja be az eltéréseket, és ugyanazzal az íróval javítson, amely a normál rendeléseket kezeli. Ezen az oldalon 1. [Mit fed le a rendelésszinkron?](https://balazscsorba.com/#what-order-sync-covers) 2. [Melyik rendelési állapot kié?](https://balazscsorba.com/#the-order-lifecycle-between-shop-and-erp) 3. [Milyen SAP integrációs lehetőségek vannak a rendelésekhez?](https://balazscsorba.com/#sap-integration-options) 4. [Mi a helyzet a Dynamics 365-tel, az Inforral és más ERP-kkel?](https://balazscsorba.com/#beyond-sap) 5. [Milyen kézbesítési garanciák érhetők el valójában?](https://balazscsorba.com/#delivery-guarantees-batch-event-queue) 6. [Hogyan működik együtt az outbox és az idempotencia?](https://balazscsorba.com/#idempotency-and-the-outbox) 7. [Milyen hibák fordulnak elő, és hogyan fogja meg őket az egyeztetés?](https://balazscsorba.com/#failure-modes-and-reconciliation) 8. [Tesztelés, megfigyelhetőség és élesítési ellenőrzőlista](https://balazscsorba.com/#testing-observability-and-checklist) 9. [Források](https://balazscsorba.com/#sources) Cikk meghallgatása 0:000:00 A **webshop és az ERP közötti rendelésszinkron** az a tranzakciós bizonylatkör, amely a webshop rendeléséből ERP vevői rendelést csinál, és visszahozza a visszaigazolásokat, a szállítási állapotot és a számlákat. A termékadat-szinkronnal ellentétben itt a hiba nem egy rossz ár egy oldalon, hanem egy duplikált vevői rendelés, egy elveszett rendelés vagy egy nem egyező számla, vagyis pénzügyi incidens. Ez a cikk sorra veszi, melyik állapot kié, az SAP integrációs lehetőségeit és megfelelőiket a Dynamics 365 Business Centralban és az Inforban, a kézbesítési garanciákat, az outbox mintát idempotens fogyasztókkal, a hibamódokat és az egyeztetést, valamint a tesztelést és a megfigyelhetőséget. A termék-törzsadatok szinkronja külön téma, ezt a [Pimcore ERP delta szinkron](https://balazscsorba.com/hu/blog/pimcore-erp-delta-sync) című cikk tárgyalja. ## Mit fed le a rendelésszinkron? A két rendszer közötti minden tranzakciós bizonylatot lefed: a kimenő rendelést, valamint a visszaérkező rendelés-visszaigazolást, elérhetőségi és árkorrekciókat, szállítási állapotot és számlákat. A sztornók és visszáruk nem törlések, hanem új, kiegyenlítő bizonylatok, amelyek ugyanazon a körön haladnak át. ![Bizonylatkör a webshop és az ERP között Öt bizonylat balról jobbra: a webshop rendelése a webshopból az ERP-be megy; az ERP vevői rendelése a hiteles rekord; a rendelés-visszaigazolás, a szállítási állapot és a számla az ERP-ből a webshopba áramlik vissza. A sztornók és visszáruk új, kiegyenlítő bizonylatok ugyanebben a körben, nem törlések.](https://balazscsorba.com/images/blog/b2b-order-sync-erp/diagram-4.webp?v=c815b9454b) A rendelési kör: egy bizonylat megy ki, több jön vissza, és a javítások új bizonylatok, nem a régiek módosításai. ## Melyik rendelési állapot kié? A webshop a belépési pontért és az ügyfél nézetéért felel; az ERP az árazásért, a készletallokációért, a hitelellenőrzésért, a szállításért és a számlázásért. A „szinkronban van” ezért mezőnként mást jelent: a webshop rendelésszáma a webshopé, és változatlanul kell az ERP-be érkeznie, a visszaigazolt szállítási dátum viszont az ERP-é, a webshop csak megjelenítheti. Ezt a felelősséget mezőnként írja le, mielőtt kódot írna. Ez dönti el, melyik oldal nyer ütközéskor, melyik javíthat egy értéket, és mit mondhat őszintén egy ügyfélszolgálati asszisztens; egy ügyfeleknek szóló asszisztens csak akkor tud válaszolni a „hol a rendelésem” kérdésre, ha ez a kör megbízható, lásd [AI ügyfélszolgálat B2B webshopoknak](https://balazscsorba.com/hu/blog/ai-assistant-b2b-shop-customer-support). Több mint tízévnyi Spryker és Pimcore projekt alatt azt láttam, hogy a termékszinkron hibái rossz árként jelennek meg egy oldalon, a rendelésszinkron hibái pedig a pénzügyi osztályon, ezért foglalkozik ez a cikk a legtöbbet az idempotenciával és az egyeztetéssel. A részleges eredmények a B2B-ben a szokásosak, nem kivételek. Az ERP most 100-ból 80 darabot igazolhat vissza, a többit jövő héten, lecserélhet egy kifutott cikket, vagy módosíthat egy árat, mert változott a szerződés. A webshopnak ezeket a változásokat úgy kell megmutatnia, ahogy vannak, vagyis az állapotmodellnek tételszintű állapotok kellenek, a visszaigazoló üzenetnek pedig tételeket kell frissítenie, nem a teljes rendelést felülírnia. ## Milyen SAP integrációs lehetőségek vannak a rendelésekhez? Három család: a vevői rendelés OData API-ja, az ALE-n keresztüli IDocok és az RFC-n keresztüli BAPI-k. Mindegyik más környezetben nyer, és sok rendszerkörnyezet egynél többet is futtat. - **OData API:** az API\_SALES\_ORDER\_SRV vevőirendelés-szolgáltatás támogatja a létrehozást, olvasást, módosítást és törlést; egy 2018-as SAP Community bejegyzés szerint a tételek csak a fej és a tételek együttes, mély beszúrásával könyvelhetők ([SAP Community](https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/posting-sales-orders-into-s-4hana-cloud-api-part-1/ba-p/13350199)), ezért ellenőrizze a viselkedést a saját kiadásán. Az irány az OData V4: az SAP 2026. február 15-én 363 V4 API-t listázott az on-premise S/4HANA-hoz ([SAP Community](https://community.sap.com/t5/financial-management-blog-posts-by-sap/sap-s-4-hana-odata-v4-apis-available-quick-reference-and-available-in-sap/ba-p/14328827)). - **IDoc és ALE:** a klasszikus EDI-útvonal az ORDERS üzenettípust, az ORDERS05 alaptípust, az ORDE feldolgozási kódot és az IDOC\_INPUT\_ORDERS bejövő függvényt használja, vevőnkénti partnerprofilban beállítva; a hibák munkafolyamat-tételt hoznak létre, a feldolgozás azonnali vagy háttérben futó lehet ([SAP Help](https://help.sap.com/doc/saphelp_nw70/7.0.12/ja-JP/dc/6b7cac43d711d1893e0000e8323c4f/content.htm)). Az ALE szerializálást is támogat, hogy az egymásra épülő üzenetek sorrendben könyvelődjenek ([SAP Help](https://help.sap.com/doc/saphelp_nw75/7.5.5/en-US/4d/51189400071c86e10000000a42189b/content.htm)). - **BAPI RFC-n:** a BAPI\_SALESORDER\_CREATEFROMDAT2 fej-, partner- és tételtáblákból hozza létre a rendelést, a bizonylatszámot a SALESDOCUMENT, az üzeneteket a RETURN paraméterben adja vissza, és nem véglegesít; a hívónak kell lefuttatnia a BAPI\_TRANSACTION\_COMMIT-ot ([SAP Community](https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/how-to-use-custom-fields-in-sales-document-bapis/ba-p/13721645)). Az elfelejtett commit a klasszikus „az API azt mondta, rendben, de semmi sincs ott” incidens. Hogyan válasszon: ha a webshop felhőben fut, és a pénztárban választ vár, az OData API a természetes választás. Ha az ügyfél már EDI-rendeléseket küld, és az SAP-csapat IDoc-felügyeletet üzemeltet, az ORDERS05 újrahasznosítása egyetlen üzemeltetési modellt tart fenn. A BAPI-k olyan köztes réteghez illenek, amely már RFC-hozzáféréssel ül az SAP mellett. Bármit választ, a deduplikációs kulcs és az egyeztető feladat ugyanaz marad, ezért kezelje cserélhetőként az átvitelt. Lehetőség Késleltetés Csatolás Kézbesítési szemantika Tipikus alkalmazás OData API (V2 vagy V4) szinkron, másodpercek közvetlen HTTP-hívás a hívó próbál újra; dedup természetes kulccsal webshopok, felhős ERP IDoc ALE-n sorban, percek aszinkron, partnerprofilok állapotrekordok, újrafeldolgozás EDI, nagy volumen, on-premise BAPI RFC-n szinkron, másodpercek szoros, RFC-kapcsolat kell kifejezett commit; a hívó kezeli az újrapróbálást SAP-hoz közeli köztes réteg Kötegelt fájl ütemezett, órák laza újrafuttatás, fájlszintű dedup kis volumen, régi rendszerek ## Mi a helyzet a Dynamics 365-tel, az Inforral és más ERP-kkel? A formák hasonlók, és elsőként a deduplikációs horgonyt érdemes keresni. A Business Central `POST /api/v2.0/companies({id})/salesOrders` hívással hoz létre vevői rendelést, és 201 Created választ ad; az `externalDocumentNumber` mező a webshop rendelési hivatkozásának természetes helye ([Microsoft Learn](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/api/dynamics_salesorder_create)). Az Infor az ION API Gateway-en keresztül, OAuth 2.0-val teszi elérhetővé a vevői rendeléseket; az üzleti objektum API alapértelmezett lapmérete 100, a maximum 20 000, a hibaválaszok pedig `retryable` jelzőt hordoznak ([Infor](https://developer.infor.com/business-obj-v1/sales-order/get-all-sales-orders)). Az ERP-k közötti hordozhatóság olcsóbb, ha a webshop egyetlen belső rendelési porttal beszél, és minden ERP vékony adaptert kap. A port határozza meg a kanonikus rendelést, a deduplikációs kulcsot és az állapotszótárat; az adapter képezi le a mezőket és a hibákat. Itt tud egy olyan jelző, mint az Infor `retryable` mezője, közvetlenül az újrapróbálási szabályba kerülni. ## Milyen kézbesítési garanciák érhetők el valójában? Legalább egyszeri kézbesítés, idempotenciával biztonságossá téve. A Kafka alapértelmezése a legalább egyszeri kézbesítés; a 0.11.0.0 verzió óta az idempotens producer termelőazonosítóval és sorszámokkal szűri ki a saját újrapróbálásaiból eredő duplikátumokat, a tranzakciós pontosan egyszeri garancia pedig csak akkor érvényes, ha a teljes folyamat Kafkán belül marad ([Confluent](https://docs.confluent.io/kafka/design/delivery-semantics.html)). Egy ERP-hívás ezen a határon kívül esik, így a pontosan egyszeri garancia nem éli túl. Ez határozza meg a választást egy egyszerű újrapróbáló ciklus és egy üzenetbusz között. Egy webshophoz és egy ERP-hez mérsékelt forgalommal elég egy outbox-táblát olvasó worker szinkron API-hívása. A busz akkor éri meg, ha több fogyasztónak kellenek ugyanazok a rendelési események, például egy raktárrendszernek és az elemzésnek, vagy ha az ERP saját üzleti eseményeket küld; az S/4HANA például vevőirendelés-eseményeket tud közzétenni az SAP Event Meshben. A fogyasztónak mindkét esetben tűrnie kell a duplikátumokat. Az újrapróbálási szabályt hibaosztályonként határozza meg, ne hívásonként. Az időtúllépések és 5xx válaszok korlátozott számú újrapróbálást kapnak exponenciális visszalépéssel és jitterrel; a validációs hibák, például ismeretlen ügyfél vagy zárolt anyag, közvetlenül emberhez kerülnek, mert az ismétlés csak zajt termel. Az utolsó próbálkozás után az üzenet a hibájával együtt dead letter tárolóba kerül, hogy javítás után ugyanazon az írón keresztül újra lefuttatható legyen, ne kézzel kelljen újra rögzíteni. ## Hogyan működik együtt az outbox és az idempotencia? Az outbox biztosítja, hogy egyetlen rendelés se mentődjön az üzenete nélkül, az idempotencia pedig azt, hogy egy kétszer kézbesített üzenet ne hozzon létre két rendelést. A tranzakciós outbox mintában az üzleti írás és az outbox-sor egy adatbázis-tranzakcióban véglegesül, a továbbító pedig később tesz közzé; a továbbító egy üzenetet többször is közzétehet, ezért a fogyasztóknak idempotensnek kell lenniük, például a feldolgozott üzenetazonosítók nyilvántartásával ([microservices.io](https://microservices.io/patterns/data/transactional-outbox.html)). ![Outbox, idempotens író és egyeztető A webshop adatbázisa egy tranzakcióban írja a rendelést és az outbox-sort. Egy továbbító közzéteszi az üzenetet, akár kétszer is. Az ERP-író idempotenciakulccsal hozza létre a vevői rendelést, az ERP pedig a webshop rendelési hivatkozása alapján szűri a duplikátumokat. Egy egyeztető ütemezetten összeveti a webshop és az ERP állapotát, és ugyanazon az ERP-írón keresztül küld javító parancsokat.](https://balazscsorba.com/images/blog/b2b-order-sync-erp/diagram-23.webp?v=57e9898c6e) Outbox, idempotens író és egyeztető: a duplikátumokra számítunk és elnyeljük őket, a javítások pedig ugyanazt az írási utat használják, mint a normál rendelések. ``` -- One transaction: the order and the message that announces it BEGIN; INSERT INTO orders (id, customer_id, total, status) VALUES ('SO-2026-104233', 'C-40017', 1840.00, 'placed'); INSERT INTO outbox (id, aggregate_id, type, payload) VALUES (gen_random_uuid(), 'SO-2026-104233', 'OrderPlaced', '{"lines": 7}'); COMMIT; ``` ``` // Idempotent consumer (sketch): the shop order id is the dedupe key all the way into the ERP async function handleOrderPlaced(msg: OutboxMessage) { if (await processed.has(msg.id)) return // the relay may deliver twice await withLock(`order:${msg.aggregateId}`, async () => { // one writer per order at a time const existing = await erp.findSalesOrder({ customerReference: msg.aggregateId }) if (!existing) await erp.createSalesOrder(toErpPayload(msg)) // header and items in one call }) await processed.add(msg.id) } ``` A webshop rendelésazonosítóját használja végig kulcsként, és tegye olyan mezőbe, amelyben az ERP keresni tud, például az SAP vevői rendelés vevői megrendelésszámába vagy a Business Central `externalDocumentNumber` mezőjébe. Az Ön által kezelt HTTP API-khoz a Stripe idempotencia-megoldása jó referencia: a kliens kulcsot küld, az újrapróbálások a mentett választ kapják, a paramétereket összevetik az eredeti kéréssel, a kulcsok pedig legalább 24 óra után törölhetők ([Stripe](https://docs.stripe.com/api/idempotent_requests)). A keres-majd-létrehoz megközelítésben versenyhelyzet van, ezért tart a fenti vázlat rendelésenkénti zárat; ahol elérhető, az ERP-ben a hivatkozásra tett egyediségi megkötés erősebb. **Javításhoz soha ne töröljön** Ha egy rendelés elromlott, egyik rendszerben se törölje az „újraszinkronizálás” kedvéért. Sztornózza kiegyenlítő bizonylattal, és ugyanazzal az íróval hozzon létre újat. A törlés megtöri az audit nyomvonalat, összezavarja az egyeztetést, és az ERP-ben ütközhet olyan szállításokkal vagy számlákkal, amelyek már a rendelésre hivatkoznak. ## Milyen hibák fordulnak elő, és hogyan fogja meg őket az egyeztetés? Duplikált vevői rendelések, elveszett nyugták, elveszett rendelések, részleges hibák, például fej tételek nélkül, ár- vagy mértékegység-eltérés, valamint állapoteltérés egy visszaállítás vagy egy kézi ERP-módosítás után. Az egyeztetés az a rutinfeladat, amely ezeket megtalálja, nem vészhelyzeti eszköz. A Mercari mérnökcsapata három gyakorlati kategóriát ír le a fizetési egyeztetéshez, amelyek közvetlenül átvihetők a rendelésekre: helyben sikeres, de a függő rendszerben nem, a függő rendszerben sikeres, de helyben nem, valamint mindkettőben sikeres, de eltérő részletekkel, ami általában esetenkénti kezelést igényel ([Mercari Engineering](https://engineering.mercari.com/en/blog/entry/20211222-1df9e3a553/)). Én rendelésenként háromféle állapotot tartanék: amit a webshop akar, amit alkalmazottként ismer az utolsó egyeztetés időbélyegével, és amit az ERP mond, az egyeztető pedig felismer, besorol, rögzít és javító parancsot ütemez. Maga a javítás ugyanazon a hiteles írón fut, mint a normál rendelések, így minden idempotencia-szabály érvényes marad. Mérje a legrégebbi egyeztetetlen rendelés korát; ha nő, valami megállt a folyamat elején. Ha a hibák felhalmozódnak, valakinek olvasnia kell az IDoc-állapotrekordokat, az OData-hibákat és a dead letter sorokat, és döntenie kell, mit próbál újra; ebben egy ágens segíthet, ahogy az [ágens ERP-integrációs hibákhoz](https://balazscsorba.com/hu/blog/erp-integration-error-agent) című cikk leírja. Az e-mailben, nem a webshopon át érkező rendelésekre a létrehozó hívásnál ugyanazok az idempotencia-szabályok érvényesek, lásd [e-mailes rendelésrögzítés automatizálása](https://balazscsorba.com/hu/blog/b2b-email-order-entry-llm). ## Tesztelés, megfigyelhetőség és élesítési ellenőrzőlista ERP homokozó- vagy QA-kliensen teszteljen tesztvállalati kódokkal, és tegye egy elakadt rendelést visszakövethetővé a webshop commitjától az ERP nyugtájáig. Az OpenTelemetry üzenetkezelési konvenciói publish, receive, process és settle spaneket határoznak meg a producer és a consumer nyomkövetései közötti linkekkel, és ez pontosan ennek a folyamatnak a formája ([OpenTelemetry](https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/)). 1. Írja le a mezők gazdáját: melyik rendszer melyik rendelési mezőért és állapotért felel. 2. A rendelést és az outbox-sort egy tranzakcióban írja. 3. Vigye a webshop rendelésazonosítóját egy kereshető ERP-mezőbe, és erre deduplikáljon. 4. Véglegesítsen kifejezetten, ahol az API megköveteli, például BAPI\_TRANSACTION\_COMMIT-tal. 5. Küldje el kétszer ugyanazt a rendelést a homokozóban, és pontosan egy vevői rendelést várjon; én ezt a valódi webshop-felületről Playwright MCP-vel szkriptelem. 6. Futtasson ütemezett, kétirányú egyeztetést, és rögzítsen minden eltérést. 7. Kövesse minden rendelés útját a publish, receive és process lépéseken át, és riasszon a sor korára és a legrégebbi egyeztetetlen rendelésre. 8. Kiegyenlítő bizonylatokkal javítson, soha ne törléssel. Ha egy B2B webshopot köt SAP-hoz, Business Centralhoz vagy Inforhoz, és azt szeretné, hogy a rendelési kör unalmas maradjon, nézze meg a [B2B e-kereskedelmi munkámat](https://balazscsorba.com/hu/expertise/b2b-ecommerce-developer). A konfigurált termékek saját adattartalom-szabályokat hoznak; lásd [headless termékkonfigurátorok B2B-ben](https://balazscsorba.com/hu/blog/headless-product-configurator-b2b). ## Források 1. [SAP Community: posting sales orders into S/4HANA Cloud via API (2018)](https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/posting-sales-orders-into-s-4hana-cloud-api-part-1/ba-p/13350199) 2. [SAP Community: S/4HANA OData V4 APIs quick reference (15 Feb 2026)](https://community.sap.com/t5/financial-management-blog-posts-by-sap/sap-s-4-hana-odata-v4-apis-available-quick-reference-and-available-in-sap/ba-p/14328827) 3. [SAP Help: EDI inbound processing, sales order](https://help.sap.com/doc/saphelp_nw70/7.0.12/ja-JP/dc/6b7cac43d711d1893e0000e8323c4f/content.htm) 4. [SAP Help: ALE inbound processing](https://help.sap.com/doc/saphelp_nw75/7.5.5/en-US/4d/51189400071c86e10000000a42189b/content.htm) 5. [SAP Community: custom fields in sales document BAPIs (2024)](https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/how-to-use-custom-fields-in-sales-document-bapis/ba-p/13721645) 6. [Microsoft Learn: Business Central API v2.0, create salesOrders](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/api/dynamics_salesorder_create) 7. [Infor Developer Portal: get all sales orders](https://developer.infor.com/business-obj-v1/sales-order/get-all-sales-orders) 8. [microservices.io: transactional outbox](https://microservices.io/patterns/data/transactional-outbox.html) 9. [Stripe API reference: idempotent requests](https://docs.stripe.com/api/idempotent_requests) 10. [Confluent: Kafka message delivery guarantees](https://docs.confluent.io/kafka/design/delivery-semantics.html) 11. [Mercari Engineering: payment reconciliation (2021)](https://engineering.mercari.com/en/blog/entry/20211222-1df9e3a553/) 12. [OpenTelemetry: messaging spans semantic conventions](https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/) ## Gyakori kérdések Hogyan szinkronizálhatók a rendelések egy webshop és az SAP között? Gyakori útvonalak a vevői rendelés OData API-ja, az ORDERS üzenettípusú és ORDERS05 alaptípusú bejövő IDocok, vagy a BAPI\_SALESORDER\_CREATEFROMDAT2 RFC-n keresztül. A csatolás és a késleltetés igénye szerint válasszon, majd adjon hozzá outboxot a webshopban, a webshop rendelési hivatkozására kulcsolt idempotens írót és ütemezett egyeztetést. Hogyan előzhetők meg a duplikált vevői rendelések az ERP-ben? Vigye át a webshop rendelési hivatkozását egy olyan mezőbe, amelyet az ERP ellenőrizni tud, például az SAP vevői rendelés vevői megrendelésszámába vagy a Business Central externalDocumentNumber mezőjébe, ellenőrizze létrehozás előtt, és a fogyasztóban tartson feldolgozottüzenet-táblát. Az újrapróbálások így a meglévő rendelést találják meg, nem hoznak létre másodikat. Mi a tranzakciós outbox minta? A webshop a rendelést és egy üzenetsort ugyanabban a tranzakcióban írja a saját adatbázisába. Egy külön továbbító később teszi közzé az üzenetet, és akár többször is, ezért a fogyasztónak idempotensnek kell lennie. A minta megszünteti azt a rést, amikor a rendelés elmentődik, de az üzenete elvész, vagy fordítva. Lehetséges a pontosan egyszeri kézbesítés webshop és ERP között? A gyakorlatban nem. A Kafka tranzakciós pontosan egyszeri garanciája csak akkor érvényes, ha a teljes folyamat Kafkán belül marad, egy ERP-hívás pedig ezen kívül esik. Tervezzen legalább egyszeri kézbesítésre idempotens fogyasztókkal és természetes kulcsokkal az ERP-ben, és egyeztessen, hogy megtalálja, ami így is átcsúszik. Mit ellenőrizzen egy rendelés-egyeztető feladat? Azokat a rendeléseket, amelyek a webshopban léteznek, de az ERP-ben nem, azokat az ERP-ben lévő rendeléseket, amelyeket a webshop nem ismer, és a mindkét helyen meglévő, de eltérő részletű rendeléseket, például mennyiség, ár vagy állapot szerint. Rögzítsen minden eltérést, ütemezzen javító parancsot, és ugyanazon a hiteles írón futtassa a javítást, mint a normál rendeléseket. Í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 - [Schema.org strukturált adatok B2B webshopokhoz: bejelentkezés mögötti árak, egységek és változatok](https://balazscsorba.com/hu/blog/schema-org-structured-data-b2b-shop) - [AI-asszisztens a B2B webshop ügyfélszolgálatához: eszközök, jogosultságok és átadás embernek](https://balazscsorba.com/hu/blog/ai-assistant-b2b-shop-customer-support) - [AI-csevegő UI Vue-ban és Nuxtban: akadálymentes streaming](https://balazscsorba.com/hu/blog/vue-ai-chat-ui-streaming-accessibility) - [LLM-fordítási pipeline i18n-hez: glosszárium, helyőrzők és review](https://balazscsorba.com/hu/blog/llm-translation-pipeline-i18n) ## Pont erre van szükséged? Írj a projektedről vagy a pozícióról – szívesen hallok felőled. [Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)