RYCHLÝ PŘEHLED
Co si z článku odnést
- Každá důležitá událost potřebuje identitu a sledovatelný výsledek.
- Opakovaný pokus nesmí opakovat obchodní účinek.
- Chyby mají mít vlastníka, termín řešení a možnost bezpečného obnovení.
Určete, který systém je zdrojem pravdy
E-shop přijímá objednávku, sklad rezervuje zboží a účetní systém spravuje doklad. Pokud každý systém může bez pravidel měnit všechno, vznikají konflikty. Pro každé pole určitě vlastníka: kdo rozhoduje o ceně, stavu platby, dostupnosti a stavu expedice. Ostatní systémy dostávají ověřenou změnu nebo posílají požadavek na její provedení.
U více firem musí identifikace obsahovat i společnost. Stejné číslo objednávky může existovat ve dvou oddělených agendách. Vazba mezi záznamy proto nemá stát jen na čísle zobrazeném zákazníkovi. Potřebujete interní identifikátory a mapování mezi systémy. Obchodní rámec popisuje článek o e-shopu napojeném na sklad a ERP.
Webhook je oznámení, ne záruka dokončení
Webhook oznámí druhé aplikaci událost, například úspěšnou platbu. Příjemce musí ověřit odesílatele a data. Dokumentace Stripe upozorňuje na ověřování podpisů, možnost duplicitních událostí i na to, že pořadí doručení nemusí být zaručeno. Tyto vlastnosti je třeba zohlednit v návrhu každé konkrétní integrace podle její dokumentace.
Doporučujeme událost nejprve bezpečně uložit do fronty a teprve poté potvrdit její přijetí. Samotné obchodní zpracování může pokračovat odděleně. Systém tak rozlišuje přijaté, zpracované a chybové události. Nestačí vrátit úspěšnou odpověď a doufat, že další krok proběhne. Pokud potvrzení odejde dříve než trvalé uložení, výpadek může událost ztratit.
Idempotence: tentýž pokyn, jeden účinek
Idempotence znamená, že bezpečné opakování stejného pokynu nevytvoří druhou objednávku, rezervaci nebo fakturu. V praxi si příjemce pamatuje jedinečný identifikátor události a výsledek zpracování. Současně musí chránit i obchodní operaci, protože dvě odlišné technické události mohou popisovat tutéž změnu.
Představte si výpadek po vytvoření objednávky v ERP, ale před doručením potvrzení zpět e-shopu. E-shop zkusí požadavek znovu. Správný výsledek je najít existující vazbu a vrátit stejnou objednávku, nikoli založit další. Kontrola musí odolat i dvěma souběžným pokusům; obyčejné „nejprve vyhledej, pak vytvoř“ bez ochrany souběhu nemusí stačit.
Opožděné události nesmí vracet zakázku dozadu
Zpráva „přijatá objednávka“ může dorazit až po zprávě „uhrazená“. Pokud každá bez kontroly přepíše stav, stará informace smaže novější výsledek. Použijte povolené přechody stavů a dostupnou verzi nebo čas události. Při konfliktu si načtěte aktuální stav ze zdrojového systému.
Storno a vrácení platby jsou samostatné události. Nevymazávejte historii úspěšného prodeje; zaznamenejte navazující změnu. Stejný princip platí při částečné expedici a rozdělení objednávky. Jeden univerzální stav „hotovo“ často nestačí na sklad, dopravu i doklady.
| Oblast | Postup | Co si ověřit |
|---|---|---|
| Opakovaný webhook | Stávající výsledek, bez druhé operace. | Počet rezervací a dokladů. |
| Výpadek po zápisu | Opakování najde již vytvořenou objednávku. | Vazbu identifikátorů mezi systémy. |
| Nesprávné pořadí | Starší stav nepřepíše potvrzený novější. | Povoleny přechody a historii. |
| Chybný údaj | Záznam se zastaví s konkrétní příčinou. | Odpovědnou osobu a bezpečný opravný postup. |
Automatické opakování a pracovní seznam výjimek
Dočasný výpadek může vyřešit opakování s rostoucím odstupem. Chybějící sazbu, neznámý produkt nebo nesprávnou firmu však samotné opakování neopraví. Rozdělte technické chyby na dočasné a věcné. Po stanoveném limitu musí událost přejít do seznamu k řešení, ne běžet donekonečna.
Manažer potřebuje vidět počet zaseknutých objednávek, jejich věk, hodnotu a důvod. Pracovník potřebuje konkrétní další krok a přístup k relevantním podkladům. Po opravě se má obnovit jen potřebná část procesu. Návrh ranního přehledu rozebíráme v článku o dashboardu pro více firem.
Ověřujte i to, co nepřišlo
Monitoring událostí odhalí chybovou zprávu, ale nemusí zachytit zcela chybějící událost. Proto přidejte pravidelné sladění: objednávky na webu versus ERP, potvrzené platby versus uhrazené objednávky a expedice versus skladové pohyby. Výjimky musí být vysvětlitelné a přiřazené člověku nebo opravnému procesu.
Pilot spusťte na jednom toku s omezeným rozsahem. Měřte čas zpracování, podíl ručních zásahů, počet duplicit a počet nevyřešených rozdílů. Teprve když lze výpadek bezpečně obnovit, rozšiřujte automatizaci. Spolehlivé propojení přináší úsporu právě tím, že firma nemusí každý den ručně kontrolovat, jestli se něco neztratilo.
