Come automatizzare le prenotazioni di un coworking senza inviare nulla due volte

Due tipi di trigger, e non sono intercambiabili

In un sistema di prenotazioni le regole si attivano per due ragioni strutturalmente diverse, e confonderle è all'origine di quasi tutti i bug di automazione.

Un trigger a evento scatta perché qualcosa è appena successo: una prenotazione è stata creata, modificata o annullata; un check-in o un check-out è stato completato; è stata emessa una fattura; è arrivato un pagamento. C'è un istante preciso, accade una volta sola, e la regola gira dentro quell'istante.

Un trigger programmato scatta perché una condizione è diventata vera col passare del tempo: una prenotazione sta per iniziare, una prenotazione è finita, una fattura è scaduta, un abbonamento sta per scadere. Non è "successo" niente: un job si è svegliato, ha guardato i dati e ha trovato dei candidati.

La differenza conta perché i trigger programmati vengono valutati ripetutamente. Una fattura scaduta oggi è scaduta anche domani. Se il valutatore gira ogni cinque minuti, "la fattura è scaduta" è vero 288 volte al giorno. Senza protezione, sono 288 email.

La chiave di idempotenza è tutto il progetto

La soluzione è dare a ogni potenziale esecuzione un'identità stabile, calcolata sulle cose che la rendono la stessa esecuzione: la regola, il tipo di trigger, l'entità specifica e la data a cui l'evento appartiene. Boris fa l'hash esattamente di questi quattro elementi in una chiave di deduplicazione e la registra quando l'azione viene eseguita.

Prima di eseguire, la regola controlla se quella chiave è già stata registrata. Se c'è, non succede nulla. Rieseguire il valutatore per la stessa regola, entità e data non duplica l'azione: il che significa che il job è sicuro se gira ogni cinque minuti, sicuro se parte due volte per sbaglio, e sicuro se deve recuperare dopo un'interruzione.

Nota cosa c'è dentro la chiave e cosa no. L'entità c'è, così due membri diversi ricevono ciascuno il proprio promemoria. La data dell'evento c'è, così un abbonamento in scadenza il mese prossimo e lo stesso abbonamento in scadenza l'anno prossimo sono esecuzioni distinte. L'ora corrente non c'è, ed è proprio questo a rendere innocua la valutazione ripetuta.

Le condizioni sono filtri, non trigger

Una regola utile è raramente "su ogni prenotazione". È "su ogni prenotazione nelle sale riunioni", o "su ogni fattura sopra i 200 euro". Sono condizioni valutate sul candidato dopo che il trigger lo ha già selezionato.

Tenere le condizioni separate dai trigger è ciò che impedisce all'elenco dei trigger di esplodere. Non serve un trigger booking.created.in_sala_riunioni: serve booking.created più una condizione sulla risorsa.

Le regole devono guidare i servizi, non riscriverli

La scorciatoia tentatrice è lasciare che l'azione di automazione faccia il lavoro da sé: scrivere la riga della fattura, chiamare l'API della porta. È la mossa sbagliata, e si manifesta più avanti come due comportamenti leggermente diversi per la stessa operazione: uno quando la fa una persona, uno quando la fa una regola.

In Boris un'azione di automazione chiama il servizio che già possiede quell'operazione. Emettere una fattura da una regola esegue lo stesso codice di fatturazione dell'emissione manuale. Il beneficio immediato è la coerenza; quello più prezioso è che il fallimento di una regola finisce nello stesso dossier di esecuzione di un fallimento nativo, così hai un posto solo da guardare invece di due.

Le regole da scrivere per prime

Le regole che si ripagano da sole in un coworking non sono affascinanti:

• La prenotazione sta per iniziare — le istruzioni di accesso, inviate prima dell'arrivo invece che dopo una telefonata.
• La prenotazione è finita — il compito di pulizia della sala, creato senza che nessuno debba ricordarsene.
• Fattura scaduta — il sollecito che nessuno ha piacere di mandare, che è esattamente il motivo per cui non viene mandato.
• Abbonamento in scadenza — la conversazione sul rinnovo, avviata quando c'è ancora tempo per farla.

Tre delle quattro sono trigger programmati, e non è un caso: il lavoro che davvero si dimentica in uno spazio è quello a cui non è attaccato nessun istante. Nessuno dimentica di reagire a una prenotazione nuova. Tutti dimenticano la fattura scaduta in silenzio tre settimane fa.

Prima di attivare una regola

• Sappi se il trigger è a evento o programmato, e aspettati che il programmato venga valutato di continuo.
• Assicurati che le esecuzioni siano identificate da regola, entità e data dell'evento, non da un timestamp.
• Metti la logica di restrizione nelle condizioni, non in nuovi tipi di trigger.
• Fai in modo che l'azione chiami il servizio reale, così il percorso automatico e quello manuale non possono divergere.
• Verifica che una regola fallita emerga in un posto che guardi davvero.