Alles im Überblick
ITSM-Connector
Was ist der ITSM-Connector?
Durch die von uns entwickelten bidirektionalen Integrationen ist es möglich, in Znuny / ((OTRS)) CE und i-doit über den Livestatus der Services aus SNAG-View informiert zu werden. Des Weiteren kann ein Znuny / ((OTRS)) CE -Ticket in allen drei Systemen erstellt und bearbeitet werden. Es können außerdem sämtliche Objekte des IT-Inventars im SNAG-View und Znuny / ((OTRS)) CE 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 Znuny / ((OTRS)) CE
Die SNAG-View - Znuny / ((OTRS)) CE Schnittstelle erweitert die Benachrichtigungsfunktion von SNAG-View. Mit dieser Schnittstelle wird die automatische Ticketerstellung im Znuny / ((OTRS)) CE 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 Znuny / ((OTRS)) CE 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 Znuny / ((OTRS)) CE 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 Znuny / ((OTRS)) CE - Oberfläche möglich.
Screenshots
SNAGView4-Znuny-Connector
Changelog
- Adjustments due to Znuny 7
- Initial Migration to Znuny 7.0.4
- Updated SV4 API compability for acknowledge
Schnittstelle
SNAG-View 4 und i-doit
Die Schnittstelle zwischen der i-doit CMDB und der Monitoring-Suite SNAG-View 4 dient als intelligenter Datenlieferant und ermöglicht so die schnelle Aufnahme von i-doit Objekten ins Monitoringsystem.
Über die Auswahl der Gerätevorlagen in i-doit kann bereits bei der Aktivierung der Überwachung festgelegt werden, welche Systemparameter vom Monitoringsystem geprüft bzw. überwacht werden sollen.
Innerhalb von SNAG-View wird durch ein kleines Icon signalisiert, dass das entsprechende Device 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 des Objektes der Monitoring-Status live durch ein farbiges Icon angezeigt.
Videos
Screenshots
SNAGView4-idoit-Connector
Changelog
- Added page to upload license to SNAG-View 4 Connector
- Added new icons
- Improved slot handling to integrate automatic import of devices from OCS
- Removed deprecated JS event DOMNodeInserted
- Improved handling to prevent double connected i-doit objects to a SNAG-View device
- Code improvements and refactoring
- Added compatibility for SNAG-View 4 0.19.0 (API Changes)
- Added console cmd to import teams and user teams assignments from i-doit to SV4
- Removed telegraf rollout (moved to SNAG-View 4 Core)
- Improved default selected address in category
- Improved documentation
- Fixed API error when updating a device to the same address
Schnittstelle
SNAG-View 3 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.
Webinar SNAG-View <> i-doit
Screenshots
SNAGView3-idoit-Connector
Changelog
- Added compability for i-doit 34 (updated language file path) (#83)
- Refactoring addon integration for i-doit 34 (#83)
- Fixed adding and removing host groups in one request (#54)
- Added REST communication to debug log (#81)
Schnittstelle
Znuny / ((OTRS)) CE 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.
Webinar ((OTRS)) Community Edition / Znuny LTS <> i-doit
Videos
Screenshots
Znuny-Idoit-Connector
Changelog
- Adjustments due to certain system configurations
- Missing SysConfig entry for SelectParentObjectType added
- When selecting, automatically add parent objects of a specific object type
Schnittstelle
Znuny / ((OTRS)) CE 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-spezifische 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.
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
Znuny-Jira-Connector
Changelog
- Added function to add previously added attachments to articles
- Fixed postmaster filter "AddJiraAttachments" breaking the daemon
- Improved inline-image handling and protecting comment-article creation loops
Schnittstelle
Znuny / ((OTRS)) CE und Gitlab
Gitlab ist eines der führenden Source Code Management Systeme und wird überwiegend im Bereich der Entwicklung eingesetzt. Das Helpdesk-System 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 Artikelbasis 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.
Screenshots
Znuny-Gitlab-Connector
Changelog
- Fixed bug where gitlab comments were not send to Znuny
- Attributes of Issues and Epics can be edited over the creation and comment mask
- Updated features from Version 6.2.4.10
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.
Schnittstelle
i-doit und Jira
Importieren Sie die Asset Informationen aus dem Atlassian Jira Service-Management zur weiteren Verarbeitung und Nutzung in die i-doit CMDB. Verwenden Sie die in Jira gepflegten Asset Informationen um Ihre IT Dokumentation und Notfallhandbücher zu vervollständigen. Nutzen Sie die bekannte aql-Syntax um Filterungen der Assets vorzunehmen. Über die Authentifizierung über OAuth können die Assets auch aus dem Jira Cloud System für den Import genutzt werden.
Die Schnittstelle setzt Atlassian Jira Service Management in der Version 5.4.3 voraus.
i-doit pro Jira Asset Import Add-on
Changelog
- Fixed license check bug during command execution
- Added Jira authentication to the Web GUI
- Added license check
- Renamed JiraAssets-idoit-Connector to Jira-Assets-Import
- Fixed import of IPv6 addresses
- Fixed automatic inactivation of host addresses
- Fixed auto assignment of layer 3 network
- Removed warning messages