In unserem Unternehmen ist JIRA inzwischen zu einem festen und wichtigen Bestandteil der täglichen Arbeit für viele unserer Mitarbeiter geworden.
Da ist es kaum verwunderlich, dass die Integration der JIRA-Plattform in Prozesse bzw. Abläufe auch mit anderen Plattformen und Tools an Bedeutung gewinnt. Konkret hatten wir vor einiger Zeit eine Anforderung, bei der es um einen Mix aus klassischen Genehmigungen und dem Ablauf verschiedener Projekttätigkeiten ging.
Außerdem werden im gesamten Ablauf weitere Daten herangezogen, die in einer klassischen SQL-Datenbank erfasst und gespeichert werden. Diese sind wiederum während der Genehmigung von Bedeutung und werden hierbei zum Teil auch ergänzt. Mit der Smartobjekt-Technik von K2 eigentlich kein Problem – daher war relativ klar, das zumindest dieser Teil mit einem K2-Workflow umgesetzt wird.
Nach abgeschlossener Genehmigung soll ein weiterer Prozess gestartet werden. Vom Ablauf ist auch dieser Teil des Gesamtprozesses klar in der Abfolge definiert. Allerdings ist es während diesen Ablaufs sehr wichtig, dass Informationen ausgetauscht werden, intensive Kommunikation sattfindet, welche auch dokumentiert werden müssen, kleinere Aufgaben müssen verteilt usw.
Alles Tätigkeiten, für die sich wiederum JIRA optimal eignen würde. Am Ende sind wir zu der Erkenntnis gekommen, dass nach der Genehmigung mit Hilfe eines K2-Workflows aus dem Workflow heraus entsprechende Epics und Stories auf JIRA angelegt werden sollen, die wiederum auf den Daten, die während des Genehmigungsworkflows verarbeitet wurden, basieren sollen.
Da JIRA eine sehr umfangreiche REST Api bietet, haben wir begonnen die API mit dem K2-REST ServiceBroker zu verbinden. Das funktioniert an sich auch sehr gut, wenngleich das Handling mit den Swaggerfiles durchaus als „lästig“ bezeichnet werden kann. Insbesondere wenn mit JIRA-Customfields gearbeitet werden soll.
Am Ende haben wir uns dazu entschieden, einen eigenen ServiceBroker für JIRA zu erstellen, der zunächst die für uns wichtigsten Methoden der JIRA-API bereitstellt. Der Servicebroker selbst kommuniziert ebenfalls mit der JIRA-Restapi. Einen großen Vorteil sahen wir darin, dass die Anpassung bzw. Erweiterung der Swaggerfiles bei neuen oder angepassten Customfields wegfiel. Mit Hilfe von Usecase bezogenen JSON-Objekten ist der Phantasie eigentlich keine Grenzen gesetzt.
Aktuell bietet dieser ServiceBroker folgende Möglichkeiten:
- Anlegen von Issues (die Inhalte werden über ein JSON-Objekt definiert – damit spielt es keine Rolle welche Felder befüllt werden sollen)
- Hinzufügen von Kommentaren zu bestehenden Issues
- Hinzufügen von Attachments zu bestehenden Issues – unterstütz werden aktuell folgende Möglichkeiten:
- K2-File Attachments
- Attachments über eine Weburl (wir verwenden dox42 zur Generierung von Dokumenten, die über einen REST-Service bietet, über diesen Aufruf können wir dynamisch generierte Dokumente direkt an einen Issue hängen. Das funktioniert natürlich auch mit jeder anderen Webadresse, die ein Dokument zurückgibt
- Pfad zu einer Datei (z.B. über einen Fileshare)
- Suche mit JQL
Mit diesen Methoden sind wir für die aktuellen Anforderungen zunächst sehr gut bedient.
Weitere Informationen werde ich in Kürze in einem weiteren Artikel liefern …
Parameter für die Serviceinstanz:
Aktuell verfügbare Methoden:
ArtikelbildBild von Markus Winkler auf Pixabay