> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/de/modul-8-entwicklung-and-devops/06-task-engine.md).

# Task Engine & Webhooks

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.

```mermaid
flowchart LR
    subgraph Trigger
        E[Ereignis-Trigger<br/>Benutzeranmeldung, Sync-Fehler]
        S[Zeitplan-Trigger<br/>täglich, wöchentlich, einmalig]
    end

    subgraph Aktionen
        T1[Aufgabe: VM einschalten]
        T2[Aufgabe: E-Mail senden]
        T3[Aufgabe: Webhook senden]
    end

    subgraph Extern
        SL[Slack-Kanal]
        EM[E-Mail / SMTP]
        ZP[Zapier / Monitoring]
    end

    E --> T1
    E --> T2
    E --> T3
    S --> T1
    S --> T2
    T3 --> SL
    T3 --> ZP
    T2 --> EM
```

## 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             |

{% hint style="success" %}
**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.
{% endhint %}

## 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-GPU`erstellen. 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:

   ```json
   {
     "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.

{% hint style="success" %}
**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.
{% endhint %}

## 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.

{% hint style="info" %}
**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.
{% endhint %}

## 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/learn-the-platform/de/modul-8-entwicklung-and-devops/06-task-engine.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.