Centro assistenza di Workiva

Applicando i limiti delle risorse in modo automatico e fornendo log dettagliati (come mostrato nelle schermate sottostanti), Workiva Scripting garantisce sia l'affidabilità della piattaforma che la trasparenza per gli sviluppatori che creano e ottimizzano gli script di automazione.

Terminazione quando un'esecuzione viene completata con successo

Quando uno script viene completato normalmente senza superare i limiti, il registro include un riepilogo dell'utilizzo delle risorse che mostra l'utilizzo medio e di picco di memoria, CPU, disco e tempo di esecuzione. Queste informazioni forniscono visibilità sulle caratteristiche delle prestazioni per le esecuzioni completate con successo.

Nota: Se uno script viene eseguito molto rapidamente (ad esempio, meno di 1 secondo), il campionamento delle risorse potrebbe non avvenire. In questi casi, il log non riporterà alcun dato sull'utilizzo delle risorse.

Lo script viene eseguito troppo velocemente per essere campionato

Se uno script termina troppo velocemente, il monitor non può acquisire i dati di utilizzo.

Lo script ha un'uscita normale

Se uno script viene completato senza superare alcun limite, le statistiche sull'utilizzo delle risorse vengono visualizzate integralmente nel registro.

Terminazione al superamento dei limiti

Se l'esecuzione di uno script supera i limiti configurati (ad esempio, la memoria, l'utilizzo del disco o il tempo allocato), lo Scripting:

1. Tentativo di fermare lo script in modo sicuro: quando i limiti vengono superati, Scripting invia prima un segnale di terminazione (SIGTERM) per consentire allo script di ripulirsi e uscire entro 15 secondi.
2. Se lo script non esce entro 15 secondi, il programma di scripting invia un segnale SIGKILL che interrompe immediatamente il processo senza consentire alcuna pulizia. Si tratta di una terminazione forzata e l'esecuzione verrà completata con uno stato di fallimento (visualizzato in rosso nel registro). Questo stato indica un errore del sistema di scripting.
3. Registra il motivo dell'interruzione: il registro mostrerà quale limite è stato raggiunto e riassumerà l'utilizzo delle risorse dello script.

Le sezioni successive forniscono esempi di ciò che accade quando uno script supera i limiti senza codice per gestire questi segnali. Per imparare a modificare i tuoi script in modo che rispondano con grazia a questi segnali, consulta Handling system signals in scripts.

Limite di memoria superato

Quando uno script supera il limite di memoria configurato, il registro include il motivo dell'interruzione e i dettagli sulla soglia superata.

Limite di utilizzo del disco superato

Quando uno script supera il limite di utilizzo del disco configurato, il registro include il motivo dell'interruzione e i dettagli sull'utilizzo del disco al momento del raggiungimento del limite.

Tempo allocato superato

Quando uno script supera il tempo configurato per la sua esecuzione, il registro include il motivo dell'interruzione e il tempo totale di esecuzione registrato.

Terminazione quando l'utente annulla un'esecuzione

Se un utente annulla manualmente un'esecuzione, lo Scripting invia un segnale di interruzione (SIGINT) per informare lo script che deve fermarsi. Lo script ha 15 secondi per ripulire, salvare i progressi o tornare indietro prima dell'arresto. Dopo questo periodo di tolleranza di 15 secondi, si verifica la stessa sequenza descritta sopra: viene inviato un segnale di terminazione (SIGTERM) per consentire allo script di completare la pulizia per altri 15 secondi, seguito da un segnale finale di uccisione (SIGKILL) se lo script non è ancora uscito.

L'immagine seguente mostra come vengono visualizzati i log dello script quando lo script non include il codice per gestire il segnale di interrupt.

Per imparare a modificare i tuoi script in modo che rispondano in modo adeguato a questi segnali, consulta Gestire i segnali di sistema negli script.

Terminazioni non pianificate

In casi rari, come quando uno script consuma la memoria più velocemente di quanto il sistema di Scripting possa monitorare il consumo, il sistema potrebbe terminare uno script prima di rilevare il superamento di un limite. Quando ciò accade, lo scripting registra un rapporto di utilizzo incompleto, mostrando solo i dati raccolti prima dell'interruzione.

Gestione dei segnali di sistema negli script

La gestione dei segnali permette al tuo script di chiudersi in modo pulito quando viene annullato o fermato dal sistema. Catturando e rispondendo ai segnali di sistema, il tuo script può rilasciare le risorse, salvare il lavoro e uscire con grazia (ad esempio, quando lo stato viene segnalato come "completo") invece di essere terminato con forza.

Quando uno script viene interrotto perché un utente lo cancella o perché supera i limiti della piattaforma, lo Scripting emette segnali di interruzione, terminazione e uccisione. Consulta le sezioni precedenti per saperne di più su come vengono attivati i segnali di interruzione, terminazione e uccisione.

Segnali di scripting e come gestirli

Questa sezione fornisce blocchi di codice e un esempio completo che puoi utilizzare per gestire questi segnali.

Puoi mantenere i gestori dei segnali piccoli e gestire la pulizia in un unico punto utilizzando un blocco try/finally che viene eseguito sempre allo spegnimento. Questo rende gli script prevedibili e facili da mantenere.

La struttura generale per la gestione dei segnali nel tuo script è la stessa indipendentemente dal segnale ricevuto:

• Inizio del file: importare i moduli e definire il gestore
• Inizializzazione anticipata: registra il gestore prima di fare qualsiasi operazione
• Intorno al tuo lavoro: avvolgi il codice principale in un blocco try/finally in modo che la pulizia venga sempre eseguita

L'utente annulla l'esecuzione (SIGINT)

Questo accade quando un utente clicca su Cancel per annullare l'esecuzione dello script.

# --- Inizio del file --- import signal, sys # Piccolo gestore: richiesta di uscita immediata e aggraziata def _graceful_exit(signum, frame): print("SIGINT ricevuto: richiesta cancellazione. Pulizia...") raise SystemExit(0) # --- Inizializzazione anticipata --- signal.signal(signal.SIGINT, _graceful_exit)

Intorno al tuo lavoro (più avanti nel file):

prova: # il tuo lavoro di lunga durata viene svolto qui... finally: # luogo centrale per la chiusura dei file, il lavaggio dei registri, ecc. print("Pulizia finale prima dell'uscita")

L'immagine seguente mostra come vengono visualizzati i log dello script quando viene gestito il segnale di interrupt (SIGINT).

Gestione diretta di KeyboardInterrupt

Workiva Scripting solleva anche KeyboardInterrupt quando SIGINT viene consegnato al thread principale. Puoi catturare questa eccezione nel blocco try e chiamare lo stesso percorso di pulizia definito da _graceful_exit().

try: # il tuo lavoro di lunga durata qui ... tranne KeyboardInterrupt: print("KeyboardInterrupt ricevuto: pulizia prima dell'uscita...") _graceful_exit(None, None) finally: # luogo centrale per la chiusura dei file, il lavaggio dei log, ecc. print("Pulizia finale prima dell'uscita")

L'immagine seguente mostra come vengono visualizzati i log dello script quando il segnale di interruzione viene gestito tramite interrupt da tastiera.

Segnale di terminazione dello scripting per fermarsi dopo un periodo di grazia (SIGTERM)

Lo scripting chiede al tuo script di fermarsi (ad esempio, dopo il superamento dei limiti). Il tuo script ha un breve periodo di grazia per uscire.

# --- Inizio del file --- def _graceful_term(signum, frame): print("SIGTERM ricevuto: la piattaforma ha richiesto la terminazione. Finishing up...") raise SystemExit(0) # --- Inizializzazione anticipata --- signal.signal(signal.SIGTERM, _graceful_term)

L'immagine seguente mostra come vengono visualizzati i log dello script quando viene gestito il segnale di terminazione (SIGTERM).

Segnale di kill dello scripting per fermarsi immediatamente (SIGKILL)

Se il tuo script non esce durante il periodo di tolleranza, lo Scripting invierà SIGKILL. Non puoi catturare SIGKILL. Esci tempestivamente da SIGINT/SIGTERM in modo che il tuo blocco finally possa essere eseguito prima che si verifichi un'uccisione.

Le schermate delle sezioni precedenti mostrano l'aspetto dei registri in seguito al segnale di uccisione.

Esempio completo (pronto per il copia-incolla)

Questo modello registra gestori minimi e centralizza la pulizia in infine. Incolla in Workiva Scripting e sostituisci l'area contrassegnata con la tua logica.

Dove aggiungere il tuo codice: Sostituisci il ciclo di esempio sotto # ===== YOUR CODE STARTS HERE ===== con i tuoi task effettivi. Evita chiamate ininterrotte molto lunghe in modo che lo script possa raggiungere il blocco finally prima che la piattaforma passi a SIGKILL.

"""Modello di scripting Workiva: gestori minimi + pulizia in finally - Gestori minuscoli che sollevano SystemExit(0) su SIGINT/SIGTERM - Un singolo blocco finally viene eseguito per la pulizia indipendentemente da come si interrompe lo script - Mantiene il codice piccolo e prevedibile """ import signal import time # --- Gestori di segnali (mantenere minuscoli) --- def _graceful_exit(signum, frame): print("SIGINT ricevuto: richiesta cancellazione. Pulizia...") raise SystemExit(0) def _graceful_term(signum, frame): print("SIGTERM ricevuto: la piattaforma ha richiesto la terminazione. Finishing up...") raise SystemExit(0) # --- Registra i gestori PRIMA di fare qualsiasi lavoro pesante --- signal.signal(signal.SIGINT, _graceful_exit) signal.signal(signal.SIGTERM, _graceful_term) # --- Il lavoro principale del tuo script --- def main(): print("Avvio del lavoro...") # ===== IL TUO CODICE INIZIA QUI ===== # Esempio di ciclo a lunga durata. Sostituisci con la tua logica attuale. for i in range(1, 1_000_000): # Simula un'unità di lavoro (sostituisci con la logica reale) print(f "Lavorando sull'elemento {i}...") time.sleep(1) # ===== IL TUO CODICE FINISCE QUI ===== if __name__ == "__main__": try: main() finally: # Pulizia centralizzata che viene sempre eseguita (anche su SIGINT/SIGTERM) print("Pulizia finale prima dell'uscita")