Task Engine & Webhooks

Automatisieren Sie VergeOS-Operationen mit der integrierten Task Engine — ereignisgesteuerte Trigger, geplante Aufgaben, Webhooks zu externen Systemen und modulare Automatisierungsabläufe.

The VergeOS Task Engine ist ein integriertes Automatisierungs-Framework, das ereignisgesteuerte und zeitplanbasierte Abläufe ohne externe Tools ermöglicht. Anstatt Skripte zu schreiben oder auf Cron-Jobs auf separaten Maschinen zu setzen, definieren Administratoren Aufgaben, verknüpfen Trigger und lassen die Plattform Aktionen automatisch ausführen. Der Task Engine ist die native Ergänzung zu den API- und IaC-Tools, die weiter oben in diesem Modul behandelt wurden — während Terraform und Ansible das Provisioning verwalten, übernimmt der Task Engine die tägliche operative Automatisierung innerhalb des laufenden Systems.

Komponenten des Task Engine

Der Task Engine verwendet sechs modulare Bausteine, die in flexiblen Kombinationen zusammengesetzt werden können:

Komponente	Beschreibung
Aufgaben	Definieren die auszuführende Aktion (z. B. eine VM herunterfahren, eine Benachrichtigung senden)
Zeitpläne	Geben an, wann und wie oft eine Aufgabe ausgeführt werden soll (z. B. täglich, wöchentlich, einmalig)
Ereignisse	Definieren Bedingungen, die eine Aufgabe auslösen (z. B. Benutzeranmeldung, Synchronisierungsfehler)
Webhooks	Senden Daten in Echtzeit per HTTP POST an externe Systeme
Skripte	Programmierbare Automatisierungsbausteine, die im Tasks Dashboard angezeigt werden (siehe Abschnitt Skripte unten)
Aufgabenprotokolle	Protokollieren die Erstellung und Ausführung von Aufgaben zur Auditierung und Fehlerbehebung

Alle Komponenten werden aufgerufen über System → Tasks Dashboard in der VergeOS-Oberfläche.

Modulare Automatisierungsarchitektur

Eine zentrale Stärke des Task Engine ist sein Viele-zu-viele Beziehungsmodell. Komponenten sind nicht auf 1:1-Zuordnungen festgelegt:

• Mehrere Aufgaben oder Ereignisse → ein einzelner Webhook — Konfigurieren Sie einen Webhook einmal und lösen Sie ihn aus mehreren verschiedenen Ereignissen aus (Sync-Fehler, Anmeldeversuche, Systemwarnungen). Dadurch werden externe Integrationen zentralisiert und Duplikate reduziert.
• Eine Aufgabe → mehrere Ereignisse — Eine Aufgabe „VM einschalten“ kann ausgelöst werden, wenn sich ein bestimmter Benutzer anmeldet oder wenn ein geplantes Wartungsfenster beginnt. Verwenden Sie Aufgabendefinitionen über verschiedene Szenarien hinweg wieder.
• Ein Zeitplan → mehrere Aufgaben — Definieren Sie einmal ein wöchentliches Wartungsfenster und verknüpfen Sie es mit Update-, Benachrichtigungs- und Herunterfahraufgaben. Konsistenz ohne Konfigurationsdrift.

Dieses zusammensetzbare Design bedeutet, dass Sie eine Bibliothek wiederverwendbarer Aufgaben, Zeitpläne und Webhooks aufbauen und diese dann miteinander verknüpfen, während sich Ihre betrieblichen Anforderungen weiterentwickeln.

Ereignisbasierte Trigger

Ereignis-Trigger lösen Aufgaben automatisch aus, wenn ein bestimmtes Systemereignis erkannt wird. Beim Erstellen eines Ereignisses wählen Sie:

1. Typ — Die Objektklasse (z. B. Benutzer, virtuelle Maschinen, Alarme, Mandanten, ausgehende Synchronisierungen)
2. Ereignis — Das konkrete Ereignis (z. B. Anmeldung, Abmeldung, Einschalten, Fehler, Statusänderung)
3. Objektinstanz oder Tag — Entweder ein bestimmtes Objekt (ein bestimmter Benutzer oder eine VM) oder ein Tag, das zu einer Gruppe von Objekten passt

Häufige Muster für Ereignis-Trigger

Ereignistyp	Beispielereignis	Typische Aktion
Benutzer	Anmeldung / Abmeldung	GPU-VMs für den angemeldeten Benutzer ein-/ausschalten
Ausgehende Synchronisierungen	Fehler	Slack-Benachrichtigung + E-Mail-Warnung senden
Virtuelle Maschinen	Einschalten / Ausschalten	Über Webhook an ein externes Monitoring-System protokollieren
Alarme	Fehlerschweregrad	E-Mail-Benachrichtigung an das Ops-Team senden
Alarme	Ausgelöst	Webhook an PagerDuty oder On-Call-Rotation senden

Tag-basierte Trigger

Anstatt separate Ereignisse für jede VM zu erstellen, weisen Sie einen gemeinsamen Tag (z. B. gpu-workstation) den zugehörigen VMs zu. Konfigurieren Sie dann den Ereignis-Trigger so, dass er auf dieses Tag passt — jede VM mit dem Tag aktiviert den Trigger. Das ist wesentlich wartungsfreundlicher als Ereignisse pro Objekt.

Zeitplanbasierte Trigger

Zeitplan-Trigger führen Aufgaben zu vordefinierten Zeiten oder in vordefinierten Intervallen aus. VergeOS enthält mehrere Standardzeitpläne und unterstützt das Erstellen benutzerdefinierter Zeitpläne.

Optionen zur Zeitplankonfiguration

• Wiederkehrend — Alle N Tage, Stunden, Minuten, Wochen, Monate oder Jahre wiederholen, mit Auswahl eines bestimmten Tages/der Uhrzeit
• Einmalig — „Wiederholt sich nicht“ auswählen und ein einzelnes Startdatum und eine Uhrzeit angeben
• Enddatum — Wiederkehrende Zeitpläne sind standardmäßig unbegrenzt; optional kann ein Enddatum festgelegt werden

Häufige Zeitplanmuster

Zeitplan	Anwendungsfall
Jeden Samstag um 17:00 Uhr	Systemupdates prüfen und herunterladen
Jeden Freitag um 18:00 Uhr	Ressourcenintensive VMs am Ende des Arbeitstages ausschalten
Bestimmtes zukünftiges Datum	Ein temporäres Mitarbeiterkonto 30 Tage nach Erstellung deaktivieren
Täglich um Mitternacht	Überprüfungen zur Verifizierung von Mandanten-Backups ausführen
Erster eines jeden Monats	Berichte zur Ressourcenauslastung erstellen

Webhooks

Webhooks ermöglichen Push-basierte Nachrichten an externe Systeme, wenn Aufgaben ausgeführt werden. Anstatt dass externe Systeme VergeOS ständig auf Status abfragen, sendet die Plattform bei erfüllten konfigurierten Bedingungen proaktiv HTTP-POST-Anfragen an vordefinierte URLs.

Webhook-Konfiguration

Beim Erstellen eines Webhooks konfigurieren Sie:

Feld	Beschreibung
Namen	Beschreibender Bezeichner für den Webhook
URL	Der API-Endpunkt auf dem externen System, der HTTP-POST-Anfragen annimmt
Autorisierungstyp	Bearer Token, API-Schlüssel, Basic (Benutzername/Passwort) oder Keine
Header	Benutzerdefinierte HTTP-Header (Standard: content-type: application/json)
Unsichere Zertifikate zulassen	Für selbstsignierte Zertifikate in Dev-/Testumgebungen
Timeout	Maximale Anzahl Sekunden, die auf eine Antwort gewartet wird (mindestens 3)
Wiederholungen	Anzahl der Wiederholungsversuche bei Fehler oder ausbleibender Antwort

Payload-Variablen

Payloads von Webhook-Aufgaben unterstützen dynamische Variablen, die zur Ausführungszeit aufgelöst werden:

Variabel	Wert
${DATE}	Aktuelles Datum/Uhrzeit im Vollstring-Format (z. B. Do, 16 Okt 2025 11:38:07 EDT)
${TIMESTAMP}	Aktuelles Datum/Uhrzeit als Epoch-Ganzzahl (z. B. 1760629087)
${RANDOM}	Zufällig erzeugte Ganzzahl
${NAME}	Name des jeweiligen VergeOS-Objekts

Anwendungsfälle für Webhooks

• Senden Sie eine Slack-Benachrichtigung an einen Admin-Kanal, wenn ein Sync-Job einen Fehler erzeugt
• Posten Sie an ein Buchhaltungssystem wenn ein Mandant online geht und dadurch eine automatische Abrechnung auslöst
• Lösen Sie einen Zapier-Workflow aus, wenn eine bestimmte VM eingeschaltet wird, und initiieren Sie damit systemübergreifende Aktionen

Praxisbeispiel 1: GPU-VMs automatisch ein-/ausschalten

Dieses Beispiel zeigt, wie Tags, Aufgaben, Ereignisse und Zeitpläne zusammenarbeiten, um ressourcenintensive GPU-Workloads zu verwalten.

Szenario: Der Benutzer JThompson verwendet mehrere GPU-gestützte VMs für 3D-Modellierung. Diese VMs verbrauchen erheblich Rechenleistung und Speicher — sie im Leerlauf weiterlaufen zu lassen, ist ineffizient.

Ziel: Die VMs sollen beim Anmelden von JThompson eingeschaltet werden, bei der Abmeldung ausgeschaltet werden und als Sicherheitsmaßnahme jeden Freitag um 18:00 Uhr heruntergefahren werden.

Konfigurationsschritte

1. Tag erstellen — Unter System → Tags eine Kategorie VMs mit einem Tag JThompson-GPUerstellen. Weisen Sie diesen Tag den Ziel-VMs zu.
2. „VM einschalten“-Aufgabe erstellen — System → Tasks Dashboard → Neue Aufgabe. Stellen Sie Objekt-Typ auf Virtuelle Maschinen, wählen Sie den Tag JThompson-GPU, und setzen Sie die Aktion auf Einschalten.
3. Login-Ereignis-Trigger hinzufügen — Fügen Sie im Aufgaben-Dashboard einen Ereignis-Trigger hinzu: Typ = Benutzer, Ereignis = Anmeldung, Objekt = JThompson.
4. „VM ausschalten“-Aufgabe erstellen — Neue Aufgabe mit derselben Tag-Auswahl, aber Aktion = Ausschalten.
5. Abmelde-Ereignis-Trigger hinzufügen — Ereignis-Trigger auf der Ausschaltaufgabe: Typ = Benutzer, Ereignis = Abmeldung, Objekt = JThompson.
6. Freitagszeitplan erstellen — Neuer Zeitplan: Alle 1 Woche am Freitag um 18:00 Uhr wiederholen.
7. Zeitplan-Trigger hinzufügen — Verknüpfen Sie den Freitagszeitplan als Zeitplan-Trigger mit der Aufgabe „VM ausschalten“.

Ergebnis: Die VMs schalten sich automatisch ein, wenn sich JThompson anmeldet, schalten sich bei der Abmeldung aus und werden unabhängig vom Anmeldestatus garantiert jeden Freitag um 18:00 Uhr heruntergefahren. Dieses Muster gilt für jede Workload mit hohem Ressourcenbedarf — ML-Trainingssysteme, CAD-Rendering-Workstations, Integrations-Testumgebungen oder Cluster für Finanzmodellierung.

Praxisbeispiel 2: Slack- + E-Mail-Warnung bei Sync-Fehler

Dieses Beispiel zeigt, wie Webhooks, Aufgaben und Ereignisse kombiniert werden, um Multi-Channel-Warnmeldungen für DR-/BC-Operationen bereitzustellen.

Szenario: Ein Dienstanbieter benötigt sofortige Benachrichtigungen, wenn nächtliche Sync-Jobs Fehler erzeugen, sowohl über Slack als auch per E-Mail.

Konfigurationsschritte

1. Einen Webhook erstellen — System → Tasks Dashboard → Neuer Webhook. Konfigurieren Sie die eingehende Slack-Webhook-URL, setzen Sie den Autorisierungstyp auf Bearer Token mit dem Slack-Bot-Token und setzen Sie content-type auf application/json.
2. E-Mail-Aufgabe erstellen — Neue Aufgabe: Objekt-Typ = E-Mail, konfigurieren Sie die Empfängeradresse und den Text des Warnhinweises.
3. Webhook-Aufgabe erstellen — Neue Aufgabe: Objekt-Typ = Webhook, wählen Sie den Slack-Webhook, Aktion = Senden. Definieren Sie die JSON-Nutzlast:

   {
     "text": "Sync-Fehler-Warnung: ${NAME} ist bei ${DATE} fehlgeschlagen"
   }

4. Ereignis-Trigger zur Webhook-Aufgabe hinzufügen — Typ = Ausgehende Synchronisierungen, Ereignis = Fehler, wählen Sie den spezifischen Sync-Job aus (oder verwenden Sie ein Tag für mehrere Synchronisierungen).
5. Denselben Ereignis-Trigger zur E-Mail-Aufgabe hinzufügen — Gleiche Konfiguration wie in Schritt 4, verknüpft mit der E-Mail-Aufgabe.

Ergebnis: Wenn ein überwachter Sync-Job einen Fehler erzeugt, erhalten sowohl der Slack-Kanal als auch das E-Mail-Postfach gleichzeitig Warnmeldungen. Administratoren können umgehend untersuchen, wodurch die Chance maximiert wird, den Sync innerhalb des verfügbaren Fensters abzuschließen.

Mit Tags skalieren

Wenn derselbe Trigger für alle ausgehenden Synchronisierungen gelten soll, weisen Sie diesen Sync-Jobs einen gemeinsamen Tag zu (z. B. critical-sync). Konfigurieren Sie den Trigger so, dass er bei jeder Synchronisierung mit diesem Tag ausgelöst wird — Sie müssen keine einzelnen Trigger pro Sync erstellen.

Aufgaben erstellen: Schnellreferenz

Jede Aufgabe folgt demselben Erstellungsablauf:

1. Navigieren Sie zu System → Tasks Dashboard → Neue Aufgabe
2. Konfigurieren: Namen, Objekt-Typ, Objekt (spezifische Instanz oder Tag), Aktion, Einstellungen
3. Einen oder mehrere Ereignis-Trigger und/oder Zeitplan-Trigger
4. Überprüfen Sie in Aufgabenprotokolle dass die Aufgabe korrekt ausgelöst wird

Aufgaben haben einen Aktiviert Schalter; Sie können eine Aufgabe vorübergehend deaktivieren, wenn Sie die Konfiguration vor der Aktivierung überprüfen müssen, und sie dann bei Bedarf wieder aktivieren.

Aufgabenfelder

Namen — Beschreibender Bezeichner Objekt-Typ — Bereich der Anwendung (VMs, Netzwerke, Benutzer, Webhooks usw.) Objekt — Spezifisches Ziel oder Tag Aktion — Auszuführende Operation Nach Ausführung löschen — Option für einmalige Ausführung

Aufgabenprotokolle

Jede Ausführung einer Aufgabe wird protokolliert mit: - Zeitstempel und Dauer - Erfolgs-/Fehlerstatus - Auslösendes Ereignis oder Zeitplan - Details des Zielobjekts Protokolle sind im Tasks Dashboard für Audits verfügbar.

Skripte (Vorschau)

Das Skripte Die in VergeOS 26 eingeführte Funktion legt die Grundlage für zukünftige von Administratoren definierte Automatisierungs-Workflows. Derzeit ist sie zwar auf interne Systemoperationen beschränkt, wurde jedoch mit Blick auf Erweiterbarkeit entwickelt. Zukünftige Versionen werden Scripts erweitern, um benutzerdefinierte Admin-Automatisierung direkt innerhalb der Plattform zu unterstützen — als Ergänzung zum bestehenden Task Engine mit programmierbarer Logik.

Kommen Sie von VMware oder Nutanix?

Der Task Engine ist auf jeder Ebene in VergeOS integriert (einschließlich innerhalb von Mandanten) — kein separates Orchestrator-Appliance, keine zusätzliche Automatisierungslizenz. Konfigurieren Sie Ereignis-Trigger, Zeitpläne und Webhooks über dieselbe Oberfläche, die Sie bereits für VMs und Speicher verwenden.

Wichtige Erkenntnisse

Ereignisgesteuert

Lösen Sie Automatisierungen durch Systemereignisse aus — Benutzeranmeldung/Abmeldung, Sync-Fehler, VM-Statusänderungen, Alarmbedingungen — ohne Polling oder externe Scheduler.

Zeitplanbasiert

Führen Sie Aufgaben zu bestimmten Zeiten mit integrierten oder benutzerdefinierten Zeitplänen aus. Einmalig oder wiederkehrend, mit optionalem Enddatum.

Externe Integration

Senden Sie Benachrichtigungen per Webhook mit konfigurierbarer Authentifizierung, Headern und Wiederholungslogik an Slack, E-Mail, Zapier oder einen beliebigen HTTP-Endpunkt.

Modular & wiederverwendbar

Viele-zu-viele-Beziehungen zwischen Aufgaben, Ereignissen, Zeitplänen und Webhooks. Einmal erstellen, frei zusammensetzen.