Skip to main content
Le automazioni sono le parti di un’app che funzionano autonomamente — secondo una pianificazione, o quando un servizio esterno invia un evento. Le dichiari su un componente process in kazzle.config.ts. Un componente può avere tutti i trigger di cui hai bisogno.

La struttura

Due cose stanno accadendo qui:
  • processMode sceglie il ciclo di vita — server long-running, o esecuzione una tantum per trigger.
  • triggers[] elenca gli eventi che devono attivare questo componente.
I due elementi sono indipendenti. Un server persistente può avere un cron. Un processo effimero può avere un webhook. Scegli il ciclo di vita che si adatta al carico di lavoro, poi allega tutti i trigger che vuoi.

processMode

Trigger

Ogni trigger ha un name (univoco all’interno del componente), un kind, e — a seconda della modalità — uno schedule e/o un path.

Modalità persistente — HTTP nel server

Quando un trigger si attiva per un componente persistente, Kazzle POSTa al tuo server al path dichiarato. La richiesta contiene: Per i trigger webhook, il corpo della richiesta originale viene inoltrato come corpo POST. Per i trigger di pianificazione il corpo è vuoto.

Modalità triggered — una tantum per trigger

Quando un trigger si attiva per un componente triggered, Kazzle genera lo script di entry da zero e attende che esca. Non c’è path; lo script apprende quale trigger si è attivato dalle variabili d’ambiente.
I componenti triggered non hanno macchine inattive in produzione — si avviano per chiamata e si spengono all’uscita.

URL dei webhook

Il segmento triggerName deve corrispondere a una voce kind: 'webhook' in triggers[] di quel componente. I nomi di trigger sconosciuti restituiscono 404.

Risoluzione della pianificazione

Le espressioni cron sono a 5 campi (minuto, ora, giorno del mese, mese, giorno della settimana) e la risoluzione al minuto è il minimo. Le pianificazioni sub-minuto vengono rifiutate al momento della convalida del manifest.

Come vengono registrate le esecuzioni

Ogni attivazione di trigger scrive una riga process_runs con trigger_name, triggered_by, run_id, e lo stato di uscita dell’esecuzione. Puoi interrogarle dal tuo codice o ispezionarle nella vista esecuzioni dell’app.

Esaurimento dei crediti

Un’esecuzione non riuscita viene registrata e registrata, ma la pianificazione continua al suo ritmo normale — un’esecuzione instabile non disabilita mai il trigger. L’unica cosa che ferma un’esecuzione è il credito: ogni attivazione di trigger viene controllata rispetto al saldo dello spazio, e mentre lo spazio è senza crediti (o non ha alcuna fatturazione configurata) le esecuzioni vengono saltate con un 402. Questo è auto-recuperabile — la pianificazione rimane armata e l’attivazione successiva dopo il rifornimento viene eseguita normalmente, senza ripresa manuale.

Aggiunta di automazioni in seguito

Un’app semplice può iniziare senza trigger e acquisirli in seguito — aggiungi un riepilogo giornaliero, connetti Stripe, esegui la pulizia. Il ciclo di vita del componente (processMode) e i trigger (triggers[]) sono indipendenti, quindi puoi modificarli senza riscrivere il resto dell’app.