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

In diesem Leitfaden: Was die OTAI Runtime ist, wie das Pipe-System funktioniert und wie die Anbindung an OTOBO für individuelle Automatisierung — auch ohne KI — gelingt.

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 ein KI-Modell?

Nein. Die Runtime kann klassische Automatisierungen wie Routing, Feldaktualisierungen und zeitgesteuerte Jobs vollständig ohne KI ausführen.

Wie verbindet sich die Runtime mit OTOBO?

Sie nutzt typischerweise das OTOBO Generic Interface und dessen REST-Webservices mit einem eigenen technischen Benutzer.

Kann die Runtime On-Premise betrieben werden?

Ja. Sie läuft als Python-Dienst oder Container in der eigenen Infrastruktur.