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 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.

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.

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 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.

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 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).

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 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.

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).