Web-Services

In einer vernetzten Welt muss ein Ticket-System in der Lage sein, auf Anfragen von anderen Systemen zu reagieren und auch Anfragen oder Informationen an andere Systeme zu senden:

  • CRM-Systeme
  • Projektmanagement-Systeme
  • Dokumentenmanagement-Systeme
  • und viele mehr

Das Ticket-System muss für andere Dienste ohne manuelle Eingriffe eines Agenten erreichbar sein.

OTRS unterstützt diese Anforderung durch das Generic Interface. Es befähigt den Administrator, einen Web-Service für eine bestimmte Aufgabe zu erstellen, ohne Skriptsprachkenntnisse zu haben. OTRS reagiert auf eingehende REST- oder SOAP-Anfragen und erstellt Objekte oder stellt anderen Systemen Objektdaten transparent zur Verfügung.

Ein Web-Service ist eine Kommunikationsmethode zwischen zwei Systemen, in unserem Fall OTRS und einem entfernten System. In seiner Konfiguration bestimmt die Operation oder der invoker die Richtung der Kommunikation, und das Mapping und der Transport kümmern sich um den Empfang und die Interpretation der Daten.

In seiner Konfiguration kann definiert werden, welche Aktionen der Web-Service intern durchführen kann (Operation), welche Aktionen die OTRS-Anforderung ausführen kann (Invokers), wie Daten von einem System in das andere konvertiert werden (Mapping) und über welches Protokoll die Kommunikation stattfindet (Transport).

Das Generic Interface ist das Framework, das es ermöglicht, Web-Services für OTRS auf vordefinierte Weise aus bereits erstellten Bausteinen zu erstellen, die unabhängig voneinander und austauschbar sind.

Generic Interface

Das Generic Interface besteht aus einem mehrschichtigen Framework, das OTRS die Kommunikation mit anderen Systemen über einen Web-Service ermöglicht. Diese Kommunikation kann bi-direktional sein:

  • OTRS als Provider: OTRS agiert als Server, der Anfragen von externen Systemen entgegennimmt, die Informationen verarbeitet, die angeforderte Aktion durchführt und die Anfrage beantwortet.
  • OTRS als Requester: OTRS agiert als Client, der Informationen sammelt, eine Anfrage an ein externes System sendet und auf die Antwort wartet.

Generic Interface Layers

Das Generic Interface ist auf einem Schichtenmodell aufgebaut, um flexibel und leicht anpassbar zu sein.

Eine Schicht ist ein Satz von Dateien, die steuern, wie das Generic Interface verschiedene Teile eines Web-Services ausführt. Mit der richtigen Konfiguration kann man verschiedene Web-Services für verschiedene externe Systeme aufbauen, ohne neue Module zu erstellen.

Bemerkung

Wenn das entfernte System die aktuellen gebündelten Module des generischen Schnittstelle nicht unterstützt, müssen spezielle Module für diesen spezifischen Web-Service entwickelt werden.

Generic Interface Layers

Generic Interface Layers

Netzwerktransport

Diese Schicht ist für die korrekte Kommunikation mit dem entfernten System verantwortlich. Sie empfängt Anfragen und generiert Antworten, wenn sie als Provider agiert, und generiert Anfragen und empfängt Antworten, wenn sie als Requester agiert.

Die Requester-Kommunikation kann durch ein Ereignis ausgelöst werden, das von einem Modul des Generic Interface oder einem anderen OTRS-Modul ausgelöst wird. Dieses Ereignis wird vom Event-Handler abgefangen und je nach Konfiguration direkt vom Requester-Objekt verarbeitet oder an den Scheduler (einen separaten Daemon zur asynchronen Verarbeitung von Aufgaben) delegiert.

Daten-Mapping

Diese Schicht ist verantwortlich für die Übersetzung von Datenstrukturen zwischen OTRS und dem entfernten System (interne und externe Datenschicht). Normalerweise haben entfernte Systeme andere Datenstrukturen als OTRS (einschließlich anderer Werte und Namen für diese Werte), und hier liegt die Bedeutung der Schicht, die empfangenen Informationen in etwas umzuwandeln, das OTRS verstehen kann, und auf der anderen Seite die Informationen an jedes entfernte System unter Verwendung ihrer Datenwörterbücher zu senden.

Beispiel: Priorität (OTRS) könnte in einem entfernten System Prio heißen und es könnte sein, dass der Wert 1 sehr niedrig (OTRS) im entfernten System auf Information abgebildet werden sollte.

Controller

Controller sind Sammlungen ähnlicher Vorgänge oder Aufrufer. Ein Ticket-Controller kann z. B. mehrere standardmäßige Ticket-Vorgänge enthalten. Es können benutzerdefinierte Controller implementiert werden, z. B. ein Controller TicketExternes Unternehmen, der ähnliche Funktionen wie der Standard-Ticket-Controller enthalten kann, jedoch mit einer anderen Datenschnittstelle oder anderen Funktionsnamen (zur Anpassung an die Funktionsnamen des entfernten Systems) oder einem komplett anderen Code.

Eine Anwendung für das Generic Interface könnte sein, Informationen mit einem entfernten System zu synchronisieren, das nur mit einem anderen entfernten System der gleichen Art kommunizieren kann. In diesem Fall müssen neue Controller entwickelt werden und die Operationen und Invoker müssen das Verhalten des entfernten Systems so emulieren, dass die Schnittstelle, die OTRS zur Verfügung stellt, der Schnittstelle des entfernten Systems ähnlich ist.

Operation (OTRS als Provider)

Eine Operation ist eine einzelne Aktion, die innerhalb von OTRS durchgeführt werden kann. Alle Operationen haben die gleiche Programmierschnittstelle, sie erhalten die Daten in einem bestimmten Parameter und geben eine Datenstruktur mit einem Erfolgsstatus, einer möglichen Fehlermeldung und den zurückgegebenen Daten zurück.

Normalerweise verwenden Operationen die bereits gemappten Daten (intern), um Kernmodule aufzurufen und Aktionen in OTRS durchzuführen, wie z.B.: ein Ticket erstellen, einen Benutzer aktualisieren, eine Queue ungültig machen, eine Benachrichtigung senden, etc. Eine Operation hat vollen Zugriff auf die OTRS-API, um die Aktion auszuführen.

Invoker (OTRS als Requester)
Ein Invoker ist eine Aktion, die OTRS gegen ein entferntes System ausführt. Invoker verwenden die OTRS-Kernmodule, um die benötigten Informationen zu verarbeiten und zu sammeln, um die Anfrage zu erstellen. Wenn die Informationen fertig sind, müssen sie auf das Format des entfernten Systems abgebildet werden, um an das entfernte System gesendet zu werden, das die Informationen verarbeitet, die Aktion ausführt und die Antwort zurücksendet, um entweder den Erfolg zu verarbeiten oder Fehler zu behandeln.

Generic Interface Kommunikationsfluss

Das Generic Interface hat einen definierten Ablauf, um Aktionen als Anbieter und als Requester durchzuführen. Diese Abläufe werden im Folgenden beschrieben:

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.

Web-Services verwalten

Ein Web Service ist eine Kommunikationsmethode zwischen zwei Systemen, in unserem Fall OTRS und einem entfernten System.

Das Herzstück des Web Service ist seine Konfiguration, in der festgelegt wird, welche Aktionen der Web Service intern ausführen kann (Operation), welche Aktionen die OTRS-Anfrage an das entfernte System ausführen kann (Invokers), wie die Daten von einem System in das andere konvertiert werden (Mapping) und über welches Protokoll die Kommunikation erfolgt (Transport).

Das Generic Interface ist das Framework, das es ermöglicht, Web-Services für OTRS auf vordefinierte Weise aus bereits erstellten Bausteinen zu erstellen, die unabhängig voneinander und austauschbar sind.

Verwenden Sie diese Ansicht, um Web-Services im System zu verwalten. Eine neue OTRS-Installation beinhaltet standardmäßig keine Web-Services. Die Ansicht zur Verwaltung von Web-Services ist im Modul Web-Services in der Gruppe Prozesse & Automation verfügbar.

Web Service Management Screen

Web-Service-Verwaltung

So erstellen Sie einen Web-Service:

  1. Klicken Sie in der linken Seitenleiste auf die Schaltfläche Web-Service hinzufügen.
  2. Füllen Sie die Pflichtfelder aus.
  3. Klicken Sie auf die Schaltfläche Speichern.
Create New Web Service Screen

Neuen Web-Service erstellen

So bearbeiten Sie einen Web-Service:

  1. Klicken Sie auf einen Web-Service in der Liste mit den Web-Services.
  2. Ändern Sie die Felder.
  3. Klicken Sie auf die Schaltfläche Speichern oder Speichern und abschließen.
Edit Web Service Screen

Web-Service bearbeiten

So löschen Sie einen Web-Service:

  1. Klicken Sie auf einen Web-Service in der Liste mit den Web-Services.
  2. Klicken Sie in der linken Seitenleiste auf die Schaltfläche Web-Service löschen.
  3. Klicken Sie im Dialog auf die Löschen-Schaltfläche.
Delete Web Service Screen

Web-Service löschen

So klonen Sie einen Web-Service:

  1. Klicken Sie auf einen Web-Service in der Liste mit den Web-Services.
  2. Klicken Sie in der linken Seitenleiste auf die Schaltfläche Web-Service klonen.
  3. Geben Sie einen Namen für den Web-Service ein.
Clone Web Service Screen

Web-Service klonen

So exportieren Sie einen Web-Service:

  1. Klicken Sie auf einen Web-Service in der Liste mit den Web-Services.
  2. Klicken Sie in der linken Seitenleiste auf die Schaltfläche Web-Service exportieren.
  3. Wählen Sie einen Speicherort auf Ihrem Computer um die „Export_ACL-yml“-Datei zu speichern.

Warnung

Alle in der Konfiguration des Web-Service gespeicherten Passwörter werden im Klartext exportiert.

So schauen Sie sich eine Konfigurationshistorie eines Web-Service an:

  1. Klicken Sie auf einen Web-Service in der Liste mit den Web-Services.
  2. Klicken Sie in der linken Seitenleiste auf die Schaltfläche Konfigurationshistorie.
Web Service Configuration History Screen

Web-Service - Konfigurationshistorie

So benutzen Sie einen Debugger für einen Web-Service:

  1. Klicken Sie auf einen Web-Service in der Liste mit den Web-Services.
  2. Klicken Sie in der linken Seitenleiste auf die Schaltfläche Debugger.
Web Service Debugger Screen

Web-Service - Debugger

So importieren Sie einen Web-Service:

  1. Klicken Sie in der linken Seitenleiste auf die Schaltfläche Web-Service hinzufügen.
  2. Klicken Sie in der linken Seitenleiste auf die Schaltfläche Web-Service importieren.
  3. Klicken Sie im Dialog auf die Schaltfläche Durchsuchen….
  4. Wählen Sie eine zuvor exportierte .yml Datei.
  5. Tragen Sie einen Namen für den Web-Service ein (optional). Bleibt dieses Feld leer, wird der Dateiname der Konfigurationsdatei als Name verwendet.
  6. Klicken Sie auf die Schaltfläche Importieren.

Web-Service - Einstellungen

Die Konfiguration des Web Service muss auf jeder Ebene gespeichert werden. Das heißt, wenn eine Einstellung geändert wird, werden die Links zu anderen, tieferen Teilen der Konfiguration deaktiviert, was Sie zwingt, die aktuelle Konfigurationsebene zu speichern. Nach dem Speichern werden die deaktivierten Links wieder aktiviert, so dass Sie mit der Konfiguration fortfahren können.

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

Allgemeine Einstellungen für Web-Services

Web Service Settings - General

Web-Service - Allgemeine Einstellungen

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit Stern 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
Wie Kommentar, aber hier kann längerer Text hinzugefügt werden.
Remote-System
In diesem Feld können Sie eine Beschreibung für das entfernte System hinzufügen.
Debug-Level

Der Standardwert ist Debug. Bei dieser Konfiguration werden alle Kommunikationsprotokolle in der Datenbank registriert. Jedes nachfolgende Debug-Level ist restriktiver und verwirft Kommunikationsprotokolle einer niedrigeren Ordnung als die im System eingestellten.

Debug-Level (von niedriger zu hoch):

  • Fehlersuche
  • Info
  • Notiz
  • Fehler
Gültigkeit
Setzt die Gültigkeit dieser Ressource. Jede Ressource kann nur in OTRS verwendet werden, wenn dieses Feld auf gültig gesetzt ist. Wenn Sie dieses Feld auf ungültig oder ungültig-temporär setzen, wird die Nutzung der Ressource deaktiviert.

Provider Web-Service - Einstellungen

Web Service Settings - OTRS as Provider

Web-Service - Einstellungen - OTRS als Provider

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

Netzwerktransport

Wählen Sie aus, welchen Netzwerktransport Sie mit dem Web-Service verwenden möchten. Mögliche Werte sind HTTP::REST und HTTP::SOAP.

Bemerkung

Nach Auswahl der Transportmethode müssen Sie die Konfiguration mit einem Klick auf die Schaltfläche Speichern speichern. Neben diesem Feld wird eine Schaltfläche Konfiguration angezeigt.

Konfiguration
Die Schaltfläche Konfigurieren ist nur sichtbar, nachdem ein Netzwerktransport ausgewählt und gespeichert wurde. Siehe unten die Konfiguration für OTRS als Anbieter - HTTP::REST und OTRS als Anbieter - HTTP::SOAP.
Operation hinzufügen

Diese Option ist nur sichtbar, wenn ein Netzwerktransport ausgewählt und gespeichert wurde. Die Auswahl einer Operation öffnet eine neue Ansicht für die Konfiguration.

Web Service Settings - OTRS as Provider - Operation

Web-Service-Einstellungen - OTRS als Provider - Operationen

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.

Web Service Settings - OTRS as Provider - HTTP\:\:REST

Web-Service-Einstellungen - OTRS als Provider - HTTP::REST

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit Stern 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.

Web Service Settings - OTRS as Provider - HTTP\:\:SOAP

Web-Service-Einstellungen - OTRS als Provider - HTTP::SOAP

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit Stern 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.

Bemerkung

Einige Header sind aus Sicherheitsgründen blockiert. Bei Bedarf kann die Liste der blockierten Header in der folgenden Systemkonfiguration über die Einstellungen geändert werden:

  • GenericInterface::Invoker::OutboundHeaderBlacklist
  • GenericInterface::Operation::OutboundHeaderBlacklist
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.

Add Web Service Operation Screen

Ansicht „Web Service hinzufügen”

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit Stern 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.

Requester Web-Service - Einstellungen

Die Konfiguration des Netzwerktransports für den Requester ähnelt der Konfiguration für den Provider.

Web Service Settings - OTRS as Requester

Webs Service-Einstellungen - OTRS als Requester

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

Netzwerktransport

Wählen Sie aus, welchen Netzwerktransport Sie mit dem Web-Service verwenden möchten. Mögliche Werte sind HTTP::REST und HTTP::SOAP.

Bemerkung

Nach Auswahl der Transportmethode müssen Sie die Konfiguration mit einem Klick auf die Schaltfläche Speichern speichern. Neben diesem Feld wird eine Schaltfläche Konfiguration angezeigt.

Konfiguration

Die Schaltfläche Konfigurieren ist nur sichtbar, nachdem ein Netzwerktransport ausgewählt und gespeichert wurde. Siehe unten die Konfiguration für OTRS als Anfragender - HTTP::REST und OTRS als Anfragender - HTTP::SOAP.

Es ist möglich, sowohl Objekt- als auch Array-Format als JSON-Antwort des entfernten Systems zu verwenden. Falls es sich jedoch um ein Array handelt, speichert das System es intern als Objekt, wobei ArrayData als Schlüssel verwendet wird und ein Wert ein Array ist. Aus diesem Grund kann ein geantwortetes JSON-Array effizient abgebildet werden, muss aber als ein oben beschriebenes Objekt betrachtet werden (der Schlüssel ist ArrayData, aber * kann auch als Platzhalter verwendet werden).

Fehlerbehandlungs-Modul hinzufügen

Diese Option ist nur sichtbar, wenn ein Netzwerktransport ausgewählt und gespeichert wurde. Wenn Sie ein Fehlerbehandlungsmodul auswählen, wird eine neue Ansicht für dessen Konfiguration geöffnet.

Web Service Settings - OTRS as Provider - Error Handling Module

Web Service Settings - OTRS als Provider - Fehlerbehandlungs-Modul

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit Stern 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.
Invoker-Filter
Ausführung des Fehlerbehandlungs-Moduls nur für die ausgewählten Invoker.
Filter für Inhalte von Fehlermeldungen

Geben Sie einen regulären Ausdruck ein, um einzuschränken, welche Fehlermeldungen zur Ausführung des Fehlerbehandlungsmoduls führen sollen. Betreff und Daten der Fehlermeldung (wie im Debugger-Fehlereintrag zu sehen) werden bei einer Übereinstimmung berücksichtigt.

Beispiel: Geben Sie ^.*401 Unauthorized.*$ ein, um ausschließlich authentifizierungsrelevante Fehlermeldungen zu handhaben.

Filter für Verarbeitungsphasen

Ausführung des Fehlerbehandlungs-Moduls nur für die ausgewählten Verarbeitungsphasen.

Beispiel: Ausschließlich Fehler behandeln, welche beim Mapping ausgehender Daten auftreten.

Fehlercode
Ein Fehlerbezeichner für dieses Fehlerbehandlungsmodul. Dieser Bezeichner ist im XSLT-Mapping verfügbar und wird in der Debugger-Ausgabe angezeigt.
Fehlermeldung
Ein Fehlerbezeichner für dieses Fehlerbehandlungsmodul. Diese Nachricht ist im XSLT-Mapping verfügbar und wird in der Debugger-Ausgabe angezeigt.
Stoppen nach Übereinstimmung
Legt fest, ob die Verarbeitung nach der Ausführung eines Moduls angehalten werden soll, wobei alle verbleibenden Module oder nur die des gleichen Backends übersprungen werden. Standardmäßig wird die Verarbeitung mit dem nächsten Modul fortgesetzt.

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.

Web Service Settings - OTRS as Requester - HTTP\:\:REST

Web-Service-Einstellungen - OTRS als Requester - HTTP::REST

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit Stern 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).

Bemerkung

Einige Header sind aus Sicherheitsgründen blockiert. Bei Bedarf kann die Liste der blockierten Header in der folgenden Systemkonfiguration über die Einstellungen geändert werden:

  • GenericInterface::Invoker::OutboundHeaderBlacklist
  • GenericInterface::Operation::OutboundHeaderBlacklist

OTRS als Requester - HTTP::SOAP

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

Web Service Settings - OTRS as Requester - HTTP\:\:SOAP

Web-Service-Einstellungen - OTRS als Requester - HTTP::SOAP

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit Stern 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.

Bemerkung

Einige Header sind aus Sicherheitsgründen blockiert. Bei Bedarf kann die Liste der blockierten Header in der folgenden Systemkonfiguration über die Einstellungen geändert werden:

  • GenericInterface::Invoker::OutboundHeaderBlacklist
  • GenericInterface::Operation::OutboundHeaderBlacklist
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 Mapping

Es gibt Fälle, in denen die Daten von einem Format in ein anderes umgewandelt werden müssen (Mapping oder Änderung der Datenstruktur), da normalerweise ein Web Service verwendet wird, um mit einem entfernten System zu interagieren, das höchstwahrscheinlich kein anderes OTRS-System ist und/oder die OTRS-Datenstrukturen und -Werte nicht verstehen kann. In diesen Fällen müssen einige oder alle Werte geändert werden, und manchmal sogar die Namen der Werte (Schlüssel) oder sogar die komplette Struktur, um mit den erwarteten Daten auf der anderen Seite übereinzustimmen. Um diese Aufgabe zu bewältigen, gibt es die generische Schnittstellenabbildungsschicht.

Simple Web Service Mapping

Einfaches Web Service Mapping

Jedes entfernte System hat seine eigenen Datenstrukturen und es ist möglich, neue Mapping-Module für jeden Fall zu erstellen (z.B. gibt es ein angepasstes Mapping-Modul für SAP Solution Manager als Feature Add-on), aber es ist nicht immer notwendig. Das Modul Mapping::Simple sollte die meisten Mapping-Anforderungen abdecken.

Bemerkung

Wenn das Mapping::Simple nicht alle Mapping-Bedürfnisse für einen Webservice abdeckt, sollte ein neues Mapping-Modul erstellt werden.

Dieses Modul gibt Ihnen die Möglichkeit, Standardwerte für jeden Schlüssel oder Wert für die gesamten Daten der Kommunikation zuzuordnen.

Am Anfang der Ansicht sehen Sie einen allgemeinen Bereich, in dem Sie die Standardregeln festlegen können, die für alle nicht zugeordneten Tasten und Werte gelten. Es stehen drei Optionen zur Verfügung, die im Folgenden aufgeführt sind:

Behalten (unverändert lassen)
Sie hat keinerlei Einfluss auf die Schlüssel oder Werte.
Ignorieren (Schlüssel-Wert-Paar entfernen)
Wenn dies auf den Schlüssel angewandt wird, werden Schlüssel und Wert gelöscht, denn wenn ein Schlüssel gelöscht wird, wird in der Folge auch der zugehörige Wert gelöscht. Wenn dies auf den Wert angewendet wird, wird nur der Wert gelöscht, der Schlüssel bleibt erhalten, der nun mit einem leeren Wert verknüpft wird.
Ändern in (verwende angegeben Wert als Standard)
Alle Schlüssel und/oder Werte ohne eine definierte Zuordnungsregel verwenden diese als Standard. Wenn Sie diese Option wählen, wird ein neues Textfeld angezeigt, in dem Sie diese Vorgabe festlegen können.

Wenn Sie auf die Plus-Schaltfläche für eine neue Schlüsselzuordnung klicken, wird ein neues Feld für eine einzelne Zuordnungskonfiguration angezeigt. Sie können so viele Tastenzuordnungen hinzufügen, wie Sie benötigen. Klicken Sie einfach erneut auf die Plus-Schaltfläche, und ein neues Zuordnungsfeld wird unter dem bestehenden angezeigt. In diesem Zuordnungsfeld können Sie eine Zuordnung für eine einzelne Taste definieren, mit den folgenden Optionen:

Genaue(r) Wert(e)
Die alte Zeichenkette des Schlüssels wird durch eine neue ersetzt, wenn der alte Schlüssel genau übereinstimmt.
Regulärer Ausdruck
Die Zeichenkette des Schlüssels wird durch eine Regel des regulären Ausdrucks ersetzt.

Wenn Sie auf die Plus-Schaltfläche für eine neue Wertekarte klicken, wird eine neue Zeile für eine Wertekarte angezeigt. Hier ist es auch möglich, Regeln für jeden zuzuordnenden Wert mit denselben Optionen wie für die Schlüsselzuordnung zu definieren (exakter Wert und regulärer Ausdruck). Sie können so viele Werte zur Zuordnung hinzufügen, wie Sie benötigen, und wenn Sie einen davon löschen möchten, klicken Sie einfach auf die Minus-Schaltfläche für jede Zeile mit einem Zuordnungswert.

Sie können den gesamten Bereich der Schlüsselzuordnung (Box) löschen, indem Sie auf die Minustaste in der oberen rechten Ecke jeder Box drücken, die Sie löschen möchten.

Wenn Sie eine komplette Mapping-Konfiguration löschen müssen, gehen Sie zurück zu der entsprechenden Ansicht, suchen Sie die Mapping-Richtung, die Sie zuvor ausgewählt haben, und setzen Sie ihren Wert auf -, und speichern Sie die Konfiguration, um die Änderungen zu übernehmen.

Es ist möglich, XSLT-Vorlagen für das Mapping zu definieren.

XSLT Web Service Incoming Mapping

XSLT Web Service Incoming Mapping

XSLT Mapping

XSLT stylesheet *

Here you can add or modify your XSLT mapping code.

The editing field allows you to use different functions like automatic formatting, window resize as well as tag- and bracket-completion.

Use key attribute

For incoming data this option defines if XML key attributes are converted into a Perl data structure or if they are ignored.

Example: Incoming XML data

<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" />

Resulting Perl data with Use key attribute disabled:

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

Resulting Perl data with Use key attribute enabled:

$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',
        },
    ],
};
Attribute options

This option must be used in order to use key attributes for outgoing elements. First level options define the elements which should receive key attributes. Second level options define which sub elements should be converted into attributes and attached to the surrounding element. Only two levels of options are considered for key attributes. These will be used for any level of elements in the XML structure (not only the first level).

Please note that sorting of elements in the attribute options is possible but will not affect how key attributes are treated.

If every sub element of an element is converted into attributes and the element contains a specific ContentKey sub element, the content of this sub element will be used as value of the surrounding element. Please see the following example as illustration for these options.

XSLT Web Service Outgoing Mapping

XSLT Web Service Outgoing Mapping

Example: 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>
Data includes

Select one or more sets of data that were created at earlier request/response stages to be included in mappable data.

These sets will appear in the data structure at /DataInclude/<DataSetName> (see debugger output of actual requests for details).