Effiziente Fehlerberichte sind entscheidend, um die Qualität und Zuverlässigkeit von Berichten zu gewährleisten. Da viele unserer Kunden Jira als Ticket-Tool verwenden, kam irgendwann die Idee auf, Jira Tickets direkt aus jedem SAC Bericht erstellen zu können.
Dieser Beitrag stellt ein eigenentwickeltes „Composite“ in der SAP Analytics Cloud (SAC) vor, das ebendiese Erstellung von Jira-Tickets direkt aus SAC-Berichten vereinfacht. Der grundsätzliche Ansatz hierzu kann auch in anderen Tools, wie Web Intelligence (WebI) realisiert werden.
Die wichtigsten Punkte auf einen Blick :
-
Was ist ein Jira Ticket-Composite?
Es ist eine Möglichkeit der direkten Erstellung von Jira-Tickets aus einem SAC-Bericht.
-
Wofür wird das Jira Ticket verwendet?
Ein Jira-Ticket in der SAP Analytics Cloud (SAC) wird in der Regel erstellt, um Aufgaben, Probleme oder Änderungsanforderungen im Zusammenhang mit SAC-Projekten zu verwalten. Jira dient hierbei als Projektmanagement- und Issue-Tracking-Tool, um die Zusammenarbeit zwischen Teams zu erleichtern.
-
Warum ist das Jira Ticket-Composite so relevant?
Dies erleichtert die nahtlose Integration von Fehlerberichten und anderen Aufgaben in den bestehenden Arbeitsablauf, ohne die SAC-Umgebung verlassen zu müssen. Durch die Verwendung spezieller Links können Benutzer direkt aus der SAC heraus neue Jira-Tickets mit vorausgefüllten Feldern erstellen, was den Prozess effizienter und benutzerfreundlicher gestaltet.
Hintergrund: Erstellung von Jira-Tickets über direkte Links
Vergleich: Direktlink-Ansatz vs. Jira REST API
Jira bietet – neben der klassischen Weboberfläche – zwei Möglichkeiten zur (halb-)automatisierten Erstellung neuer Tickets: über direkte Links und über ein REST API. Die Wahl des besten Ansatzes hängt vom Anwendungsfall und der technischen Umgebung ab.
Ansatz | Vorteile | Nachteile |
Direktlink |
|
|
REST API |
|
|
Der Direct Link-Ansatz wurde aufgrund seiner Einfachheit, der leichten Implementierung und der Kompatibilität mit Jira-Instanzen sowohl on Premise als auch in der Cloud gewählt. Zwar muss der Benutzer mit einem Jira-Fenster interagieren, doch bietet dies auch Vorteile, da zusätzliche Felder bei Bedarf manuell ausgefüllt werden können. Darüber hinaus wird durch die Vermeidung der Komplexität von REST-API-Vorgängen sichergestellt, dass die Lösung für SAC-Entwickler zugänglich und wartbar bleibt.
Details zum Direktlink-Ansatz
Die Erstellung eines Jira-Ticket via spezieller Links ist unkompliziert und basiert auf der Anleitung “How to create issues using direct HTML links in Jira Server”. Der generierte Link hat folgende Struktur:
[Jira-Basis-URL]/secure/CreateIssueDetails!init.jspa?Feld1=Wert1&Feld2=Wert2
Beispiel:
=Fehlerbeschreibung&description=Beispielbeschreibung
Wenn es für ein Feld mehrere Werte gibt, dann kann der Parameter mehrfach ergänzt werden. Am Beispiel des Parameters „Label“ würde das z. B. wie folgt aussehen:
=Fehlerbeschreibung&description=Beispielbeschreibung&label=SAC&label=BW
Achtung: Jegliche Form von Sonderzeichen – wie Umlaute, aber auch schon einfache Leerzeichen – müssen URL encodiert übertragen werden. Dies trifft insbesondere auf Textfelder wie “Summary” oder “Description” zu, bei denen im Zweifel sogar Benutzereingaben entsprechend kodiert werden müssen.
Für manuelle Tests kann hierzu ein Online-Tool wie URL Encoder verwendet werden.
Nehmen wir an, die Zusammenfassung lautet „Falsche Daten im aktuellen Jahr!“. Da ein Link keine Leerzeichen oder ein Ausrufezeichen enthalten darf, werden die Daten URL encodiert dargestellt: „Falsche%20Daten%20im%20aktuellen%20Jahr%21“.
Wenn die Werte in Jira, z. B. die Beschreibung, in irgendeiner Weise formatiert werden sollen, bietet Jira eine spezielle Notation dafür an, siehe Text Formatting Notation Help.
Übersicht über einige Jira-Felder und ihrer möglichen Werte
In diesem Composite werden die folgenden Parameter an Jira übermittelt:
- Project*
- Issue Type*
- Priority**
- Summary*
- Description
- Environment
- Components
- Labels
- Assignee
Felder mit * sind Pflichtfelder, Felder mit ** sind meistens Pflichtfelder. Das Feld „Reporter“ wird in der konkreten Lösung nicht übermittelt, da Jira so konfiguriert ist, dass der angemeldete Benutzer verwendet wird.
Es gibt drei Optionen für ein Feld, den technischen Feldnamen – den man als URL-Parameter verwendet und die möglichen Werte zu ermitteln:
- Im Jira Customizing nachschauen (erfordert administrative Berechtigungen und ist nicht für jedes Feld einfach möglich, sodass wir die Methode nicht empfehlen)
- Mit den Entwickler-Tools des Browsers (Shortcut F12)
- Nutzung eines Jira APIs
Es gibt eine API, um das XML eines Tickets zu erhalten:
https://<IhreInstanzurl>/rest/api/3/issue/<issuekey>?expand=names, also beispielhaft https://titecon.atlassian.net/rest/api/3/issue/SCRUM-1?expand=names
Mit dem nun bekannten Namen „customfield_10037“ können anschließend die im Ticket ausgewählten Werte angezeigt werden.
- Für den letzten Schritt gibt es wieder ein paar Alternativen:
- Das oben genannte API kann auf den relevanten Feldnamen eingeschränkt werden (https://titecon.atlassian.net/rest/api/3/issue/SCRUM-1?expand=names&fields=customfield_10037)
- Mit einem anderen API (https://titecon.atlassian.net/rest/api/3/issue/SCRUM-1/editmeta) können nicht nur die im Ticket selektierten, sondern alle möglichen Feldwerte angezeigt werden:
- Für einige Felder (wie den „Issue Type“) gibt es spezifische APIs: https://titecon.atlassian.net/rest/api/3/issuetype.
Konzept und Funktionsweise des “Jira Ticket”-Composites in der SAC
Wie man aus der Beschreibung der Jira Felder und Werte erahnen kann, sind nicht nur kundeneigene Felder, sondern auch mögliche Werte der Felder in jedem Jira-System unterschiedlich. Darüber hinaus ändern sich mögliche Werte potenziell über die Zeit. Hat man z. B. bei „Environment“ eine 3-Systemlandschaft hinterlegt und braucht nun aufgrund eines Upgradeprozesses noch eine Demo-Landschaft, dann muss dies auch in der SAC integrierbar sein.
Deshalb ist eine Anforderung an eine Lösung in der SAC, dass sie auf Veränderungen reagieren kann, ohne dass hierfür alle Berichte anzupassen sind. Als Lösungsoption kommt also ein „Custom Widget“ oder ein „Composite“ in Frage.
In der SAP Analytics Cloud sind Custom Widgets und Composites wiederverwendbare Komponenten, die darauf ausgelegt sind, die Entwicklung und Wartung komplexer Funktionalitäten zu vereinfachen. Die Hauptidee besteht darin, die erforderliche Programmierung und das visuelle Design einmal zu entwickeln und es anschließend in mehreren Berichten einzusetzen. Jede Änderung, die an einem Composite oder einem Custom Widget vorgenommen werden, sind automatisch in allen Berichten widergespiegelt, die es verwenden. Auf diese Weise wird Konsistenz gewährleistet und der Wartungsaufwand verringert.
Während ein Composite ähnlich wie eine Story innerhalb der SAC erstellt wird, entwickelt man ein Widget unabhängig von der SAC in einer Entwicklungsumgebung und importiert es anschließend in die SAC.
Da für viele ein Composite leichter nachvollziehbar, verständlich und änderbar ist, ist dieser Ansatz gewählt worden, auch wenn dies ein paar Folgeprobleme (z. B. Einschränkungen im JavaScript Coding) mit sich bringt.
Aufbau des „Jira Ticket“-Composite
- Visuelle Darstellung
Das Composite enthält eine Benutzeroberfläche mit:
- Auswählbaren Feldwerten: Bei Feldern wie Priorität und Typ können durch den Anwender vordefinierte Werte ausgewählt werden.
- Text-Pflichtfeldern: Ein Feld wie “Summary” muss ausgefüllt werden.
- Nur-Anzeige-Feldern: Technische Informationen können angezeigt, aber nicht bearbeitet werden.
Buttons:
- “Cancel”: Bricht die Erstellung eines Jira-Tickets ab.
- “Create Jira-Ticket”: Öffne ein Jira-Fenster mit einem bereits vorausgefülltem Ticket.
Customizing anhand eines SAC-Datenmodells
Das Composite basiert auf dem SAC-Datenmodell „Configurations“, in dem konfigurierbare Einstellungen gespeichert werden. Beispielsweise ist der Vorgangstyp „Bug“ mit dem Jira Issue Type „1“ ein Standardwert, während der Vorgangstyp „New Feature“ mit der internen ID „10500“ manuell definiert wurde. Durch das „Configurations“-Modell wird sichergestellt, dass mögliche zukünftige Wertänderungen keine Code-Anpassungen erfordern.
Derzeit sind u. a. folgende Parameter im Einsatz:
- JIRA-LINK: Der Basislink, um Jira-Tickets zu erstellen (https://titecon.atlassian.net/secure/CreateIssueDetails!init.jspa).
- JIRA-FIELDVALUE-ISSUETYPEID: Mögliche Vorgangstypen.
- JIRA-FIELDVALUE-PRIORITY: Mögliche Prioritäten.
- JIRA-FIELDVALUE-PROJECTID: Die Projekt-ID, die für das Ticket verwendet wird.
- JIRA-FIELD-ENVIRONMENTID & JIRA-FIELDVALUE-ENVIRONMENTID: Mögliche Environment-IDs (Production, Acceptance, …) sowie der zugehörige benutzerdefinierte Feldname in Jira.
- SAC-LINK: SAC-Links, um zu erkennen, in welcher Umgebung der Bericht ausgeführt wird. Wird also ein SAC Bericht auf der produktiven SAC ausgeführt, würde entsprechend auch der Wert „Production“ als „Environment“ in Jira vorbelegt.
Die Anpassungsdaten sind in einem tabellarischen Format mit folgenden Spalten organisiert:
- Parameter Group: Gruppiert zusammengehörige Parameter.
- Detailed Parameter: Der spezifische Parametername.
- Detailed Parameter (English Text): Eine beschreibende Bezeichnung für den Parameter (z. B. für Drop-down-Anzeigen).
- Default Value Marker: Kennzeichnet mit einem „x“ den Standardwert (aktuell verwendet für Priority und Issue Type).
- Value: Der tatsächliche Wert des Parameters.
Skripte und Ereignisse
Das Composite nutzt interne Funktionen (z. B. “URLencode” zur Kodierung von Texten für URLs) und externe Funktionen (z. B. “initialization”, um das Composite mit benötigten Daten zu initialisieren). Die Skripte sind das eigentliche „Herzstück“ des Composites und lösen u.a. folgende Anforderungen:
- Automatisches Vorbefüllen von Feldern (z. B. wird der aktuelle Bericht & Anwender vorbefüllt, die Umgebung usw.)
- Hilfsfunktionen (Jira Customizing auslesen, URLencode, Debug & Messagehandling)
- Die Hauptfunktion: Einen Jira Link so zu erstellen, dass die wichtigen Felder korrekt vorbefüllt sind
Zusätzlich gibt es einige Events, die sich in zwei Gruppen einteilen lassen:
- Warnungen- und Fehlerbehandlung
- Button-Events (Cancel bzw. Create)
Die Events dienen dazu, auf Ergebnisse – z. B. Fehler – im eigentlichen SAC Bericht reagieren zu können.
Verwendung des Composites
Schritte zur Integration in eine neue Story:
- Composite zur Story hinzufügen
- Story-Pop-up erstellen
- Composite zum Story-Pop-up hinzufügen
- Initialisieren des Composites mittels “initialization”.
- Funktionen zur Ergebnisbehandlung hinzufügen (jeweils nur eine Zeile Code)
- Hinzufügen eines Icons oder Buttons, mit dem sich das unter 2. Erstellte Story-Pop-up öffnet.
Zusammenfassung
Mit dem Jira Ticket Composite können von jedem SAC Bericht aus direkt vorbefüllte Jira-Tickets erstellt werden. Da sich Änderungen am Composite in allen Berichten widerspiegeln, brauchen spätere Anforderungen an nur einer Stelle umgesetzt zu werden.
Melden Sie sich hier an, um einen Transport des Composites zugeschickt zu bekommen.
Die TITECON GmbH verarbeitet die von Ihnen hier zur Verfügung gestellten Daten ausschließlich,
um Sie für die angefragten Composites zu kontaktieren.
- Integration von Jira in die SAP Analytics Cloud ☁️ Das “Jira Ticket”-Composite
- Technische Information
- Denis Titho
SAP Analytics Cloud News Q4 - Jetzt im Newsletter anmelden!
Weitere interessante Blogbeiträge
SAP Datasphere (Data Warehouse Cloud) ☁️ Ideales Data Warehousing
Lesedauer 8 minsErfahren Sie alles Wissenswerte über die SAP Datasphere (SAP Data Warehouse Cloud). Von den Vorteilen über die Voraussetzungen und Funktionen mit einem Abschließenden Vergleich mit der SAP Analytics Cloud.
SAP Analytics Cloud Q4-2024 Update
Lesedauer 14 minsErfahren Sie alles Wissenswerte über die SAP Data Warehouse Cloud. Von den Vorteilen über die Voraussetzungen und Funktionen mit einem Abschließenden Vergleich mit der SAP Analytics Cloud.
SAC Model ☁️ Alles wissenswerte zu effizienten Analysen
Lesedauer 10 minsErfahren Sie alles Wissenswerte über SAC Model in der SAP Analytics Cloud. Erfahren Sie mehr über Modellierung, Modelltypen und Flexibilität.
Denis Titho ist SAP Analytics Cloud Experte. Über 20 Jahre an Erfahrungswerten bei Unternehmensberatungen und IT-Unternehmen, lassen ihn die Möglichkeiten von souveränen, datenbasierten Entscheidungen bestens wissen. Er ist überzeugt, dass Erkenntnisse aus den eigenen Unternehmenszahlen gepaart mit datenbasierten Entscheidungen die Zukunft eines Unternehmens erfolgreich gestalten lässt.
