Když se spojení na chvíli přeruší, automatizace může požadavek zopakovat. To zní jako správná oprava. Jenže co když první pokus ve skutečnosti proběhl a ztratila se pouze odpověď? U načtení seznamu si toho možná nikdo nevšimne. U objednávky, faktury nebo výdeje ze skladu už druhý úspěšný pokus není důvod k oslavě.
U aplikace, která předává schválenou objednávku do ERP, může nastat nenápadná komplikace. Uživatel klikne, chvíli čeká a nakonec dostane informaci, že se operaci nepodařilo potvrdit. Zkusí to znovu. Mezitím stejný krok opakuje i automatizace, která se snaží pomoci. V dobré víře tak mohou vzniknout dva požadavky na jednu skutečnou objednávku.
Podobné situace není potřeba řešit zákazem všech opakování. Dočasná nedostupnost služby není nic, kvůli čemu by měl člověk pokaždé přebírat práci ručně. Potřebujeme však rozlišit, co bezpečně zopakovat lze a co se při dalším pokusu nesmí provést podruhé. Právě na takových detailech stojí spolehlivost integrací.
Chybějící odpověď ještě neznamená chybějící výsledek
Dvě propojené aplikace nevidí vždy stejnou situaci. Příjemce mohl záznam uložit, zatímco odesílatel už čekání ukončil. Z jeho pohledu operace selhala. Z pohledu databáze je hotová. Opakovaný požadavek pak může vytvořit další záznam, pokud návrh s touto možností nepočítá.
Pomáhá jednoznačný identifikátor předání, který zůstává při opakování stejný. Samostatnou úlohou je kontrola obchodních duplicit. Faktura doručená z jiné adresy nebo s jiným názvem přílohy může být pořád stejným dokladem. Technické opakování a opakovaně zaslaný obchodní podklad proto potřebují související, ale ne totožná pravidla.
Kontrola má být blízko skutečnému zápisu
Pouhá otázka „už ten záznam existuje?“ nemusí stačit. Dva současné běhy mohou oba dostat odpověď, že neexistuje, a potom ho oba založit. Proto je důležité využít možnosti cílového systému, například unikátní klíče nebo podporu bezpečného opakování přímo v jeho rozhraní.
Když cílová aplikace takové možnosti nemá, integrace potřebuje jiný způsob řízeného předání a ověření výsledku. Někdy pomůže fronta, jindy následná kontrola podle dohodnutého identifikátoru. Neexistuje jedno univerzální zatržítko, které vyřeší všechny kombinace služeb.
Pro uživatele přitom nemá vzniknout záhada. Musí poznat rozdíl mezi odmítnutým požadavkem, zpracovávaným požadavkem a situací, u které se výsledek teprve ověřuje. Teprve potom může bezpečně rozhodnout, zda čekat, opravit podklady, nebo požádat podporu o pomoc.
Spolehlivost se testuje i při nepříjemném načasování
Při ověřování integrace má smysl poslat stejnou zprávu znovu, spustit dva požadavky současně a přerušit komunikaci po provedení zápisu. To nejsou samoúčelné zkoušky odolnosti. Jsou to způsoby, jak zjistit, co systém udělá v situacích, které běžné úspěšné demo vůbec neukáže.
Důležitá je i obsluha nejasných případů. Historie předání, odpovědi příjemce a návazné identifikátory umožní dohledat výsledek bez ručního procházení několika aplikací. Když automatizace potřebuje pomoc, měla by člověku předat informace, ne pouze obecnou červenou hlášku.
Pro firmu je výsledkem větší jistota, že technický problém nevytvoří nový obchodní problém. Automatické opakování pak skutečně šetří práci, místo aby přidávalo úklid duplicit. A právě to je měřítko, které nás v Evenaut zajímá: ne kolikrát tok úspěšně doběhl, ale zda správně dokončil práci, kvůli které vznikl.
Propojujete firemní aplikace a chcete mít přenosy pod kontrolou? Napište nám na customers@evenaut.com.
