Open Ticket AI Runtime – Python-Automatisierung für OTOBO

In diesem Leitfaden: OTAI Runtime im OTOBO-Admin (Generic Interface, Python, On-Premise). Produktdoku: openticketai.com/de/docs/otai-runtime.

Verwandt: Generic Agent · Web Services · REST API · OpenTicketAI Produktübersicht · OTOBO KI-Funktionen

Wenn eingebaute Werkzeuge wie der Generic Agent oder das Prozessmanagement an ihre Grenzen stoßen, brauchen Sie eine Möglichkeit, komplexere Logik abzubilden: Tickets abrufen, Bedingungen prüfen, externe APIs aufrufen, Felder aktualisieren und wiederholen — alles unter Ihrer Kontrolle und auf Ihrer Infrastruktur.

Die Open Ticket AI Runtime (OTAI Runtime) ist eine Open-Source-Automatisierungs-Engine in Python genau dafür. Trotz des Namens ist sie nicht auf KI beschränkt. Sie eignet sich für klassisches Ticket-Routing, Feldaktualisierungen, zeitgesteuerte Jobs und Integrationen — KI-Klassifikation oder Zusammenfassung kommen nur dort hin, wo sie Mehrwert bringen.

Quellcode: github.com/Softoft-Orga/open-ticket-ai (LGPL-2.1)

Was die OTAI Runtime leistet

Die OTAI Runtime läuft als containerisierter Python-Dienst (Docker oder pip install) zwischen Ihrem Helpdesk und der von Ihnen definierten Logik. Für OTOBO erfolgt typischerweise:

1. Ticket-Erfassung — über das Generic Interface (Web Services) mit einem dedizierten technischen Benutzer.
2. Pipeline-Ausführung — eine Folge von Pipes, die Kontext Schritt für Schritt weitergeben.
3. Aktionen ausführen — Queue, Priorität, Dynamic Fields aktualisieren, Notizen hinzufügen, externe Systeme anbinden oder ML-Modelle lokal ausführen.
4. Alles protokollieren — jedes Pipe-Ergebnis ist nachvollziehbar für Audit und Debugging.

Da die Verarbeitung On-Premise bleibt, müssen Ticket-Inhalte das Netzwerk nicht verlassen — ein wichtiger Unterschied zu rein cloudbasierten Automatisierungstools.

flowchart LR
    OTOBO["OTOBO\n(Generic Interface)"]
    RT["OTAI Runtime\n(Python-Pipelines)"]
    AI["Optional:\nlokales ML / LLM"]
    EXT["Optional:\nexterne APIs"]

    OTOBO <-->|REST| RT
    RT --> AI
    RT --> EXT
    RT -->|Tickets aktualisieren| OTOBO

---

Pipes: Wenn das, dann das

Das Kernkonzept sind Pipes: kleine, kombinierbare Verarbeitungseinheiten, die in YAML verkettet werden. Jede Pipe erhält einen gemeinsamen Kontext (Ergebnisse früherer Schritte), führt ihre Aufgabe aus und erzeugt ein PipeResult für den nächsten Schritt.

Denken Sie an Wenn das, dann das — verkettet:

Muster	Pipe-Typ	Verhalten
Wann (Trigger)	IntervalTrigger, ExpressionPipe	Nur alle N Sekunden oder wenn eine Bedingung gilt
Wenn (Guard)	ExpressionPipe mit fail()	Pipeline stoppen, wenn eine Prüfung fehlschlägt
Dann (Aktion)	FetchTicketsPipe, UpdateTicketPipe, AddNotePipe	Tickets in OTOBO lesen oder ändern
Sonst / überspringen	SimpleSequentialRunner	run nur ausführen, wenn on erfolgreich war

Einfache Pipes

Atomare Schritte mit einer Aufgabe — z. B. Tickets aus einer Queue laden:

- id: fetch_tickets
  use: base:FetchTicketsPipe
  injects:
    ticket_system: otobo_znuny
  params:
    ticket_search_criteria:
      queue:
        name: Incoming
      limit: 10

Composite Pipes (Mehrschritt-Workflows)

Ein CompositePipe führt Kind-Schritte der Reihe nach aus und führt deren Ergebnisse zusammen:

- id: ticket_workflow
  use: base:CompositePipe
  steps:
    - id: fetch
      use: base:FetchTicketsPipe
      injects: { ticket_system: otobo_znuny }
      params:
        ticket_search_criteria:
          queue: { name: Incoming }
          limit: 10

    - id: guard
      use: base:ExpressionPipe
      params:
        expression: >
          {{ fail() if (get_pipe_result('fetch', 'fetched_tickets') | length) == 0 else 'ok' }}

    - id: update
      use: base:UpdateTicketPipe
      injects: { ticket_system: otobo_znuny }
      params:
        ticket_id: "{{ get_pipe_result('fetch', 'fetched_tickets') | first | attr('id') }}"
        updated_ticket:
          queue:
            name: Support

Bedingte Ausführung

SimpleSequentialRunner implementiert klassische Wenn-Dann-Logik: run nur ausführen, wenn on erfolgreich war (z. B. wenn ein Intervall-Trigger feuert):

- id: run-when-triggered
  use: base:SimpleSequentialRunner
  params:
    on:
      id: gate
      use: base:IntervalTrigger
      params: { interval: PT60S }
    run:
      id: do-something
      use: base:ExpressionPipe
      params: { expression: Triggered run }

Pipes teilen Daten über Jinja2-Templates. Mit get_pipe_result('pipe_id', 'data_key') lesen Sie Ausgaben früherer Schritte; mit has_failed('pipe_id') verzweigen Sie bei Fehlern.

Für Hintergrund-Polling (Daemon-Schleifen) wiederholt SimpleSequentialOrchestrator seine Schritte endlos — nützlich für kontinuierliche Ticket-Verarbeitung.

---

Anbindung an OTOBO

Die OTAI Runtime kommuniziert mit OTOBO über das Generic Interface — dieselbe Schnittstelle wie in Web Services und der REST-API-Referenz beschrieben.

Typisches Setup:

1. Technischer Benutzer — Agent z. B. open_ticket_ai anlegen, nur mit den Rechten, die Ihre Pipeline braucht (ro, move_into, priority, note usw.).
2. Web Service — mitgeliefertes OpenTicketAI.yml-Template aus dem GitHub-Repository importieren. Es stellt eingeschränkte REST-Operationen bereit (ticket-search, ticket-get, ticket-update, ticket-create) und mappt alle Anfragen auf den technischen Benutzer.
3. Runtime-Konfiguration — OTAI per Umgebungsvariablen und config.yml auf OTOBO-URL und Zugangsdaten zeigen.

Die OTOBO-Schritte entsprechen einer Standard-Web-Services-Integration; die Runtime ergänzt die Python-Pipeline-Schicht darüber.

Ausführliche Anleitung: OTOBO / Znuny Setup (Open Ticket AI Docs)

---

Schnellstart

Installation per pip

pip install open-ticket-ai
pip install open-ticket-ai otai-otobo-znuny otai-hf-local

Mit Docker starten

docker pull openticketai/engine:latest

services:
  open-ticket-ai:
    image: openticketai/engine:latest
    ports:
      - "8080:8080"
    environment:
      OT_AI_CONFIG: /app/config.yml
    volumes:
      - ./config.yml:/app/config.yml:ro

Repository für Entwicklung klonen:

git clone https://github.com/Softoft-Orga/open-ticket-ai.git
cd open-ticket-ai
uv sync
uv run -m pytest

---

Beispiel: Tickets klassifizieren und routen

Dasselbe Pipe-Modell unterstützt KI- und Nicht-KI-Schritte. Eine Klassifikations-Pipe kann zwischen Abruf und Update stehen:

- id: classify
  use: otai_hf_local:HFLocalTextClassificationPipe
  params:
    model: bert-base-german-cased
    text: "{{ get_pipe_result('fetch', 'fetched_tickets') | first | attr('subject') }}"

- id: update
  use: base:UpdateTicketPipe
  injects: { ticket_system: otobo_znuny }
  params:
    ticket_id: "{{ get_pipe_result('fetch', 'fetched_tickets') | first | attr('id') }}"
    updated_ticket:
      queue:
        name: "{{ get_pipe_result('classify', 'predicted_queue') }}"

Ersetzen Sie die Klassifikations-Pipe durch eine beliebige andere — Stichwort-Matching, HTTP-Aufrufe, Datenbankabfragen — die Workflow-Struktur bleibt gleich.

---

Mit Python-Plugins erweitern

Jede Pipe ist eine in der Pipe-Registry registrierte Python-Klasse (base:FetchTicketsPipe, base:UpdateTicketPipe, …). Sie können:

• Bestehende Pipes in YAML konfigurieren (für viele Automatisierungen ohne Code).
• Community-Plugins aus dem Plugin-Marketplace installieren.
• Eigene Pipes in Python schreiben, wenn proprietäre Geschäftslogik nötig ist, und sie mit use: your_plugin:YourPipe referenzieren.

Die Runtime nutzt Dependency Injection, strukturiertes Logging und pytest-basierte Tests — siehe die Entwickler-Dokumentation auf openticketai.com.

---

OTAI vs. eingebaute Automatisierung

Anforderung	Eingebautes OTOBO	OTAI Runtime
Einfache Regeln (Queue, Priorität, Zeit)	Generic Agent	Meist überdimensioniert
Geführte Agenten-/Kunden-Flows	Prozessmanagement	Anderer Zweck
REST-Integration mit externen Systemen	Web Services	OTAI nutzt dies intern
Mehrschritt-Logik, Python, ML, eigene APIs	Begrenzt	OTAI Runtime
On-Premise-KI ohne Cloud-APIs	Nicht eingebaut	OTAI Runtime + lokale Modell-Plugins
Individuelle Automatisierung ohne KI	Generic Agent oder Skripte	OTAI Runtime (Pipes, kein ML nötig)

---

Weiterführende Links

• GitHub-Repository: github.com/Softoft-Orga/open-ticket-ai
• Offizielle OTAI-Runtime-Docs: openticketai.com/de/docs/otai-runtime/
• Pipe-System-Referenz: Pipe System
• Erstes Pipeline-Tutorial: First Pipeline
• Produkt / KI-Lösungen: OpenTicketAI für OTOBO

Lizenz: LGPL-2.1-only — geeignet für Erweiterungen und Integration in Unternehmensumgebungen, während eigener Pipe-Code unter Ihrer Kontrolle bleibt.

Häufig gestellte Fragen

Benötigt die Open Ticket AI Runtime zwingend ein KI-Modell?

Nein, die Open Ticket AI Runtime ist bewusst flexibel konzipiert und nicht ausschließlich auf den Einsatz von Künstlicher Intelligenz beschränkt. Sie kann klassische Automatisierungsaufgaben wie Ticket-Routing, die Aktualisierung von Feldern oder die Ausführung zeitgesteuerter Jobs vollständig ohne ein KI-Modell bewältigen. KI-Funktionen wie Klassifikation oder Zusammenfassung werden nur dann integriert, wenn sie einen klaren Mehrwert für den Workflow bieten. Dies ermöglicht es Organisationen, die Runtime sowohl für traditionelle Automatisierung als auch für erweiterte KI-gestützte Szenarien zu nutzen, je nach Bedarf und Infrastruktur.

Quellen:

• Open Ticket AI Runtime – Python-Automatisierung für OTOBO
• Softoft-Orga/open-ticket-ai - GitHub

Wie funktioniert die Anbindung der OTAI Runtime an OTOBO?

Die OTAI Runtime kommuniziert mit OTOBO primär über das OTOBO Generic Interface, welches auch für Web Services und die REST-API genutzt wird. Der typische Anbindungsprozess umfasst mehrere Schritte:

• Technischer Benutzer: Zuerst wird ein dedizierter technischer Agent in OTOBO angelegt, beispielsweise open_ticket_ai. Dieser Benutzer erhält nur die notwendigen Rechte, die für die Ausführung der Pipeline-Aktionen erforderlich sind (z.B. ro für Lesezugriff, move_into für Queue-Wechsel, priority für Prioritätsänderungen, note zum Hinzufügen von Notizen).
• Web Service: Anschließend wird ein Web Service in OTOBO konfiguriert, oft unter Verwendung des mitgelieferten OpenTicketAI.yml-Templates aus dem GitHub-Repository. Dieses Template stellt eingeschränkte REST-Operationen bereit (z.B. ticket-search, ticket-get, ticket-update, ticket-create) und leitet alle Anfragen sicher über den technischen Benutzer weiter.
• Runtime-Konfiguration: Zuletzt wird die OTAI Runtime selbst über Umgebungsvariablen und eine config.yml-Datei konfiguriert, um auf die OTOBO-URL und die Zugangsdaten des technischen Benutzers zu verweisen. So kann die Runtime Tickets abrufen, verarbeiten und aktualisieren.

Quellen:

• Open Ticket AI Runtime – Python-Automatisierung für OTOBO
• OTOBO Interface: Web Services & Integrations

Welche Vorteile bietet die OTAI Runtime gegenüber den eingebauten OTOBO-Automatisierungstools?

Während OTOBO leistungsfähige integrierte Tools wie den Generic Agent oder das Prozessmanagement bietet, stößt man bei komplexeren Automatisierungsanforderungen oft an deren Grenzen. Die Open Ticket AI Runtime schließt diese Lücke, indem sie eine flexible Python-basierte Engine bereitstellt. Ihre Vorteile umfassen:

• Komplexere Logik: Sie ermöglicht die Abbildung von komplexen, mehrschrittigen Workflows, die das Abrufen von Tickets, die Prüfung detaillierter Bedingungen, das Aufrufen externer APIs und das Aktualisieren von Feldern in einer sequenziellen oder bedingten Weise umfassen.
• Erweiterbarkeit: Als Open-Source-Python-Engine kann sie leicht erweitert und an spezifische Unternehmensbedürfnisse angepasst werden, indem eigene Pipes oder Integrationen entwickelt werden.
• On-Premise-Kontrolle: Die Runtime läuft auf der eigenen Infrastruktur, was volle Kontrolle über die Datenverarbeitung und die Einhaltung von Datenschutzrichtlinien gewährleistet, da Ticket-Inhalte das eigene Netzwerk nicht verlassen müssen.
• Flexibilität mit oder ohne KI: Sie ist nicht auf KI beschränkt und kann sowohl für klassische Automatisierung als auch für KI-gestützte Anwendungsfälle genutzt werden, je nachdem, wo ein Mehrwert gesehen wird.

Quellen:

• Open Ticket AI Runtime – Python-Automatisierung für OTOBO
• Open Ticket AI Runtime – Python Automation for OTOBO | OTOBO ...

Was sind "Pipes" in der Open Ticket AI Runtime und wie funktionieren sie?

Pipes sind das Kernkonzept der Open Ticket AI Runtime und stellen kleine, kombinierbare Verarbeitungseinheiten dar, die in YAML-Dateien verkettet werden, um Workflows zu definieren. Jede Pipe hat eine spezifische Aufgabe und arbeitet nach dem Prinzip "Wenn das, dann das".

• Kontextübergabe: Jede Pipe erhält einen gemeinsamen Kontext, der die Ergebnisse früherer Schritte enthält. Sie führt ihre definierte Aufgabe aus und erzeugt ein PipeResult, das wiederum dem Kontext für den nächsten Schritt hinzugefügt wird.
• Typen und Beispiele: Es gibt verschiedene Pipe-Typen für unterschiedliche Aufgaben:
  • IntervalTrigger: Löst eine Pipeline nur alle N Sekunden aus.
  • ExpressionPipe: Prüft Bedingungen oder führt einfache Logik aus, kann bei Fehlschlag die Pipeline stoppen (fail()).
  • FetchTicketsPipe: Lädt Tickets aus OTOBO basierend auf Suchkriterien.
  • UpdateTicketPipe: Aktualisiert Felder eines Tickets in OTOBO.
  • AddNotePipe: Fügt einem Ticket eine Notiz hinzu.
• Verkettung und bedingte Ausführung: Pipes können in CompositePipe für Mehrschritt-Workflows oder in SimpleSequentialRunner für bedingte Ausführung (on und run Schritte) kombiniert werden. Daten werden über Jinja2-Templates mit get_pipe_result('pipe_id', 'data_key') zwischen den Pipes ausgetauscht.

Quellen:

• Open Ticket AI Runtime – Python-Automatisierung für OTOBO

Wie gewährleistet die OTAI Runtime Datenschutz und On-Premise-Betrieb?

Die Open Ticket AI Runtime ist speziell für den On-Premise-Betrieb konzipiert, um maximale Kontrolle über Daten und Datenschutz zu gewährleisten. Dies ist ein entscheidender Unterschied zu vielen cloudbasierten Automatisierungstools:

• Lokale Ausführung: Die Runtime läuft als containerisierter Python-Dienst (z.B. mit Docker oder direkt über pip install) innerhalb der eigenen Infrastruktur. Das bedeutet, dass die gesamte Verarbeitung der Ticket-Inhalte und die Ausführung der Automatisierungslogik auf den eigenen Servern stattfindet.
• Kein Datenabfluss: Da die Verarbeitung On-Premise erfolgt, müssen sensible Ticket-Inhalte das lokale Netzwerk nicht verlassen. Dies ist besonders wichtig für Unternehmen mit strengen Datenschutzrichtlinien oder Compliance-Anforderungen, da es das Risiko von Datenlecks oder unautorisiertem Zugriff durch Dritte minimiert.
• Volle Kontrolle: Organisationen behalten die volle Kontrolle über die Konfiguration, die Sicherheit und die Skalierung der Runtime, da sie in ihrer eigenen Umgebung betrieben wird. Optional können auch lokale ML/LLM-Modelle integriert werden, ohne dass Daten an externe KI-Dienste gesendet werden müssen.

Quellen:

• Open Ticket AI Runtime – Python-Automatisierung für OTOBO
• OTAI for OTOBO – AI Attribute Classification - Open Ticket AI

Wie kann ich die Open Ticket AI Runtime installieren und starten?

Die Open Ticket AI Runtime bietet flexible Installationsmöglichkeiten, entweder über pip für Python-Umgebungen oder als Docker-Container für eine isolierte Bereitstellung:

Installation per pip:
Für eine direkte Installation in einer Python-Umgebung können Sie die notwendigen Pakete über pip installieren. Dies umfasst die Kern-Runtime sowie optionale Konnektoren wie den OTOBO/Znuny-Konnektor und lokale Hugging Face-Modelle:

pip install open-ticket-ai
pip install open-ticket-ai otai-otobo-znuny otai-hf-local

Starten mit Docker:
Für eine containerisierte Bereitstellung können Sie das offizielle Docker-Image verwenden. Zuerst ziehen Sie das Image und definieren dann einen Dienst in Ihrer docker-compose.yml (oder starten es direkt mit docker run):

1. Image ziehen:

docker pull openticketai/engine:latest
2. **`docker-compose.yml` Beispiel**: yaml
services:
open-ticket-ai:
image: openticketai/engine:latest
ports:
- "8080:8080"
environment:
OT_AI_CONFIG: /app/config.yml
volumes:
- ./config.yml:/app/config.yml:ro
```
Stellen Sie sicher, dass Ihre config.yml im selben Verzeichnis liegt wie Ihre docker-compose.yml und die notwendigen Konfigurationen für OTOBO und Ihre Pipelines enthält.

Quellen:

• Open Ticket AI Runtime – Python-Automatisierung für OTOBO
• Softoft-Orga/open-ticket-ai - GitHub