Problèmes connus pour les adaptateurs WCF

Cette rubrique décrit les problèmes connus pour les adaptateurs WCF inclus avec BizTalk Server.

Un message échouant au cours du traitement de marshaling SOAP entrant n'est pas interrompu dans les adaptateurs de réception WCF.

Lorsqu'un message arrive à un adaptateur de réception WCF, ce dernier crée un message BizTalk à partir du message SOAP entrant, puis transmet le message BizTalk au proxy de transport géré par le Gestionnaire des points de terminaison. Si l'adaptateur ne peut pas lire l'enveloppe et le corps SOAP lors de la création du message BizTalk, le message n'est pas interrompu car l'adaptateur utilise le lecteur rapide, non mis en cache et vers l'avant uniquement, pour accéder au message SOAP.

Vous devez rechercher le message échoué dans le journal des événements. Par exemple, vous pouvez utiliser une expression de chemin d’accès au corps sous l’onglet Messages de la boîte de dialogue propriétés de transport de l’adaptateur WCF pour spécifier comment créer le corps du message BizTalk entrant à partir d’un message SOAP entrant via l’adaptateur WCF. Lorsqu’une expression de chemin de corps non valide pour le message SOAP entrant est fournie sous l’onglet Messages , l’adaptateur ne parvient pas à créer le message BizTalk et ne peut pas suspendre le message entrant. Pour plus d’informations sur l’utilisation de l’expression de chemin de corps sous l’onglet Messages , consultez Spécification du corps du message pour les adaptateurs WCF.

L’illustration suivante montre l’onglet Messages dans lequel vous pouvez spécifier comment créer des messages BizTalk entrants à partir des messages SOAP entrants.

Un message échouant au cours du traitement de marshaling SOAP entrant n'est pas interrompu dans les adaptateurs d'envoi WCF.

Le port d'envoi WCF de type sollicitation-réponse peut recevoir un message WCF en tant que message de réponse. Lorsque le message arrive à l'adaptateur d'envoi WCF, ce dernier crée le message BizTalk à partir du message SOAP entrant, puis transmet le message BizTalk au proxy de transport géré par le Gestionnaire des points de terminaison. Si l'adaptateur ne peut pas lire l'enveloppe et le corps SOAP lors de la création du message BizTalk, le message n'est pas interrompu car l'adaptateur utilise le lecteur rapide, non mis en cache et vers l'avant uniquement, pour accéder au message SOAP.

Vous devez rechercher le message échoué dans le journal des événements. Par exemple, vous pouvez utiliser une expression XPath sous l’onglet Messages de la boîte de dialogue propriétés de transport de l’adaptateur WCF pour spécifier comment créer le corps du message BizTalk entrant à partir d’un message SOAP entrant via l’adaptateur WCF. Lorsqu’une expression XPath non valide pour le message SOAP entrant est fournie sous l’onglet Messages , l’adaptateur ne parvient pas à créer le message BizTalk et ne peut pas suspendre le message entrant. Pour plus d’informations sur l’utilisation de l’expression XPath sous l’onglet Messages , consultez Spécification du corps du message pour les adaptateurs WCF.

La figure suivante montre l’onglet Messages de l’adaptateur d’envoi WCF-NetNamedPipe à titre d’exemple.

Des messages peuvent être perdus lors de l'utilisation de OneWayBindingElement dans un transport bidirectionnel avec une liaison personnalisée dans les emplacements de réception WCF non transactionnels.

Dans une communication bidirectionnelle, les adaptateurs WCF renvoient la réponse jusqu'à la conservation des messages dans la base de données MessageBox. Toutefois, l’utilisation de OneWayBindingElement génère une réponse factice immédiatement avant de distribuer le message reçu à l’adaptateur WCF. Par conséquent, si vous configurez une liaison personnalisée avec un OneWayBindingElement dans la pile des canaux pour un transport bidirectionnel dans des emplacements de réception non transactionnels, les messages peuvent être perdus, car les adaptateurs WCF traitent les messages reçus de manière unidirectionnelle.

Des valeurs par défaut des attributs ReaderQuotas dans les boîtes de dialogue Propriétés du transport WCF-Custom et WCF-CustomIsolated sont utilisées lors de la construction des liaisons.

Dans les boîtes de dialogue WCF-Custom et WCF-CustomIsolated propriétés de transport, les valeurs d’attribut ReaderQuotas sont affichées comme zéro. Toutefois, lors de la construction des liaisons, les valeurs suivantes sont utilisées :

Attribut	Description	Valeur
maxArrayLength	Entier positif qui spécifie la longueur de tableau maximale autorisée.	16384
maxBytesPerRead	Entier positif qui spécifie le nombre maximal autorisé d'octets renvoyés par lecture.	4096
maxDepth	Entier positif qui spécifie la profondeur maximale du nœud imbriqué par lecture.	32
maxNameTableCharCount	Entier positif qui spécifie le nombre maximal de caractères autorisés dans un nom de table.	16384
maxStringContentLength	Entier positif qui spécifie le nombre maximal de caractères autorisés dans le contenu d'un élément XML.	8 192

Les emplacements de réception WCF risquent d'être désactivés si vous modifiez le type d'adaptateur WCF et conservez la même adresse.

Si vous modifiez le type d'adaptateur (par exemple, si vous modifiez l'adaptateur WCF de WCF-NetTcp en WCF-Custom avec la liaison NetTcp) et que vous conservez la même adresse, l'emplacement de réception risque d'être désactivé en raison du problème de mise en cache dans le Gestionnaire des points de terminaison. Pour contourner ce problème, vous pouvez effectuer l'une des opérations suivantes :

• Redémarrez le service BTSNTSvc.

• Modifiez l'URI en une adresse différente et enregistrez-la, puis remodifiez l'URI en l'adresse d'origine et enregistrez-la de nouveau.

L'action WCF définie dans l'orchestration ne remplace pas la définition d'action dans le port d'envoi statique.

Si vous définissez WCF . Propriété de contexte d’action dans l’orchestration, vous devez laisser le champ Action vide dans la boîte de dialogue Propriétés de transport de l’adaptateur WCF. Si vous spécifiez également une action dans le port d’envoi statique, wcf. La propriété de contexte d’action que vous définissez dans l’orchestration est remplacée par la valeur que vous avez définie dans le port d’envoi statique.

La répercussion d'un message d'erreur n'est pas prise en charge dans l'envoi transactionnel

L’option Propager le message d’erreur dans les ports d’envoi de sollicitation-réponse vous permet d’acheminer les messages qui échouent au traitement sortant vers une application d’abonnement. Toutefois, si la zone Activer les transactions case activée est également sélectionnée dans la boîte de dialogue propriétés de transport et que la transaction est abandonnée ou inutilisable lorsque la réponse d’erreur arrive à l’adaptateur, vous ne pourrez pas propager les messages d’erreur aux applications abonnées.

Le groupe de ressources en cluster MSMQ doit être redémarré avant le redémarrage du groupe de ressources en cluster de l'hôte BizTalk lors du basculement de cluster.

Dans un scénario de cluster de basculement, lorsqu'un basculement a lieu, le groupe de ressources en cluster MSMQ doit être redémarré avant le redémarrage du groupe de ressources en cluster de l'hôte BizTalk. Si vous ne parvenez pas à le faire, les emplacements de réception MSMQ risquent d'être désactivés. Pour contourner ce problème, vous pouvez rendre le groupe de ressources en cluster de l'hôte BizTalk dépendant du groupe de ressources en cluster MSMQ pour garantir le redémarrage du groupe de ressources en cluster MSMQ avant le groupe de ressources en cluster de l'hôte BizTalk. Vous pouvez également redémarrer le groupe de ressources en cluster de l'hôte BizTalk pour contourner ce problème.

Vous obtenez une erreur lors de l'envoi de messages à un service WCF utilisant wsFederationHttpBinding dans le point de terminaison.

Vous obtenez une erreur semblable à celle-ci :

The adapter failed to transmit message going to send port "MySendPort" with URL "http://localohost/MywsFedHttp". It will be retransmitted after the retry interval specified for this Send Port. Details:"The channel is configured to use interactive initializer 'System.ServiceModel.Security.InfocardInteractiveChannelInitializer', but the channel was Opened without calling DisplayInitializationUI.  Call DisplayInitializationUI before calling Open or other methods on this channel.".

Ce comportement est normal. Les adaptateurs WCF ne peuvent pas envoyer de messages aux services WCF qui utilisent wsFederationHttpBinding dans leurs points de terminaison.

L'Assistant Consommation de service WCF BizTalk ne vous permet pas de sélectionner les types de messages ou les types de ports à partir de WSDL.

L'Assistant Consommation de service WCF BizTalk ne vous permet pas de sélectionner les types de messages ou les types de ports à partir de WSDL, lors de l'importation de services WCF. Pour contourner cette restriction, vous pouvez utiliser le code suivant afin d'obtenir les schémas et ajouter les schémas souhaités à vos projets BizTalk :

svcutil.exe /t:metadata http://service/metadataendpoint

L'Assistant Consommation de service WCF BizTalk ne permet pas la combinaison d'opérations unidirectionnelles et requête-réponse.

L'Assistant Consommation de service WCF BizTalk ne vous permet pas d'importer les types de ports qui ont une combinaison d'opérations unidirectionnelle et requête-réponse. Pour contourner ce problème, vous pouvez utiliser l'outil Service Model Metadata Utility Tool pour générer les types de ports.

L’Assistant Consommation de services WCF BizTalk ne vous permet pas de définir les informations d’identification de certificat lors de la récupération du WSDL

L'Assistant Consommation de service WCF BizTalk ne vous permet pas de définir les informations d'identification des certificats lors de l'extraction du WSDL. Pour contourner ce problème, vous pouvez utiliser l’outil Utilitaire de métadonnées ServiceModel pour générer les fichiers WSDL et XSD à partir des services WCF que vous souhaitez utiliser avec les informations d’identification de certificat définies dans le fichier svcutil.exe.config, puis les importer dans l’Assistant Consommation de services WCF BizTalk en choisissant l’option Fichiers de métadonnées (WSDL et XSD) dans la page Métadonnées source .

Les adaptateurs WCF ne prennent pas en charge les opérations unidirectionnelles.

Vous recevrez un message d’erreur semblable à ce qui suit lors de la consommation des services WCF publiés avec les adaptateurs WCF (à l’exception de l’adaptateur de réception WCF-NetMsmq) si la propriété IsOneWay a la valeur true côté client. En effet, la propriété System.ServiceModel.OperationContractAttribute.IsOneWay des services WCF publiés avec les adaptateurs WCF (à l’exception des services publiés avec l’adaptateur de réception WCF-NetMsmq) a la valeur false , même pour les emplacements de réception unidirectionnel.

The channel received an unexpected input message while closing. Your Channel.Close() calls are not synchronized.

Vous recevez un message d’erreur semblable à ce qui suit lors de l’utilisation des services WCF spécifiés avec la propriété IsOneWay définie sur true. Les messages que vous avez envoyés à partir de BizTalk Server sont suspendus et peuvent être repris.

The request operation at net.tcp://localhost:8088/MyService/tcp did not receive a reply within timeout 00:01:00.

Une fuite de mémoire peut se produire lors de l'envoi de messages aux files d'attente MSMQ non transactionnelles à l'aide de la liaison WCF-NetMsmq.

Une fuite de mémoire peut se produire dans le service NT BizTalk lors de l'envoi de messages aux files d'attente MSMQ non transactionnelles à l'aide de la liaison WCF-NetMsmq. Cela peut arriver lorsque vous envoyez des messages à une file d'attente MSMQ non transactionnelle à l'aide du transport WCF-NetMsmq ou lorsque vous envoyez des messages à une file d'attente MSMQ non transactionnelle utilisant netMsmqBinding avec le transport WCF-Custom.

Pour résoudre le problème, vous devez installer le correctif logiciel .NET Framework 3.0 décrit dans l’article de la base de connaissances 936512 à l’adresse https://go.microsoft.com/fwlink/?LinkId=92962. Le correctif ne requiert pas de redémarrage système mais il est nécessaire de redémarrer le service NT BizTalk qui héberge les ports d'envoi utilisant la liaison WCF-NetMsmq.

Vous pouvez obtenir une exception lors de la communication avec les serveurs Web Apache à l'aide de l'adaptateur WCF-BasicHttp.

Lorsque vous utilisez l'adaptateur WCF-BasicHttp avec la sécurité du transport pour communiquer avec un serveur Web Apache, vous pouvez obtenir une exception semblable à ce qui suit :

System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.
System.IO.IOException: Unable to write data to the transport connection: An established connection was aborted by the software in your host machine. System.Net.Sockets.SocketException: An established connection was aborted by the software in your host machine

Pour contourner ce problème, vous devez utiliser l'adaptateur WCF-Custom à la place de l'adaptateur WCF-BasicHttp pour communiquer avec les serveurs Web Apache, comme suit :

1. Créez un port d’envoi et définissez le type de transport sur WCF-Custom.

2. Dans la boîte de dialogue Propriétés de transport WCF-Custom, sous l’onglet Liaison , sélectionnez customBinding dans la liste déroulante Type de liaison .

3. Sous CustomeBindingElement, cliquez avec le bouton droit sur httpTransport, puis cliquez sur Supprimer l’extension.

4. Cliquez avec le bouton droit sur CustomeBindingElement, puis cliquez sur Ajouter une extension.

5. Dans la boîte de dialogue Sélectionner une extension d’élément de liaison , sélectionnez httpTransport , puis cliquez sur OK.

6. Cliquez sur httpTransport, puis, dans le volet Configuration , définissez la valeur de keepAliveEnabled sur False.

7. Cliquez sur textMessageEncoding, puis, dans le volet Configuration , définissez la valeur messageVersion sur Soap11WSAddressing10.

8. Vous devrez peut-être configurer des propriétés supplémentaires si nécessaire.

BizTalk Server ne fonctionne pas avec les clients WCF qui utilisent ClientViaBehavior pour les conversations à tronçons multiples.

Les clients WCF utilisent ClientViaBehavior lorsque la destination réseau immédiate n'est pas le processeur prévu du message pour permettre les conversations à tronçons multiples lorsque l'application d'appel ne connaît pas nécessairement la destination ultime. Si vous spécifiez clientViaBehavior et définissez l’adresse À sur un service distant où BizTalk Server fera office d’intermédiaire, vous recevrez le message d’erreur semblable au suivant :

The message with To 'net.tcp://localhost:5555/test.svc' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree