Většina firemní logiky se pohodlně vejde do vizuálního tvůrce automatizací, a pokud se tam vejde, má tam i zůstat. Vizuální automatizace se snáz čtou na první pohled, bezpečněji je upraví i někdo, kdo je původně nepsal, hůř se v nich něco omylem rozbije a jasně ukazují i netechnickým lidem, co jejich systém vlastně dělá. Vizuální tvůrce zvládne naprostou většinu toho, co automatizace potřebují vyjádřit — spouštěče, podmínky, práci se záznamy, oznámení i napojení na známé služby — a to ve formě, která bez potíží přežije, i když projekt převezme někdo jiný.
Některá logika ale opravdu potřebuje programovací jazyk. Výpočet ceny závislý na sedmi provázaných proměnných s nepravidelnou prioritou. Transformace dat, která jeden tvar převádí na jiný přes nepříliš zřejmou řadu kroků. Napojení na externí API, jehož zvláštnosti obecná akce webhooku pohodlně nepokryje. Dávkové zpracování, které projde tisíce záznamů a na každém provede výpočet, jenž by se ve vizuální automatizaci skládal jen s velkou bolestí. Pro tyto případy — a jen pro ně — je správným nástrojem skript. A správné místo, kde ho napsat, je přímo v platformě, ne v nějakém odděleném systému, který se pak musí kostrbatě propojovat.
Skripty jsou plnohodnotnou součástí platformy. Skript má název, historii verzí, oprávnění podle rolí, auditní stopu i své místo v protokolu událostí. Žije v editoru v prohlížeči vedle dotazů, pohledů a automatizací; upravuje se ve stejném prostředí, které implementátoři už znají, a nasazuje se, aniž byste platformu opouštěli. Na tomhle propojení záleží: skripty, které žijí mimo platformu — na nějakém externím serveru, kterého se dotkne jen ten, kdo je nastavil, a na který se zapomene, jakmile dotyčný odejde — bývají zdrojem většiny technického dluhu implementace.
Typovaný přístup k datovému modelu je to, co dělá skripty skutečně produktivními. Skript nemusí sahat po REST API a ručně serializovat objekty — pracuje přímo s typy, vlastnostmi a záznamy a zná jejich schéma. Načtení záznamu vrátí typovaný objekt, jehož vlastnosti umí editor našeptávat. Zápis do vlastnosti se ověří proti schématu. Vazby mezi objekty procházíte bez ručně skládaných spojení. Právě tahle ergonomie brání tomu, aby se z psaní skriptů stalo otravné skládání textových řetězců; práce s daty ve skriptu se podobá práci v jakémkoli dobře navrženém programovacím prostředí.
HTTP klient je vestavěný, včetně opakování požadavků, časových limitů a ošetření chyb, které každé skutečné napojení potřebuje. Skripty mohou volat externí API, aniž by sahaly po knihovně třetí strany, nastavovaly zvláštní vrstvu pro přístup k síti nebo se bály, že je dočasný výpadek celé shodí. O nudnou mašinérii spolehlivosti se stará HTTP vrstva, takže se skript může soustředit na svou vlastní logiku.
Přístup k citlivým údajům propojuje skriptovací prostředí se správou hesel a klíčů v platformě. Skript, který potřebuje API klíč, se na něj odkáže jménem a funkce citlivých údajů odkaz vyhodnotí až za běhu. Hodnota přihlašovacího údaje se nikdy neobjeví ve zdrojovém kódu skriptu, neskončí v historii verzí ani se neukáže při revizích kódu. U každého skriptu, který se dotýká externích služeb — a to je většina z nich — právě tohle brání tomu, aby se z přihlašovacích údajů stalo nejslabší místo.
Odesílání e-mailů ze skriptů probíhá přes e-mailový engine nastavený pro dané prostředí, se stejnou mašinérií i šablonami, jaké používá zbytek platformy. Skript, který potřebuje poslat vlastní oznámení, nemusí doručování e-mailů řešit znovu; zavolá e-mailovou funkci platformy s příjemcem, předmětem, tělem a případnými proměnnými šablony a o zbytek se postará e-mailový engine. Zpráva odejde z odesílací adresy daného prostředí, v jeho vizuálním stylu, a zaznamená se do protokolu e-mailů stejně jako každý jiný odchozí e-mail.
Volání skriptů z automatizací je nejčastější způsob jejich zapojení. Automatizace, která potřebuje jeden neobvyklý krok — výpočet příliš složitý pro vizuálního tvůrce nebo napojení na svérázný externí systém — vloží do svého toku krok se skriptem. Automatizace předá skriptu vstupy, skript odvede svou práci a automatizace pokračuje dál s jeho výstupy. Tímhle mícháním vizuální a skriptované logiky zůstává každá část workflow ve formě, která jí nejlíp sedí, místo aby vás nutila jít buď jen vizuální, nebo jen kódovou cestou.
Skripty jako akce v rozhraní dají uživateli tlačítko, které skript spustí. Akce „vygeneruj tento report“ u záznamu spustí skript, který report sestaví a vrátí PDF. Akce „vyrovnej tento účet“ u finančního záznamu spustí skript, který provede několikakrokové vyrovnání. Skript se nabídne jako akce; uživatel vidí tlačítko; a za tím tlačítkem je náhodou skript, ne vizuální automatizace. Pro případy, kdy uživatelem vyvolaná složitá logika patří spíš do jednoho čistého spouštěče než do řetězce kroků automatizace, se hodí právě tento vzor.
Naplánované skripty běží podle plánu ve stylu cronu a řeší dávkové zpracování, které se nevejde do událostmi spouštěného tvaru automatizací. Noční souhrnný výpočet; týdenní úklid zastaralých záznamů; měsíční generování reportu, který se dotkne každého zákazníka v prostředí. Samotný plánovací aparát popisuje článek o plánovači; skripty se do něj zapojují jako jedna z věcí, které lze spustit podle plánu, se stejnými logy a oznámeními jako kterákoli jiná naplánovaná úloha.
Ošetření chyb a logování jsou tu na prvním místě. Skript, který vyhodí neošetřenou chybu, skončí v protokolu událostí jako strukturovaný záznam — který skript, s jakými vstupy, jaká chyba a na kterém řádku. Chyby při naplánovaných spuštěních vygenerují oznámení, místo aby tiše selhaly. Skripty, které chtějí zaznamenávat vlastní postup nebo hlásit dílčí selhání, mají k dispozici logovací rozhraní napojené na stejný přehled o provozu. Vzhledem k tomu, že skripty běží bez dozoru celé měsíce a občas narazí na situaci, se kterou jejich autor nepočítal, právě tahle přehlednost je udržuje spravovatelné.
Izolace a limity brání tomu, aby špatně napsaný skript ovlivnil zbytek platformy. Každý skript běží s limity na procesor, paměť a celkový čas běhu; skript, který kterýkoli z nich překročí, se ukončí s čistou chybou, místo aby stáhl celé prostředí dolů. Právě tohle ohraničení dělá ze skriptování bezpečný nástroj rozšiřitelnosti, a ne nabitou zbraň: kdo napíše nekonečnou smyčku, zadělá si jen na vlastní nepříjemnost, ale zbytek prostředí běží dál.
Kdy sáhnout po skriptu a kdy ne je rozhodnutí, na kterém záleží nejvíc. Začněte vizuálním tvůrcem automatizací; zůstaňte u něj, dokud se do něj logika pohodlně vejde; ke skriptu sáhněte, jen když je vizuální podoba opravdu horší. Většina implementací bude mít spoustu vizuálních automatizací a hrstku skriptů — a takový poměr je správný. K okolním tématům: článek o automatizacích popisuje vizuálního tvůrce, se kterým se skripty pojí, článek o editoru kódu popisuje psaní přímo v prohlížeči, článek o správě citlivých údajů se věnuje práci s přihlašovacími údaji a článek o protokolu událostí popisuje hlášení chyb. Skriptování na straně serveru je záložní cesta, kterou platforma záměrně nabízí — schopná zvládnout, co je potřeba, ošetřená tak, aby zůstala bezpečná, a přesto nikdy ne první nástroj, po kterém sáhnete. Právě tahle rovnováha dělá rozšiřitelnost udržitelnou.