SOAP und WSDL Webservices mit Apidog testen

Sie haben einen SOAP-Endpunkt erhalten: vielleicht einen alten Währungsrechner für die Abrechnung oder einen Auftragsverwaltungs-Webdienst eines .NET-Partners. Jetzt müssen Sie ihn aufrufen, die vertraglich erwartete Antwort prüfen und sicherstellen, dass er bei Änderungen am umgebenden Code weiterhin korrekt funktioniert. REST-Tools reichen dafür nicht immer aus, denn SOAP benötigt einen vollständigen XML-Envelope, einen passenden Content-Type und häufig eine WSDL, die die verfügbaren Operationen beschreibt.

Apidog heute ausprobieren

Apidog unterstützt SOAP- und WebService-Anfragen neben REST, GraphQL und gRPC. Sie benötigen also kein separates Tool für den SOAP-Legacy-Dienst in Ihrem Stack.

In diesem Leitfaden verwenden Sie zwei dokumentierte Wege:

1. Eine SOAP-Anfrage manuell erstellen und senden
2. Eine WSDL importieren, damit Endpunkte und Umgebung automatisch erstellt werden

Für einen Überblick über die Unterschiede der Protokolle lesen Sie den Vergleich von REST, GraphQL, gRPC und SOAP. Die formale Definition der Envelope-Struktur finden Sie in der W3C-SOAP-Spezifikation.

Was SOAP ist und warum es eine andere Handhabung erfordert

SOAP steht für Simple Object Access Protocol. Es ist ein XML-basiertes Kommunikationsprotokoll, das Dienste und Clients unterschiedlicher Plattformen und Programmiersprachen über einen definierten Vertrag verbinden kann.

Das ist besonders bei Enterprise- und Legacy-Integrationen relevant: Ein Java-Client und ein .NET-Dienst können über dieselbe Schnittstellenbeschreibung kommunizieren, ohne die interne Implementierung des jeweils anderen Systems kennen zu müssen.

Beim Testen sind drei Eigenschaften entscheidend:

• SOAP verwendet XML. Anfrage und Antwort sind strukturierte XML-Dokumente, keine JSON-Payloads.
• SOAP wird meist über HTTP oder HTTPS übertragen.
• SOAP-Nachrichten folgen einer festen Struktur. Envelope, Header und Body müssen zum Vertrag des Dienstes passen.

Wenn XML für Sie neu ist, bietet die XML-Referenz von MDN einen guten Einstieg.

Diese Strenge erklärt, warum SOAP weiterhin für plattformübergreifende Integrationen, Legacy-Brücken und sichere Transaktionen eingesetzt wird. Für verschlüsselte und authentifizierte Nachrichten kann SOAP beispielsweise WS-Security verwenden.

Eine SOAP-Anfrage besteht typischerweise aus:

1. einem passenden Content-Type-Header,
2. einem XML-Body,
3. einem SOAP-Envelope,
4. optionalen SOAP- oder WS-Security-Headern.

Details zu Envelope und XML-Body finden Sie auch in diesem Leitfaden zu SOAP-APIs und XML.

Bevor Sie beginnen

Für SOAP- und WebService-Anfragen benötigen Sie Apidog 2.1.31 oder höher.

Prüfen Sie Ihre installierte Version und aktualisieren Sie Apidog bei Bedarf. Alle folgenden Schritte setzen diese oder eine neuere Version voraus.

Falls Sie Apidog noch nicht installiert haben, können Sie Apidog herunterladen.

Bereiten Sie außerdem diese Informationen vor:

• URL des SOAP-Endpunkts
• Name der gewünschten Operation
• Parameter der Operation
• optional: die WSDL-Datei des Dienstes

Eine WSDL beschreibt unter anderem Operationen, Eingaben und Dienstadressen. Die Spezifikation finden Sie bei WSDL 2.0.

Pfad A: Eine SOAP-Anfrage manuell senden

Nutzen Sie diesen Weg, wenn Sie den Endpunkt und die aufzurufende Operation bereits kennen.

Sie konfigurieren dabei drei Dinge:

1. Content-Type
2. XML-Body
3. SOAP-Envelope

Schritt 1: Content-Type manuell setzen

SOAP leitet den benötigten Header nicht automatisch aus dem Body ab. Legen Sie daher unter Headers einen Content-Type fest.

Gültige Werte sind:

text/xml; charset=utf-8

oder:

application/soap+xml

In der Praxis gilt meist:

SOAP-Version	Typischer Content-Type
SOAP 1.1	text/xml; charset=utf-8
SOAP 1.2	application/soap+xml

Prüfen Sie bei Unsicherheit die WSDL oder die Dokumentation des Dienstes. Erhalten Sie einen Fehler zum Inhaltstyp, testen Sie den jeweils anderen Wert.

Schritt 2: Body auf XML setzen und SOAP-Envelope einfügen

Wählen Sie für den Request-Body das Format xml.

Fügen Sie anschließend den vollständigen SOAP-Envelope ein. Dieser enthält:

• Namespace-Deklarationen
• das soap:Body-Element
• die aufzurufende Operation
• die Parameter der Operation

Beispiel: Öffentlicher Zahlen-zu-Wörtern-Dienst mit der Operation NumberToWords und dem Parameter ubiNum.

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:web="http://www.dataaccess.com/webservicesserver/">
  <soap:Body>
    <web:NumberToWords>
      <web:ubiNum>1234</web:ubiNum>
    </web:NumberToWords>
  </soap:Body>
</soap:Envelope>

Achten Sie besonders auf die Namespaces:

• soap:Envelope definiert den SOAP-Rahmen.
• soap:Body enthält den eigentlichen Methodenaufruf.
• web:NumberToWords ist die Operation.
• web:ubiNum ist der Eingabeparameter.

Raten Sie den Namespace nicht. Übernehmen Sie ihn aus der WSDL oder der Dienst-Dokumentation.

Schritt 3: Anfrage senden und XML-Antwort prüfen

Senden Sie die Anfrage. Die Antwort ist ebenfalls ein SOAP-Envelope mit einer Antwortoperation im Body.

Für die vorherige Anfrage kann die Antwort beispielsweise so aussehen:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:NumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/">
      <m:NumberToWordsResult>one thousand two hundred and thirty four</m:NumberToWordsResult>
    </m:NumberToWordsResponse>
  </soap:Body>
</soap:Envelope>

Prüfen Sie mindestens:

1. Ist ein gültiger SOAP-Envelope zurückgekommen?
2. Existiert der erwartete Antwortknoten, etwa NumberToWordsResponse?
3. Enthält das Ergebniselement den erwarteten Wert?

Die Antwortoperation trägt häufig das Suffix Response. Das Ergebnis befindet sich meist in einem verschachtelten Result-Element.

Weitere Envelope-Beispiele und Konfigurationsdetails finden Sie in der WebService-Dokumentation von Apidog.

Übertragung auf eigene SOAP-Dienste

Das Muster bleibt immer gleich:

1. Header setzen
2. XML-Envelope erstellen
3. Anfrage senden
4. XML-Antwort validieren

Für einen Währungsdienst könnte der Body beispielsweise eine ConvertCurrency-Operation enthalten:

<web:ConvertCurrency>
  <web:fromCurrency>EUR</web:fromCurrency>
  <web:toCurrency>USD</web:toCurrency>
  <web:amount>100</web:amount>
</web:ConvertCurrency>

Für einen Auftragsdienst könnte die Operation so aussehen:

<web:GetOrderStatus>
  <web:orderId>ORD-12345</web:orderId>
</web:GetOrderStatus>

Die konkreten Elementnamen und Namespaces müssen immer dem Vertrag des Dienstes entsprechen.

Pfad B: Eine WSDL importieren, um Endpunkte zu generieren

Für einzelne SOAP-Aufrufe ist ein manueller Envelope schnell erstellt. Wenn ein Dienst viele Operationen anbietet, ist der WSDL-Import effizienter.

Eine WSDL-Datei beschreibt unter anderem:

• verfügbare Operationen,
• Eingabe- und Ausgabeparameter,
• Bindings,
• Dienstadressen.

Apidog kann diese Informationen beim Import übernehmen.

WSDL in Apidog importieren

Folgen Sie diesem Ablauf:

1. Öffnen Sie Einstellungen (Settings).
2. Wählen Sie Daten importieren (Import Data).
3. Wählen Sie WSDL.
4. Laden Sie eine .wsdl- oder .xml-Datei hoch.
5. Prüfen Sie die Vorschau der geparsten API-Endpunkte.
6. Öffnen Sie den Tab Umgebungen (Environments).
7. Kontrollieren Sie die Dienstadresse.
8. Klicken Sie auf Bestätigen (Confirm).
9. Wählen Sie oben rechts die importierte Umgebung aus.
10. Senden Sie eine Anfrage.

Dienstadresse vor dem Bestätigen kontrollieren

Schritt 6 und 7 sind wichtig.

Die Adresse in der WSDL wird zur Basis für importierte Requests. Zeigt sie auf einen Staging-Host, einen veralteten Server oder eine Platzhalter-URL, gehen Ihre Anfragen an das falsche Ziel.

Prüfen Sie daher die URL im Tab Umgebungen, bevor Sie den Import bestätigen.

Importierte Umgebung aktivieren

Nach dem Import wird die Umgebung automatisch erstellt. Sie müssen sie jedoch oben rechts auswählen.

Wenn keine oder die falsche Umgebung aktiv ist, fehlt der Anfrage möglicherweise die korrekte Basis-URL oder sie trifft den falschen Server.

Nach dem Import erscheint jede WSDL-Operation als aufrufbarer Endpunkt. Sie müssen den Envelope nicht mehr für jede Operation von Hand schreiben, sollten die XML-Antwort aber weiterhin prüfen.

Wenn Sie ein gesamtes Projekt aus einem anderen Tool übernehmen möchten, lesen Sie den Leitfaden zum Importieren von SOAP-Projekten.

Der dokumentierte WSDL-Import unterstützt Datei-Uploads für .wsdl- und .xml-Dateien. Ein Import per URL oder durch Einfügen des WSDL-Inhalts ist nicht dokumentiert. Laden Sie daher die WSDL-Datei hoch.

Von SoapUI kommend

Wenn Ihre SOAP-Tests bereits in SoapUI existieren, müssen Sie sie nicht zwingend neu erstellen.

Praktischer Migrationsweg:

1. Exportieren oder behalten Sie die verwendete WSDL.
2. Importieren Sie die Datei in Apidog.
3. Prüfen Sie die erzeugten Operationen und die Dienstadresse.
4. Erstellen oder übertragen Sie Ihre Testfälle als Testszenarien.

So können SOAP-Dienste, REST-Endpunkte und Testszenarien in einem Workspace liegen. Der Vorteil ist die Konsolidierung statt mehrerer separater Tools.

Weitere Unterschiede zwischen den Workflows beschreibt der Vergleich Apidog versus SoapUI.

Assertions und Variationen

Ein erfolgreicher Request zeigt nur, dass der Endpunkt erreichbar ist. Ein Test prüft, ob er sich gemäß Vertrag verhält.

Fügen Sie nach einem erfolgreichen SOAP-Request Assertions für die XML-Antwort hinzu.

Prüfen Sie beispielsweise:

• Der erwartete Antwortknoten ist vorhanden.
• Das Ergebniselement kann extrahiert werden.
• Der extrahierte Wert entspricht der erwarteten Geschäftslogik.

Beispiele:

Dienst	Sinnvolle Prüfung
Währungsdienst	Der konvertierte Betrag ist eine Zahl und liegt in einem erwartbaren Bereich.
Bestelldienst	Der zurückgegebene Status gehört zu den erlaubten Statuswerten.
Kundendienst	Die Kundennummer ist vorhanden und entspricht dem angefragten Datensatz.

Erstellen Sie anschließend wiederholbare Testszenarien. Ein typisches Szenario könnte:

1. eine Bestellung anlegen,
2. die zurückgegebene Bestell-ID speichern,
3. den Bestellstatus mit dieser ID abfragen,
4. den Status validieren.

Wie Sie extrahierte Werte in spätere Requests übernehmen, zeigt der Leitfaden zum Schreiben eines Testszenarios mit Apidog.

Dieses Muster ist nicht protokollgebunden. Ein Szenario kann SOAP-Aufrufe mit REST-Endpunkten kombinieren.

WS-Security verwenden

Bei abgesicherten SOAP-Endpunkten kommt häufig WS-Security zum Einsatz.

Der Security-Block gehört in den SOAP-Header des Envelopes. Die grundlegende Vorgehensweise bleibt gleich:

1. passenden Content-Type setzen,
2. vollständigen SOAP-Envelope erstellen,
3. WS-Security-Header ergänzen,
4. Anfrage senden,
5. Antwort prüfen.

Workflow mit der Apidog CLI automatisieren

Sobald Sie SOAP- oder WSDL-importierte Requests als Testszenarien gespeichert haben, kann die Apidog CLI gespeicherte Szenarien über die Kommandozeile ausführen.

Installieren Sie die CLI mit Node.js v16 oder höher:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

Führen Sie ein gespeichertes Szenario mit Szenario- und Umgebungs-ID aus:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Die wichtigsten Parameter:

Parameter	Bedeutung
-t	Test-Szenario-ID
-e	Umgebungs-ID
-r	Reporter, z. B. cli, html oder junit

Mehrere Reporter können kommagetrennt angegeben werden.

Die Dokumentation bestätigt, dass der Runner gespeicherte Testszenarien und Suiten ausführt. Sie gibt jedoch nicht explizit an, ob SOAP-basierte Schritte headless ausgeführt werden. Verwenden Sie die CLI daher für die dokumentierten Szenario- und HTTP-Workflows und verifizieren Sie SOAP-spezifische Ausführungen in Ihrem eigenen Projekt.

Die Einbindung in CI/CD behandelt der Apidog CLI CI/CD-Leitfaden.

FAQ

Welchen Content-Type sollte ich für eine SOAP-Anfrage verwenden?

Verwenden Sie entweder:

text/xml; charset=utf-8

oder:

application/soap+xml

SOAP-1.1-Endpunkte erwarten typischerweise text/xml; charset=utf-8, SOAP-1.2-Endpunkte häufig application/soap+xml. Prüfen Sie die WSDL oder Dienst-Dokumentation. Erhalten Sie einen Content-Type-Fehler, testen Sie den anderen Wert.

Benötige ich einen kostenpflichtigen Plan, um SOAP in Apidog zu testen?

Die dokumentierte Voraussetzung ist Apidog in Version 2.1.31 oder höher. Es werden keine Tarifstufen- oder Self-Hosting-Einschränkungen für SOAP- oder WSDL-Unterstützung genannt.

Kann ich eine WSDL über eine URL importieren?

Der dokumentierte WSDL-Import akzeptiert Datei-Uploads von .wsdl- und .xml-Dateien. Ein Import über URL oder durch Einfügen von WSDL-Text ist nicht dokumentiert. Laden Sie die Datei hoch.

Wie teste ich SOAP- und REST-APIs im selben Projekt?

Apidog behandelt SOAP, REST, GraphQL und gRPC als Anfragetypen innerhalb eines Workspaces. Sie können daher SOAP-Operationen neben REST-Endpunkten und GraphQL-Aufrufen verwalten und in Testszenarien verketten.

Wenn Sie zusätzlich GraphQL testen, hilft dieser Leitfaden zum Testen von GraphQL-APIs in Apidog.

Meine WSDL-importierten Anfragen treffen den falschen Server. Was ist passiert?

Prüfen Sie zwei Punkte:

1. War die Dienstadresse im Tab Umgebungen beim Import korrekt?
2. Ist die importierte Umgebung oben rechts aktiv ausgewählt?

Importieren Sie die WSDL bei Bedarf erneut, prüfen Sie die Adresse vor dem Bestätigen und aktivieren Sie anschließend die richtige Umgebung.

Zusammenfassung

SOAP-Tests benötigen kein separates Legacy-Tool.

In Apidog haben Sie zwei praktikable Wege:

• Manuell: Content-Type setzen, XML-Body wählen, SOAP-Envelope einfügen und XML-Antwort prüfen.
• Per WSDL: WSDL-Datei importieren, Dienstadresse kontrollieren, Umgebung aktivieren und erzeugte Endpunkte verwenden.

Beide Wege führen zum selben Ziel: Sie prüfen wiederholbar, dass ein SOAP-Webdienst seinen Vertrag weiterhin erfüllt.

Laden Sie Apidog herunter, verwenden Sie mindestens Version 2.1.31, importieren Sie Ihre WSDL und behandeln Sie Ihre SOAP-Dienste mit denselben Teststandards wie den Rest Ihrer API-Landschaft.