SOAP API-Überwachung, die Ihre Enterprise SOAP-Dienste vor stillschweigendem Ausfall bewahrt

Kontinuierliche Prüfung von SOAP-basierten Webdiensten außerhalb Ihrer Infrastruktur. Validiert, dass der Dienst erreichbar und reaktionsfähig ist, dass der XML-Envelope wohlgeformt ist, dass XPath-Prüfungen bestehen und dass die Antwort dem WSDL-Vertrag entspricht — und alarmiert Ihr Team sofort, wenn eines davon fehlschlägt.

Ja. Laden Sie eine WSDL 1.1- oder 2.0-Datei hoch. Dotcom-Monitor analysiert Operationen, Porttypen, Bindungen und Nachrichtenschemata und generiert dann Anfragevorlagen, sodass Sie Monitore gegen jede Operation ausführen können, ohne XML-Envelope von Hand codieren zu müssen.

Ja — WS-Security mit X.509-Zertifikat-Signierung, UsernameToken, SAML-Token, Nachrichtenverschlüsselung auf Nachrichtsebene und Zeitstempelvalidierung. Zusätzlich mTLS auf Transportschicht für Client-Zertifikatsauthentifizierung.

Beide. 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 auf den Antwort-Envelope, Header oder beliebige Knoten ausgewertet werden. Der Monitor schlägt fehl, wenn eine Assertion einen unerwarteten Wert, einen fehlenden Knoten oder einen falschen Typ zurückgibt. Häufige Muster: //transaction/status = 'approved' oder count(//errors) = 0.

Ein SOAP-Fehler liefert HTTP 200 mit einem <soapenv:Fault>-Element im Envelope — Uptime-Monitoren entgeht das komplett. Wir prüfen explizit auf das Fault-Element und zeigen faultcode und faultstring im Alarm-Payload an.

SOAP validiert XML-Envelopes über XPath statt JSON über JSONPath, analysiert WSDL-Verträge anstelle von OpenAPI-Spezifikationen und unterstützt Enterprise-Authentifizierungsschemata (WS-Security, SAML, mTLS), die bei SOAP-Diensten üblich sind. Die zugrundeliegende Plattform — globale Standorte, Mehrschrittketten, Benachrichtigungen, Private Agents — ist gemeinsam genutzt. Siehe REST API-Überwachung →

Ja. Setzen Sie Private Agents in Ihrem Netzwerk ein — üblich bei internen Enterprise-Integrationsbus-Systemen, On-Premises-Servicekatalogen und regulierten Umgebungen. Ausgehende Verbindung nur, keine eingehenden Firewall-Regeln.

Langlebige Integrationen in Banken, Versicherungen, Gesundheitswesen (HL7 über SOAP, FHIR über SOAP), Behörden und ERP. SOAPs strenge WSDL-Verträge, die WS-* Sicherheitsschicht und Transaktionsgarantien sind in regulierten Umgebungen nach wie vor wertvoll. Ein Ersatz durch REST lohnt wegen des Risikos selten — Überwachung hält sie sichtbar neben modernen Diensten.

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

Ja. MTOM/XOP-Anfrage- und Antwortanhänge werden unterstützt, inklusive Validierung der binären Nutzlast gegen erwartete Größen- oder Content-Type-Beschränkungen.

Wie jeden anderen SOAP-Endpunkt — richten Sie einen Monitor auf die veröffentlichte WSDL-URL oder direkt auf die Endpunkt-URL mit einem Anfrage-Envelope. Für nur intern verfügbare Dienste setzen Sie einen Private Agent dort ein, wo der Integrationsbus läuft.

Jeder fehlgeschlagene Lauf erfasst den vollständigen Anfrage-Envelope, Antwort-Envelope (oder Socket-Fehler, falls der Endpunkt nicht erreichbar war), HTTP-Header, zeitliche Aufschlüsselung (DNS, TLS, Serververarbeitung), die spezifische fehlgeschlagene XPath-Assertion und den SOAP-Fehler, falls zurückgegeben.