Integrace (ERP, PIM, WMS, platby)

E-shop je jen jeden ze systémů, na kterých firma stojí. Vedle něj běží ERP pro sklady a účetnictví, PIM pro produktová data, WMS pro expedici, platební brány a CRM pro marketing. A právě v integrační vrstvě, která tyto systémy propojuje, vzniká většina produkčních incidentů.

Na co se napojujeme

• ERP: SAP Business One, Microsoft Dynamics 365 Business Central, Pohoda, Money S5, Odoo, NetSuite
• PIM: Akeneo, Pimcore, Plytix a také interní tabulky, které roli PIM pouze suplují
• WMS / 3PL / expedice: Zásilkovna, Packeta, GLS, DPD, FedEx, vlastní skladové systémy
• Platby: Stripe, GoPay, ComGate, PayU, Adyen, Mollie, včetně vrstev pro fraud detection a recurring billing
• CRM / marketing: HubSpot, Klaviyo, Mailchimp, Salesforce
• Analytika a data: BigQuery, Snowflake, Segment, GA4

Jak integrace stavíme

• Idempotentně. Každý webhook může dorazit dvakrát, aniž by vznikla nekonzistence. Reálné systémy požadavky opakují a integrace s tím musí počítat.
• S observabilitou. Každé volání mezi systémy nese v logu correlation ID, takže objednávku, která nedorazila do WMS, dohledáme v logech do minuty.
• Odolně. Výpadek třetí strany integraci nevyřadí z provozu: dead-letter queues, exponenciální backoff a nástroje pro ruční replay.
• S verzovanými kontrakty. API kontrakt leží v repozitáři, takže změnu schématu na straně dodavatele zachytíme už při deployi, a ne až v produkci.
• S testy. Kontraktové testy proti nahraným odpovědím a smoke testy proti sandboxu při každém deployi.

Z čeho tato pravidla vycházejí

Žádné z uvedených pravidel není teorie. Každé vychází z konkrétního incidentu na e-shopu, na kterém jsme pracovali:

• Synchronizace stavů se na týdny zastavila, aniž by kdy selhala: ERP posílalo 300 000 stavů k objednávkám, které v e-shopu nikdy neexistovaly. Vyčerpalo tím chybový rozpočet importního nástroje a každý běh se předčasně ukončil bez chybového hlášení, dřív, než došlo na skutečná data. Poučení: error budgety se monitorují, nejen konfigurují.
• Čerstvě nasazená synchronizace objednávek přepsala pole, která patřila konektoru na marketplace, a zásilky za celý den se na marketplaces nedostaly. Od té doby má každý synchronizovaný sloupec právě jednoho deklarovaného vlastníka a synchronizace do polí jiných vlastníků nezapisuje.
• Stored procedura v ERP vyhazovala SQL výjimky, a přitom vracela „success“. Odhalili jsme to přehráním 1 300 reálných objednávek přes integraci ještě před spuštěním; dnes je to standardní předprodukční test pro každý tok, na kterém stojí objednávky.
• Rozbitý feed se jednou pokusil v jediném běhu smazat desítky tisíc produktů. Prahy pro mazání s circuit breakerem má od té chvíle každá synchronizace katalogu, kterou stavíme.
• Platby se přestaly párovat s objednávkami, protože firewall hostingu rate-limitoval webhooky platební brány. Opravou byl whitelist; najít ji znamenalo přečíst HTTP logy, do kterých se předtím nikdo nepodíval.

B2B e-commerce

B2B se řídí jinými pravidly než prodej koncovým zákazníkům: kupující jsou zaměstnanci firem, ceny závisí na smlouvách a objednávky procházejí schvalováním. Stavíme proto i tuto vrstvu: firemní účty s rolemi a hierarchiemi, zákaznické katalogy se smluvními cenami, workflow quote-to-order, platební podmínky (net 30/60/90, kreditní limity, fakturace napojená na ERP) a napojení na nákupní systémy, tedy punchout (OCI, cXML, Ariba) a EDI pro zákazníky, kteří dosud posílají zprávy 850.

Jak spolupráce obvykle začíná

Integrační práci vymezujeme podle selhání, které už vidíte: objednávky, která nikdy nedorazila do WMS, skladového stavu, který se každou noc rozchází s realitou, nebo CSV, které někdo každé ráno upravuje ručně. Celý tok zmapujeme od začátku do konce, scope i pevnou cenu dostanete písemně a náhradu postavíme tak, aby se příští selhání ohlásilo samo, místo aby zůstalo týden neodhalené. Průběžný provoz, včetně monitoringu, u nás může zůstat jako měsíční paušál.