JiraPackage - Felder dynamisch füllen
Mit der JiraPackage-Erweiterung von catworkx ist es möglich, OTRS-Tickets nach Jira zu übertragen und umgekehrt. Über die grundsätzlichen Funktionen haben ich schon vor einiger Zeit gebloggt.
Heute zeige ich, wie man das Feldmapping so erweitern kann, dass Werte dynamisch berechnet werden. Als Beispiel soll es ein Feld Genehmigt am
in Jira geben,
in dem gespeichert wird, wann ein Feature freigegeben wurde. Aus OTRS heraus soll dieses Feld mit dem aktuellen Datum gefüllt werden.
Schritt 1: Erstellen des Benutzerdefinierten Feldes
Es wird ein Datumsfeld verwendet, die Uhrzeit soll hier keine Rolle spielen.
Noch beschreiben was in dem Feld gespeichert wird ...
... und für die entprechenden Seiten aktivieren.
Schritt 2: Erstellen des Perl-Moduls
Für dieses Beispiel reicht ein kleines Perl-Modul, das nur die Subroutine Today zur Verfügung stellt.
Hier benötigt die Subroutine keine Übergabeparameter. Vom Hauptmodul werden aber folgende Parameter übergeben:
- Objekt von Kernel::System::TicketJira
- Das Mapping
- Artikelinformationen
Damit kann alles gemacht werden was man möchte.
Es ist natürlich von Vorteil, wenn man die API der OTRS-Klassen kennt. Denn dann kann man Informationen zu verknüpften Objekten (z.B. Tickets, FAQ, Config Items, ...) zu dem Ticket herausfinden oder einfach die Hilfsfunktionen aus verschiedenen Klassen nutzen. Man kann aber auch andere Perl-Module nutzen oder andere Programme aufrufen. Was in der Subroutine gemacht wird ist im Prinzip egal - man muss nur darauf achten, welches Format Jira haben möchte.
Im Fall von Datumsfeldern muss das Datum in dem Format YYYY-MM-ddThh::mm::ss.0+Offset angegeben werden. Bei anderen Feldern müsste man eine Hashreferenz zurückgeben. Da hilft
dann aber auch die Fehlermeldung weiter, die Jira zurückliefert wenn man testweise ein Ticket von OTRS nach Jira überträgt.
Schritt 3: Anpassen des Feldmappings
Im Schlüssel ist das zu finden, was auf OTRS-Seite passieren soll: call:Kernel::System::JiraMapping,Today
Der Aufbau ist call:<Modul>,<Funktion>.
call ist das Schlüsselwort, dass eine Funktion aus einem Modul aufgerufen werden soll. Das Kernel::System::JiraMappingist
der Paketname des Moduls und Today ist der Funktionsname.
Das war's.
Wenn jetzt das Ticket aus OTRS heraus an Jira übertragen wird, wird der Inhalt für das Benutzerdefinierte Feld berechnet:
Sollten Sie noch Fragen zu dem Modul haben, nehmen Sie am besten Kontakt zu catworkx auf.
Permalink: /2018-02-14-jirapackage-function-call
JIRA-Connector der OTRS-AG vs. JIRAPackage von catWorkX
Mit OTRS5s hat die OTRS AG auch einen JIRA-Connector veröffentlicht. Schon seit einigen Jahren bietet die catWorkX GmbH ein JIRAPackage an. Das Gesamtpaket von catWorkX besteht aus einem JIRA-Addon und einen OTRS-Addon. Ich kenne den JIRA-Connector der OTRS AG nur aus den Ankündigungen und dem Blogpost, möchte hier an dieser Stelle aber trotzdem auf beide Pakete eingehen.
Der JIRA-Connector setzt auf das GenericInterface von OTRS auf. Man benötigt zwei Erweiterungen, die es nur für Kunden der Business-Lösung gibt. Sind die Abhängigkeiten installiert, muss der Webservice eingerichtet werden. Anschließend müssen noch Mappings konfiguriert werden. Der oben verlinkte Blogpost beschreibt die notwendigen Schritte ausführlicher.
Durch Trigger - wie Änderung des Ticketstatus, Neues Ticket oder neuer Artikel - wird die Kommunikation mit JIRA ausgelöst und die Informationen werden von OTRS an JIRA übertragen.
Das JIRAPackage implementiert die Kommunikation mit JIRA in eigenen Modulen. Das Gesamtpaket bietet im Gegensatz zur Lösung der OTRS AG die Kommunikation in beide Richtungen: Von OTRS nach JIRA und von JIRA nach OTRS. So bleiben beide Systeme auf dem aktuellen Stand. Aber wo liegen die Unterschiede in der Bedienung? Auch beim JIRAPackage kann der Informationsaustausch durch Trigger wie neue Tickets, neue Artikel, Statusänderung etc. angestoßen werden.
Möchte man aber vermeiden dass automatisch JIRA-Issues erzeugt werden, kann man das abschalten und der Agent muss aktiv das Erstellen des JIRA-Issues anstoßen. Dazu gibt es zwei Wege:
- Wenn der Vorgang in JIRA schon ab dem ersten Artikel gelten soll, kann der Agent im Ticketmenü auf OTRS -> JIRA klicken. Dann wird der erste Artikel als Basis genommen und der Vorgang dafür erstellt. Es ist auch konfigurierbar dass neben dem ersten Artikel auch alle anderen Artikel an das JIRA übertragen werden. Das ist dann hilfreich wenn sich erst im Laufe der Kommunikation mit dem Kunden rausstellt, dass das Ticket ein Thema für die Entwickler ist.
- Wenn ein Ticket schon viele Artikel hat und bspw. der sechste Artikel die Infos für einen JIRA-Vorgang enthält. Dann kann der Agent im Artikelmenü auf OTRS -> JIRA klicken. Dann werden die Artikel 1-5 nicht an das JIRA übertragen.
Sollen nur für ein einziges Projekt Vorgänge - mit einem bestimmten Typ - und für einen JIRA-Benutzer erstellt werden, kann der Dialog auch ausgeschaltet werden.
Kommen wir zur Konfiguration: Nach der Installation kann man im Adminbereich einfach über einen Wizard die JIRA-Integration einrichten. Es werden Dinge wie URL zu JIRA, Authentifizierungsdaten abgefragt und auch die Zuordnung von JIRA-Feldern zu OTRS-Feldern wird dort vorgenommen.
Für erfahrenere Admins kann das alles auch in der SysConfig direkt eingetragen werden. Dann kann man beim Mapping sogar dafür sorgen, dass Benutzerdefinierte Funktionen ausgeführt werden (z.B. damit Inhalte verschlüsselt übertragen werden).
Disclaimer: An der Entwicklung von JIRAPackage bin ich direkt beteiligt.
Wenn Sie Interesse am JIRAPackage haben, kontaktieren Sie doch bitte catWorkX.
Sie können auch über den JIRA Marketplace das Paket zur OTRS-Integration in JIRA in Ihrem JIRA installieren und das OTRS-Paket können Sie bei catWorkX herunterladen und dann erstmal testen.
Permalink: /2016-12-15-otrs-jira-vs-catworkx-jira