Workiva Scripting überwacht automatisch die von jedem Skriptlauf verwendeten Ressourcen, einschließlich Arbeitsspeicher, CPU, Festplattennutzung und Laufzeit. Wenn ein Skript seine konfigurierten Ressourcengrenzen überschreitet, versucht Scripting, es sicher zu stoppen und gleichzeitig die Plattformstabilität aufrechtzuerhalten. Außerdem gibt das System den Skripten Zeit, sich zu bereinigen und zu beenden, bevor sie vollständig gestoppt werden, so dass es für die Benutzer nur zu minimalen Unterbrechungen kommt.
Dieser Artikel erklärt, wie Scripting mit Beendigungsszenarien umgeht, welche Details in den Protokollen erscheinen, und enthält Referenz-Screenshots.
Einzelheiten zu allen Systemlimits finden Sie unter Workiva Scripting Limits.
Szenarien
| Szenario | Verhalten | Log Details |
| Sehr kurzer Lauf | Erfolgreicher Lauf | Keine Daten zur Ressourcennutzung aufgezeichnet |
| Normale Beendigung | Erfolgreicher Lauf | Vollständige Zusammenfassung der Ressourcennutzung protokolliert (es sei denn, sie ist zu kurz für eine Stichprobe) |
| Überschreitung des Speicherlimits | Ordnungsgemäße Beendigung | Zeigt das Überschreiten der Speicherschwelle an und zeigt die durchschnittliche und maximale Nutzung an |
| Überschreitung des Festplattenlimits | Ordnungsgemäße Beendigung | Zeigt das Überschreiten des Festplattenschwellenwerts an und zeigt die durchschnittliche und maximale Nutzung an. |
| Überschreitung der zugewiesenen Zeit | Ordnungsgemäße Beendigung | Zeigt Laufzeitüberschreitung und verbrauchte Gesamtzeit an |
| Manueller Abbruch | Gnadenlose Beendigung | Vollständige Ressourcenfreigabe, Ressourcenzusammenfassung protokolliert |
| Unerwartete Beendigung | Unerwünschte Beendigung | Teilweise oder unvollständige Aufzeichnung der Nutzungsdaten |
Durch die automatische Durchsetzung von Ressourcenlimits und die Bereitstellung detaillierter Protokolle (wie in den Screenshots unten gezeigt) gewährleistet Workiva Scripting sowohl die Zuverlässigkeit der Plattform als auch die Transparenz für Entwickler, die Automatisierungsskripte erstellen und optimieren.
Beendigung bei erfolgreichem Abschluss eines Laufs
Wenn ein Skript normal abgeschlossen wird, ohne die Grenzwerte zu überschreiten, enthält das Protokoll eine Zusammenfassung der Ressourcennutzung mit der durchschnittlichen und maximalen Auslastung von Arbeitsspeicher, CPU, Festplatte und Ausführungszeit. Diese Informationen geben Aufschluss über die Leistungsmerkmale erfolgreich abgeschlossener Läufe.
Hinweis: Wenn ein Skript sehr schnell ausgeführt wird (z.B. weniger als 1 Sekunde), kann es sein, dass die Ressourcennutzung nicht erfasst wird. In diesen Fällen werden keine Daten zur Ressourcennutzung im Protokoll angezeigt.
Skript läuft zu schnell für eine Stichprobe
Wenn ein Skript zu schnell beendet wird, kann der Monitor keine Nutzungsdaten erfassen.
Skript hat ein normales Ende
Wenn ein Skript ohne Überschreitung von Grenzwerten beendet wird, werden die Statistiken zur Ressourcennutzung vollständig im Protokoll angezeigt.
Abbruch bei Überschreitung der Grenzen
Wenn ein Skriptlauf die konfigurierten Grenzen überschreitet (z.B. Speicher, Festplattennutzung oder zugewiesene Zeit), wird Scripting:
- Versuch, das Skript sicher zu stoppen: Wenn die Grenzwerte überschritten werden, sendet Scripting zunächst ein Beendigungssignal (SIGTERM), damit das Skript aufräumt und sich innerhalb von 15 Sekunden beendet.
- Wenn das Skript nicht innerhalb von 15 Sekunden beendet wird, sendet Skripting ein SIGKILL-Signal, das den Prozess sofort anhält, ohne eine Bereinigung zuzulassen. Dies ist ein erzwungener Abbruch und der Lauf wird mit dem Status "fehlgeschlagen" beendet (im Protokoll in rot angezeigt). Dieser Status weist auf einen Scripting-System-Fehler hin.
- Notieren Sie den Grund für das Anhalten - das Protokoll zeigt an, welches Limit erreicht wurde und fasst den Ressourcenverbrauch des Skripts zusammen.
In den nächsten Abschnitten finden Sie Beispiele dafür, was passiert, wenn ein Skript ohne Code zur Behandlung dieser Signale Grenzen überschreitet. Wie Sie Ihre Skripte so modifizieren, dass sie auf diese Signale angemessen reagieren, erfahren Sie unter Umgang mit Systemsignalen in Skripten.
Speicherlimit überschritten
Wenn ein Skript das konfigurierte Speicherlimit überschreitet, enthält das Protokoll den Grund für den Abbruch und Details über den überschrittenen Schwellenwert.
Festplattennutzungslimit überschritten
Wenn ein Skript das konfigurierte Limit für die Festplattennutzung überschreitet, enthält das Protokoll den Grund für den Abbruch und Details zur Festplattennutzung zum Zeitpunkt des Erreichens des Limits.
Zugewiesene Zeit überschritten
Wenn ein Skript die ihm zugewiesene Zeit überschreitet, enthält das Protokoll den Grund für den Abbruch und die aufgezeichnete Gesamtlaufzeit.
Beendigung, wenn der Benutzer einen Lauf abbricht
Wenn ein Benutzer einen Lauf manuell abbricht, sendet Scripting zunächst ein Unterbrechungssignal (SIGINT), um dem Skript mitzuteilen, dass es anhalten soll. Das Skript hat 15 Sekunden Zeit, um die Bereinigung abzuschließen, den Fortschritt zu speichern oder einen Rollback durchzuführen, bevor es heruntergefahren wird. Nach dieser 15-sekündigen Gnadenfrist findet dieselbe Sequenz wie oben beschrieben statt: Es wird ein Abbruchsignal (SIGTERM) gesendet, damit das Skript weitere 15 Sekunden Zeit hat, um die Bereinigung abzuschließen, gefolgt von einem abschließenden Kill-Signal (SIGKILL), wenn das Skript immer noch nicht beendet wurde.
Die folgende Abbildung zeigt, wie die Skriptprotokolle angezeigt werden, wenn das Skript keinen Code für die Behandlung des Interrupt-Signals enthält.
Wie Sie Ihre Skripte so anpassen können, dass sie auf diese Signale angemessen reagieren, erfahren Sie unter Umgang mit Systemsignalen in Skripten.
Ungeplante Abbrüche
In seltenen Fällen, z.B. wenn ein Skript schneller Speicher verbraucht, als das Scripting-System den Verbrauch überwachen kann, kann das System ein Skript beenden, bevor es erkennt, dass ein Limit überschritten wurde. In diesem Fall protokolliert Scripting einen unvollständigen Nutzungsbericht, in dem nur die vor der Beendigung gesammelten Datenpunkte angezeigt werden.
Behandlung von Systemsignalen in Skripts
Durch die Signalverarbeitung kann Ihr Skript sauber beendet werden, wenn es vom System abgebrochen oder angehalten wird. Durch das Abfangen und Reagieren auf Systemsignale kann Ihr Skript Ressourcen freigeben, Arbeit speichern und sich ordnungsgemäß beenden (z. B. wenn der Status als "abgeschlossen" gemeldet wird), anstatt gewaltsam beendet zu werden.
Wenn ein Skript gestoppt wird, weil ein Benutzer es abbricht oder es die Plattformgrenzen überschreitet, liefert Scripting Unterbrechungs-, Abbruch- und Kill-Signale. Lesen Sie die vorangegangenen Abschnitte, um mehr darüber zu erfahren, wie Unterbrechungs-, Beendigungs- und Kill-Signale ausgelöst werden.
Skripting-Signale und ihr Umgang mit ihnen
In diesem Abschnitt finden Sie Codeblöcke und ein vollständiges Beispiel, mit denen Sie diese Signale behandeln können.
Sie können Ihre Signal-Handler klein halten und die Bereinigung an einer Stelle durchführen, indem Sie einen try/finally Block verwenden, der immer beim Herunterfahren ausgeführt wird. So bleiben Skripte vorhersehbar und leicht zu pflegen.
Die allgemeine Struktur für die Behandlung von Signalen in Ihrem Skript ist gleich, unabhängig davon, welches Signal empfangen wird:
- Anfang der Datei: importieren Sie Module und definieren Sie den Handler
- Frühe Initialisierung: registrieren Sie den Handler, bevor Sie mit der Arbeit beginnen
- Um Ihre Arbeit herum: verpacken Sie den Hauptcode in einen
try/finallyBlock, damit die Aufräumarbeiten immer ausgeführt werden
Benutzer bricht den Lauf ab (SIGINT)
Dies geschieht, wenn ein Benutzer auf Cancel klickt, um die Ausführung des Skripts abzubrechen.
# --- Anfang der Datei --- import signal, sys # Tiny handler: sofortiger, eleganter Exit def _graceful_exit(signum, frame): print("SIGINT received: cancellation requested. Aufräumen...") raise SystemExit(0) # --- Frühe Initialisierung --- signal.signal(signal.SIGINT, _graceful_exit) Um Ihre Arbeit herum (später in der Datei):
versuchen: # Ihre langwierige Arbeit hier ... finally: # zentraler Ort zum Schließen von Dateien, Leeren von Protokollen usw. print("Letzte Aufräumarbeiten vor dem Beenden") Das folgende Bild zeigt, wie die Skriptprotokolle aussehen, wenn das Interrupt-Signal (SIGINT) behandelt wird.
Direkte Behandlung von KeyboardInterrupt
Workiva Scripting löst auch KeyboardInterrupt aus, wenn SIGINT an den Hauptthread geliefert wird. Sie können diese Ausnahme in Ihrem try Block abfangen und denselben Bereinigungspfad aufrufen, der durch _graceful_exit() definiert ist.
try: # Ihre langwierige Arbeit hier ... except KeyboardInterrupt: print("KeyboardInterrupt empfangen: Aufräumen vor dem Beenden...") _graceful_exit(None, None) finally: # zentrale Stelle für das Schließen von Dateien, Leeren von Protokollen usw. print("Letzte Aufräumarbeiten vor dem Beenden") Die folgende Abbildung zeigt, wie die Skriptprotokolle erscheinen, wenn das Unterbrechungssignal über die Tastaturunterbrechung behandelt wird.
Scripting-Beendigungssignal zum Anhalten nach einer Karenzzeit (SIGTERM)
Das Skript fordert Ihr Skript zum Anhalten auf (z.B. nach Überschreiten von Grenzwerten). Ihr Skript hat eine kurze Gnadenfrist zum Beenden.
# --- Anfang der Datei --- def _graceful_term(signum, frame): print("SIGTERM received: platform requested termination. Finishing up...") raise SystemExit(0) # --- Frühe Initialisierung --- signal.signal(signal.SIGTERM, _graceful_term) Die folgende Abbildung zeigt, wie die Skriptprotokolle angezeigt werden, wenn das Abbruchsignal (SIGTERM) behandelt wird.
Scripting-Kill-Signal zum sofortigen Anhalten (SIGKILL)
Wenn Ihr Skript während der Karenzzeit nicht beendet wird, sendet Scripting SIGKILL. Sie können SIGKILL nicht abfangen. Beenden Sie sofort bei SIGINT/SIGTERM, damit Ihr finally Block ausgeführt werden kann, bevor ein Kill eintritt.
Die Screenshots in den vorangegangenen Abschnitten zeigen, wie die Protokolle als Ergebnis des Kill-Signals aussehen würden.
Vollständiges Beispiel (fertig zum Kopieren und Einfügen)
Diese Vorlage registriert minimale Handler und zentralisiert die Bereinigung in finally. Fügen Sie sie in Workiva Scripting ein und ersetzen Sie den markierten Bereich durch Ihre Logik.
Wo Sie Ihren Code einfügen können: Ersetzen Sie die Beispielschleife unter # ===== YOUR CODE STARTS HERE ===== durch Ihre eigentlichen Aufgaben. Vermeiden Sie sehr lange, nicht unterbrechbare Aufrufe, damit das Skript den finally Block erreichen kann, bevor die Plattform zu SIGKILL eskaliert.
"""Workiva Scripting-Vorlage: minimale Handler + Aufräumen in finally - Winzige Handler raise SystemExit(0) bei SIGINT/SIGTERM - Ein einziger finally-Block läuft für das Aufräumen, unabhängig davon, wie das Skript endet - Hält den Code klein und vorhersehbar """ import signal import time # --- Signal-Handler (winzig bleiben) --- def _graceful_exit(signum, frame): print("SIGINT empfangen: Abbruch angefordert. Aufräumen...") raise SystemExit(0) def _graceful_term(signum, frame): print("SIGTERM received: platform requested termination. Finishing up...") raise SystemExit(0) # --- Registrieren Sie Handler, BEVOR Sie schwere Arbeit leisten --- signal.signal(signal.SIGINT, _graceful_exit) signal.signal(signal.SIGTERM, _graceful_term) # --- Die Hauptarbeit Ihres Skripts --- def main(): print("Starting work...") # ===== YOUR CODE STARTS HERE ===== # Beispiel für eine lang laufende Schleife. Ersetzen Sie durch Ihre eigene Logik. for i in range(1, 1_000_000): # Simulieren Sie eine Arbeitseinheit (ersetzen Sie sie durch echte Logik) print(f "Working on item {i}...") time.sleep(1) # ===== YOUR CODE ENDS HERE ===== if __name__ == "__main__": try: main() finally: # Zentralisierte Bereinigung, die immer läuft (auch bei SIGINT/SIGTERM) print("Letzte Bereinigung vor Exit")