Alles im Überblick

ITSM-Connector

Was ist der ITSM-Connector?

Community Edition / Znuny

Durch die von uns entwickelten bidirektionalen Integrationen ist es möglich, in Community Edition / Znuny und i-doit über den Livestatus der Services aus SNAG-View informiert zu werden. Des Weiteren kann ein Community Edition / Znuny-Ticket in allen drei Systemen erstellt und bearbeitet werden. Es können außerdem sämtliche Objekte des IT-Inventars im SNAG-View und Community Edition / Znuny dargestellt, in das Monitoring übernommen sowie mit Tickets verknüpft werden. Sämtliche Daten sind in allen Systemen verfügbar und bieten die maximale Kontrolle über das Monitoring, die IT-Infrastruktur und den Helpdesk.

Nähere Informationen zu den einzelnen Integrationen befinden sich unten auf dieser Seite.

Schnittstelle

SNAG-View und ((OTRS)) Community Edition / Znuny LTS

Die SNAG-View - ((OTRS)) Community Edition / Znuny LTS Schnittstelle erweitert die Benachrichtigungsfunktion von SNAG-View. Mit dieser Schnittstelle wird die automatische Ticketerstellung im ((OTRS)) Community Edition / Znuny LTS durch den SNAG-View-Server möglich. Dabei werden Attribute (z.B. Status, Hostname, Servicename etc.) als Ticketparameter übergeben.

Pro Störfall wird nur ein Ticket erstellt, jede weitere SNAG-View-Benachrichtigung wird als Kommentar im bestehenden Ticket verarbeitet.

Aus ((OTRS)) Community Edition / Znuny LTS heraus lässt sich die Störung im SNAG-View auf „Acknowledge“ setzen. Beide Systeme wissen jetzt, dass sich ein Techniker um die Störung kümmert. SNAG-View schickt in diesem Fall keine weiteren Benachrichtigungen zu diesem Problem.

Der Livestatus des betroffenen Hosts bzw. Services wird in der Ticketansicht angezeigt. Diese zusätzliche Information kann z.B. für die Ticketbearbeitung und -schließung verwendet werden, ohne die SNAG-View-Oberfläche öffnen zu müssen. Des Weiteren besteht die Möglichkeit, das Ticket automatisch schließen zu lassen, wenn der Servicestatus wieder auf „OK“ wechselt und die Störung behoben wurde.

Sämtliche Ticketbearbeitungsschritte aus dem ((OTRS)) Community Edition / Znuny LTS werden als Notizen im SNAG-View unter dem betroffenen Host bzw. Service angezeigt.

Durch dieses intelligente Zusammenspiel beider Systeme ist eine professionelle Klärung schnell, zentral und ausschließlich über die ((OTRS)) Community Edition / Znuny LTS-Oberfläche möglich.

Ticketübersicht im SNAG-View

Behalten Sie immer den Überblick über alle ((OTRS)) Community Edition / Znuny LTS-Tickets, die die Infrastruktur betreffen im SNAG-View.

SNAG-View Livestatus in ((OTRS)) Community Edition / Znuny LTS

Sehen Sie bei allen Tickets die die IT-Infrastruktur betreffen direkt den Livestatus des Hosts im ((OTRS)) Community Edition / Znuny LTS.

Mehrwert

Gezielte und effektive Zuordnung von Incidents der IT-Infrastruktur im Servicedesk.

Screenshots

Ticketübersicht in SNAG-View
Ticketerstellung in SNAG-View
Acknowledgement setzen
SNAG-View Livestatus in ((OTRS)) Community Edition

Schnittstelle

SNAG-View und i-doit

Die SNAG-View - i-doit Schnittstelle ermöglicht die schnelle Aufnahme von i-doit Objekten in das Monitoring. Jedes i-doit Objekt, das eine IP- / Hostadresse besitzt, kann durch einen einfachen Klick in SNAG-View exportiert werden. Dort wird dann das passende Serviceprofil ausgewählt und die Überwachung gestartet.

Innerhalb von SNAG-View wird durch ein kleines Icon signalisiert, dass der entsprechende Host aus der i-doit CMDB stammt und dort verwaltet wird. Dieses Icon ist mit der Übersichtsseite des entsprechenden Objekts in i-doit verlinkt, sodass schnell darauf zugegriffen werden kann, wenn detaillierte Informationen benötigt werden.

Innerhalb von i-doit wird auf der Übersichtsseite der aktuelle Status des Objekts durch ein farbiges Icon angezeigt.

Werden an einem SNAG-View überwachten Objekt Änderungen vorgenommen (bspw. Änderung der IP-Adresse), wird diese Änderung automatisch an SNAG-View übergeben, sodass ein lückenloses Monitoring gewährleistet bleibt. Alle Konfigurationsänderungen werden im Revisionslog in SNAG-View gespeichert und somit ist gewährleistet, dass auch i-doit – Änderungen nachvollziehbar bleiben.

i-doit Objekte im Servicebrowser

Sehen Sie im SNAG-View, welche Ojekte sich in der CMDB i-doit befinden und erhalten somit immer einen Überblick über die Inventarisierten Geräte.

SNAG-View Livestatus im i-doit

Sehen Sie den Livestatus direkt im i-doit.

Mehrwert

Vermeidung doppelter Datenpflege durch Synchronisation und zügiger Aufbau eines Monitorings.

Webinar SNAG-View <> i-doit

 

Screenshots

i-doit Objekte im Servicebrowser
SNAG-View Livestatus auf der Übersichtsseite

Schnittstelle

((OTRS)) Community Edition / Znuny LTS und i-doit

Die ((OTRS)) Community Edition / Znuny LTS - i-doit Schnittstelle ermöglicht die Verknüpfung von i-doit Objekten mit ((OTRS)) Community Edition / Znuny LTS-Tickets. Allen Objekttypen wird eine neue Kategorie „((OTRS)) Community Edition / Znuny LTS“ zugewiesen. In dieser Kategorie werden alle ((OTRS)) Community Edition / Znuny LTS Tickets zu dem entsprechenden Objekt angezeigt. Außerdem gibt es dort die Möglichkeit ein neues Ticket zu diesem Objekt zu erstellen. Es erfolgt automatisch eine Verknüpfung mit diesem Objekt.

Auf der ((OTRS)) Community Edition / Znuny LTS Seite werden alle verknüpften / betroffenen Objekte zu dem geöffneten Ticket angezeigt. Bei der Ticketerstellung in ((OTRS)) Community Edition / Znuny LTS kann ausgewählt werden, ob und mit welchen i-doit Objekten das neue Ticket verknüpft werden soll. Dazu werden nach Eingabe des Kunden alle ihm zugewiesenen Objekte aufgelistet. Alle weiteren Objekte lassen sich ebenfalls mit Tickets verknüpfen.

Verknüpfung von i-doit Objekten mit ((OTRS)) Community Edition / Znuny LTS-Tickets

Weisen Sie bei der Erstellung von Tickets jedem Ticket das betroffene i-doit Objekt zu.

Ticketerstellung in i-doit

Erstellen Sie direkt aus dem i-doit Objekt Ihre Tickets.

Mehrwert

Kürzere Bearbeitungszeiten durch zentrale Darstellung wichtiger Informationen der Configuration Items.

Webinar ((OTRS)) Community Edition / Znuny LTS <> i-doit

 

Screenshots

Ticketerstellung in ((OTRS)) Community Edition
Ticketansicht
Ticketerstellung in i-doit

Schnittstelle

((OTRS)) Community Edition / Znuny LTS und JIRA

JIRA ist eine führende Projektmanagementsoftware von Atlassian und wird hauptsächlich im Bereich Entwicklung eingesetzt. Viele agile Teams setzen in der Softwareentwicklung auf dieses Tool. ((OTRS)) Community Edition / Znuny LTS dagegen legt in erster Linie den Fokus auf den Helpdesk, das Incident- und Problemmanagement.

Der Helpdesk leitet Anfragen (Softwarefehler, Feature Request) weiter, wenn zur Lösung das Entwicklungsteam erforderlich ist.

Über die Schnittstelle lassen sich von ((OTRS)) Community Edition / Znuny LTS Tickets JIRA Vorgänge erzeugen. Einzelne Artikel und Dateianlagen werden ausgewählt und an das JIRA System übertragen. Dabei können JIRA spezifischen Felder im ((OTRS)) Community Edition / Znuny LTS frei und flexibel konfiguriert und an JIRA übermittelt werden. Durch freidefinierte Postmaster Filter werden Aktionen angetriggert, um ((OTRS)) Community Edition / Znuny LTS Informationen automatisch in JIRA darzustellen.

Kommentare und Bearbeitungsschritte am JIRA Ticket werden im ((OTRS)) Community Edition / Znuny LTS als Artikel hinzugefügt. Der Informationsfluss zwischen Entwicklung, Helpdesk und ((OTRS)) Community Edition / Znuny LTS Kunde wird dadurch gewährleistet.

Über die Integration im Customer Portal können anhand definierter Filter automatisch JIRA Vorgänge erzeugt und verknüpft werden.

Ticketübersicht im JIRA

((OTRS)) Community Edition / Znuny LTS Artikel werden als Kommentare dargestellt. Verlinkung zum betroffenen ((OTRS)) Community Edition / Znuny LTS Ticket.

Ticketübersicht im ((OTRS)) Community Edition / Znuny LTS

Verlinkung zum betroffenen JIRA Vorgang. Anzeige des aktuellen Bearbeitungsstandes des JIRA Vorganges. (Projekt, VorgangsID, Typ, Priorität, Status, Bearbeiter und Zusammenfassung)

Mehrwert

Verbesserter Informationsfluss für die Bearbeiter und den Kunden. Durch die übersichtliche Darstellung werden die Stärken der beiden Systeme
weiterhin genutzt.

Funktionen

  • Tickets aus OTRS/Znuny können an Jira übertragen werden, um einen Vorgang zu erzeugen.
  • Vor der Übertragung an Jira können unter anderem das Projekt, der Vorgangtyp, die Beschreibung, der zuständige Bearbeiter, die Priorität sowie jedes andere Jira-Feld (konfigurierbar) in OTRS/Znuny ausgewählt und verändert werden.
  • Bestehende Tickets lassen sich mit bestehenden Jira-Vorgängen verknüpfen.
  • Artikel aus OTRS/Znuny können an Jira gesendet werden und sind dort in Form von Kommentaren sichtbar.
  • Kommentare und Bearbeitungsschritte am Jira Vorgang werden in OTRS/Znuny als Artikel hinzugefügt.
  • Alle Attribute (konfigurierbar) aus Jira werden in Echtzeit in einem Sidebar-Widget in OTRS/Znuny angezeigt.
  • Attribute können automatisch in beide Richtungen synchronisiert werden: Wird im Vorgang in Jira die Priorität geändert, ändert sich auch die Priorität in OTRS/Znuny.
  • Dynamische Felder in OTRS/Znuny können mit Customfields in Jira verknüpft werden: Individuelle Attribute mit Informationen können zwischen Jira und OTRS/Znuny synchronisiert werden. Dadurch lassen sich Informationen aus Jira beispielsweise im Dashboard oder im Customer-Portal anzeigen.

Viele Funktionen des JiraConnectors wurden generisch entwickelt und lassen sich über die System-Konfiguration in OTRS/Znuny individuell anpassen oder erweitern.

Screenshots

JIRA Vorgang in ((OTRS)) Community Edition erstellen
Schnittstelle in JIRA
Schnittstelle in ((OTRS)) Community Edition

 

Schnittstelle

Znuny und Gitlab

 

Gitlab ist eines der führenden Source Code Management Systeme und wird überwiegend im Bereich der Entwicklung eingesetzt. Das Helpdesk Systeme Znuny hingegen legt in erster Linie den Fokus auf den Helpdesk, das Incident- und Problemmanagement.

Über diese bidirektionale Schnittstelle wird eine direkte Kommunikation zwischen einem Znuny- und einem Gitlab-System ermöglicht. Hierbei werden aus einem Znuny Ticket auf Artikel Basis wichtige und relevante Informationen an das Gitlab System übertragen. So lässt sich die Schnittstelle beispielsweise im klassischen 1st, 2nd & 3rd Level sehr gut einsetzen um die Informationen bzw. Anforderungen für etwaige Entwicklungen schnell und einfach zusammenzutragen.

Znuny -> Gitlab

  • Gitlab Projektauswahl und Gitlab Issue Erstellung inkl. Verknüpfung beider Tickets

Hierbei werden Projektspezifische Informationen abgefragt und direkt in der Erstellungsmaske im Znuny zur Auswahl dargestellt.

  • Anlage eines Kommentar zu einem verknüpften Gitlab Issue

Sobald ein Ticket mit einem Gitlab-Vorgang verknüpft ist, kann ein Kommentar dem Vorgang hinzugefügt werden.

  • Label Synchronisierung und Status Update

Wenn ein Ticket geschlossen wird, kann es manchmal sinnvoll sein auch den Gitlab-Issue zu schließen. Damit das nicht allerdings nicht unbemerkt geschieht, ist es intelligenter für den Vorgang ein bestimmtes Label zu setzen. Durch eine systemübergreifende Synchronisierung der Labels lässt sich die Schnittstelle individuell einsetzen.

 

Gitlab -> Znuny

  • Anlage eines Kommentars zu einem verknüpften Znuny Ticket

Wenn ein Kommentar in Gitlab mit einem bestimmten Muster erstellt wird, wird der Kommentar in Znuny als Artikel angelegt. Das Muster lässt sich in der System-Konfiguration einstellen, Standard: "@znuny".

  • Aktionen in Znuny ausführen wenn in Gitlab der Issue geschlossen wird

Über den GenericAgent lassen sich verschiedene Aktionen im Ticket ausführen, sobald der verknüpfte Vorgang geschlossen wurde. Beispielsweise lässt sich das verknüpfte Ticket schließen oder in eine andere Queue verschieben.

  • Aktionen in Znuny ausführen wenn in Gitalb ein Issue Label hinzugefügt wird

Über den GenericAgent lassen sich verschiedene Aktionen im Ticket ausführen, wenn ein bestimmtes Label hinzugefügt wird.

Screenshots

In Znuny ein GitLab Issue erstellen
GitLab Issue Maske
Erstelles Issue im GitLab
Ansicht des Issues im Znuny

Schnittstelle

i-doit und icinga2

 

Die i-doit-Icinga2-Kopplung ermöglicht die schnelle Aufnahme von i-doit Objekten in das Monitoring. Jedes i-doit Objekt, das eine IP- /Hostadresse besitzt, kann durch einen einfachen Klick in Icinga2 exportiert werden. Dort wird dann das passende Template ausgewählt und die Überwachung gestartet. Innerhalb von Icinga2 wird durch ein kleines Icon signalisiert, dass der entsprechende Host aus der i-doit CMDB stammt und dort verwaltet wird. Dieses Icon ist mit der Übersichtsseite des entsprechenden Objekts in i-doit verlinkt, sodass schnell darauf zugegriffen werden kann, wenn detaillierte Informationen benötigt werden. Innerhalb von i-doit wird auf der Übersichtsseite der aktuelle Status des Objekts durch ein farbiges Icon angezeigt. Werden an einem Icinga2 überwachten Objekt Änderungen vorgenommen (bspw. Änderung der IP-Adresse), wird diese Änderung automatisch übergeben, sodass ein lückenloses Monitoring gewährleistet bleibt.

 

Screenshots