Wir haben den Connector: API-Erweiterungen für OTOBO und Znuny

OTOBO und Znuny bieten über das Generic Interface bereits Ticket anlegen, lesen, suchen und aktualisieren. Das reicht, um Tickets zu bewegen — nicht aber für eine KI-Runtime oder ein Studio, das Queues, Status, Prioritäten, Services, Typen, Dynamische Felder und FAQ synchronisieren muss, bevor es klassifizieren oder routen kann.

Deshalb liefern wir den Open Ticket AI Connector: ein Paket, das einen REST-Webservice namens OpenTicketAI einrichtet und zusätzliche Generic-Interface-Operationen über die eingebaute Ticket-API legt.

Der Connector ist die Anbindung von Open Ticket AI an OTOBO 11 und Znuny on-premise. Kein SaaS-Umweg, kein zweites Ticket-Archiv — das Ticketsystem bleibt die Quelle der Wahrheit.

Was das Paket installiert

Bei der Installation passieren zwei Dinge:

1. Es wird ein eingeschränkter API-Agent angelegt, den nur Open Ticket AI nutzt (OTOBO-Standardlogin otai-webservice; Znuny-Standard open_ticket_ai).
2. Es wird ein Generic-Interface-REST-Webservice OpenTicketAI importiert, der auf diesen Benutzer beschränkt ist — andere Agenten können ihn nicht aufrufen.

Zusätzlich existiert die Gruppe ai-agent. FAQ-Kategorien, die die KI durchsuchen darf, müssen dieser Gruppe (und users für menschliche Agenten) zugeordnet sein.

Ticket-Operationen plus Katalog-Erweiterungen

Der Webservice behält die bekannten Ticket-Routen und ergänzt Katalog-Operationen als Module TicketAICatalog::*:

Basis-URL:

<host>/<otobo|znuny>/nph-genericinterface.pl/Webservice/OpenTicketAI/<route>

Authentifizierung per HTTP Basic Auth mit den Zugangsdaten des API-Agenten.

So sieht eine Erweiterung im Code aus

Jede Katalog-Operation ist ein Generic-Interface-Modul. Nach der Authentifizierung liest sie native OTOBO-/Znuny-Objekte und liefert eine stabile JSON-Liste — hier Queues:

package Kernel::GenericInterface::Operation::TicketAICatalog::QueueList;

use parent qw(Kernel::GenericInterface::Operation::TicketAICatalog::Base);

sub Run {
    my ( $Self, %Param ) = @_;

    my ( $UserID, $Error ) = $Self->_AuthOrError(%Param);
    return $Error if $Error;

    my $QueueObject = $Kernel::OM->Get('Kernel::System::Queue');
    my %Queues      = $QueueObject->QueueList( Valid => 0 );

    my @Items;
    for my $QueueID ( sort { $a <=> $b } keys %Queues ) {
        my %Queue = $QueueObject->QueueGet( ID => $QueueID );
        next if !%Queue;
        push @Items, {
            ID      => $QueueID + 0,
            Name    => $Queue{Name} // $Queues{$QueueID},
            Comment => $Queue{Comment} // '',
            Valid   => ( ( $Queue{ValidID} // 1 ) == 1 ) ? 1 : 0,
        };
    }

    return {
        Success => 1,
        Data    => { Item => \@Items },
    };
}

Dasselbe Muster gilt für Status, Prioritäten, Services, Typen und Dynamische Felder. DynamicFieldCreate legt ein Ticket-Dropdown an oder aktualisiert es und schaltet es auf den üblichen Agenten-Masken frei. FAQSearch sucht kundenrelevante FAQ-Artikel und bricht weich ab, wenn das FAQ-Paket fehlt.

Die Operationen sind in der Systemkonfiguration als Generic-Interface-Module registriert, etwa TicketAICatalog::QueueList und TicketAICatalog::FAQSearch.

Warum das für KI am Helpdesk zählt

Ohne Katalog-Endpunkte kann eine externe Engine Queue-Namen nur aus dem Tickettext raten. Mit dem Connector synchronisieren Studio und Runtime den lebenden Katalog, mappen Vorhersagen auf echte IDs und schreiben über TicketUpdate zurück — inklusive Dynamischer Felder.

Verwandte Pakete auf demselben Stack:

• OTAIStudio — SSO aus der Agentenoberfläche ins Open Ticket AI Studio (benötigt diesen Connector).
• Optionale Agenten-Ansichten für Attribute und menschliche Prüfung von KI-Vorschlägen.

OTOBO und Znuny

Die Generic-Interface-Operationsnamen sind auf beiden Systemen gleich. OTOBO liest das API-Passwort aus der Prozessumgebung (OTAI_TICKETSYSTEM_PASSWORD); Znuny erwartet vor der Installation SysConfig (OpenTicketAIConnector::AgentPassword).

Nächster Schritt

Wenn Sie OTOBO oder Znuny betreiben und On-Prem-Ticket-KI mit einer sauberen API wollen — nicht mit einem fragilen UI-Scraping —, ist dieser Connector die Integrationsschicht, die wir in Produktion nutzen.

Mehr zum Produkt auf openticketai.com oder Kontakt aufnehmen.