Každá firemní aplikace potřebuje vlastní logiku. Když se zaplatí faktura, vystav doklad a pošli ho zákazníkovi e-mailem. Když je úkol víc než týden po termínu, upozorni jeho řešitele i jeho nadřízeného. Každou noc ve 2:00 archivuj uzavřené tikety starší než devadesát dní. Když někdo odešle formulář na veřejném webu, založ poptávku, přiřaď ji obchodníkovi podle regionu a pošli potvrzovací e-mail. Právě taková pravidla dělají z obecného softwaru vaši aplikaci. Na většině platforem je to přesně místo, kde končí implementátor a nastupuje vývojář. Automatizace tuto hranici posouvají dál – tak daleko, že ji řada prostředí nikdy nemusí překročit.
Automatizace má tři části. Spouštěč určuje, kdy se spustí. Volitelné vstupní parametry (u automatizací, které přijímají vstup od uživatele) určují, s jakým kontextem běží. A posloupnost akcí rozhoduje o tom, co se stane. Sestavování je vizuální – automatizaci poskládáte z nabídek a zapsaných výrazů – ale výsledkem je skutečná, doložitelná logika, která se pokaždé, když spouštěč zareaguje, chová předvídatelně.
Spouštěče pokrývají události, na kterých ve firemní aplikaci opravdu záleží. Vytvoření, úprava nebo smazání záznamu u libovolného typu. Změna konkrétního pole, kdy má logika k dispozici starou i novou hodnotu. Naplánované spuštění v libovolném rytmu přes plánovač. Akce vyvolaná uživatelem, když někdo klikne na tlačítko v rozhraní. Příchozí webhook, když platformu upozorní externí systém. Odeslání formuláře v Canvasu, když někdo vyplní vlastní formulář. Událost z API, když integrace vyvolá něco konkrétního. Ke každému spouštěči patří odpovídající kontext – spouštěč „při úpravě záznamu“ zná starou i novou hodnotu každého změněného pole, „příchozí webhook“ zná hlavičky a tělo požadavku a „naplánované spuštění“ nese naplánovaný čas. Automatizace si o tento kontext nemusí říkat; prostě ho má k dispozici.
Drobnost, která má velký význam: spouštěče mohou ignorovat systémové zásahy. Předejde se tím nepříjemnému zacyklení, kdy by změny provedené samotnou automatizací spustily tutéž automatizaci znovu. Systémem vyvolané úpravy – migrace, hromadné importy nebo změny od jiných automatizací označených jako systémové – projdou, aniž by spouštěč znovu zareagoval. Změny vyvolané uživatelem spouštějí automatizaci normálně. Díky tomuto rozlišení se z dlouhých řetězců automatizací nestanou nekontrolovatelné procesy.
Teprve akce dělají z automatizace opravdu schopný nástroj. Knihovna je rozsáhlá a stále se rozrůstá: vytvoření, úprava, smazání a duplikace záznamů; úprava podle reference pomocí externího identifikátoru; převod objektu z jednoho typu na jiný (z poptávky na zákazníka); načtení objektů z dotazu a procházení jejich seznamu – včetně procházení streamované odpovědi JSON z externího zdroje, které zvládne i velké objemy dat bez načtení celku do paměti. Větvení řešíte přehledně přes if/else, cykly přes while a průběh řídíte akcemi continue, abort a terminate – řízení běhu tak vypadá stejně jako v jakémkoli strukturovaném programu.
Komunikační akce pokrývají kanály, které platforma podporuje: odeslání e-mailu (se šablonami, přílohami, kopií i skrytou kopií a adresou pro odpověď), odeslání SMS, odeslání webhooku (s volitelnou metodou, hlavičkami a tělem), odeslání odpovědi JSON, když byla automatizace volaná z API, oznámení v aplikaci, push oznámení pro mobilní zařízení a systémové oznámení pro upozornění administrátorům. Každá z nich je v tvůrci jedinou akcí a všechny čerpají ze stejného jazyka výrazů, takže personalizaci vyřešíte přímo na místě.
Datové akce sahají napříč celou platformou: načtení externích dat ze souboru CSV, z koncového bodu JSON nebo z rejstříku firem (ARES); vytvoření PDF ze stránky v Canvasu; uložení souboru do úložiště; publikování události server-sent event, která klientům posílá živé aktualizace v reálném čase. Pro automatizace běžící v kontextu uživatelského rozhraní – tedy když uživatel klikl na tlačítko – umí přesměrování poslat prohlížeč na jinou stránku a krátká zpráva (flash) zobrazit potvrzení. Pro administrativní scénáře umí přihlášení jako jiný uživatel spustit zbytek automatizace pod jinou identitou (s úplným záznamem v protokolu) – tak dokážou delegované postupy zapsat správné položky do protokolu aktivit.
Vlastní skripty řeší případy, na které vestavěné akce nestačí. Malý skript v izolovaném prostředí (sandboxu) – napsaný ve skriptovacím jazyce na straně serveru nebo ve vestavěném jazyce na straně klienta – umí provést libovolnou logiku a přitom má přístup ke kontextu automatizace. Je to úniková cesta pro chvíle, kdy si s hotovými akcemi nevystačíte, a dali jsme si záležet, aby byla opravdu bezpečná (izolovaná, časově i zdrojově omezená), ne aby z ní byla zadní vrátka. Psaní skriptů popisuje článek o editoru kódu; z pohledu automatizace je skript prostě další akce, kterou do postupu vložíte.
Vstupní parametry mění automatizace v nástroje ovládané uživatelem. Parametry mají svůj datový typ, při ručním spuštění se mohou zobrazit jako formulář a mohou se navzájem podmíněně zobrazovat – „parametr důvod zrušení ukaž jen tehdy, když uživatel zvolil akci Zrušit.“ Stejné rozhraní parametrů pohání i tlačítka v aplikaci, která automatizaci spustí na jedno kliknutí s krátkým potvrzovacím formulářem – tak vzniká řada vlastních akcí u záznamu.
SUDO je drobnost, která řeší problém se zvýšeným oprávněním. Většinou má automatizace běžet s oprávněními uživatele, který ji spustil – a je to tak správně, protože to brání tomu, aby se z automatizací staly nástroje na obcházení oprávnění. Občas ale automatizace opravdu potřebuje udělat něco, na co spouštějící uživatel právo nemá – zapsat do chráněného typu, sáhnout na systémové pole, provést citlivou akci. Označením jednotlivé akce nebo celé automatizace jako SUDO toto oprávnění dočasně udělíte a zaznamená se do protokolu, takže je při auditu jasně vidět, kdy a proč automatizace vykročila mimo běžná práva uživatele.
Teprve správa a dohled dělají z automatizací spolehlivou provozní součást. Automatizace lze omezit na role, takže je smějí vytvářet nebo měnit jen některé z nich. Sledování změn zaznamenává každou úpravu definice automatizace včetně rozdílů, takže je historie procesu vidět. Zkušební běhy umožňují automatizaci vyzkoušet na vzorových datech bez vedlejších účinků, což se hodí, když automatizace zapisuje do ostrého systému. Provozní protokoly zachycují každé spuštění – s jakým kontextem běželo, jaké akce provedlo a na jaké chyby narazilo – takže ladění problému začíná u skutečných dat, ne u dohadů.
A právě u toho posledního bodu stojí za to se zastavit. Na mnoha platformách je automatizace až dodatečný nápad – jednoduchý strojek na pravidla přišroubovaný k datovému modelu. Protože ta naše byla od začátku navržená jako vrstva pro procesy, připomíná ladění automatizací ladění kódu: záznam toho, co se stalo, průběh hodnot v jednotlivých krocích a jasné označení místa, kde se něco pokazilo. Právě díky tomu dokážou i lidé bez programátorské průpravy stavět automatizace, které obstojí i v ostrém provozu.
Na tento článek přirozeně navazují texty o plánovači, formulářích v Canvasu, webhoocích, skriptování na straně serveru a o AI v automatizacích. Automatizace jsou pojivem mezi datovým modelem a firemními procesy – a víc než která jiná funkce určují, jak daleko se prostředí dostane, aniž by u toho musel být vývojář.