Tri rovnaké karty vstupujú do modrej brány so zámkom a kľúčom, z ktorej vychádza jediná karta; bránu obopínajú oranžové šípky.
Ilustračný vizuál k téme článku vytvorený pomocou AI.

RÝCHLY PREHĽAD

Čo si z článku odniesť

  • Každá dôležitá udalosť potrebuje identitu a sledovateľný výsledok.
  • Opakovaný pokus nesmie opakovať obchodný účinok.
  • Chyby majú mať vlastníka, termín riešenia a možnosť bezpečného obnovenia.

Určite, ktorý systém je zdrojom pravdy

E-shop prijíma objednávku, sklad rezervuje tovar a účtovný systém spravuje doklad. Ak každý systém môže bez pravidiel meniť všetko, vznikajú konflikty. Pre každé pole určite vlastníka: kto rozhoduje o cene, stave platby, dostupnosti a stave expedície. Ostatné systémy dostávajú overenú zmenu alebo posielajú požiadavku na jej vykonanie.

Pri viacerých firmách musí identifikácia obsahovať aj spoločnosť. Rovnaké číslo objednávky môže existovať v dvoch oddelených agendách. Väzba medzi záznamami preto nemá stáť len na čísle zobrazenom zákazníkovi. Potrebujete interné identifikátory a mapovanie medzi systémami. Obchodný rámec opisuje článok o e-shope napojenom na sklad a ERP.

Webhook je oznámenie, nie záruka dokončenia

Webhook oznámi druhej aplikácii udalosť, napríklad úspešnú platbu. Príjemca musí overiť odosielateľa a dáta. Dokumentácia Stripe upozorňuje na overovanie podpisov, možnosť duplicitných udalostí aj na to, že poradie doručenia nemusí byť zaručené. Tieto vlastnosti treba zohľadniť v návrhu každej konkrétnej integrácie podľa jej dokumentácie.

Odporúčame udalosť najprv bezpečne uložiť do frontu a až potom potvrdiť jej prijatie. Samotné obchodné spracovanie môže pokračovať oddelene. Systém tak rozlišuje prijaté, spracované a chybové udalosti. Nestačí vrátiť úspešnú odpoveď a dúfať, že ďalší krok prebehne. Ak potvrdenie odíde skôr než trvalé uloženie, výpadok môže udalosť stratiť.

Zdroje ku kapitole:Stripe: webhooks, podpisy, duplicity a spracovanie udalostí (nová karta)

Idempotencia: ten istý pokyn, jeden účinok

Idempotencia znamená, že bezpečné opakovanie rovnakého pokynu nevytvorí druhú objednávku, rezerváciu alebo faktúru. V praxi si príjemca pamätá jedinečný identifikátor udalosti a výsledok spracovania. Súčasne musí chrániť aj obchodnú operáciu, pretože dve odlišné technické udalosti môžu opisovať tú istú zmenu.

Predstavte si výpadok po vytvorení objednávky v ERP, ale pred doručením potvrdenia späť e-shopu. E-shop skúsi požiadavku znovu. Správny výsledok je nájsť existujúcu väzbu a vrátiť tú istú objednávku, nie založiť ďalšiu. Kontrola musí odolať aj dvom súbežným pokusom; obyčajné „najprv vyhľadaj, potom vytvor“ bez ochrany súbehu nemusí stačiť.

Oneskorené udalosti nesmú vracať zákazku dozadu

Správa „prijatá objednávka“ môže doraziť až po správe „uhradená“. Ak každá bez kontroly prepíše stav, stará informácia zmaže novší výsledok. Použite povolené prechody stavov a dostupnú verziu alebo čas udalosti. Pri konflikte si načítajte aktuálny stav zo zdrojového systému.

Storno a vrátenie platby sú samostatné udalosti. Nevymazávajte históriu úspešného predaja; zaznamenajte nadväzujúcu zmenu. Rovnaký princíp platí pri čiastočnej expedícii a rozdelení objednávky. Jeden univerzálny stav „hotovo“ často nestačí na sklad, dopravu aj doklady.

Prípady, ktoré musí skúška integrácie obsahovať
OblasťPostupČo si overiť
Opakovaný webhookExistujúci výsledok, bez druhej operácie.Počet rezervácií a dokladov.
Výpadok po zápiseOpakovanie nájde už vytvorenú objednávku.Väzbu identifikátorov medzi systémami.
Nesprávne poradieStarší stav neprepíše potvrdený novší.Povolené prechody a históriu.
Chybný údajZáznam sa zastaví s konkrétnou príčinou.Zodpovednú osobu a bezpečný opravný postup.

Automatické opakovanie a pracovný zoznam výnimiek

Dočasný výpadok môže vyriešiť opakovanie s rastúcim odstupom. Chýbajúcu sadzbu, neznámy produkt alebo nesprávnu firmu však samotné opakovanie neopraví. Rozdeľte technické chyby na dočasné a vecné. Po stanovenom limite musí udalosť prejsť do zoznamu na riešenie, nie bežať donekonečna.

Manažér potrebuje vidieť počet zaseknutých objednávok, ich vek, hodnotu a dôvod. Pracovník potrebuje konkrétny ďalší krok a prístup k relevantným podkladom. Po oprave sa má obnoviť len potrebná časť procesu. Návrh ranného prehľadu rozoberáme v článku o dashboarde pre viac firiem.

Overujte aj to, čo neprišlo

Monitoring udalostí odhalí chybovú správu, ale nemusí zachytiť úplne chýbajúcu udalosť. Preto pridajte pravidelné zosúladenie: objednávky na webe verzus ERP, potvrdené platby verzus uhradené objednávky a expedície verzus skladové pohyby. Výnimky musia byť vysvetliteľné a priradené človeku alebo opravnému procesu.

Pilot spustite na jednom toku s obmedzeným rozsahom. Merajte čas spracovania, podiel ručných zásahov, počet duplicít a počet nevyriešených rozdielov. Až keď sa dá výpadok bezpečne obnoviť, rozširujte automatizáciu. Spoľahlivé prepojenie prináša úsporu práve tým, že firma nemusí každý deň ručne kontrolovať, či sa niečo nestratilo.

OD ČÍTANIA K REALIZÁCII

Posuňme to do vašej firmy.

Prejdeme vaše zadanie a vyberieme konkrétny ďalší krok.

Napísať nám o projekte