Mit der Jira-Schnittstelle übernehmen Sie Strukturen aus Jira in ZEP – von Spaces über Epics bis zu Issues. Jira bleibt dabei das führende System für die übertragenen Strukturen. Je nach Bedarf können Jira-Spaces als ZEP-Kunden abgebildet werden (typisch für Beratungsunternehmen) oder als ZEP-Projekte (typisch für interne IT-Teams).

Für die Einrichtung benötigen Sie:

Öffnen Sie in ZEP Administration > Schnittstellen > Schnittstellenmarktplatz. Wählen Sie Jira aus und klicken Sie auf Hinzufügen. Sie werden anschließend durch den Buchungsprozess im Self-Service-Tool geführt. Nach der Buchung erscheint die Jira-Schnittstelle in Ihrer Schnittstellenübersicht und kann konfiguriert werden.

Tragen Sie in den Einstellungen folgende Zugangsdaten ein:

Klicken Sie anschließend auf Test Connection, um die Verbindung zu prüfen. Erst wenn der Test erfolgreich ist, wechselt der Status von „inaktiv“ auf „aktiv“.

Das Herzstück der Schnittstelle: Sie legen über Dropdowns in den Einstellungen fest, wie Jira-Elemente auf ZEP-Strukturen abgebildet werden. Die folgende Tabelle gibt einen Überblick:

Jira-Spaces entsprechen Jira-Projekten. Sie können jeden Space als ZEP-Projekt oder ZEP-Kunden anlegen lassen. Bei der Zuordnung als Kunde wird die Kundennummer automatisch aus dem konfigurierten Präfix und dem Jira-Key gebildet (z. B. jira_knr_PROJ-1). Spaces ohne gewünschte Zuordnung belassen Sie auf „keine Zuordnung“.

Epics werden unter dem Ergebnis ihres übergeordneten Space eingeordnet. Sie können als ZEP-Projekt oder ZEP-Vorgang angelegt werden. Da Spaces und Epics nicht gleichzeitig auf ZEP-Projekte abgebildet werden können, ist die Zuordnung Epic → Projekt nur dann möglich, wenn der übergeordnete Space nicht ebenfalls als Projekt importiert wird.

Issues folgen automatisch der Zuordnung ihres Parent-Epics: Wurde das Epic als ZEP-Projekt importiert, wird das Issue als ZEP-Vorgang angelegt. Wurde das Epic als ZEP-Vorgang importiert, wird das Issue als ZEP-Ticket angelegt.

Issues, die in Jira keinem Epic zugeordnet sind, können ohne Sonderkonfiguration nicht importiert werden. Damit diese nicht verloren gehen, können Sie ein Standardziel wählen: ein Standard-ZEP-Projekt (Issues werden als Vorgänge angelegt) oder einen Standard-ZEP-Vorgang (Issues werden als Tickets angelegt). Alle Issues ohne Epic — auch aus verschiedenen Jira-Spaces — landen dann in diesem einen Standardziel und müssen dort gegebenenfalls manuell weiter zugeordnet werden. Alternativ können Issues ohne Epic auch übersprungen werden.

Sollen Issues ohne Epic je nach Jira-Space in unterschiedliche ZEP-Projekte landen — zum Beispiel Helpdesk-Tickets in ein eigenes ZEP-Projekt und übrige Issues in ein anderes — empfiehlt sich folgender Workaround: Legen Sie in Jira pro gewünschtem Parent-Projekt ein Epic an (etwa ein Epic Helpdesk) und hängen Sie die jeweiligen Issues dort ein. Das Epic wird dann als ZEP-Projekt importiert und die untergeordneten Issues werden diesem Projekt als Vorgänge zugeordnet.

Ist das Parent-Epic zum Zeitpunkt des Syncs noch nicht in ZEP vorhanden (z. B. weil es gelöscht, archiviert oder außerhalb des 12-Wochen-Rückblicks liegt), wird das Issue sicher übersprungen und als Warnung im Protokoll vermerkt. Es wird nie an ein falsches Parent gehängt und der Sync läuft weiter. Beim nächsten Lauf versucht ZEP das Issue erneut, sobald das Epic in ZEP verfügbar ist – kein Nutzereingriff nötig.

Beim Import eines Issues werden die folgenden Informationen aus Jira in ZEP-Felder übernommen. Diese Felder werden bei jeder Synchronisation aktualisiert — Status, Priorität, Start- und Fälligkeitsdatum spiegeln so stets den aktuellen Stand in Jira wider. Die Zuordnung von Ersteller und Beauftragtem erfolgt automatisch anhand der E-Mail-Adresse.

Damit das Start-Datum sauber übernommen wird, muss in Jira ein Custom Field mit dem exakten Namen Start Date existieren — die Schnittstelle sucht in Jira gezielt nach diesem Feldnamen. Existiert das Feld in Ihrer Jira-Konfiguration nicht oder ist es anders benannt, wird das Start-Datum nicht übertragen, und Projekte, Vorgänge und Tickets erhalten stattdessen das Datum der Synchronisation als Startdatum.

Beim Import eines Issues überträgt die Schnittstelle automatisch auch die zugehörigen Jira-Worklogs und wandelt sie in Anwesenheitsbuchungen in ZEP um. Die Tätigkeit, auf die die Zeiten gebucht werden, legen Sie einmalig in den Einstellungen fest.

ZEP berücksichtigt dabei folgende Regeln:

Die Schnittstelle synchronisiert automatisch stündlich. Der Import ist inkrementell: ZEP überträgt nur Daten, die seit dem letzten erfolgreichen Sync geändert wurden — als Referenz-Zeitpunkt gilt der letzte erfolgreiche Sync minus eine Woche als Sicherheitspuffer. Eine manuelle Synchronisation lässt sich jederzeit über Jetzt synchronisieren anstoßen.

Beim initialen Einrichten der Schnittstelle gilt ein Rückblick von maximal 12 Wochen: ZEP importiert nur Epics und Issues, die in den letzten 12 Wochen in Jira erstellt oder aktualisiert wurden. Ältere Strukturen werden nicht automatisch übernommen und müssen bei Bedarf in Jira aktualisiert (damit sie ins 12-Wochen-Fenster fallen) oder manuell in ZEP nachgeführt werden. Wenn nach dem ersten Sync weniger Epics oder Issues in ZEP erscheinen als erwartet, ist meistens das 12-Wochen-Fenster die Ursache.

Die Synchronisation läuft in einer festen, verketteten Reihenfolge ab: Spaces werden zuerst importiert, dann Epics, zuletzt Issues. Jede Stufe startet erst, wenn die vorherige erfolgreich abgeschlossen wurde. Schlägt eine Stufe fehl, werden die abhängigen Schritte abgebrochen – so entstehen keine halb importierten Datensätze.

Jeder Sync-Lauf erzeugt einen Protokolleintrag mit folgenden Zählern:

Ein einzelner fehlerhafter Datensatz hält den restlichen Batch nicht auf. Fehlende Parent-Epics werden als Warnung protokolliert und beim nächsten Sync-Lauf erneut verarbeitet. Automatische Wiederholungsversuche gibt es nicht – der stündliche Scheduler übernimmt diese Funktion.

Alle konfigurierbaren Parameter der Jira-Schnittstelle auf einen Blick: