WorkPipe

Generelle Informationen

Was sind WorkPipes?

Hinweis: Diese Funktionalität befindet sich aktuell im Beta Status.

Mit WorkPipe können Sie Aufgaben aus DocBee heraus auf eigenen Servern und Rechnern ausführen lassen, ohne VPN und ohne dass von außen Verbindungen zu Ihren Systemen geöffnet werden müssen. Ein Runner läuft auf einem Host Ihrer Wahl und holt Aufgaben selbstständig aus DocBee ab. WorkPipes sind also ideal, wenn Sie wiederkehrende Schritte „in der eigenen Infrastruktur“ automatisieren wollen, aber die Steuerung und Rückmeldung in DocBee behalten möchten. Typischer Anwendungsfall: Ein Vorgang kommt rein, eine Automatisierungsregel erkennt den Typ und legt automatisch eine WorkPipe an z. B. mit dem Benutzernamen aus dem Ticket als Parameter. Der Runner auf dem AD-Server holt sich die Aufgabe, setzt das Passwort zurück und meldet das Ergebnis zurück an DocBee. Eine weitere Automatisierungsregel reagiert auf den Abschluss und aktualisiert das Ticket.

Wann sollten Sie WorkPipes einsetzen?

• Ausführung von Skripten oder Kommandozeilenaktionen in Ihrer internen Infrastruktur (z.B. das Zurücksetzen eines AD-Passworts)
• Workflows aus Vorgängen/Protokollen heraus anstoßen (z. B. „Konto entsperren“, „Dienst neu starten“)
• Ergebnisse zurück in DocBee spiegeln und danach automatisch weiterarbeiten (Vorgang aktualisieren, Nachricht schreiben, Status setzen)

WorkPipes

Bevor man WorkPipes nutzen kann, müssen diese erst unter Administration > WorkPipes aktiviert werden. Danach stehen Ihnen zwei zentrale Bereiche zur Verfügung:

• Runner: Hier verwalten Sie die Runner, die Aufgaben ausführen dürfen.
• WorkPipe Queue: Hier sehen Sie die erstellten WorkPipes und deren Status.

Einstellungen

Feld	Beschreibung
Server Public-Key Fingerprint	Fingerprint des öffentlichen Server-Schlüssels zur Runner-Verifizierung. Wird automatisch generiert.

WorkPipe Runner

Der Runner wird auf beliebigen Hosts installiert und verbindet sich ausgehend über HTTPS mit DocBee. Er nimmt Aufgaben entgegen und führt sie lokal aus z. B. Skripte oder Befehle direkt auf dem Ziel-Host. Der Runner meldet sich regelmäßig bei DocBee (Heartbeat-Mechanik), damit wird der Status des Runners in der Oberfläche aktualisiert.

Runnner bearbeiten

Feld	Pflicht	Beschreibung
Name	Ja	Name des Runners
Aktiv	-	Aktueller Zustand des Runners Aktiv, Verzögert, Inaktiv

Token generieren

Hinweis: Der alte Token wird sofort ungültig, wenn ein neuer Token generiert wird.

Feld	Beschreibung
Token	Token des Runners. Dieses Token wird nur einmal angezeigt, bitte kopieren und sicher aufbewahren.
Server Fingerprint	Der Fingerprint aus den WorkPipe Einstellung.

Installation

Für die Installation des Runners auf Ihrem Host finden Sie die ausführliche Anleitung in der Runner-Dokumentation:

https://pypi.org/project/docbee-workpipe-runner/

WorkPipe Queues

In der Queue sehen Sie alle WorkPipes, die erstellt wurden, inklusive Status und Ergebnis.

WorkPipe erstellen

WorkPipes können auf verschiedene Arten erstellt werden:

• Automatisierungen: Reaktion „WorkPipe erstellen“ legt eine WorkPipe mit Typ und Parametern an. Platzhalter werden dabei automatisch befüllt (z. B. Ticketnummer, Kundenname).
• Protokoll-Abschluss-Reaktionen: Beim Abschluss eines Protokolls kann ebenfalls eine WorkPipe erstellt werden, Parameter können aus Protokollwerten befüllt werden.
• DocBee-Skript: Die Methode createWorkPipeItemForObject(type, data, object) erstellt eine WorkPipe direkt mit Referenz auf einen Vorgang, eine Leistung oder ein Protokoll. Bestehende Methode createWorkPipeItem bleibt abwärtskompatibel.

Feld	Pflicht	Beschreibung
Typ	Ja	Bezeichnung für die WorkPipe, wird vom Runner ausgewertet.
Schlüssel	Ja	Zusätzlicher Parameter für den Typ. Es können mehrere Schlüssel-Wert-Paare hinzugefügt werden.
Wert	Nein	Wert des zusätzlichen Parameters. Kompatibel mit Nachrichten-Logik und Platzhaltern.

WorkPipe Status

Status	Beschreibung
Ausstehend	Wartet darauf, von einem Runner aufgenommen zu werden
In Bearbeitung	Wird aktuell von einem Runner verarbeitet (gesperrt)
Abgeschlossen	Erfolgreich abgeschlossen — wird nach Rule-Engine-Trigger gelösch
Fehler	Verarbeitung fehlgeschlagen — bleibt in DB zur Inspektion/Neustart
Neugestartet	Ursprünglicher ERROR-Eintrag wurde neu gestartet (kann nicht erneut gestartet werden)