Surveillance SOAP API Qui Empêche Vos Services SOAP d'Entreprise de se Casser Silencieusement

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 est conforme au contrat WSDL — et alerte votre équipe dès que l’une de ces conditions est rompue.

Oui. Importez un fichier WSDL 1.1 ou 2.0. Dotcom-Monitor analyse les opérations, les types de ports, les liaisons et les schémas de messages, puis génère des modèles de requêtes afin que vous puissiez exécuter des moniteurs contre 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 de l’horodatage. Plus mTLS au niveau du transport pour l’authentification par certificat client.

Les deux. SOAP 1.1 (type de contenu text/xml avec en-tête SOAPAction) et SOAP 1.2 (application/soap+xml) sont pleinement supportés, avec une négociation correcte du contenu selon la liaison.

Configurez des expressions XPath à évaluer contre 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é. Exemples courants : //transaction/status = 'approved' ou count(//errors) = 0.

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

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

Oui. Déployez des Agents Privés à l’intérieur de votre réseau — fréquent pour les bus d’intégration d’entreprise internes, les catalogues de services sur site et les environnements réglementés. Connexion sortante uniquement, aucune règle entrante dans le pare-feu.

Intégrations à long terme dans la banque, l’assurance, la santé (HL7 via SOAP, FHIR sur SOAP), le secteur public et les ERP. Les contrats WSDL stricts de SOAP, la pile de sécurité WS-*, et les garanties de transaction restent précieux dans les environnements réglementés. Les remplacer par REST vaut rarement le risque — la surveillance les rend 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 supportées, y compris la validation du contenu binaire par rapport aux contraintes de taille ou de type de contenu attendues.

Comme pour tout autre point de terminaison SOAP — pointez un moniteur vers l’URL WSDL publiée ou directement vers l’URL de l’endpoint avec une enveloppe de requête. Pour les services internes uniquement, déployez un Agent Privé à l’intérieur du réseau où le bus d’intégration fonctionne.

Chaque exécution échouée capture l’enveloppe de requête complète, l’enveloppe de réponse (ou une erreur au niveau socket si le point de terminaison é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 la faute SOAP si elle est retournée.