Biztalk 2013: Définition d'un espace de noms différent sur les éléments de schéma

Question

Je développe une application BizTalk pour interroger un certain nombre de services Web qui ont été écrits et gérés par un tiers, et j'ai de la difficulté à obtenir les espaces de noms Schémas Fondamentalement, je ne peux pas consommer le wsdl pour générer automatiquement les schémas parce que les espaces de noms et les noms d'éléments sont tous faux dans les schémas générés (génération C# wsdl paresseuse), donc je dois les écrire à partir de zéro. Ce serait bien, mais les points de terminaison de service Web exigent que les éléments dans le schéma soient tous qualifiés avec des espaces de noms spécifiques, et aucun d'entre eux ne correspond à l'espace de noms du schéma global.

J'ai trouvé comment importer d'autres espaces de noms/schémas dans mon schéma, mais je n'arrive pas à comprendre comment changer l'espace de noms des éléments à autre chose que la valeur par défaut. Est-ce que quelqu'un sait comment faire ça? Par exemple, la racine de schéma doit avoir un espace de noms de "http:/tempuri.org/", mais l'un des éléments requiert l'espace de noms "http://schemas.datacontract.org/2004/07/ReadService.DTO.Inbound.Supplier", mais dans BizTalk, je ne peux pas modifier l'espace de nom de cet élément pour le modifier.

Le corps de l'une des demandes ressemble à ceci: « . «

<tem:GetSupplierIdWithExternalId> 
    <tem:request> 
     <com:Header> 
      <com1:Username></com1:Username> 
      <com1:Locale></com1:Locale> 
     </com:Header> 
     <read:ExternalSupplierId></read:ExternalSupplierId> 
    </tem:request> 
    </tem:GetSupplierIdWithExternalId> 

« tem » dans ce cas est http://tempuri.org/ com », « com1 » et « lire » sont tous les espaces de noms différents, qui, comme Gruff l'a souligné, sont tous les espaces de noms par défaut pour les projets de la WCF

Génération de WSDL dans Biztalk crée 2 numéros:.

1. l'espace de noms par défaut appliqués à la racine ne te n'est pas tempuri.org (comme il le reconnaît par défaut), c'est l'espace de noms standard Biztalk http: //..Folder.SchemaName. Changer ceci en tempuri.org provoque une cascade d'erreurs qui doivent être corrigées, et ne résout pas le problème majeur qui est:

2. En raison de la façon dont les fonctions WCF le WSDL a été généré est écrit , les noms des principaux éléments (GetSupplierIdWithExternalId ci-dessus) sont tous nommés de manière incorrecte - dans la plupart des cas, quelque chose comme "GetSupplierIdWithExternalId Request", car c'est le nom de la fonction à partir de laquelle le schéma est généré. Encore une fois, cela est dû à la programmation paresseuse sur les points de terminaison, car le nom de l'élément n'est pas correctement défini, il est simplement supposé par le processus de génération.

Si je tente de créer un schéma de fichier plat, je ne peux définir un seul espace de noms pour le fichier entier, et si je mets cela à tempuri.org je reçois:

<ns0:GetSupplierWithExternalId xmlns:ns0="http://tempuri.org/"> 
    <Header> 
    <Username>Username_0</Username> 
    <Locale>Locale_0</Locale> 
    </Header> 
    <ExternalSupplierId>ExternalSupplierId_0</ExternalSupplierId> 
</ns0:GetSupplierWithExternalId> 

. ..qui échoue la requête SOAP car les espaces de noms sur les éléments internes ne sont pas corrects.

Merci d'avance!

Answer 1

Vous devez définir l'élément avec l'espace de noms "http://schemas.datacontract.org/2004/07/ReadService.DTO.Inbound.Supplier" dans son propre fichier de schéma et l'importer dans la racine du schéma et composer la racine de cette façon. L'élément conservera l'espace de noms défini. En regardant l'espace de noms "http://schemas.datacontract.org/2004/07/ReadService.DTO.Inbound.Supplier", il semble que c'est l'espace de noms par défaut que WCF donne au contrat de données car il n'a pas été explicitement défini.(L'espace de noms CLR de la classe est ReadService.DTO.Inbound.Supplier) Lorsque DataContractSerializer sérialise le message lors de l'envoi de la requête, il le sérialisera avec cet espace de noms. Vous ne devriez pas essayer de le modifier dans le schéma BizTalk, sinon il y aura une discordance de schéma.

MISE À JOUR: Dans votre mise à jour, vous mentionnez 2 problèmes lors de la génération du schéma à partir du fichier WSDL.

1. Pouvez-vous coller une capture d'écran de ceci?
2. Etes-vous sûr que GetSupplierIdWithExternalIdRequest est incorrect? Si vous recherchez dans le WSDL pour ce terme, pouvez-vous le trouver? Les enveloppes de requête et de réponse de l'opération reçoivent généralement le suffixe -Request et -Response, donc cela peut être parfaitement correct.