Z praxe

Výpadek e-shopu nebo API: jak bezpečně zopakovat přenos

Bezpečné opakování datového přenosu po výpadku e-shopu nebo API

Když MAXim načítá objednávky z e-shopu nebo předává data dopravci, dodavateli či jiné externí službě, může se komunikace přerušit v kterémkoli okamžiku. E-shop může být dočasně nedostupný, API může mít odstávku, internetové spojení se přeruší, vyprší časový limit, selže přihlášení nebo cílová služba vrátí chybovou odpověď.

Nejistota vzniká hlavně tehdy, když systém požadavek odešle, ale nedostane potvrzení o jeho zpracování. Cílová služba jej mohla odmítnout, ale také přijmout a zpracovat těsně před přerušením spojení. Správně navržená integrace proto neřeší jen další pokus. Musí jej provést tak, aby se neztratila data a současně nevznikla duplicitní objednávka, doklad nebo zásilka.

Výpadek není potvrzení úspěšného přenosu

Záznam se nemá označit jako úspěšně přenesený jen proto, že byl požadavek odeslán. Dokončení přenosu lze potvrdit až ve chvíli, kdy cílová služba vrátí očekávanou odpověď a je zřejmé, že data přijala správně.

Pokud se spojení přeruší, vyprší časový limit nebo přijde chybová odpověď, přenos musí zůstat dohledatelný jako nedokončený. Jinak by mohl z dalšího zpracování zmizet, přestože se objednávka, cena nebo doklad do cílového systému vůbec nedostaly.

Stejně důležité je nepovažovat každý výpadek automaticky za důkaz, že cílová služba nic nezpracovala. Chybějící potvrzení znamená nejistý výsledek, který je potřeba před dalším krokem správně vyhodnotit.

Proč nestačí požadavek posílat stále znovu

Bezhlavé opakování může být stejně nebezpečné jako vynechaný přenos. Pokud externí služba první požadavek přijala, ale odpověď se cestou ztratila, další stejný požadavek může založit druhou objednávku, druhou zásilku nebo další doklad.

Nepřetržité pokusy navíc zbytečně zatěžují vlastní systém i službu, která právě řeší delší výpadek. Integrace proto musí rozlišovat, které přenosy už mají správné potvrzení, které čekají na další pokus a u kterých je nejprve nutné ověřit výsledek předchozí komunikace.

Každý přenos musí být dohledatelný

Pro řízené opakování je potřeba evidovat průběh jednotlivých přenosů. Konkrétní provedení se liší podle integrace a možností cílové služby, ale obsluha by měla být schopná dohledat zejména:

  • který záznam se přenášel a jakým směrem,
  • jeho jednoznačný interní nebo externí identifikátor,
  • kdy proběhl poslední pokus,
  • jakou odpověď nebo chybu externí služba vrátila,
  • zda bylo zpracování správně potvrzeno,
  • zda záznam čeká na kontrolu nebo další pokus.

Dokončeným se přenos stane až po správném potvrzení. Pokud se nepodaří přihlášení, API není dostupné nebo potvrzení nepřijde, záznam zůstane připravený k navazujícímu zpracování a neztratí se z přehledu.

Po obnovení spojení se opakují jen nedokončené přenosy

Jakmile je komunikace znovu dostupná, není potřeba přenášet všechno od začátku. Znovu se zpracují pouze záznamy, u kterých chybí potvrzený výsledek. Úspěšně dokončené přenosy se neposílají znovu.

Podle konkrétní integrace může další pokus proběhnout automaticky nebo jej spustí obsluha po kontrole příčiny. Mezi pokusy je vhodné ponechat časový odstup. Při delší odstávce tak systém neposílá požadavky nepřetržitě a externí služba dostane prostor k obnovení provozu.

Automatické opakování dává smysl například u krátké nedostupnosti nebo časového limitu. Řízený zásah může být vhodnější tehdy, když odpověď upozorňuje na chybná data, změnu oprávnění nebo stav, který musí nejprve posoudit člověk.

Jednoznačný identifikátor chrání před duplicitou

Objednávka, doklad, zásilka nebo jiný přenášený záznam by měl mít jednoznačný identifikátor, který zůstává stejný i při opakovaném pokusu. Díky němu lze poznat, že nejde o nový požadavek, ale o pokračování dříve zahájeného přenosu.

Před opakovaným vytvořením záznamu je potřeba podle dostupných možností ověřit, zda už jej cílová služba nezpracovala. Některé služby umějí opakovaný externí identifikátor odmítnout, jiné dovolí existující záznam vyhledat nebo zjistit jeho stav. Jinde musí integrace použít jiný dostupný způsob kontroly.

Nelze proto předpokládat, že každý e-shop, dopravce nebo dodavatelské API podporuje stejné mechanismy. Bezpečný postup se vždy navrhuje také podle toho, jaké možnosti konkrétní externí služba skutečně nabízí.

Import objednávek z e-shopu

Při importu objednávek se může spojení přerušit během načítání nebo ukládání. Po obnovení komunikace musí systém rozpoznat, které objednávky už byly v MAXimu založené a které ještě chybějí.

Kontrolním bodem může být jednoznačné číslo nebo externí ID objednávky z e-shopu. Pokud se stejná objednávka objeví při dalším načtení, integrace nejprve ověří její předchozí zpracování. Tím se zabrání tomu, aby výpadek a následný pokus vytvořily druhý doklad pro tentýž nákup.

Skladové zásoby a ceny: odeslat aktuální platnou hodnotu

Když se nepodaří předat stav skladu nebo cenu do e-shopu, záznam se nemá považovat za vyřízený. Změna musí zůstat viditelná jako nedokončená, aby se k ní integrace po obnovení spojení mohla vrátit.

U těchto údajů bývá důležité pracovat s aktuální platnou hodnotou. Pokud se během výpadku zásoba nebo cena změnila několikrát, může být podle pravidel konkrétního napojení vhodné po obnovení komunikace odeslat poslední správný stav namísto všech mezilehlých změn. Rozhodující je, aby e-shop nakonec dostal platný údaj a obsluha viděla, zda byl potvrzen.

Doklady a zásilky: nejdřív zjistit, co se skutečně stalo

U dokladů, zásilek a podobných záznamů je potřeba zvlášť pečlivě rozlišit dvě situace. V první cílová služba požadavek vůbec nepřijala. Ve druhé jej přijala a zpracovala, ale potvrzení se už nestihlo vrátit.

Před založením nového záznamu se proto kontroluje jeho jednoznačný identifikátor a dostupný stav na straně externí služby. Teprve podle výsledku lze rozhodnout, zda má pokračovat původní přenos, zopakovat se požadavek, nebo se už pouze doplní potvrzení do evidence.

Protokol dává obsluze přehled

Chyby, časy pokusů a odpovědi externí služby mají být dohledatelné v protokolu komunikace. Obsluha díky tomu pozná, co bylo úspěšně dokončeno, co stále čeká a proč další pokus zatím neproběhl.

Přehled je důležitý také při delší odstávce nebo při řešení opakované chyby s provozovatelem externí služby. Místo odhadu je k dispozici historie komunikace a konkrétní odpovědi, podle kterých lze rozhodnout o dalším postupu.

Způsob automatizace, kontroly a řešení chybových stavů se vždy přizpůsobuje skutečnému provozu. Více o možnostech propojení MAXimu s e-shopy, dopravci, dodavateli a dalšími systémy najdete na stránce integrace MJSoft.

Přínosem je řízené zotavení, ne slib provozu bez výpadků

Výpadkům internetu ani cizích služeb nelze úplně zabránit. Lze ale připravit integraci tak, aby při problému neztratila přehled o rozpracovaných datech a po obnovení spojení bezpečně navázala.

  • nedokončené přenosy zůstanou dohledatelné,
  • úspěšné záznamy se zbytečně neposílají znovu,
  • jednoznačné identifikátory pomáhají chránit před duplicitami,
  • opakování probíhá automaticky nebo řízeně podle typu chyby,
  • obsluha vidí výsledek každého přenosu i důvod čekání.

Řešíte propojení ERP s e-shopem, dopravcem nebo jinou externí službou? Nezávazně s námi proberte, jak nastavit spolehlivý a kontrolovatelný přenos dat.