SOAP API Überwachung, die Ihre Enterprise SOAP-Dienste vor stillschweigendem Ausfall schützt

Kontinuierliches Testen von SOAP-basierten Webdiensten von außerhalb Ihrer Infrastruktur. Es überprüft, ob der Dienst erreichbar und reaktionsfähig ist, ob der XML-Envelope wohlgeformt ist, ob XPath-Prüfungen bestanden werden und ob die Antwort dem WSDL-Vertrag entspricht – und alarmiert Ihr Team sofort, wenn eine dieser Bedingungen verletzt wird.

Ja. Laden Sie eine WSDL 1.1 oder 2.0 Datei hoch. Dotcom-Monitor analysiert Operationen, Porttypen, Bindungen und Nachrichtenschemata und erstellt dann Anforderungsvorlagen, damit Sie Monitore für jede Operation ausführen können, ohne XML-Envelope manuell codieren zu müssen.

Ja – WS-Security mit X.509-Zertifikatsignatur, UsernameToken, SAML-Token, Nachrichtenverschlüsselung auf Nachrichtenebene und Zeitstempelvalidierung. Plus mTLS auf der Transportschicht zur Client-Zertifikatsauthentifizierung.

Beides. SOAP 1.1 (text/xml Content-Type mit SOAPAction-Header) und SOAP 1.2 (application/soap+xml) werden vollständig unterstützt, mit korrekter Inhaltsverhandlung je nach Bindung.

Konfigurieren Sie XPath-Ausdrücke, die gegen den Antwort-Envelope, Header oder einen beliebigen Knoten ausgewertet werden. Der Monitor schlägt fehl, wenn eine Assertion einen unerwarteten Wert, einen fehlenden Knoten oder einen falschen Typ zurückgibt. Übliche Muster: //transaction/status = 'approved' oder count(//errors) = 0.

Ein SOAP-Fehler gibt HTTP 200 mit einem <soapenv:Fault>-Element im Envelope zurück – Uptime-Monitore übersehen ihn vollständig. Wir prüfen explizit auf das Fault-Element und zeigen faultcode und faultstring in der Alarmmeldung an.

SOAP validiert XML-Envelopes via XPath anstelle von JSON via JSONPath, analysiert WSDL-Verträge statt OpenAPI-Spezifikationen und unterstützt Unternehmens-Authentifizierungsschemata (WS-Security, SAML, mTLS), die in SOAP-Diensten üblich sind. Die zugrundeliegende Plattform – globale Standorte, Mehrschrittketten, Alarme, Private Agents – wird gemeinsam genutzt. Siehe REST API Monitoring →

Ja. Setzen Sie Private Agents in Ihrem Netzwerk ein – üblich für interne Enterprise-Integrationsbusse, lokale Servicekataloge und regulierte Umgebungen. Nur ausgehende Verbindungen, keine eingehenden Firewall-Regeln.

Längerfristige Integrationen in Bankwesen, Versicherungen, Gesundheitswesen (HL7-via-SOAP, FHIR über SOAP), Behörden und ERP. Die strengen WSDL-Verträge von SOAP, der WS-* Security Stack und Transaktionsgarantien sind in regulierten Umgebungen weiterhin wertvoll. Diese durch REST zu ersetzen lohnt selten das Risiko – Monitoring hält sie neben modernen Diensten sichtbar.

Ja. WS-Addressing Header (Action, To, MessageID, ReplyTo) können pro Anfrage explizit gesetzt oder automatisch aus einer WSDL importiert werden, wenn die Bindung sie verlangt.

Ja. MTOM/XOP Anhangsanfragen und -antworten werden unterstützt, einschließlich binärer Payload-Validierung entsprechend erwarteter Größe oder Content-Type-Beschränkungen.

Wie jeden anderen SOAP-Endpunkt – richten Sie den Monitor auf die veröffentlichte WSDL-URL oder direkt auf die Endpunkt-URL mit einem Anforderungsenvelope. Für interne Dienste setzen Sie einen Private Agent im Netzwerk ein, in dem der Integrationsbus läuft.

Jeder fehlgeschlagene Durchlauf erfasst den vollständigen Anforderungsenvelope, Antwortenvelope (oder Socket-Ebene Fehler, falls der Endpunkt unerreichbar war), HTTP-Header, Zeitaufgliederung (DNS, TLS, Serververarbeitung), die spezifische XPath-Assertion, die fehlgeschlagen ist, und den SOAP-Fehler, falls zurückgegeben.