Přeskočit na hlavní obsah

Automatizace

Automatizace spouštějí instrukci podle plánu a výsledek doručí jako běžnou chatovou relaci. Denní přehled zpráv, týdenní kontrola nebo měsíční report běží bez uživatelského rozhraní na serveru, objeví se v seznamu chatů a lze je otevřít a pokračovat v nich jako v kterékoli jiné konverzaci.

Struktura​

Automatizace má název, volně psané instrukce, jeden či více spouštěčů, volitelný model (prázdná hodnota znamená Auto: výchozí chatový model v okamžiku běhu), cíl běhu a nastavení oznámení. Cíl určuje výstup: Chat session (výchozí) zařadí instrukci jako konverzaci, zatímco Work task spustí izolovaný sandbox Work s instrukcí jako první zprávou a volitelně s pojmenovanou zásadou Work. Při zapnutých oznámeních se neúspěšný běh objeví také v doručených oznámeních, takže se o selhání dozvíte i se zavřenou stránkou Automations. Nezávisle na tom vám zapnutí Automation results pod Settings → Notifications → Email notifications pošle e-mailem výsledek každého běhu, jakmile správce nastaví odchozí poštovní server (viz Oznámení). Názvy a instrukce jsou v úložišti šifrované. Každá automatizace patří svému tvůrci.

Spouštěče používají společný model kalendáře — once, hourly, daily, weekly, monthly, yearly — a jedna automatizace jich může mít nejvýše pět. Další běh je nejbližší budoucí výskyt napříč všemi spouštěči, vypočítaný v místním časovém pásmu serveru.

Spouštěče událostí​

Sedmý druh, event, nemá žádné hodiny: spustí se, jakmile dorazí jedno z vašich oznámení.

{ "kind": "event", "event": "channel-mention", "match": "release" }

event může být libovolný typ oznámení kromě automation-failed — rutina se nesmí umět restartovat z vlastní zprávy o selhání. Volitelné match je test poduřetězce v názvu oznámení nerozlišující velikost písmen; bez něj rutinu spustí každé oznámení daného typu.

Spouštěč události nikdy nepřispívá k času dalšího běhu. Automatizace, jejíž všechny spouštěče jsou události, proto nemá žádný další běh: seznam i dialog úprav místo toho říkají Runs when …. Kombinace spouštěče události s plánem je v pořádku — naplánované spouštěče stále řídí hodiny.

Dvě pojistky omezují dosah. Rutina se ze spouštěčů událostí spustí nejvýše jednou za minutu bez ohledu na to, jak rušný je proud, a vlastní oznámení o selhání běhu nikdy znovu nespustí rutinu, která je vytvořila.

Běh dostane to, co jej spustilo, připojené k instrukcím:

---
Trigger payload (JSON):
{"event":"channel-mention","title":"...","body":"...","href":"..."}

Provádění​

Plánovač tiká každou minutu pod koordinačním leasovacím zámkem, takže plány posouvá právě jedna replika. Když automatizace dozraje, tick zaznamená běh, zařadí trvalou úlohu automation.run.v1 a pomocí compare-and-set posune next_run_at, aby se každý výskyt spustil nejvýše jednou. Úloha vytvoří chatovou relaci s názvem automatizace a zařadí instrukci do stejné trvalé pipeline generování jako běžné konverzace, včetně směrování poskytovatele, výchozích hodnot persony a ukládání.

Pokud byl server při výskytu vypnutý, příští tick jej spustí jednou a starší zmeškané sloty přeskočí. Pozastavení plán smaže; obnovení nebo úprava jej přepočítá od aktuálního okamžiku. Smazání automatizace odstraní historii běhů pomocí foreign-key cascade.

Stav běhů se odvozuje z trvalého účetního záznamu úloh: úspěch po dokončení generování, chyba při dead-lettered úloze a stalled, pokud zařazený běh nezačne do 30 minut.

Běhy s cílem Work používají životní cyklus Work místo chatové úlohy. Běh zaznamená vytvořenou úlohu a odkazuje na ni, uspěje při dokončení agentem nebo zastavení kvůli vstupu a selže při chybě či zrušení. E-mail s výsledkem u běhu s cílem Work nese souhrn, který si sám běh Work uložil — stejný text, jaký ukazuje historie běhů úlohy — a u běhu, který předchází ukládaným souhrnům, se vrátí k jednořádkovému stavu úlohy. Přístup k Work se ověřuje při spuštění plánu; odvolaný přístup vede na work-access-denied. Vybraná zásada se ověří při uložení a její síťové a prostředkové limity platí pro všechny úlohy. Ve Work běží pouze přímí poskytovatelé modelů a model musí podporovat nástroje.

Rutiny agentů​

Automatizaci Work lze pomocí workTaskId svázat s existující úlohou Work; to je struktura za částí Routines na detailu agenta. Každý výskyt spustí běh v existujícím pracovním prostoru a konverzaci úlohy s jejím modelem, poskytovatelem a runtime zásadou; pole modelu a zásady automatizace se nepoužijí. Vazba se ověřuje při uložení. Smazaná úloha vede na work-task-missing; již běžící úloha nebo živý náhled na work-task-busy místo čekání ve frontě.

Spouštěče webhookem​

Kromě plánu může automatizaci spustit i vnější systém — CI pipeline, cronová služba, domácí automatizace. V dialogu úprav automatizace vygeneruje Webhook trigger → Enable tajemství pro danou automatizaci; ukládá se jen jeho SHA-256, takže se otevřený text zobrazí právě jednou. Rotace tajemství předchozí okamžitě zneplatní a vypnutí webhooku endpoint zase uzavře.

Vnější systém spustí automatizaci takto:

curl -X POST https://your-host/api/automations/<automationId>/webhook \
-H "Authorization: Bearer lwh_..."

(Jako alternativní hlavička funguje X-Libre-Webhook-Secret: lwh_....) Odpovědí je 202 s id zařazeného běhu — jde o stejnou cestu ručního spuštění jako u Run now, takže běhy se uzavírají, oznamují a objevují v historii úplně stejně. Porovnání tajemství probíhá v konstantním čase, chybějící automatizace a špatné tajemství odpovědí shodně (žádná věštírna id automatizací) a pozastavená automatizace odpoví 409: na rozdíl od vlastníkova Run now nemůže vnější volající spustit běh přes pauzu.

Objekt JSON v těle požadavku vjede do běhu jako jeho trigger payload, takže rutina vidí, na co reaguje:

curl -X POST https://your-host/api/automations/<automationId>/webhook \
-H "Authorization: Bearer lwh_..." \
-H "Content-Type: application/json" \
-d '{"commit":"abc123","branch":"main"}'

Payload se připojí k instrukcím, které běh provádí, pod nadpisem Trigger payload (JSON): — stejně pro chatové běhy, nové úlohy Work i úlohami vázané rutiny. Nesou se jen objekty JSON (pole a skaláry se ignorují) a payload, jehož serializovaná podoba přesáhne 4000 znaků, se zahodí místo zkrácení, s varováním v serverovém logu. Spuštění bez těla se chová přesně jako dřív.

API​

Všechny endpointy kromě spuštění webhookem vyžadují ověření a pracují pouze s automatizacemi volajícího; spuštění webhookem se místo toho ověřuje tajemstvím dané automatizace.

MetodaCestaÚčel
GET/api/automationsVypsat automatizace
POST/api/automationsVytvořit automatizaci
GET/api/automations/occurrences?from=&to=Vypočítané budoucí výskyty
GET/api/automations/runsHistorie běhů (lze filtrovat)
GET/api/automations/runs/summaryPočet neviděných + 30denní skupiny
POST/api/automations/runs/seenOznačit dokončené běhy jako viděné
GET/api/automations/:automationIdNačíst jednu automatizaci
PUT/api/automations/:automationIdAktualizovat automatizaci
DELETE/api/automations/:automationIdSmazat automatizaci
POST/api/automations/:automationId/pausePozastavit plán
POST/api/automations/:automationId/resumeObnovit plán
POST/api/automations/:automationId/runSpustit nyní (202 s id běhu)
POST/api/automations/:automationId/webhookSpustit tajemstvím (202)
POST/api/automations/:automationId/webhook-secretVytvořit/rotovat tajemství
DELETE/api/automations/:automationId/webhook-secretVypnout webhook

Uživatel může mít nejvýše 50 automatizací. Název má limit 200 znaků a instrukce 20 000.