Altova MapForce 2025 Enterprise Edition

In diesem Kapitel wird erläutert, wie Sie HTTP-Fehler in einem Mapping, das eine HTTP API aufruft, behandeln. Um einen HTTP-Fehler zu behandeln (z.B. Not Found, Unauthorized), müssen Sie im Response-Teil des Webservice-Aufrufs einen entsprechenden Body-Node dafür definieren (nähere Informationen siehe unten). Andernfalls beendet ein HTTP-Fehler die Ausführung des Mappings immer.

WebService-Call-Implementierung

Im Beispiel-Mapping unten liefert eine CSV-Datei namens products.csv die IDs von Produkten an den Request-Teil des Webservice-Aufrufs. Wenn der Webservice aufrufen wird, wird die Response mit den abgerufenen Informationen auf eine XML-Datei namens output.xml gemappt.

Wenn die Produkte mit der angegebenen ID auf dem Server vorhanden sind, werden die dazugehörigen Daten vom Body mit dem Statuscode 200 (Erfolg) gemappt. Wenn auf dem Server keine Produkte mit diesen IDs vorhanden sind, gibt der Webservice-Aufruf den Statuscode 404 (nicht gefunden) zurück und die Response wird vom Body mit dem Statuscode 404 in der Ausgabe auf den Node ErrorMessage gemappt.

Bodys und Response-Strukturen

Um unterschiedliche HTTP Responses des Webservice im selben Mapping zu behandeln, können Sie mehrere Body-Elemente erstellen. Gehen Sie dazu folgendermaßen vor: Klicken Sie mit der rechten Maustaste in der Webservice-Komponente auf das Body-Element und wählen Sie im Kontextmenü den Befehl Body-Node hinzufügen vor/nach. In unserem Beispiel gibt es zwei Body-Elemente, von denen jedes einen bestimmten HTTP-Response-Typ behandelt: Der Body mit dem Statuscode 200 behandelt erfolgreiche Responses und der Body mit dem Statuscode 404 behandelt Not Found-Fehler.

Jedes der Response Body-Datenelemente kann über die dazugehörige -Schaltfläche konfiguriert werden. Bei Klick auf diese Schaltfläche wird das Dialogfeld Response-Struktur geöffnet (Abbildung unten). Beide Bodys haben Response-Strukturen im XML-Format. Die Bodys können auch Inhalt eines anderen Typs (z.B. JSON) erhalten.

Body-Status=200

Body-Status=404

Verarbeitungsreihenfolge

In diesem Unterabschnitt erfahren Sie, wie das Mapping den Request verarbeitet und die Response im Zieldokument ausgibt.

Gemeinsamer Ziel-Kontext

Gemäß einer der grundlegenden Regeln in MapForce beginnt die Verarbeitung immer beim Root-Node der Zielkomponente und wird dann von oben nach unten in der Hierarchie fortgesetzt. Der Ziel-Root-Node in unserem Beispiel ist ProductList. Da der Ziel-Node nicht verbunden ist, wird die Verarbeitung beim Element Product, welches mit dem Response-Node des Webservice-Aufrufs verbunden ist, fortgesetzt. Mit dieser Verbindung wurde für alle Nachfahren des Nodes Product ein gemeinsamer Ziel-Kontext festgelegt. Das bedeutet, dass die Nachfahren Zugriff auf die Daten ihrer Parent-Elemente haben, wodurch unnötige Webservice-Aufrufe vermieden werden.

Ein Produkt pro Response

Gemäß einer anderen grundlegenden Regel in MapForce wird für jedes Quell-Datenelement ein Datenelement in der Zielkomponente erstellt. Dies bedeutet, dass in unserem Beispiel für jede Response in der Ausgabe ein Product-Datenelement erstellt wird. Im Allgemeinen gilt vor allem, wenn mehrere Body-Nodes konfiguriert sind, dass der Response-Node normalerweise mit einem gemeinsamen Parent in der Zielkomponente verbunden werden sollte. Dadurch vermeiden Sie, dass zu viele Aufrufe durchgeführt werden.

Verarbeitung von Request/Response

Wenn die Verbindung vom Product-Node zum Response-Node zurückverfolgt wird, weiß MapForce, dass es einen Webservice-Aufruf durchführen muss, benötigt aber zuerst einen Request. Anschließend wird der Request-Teil verarbeitet. Der Parameter id erhält Werte aus dem Node ProductID der CSV-Quelldatei.

Die CSV-Datei enthält eine Sequenz von Werten, die wir versuchen auf den Parameter, der nur einen einzigen Wert erwartet, zu mappen. In diesem Fall wird die Webservice-Funktion so oft aufgerufen und erzeugt so viele Datenelemente, wie sich Datenelemente in der Sequenz befinden. Das bedeutet, dass bei 5 Produkt-IDs für jede ID ein Aufruf durchgeführt wird.

Wenn die Verbindung vom id-Node zum Node ProductID zurückverfolgt wird, bringt MapForce seinen Parent, nämlich den Node Rows in den Kontext und verarbeitet die einzelnen Zeilen (ProductID) in einer Schleife. Für jede Zeile wird ein Request an den Server gesendet. MapForce erhält daraufhin eine Response vom Server und erstellt ein Prduct-Datenelement, das dieselbe ID wie die an den Request gesendete hat.

Beachten Sie, dass der Node ProductID in der Zielkomponente Daten nicht von der Response-Struktur, sondern direkt aus der CSV-Quelldatei erhält. Der Grund dafür ist, dass wir für jede einzelne Produkt-ID, die auf dem Server vorhanden oder auch nicht vorhanden ist, eine Response erhalten möchten.

Bodys

Die Bodys werden von oben nach unten verarbeitet. Der erste Body, der mit der Response übereinstimmt, wird zuerst verarbeitet. Anschließend arbeitet sich MapForce durch die Struktur nach unten. Wenn keiner der Bodys eine Entsprechung hat, gibt MapForce eine Ausnahme zurück und die Ausführung des Mappings wird abgebrochen.

Wenn auf dem Server ein Produkt mit der angegebenen ID aus der CSV-Datei vorhanden ist, wird das Product-Element mit den Daten aus dem Body mit dem Statuscode 200 befüllt. Wenn auf dem Server kein Produkt mit einer solchen ID vorhanden ist, wird der zweite Body mit dem Statuscode 404 verarbeitet und das Product-Element erhält nur die Produkt-ID und eine Fehlermeldung.

Ausgabe

Unten sehen Sie die Ausgabe, in der die Details der Produkte mit den IDs 1, 5 und 7 erfolgreich abgerufen wurden. Das Produkt mit der ID 6 wurde nicht gefunden, daher wurde der Body mit dem Statuscode 404 verarbeitet und der Wert des Node Message wurde in der Zielkomponente auf den Node ErrorMessage gemappt.