2010-09-23 4 views
0

Je dois appeler un service Web extrêmement exigeant (non standard) concernant le format de message SOAP qu'il choisit de traiter. Je n'ai aucun contrôle sur l'implémentation côté serveur et il n'y a pas de WSDL disponible, tout ce que j'ai est un message intercepté attaché ci-dessous. Ma première pensée a été WCF + MessageContract, mais quoi que je fasse avec le dernier, je n'arrive pas à obtenir le bon résultat. Les messages sortants devraient ressembler à ceux ci-dessous. La partie la plus délicate semble être le contenu de plusieurs corps ("ProxyInfo" et "PayloadInfo" ci-dessous). En outre, je ne peux pas non plus que WCF supprime l'élément "Action" de l'en-tête du message SOAP. Je réalise que c'est un élément vital pour WCF, mais je doute que je puisse persuader le service Web de l'accepter. La réponse sera probablement une autre histoire, mais je franchirai ce pont quand j'y arriverai. Actuellement, j'envisage la sérialisation personnalisée et le post-traitement/pré-traitement des messages sortants/entrants. Dans le pire des cas, je suppose que je vais devoir faire des requêtes Web ainsi que la sérialisation manuellement. S'il vous plaît aider, je reçois ... vraiment désespéréWCF MesageContract - personnalisation du message SOAP sortant - plusieurs corps

<?xml version="1.0" encoding="UTF-8" ?> 
<e:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> 
<e:Header> 
    <ServiceHeader xmlns="http://services/serviceheader" e:actor="http://services/loadbalancer" > 
    <ServiceLevel> 
    <Type>HIGH</Type> 
    <Method>FIFO</Method> 
    </ServiceLevel> 
    </ServiceHeader> 
</e:Header> 
<e:Body> 
    <ProxyInfo xmlns="http://services/proxyinfo"> 
    <Server> 
    <Address>proxy1:8080</Address> 
    <AppId>case_delegator</AppId> 
    </Server> 
    </ProxyInfo> 
    <PayloadInfo xmlns="http://services/payload"> 
    <GetConfirmation> 
    <CaseId> 
    <Id>9728DFC889874CC8B1505D91E33FCFCD</Id> 
    </CaseId> 
    </GetConfirmation> 
    </PayloadInfo> 
</e:Body> 
</e:Envelope> 
+1

Veuillez poster le contrat de message que vous avez essayé, et montrer le XML résultant. Le service s'oppose-t-il réellement à l'élément Action? Pourquoi? S'il ne le reconnaît pas, il doit l'ignorer (à moins qu'il ne possède un drapeau mustUnderstand). –

Répondre

0

Si vous ne souhaitez pas utiliser en-tête d'adresse, vous devez utiliser la liaison sans WS-Addressing. Dans votre cas, utilisez BasicHttpBinding. Il n'utilisera pas l'en-tête WS-Addressing et Action SOAP mais utilisera à la place l'en-tête HTTP SOAPAction.

Pour votre contrat de message essayer d'utiliser quelque chose comme ceci:

[DataContract] 
public class ServiceHeader 
{ 
    ... 
} 

[DataContract] 
public class ProxyInfo 
{ 
    ... 
} 

[DataContract] 
public class PayloadInfo 
{ 
    ... 
} 

[MessageContract(IsWrapped = false)] 
public class Request 
{ 
    [MessageHeader(Namespace="http://services/serviceheader")] 
    public ServiceHeader ServiceHeader { get; set; } 

    [MessageBodyMember(Namespace="http://services/proxyinfo")] 
    public ProxyInfo ProxyInfo { get; set; } 

    [MessageBodyMember(Namespace="http://services/payload")] 
    public PayloadInfo PayloadInfo { get; set; } 
} 

La chose étrange est l'attribut acteur ServiceHeader. Votre message ne définit pas l'espace de noms pour le préfixe e, donc le message n'est pas valide au format XML.

+0

Merci, Ladislav! La partie "IsWrapped = false" était celle qui manquait. Combinant cela avec la déclaration d'espace de noms à tous les niveaux semblait faire l'affaire, les demandes fonctionnent maintenant.Si je pouvais seulement déclarer "http://www.w3.org/2001/XMLSchema-instance" Namespace avec le préfixe dans un endroit ou même mieux , pas du tout (le service ne l'exige pas) ce serait encore mieux, mais pour l'instant cette partie semble fonctionner et l'optimisation n'est pas prioritaire :) –

Questions connexes