Automatisierung in KIX - was geht da so?

[Torsten Thau]

Zur Automatisierung in KIX in Version 17 und niedriger lassen sich folgende Möglichkeiten zur Automatisierung nutzen:


Zusatzmodul Wartungsplaner (KIXMaintenancePlan)
Damit ist es möglich Tickets/Aufgaben autom. in Abhängigkeit vom Erreichen von Zeitpunkten oder dem Überschreiten von Schwellwerten (z.B. Beitriesbsstundenzähler) zu erstellen. Die Erledigung der Aufgaben inkrementiert auch optional die Fälligkeit der nächsten Aufgabenerstellung.


Zusatzmodul KIX Connect
Basierend auf Ereignissen an Tickets ("Ticket Events") werden entfernte Webschnittstellen aufgerufen. KIX tritt dabei als Requester des entfernten Webservices auf. Die Rückgabe eines solchen Requests ermöglicht wiederum Änderungen am Ticket.


Ticketbenachrichtigungen
Basierend auf Ereignissen an Tickets werden Benachrichtigungen an die Stakeholder des Tickets (meist, involvierte Agenten, Beabrieter, Verantwortlicherm Kundennutzer oder Werte aus Dynamischen Feldern) versendet.


Auto-Antworten
Auto-Antworten sind ein veralteter Mechanismus zum Bestätigen des Eingangs einer Nachricht. Die Funktion kann in Teilen auch von Ticketbenachrichtigungen abgebildet werden.


Generic Agents
"Generic Agents" erlauben die Konfiguration von zeit- oder ereignisgesteuerten Änderungen an den oder dem betroffenen Ticket selbst. Damit können sehr frei und flexibel Automatische Aktionen an Tickets konfiguriert werden. Generic Agents dienen dabei als Auslöser für KIXConnect-Aufrufe (z.B. "Polling" von Werten eines zugeordeten Tickets/Issues in einem entfernten Systems wie bspw. JIRA oder ServiceNow).


"Quick State"
Die Funktionalität Quick State ist seit KIX 17.6 enthalten und erlaubt das Ändern eines Tickets mit zwei Klicks. So kann bspw. eine Aktion "2 Tage warten" definiert werden. Diese erscheint am Ticket in einer Auswahlliste. Wird sie nun vom Bearbeiter ausgewählt, wird das Ticket in den Status "warten zur Erinnerung" in 2 Tagen versetzt. Die Konfiguration der Quick-States obliegt dabei den Admin-Nutzern. Mit sehr wenigen Klicks können so Tickets eingeplant, zurück gestellt oder mit Standardvorgehen abgearbeitet werden.


Prozesstickets - Transitions/TransitionActions
Tickets, die einem definiertem Prozess zugeordnet sind, können innerhalb eines Übergangs von einer Prozessaktivität zu einer anderen nahezu alle Ticketattribute geändert werden. Dabei kann auf rechtsseitige Platzhalter der Form <KIX_TICKET_DynamicField_SuperiorUserLogin>, <KIX_TICKET_DueDate> zurückgegriffen werden. Die Reihenfolge der Aktionen ist dabei essentiell und beeinflusst das Ergebnis einer Transaktion.


Workflows
"Ticketworkflows" sind eine Möglichkeit komplexe Aufgaben in Teilaufgaben aufzuteilen und diese abhängig voneinander beginnen zu lassen. Dabei werden Informationen jeweils nur von der "Hauptaufgabe" an die zugeordneten Teilaufgaben weitergegeben. Ein anderer Aspekt sind sog. Ticketstatus-Workflows welche im Grunde genommen eine Abfolge von Ticketstatus vorgeben die auf Basis von ACLs erzwungen werden. Ein Großteil der damit gelösten Anforderungen wird heute mit einer überschaubaren Prozesskonfiguration gelöst - auch das Erstellen von mehreren Untertickets.



Ausblick KIX Version 18
Viele der genannten Möglichkeiten aus KIX17 (und zuvor) überschneiden sich teilweise in ihrer Funktionalität, haben aber z.T. grundverschiedene Konfigurationen und Möglichkeiten. Dies ist z.g.T. in der Historie von KIX bedingt.

KIX18 wird versch. Ticketautomatisierungen zusammenführen. Generische Agenten werden durch einen Makromechanismus ersetzt, der wie generische Agenten durch Ereignisse oder Zeitpläne ausgelöst werden und auf einzelnen oder mehreren Objekten agieren kann. Initial werden damit Tickets unterstützt. Es ist geplant dieses auch auf Config Items ("Assets") u.a. Objekte auszuweiten. Damit ist die Grundlage für einen einfach zu verstehenden Wartungsplaner geschaffen.

Die auf einem Objekt durchzuführenden Aktionen sind in ihrer Reihenfolge konfigurierbar und unterstützen tlw. rechtsseitige Platzhalter. Dadurch wird große Flexibilität geschaffen. Die Mehrfachimplementierung von ähnlichen Funktionen (Generische Agenten, Prozessticket-Transaktionen, usw.) und damit potentielle Fehlerquellen und Seiteneffekte wie in KIX4OTRS und KIX wird damit vermieden. Die Konfiguration wird konsistenter und nachvollziehbarer.