Portail de support Workiva

En appliquant automatiquement les limites de ressources et en fournissant des journaux détaillés (comme le montrent les captures d’écran ci-dessous), Workiva Scripting garantit à la fois la fiabilité de la plateforme et la transparence pour les développeurs qui élaborent et optimisent les scripts d’automatisation.

Fin de l’exécution lorsqu’elle est réussie

Lorsqu’un script se termine normalement sans dépasser les limites, le journal comprend un résumé de l’utilisation des ressources indiquant l’utilisation moyenne et maximale de la mémoire, du processeur, du disque et du temps d’exécution. Ces informations permettent de connaître les caractéristiques des performances pour les exécutions réussies.

Note : Si un script s’exécute très rapidement (par exemple, moins d’une seconde), il se peut que l’échantillonnage des ressources ne se produise pas. Dans ce cas, aucune donnée relative à l’utilisation des ressources ne sera consignée dans le journal.

Le script s’exécute trop rapidement pour être échantillonné

Si un script se termine trop rapidement, le moniteur ne peut pas capturer de données d’utilisation.

Le script se termine normalement

Si un script se termine sans dépasser aucune limite, les statistiques d’utilisation des ressources sont entièrement affichées dans le journal.

Fin en cas de dépassement des limites

Si l’exécution d’un script dépasse les limites configurées (par exemple, la mémoire, l’utilisation du disque ou le temps alloué), Scripting : tente d’arrêter le script en toute sécurité :

1. Tenter d’arrêter le script en toute sécurité - Lorsque les limites sont dépassées, Scripting envoie d’abord un signal de fin (SIGTERM) pour permettre au script de se nettoyer et de se terminer dans les 15 secondes.
2. Si le script ne se termine pas dans les 15 secondes, Scripting envoie un signal SIGKILL, qui arrête immédiatement le processus sans permettre aucun nettoyage. Il s’agit d’un arrêt forcé, et l’exécution se terminera avec un état d’échec (affiché en rouge dans le journal). Cet état indique une erreur du système de script.
3. Enregistrez la raison de l’arrêt - le journal indiquera la limite atteinte et résumera l’utilisation des ressources du script.

Les sections suivantes fournissent des exemples de ce qui se passe lorsqu’un script dépasse les limites sans code pour gérer ces signaux. Pour apprendre à modifier vos scripts afin qu’ils réagissent de manière élégante à ces signaux, consultez Handling system signals in scripts.

Limite de mémoire dépassée

Lorsqu’un script dépasse la limite de mémoire configurée, le journal inclut la raison de l’arrêt et des détails sur le seuil dépassé.

Limite d’utilisation du disque dépassée

Lorsqu’un script dépasse la limite d’utilisation du disque configurée, le journal inclut la raison de l’arrêt et des détails sur l’utilisation du disque au moment où la limite a été atteinte.

Dépassement du temps alloué

Lorsqu’un script dépasse la durée allouée configurée, le journal indique la raison de l’arrêt et la durée totale d’exécution enregistrée.

Arrêt lorsque l’utilisateur annule une exécution

Si un utilisateur annule manuellement une exécution, Scripting envoie d’abord un signal d’interruption (SIGINT) pour indiquer au script qu’il doit s’arrêter. Le script dispose de 15 secondes pour nettoyer, enregistrer la progression ou revenir en arrière avant de s’arrêter. Après cette période de grâce de 15 secondes, la même séquence décrite ci-dessus se déroule : un signal de fin (SIGTERM) est envoyé pour laisser 15 secondes supplémentaires au script pour terminer le nettoyage, suivi d’un signal final de mise à mort (SIGKILL) si le script n’est toujours pas terminé.

L’image ci-dessous montre comment les journaux de scripts apparaissent lorsque le script ne contient pas de code pour gérer le signal d’interruption.

Pour savoir comment modifier vos scripts afin qu’ils réagissent avec élégance à ces signaux, consultez Handling system signals in scripts.

Terminaisons non planifiées

Dans de rares cas, par exemple lorsqu’un script consomme de la mémoire plus rapidement que le système Scripting ne peut en contrôler la consommation, le système peut mettre fin à un script avant de détecter qu’une limite a été dépassée. Dans ce cas, Scripting enregistre un rapport d’utilisation incomplet, ne montrant que les données collectées avant l’arrêt du script.

Gestion des signaux système dans les scripts

La gestion des signaux permet à votre script de se fermer proprement lorsqu’il est annulé ou arrêté par le système. En capturant les signaux du système et en y répondant, votre script peut libérer des ressources, sauvegarder le travail et se terminer de manière élégante (par exemple, lorsque l’état est signalé comme « complet ») au lieu d’être interrompu de manière forcée.

Lorsqu’un script est arrêté parce qu’un utilisateur l’annule ou qu’il dépasse les limites de la plate-forme, Scripting émet des signaux d’interruption, de terminaison et de mise à mort. Consultez les sections précédentes pour en savoir plus sur le déclenchement des signaux d’interruption, de fin et de mise à mort.

Signaux de script et leur gestion

Cette section fournit des blocs de code et un exemple complet que vous pouvez utiliser pour gérer ces signaux.

Vous pouvez limiter la taille de vos gestionnaires de signaux et gérer le nettoyage en un seul endroit en utilisant un bloc try/finally qui s’exécute toujours à l’arrêt. Les scripts restent ainsi prévisibles et faciles à maintenir.

La structure générale de traitement des signaux dans votre script est la même, quel que soit le signal reçu :

• Début du fichier : importer des modules et définir le gestionnaire
• Initialisation précoce : enregistrez le gestionnaire avant d’effectuer tout travail.
• Autour de votre travail : insérer le code principal dans un bloc try/finally pour que le nettoyage s’exécute toujours.

L’utilisateur annule l’exécution (SIGINT)

Cela se produit lorsqu’un utilisateur clique sur Cancel pour annuler l’exécution du script.

# --- Haut du fichier --- import signal, sys # Tiny handler : request immediate, graceful exit def _graceful_exit(signum, frame) : print(« SIGINT reçu : annulation demandée. Cleaning up... ») raise SystemExit(0) # --- Initialisation précoce --- signal.signal(signal.SIGINT, _graceful_exit)

Autour de votre travail (plus loin dans le fichier) :

try : # votre travail de longue haleine ici ... finally : # endroit central pour fermer les fichiers, vider les journaux, etc. print(« Final cleanup before exit »)

L’image ci-dessous montre comment les journaux de script apparaissent lorsque le signal d’interruption (SIGINT) est géré.

Gestion directe de KeyboardInterrupt

Workiva Scripting soulève également KeyboardInterrupt lorsque SIGINT est transmis au thread principal. Vous pouvez attraper cette exception dans votre bloc try et appeler le même chemin de nettoyage défini par _graceful_exit().

try : # votre travail de longue haleine ici ... except KeyboardInterrupt : print(« KeyboardInterrupt received : cleaning up before exit... ») _graceful_exit(None, None) finally : # endroit central pour fermer les fichiers, vider les journaux, etc. print(« Final cleanup before exit »)

L’image ci-dessous montre comment les journaux de script apparaissent lorsque le signal d’interruption est géré par une interruption clavier.

Signal de fin de script pour arrêter après une période de grâce (SIGTERM)

Le script demande à votre script de s’arrêter (par exemple, après que les limites ont été dépassées). Votre script dispose d’un court délai de grâce pour quitter.

# --- Haut du fichier --- def _graceful_term(signum, frame) : print(« SIGTERM reçu : la plate-forme a demandé la fin. Finishing up... ») raise SystemExit(0) # --- Initialisation précoce --- signal.signal(signal.SIGTERM, _graceful_term)

L’image ci-dessous montre comment les journaux de scripts apparaissent lorsque le signal de fin (SIGTERM) est géré.

Signal de fin de script pour arrêter immédiatement (SIGKILL)

Si votre script ne se termine pas pendant la période de grâce, Scripting enverra SIGKILL. Vous ne pouvez pas attraper SIGKILL. Quittez rapidement SIGINT/SIGTERM pour que votre bloc finally puisse s’exécuter avant qu’un kill ne se produise.

Les captures d’écran des sections précédentes montrent à quoi ressembleraient les journaux à la suite du signal de mise à mort.

Exemple complet (prêt à être copié-collé)

Ce modèle enregistre des gestionnaires minimaux et centralise le nettoyage dans et enfin. Collez dans Workiva Scripting et remplacez la zone marquée par votre logique.

Où ajouter votre code : Remplacez la boucle d’exemple sous # ===== VOTRE CODE COMMENCE ICI ===== par vos tâches réelles. Evitez les très longs appels ininterrompus afin que le script puisse atteindre le bloc finally avant que la plateforme ne passe à SIGKILL.

"""Workiva Scripting template : minimal handlers + cleanup in finally - Tiny handlers raise SystemExit(0) on SIGINT/SIGTERM - Single finally block runs for cleanup regardless of how the script stops - Keeps code small and predictable « " » import signal import time # --- Signal handlers (keep tiny) --- def _graceful_exit(signum, frame) : print(« SIGINT received : cancellation requested. Cleaning up... ») raise SystemExit(0) def _graceful_term(signum, frame) : print(« SIGTERM reçu : la plate-forme a demandé la fin. Finishing up... ») raise SystemExit(0) # --- Register handlers BEFORE doing any heavy work --- signal.signal(signal.SIGINT, _graceful_exit) signal.signal(signal.SIGTERM, _graceful_term) # --- Your script’s main work --- def main() : print(« Starting work... ») # ===== YOUR CODE STARTS HERE ===== # Example long-running loop. Remplacez par votre logique réelle. for i in range(1, 1_000_000) : # Simulez une unité de travail (remplacez par la logique réelle) print(f « Working on item {i}... ») time.sleep(1) # ===== VOTRE CODE SE TERMINE ICI ===== if __name__ == « __main__ » : try : main() finally : # Nettoyage centralisé qui s’exécute toujours (y compris sur SIGINT/SIGTERM) print(« Final cleanup before exit »)