Web-Services

OTRS als Provider

Entfernte Anfrage:

1. HTTP-Anfrage

   • OTRS empfängt HTTP-Anfragen und leitet sie durch die verschiedenen Schichten weiter.

   • Die Provider-Modul ist für die Ausführung und Kontrolle dieser Maßnahmen vorhanden.

2. Netzwerktransport

   • Das Netzwerktransportmodul dekodiert den Daten-Payload und trennt den Operationsnamen aus dem Rest der Daten.

   • Der Operationsname und die Betriebsdaten werden an den Provider zurückgegeben.

3. Externe Daten

   • Daten die vom Remote-System gesendet wurden (Das ist kein Modulbasierter Layer).

4. Mapping

   • Die Daten werden vom externen Systemformat in das OTRS-interne Format transformiert, wie es in der Mapping-Konfiguration für diese Operation angegeben ist (Mapping für eingehende Anfragedaten).

   • Die bereits transformierten Daten werden an den Provider zurückgegeben.

5. Interne Daten

   • Sobald die Daten, transformiert und aufbereitet wurden, werden diese an die Operation weitergeleitet. (Das ist kein Modulbasierter Layer).

6. Operation

   • Empfängt und prüft Daten.

   • Führt eine Benutzerzugangskontrolle durch.

   • Führt die Aktion aus.

OTRS-Antwort:

1. Operation

   • Liefert das Ergebnis an den Provider.

2. Interne Daten

   • Von der Operation zurückgegebene Daten.

3. Mapping

   • Die Daten werden in das Format des entfernten Systems zurückverwandelt, wie in der Mapping-Konfiguration angegeben (Mapping für ausgehende Antwortdaten).

   • Die bereits transformierten Daten werden an den Provider zurückgegeben.

4. Externe Daten

   • Daten in umgewandelter Form und vorbereitet zur Weiterleitung an den Netzverkehr als Antwort.

5. Netzwerktransport

   • Empfängt die Daten bereits im Format des entfernten Systems.

   • Konstruiert eine gültige Antwort für diesen Netztransport-Typ.

6. HTTP-Antwort

   • Die Antwort wird an den Web Service Client zurückgeschickt.

   • Im Falle eines Fehlers wird eine Fehlerantwort an das externe System gesendet (z.B. SOAP-Fehler, HTTP-Fehler, etc.).

OTRS als Requester

OTRS Anfrage:

1. Event Trigger Handler

   • Basierend auf der Konfiguration des Web Services wird entschieden ob die Anfrage synchron oder asynchron ist.

     • Synchron

       • Es erfolgt ein direkter Aufruf an den Requester, um eine neue Anfrage zu erstellen und sie durch die Schichten zu leiten.

     • Asynchron

       • Erstellen Sie einen neuen Task für das Generic Interface (Requester) für den OTRS-Daemon (indem Sie die Ausführung der Anfrage an den Scheduler-Daemon delegieren, könnte die Benutzererfahrung stark verbessert werden, da ansonsten die gesamte Zeit, die für die Vorbereitung der Anfrage und die Remote-Ausführung benötigt wird, zu den OTRS-Ereignissen, die diese Anfragen auslösen, hinzugefügt wird).

       • In seinem nächsten Zyklus liest der OTRS-Daemon-Prozess die neue Aufgabe und erstellt einen Aufruf an den Requester, der eine neue Anfrage erstellt und diese dann durch die Schichten leitet.

2. Invoker

   • Empfängt Daten von dem Event.

   • Überprüft empfangene Daten (wenn benötigt).

   • Rufen Sie Kernmodule auf, um die Daten zu ergänzen (falls erforderlich).

   • Rückgabe der Datenstruktur der Anforderung oder Senden eines Stopp-Kommunikationssignals an den Requester, um die Anforderung ordnungsgemäß abzubrechen.

3. Interne Daten

   • Daten, wie sie vom Invoker übergeben werden (es handelt sich nicht um eine modulbasierte Schicht).

4. Mapping

   • Die Daten werden in das Format des entfernten Systems zurückverwandelt, wie in der Mapping-Konfiguration angegeben (Mapping für ausgehende Antwortdaten).

   • Die bereits transformierten Daten werden an den Provider zurückgegeben.

5. Externe Daten

   • Die Daten werden umgewandelt und zum Senden an das entfernte System vorbereitet.

6. Netzwerktransport

   • Empfängt den Namen des entfernten Vorgangs und die bereits in das Format des entfernten Systems transformierten Daten vom Requester.

   • Konstruiert eine gültige Anfrage für die Netzwerkübertragung.

   • Sendet die Anfrage an das entfernte System und wartet auf die Antwort.

Remote Antwort:

1. Netzwerktransport

   • Empfängt die Antwort und dekodiert die Nutzdaten.

   • Sendet die Daten zurück zu dem Requester.

2. Externe Daten

   • Daten, wie sie vom entfernten System empfangen wurden.

3. Mapping

   • Die Daten wird aus dem Fremdsystem-Format in das interne OTRS Format, wie in der Mapping-Konfiguration für diesen Vorgang (Mapping für eingehende Anforderungsdaten) spezifiziert, umgewandelt.

   • Die bereits transformierten Daten werden an den Provider zurückgegeben.

4. Interne Daten

   • Sobald die Daten, transformiert und aufbereitet wurden, werden diese an den Requester zurückgeschickt.

5. Invoker

   • Empfängt die zurückgegebenen Daten.

   • Verarbeitet die Daten als speziell von jedem Invoker benötigt werden (inklusive Fehlerbehandlung falls vorhanden).

   • Gibt das Ergebnis und die Daten des Invokers an den Requester.

6. Event-Handler oder OTRS-Daemon

   • Empfängt die Daten vom Requester. Im Falle des OTRS-Daemons können diese Daten Informationen enthalten, um eine Aufgabe in der Zukunft zu erstellen.

OTRS als Provider – HTTP::REST

Die Konfiguration könnte etwas komplizierter sein, da sie für jeden konfigurierten Vorgang dynamisch wächst, indem die Standard-Transporteinstellungen um die Routenzuordnung für jeden Vorgang und die gültigen Anforderungsmethoden für jeden Vorgang ergänzt werden.

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit einem Sternchen gekennzeichneten Felder sind Pflichtfelder.

Routen-Mapping für Operation ‚<OperationsName>‘ *

Definiert die Route, die zu der Operation gemappt werden soll. Variablen, die mit einem ‚:‘ markiert sind, werden zu dem eingegeben Namen gemappt und mit den anderen Variablen an die Funktion übergeben. (z.B.: /Ticket/:TicketID).

In dieser Einstellung wird ein Ressourcenpfad festgelegt. Dieser Pfad muss entsprechend den Bedürfnissen des Web Service definiert werden, da der Pfad in Verbindung mit der HTTP-Anforderungsmethode die auszuführende generische Schnittstellenoperation bestimmt.

Pfad kann Variablen in der Form von :<VariableName> enthalten. Jeder Pfadstring, der auf die Position des Variablennamens passt, wird unter Verwendung des in dieser Einstellung definierten Variablennamens zur Nutzlast der Anfrage hinzugefügt. Beispiele:

Gültige Anfragen für /Resource-Routen-Mapping:

https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource
https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource?Param1=One

Gültige Anfragen für /Resource-Routen-Mapping:

https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/
https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/OtherResource
https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/OtherResource?Param1=One

Gültige Anfragen für /Resource/:ID-Routen-Mapping:

https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/1
https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/1?Param1=One

In beiden Fällen wird ID = 1 als Teil des Payloads an die Operation gesendet. Im zweiten Fall wird auch Param1 = Ein hinzugefügt, abhängig von der HTTP-Anforderungsmethode werden andere Parameter hinzugefügt, wenn sie als JSON-String im Anfragekopf enthalten sind.

Ungültige Anfragen für /Resource/:ID-Routen-Mapping:

https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource
https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource?Param1=One

Gültige Anfragen für /Resource/AndereRessource/:ID/:Farbe-Routen-Mapping:

https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/OtherResource/1/Red
https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/OtherReosurce/123/Blue?Param1=One

Im ersten Beispiel ist ID = 1 und Farbe = Rot, während im zweiten Beispiel ID = 123 und Farbe = Blau ist.

Gültige Anfragen für /Resource/AndereRessource/:ID/:Color-Routen-Mapping:

https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/1
https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/OtherResource/1
https://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/OtherResource/1?Param1=One

Im ersten Beispiel fehlt der Teil des Pfades /OtherResource sowie die Variable :Color. Im zweiten Beispiel fehlt nur die Variable :Color.

Gültige Anfragemethoden für Operation ‚<Operationsname>‘

Beschränken Sie diese Operation auf bestimmte Anfragemethoden. Wenn keine Anfragemethode ausgewählt ist, werden alle Anfragen akzeptiert.

Die HTTP-Anfragemethoden zur Bestimmung der zu verwendenden Operation zusammen mit der Routenzuordnung, mögliche Optionen: CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT und TRACE.

Völlig unterschiedliche Vorgänge können genau denselben Zuordnungspfad verwenden, aber die Anforderungsmethode muss für jeden Vorgang eindeutig sein, damit der für jeden Vorgang zu verwendende Vorgang korrekt bestimmt werden kann.

Maximale Nachrichtenlänge *

Gibt die maximale Größe (in Bytes) für REST-Nachrichten an, die von OTRS verarbeitet werden.

Keep-Alive senden *

Bestimmt, ob eingehende Verbindungen geschlossen oder am Leben erhalten werden sollen.

Zusätzliche Antwort-Header (alle Operationen)

Optional können Sie zusätzliche Antwort-Header für alle Vorgänge definieren. Diese können verwendet werden, um statische Kopfzeilenwerte zu jeder Antwort hinzuzufügen. Klicken Sie einfach auf die Schaltfläche Kopfzeile hinzufügen und füllen Sie die Felder für Kopf und Wert aus. Die Anzahl der zusätzlichen Kopfzeilen ist nicht begrenzt.

Kopfwertvariablen, die mit einem : gekennzeichnet sind, werden durch den entsprechenden Datenwert ersetzt (z.B. :TicketID wird zu 1).

Zusätzliche Antwort-Header (Operation-spezifisch)

Diese Kopfzeilen werden in den Antworten für den ausgewählten Vorgang gesetzt. Der Zweck dieser Einstellung ist derselbe wie oben.

Kopfwertvariablen, die mit einem : gekennzeichnet sind, werden durch den entsprechenden Datenwert ersetzt (z.B. :TicketID wird zu 1).

OTRS als Provider – HTTP::SOAP

Es ist recht einfach, das HTTP::SOAP-Protokoll als Provider zu konfigurieren.

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit einem Sternchen gekennzeichneten Felder sind Pflichtfelder.

Überprüfe SOAPAction *

Setzen Sie diesen Wert auf Ja, um den empfangenen SOAPAction-Header zu prüfen (wenn er nicht leer ist). Setzen Sie den Wert auf Nein, um den empfangenen SOAPAction-Header zu ignorieren.

SOAPAction-Schema *

Wählen Sie, wie die SOAPAction aufgebaut sein soll. Einige Web Services senden einen bestimmten Aufbau.

SOAPAction-Trenner *

Zeichen, das als Trennzeichen zwischen Namensraum und SOAP-Operation verwendet wird. Normalerweise verwenden .Net-Web Services / als Trennzeichen.

Namensraum *

URI, die SOAP-Methoden einen Kontext gibt und damit Mehrdeutigkeiten auflöst.

Anfragen-Namensschema *

Wählen Sie aus, wie der Wrapper der SOAP-Anfragefunktion aufgebaut sein soll. FunctionName wird als Beispiel für den tatsächlichen Invoker oder Operationsnamen verwendet. FreeText wird als Beispiel für den tatsächlich konfigurierten Wert verwendet.

Antwort-Namensschema *

Wählen Sie aus, wie der Wrapper der SOAP-Antwortfunktion aufgebaut sein soll. FunctionName wird als Beispiel für den tatsächlichen Invoker oder Operationsnamen verwendet. FreeText wird als Beispiel für den tatsächlich konfigurierten Wert verwendet.

Maximale Nachrichtenlänge *

Gibt die maximale Größe (in Bytes) für SOAP-Nachrichten an, die von OTRS verarbeitet werden.

Zusätzliche Antwort-Header (alle Operationen)

Optional können Sie zusätzliche Antwort-Header für alle Vorgänge definieren. Diese können verwendet werden, um statische Kopfzeilenwerte zu jeder Antwort hinzuzufügen. Klicken Sie einfach auf die Schaltfläche Kopfzeile hinzufügen und füllen Sie die Felder für Kopf und Wert aus. Die Anzahl der zusätzlichen Kopfzeilen ist nicht begrenzt.

Kopfwertvariablen, die mit einem : gekennzeichnet sind, werden durch den entsprechenden Datenwert ersetzt (z.B. :TicketID wird zu 1).

Zusätzliche Antwort-Header (Operation-spezifisch)

Diese Kopfzeilen werden in den Antworten für den ausgewählten Vorgang gesetzt. Der Zweck dieser Einstellung ist derselbe wie oben.

Kopfwertvariablen, die mit einem : gekennzeichnet sind, werden durch den entsprechenden Datenwert ersetzt (z.B. :TicketID wird zu 1).

Zusätzliche Antwort SOAP-Namensräume (alle Operationen)

Diese Namensräume werden in jeder Antwort verwendet.

Zusätzliche Antwort SOAP-Namensräume (Operation-spezifisch)

Diese Namensräume werden in den Antworten für diese spezielle Operation verwendet.

Sortierungsoptionen

Sortierung für ausgehende XML-Felder (Struktur, die unter dem Wrapper für den Funktionsnamen beginnt) – siehe Dokumentation für SOAP-Transport.

Web Service Operation

Die Aktionen, die durchgeführt werden können, wenn Sie OTRS als Provider nutzen, werden Operationen genannt. Jede Operation gehört zu einem Controller. Controller sind Sammlungen von Operationen oder Invokern, normalerweise benötigen Operationen aus demselben Controller ähnliche Einstellungen und teilen sich denselben Konfigurationsdialog. Aber jede Operation kann auch unabhängige Konfigurationsdialoge haben, falls erforderlich.

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit einem Sternchen gekennzeichneten Felder sind Pflichtfelder.

Name *

Der Name der Ressource. In dieses Feld können beliebige Zeichen eingegeben werden, einschließlich Großbuchstaben und Leerzeichen. Der Name wird in der Übersichtstabelle angezeigt.

Beschreibung

Fügen Sie dieser Ressource zusätzliche Informationen hinzu. Es wird empfohlen, dieses Feld als Beschreibung der Ressource zur besseren Übersichtlichkeit immer mit einem vollständigen Satz zu füllen, da der Kommentar auch in der Übersichtstabelle angezeigt wird.

Operation-Backend

Dieses OTRS-Operation-Backend-Modul wird intern aufgerufen, um die Anforderung zu bearbeiten und Daten für die Antwort zu generieren.

Das Backend des Vorgangs ist vorausgefüllt und kann nicht bearbeitet werden. Sie sehen diesen Parameter, wenn Sie den Vorgang auf dem Bearbeitungsbildschirm des Web Service auswählen. Das Feld ist nur informativ.

Mapping für eingehende Anfragedaten

Die Daten der eingehenden Anfrage werden von diesem Mapping verarbeitet, um sie so umzuformen, wie die OTRS-Operation sie benötigt.

Mapping für ausgehende Antwortdaten

Die Antwortdaten werden von diesem Mapping verarbeitet, um sie so umzuformen, wie das entfernte System die Daten benötigt.

Ticketdaten einbinden

Ob Ticket-Daten in die Antwort aufgenommen werden sollen oder nicht.

Zuordnungen sind Felder, die normalerweise bei jedem Vorgang erscheinen, aber andere spezielle Felder können in nicht standardmäßigen Konfigurationsdialogen erscheinen, um spezifische Anforderungen des Vorgangs zu erfüllen.

Normalerweise gibt es zwei Mapping-Konfigurationsabteilungen bei jeder Operation, eine für die ankommenden Daten und eine für die ausgehenden Daten. Sie können verschiedene Mapping-Arten (Backends) für jede Mapping-Richtung auswählen, da deren Konfiguration unabhängig voneinander und unabhängig vom Operations-Backend ist. Die normale und am meisten übliche Praxis ist es, dass die Operation in beiden Fällen die gleiche Mapping-Art nutzt (mit umgekehrter Konfiguration). Die komplette Mapping-Konfiguration wird in einer extra Anzeige, die auf die Mapping-Art drauf ankommt, gemacht.

Im linken Teil der Ansicht haben Sie in der Spalte „Aktion“ die Möglichkeit, zum Web Service zurückzukehren (wobei alle Änderungen seit der letzten Speicherung verworfen werden) und zu löschen. Wenn Sie auf die letzte Option klicken, wird ein Dialogfeld geöffnet, in dem Sie gefragt werden, ob Sie den Vorgang entfernen möchten. Klicken Sie auf die Schaltfläche Löschen, um das Entfernen des Vorgangs und seiner Konfiguration zu bestätigen, oder klicken Sie auf die Schaltfläche Abbrechen, um den Löschdialog zu schließen.

Generic Link Object Invoker

Zusätzlich zur Funktionalität des Configuration Items bietet der Generic:: LinkObject -Invoker die Funktionalität, Objekte wie Tickets mit Configuration Items oder Configuration Items mit Configuration Items zu verknüpfen. Der Invoker kann sich daran gewöhnen, neue Links von einem Remote System abzurufen oder die bereitgestellten Links synchron zu halten und entfernte Links aus der OTRS-Datenbank zu löschen. Der Verknüpfung verschiedener Objekte sind keine Grenzen gesetzt.

Um verschiedene Objekte miteinander zu verknüpfen, benötigen die folgenden Mapping-Schlüssel Werte:

- SourceClass
- SourceObject
- TargetClass
- TargetObject
- Type

Die OTRS-interne Objekt-ID kann direkt mit den Schlüsseln SourceKey und TargetKey versehen werden oder kann durch die Angabe der OTRS-Objektnummer mit den Schlüsseln SourceNumber und TargetNumber nachgeschlagen werden.

Um das OTRS mit dem entfernten System synchron zu halten, ist es möglich, verschiedene Link-Kombinationen, auszuwählen, die synchronisiert werden sollen. Das heißt, wenn eine Remote-Link-Kombination entfernt wurde, wird auch der lokale Link entfernt.

Die Synchronisation von Configuration Item-Klassen kann durch Auswahl der Klassen, die synchronisiert werden sollen, aus der Liste in der Invoker-Administrationsansicht eingeschränkt werden.

Generischer Operations Invoker

Mit dem Invoker Generic::Operations können Sie Phasen definieren, in denen jede als Phase definierte Zuordnung nebeneinander ausgeführt wird. Der Ausgang einer Phase wird der Eingang der nächsten Phase sein.

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit einem Sternchen gekennzeichneten Felder sind Pflichtfelder.

Name *

Der Name der Ressource. In dieses Feld können beliebige Zeichen eingegeben werden, einschließlich Großbuchstaben und Leerzeichen. Der Name wird in der Übersichtstabelle angezeigt.

Beschreibung

Fügen Sie dieser Ressource zusätzliche Informationen hinzu. Es wird empfohlen, dieses Feld als Beschreibung der Ressource zur besseren Übersichtlichkeit immer mit einem vollständigen Satz zu füllen, da der Kommentar auch in der Übersichtstabelle angezeigt wird.

Operation-Backend

Dieses OTRS-Operation-Backend-Modul wird intern aufgerufen, um die Anforderung zu bearbeiten und Daten für die Antwort zu generieren.

Das Backend des Vorgangs ist vorausgefüllt und kann nicht bearbeitet werden. Sie sehen diesen Parameter, wenn Sie den Vorgang auf dem Bearbeitungsbildschirm des Web Service auswählen. Das Feld ist nur informativ.

Mapping für ausgehende Antwortdaten

Die Antwortdaten werden von diesem Mapping verarbeitet, um sie so umzuformen, wie das entfernte System die Daten benötigt.

Mapping für eingehende Anfragedaten

Die Daten der eingehenden Anfrage werden von diesem Mapping verarbeitet, um sie so umzuformen, wie die OTRS-Operation sie benötigt.

Benutzer für Operationen

Diese Operation wird unter Verwendung dieses Benutzers ausgeführt.

Phasen

Hier können Sie Abschnitte hinzufügen, die nebeneinander bearbeitet werden sollen. Über die Schaltfläche Phasen hinzufügen können Sie so viele Phasen wie nötig hinzufügen.

Klicken Sie auf die Schaltfläche Speichern, damit neben jeder Phase eine Schaltfläche Konfigurieren erscheint. Hier können Sie für jede Phase ein XSLT-Stylesheet hinzufügen.

Ereignisauslöser

Dieser Invoker wird von den konfigurierten Ereignissen ausgelöst.

Ereignisauslöser hinzufügen

Um einen neues Ereignis hinzuzufügen, wählen Sie bitte das Objekt und den Ereignisnamen und klicken Sie auf den +-Schaltfläche.

Configuration Item Invoker

Der Invoker ITSM:: ConfigItem bietet die Funktionalität, eine Liste von Configuration Items von einem Remote-System mit der generischen Schnittstelle anzufordern. Eine vollständige Zuordnung zwischen dem Namen von Remote Value Keys zu den lokalen Configuration-Item-Klassendefinitionen ist möglich. Um die Möglichkeit zu geben, alle Klassenattribute im Mapping zu definieren, wird ein erweitertes Mapping bereitgestellt.

Für die Handhabung von Remote-Configuration-Items und Links wird mit dieser Funktion eine erweiterte Zuordnung bereitgestellt. Um diese Funktionalität zu nutzen, wählen Sie das ITSMConfigItem in der Mapping-Auswahlbox.

Eines dieser fortgeschrittenen Mapping-Features sind statische Werte. Diese ermöglichen es, statische Werte für definierte Schlüssel zu definieren, z.B. die Einstellung der Configuration Item-Klasse für jedes Element. Diese Einträge können vom entfernten System gesendete Daten überschreiben.

Ein weiteres Merkmal des erweiterten Mappings ist die Umwandlung von Zeichenketten in Listenstrukturen. Für die Erstellung einer Liste aus einem String kann ein Listentrennzeichen definiert werden, z.B. ;. Das Trennfeld nimmt einen regulären Ausdruck, der komplexere Trennzeichen wie ;(?:\s+)?` (ein ; optional gefolgt von mehreren Leerzeichen) möglich macht.

Es ist möglich zu definieren, wo der Index der Elemente in der Configuration Item Struktur stattfinden soll. Dazu muss der Platzhalter ####INDEX##### in der Schlüsselabbildung platziert werden. Die Konfiguration im Screenshot würde die getrennte IP-Adressenliste jeweils in einer neuen Schnittstelle speichern. Wenn in der Abbildung kein Index definiert ist, erhöht der Index den Hauptattributzähler, wie ein Suffix.

Das Configuration Item Number-Attribut wird verwendet, um die logische Verbindung zwischen den Remote-Daten und den in der OTRS-Datenbank gespeicherten Daten herzustellen. Um Configuration Items mit diesem Invoker zu erstellen und zu aktualisieren, sind Werte für die folgenden Schlüssel erforderlich:

- Name
- Class
- Number
- DeploymentState
- IncidentState

Die Werte für diese Schlüssel (außer Nummer) können statisch sein oder vom entfernten System bereitgestellt werden.

Configuration Item Synchronization Invoker

Der ITSM::ConfigItemSync -Invoker bietet die Funktionalität, Configuration Items zwischen zwei OTRS-Instanzen mit einem speziellen Synchronisierungs-Invoker zu synchronisieren. Dieser Invoker ermöglicht es, Invoker für das Erstellen, Aktualisieren und Löschen von Synchronisationen zu definieren, die bei Bedarf automatisch aufgerufen werden.

Um Configuration Items zwischen zwei Systemen zu synchronisieren, ist es erforderlich, einen Web Service mit einem Invoker vom Typ ITSM::ConfigItemSync hinzuzufügen. Dieser Invoker ist der grundlegende (Such-) Invoker, der verwendet wird, um ITSM-Objektsuchen auf dem entfernten System durchzuführen, um Configuration Items zu bestimmen, die geändert werden sollen.

Es arbeitet bei jeder Synchronisierungsaktion mit zwei Schritten:

1. Abhängig von der Änderung, die im lokalen System vorgenommen wurde (Hinzufügen, Aktualisieren oder Löschen eines Configuration Items), führt der Invoker zunächst eine verwandte Suche auf dem entfernten System durch, um festzustellen, ob es zum Erstellen, Aktualisieren oder Löschen eines entfernten Configuration Items erforderlich ist.

2. Im zweiten Schritt wird ein zugehöriger Invoker für Erstellungsaktionen, Aktualisierungsaktionen oder Löschaktionen aufgerufen, der die wichtigsten Änderungen auf dem entfernten System ausführt. Diese Invoker müssen ebenfalls erstellt werden und müssen vom Invoker-Typ ITSM::ConfigItem sein, um sicherzustellen, dass die Kommunikation einwandfrei funktioniert.

Siehe die beiliegende Übersicht der Beispiel-Invokers:

Innerhalb der Konfiguration des Such-Invokers müssen die Invoker, die die Änderungen durchführen sollen, für jede Aktion in den entsprechenden Dropdown-Menüs separat konfiguriert werden.

Wenn ein Invoker nicht für die entsprechende Aktion konfiguriert ist, wird er ausgelassen. Der konfigurierte Invoker wird in jeder Dropdown-Liste aufgeführt und kann leicht für die verschiedenen Aktionen ausgewählt werden.

Die verschiedenen Invoker müssen ihre Daten abbilden. Damit dies richtig funktioniert, wird empfohlen, das Mapping-Modul ITSMConfigItem zu verwenden, das in dieser Dokumentation beschrieben wird. Tatsächlich ist es aber auch möglich, andere Arten von Mappings wie XSLT zu verwenden, wenn es richtig konfiguriert ist.

Da diese Struktur entfernte Systeme aufruft, ist es erforderlich, zumindest die Verbindungs-Anmeldedaten für den Zugriff auf die entfernte CMDB zu konfigurieren.

Alle anderen Konfigurationen können optional eingestellt werden, aber sie sind nicht erforderlich, damit die Grundfunktion funktioniert.

Um sicherzustellen, dass der Such-Invoker nur auf bestimmte Ereignisse hört, erweitert diese Funktionalität die Möglichkeiten der Invoker-Ereignisfilterfunktion von OTRS, mit der zusätzliche Bedingungen zu den Event Triggern hinzugefügt werden können, die für den Such-Invoker konfiguriert sind. Ein Beispiel könnte sein, dass nur Configuration Items der ITSM-Klasse Computer mit dem Remote-System synchronisiert werden.

Die Konfiguration des entfernten Systems, das synchronisiert wird, muss nicht speziell sein, aber dafür muss es mindestens eine Operation für die Suchausführungen und eine separate Operation für jede Synchronisierungsaktion, die ausgeführt werden muss, bereitstellen.

Ticket Invoker

Diese Funktion fügt die Funktionalität der Invokers TicketCreate und TicketUpdate für Webservices hinzu.

Darüber hinaus folgt das Paket HTTP-Umleitungsantworten (HTTP-Code 301, 307 und 308) für die ausgehende Kommunikation von HTTP::REST- und HTTP::SOAP-basierten Webdiensten.

Darüber hinaus ermöglicht das Paket das Senden von leeren HTTP-Anfragen (POST, PUT, PATCH) für die ausgehende Kommunikation von HTTP::REST-basierten Webservices.

Die Invoker TicketCreate und TicketUpdate geben die kompletten Ticket- und Artikeldaten basierend auf der Ticket-ID und der Artikel-ID des ausgelösten Ereignisses zurück.

Bereiten Sie den Aufruf des konfigurierten Remote-Websrvice vor. Ereignisdaten:

my $Result = $InvokerObject->PrepareRequest(
    Data => {                                               # data payload
        TicketID => 123,
        ArticleID => 123,                                   # optional
    },
);

Invoker-Resultat:

{
    Data => {
        Ticket => {
            Title         => 'some ticket title',
            Queue         => 'some queue name',
            Lock          => 'some lock name',              # optional
            Type          => 'some type name',              # optional
            Service       => 'some service name',           # optional
            SLA           => 'some SLA name',               # optional
            State         => 'some state name',
            Priority      => 'some priority name',
            Owner         => 'some user login',             # optional
            Responsible   => 'some user login',             # optional
            CustomerUser  => 'some customer user login',
            PendingTime {       # optional
                Year   => 2011,
                Month  => 12
                Day    => 03,
                Hour   => 23,
                Minute => 05,
            },
        },
        Article => {
            SenderType       => 'some sender type name',    # optional
            AutoResponseType => 'some auto response type',  # optional
            From             => 'some from string',         # optional
            Subject          => 'some subject',
            Body             => 'some body'
            ContentType      => 'some content type',        # ContentType or MimeType and Charset is required
            MimeType         => 'some mime type',
            Charset          => 'some charset',
            TimeUnit         => 123,                        # optional
        },
        DynamicField => [                                   # optional
            {
                Name   => 'some name',
                Value  => 'Value',                          # value type depends on the dynamic field
            },
            # ...
        ],
         Attachment => [
            {
                Content     => 'content'                    # base64 encoded
                ContentType => 'some content type'
                Filename    => 'some fine name'
            },
            # ...
        ],
    },
};

OTRS als Requester – HTTP::REST

Im Fall von HTTP::REST wächst diese Konfiguration auch dynamisch in Abhängigkeit von den konfigurierten Invokern. Die Authentifizierungs- und SSL-Optionen ähneln denen in HTTP::SOAP.

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit einem Sternchen gekennzeichneten Felder sind Pflichtfelder.

Endpunkt *

URI des entfernten Systems, um einen bestimmten Ort für den Zugriff auf einen Web Service anzugeben.

Timeout *

Timeout-Wert für Anfragen.

Authentifizierung

Ein optionaler Authentifizierungsmechanismus für den Zugriff auf das entfernte System. Wählen Sie einen Authentifizierungsmechanismus aus der Liste aus und es werden zusätzliche Felder angezeigt.

Anmeldeinformation *

Wählen Sie die Anmeldeinformation, die Sie in der Ansicht Anmeldedaten hinzugefügt haben. Klicken Sie auf die Schaltfläche Anmeldeinformation hinzufügen, um die Ansicht für die Verwaltung der Anmeldeinformation zu öffnen.

Zertifikat der Certification Authority (CA)

Voller Pfad und Dateiname der Datei der Certification Authority (CA), welche das Zertifikat signiert hat.

Verzeichnis mit Certification Autorities (CA)

Voller Pfad und Dateiname des CA-Verzeichnisses, in dem CA-Zertifikate gespeichert sind.

Proxy-Optionen verwenden *

Optionen für die Verwendung eines Proxy zum Zugriff auf das entfernte System anzeigen oder verbergen.

Controller-Mapping für Invoker ‚<InvokerName>‘ *

Der Controller, an den der Invoker Anfragen senden soll.

Variablen, die mit einem : gekennzeichnet sind, werden durch den Datenwert ersetzt und mit der Anfrage weitergegeben (z.B. /Ticket/:TicketID?UserLogin=:UserLogin&Password=:Password).

Gültiger Anfragebefehl für Invoker ‚<InvokerName>‘

Ein spezifisches HTTP-Kommando, das für Anfragen mit diesem Invoker zu verwenden ist (optional).

Standardbefehl

Der Standard-HTTP-Befehl, der für die Anfragen verwendet werden soll. Mögliche Optionen: CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT und TRACE. Wenn kein Befehl ausgewählt wird, wird Standardbefehl verwendet.

Zusätzliche Anfrage-Header (alle Invoker)

Optional können Sie zusätzliche Anfrage-Header für alle Invoker definieren. Diese können verwendet werden, um statische Kopfzeilenwerte zu jeder Anfrage hinzuzufügen. Klicken Sie einfach auf die Schaltfläche Kopfzeile hinzufügen und füllen Sie sowohl die Kopfzeilen- als auch die Wertfelder aus. Die Anzahl der zusätzlichen Kopfzeilen ist nicht begrenzt.

Kopfwertvariablen, die mit einem : gekennzeichnet sind, werden durch den entsprechenden Datenwert ersetzt (z.B. :TicketID wird zu 1).

Zusätzliche Anfrage-Header (Invoker-spezifisch)

Diese Kopfzeilen werden in Anfragen für den ausgewählten Invoker gesetzt. Der Zweck dieser Einstellung ist derselbe wie oben.

Kopfwertvariablen, die mit einem : gekennzeichnet sind, werden durch den entsprechenden Datenwert ersetzt (z.B. :TicketID wird zu 1).

Wenn mindestens zwei Invoker hinzugefügt werden, wird die Ansicht des Requester-Transports für HTTP::REST um zwei Felder erweitert.

Controller-Mapping für Invoker ‚<InvokerName>‘ *

In dieser Einstellung wird ein Ressourcenpfad festgelegt. Dieser Pfad muss entsprechend den Erfordernissen des entfernten Web Service und nach dessen Definition festgelegt werden.

Der Pfad kann Variablen in der Form :<Variablenname> enthalten. Jeder Variablenname, der mit den aktuellen (zu sendenden) Daten übereinstimmt, wird durch den entsprechenden Datenwert ersetzt. Diese übereinstimmenden Variablennamen und -werte werden aus den aktuellen Daten entfernt. Je nach HTTP-Anforderungsbefehl können die verbleibenden Daten als JSON-String im Anforderungskörper oder als Abfrageparameter innerhalb des URI gesendet werden.

Beispiele für Daten Var1 = Eins, Var2 = Zwei, Var3 = Drei und Var4 = Vier.

• Controller-Zuordnung: /Ressource, nach Ersetzungen: /Resource, verbleibende Daten: Var1 = Eins, Var2 = Zwei, Var3 = Drei und Var4 = Vier

• Controller-Zuordnung: /Ressource/:Var1, nach Ersetzungen: /Resource/Eins, verbleibende Daten: Var2 = Zwei, Var3 = Drei und Var4 = Vier

• Controller-Zuordnung: /Resource/:Var1?Param1=:Var2&Var3=:Var3, nach Ersetzungen: /Resource/One?Param1=Two&Var3=Three, verbleibende Daten: Var4 = Vier

Gültiger Anfragebefehl für Invoker ‚<InvokerName>‘

Hiermit wird die zu verwendende HTTP-Anforderungsmethode festgelegt. Mögliche Optionen: CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT und TRACE. Wenn kein Befehl ausgewählt wird, wird Standardbefehl verwendet.

OTRS als Requester – HTTP::SOAP

Für den Requester HTTP::SOAP-Netzwerktransport sind weitere Felder zu setzen.

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit einem Sternchen gekennzeichneten Felder sind Pflichtfelder.

Endpunkt *

URI des entfernten Systems, um einen bestimmten Ort für den Zugriff auf einen Web Service anzugeben.

Timeout *

Timeout-Wert für Anfragen.

Setzen von SOAPAction *

Auf Ja gesetzt, um einen gefüllten SOAPAction-Header zu senden. Setzen Sie den Wert auf Nein, um einen leeren SOAPAction-Header zu senden.

SOAPAction-Schema *

Wählen Sie aus, wie die SOAPAction aufgebaut sein soll. Einige Web Services erfordern einen bestimmten Aufbau.

SOAPAction-Trenner *

Zeichen, das als Trennzeichen zwischen Namensraum und SOAP-Operation verwendet wird. Normalerweise verwenden .Net-Web Services / als Trennzeichen.

Namensraum *

URI, die SOAP-Methoden einen Kontext gibt und damit Mehrdeutigkeiten auflöst.

Anfragen-Namensschema *

Wählen Sie aus, wie der Wrapper der SOAP-Anfragefunktion aufgebaut sein soll. FunctionName wird als Beispiel für den tatsächlichen Invoker oder Operationsnamen verwendet. FreeText wird als Beispiel für den tatsächlich konfigurierten Wert verwendet.

Antwort-Namensschema *

Wählen Sie aus, wie der Wrapper der SOAP-Antwortfunktion aufgebaut sein soll. FunctionName wird als Beispiel für den tatsächlichen Invoker oder Operationsnamen verwendet. FreeText wird als Beispiel für den tatsächlich konfigurierten Wert verwendet.

Kodierung

Die Zeichenkodierung für SOAP-Nachrichteninhalte.

Authentifizierung

Ein optionaler Authentifizierungsmechanismus für den Zugriff auf das entfernte System. Wählen Sie einen Authentifizierungsmechanismus aus der Liste aus und es werden zusätzliche Felder angezeigt.

Anmeldeinformation *

Wählen Sie die Anmeldeinformation, die Sie in der Ansicht Anmeldedaten hinzugefügt haben. Klicken Sie auf die Schaltfläche Anmeldeinformation hinzufügen, um die Ansicht für die Verwaltung der Anmeldeinformation zu öffnen.

Zertifikat der Certification Authority (CA)

Voller Pfad und Dateiname der Datei der Certification Authority (CA), welche das Zertifikat signiert hat.

Verzeichnis mit Certification Autorities (CA)

Voller Pfad und Dateiname des CA-Verzeichnisses, in dem CA-Zertifikate gespeichert sind.

Proxy-Optionen verwenden *

Optionen für die Verwendung eines Proxy zum Zugriff auf das entfernte System anzeigen oder verbergen.

Zusätzliche Anfrage-Header (alle Invoker)

Optional können Sie zusätzliche Anfrage-Header für alle Invoker definieren. Diese Kopfzeilen werden in jeder Anfrage gesetzt.

Kopfwertvariablen, die mit einem : gekennzeichnet sind, werden durch den entsprechenden Datenwert ersetzt (z.B. :TicketID wird zu 1).

Zusätzliche Anfrage-Header (Invoker-spezifisch)

Diese Kopfzeilen werden in Anfragen für den ausgewählten Invoker gesetzt. Der Zweck dieser Einstellung ist derselbe wie oben.

Kopfwertvariablen, die mit einem : gekennzeichnet sind, werden durch den entsprechenden Datenwert ersetzt (z.B. :TicketID wird zu 1).

Zusätzliche Anfrage SOAP-Namensräume (alle Invoker)

Diese Namensräume werden in jeder Anfrage verwendet.

Zusätzliche Anfrage SOAP-Namensräume (Invoker-spezifisch)

Diese Namensräume werden in Anfragen für diesen speziellen Invoker verwendet.

Sortierungsoptionen

Sortierung für ausgehende XML-Felder (Struktur, die unter dem Wrapper für den Funktionsnamen beginnt) – siehe Dokumentation für SOAP-Transport.

XSLT-Mapping

XSLT-Stylesheet *

Hier können Sie Ihren XSLT-Mapping-Code hinzufügen oder bearbeiten.

Das Bearbeitungsfeld ermöglicht die Benutzung verschiedener Funktionen wie automatische Formatierung, Veränderung der Fenstergröße sowie Tag- und Klammer-Vervollständigung.

Schlüsselattribut benutzen

Für eingehende Daten legt diese Option fest, ob XML-Schlüsselattribute in eine Perl-Datenstruktur konvertiert oder ignoriert werden.

Beispiel: Eingehende XML-Daten

<Article>
    <Subject>some subject</Subject>
    <Body>some body</Body>
    <ContentType>text/plain; charset=utf8</ContentType>
    <TimeUnit>1</TimeUnit>
</Article>
<Attachment>
    <Content>someTestData</Content>
    <ContentType>text/plain</ContentType>
    <Filename>test1.txt</Filename>
</Attachment>
<Attachment Content="someTestData" ContentType="text/plain" Filename="test2.txt" />

Resultierende Perl-Daten mit deaktiviertem Schlüsselattribut verwenden:

$VAR1 = {
    Article => {
        Body => 'some body',
        ContentType => 'text/plain; charset=utf8',
        Subject => 'some subject',
        TimeUnit => '1',
    },
    Attachment => [
        {
            Content => 'someTestData',
            ContentType => 'text/plain',
            Filename => 'test1.txt',
        },
        {},
    ],
};

Resultierende Perl-Daten mit Schlüsselattribut verwenden aktiviert:

$VAR1 = {
    Article => {
        Body => 'some body',
        ContentType => 'text/plain; charset=utf8',
        Subject => 'some subject',
        TimeUnit => '1',
    },
    Attachment => [
        {
            Content => 'someTestData',
            ContentType => 'text/plain',
            Filename => 'test1.txt',
        },
        {
            Content => 'someTestData',
            ContentType => 'text/plain',
            Filename => 'test2.txt',
        },
    ],
};

Attribut-Optionen

Diese Option muss verwendet werden, um Schlüsselattribute für ausgehende Elemente zu verwenden. Optionen der ersten Ebene definieren die Elemente, die Schlüsselattribute erhalten sollen. Die Optionen der zweiten Ebene legen fest, welche Unterelemente in Attribute umgewandelt und an das umgebende Element angehängt werden sollen. Für Schlüsselattribute werden nur zwei Ebenen von Optionen berücksichtigt. Diese werden für jede Ebene von Elementen in der XML-Struktur verwendet (nicht nur für die erste Ebene).

Bitte beachten Sie, dass eine Sortierung der Elemente in den Attributoptionen möglich ist, aber keinen Einfluss darauf hat, wie Schlüsselattribute behandelt werden.

Wenn jedes Unterelement eines Elements in Attribute umgewandelt wird und das Element ein bestimmtes Unterelement ContentKey enthält, wird der Inhalt dieses Unterelements als Wert des umgebenden Elements verwendet. Zur Veranschaulichung dieser Optionen dient das folgende Beispiel.

Beispiel: XSLT Mapping

<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:date="http://exslt.org/dates-and-times" version="1.0" extension-element-prefixes="date">
        <xsl:template match="RootElement">
        <xsl:copy>
            <header>
                <messageID>someMessageID</messageID>
                <Attachment>
                    <ContentKey>text1.txt</ContentKey>
                    <Content>someValue</Content>
                    <ContentType>text/plain</ContentType>
                </Attachment>
                <Attachment>
                    <Filename>text2.txt</Filename>
                    <Content>someValue</Content>
                    <ContentType>text/plain</ContentType>
                </Attachment>
                <Attachment>
                    <ContentKey>text3.txt</ContentKey>
                    <Content>someValue</Content>
                    <ContentDisposition>inline</ContentDisposition>
                    <ContentType>text/plain</ContentType>
                </Attachment>
            </header>
            <ticketID>someTicketID</ticketID>
            <returnCode>0</returnCode>
        </xsl:copy>
    </xsl:template>
</xsl:transform>

Daten-Include

Wählen Sie einen oder mehrere Datensätze, welche in vorhergehenden Anfrage-/Antwortphasen erstellt wurden, um diese im Mapping zur Verfügung zu stellen.

Diese Datensätze werden in die Datenstruktur unter /DataInclude/<DataSetName> dargestellt (in der Ausgabe des Debugger sehen Sie Details der tatsächlichen Struktur).