© Fritz, Photocase.com

Das bekannteste freie Trouble-Ticket-System geizt zwar nicht mit Einstellmöglichkeiten; wenn aber bestimmte Routinearbeiten vor Ort sich als unnötig kompliziert erweisen, bleibt nur die Mühe, den Quellentext zu ändern. Die Scheu davor ist unbegründet – eine Anleitung.

Das “Open Ticket Request System” ([1], [2], [3]) ist mit mehr als 60 000 Installationen eines der beliebtesten Trouble-Ticket-Systeme ([4], [5]) und muss keinen Vergleich mit kommerzieller Software scheuen. Neben einer sehr aktiven Community ist auch professioneller Support bei OTRS zu erhalten. Die Software ist für den individuellen Einsatz im Unternehmen konzipiert. So bietet bereits die Grundinstallation mehr als 1000 über die Weboberfläche (Abbildung 1) oder per Konfigurationsdatei einstellbare Optionen zur individuellen Konfiguration an. Damit kann nicht nur das äußere Erscheinungsbild von OTRS angepasst, sondern vor allem auch das Verhalten während des Einstellens oder des Bearbeitens von Tickets beeinflusst werden.

Abbildung 1: OTRS besitzt bereits in der Grundinstallation zahlreiche Konfigurationsmöglichkeiten.

Das Rechenzentrum der Universität der Bundeswehr in München [6] setzt seit 2007 für die Betreuung von etwa 6000 Kunden OTRS ein. Insbesondere die Mitarbeiter des Service Desk, im OTRS-Sprachgebrauch “Agenten”, hatten nach Einführung des Systems die Vereinfachung von Routineaufgaben gefordert. Im Kern wünschten sich die Mitarbeiter einige Usability-Verbesserungen, wenn sie Tickets erstellen und bearbeiten. Oft waren die Funktionen in der Software bereits vorhanden, aber nur umständlich mit mehreren Arbeitsschritten erreichbar. Daher kam zur Lösung nur in Frage, direkt in den Quellcode einzugreifen.

Entweder eigene Packages schnüren …

Eigene OTRS-Anpassungen realisieren geht auf zwei Arten: Größere Entwicklungen bündelt man als so genanntes Package, das sich nach der Grundinstallation hinzufügen und auch wieder entfernen lässt. Es arbeitet autonom und erfordert am Basissystem keinerlei weitere Anpassungen durch den Administrator. Ein Package entwickeln erfordert aber profunde Kenntnisse im Aufbau von OTRS sowie dessen API – ein nicht zu unterschätzender Aufwand.

Wer den nicht leisten kann oder will, kann die OTRS AG mit der Programmierung beauftragen. Das Rechenzentrum der Universität der Bundeswehr hat diese Möglichkeit bereits genutzt und das damals nur sehr eingeschränkt nutzbare Volltext-Suchmodul von OTRS um reguläre Ausdrücke erweitern lassen. Die Erweiterung ist inzwischen in die Standarddistribution eingeflossen und steht somit auch der Community zur Verfügung. Dieser Weg eignet sich hervorragend für Firmen und Institutionen, ebenfalls einen Beitrag für OTRS zu leisten.

… oder die Quellen punktuell patchen

Die zweite Möglichkeit ist Open-Source-Software eigen: den Quellcode modifizieren. Dies setzt zwar ein gewisses Grundverständnis für den Aufbau und die Programmierung der Software voraus, allerdings nur punktuell. Zumeist reicht es, den bestehenden Code leicht anzupassen, selten sind größere Neuprogrammierungen erforderlich.

Einige Anpassungen von OTRS an die Gegebenheiten im Rechenzentrum der Universität der Bundeswehr erläutern die folgenden Seiten. Die Entwicklungsarbeiten fallen überraschend einfach aus und erzielen trotzdem eine deutliche Erleichterung beim täglichen Umgang mit dem Ticketsystem. OTRS-Admins werden anhand der Beispiele sicherlich auch ein paar Möglichkeiten für die eigene Umgebung erkennen.

Es sollte selbstverständlich sein, Entwicklung und Test solcher Anpassungen nicht im Produktivsystem durchzuführen, sondern auf einem getrennten Testsystem. Zum Handwerkszeug: OTRS ist in Perl programmiert. Es empfiehlt sich zumindest ein Editor mit Syntax-Highlighting für Perl. Liebhabern integrierter Entwicklungsumgebungen sei Eclipse (mit Perl-Erweiterung [7]) ans Herz gelegt, das zudem weitere nützliche Funktionen wie Versionsverwaltung mitbringt (siehe Abbildung 2).

Abbildung 2: Bereit zum Ändern: OTRS-Quellcode, geladen in einer Eclipse-Umgebung mit Perl-Integration.

Wichtig bei jeder auch noch so kleinen individuellen Änderung: Da diese nicht Bestandteil der offiziellen Distribution ist, muss der Admin sie nach jedem OTRS-Update und -Upgrade manuell nachziehen. Die etablierten Tools in der Software-Entwicklung machen das Einpflegen aber leicht. Ein Verfahren stellt dieser Artikel auch vor.

Standardverhalten von OTRS ändern

Der Service Desk des Uni-Rechenzentrums nutzt zur Überwachung von Tickets die Standardansicht »Meine Queues« von OTRS, die alle offenen und nicht in aktiver Bearbeitung befindlichen (daher gesperrten) Tickets anzeigt. Dabei erwies es sich in der täglichen Praxis als erforderlich, bei der expliziten Zuweisung an einen weiteren Bearbeiter das zugrunde liegende Ticket nicht zu sperren, da bei diesem Vorgang das Ticket aus der Standardansicht des zweiten Bearbeiters verschwindet, ohne dass aus Sicht des Kunden das Ticket explizit bearbeitet worden wäre.

Das geschilderte Verhalten zu ändern, geht nur direkt im Quellcode. Die Suche nach dem dafür verantwortlichen OTRS-Modul gestaltet sich sehr einfach. OTRS bildet das für die Aktion verantwortliche Modul stets in der URL mit ab. So zeigt die URL beim Ändern des Besitzers eines Tickets »Action=AgentTicketOwner« an. Der dafür verantwortliche Quellcode befindet sich in »OTRS-Pfad/Kernel/Modules/AgentTicketOwner.pm« und ist damit schnell identifiziert (Listing 1). Die erforderliche Anpassung nebst Kommentar ist schnell gemacht (Listing 2).

Es ist sehr empfehlenswert, nicht nur die Art der Änderung zu kommentieren, sondern auch durch eindeutige Tags (hier »custom unibwm«) hervorzuheben. Dadurch lassen sich bei Updates und – wichtiger noch – Upgrades die modifizierten Stellen einfach identifizieren.

01 if ($Self->{Config}->{Owner}) {
02      if ($GetParam{NewOwnerType} eq 'Old' && $GetParam{OldOwnerID}) {
03         $Self->{TicketObject}->LockSet(
04            TicketID => $Self->{TicketID},
05            Lock => 'lock',
06            UserID => $Self->{UserID},
07         );

01 # Wenn neuer Besitzer gesetzt, Ticket immer entsperren!
02 # custom unibwm (lock->unlock)
03 if ($Self->{Config}->{Owner}) {
04      if ($GetParam{NewOwnerType} eq 'Old' && $GetParam{OldOwnerID}) {
05         $Self->{TicketObject}->LockSet(
06            TicketID => $Self->{TicketID},
07            Lock => 'unlock',
08            UserID => $Self->{UserID},
09         );

Die Lösung: Herrenlose Tickets

Auf die gleiche Weise hat das Uni-Rechenzentrum ein anderes nicht passendes Standardverhalten geändert: OTRS belegt auch frisch erzeugte Tickets sofort mit einer Sperre. Wenn nämlich ein Service-Desk-Mitarbeiter telefonisch oder persönlich eine Störung entgegennimmt, wird dieser automatisch zum Bearbeiter des Tickets, statt des für die Aufgabe eigentlich vorgesehenen Agenten. Die ersonnene Lösung sieht vor, zunächst keinen Agenten als Besitzer zu deklarieren. Dies passiert in OTRS durch Setzen des Besitzers auf »root« (id=1) im Modul »AgentTicketPhone« (Listing 3).

Das OTRS-Team im Rechenzentrum hat im Zuge der beiden Quelltext-Änderungen gleich einen lästigen Bug im FAQ-Modul gefixt: Explizite »<br>«-Zeilenumbrüche auch innerhalb von »<href>«-Tags verhinderten die Nutzung von längeren Hypertext-Links in FAQ-Artikeln. Der eingereichte Bugzilla-Report schlummerte unbeachtet vor sich hin. Lediglich eine eingefügte Quellcodezeile in »OTRS-PfadKernel/Modules/FAQ.pm« löst das Problem (Listing 4).

01 # custom unibwm: Owner bei neuem Ticket ist stets root (id=1)
02 # OwnerID => $Self->{UserID},
03 OwnerID => '1',

01 $ItemData{$Key} = $Text;
02 # custom unibwm
03 # protect against line-breaks within anchor-tags
04 $ItemData{$Key} =~ s/<br>href/ href/g;

Anpassungen in der Benutzeroberfläche

Während die Beispiele eben direkt in das Verhalten von OTRS eingreifen, verbessern angepasste Oberflächen-Funktionen die Benutzerinteraktion erheblich. Insbesondere die Agenten profitieren von der am lokalen Bedarf ausgerichteten Weboberfläche. Dabei lässt sich die Eigenschaft von OTRS nutzen, alle Informationen zu einem Bearbeitungsvorgang über das Webinterface wahlweise mit »POST«- oder »GET«-Variablen bereitzustellen. Da OTRS alle Aktionen über ein sehr fein granulares Rechtekonzept absichert, erzeugt dies auch kein konkretes Sicherheitsproblem. Das System prüft jede Aktion vorab – das heißt innerhalb eines jeden aufgerufenen Moduls – auf Zulässigkeit.

Ein Beispiel für eine veränderte Oberfläche ergab sich aus einer weiteren Anforderung im Service Desk: Die Mitarbeiter müssen oft ihre Zuständigkeit (als Besitzer oder Verantwortlicher) für ein Ticket einfacher beenden können als out of the Box vorgesehen. Technisch erfolgt dies durch Rückgabe der Zuständigkeit an das System (OTRS-Root). Als Frontend ist dafür ein Formular vorgesehen, das den neuen Besitzer sowie Betreff und Beschreibung abfragt. Für Agenten, die es oft ausfüllen und absenden müssen, ist das eine lästige und fehlerträchtige Angelegenheit.

Die OTRS-Admins haben die Oberfläche nun so angepasst, dass das Gleiche mit einem Mausklick erledigt ist. Der Vorgang lässt sich nämlich vollständig über eine URL abwickeln. Diese URL ist durch Analyse des bereitgestellten Dialogs (eines HTML-Formulars) rasch bestimmt, die entsprechenden Formularattribute sind dann in einen GET-Request schnell übernommen. Dazu lässt sich entweder der HTML-Quellcode direkt untersuchen oder, etwas komfortabler, ein Browser-Plugin zu Rate ziehen, beispielsweise Web Developer für den Firefox (Abbildung 3). Der gefundene Request, um bei einem vorhandenen Ticket den Besitzer auf »root« zu setzen, sieht so aus:

https://otrsserver/otrs/index.pl?Action=AgentTicketOwner&Subaction=Store&TicketID=11948&NewOwnerID=1&Subject=Freigabe%20Besitzer&ArticleTypeID=9&Body=Besitzer%20zurueckgesetzt%20von%20stefan%20auf%20root

Die Attribute »Subject« und »Body« sind frei wählbar. Die »TicketID« bezieht sich auf das aktuelle Ticket, Root hat immer die ID 1. Die URL lässt sich zum Testen direkt im Browser eingeben.

Abbildung 3: Das Firefox-Plugin Web Developer hilft die URL-Parameter im OTRS-Formular zu finden.

Frei konfigurierbare Templates

Nun wäre es sicher alles andere als komfortabel, immer eine derart angepasste URL eintippen zu müssen. Da das OTRS-GUI sowieso im Browser läuft, bietet es sich an, einen entsprechenden Link in die Weboberfläche einzubetten. OTRS definiert Oberflächen über spezielle Templates in einer eigenen DTL-Syntax (Dynamic Template Language). Die frei konfigurierbaren Templates liegen als Dateien unter »OTRS-Pfad/Kernel/Output/HTML/Themes«, wobei »Themes« beliebig benannte Ordner sind.

Die OTRS-Standardtemplates finden sich im Ordner »Standard«. Nun steht der Entwickler vor der Grundsatzentscheidung, wo er seine Modifikationen unterbringt. OTRS empfiehlt ein eigenes Template anzulegen, da jedes Update die Standardtemplates potenziell überschreibt. Allerdings bringt das Verfahren auch einen gravierenden Nachteil: Wenn ein OTRS-Update auch die Standardtemplates verbessert, beispielsweise um neue Funktionen, muss der Admin diese stets in den eigenen Templates nachziehen.

Aus diesem Grund scheint es sinnvoll, entgegen der Herstellerempfehlung direkt die Standardtemplates zu modifizieren. Da die gleich besprochenen Anpassungen auch das Standardverhalten von OTRS in den Perl-Modulen betreffen, die man nach Releasewechseln sowieso immer nachziehen muss, hat das Uni-Rechenzentrum den Weg modifizierter Standardtemplates gewählt, alle Modifikationen kamen folglich in den Ordner »OTRS-Pfad/Kernel/Output/HTML/Standard«.

Übergabe per Variable

Nachdem die URL zum Ändern des Besitzers auf OTRS-Root bekannt ist, muss sie noch in der Oberfläche untergebracht werden. Dafür bietet sich die Ticket-Ansicht an. Sinnvollerweise tragen die beteiligten Perl-Module und die Templates zur Oberfläche die gleichen Namen, hier »AgentTicketZoom« und »AgentTicketZoom.dtl«. Das Ergebnis ist in Abbildung 4 zu sehen, der in der Datei »AgentTicketZoom.dtl« hinterlegte DTL-Code in Listing 5. Es geht tatsächlich nur darum, die Zeile 3 einzufügen, Perl-Code zu ändern ist nicht erforderlich.

Abbildung 4: Listing 5 erweitert die Weboberfläche um den Link »Frei«.

DTL-Dateien in OTRS besitzen die Möglichkeit, auf relevante Informationen zum Ticket über Variablen zuzugreifen. Listing 5 nutzt beispielsweise zum Zugriff auf die Ticketdaten die Ticket-ID (»$LQData{“TicketID”}«) und für den aktuellen Agenten dessen Kennung (»$QData{“UserLogin”}«). Es legt auch eine interne Notiz (»ArticleTypeID=9«) für diesen Vorgang an.

Die Anpassung erfolgt für alle angezeigten Tickets unabhängig von derem Inhalt. Zum Implementieren reichen meist die vorhandenen Quellen als Beispiel und Vorlage. Wenn nicht, dann hilft die detaillierte Beschreibung der Templates und der Variablen in der umfangreichen Dokumentation unter [3].

01 $QData{"UserLogin","18"} ($Quote{"$Data{"UserFirstname"} $Data{"UserLastname"}","18"})
02 <!-- custom unibwm -->
03 <a href=/otrs/index.pl?Action=AgentTicketOwner&Subaction=Store&TicketID=$LQData{"TicketID"}&NewOwnerID=1&Subject=Freigabe%20Besitzer&ArticleTypeID=9&Body=Besitzer%20zurueckgesetzt%20von%20$QData{"UserLogin"}%20auf%20root>Frei</a>

Zugriff auf den Ticketinhalt

Alle bisherigen Anpassungen waren für jedes Tickets nutzbar, unabhängig vom Inhalt. Eine sehr beliebte Möglichkeit Ticketinhalt-abhängige Funktionen zu implementieren, führt zu OTRS-Freitextfeldern. Damit lassen sich lokale Besonderheiten berücksichtigen und eigene Erweiterungen entwickeln.

Das Rechenzentrum benutzt diese Möglichkeit beispielsweise bei sicherheitsrelevanten Vorfällen im Datennetz, wo die IP-Adresse des potenziellen Verursachers bekannt ist. Der Aufruf eines externen Perl-Skripts fragt eine Datenbank ab, in welcher die Zuständigkeiten für Netzbereiche hinterlegt sind. Dadurch erweitert sich das Ticket automatisch um die Daten des zuständigen Netzbetreuers.

Abbildung 5: Der Aufruf eines externen Perl-Testskripts liefert prompt das zugehörige Ergebnis »Test-Resultat«.

Das folgende Beispiel zeigt das Prinzip des Aufrufs eines eigenen, externen Perl-Skripts. Das Skript ist nur dann aufrufbar, wenn das erste Freitextfeld eines Tickets den Schlüssel »IP« aufweist (Abbildung 5). Der entsprechende Link zum Skript wird in »AgentTicketZoom« eingebaut, indem man den bereits für Freitextfelder vorhandenen Code anpasst (Listing 6). Generierung und Rückgabe des Resultats übernimmt das eigene Skript »test.pl«, das sein Ergebnis als »GET«-Request formuliert und nach Bestätigung des Nutzers zurückliefert (Listing 7).

Das Skript bekommt seine Parameter in der URL übergeben. Der Parameter »TicketID« ist erforderlich, damit das Skript seine Ergebnisse diesem Ticket wieder hinzufügen kann. Dazu dient das OTRS-Modul »AgentTicketFreeText«. Das Beispiel bettet das Ergebnis als neues Freitextfeld »Ergebnis« ein. Möglich wäre auch, einen neuen Artikel zum Ticket hinzuzufügen oder andere beliebig umfangreiche Skripte, die sich außerhalb von OTRS entwickeln und betreiben lassen.

01 <dtl if ($Data{"TicketFreeKey1"} eq "IP") { $Data{"TicketFreeString1"} = "<tr valign="top"><td><b>$QData{"TicketFreeKey1","25"}:</b></td><td><div title="$QData{"TicketFreeText1"}">$QData{"TicketFreeText1"}<a href="/otrs/tools/test.pl?IP=$LQData"TicketFreeText1"}&TicketID=$LQData{"TicketID"}"> (Skript)</a></div></td></tr>"; }>

01 #!/usr/bin/perl -w
02 
03 # Nutzung des Perl-CGI-Interfaces
04 use CGI qw/:standard/;
05 $query = new CGI;
06 
07 print   $query->header(),
08         $query->start_html(-title=>'Test-Skript zur OTRS-Anbindung');
09 
10 # Sicherheitsabfrage (Skript darf nur aus OTRS heraus aufgerufen werden)
11 if(!( $ENV{HTTP_REFERER} =~ /Action=AgentTicketZoom/))
12 {
13         print $query->h3("Aufruf des Skripts nicht gestattet!");
14         exit;
15 }
16 
17 # Parameter aus der URL
18 my $ip = $query->param('IP');
19 my $ticketID = $query->param('TicketID');
20 
21 my $result = "Test-Resultat";
22 
23 # Inhalt der Webseite
24 print   $query->h1("Testskript zu IP=$ip");
25 print p(
26         a({href=>$ENV{HTTP_REFERER}},"Zurück zum Ticket")
27         ,"--"
28         ,"Ergebnis: $result"
29         );
30 
31 if ($result)
32 {
33         # Rückgabe des Ergebnisses als Freitextfeld 4
34         print '<a href="/otrs/index.pl?Action=AgentTicketFreeText&Subaction=Store&TicketID='.$ticketID.'&TicketFreeKey4=Ergebnis&TicketFreeText4='.$result.'">Ergebnis übernehmen</a><br>';
35 }
36 
37 print $query->end_html();

Änderungen verwalten

Alle am OTRS-Quellcode vorgenommenen Änderungen muss der Admin so verwalten, dass er sie bei Releasewechseln einfach nachziehen kann. Die neue Release wird beim Einspielen der OTRS-Quellen zunächst alle eigenen Änderungen überschreiben. Das Nachziehen in die neuen Quellen lässt sich recht einfach mit Tools zum Textvergleich (»diff«) bewerkstelligen, die sowieso Bestandteil jeder Versionsverwaltung sind. Das Rechenzentrum setzt Subversion [8] ein und hat alle eigenen Änderungen an und Skripte für OTRS dieser Versionsverwaltung übertragen.

Subversion als das Mittel der Wahl

Nach jedem Releasewechsel ermittelt das integrierte Diff die Unterschiede zwischen der neuen Basisversion und den alten, angepassten Quellen im Repository. Dass viele gängige grafische Entwicklungswerkzeuge Subversion unterstützen, nimmt der Migration einen Großteil ihrer Komplexität. Die oben angesprochenen Tags erleichtern die Arbeit zusätzlich. Abbildung 6 zeigt als Beispiel Eclipse mit integriertem Subclipse-Modul [9], das gerade die Änderungen im OTRS-Modul »AgentTicketOwner« ermittelt. Zumeist reicht ein Mausklick, um sie zu übernehmen.

Generell ist sehr zu empfehlen, die einzelnen Revisionen der Modifikationen in der Versionsverwaltung analog zu den OTRS-Revisionen mitzuführen. So bleiben alle Änderungen revisionssicher aufbewahrt und alle OTRS-Versionsstände bei Test- und Produktionssystemen parallel einsetzbar. Abbildung 7 zeigt eine sich daraus ergebene Repository-Struktur, die der Ordnerstruktur von OTRS folgt.

Abbildung 6: Die Eclipse-Erweiterung Subclipse vergleicht in der IDE die alte, modifizierte Version mit dem neuen OTRS-Quellcode.

Abbildung 7: Repository-Struktur in Subversion, die alle Anpassungen und alle OTRS-Releases an der Bundeswehr-Uni verwaltet.

Zusammenfassung

Open-Source-Software in Unternehmen ist auch daher eine Erfolgsgeschichte, weil dank des Quelltextes unternehmensspezifische Anpassungen entweder im Auftrag oder durch eigene Entwickler möglich sind. Ein gutes Beispiel dafür gibt das beliebte Open-Source-Produkt OTRS ab. Obwohl die Grundinstallation bereits eine Vielzahl von Konfigurationsparametern aufweist, sind dennoch in einigen Fällen Anpassungen des Quellcode empfehlenswert.

Durch Werkzeuge zur Versionsverwaltung sind die Anpassungen auch über Revisionen der Software leicht zu pflegen. Der Beitrag hat einige Modifikationen gezeigt, die das Rechenzentrum der Universität der Bundeswehr in München anhand von Anforderungen aus der eigenen täglichen Praxis umgesetzt hat. Die Beispiele versuchen mit möglichst geringem Aufwand für Entwicklung und Pflege einen größtmöglichen Effekt zu erzielen. Sie eignen sich bestens als Handlungsschablone für jeden OTRS-Admin, der gern lokale Anpassungen zur Effizienzsteigerung für seine Agenten vornehmen möchte, denn prinzipiell sind alle OTRS-Formulare automatisiert aufrufbar, mit Übergabe der Formularinformationen. (jk)