Surveillance SOAP API Qui Empêche Vos Services SOAP d’Entreprise de Tomber Silencieusement en Panne

Test continu des services web basés sur SOAP depuis l’extérieur de votre infrastructure. Valide que le service est accessible et réactif, que l’enveloppe XML est bien formée, que les assertions XPath passent, et que la réponse respecte le contrat WSDL — et alerte votre équipe dès que l’un d’eux échoue.

Oui. Déposez un fichier WSDL 1.1 ou 2.0. Dotcom-Monitor analyse les opérations, types de ports, liaisons et schémas de messages, puis génère des modèles de requêtes pour que vous puissiez exécuter des moniteurs sur n’importe quelle opération sans coder manuellement les enveloppes XML.

Oui — WS-Security avec signature de certificat X.509, UsernameToken, jeton SAML, chiffrement au niveau du message et validation du timestamp. Plus mTLS au niveau du transport pour l’authentification par certificat client.

Les deux. SOAP 1.1 (type de contenu text/xml avec l’en-tête SOAPAction) et SOAP 1.2 (application/soap+xml) sont entièrement pris en charge, avec une négociation de contenu correcte selon la liaison.

Configurez des expressions XPath à évaluer sur l’enveloppe de réponse, l’en-tête ou tout nœud. Le moniteur échoue si une assertion retourne une valeur inattendue, un nœud manquant ou un type erroné. Modèles courants : //transaction/status = 'approved' ou count(//errors) = 0.

Un défaut SOAP retourne HTTP 200 avec un élément <soapenv:Fault> à l’intérieur de l’enveloppe — les moniteurs de disponibilité le manquent complètement. Nous vérifions explicitement l’élément Fault et affichons le faultcode et faultstring dans la charge de l’alerte.

SOAP valide les enveloppes XML via XPath au lieu de JSON via JSONPath, analyse les contrats WSDL au lieu des spécifications OpenAPI, et gère les schémas d’authentification d’entreprise (WS-Security, SAML, mTLS) courants dans les services SOAP. La plateforme sous-jacente — emplacements globaux, chaînes multi-étapes, alertes, Agents Privés — est partagée. Voir la surveillance REST API →

Oui. Déployez des Agents Privés dans votre réseau — courant pour les bus d’intégration d’entreprise internes, catalogues de services sur site et environnements réglementés. Connexion uniquement sortante, sans règles entrantes au pare-feu.

Intégrations de longue durée dans la banque, l’assurance, la santé (HL7-via-SOAP, FHIR sur SOAP), le gouvernement et les ERP. Les contrats stricts WSDL de SOAP, la pile de sécurité WS-*, et les garanties de transaction restent précieux en environnement réglementé. Les remplacer par REST est rarement justifié — la surveillance les maintient visibles aux côtés des services modernes.

Oui. Les en-têtes WS-Addressing (Action, To, MessageID, ReplyTo) peuvent être définis explicitement par requête ou importés automatiquement depuis un WSDL lorsque la liaison les exige.

Oui. Les requêtes et réponses avec pièces jointes MTOM/XOP sont prises en charge, y compris la validation des charges binaires selon les contraintes de taille ou de type de contenu attendues.

De la même manière que pour tout autre point de terminaison SOAP — orientez un moniteur vers l’URL WSDL publiée ou directement vers l’URL du point final avec une enveloppe de requête. Pour les services internes uniquement, déployez un Agent Privé dans le réseau où le bus d’intégration fonctionne.

Chaque exécution échouée capture l’enveloppe complète de la requête, l’enveloppe de réponse (ou une erreur au niveau de la socket si le point final était inaccessible), les en-têtes HTTP, la répartition du temps (DNS, TLS, traitement serveur), l’assertion XPath spécifique qui a échoué, et le défaut SOAP s’il est retourné.