Představte si jednoduché propojení dvou aplikací. Zákazník odešle formulář a automatizace z něj založí objednávku. Jenže potvrzení o uložení se cestou ztratí. Na obrazovce svítí chyba a kolega chce kliknout na „Spustit znovu“. Pomůže tím, nebo založí stejnou objednávku podruhé?

V tomto modelovém příkladu objednávka už existuje. Automatizace o tom ale neví, protože nedostala odpověď. To je jiná situace, než když cílová aplikace požadavek výslovně odmítne třeba kvůli chybějící adrese. Při odmítnutí víte, co opravit. Při ztracené odpovědi nejdřív potřebujete zjistit, co se skutečně stalo.

Opakování po výpadku je běžná součást provozu propojených aplikací. Amazon Builders’ Library popisuje právě tento problém: první pokus může uspět, i když odesílatel nedostane potvrzení. Další pokus pak může vytvořit druhý záznam.

Při zadávání automatizace proto nestačí ověřit, že objednávka jednou projde. Potřebujete také vědět, co se stane, když stejný požadavek přijde znovu. Ať už ho zopakuje člověk, nebo aplikace sama.

Jak poznat, že jde pořád o stejnou objednávku

Nejdřív si ujasněte, co má systém považovat za opakování. Jedno odeslání formuláře má vytvořit jednu objednávku. Technický pokus o opětovné doručení má dokončit původní práci. Když si zákazník vědomě objedná znovu, má vzniknout další objednávka, i kdyby měla úplně stejný obsah.

Samotná shoda jména, zboží a částky tedy nestačí. Každé nové objednání potřebuje vlastní identifikátor, například pozadavek-1048. Ten vznikne před prvním odesláním a zachová se při každém dalším pokusu. Nové číslo při restartu by cílové aplikaci říkalo, že má provést novou práci.

Identifikátor musí být jednoznačný i mezi různými zdroji či účty a rozlišovat jednotlivé akce. Založení objednávky je jiná akce než její zrušení. A dvě různá oznámení o téže objednávce nesmějí každé spustit její založení. Dodavatel by měl vysvětlit, podle čeho tyto situace rozpozná.

Pokud pod stejným identifikátorem dorazí jiné údaje, jde o rozpor, který se musí vyřešit. Systém nemá bez vysvětlení přepsat původní objednávku ani založit druhou. Oprava údajů potřebuje vlastní domluvený postup.

Samotné číslo ještě nestačí

Příjemce musí identifikátor také používat. Schopnosti zopakovat stejnou operaci bez dalšího účinku se říká idempotence. V našem příkladu to znamená, že další pokus nevytvoří druhou objednávku. Není to automatická vlastnost každého propojení.

Pozor na odpověď „před založením se podíváme, jestli už objednávka existuje“. Dva běhy mohou proběhnout současně, oba najít prázdný výsledek a oba objednávku založit. Microsoft proto doporučuje vynutit jedinečnost přímo při zápisu. Ve vlastní databázi lze objednávku a záznam o jejím zpracování uložit společně, aby výpadek mezi těmito kroky nezanechal nejasný výsledek.

U cizí služby musí dodavatel ověřit, jakou ochranu její rozhraní nabízí. Pokud bezpečné opakování nepodporuje, potřebujete spolehlivě dohledat původní výsledek. Ani nenalezený záznam nemusí hned dokazovat neúspěch: první pokus může ještě dobíhat. Dokud nelze výsledek určit, je namístě ruční ověření, ne další založení naslepo.

Dobrá otázka při předání proto zní:

Když automatizace spadne těsně po založení objednávky, jak po restartu pozná, že už ji založila?

Co má automatizace udělat při chybě

Pro různé výsledky potřebujete různé postupy. Do zadání můžete použít tato čtyři pravidla:

Stejné rozlišení mezi dočasnou poruchou a chybou, kterou další pokus nevyřeší, používá doporučení Microsoftu pro opakování požadavků. Prodlevy a počet pokusů se volí podle provozu a konkrétní služby. Příliš časté opakování může přetížené aplikaci ještě přitížit.

Ověřte i to, jak dlouho si systém provedené operace pamatuje. Pokud po dni záznam o zpracování smaže, nemůžete bez další kontroly bezpečně opakovat stejný požadavek za týden. Domluvená ochrana musí pokrýt i pozdější ruční zásahy.

Nechte si předvést i nepovedený průběh

Vedle běžného průchodu vyzkoušejte s dodavatelem těchto šest situací. V testovacím prostředí použijte smyšlené objednávky a sledujte, co opravdu vzniklo v cílové aplikaci:

  1. Stejný požadavek přijde dvakrát. Výsledkem je jedna objednávka.
  2. Dva stejné požadavky dorazí současně. Ani souběh nesmí vytvořit druhou.
  3. Objednávka se uloží, ale potvrzení se ztratí. Systém dohledá původní výsledek nebo viditelně předá případ k ověření.
  4. Automatizace se uprostřed restartuje. Pozná dokončené kroky a označí ty, u kterých výsledek nezná.
  5. Pod stejným identifikátorem přijdou jiné údaje. Upozorní na rozpor, místo aby tiše změnila výsledek.
  6. Někdo obnoví odložený případ po delší době. Před dalším pokusem se ověří, co už vzniklo a zda ochrana ještě platí.

Pak zadejte také dvě úmyslně nové objednávky se stejným obsahem. Obě musí projít. Ochrana, která blokuje i oprávněné objednávky, řeší jeden problém a vytváří druhý.

Z každé zkoušky si nechte stručný záznam: co se poslalo, pod jakým testovacím identifikátorem a co vzniklo. Po změně propojení tak můžete stejnou kontrolu zopakovat.

Když je potřeba člověk

Obsluha musí poznat, který případ čeká na ověření, co už je potvrzené a jaký další krok může udělat. Tlačítko „Spustit znovu“ samo o sobě nestačí. Musí být jasné, zda ověří původní výsledek, zopakuje stejný požadavek, nebo založí novou objednávku.

Určete také, kdo nevyřešené případy kontroluje a do kdy. Zastavená automatizace sice nevytvoří duplicitu, ale objednávka může zůstat ležet bez povšimnutí. Proto sledujte, kolik případů čeká a jak dlouho. Pro dohledání stačí identifikátor a odkaz do aplikace; není nutné kopírovat celý zákaznický formulář do chatu.

Zkontrolujte i to, co následuje po objednávce

Jedna objednávka může stále vyvolat dvě potvrzovací zprávy nebo dvě rezervace. Při zkouškách proto sledujte i navazující kroky. Ochrana před opakováním musí fungovat všude, kde by druhé provedení způsobilo problém.

Samostatně je potřeba řešit pořadí změn. Zpráva o vytvoření může dorazit až po zprávě o zrušení. Ochrana proti duplicitám sama nezabrání tomu, aby stará zpráva vrátila objednávku do nesprávného stavu. I na tuto situaci se při předání zeptejte.

Začněte jednou důležitou akcí. Ujasněte, jak se pozná opakování, kde ověříte výsledek a kdo převezme nejasný případ. Pak si nechte předvést, že domluvený postup funguje i při výpadku.

Pokud ještě nemáte jasné kroky a odpovědnosti, pomůže článek Neautomatizujte chaos. U automatizovaného zpracování exportů navazuje kontrola vstupních CSV. Co stavíme a propojujeme, najdete ve vybraných projektech Duha Works.