Jira anbinden

Die Anbindung Jira verbindet octoja mit deiner Atlassian-Site mit Jira Service Management, sodass aus Monitoring-Alarmen Fälle werden, in denen dein Team ohnehin schon arbeitet. Für die Einrichtung brauchst du drei Dinge: die Verbindung selbst, das Meldungs-Mapping und eine Alarmierungsregel, die Alarme an den Jira-Kanal leitet.

Was die Anbindung leistet

Sobald verbunden und konfiguriert, erledigt die Anbindung drei getrennte Aufgaben:

• Erstellt einen Fall aus einem Alarm — wenn ein Monitoring-Check einen Alarm auslöst und eine Alarmierungsregel ihn an den Jira-Kanal leitet, öffnet octoja eine Kundenanfrage auf dem gewählten Service-Desk.
• Behandelt die Entwarnung — ist der Check wieder in Ordnung, ergänzt octoja immer einen internen Kommentar an diesem Fall und setzt ihn auf deinen Schließen-Status, solange ihn noch niemand übernommen hat.
• Synchronisiert Geräte nach Jira Assets — wenn deine Atlassian-Site Jira Assets lizenziert hat, erscheint auf der Konfigurationsseite der Bereich Geräte-Sync. Ist Geräte stündlich automatisch synchronisieren eingeschaltet, überträgt octoja einmal pro Stunde die Geräte jedes zugeordneten Kunden nach Jira Assets und legt dabei je Gerät ein Objekt an oder aktualisiert es, abgeglichen über den Hostnamen des Geräts. Geräte werden nie gelöscht. In welchem Jira-Objekttyp welche Geräteart landet, wird in dieser Version über die octoja-API festgelegt und nicht in der Oberfläche — der Schalter allein bewegt also noch nichts.

Alles läuft ausgehend, von octoja nach Jira. octoja fasst ausschließlich die Fälle an, die es selbst erstellt hat, in Jira Assets legt es ausschließlich Geräte-Objekte an und aktualisiert sie, und löscht in Jira niemals etwas.

Eine Anmerkung zur Bezeichnung vorweg: Die Zustellhistorie zeigt Meldung erstellen, während der Kanal, den du später auswählst, Jira-Ticket heißt. Gemeint ist beide Male dieselbe Kundenanfrage in Jira Service Management.

Das Verbinden allein erstellt nichts. Eine verbundene Anbindung mit allen ausgefüllten Einstellungen erzeugt weiterhin null Fälle, solange keine Alarmierungsregel auf den Jira-Kanal zeigt. Dieser Schritt ist Schritt 5 weiter unten — und derjenige, den man am häufigsten übersieht.

Voraussetzungen

• Die Berechtigung Integrationsverwaltung in octoja. Berechtigungen werden unter Administration → Gruppen zugewiesen.
• Zusätzlich die Berechtigung Kundenverwaltung, falls du auch Kunden aus Jira importieren möchtest.
• Eine Atlassian-Site mit Jira Service Management, erreichbar über HTTPS. octoja spricht den Service-Management-Teil der Jira-API an — eine Jira-Site ohne Service Management bietet ihm also nichts zum Ansprechen.
• Eine Atlassian-Konto-E-Mail-Adresse und ein API-Token, das für dieses Konto ausgestellt wurde. Atlassian erzeugt das Token in den Einstellungen des Atlassian-Kontos; octoja legt keines an.
• Dieses Konto braucht im Ziel-Service-Desk genug Rechte, um Anfragen zu erstellen, sie zu kommentieren, eine Vorgangspriorität zu setzen und den Übergang in deinen Schließen-Status auszuführen. Welches Jira-Berechtigungsschema genau das gewährt, entscheidet sich auf der Atlassian-Seite — frage im Zweifel bei Atlassian nach.
• Mindestens einen Service-Desk mit mindestens einem Anfragetyp in Jira sowie einen Monitoring-Check, der bereits läuft, damit es überhaupt einen Alarm gibt, aus dem ein Fall werden kann.

Schritt 1 — Jira-Zugangsdaten zusammenstellen

Sammle drei Werte: die Site-URL deiner Atlassian-Site, die E-Mail-Adresse des Atlassian-Kontos, dem das API-Token gehört, und das API-Token selbst. Alle drei trägst du im nächsten Schritt in octoja ein.

Die Site-URL muss eine absolute HTTPS-Adresse in der Form https://deine-domain.atlassian.net sein. Alles, was nicht HTTPS ist, wird direkt abgelehnt. Ein abschließender Schrägstrich ist unproblematisch — octoja entfernt ihn vor dem Speichern.

Schritt 2 — octoja mit Jira verbinden

1. Öffne in octoja Administration → Integrationen und suche die Karte Jira.
2. Klicke auf Einrichten. Der Dialog Jira einrichten öffnet sich.
3. Fülle die drei Felder aus:

4. Klicke auf Verbindung testen. octoja kontaktiert Jira mit den eingegebenen Werten und meldet Verbindung erfolgreich. oder den Grund, warum der Versuch gescheitert ist — und wenn es keinen Grund anzuzeigen gibt, ersatzweise Verbindung fehlgeschlagen.
5. Klicke auf Verbinden. octoja speichert die Zugangsdaten und öffnet die Jira-Integrationsseite auf dem Reiter Konfiguration.

Verbindung testen ist optional — nutze es trotzdem. Verbinden prüft nur, ob die drei Felder ausgefüllt sind und die Site-URL HTTPS ist — octoja speichert, was du eintippst, ohne bei Jira nachzufragen, ob die Zugangsdaten funktionieren. Falsche Zugangsdaten lassen sich völlig problemlos verbinden, und der Fehler zeigt sich erst danach, wenn auf der Konfigurationsseite sämtliche Auswahllisten hartnäckig leer bleiben. Ein Klick auf Verbindung testen vor dem Verbinden macht aus einer Stunde Fehlersuche eine klare Fehlermeldung.

Für einen Token-Wechsel musst du zuerst trennen. Solange eine Verbindung besteht, wird ein erneutes Verbinden mit dem Hinweis abgelehnt, dass Jira bereits verbunden ist. Nutze Jira trennen und verbinde dann mit dem neuen Token — Zuordnungen und Einstellungen überleben diesen Umweg.

Schritt 3 — Kunden Jira-Organisationen zuordnen

Der Bereich Kunden-Mapping ordnet jedem octoja-Kunden eine Jira-Organisation zu.

1. Suche auf dem Reiter Konfiguration den Bereich Kunden-Mapping, der zählt, wie viele deiner Kunden zugeordnet sind.
2. Klicke auf Kunden zuordnen, ordne jedem octoja-Kunden seine Jira-Organisation zu und speichere den Dialog.

Die Fälle hängen nicht davon ab. Jeder Fall entsteht auf dem einen Service-Desk, den du in Schritt 4 wählst, egal zu welchem Kunden das Gerät gehört, und der Kundenname landet ohnehin in der Fallbeschreibung. Ein nicht zugeordneter Kunde bekommt also trotzdem Fälle — die Zuordnung hält deine beiden Kundenlisten in Deckung, und der Import weiter unten legt sie für dich an. Der Geräte-Sync ist die Ausnahme: Er läuft nur für zugeordnete Kunden, die Geräte eines nicht zugeordneten Kunden erreichen Jira Assets also nie.

Jeder octoja-Kunde nimmt eine Organisation auf, und jede Organisation lässt sich einmal verwenden. Der Dialog weigert sich, eine Dopplung auf einer der beiden Seiten zu speichern.

Schritt 4 — Einstellungen für das Meldungs-Mapping wählen

Der Bereich Meldungs-Mapping bestimmt, wo ein Fall landet und wie er aussieht. Zwei dieser Einstellungen sind harte Voraussetzungen: Fehlt eine davon, überspringt octoja den Fall stillschweigend. Das Überspringen hinterlässt überhaupt keine Spur — nicht einmal auf dem Reiter Historie, der nur Versuche festhält, die tatsächlich an Jira hinausgegangen sind. Eine leere Historie zusammen mit fehlenden Fällen weist also direkt auf diese beiden Einstellungen hin.

Wähle zuerst den Service-Desk. Ein Wechsel setzt den Anfragetyp zurück, weil Anfragetypen zu einem Service-Desk gehören, und die Auswahlliste für den Schließen-Status wird aus dem Projekt dieses Service-Desks befüllt — deshalb bleiben beide deaktiviert, bis ein Service-Desk ausgewählt ist. Ein bereits gewählter Schließen-Status bleibt bei diesem Wechsel unangetastet — prüfe ihn nach einem Wechsel des Service-Desks also noch einmal.

Prioritäten werden in einem zweiten Aufruf direkt nach dem Anlegen des Falls gesetzt. Schlägt dieser Aufruf fehl, existiert der Fall trotzdem, nur ohne Priorität, und die Zustellung gilt weiterhin als erfolgreich — ein Fall ohne Priorität ist deshalb meist eine Frage der Jira-Berechtigungen und nicht einer fehlenden Einstellung.

Einstellungen werden nicht automatisch gespeichert. Jede geänderte Auswahlliste bleibt lokal, bis du oben auf der Seite auf Einstellungen speichern klickst oder Strg+S drückst. Diese Schaltfläche gibt es nur auf dem Reiter Konfiguration — bist du gerade auf Historie, musst du also zurückwechseln, bevor du speichern kannst. Weggeworfen werden deine Änderungen erst, wenn du die Seite verlässt, ohne zu speichern.

Schritt 5 — Alarme an den Jira-Kanal leiten

Dieser Schritt sorgt dafür, dass Fälle entstehen. Alles bisherige hat nur octoja vorbereitet; kein Alarm erreicht Jira, bevor ihn eine Alarmierungsregel dorthin schickt.

1. Öffne das Konfigurationspaket mit dem Check, für den du Fälle willst, wechsle zu seinem Reiter Checks und öffne den Check. Liegt der Check an einem einzelnen Gerät statt in einem Paket, öffne dieses Gerät und nutze dessen eigenen Reiter Checks — der Check öffnet sich von dort genauso.
2. Wechsle zum Reiter Alarmierung des Checks und wähle oder erstelle eine Alarmierungskonfiguration.
3. Füge in dieser Konfiguration den Kanal Jira-Ticket hinzu.
4. Lege die Regel für den Kanal fest — den Anteil der Ergebnisse, die fehlschlagen müssen, das Fenster, über das gemessen wird (eine Anzahl der jüngsten Ergebnisse oder eine Spanne in Minuten oder Stunden), und die Mindest-Schwere, die erreicht sein muss — und speichere den Check.

Jira ist ein einzelner, mandantenweiter Kanal: Hast du Jira-Ticket gewählt, gibt es nichts weiter auszuwählen, kein Ziel und keinen erneuten Service-Desk. Der Kanal erscheint in der Auswahl nur, solange die Anbindung verbunden ist — verbinde also zuerst und leite danach weiter; wer den Kanal vorher sucht, sucht vergeblich.

Die vollständige Anleitung zu Alarmierungskonfigurationen, Regeln und Zeitplänen findest du unter Alarmierung für einen Check einrichten.

Ein Fall, den octoja öffnet, trägt den Titel [octoja] <Check> <Status> – <Gerät>. Die Beschreibung nennt den Check, das Gerät, den gemeldeten Status, wie viele der letzten Läufe fehlgeschlagen sind und zu welchem Kunden das Gerät gehört, gefolgt von der Ausgabe des Checks und einem Link zurück auf die Check-Seite des Geräts in octoja. Dieser Text wird immer auf Englisch geschrieben, unabhängig davon, welche Sprache in octoja eingestellt ist.

Was bei einer Entwarnung passiert

Die Entwarnung besteht aus zwei Schritten; der Kommentar wird immer ergänzt.

Alle vier Ergebnisse werden als erfolgreiche Zustellung festgehalten — „kommentiert, offen gelassen“ ist ein normales Ergebnis und kein Fehler —, und der Reiter Historie schreibt zu jedem Fall aus, welches davon eingetreten ist.

Angefasst werden nur Fälle, die octoja für diesen Alarm erstellt hat. Wurde der ursprüngliche Fall übersprungen, weil Service-Desk oder Anfragetyp fehlten, gibt es nichts zu kommentieren, und die Erholung geht in Jira spurlos vorüber.

Kunden aus Jira importieren

Existieren deine Kunden in octoja noch nicht, kannst du sie aus deinen Jira-Organisationen übernehmen. Das liegt auf der Seite Kunden, nicht auf der Integrationsseite.

1. Öffne Kunden und wähle Aus Ticketsystem importieren.
2. Markiere die gewünschten Jira-Organisationen und bestätige den Import.

Jede ausgewählte Organisation wird zu einem octoja-Kunden, und die Kundenzuordnung wird automatisch angelegt — ein importierter Kunde braucht damit keine Zuordnung von Hand aus Schritt 3. Bereits zugeordnete Organisationen werden markiert und übersprungen. Für den Import brauchst du zusätzlich zur Integrationsverwaltung die Berechtigung Kundenverwaltung.

Der Menüpunkt öffnet das erste verbundene Ticketsystem in einer festen Reihenfolge: DocBee, HaloPSA, Inserve, Autotask, Codemeta OS, Odoo, Jira, TOPdesk, TANSS, c-entron Service-Board, Freshservice, Zammad. Jira steht an siebter Stelle — ist eines der sechs davor ebenfalls verbunden, öffnet sich dessen Import-Dialog statt dem von Jira.

Wenn keine Fälle mehr ankommen

Der Reiter Historie listet die jüngsten Fall-, Erholungs- und Geräte-Sync-Versuche mit Ergebnis und Antwort auf und aktualisiert sich dabei laufend. Er ist die Anlaufstelle, wenn ein erwarteter Fall fehlt.

• Sämtliche Auswahllisten auf der Konfigurationsseite sind leer. Die hinterlegten Zugangsdaten funktionieren nicht, deshalb liefert keine der Abfragen etwas zurück. Trenne die Verbindung und verbinde erneut mit einem gültigen Token — diesmal mit einem Klick auf Verbindung testen vorab.
• Eine Zustellung ist fehlgeschlagen. octoja wiederholt eine fehlgeschlagene Fall-Erstellung oder Erholung nach 1 Minute, 5 Minuten, 30 Minuten, 2 Stunden, 12 Stunden und 24 Stunden. Fehler, die Jira als Fehler des Aufrufers meldet — ein abgelehntes Token, ein Anfragetyp, den es nicht mehr gibt —, werden nicht wiederholt, weil eine Wiederholung nichts an der Antwort ändern würde.
• Die Karte zeigt den Status Pausiert. Nach 20 aufeinanderfolgenden fehlgeschlagenen Zustellungen stellt octoja das Senden ein, damit eine kaputte Verbindung nicht dauerhaft gegen Jira läuft. Eine Schaltfläche zum Fortsetzen gibt es nicht: Nutze Jira trennen und verbinde erneut. Zuordnungen und Einstellungen bleiben erhalten, das API-Token musst du aber erneut eingeben, weil octoja es nie wieder anzeigt — bewahre eine Kopie dort auf, wo du auch sonst Zugangsdaten aufbewahrst.
• Gar keine Fälle. Prüfe, ob Service-Desk und Anfragetyp beide gesetzt und gespeichert sind und ob eine Alarmierungskonfiguration am Check den Kanal Jira-Ticket wirklich enthält.

Jira trennen

Um die Verbindung zu entfernen, öffne die Jira-Integrationsseite, scrolle zur Danger Zone und klicke auf Jira trennen, dann bestätige mit Trennen.

Entfernt werden nur die Zugangsdaten. Deine Kundenzuordnungen, sämtliche Einstellungen des Meldungs-Mappings und die Zustellhistorie bleiben genau so erhalten, wie sie waren, und jeder bereits erstellte Fall bleibt in Jira. Ein späteres erneutes Verbinden bedeutet nur, Site-URL, E-Mail-Adresse und Token noch einmal einzutragen.

Tipps

• Klicke nach jeder Änderung auf Einstellungen speichern — eine geänderte, aber nicht gespeicherte Auswahl wirkt sich auf den nächsten Alarm nicht aus.
• Setze sowohl Priorität für Warnung als auch Priorität für Kritisch, damit ein Fall unabhängig von der ausgelösten Schwere eine brauchbare Priorität trägt.
• Prüfe, ob dein Schließen-Status aus den Status erreichbar ist, in denen deine Fälle tatsächlich stehen. Bietet der Workflow keinen Übergang dorthin, kommentiert octoja und lässt den Fall offen.
• Lass Status beim Schließen bei Erholung leer, wenn dein Team Fälle lieber von Hand schließt — die Erholung wird trotzdem am Fall vermerkt.
• Wähle den Anfragetyp neu, nachdem jemand den Service-Desk in Jira umgebaut hat. octoja verwendet weiterhin die gespeicherte ID, die nach dem Entfernen des Anfragetyps ins Leere läuft.
• Jira Assets erst nach dem Verbinden lizenziert? octoja sucht den Assets-Workspace nur einmal, während es verbindet — der Bereich Geräte-Sync bleibt deshalb verborgen, bis du trennst und erneut verbindest.
• Nutze den Reiter Historie als erste Anlaufstelle. Einträge vom Typ Meldung erstellen tragen den Schlüssel des neuen Falls, Einträge vom Typ Erholung sagen, ob der Fall geschlossen oder bewusst offen gelassen wurde.