Rendelésszinkron a webshop és az ERP között: SAP API-k, idempotencia és egyeztetés

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 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.

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. 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), 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).
• 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). Az ALE szerializálást is támogat, hogy az egymásra épülő üzenetek sorrendben könyvelődjenek (SAP Help).
• 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). 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.

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). 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).

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). 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).

-- 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). 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.

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). É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 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.

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).

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. A konfigurált termékek saját adattartalom-szabályokat hoznak; lásd headless termékkonfigurátorok B2B-ben.

Források

1. SAP Community: posting sales orders into S/4HANA Cloud via API (2018)
2. SAP Community: S/4HANA OData V4 APIs quick reference (15 Feb 2026)
3. SAP Help: EDI inbound processing, sales order
4. SAP Help: ALE inbound processing
5. SAP Community: custom fields in sales document BAPIs (2024)
6. Microsoft Learn: Business Central API v2.0, create salesOrders
7. Infor Developer Portal: get all sales orders
8. microservices.io: transactional outbox
9. Stripe API reference: idempotent requests
10. Confluent: Kafka message delivery guarantees
11. Mercari Engineering: payment reconciliation (2021)
12. OpenTelemetry: messaging spans semantic conventions