2010-10-14 2 views
1

Utilisation de BizTalk 2010 pour consommer un service Web WCF avec une liaison BasicHttp.Empêcher BizTalk d'émettre un en-tête de savon «To» dans une demande sortante vers un service WCF BasicHttp

Mon service rejette les demandes provenant de BizTalk. Je peux voir en utilisant le traçage et soapUI que la raison est la tête « To » émis par BizTalk dans le message sortant: <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:Header> <To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://biztalk01:81/StuffServices.svc</To> </s:Header> <s:Body> <ns0:GetMyStuff xmlns:ns0="http://example.com/stuff" xmlns:ns1="http://schemas.microsoft.com/2003/10/Serialization/Arrays"> <ns0:inputArray> <ns1:string>80220</ns1:string> </ns0:inputArray> </ns0:GetMyStuff > </s:Body> </s:Envelope>

Cette demande donne un défaut de retour à la fois dans BizTalk et soapUI, mais si je tente de soapUI à envoyer la même requête sans l'en-tête To (en supprimant le "<To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none"> http: // biztalk01: 81/StuffServices.svc "), alors cela fonctionne très bien et renvoie la bonne réponse.

Ainsi ma question: quelles sont mes options pour que BizTalk n'émette pas cet en-tête de savon "To" dans cette demande sortante?

Répondre

1

En réalité cet en-tête n'a jamais été dans la requête envoyée par BizTalk, il a été ajouté par le traçage WCF dans le journal. Utiliser Fiddler pour capturer la vraie demande envoyée m'a permis de voir que le problème était ailleurs. Il est possible d'obtenir la requête BizTalk à travers fiddler en ajoutant le proxy http://127.0.0.1:8888 dans la configuration de liaison du port d'envoi.

Questions connexes