Bekannte Probleme bei den WCF-Adaptern
In diesem Thema werden die bekannten Probleme mit den WCF-Adaptern beschrieben, die in BizTalk Server enthalten sind.
Eine Nachricht, für die bei der eingehenden SOAP-Marshallingverarbeitung ein Fehler auftritt, wird in WCF-Empfangsadaptern nicht angehalten
Wenn eine Nachricht bei einem WCF-Empfangsadapter eingetroffen ist, erstellt der WCF-Adapter aus der eingehenden SOAP-Nachricht eine BizTalk-Nachricht und übergibt diese an den Transportproxy, der vom Endpunkt-Manager verwaltet wird. Kann der Adapter den SOAP-Umschlag und -Text beim Erstellen der BizTalk-Nachricht nicht lesen, wird die Nachricht nicht angehalten, weil der Adapter für den Zugriff auf die SOAP-Nachricht den schnellen, nicht zwischengespeicherten Vorwärtsleser verwendet.
Sie sollten das Ereignisprotokoll hinsichtlich der fehlerhaften Nachricht prüfen. Sie können beispielsweise einen Textpfadausdruck auf der Registerkarte Meldungen im Dialogfeld WCF-Adaptertransporteigenschaften verwenden, um anzugeben, wie der eingehende BizTalk-Nachrichtentext aus einer SOAP-Nachricht erstellt werden soll, die über den WCF-Adapter eingibt. Wenn auf der Registerkarte Nachrichten ein ungültiger Textpfadausdruck für die eingehende SOAP-Nachricht angegeben wird, kann der Adapter die BizTalk-Nachricht nicht erstellen und die eingehende Nachricht nicht anhalten. Weitere Informationen zur Verwendung des Textpfadausdrucks auf der Registerkarte Meldungen finden Sie unter Angeben des Nachrichtentexts für die WCF-Adapter.
Die folgende Abbildung zeigt die Registerkarte Nachrichten , auf der Sie angeben können, wie eingehende BizTalk-Nachrichten aus den eingehenden SOAP-Nachrichten erstellt werden sollen.
Eine Nachricht, für die bei der eingehenden SOAP-Marshallingverarbeitung ein Fehler auftritt, wird in WCF-Sendeadaptern nicht angehalten
Der WCF-Sendeport vom Typ „Antwort anfragen“ kann eine WCF-Nachricht als Antwortnachricht empfangen. Wenn die Nachricht beim WCF-Sendeadapter eingeht erstellt der WCF-Adapter aus der eingehenden SOAP-Nachricht die BizTalk-Nachricht und übergibt diese an den Transportproxy, der vom Endpunkt-Manager verwaltet wird. Kann der Adapter den SOAP-Umschlag und -Text beim Erstellen der BizTalk-Nachricht nicht lesen, wird die Nachricht nicht angehalten, weil der Adapter für den Zugriff auf die SOAP-Nachricht den schnellen, nicht zwischengespeicherten Vorwärtsleser verwendet.
Sie sollten das Ereignisprotokoll hinsichtlich der fehlerhaften Nachricht prüfen. Sie können beispielsweise einen XPath-Ausdruck auf der Registerkarte Meldungen im Dialogfeld WCF-Adaptertransporteigenschaften verwenden, um anzugeben, wie der eingehende BizTalk-Nachrichtentext aus einer SOAP-Nachricht erstellt werden soll, die über den WCF-Adapter eingibt. Wenn auf der Registerkarte Nachrichten ein ungültiger XPath-Ausdruck für die eingehende SOAP-Nachricht angegeben wird, kann der Adapter die BizTalk-Nachricht nicht erstellen und die eingehende Nachricht nicht anhalten. Weitere Informationen zur Verwendung des XPath-Ausdrucks auf der Registerkarte Meldungen finden Sie unter Angeben des Nachrichtentexts für die WCF-Adapter.
Die folgende Abbildung zeigt die Registerkarte Nachrichten des WCF-NetNamedPipe-Sendeadapters als Beispiel.
Nachrichten können verloren gehen, wenn „OneWayBindingElement“ in einem bidirektionalen Transport mit benutzerdefinierter Bindung in WCF-Empfangsspeicherorten ohne Transaktionsverarbeitung verwendet wird
In einer bidirektionalen Kommunikation senden WCF-Adapter die Antwort zurück, bis die Nachrichten dauerhaft in der MessageBox-Datenbank gespeichert wurden. Die Verwendung von OneWayBindingElement generiert jedoch unmittelbar vor dem Senden der empfangenen Nachricht an den WCF-Adapter eine Dummyantwort. Wenn Sie also eine benutzerdefinierte Bindung mit einem OneWayBindingElement im Kanalstapel für den bidirektionalen Transport an nicht transaktionalen Empfangsspeicherorten konfigurieren, können Nachrichten verloren gehen, da die WCF-Adapter die empfangenen Nachrichten unidirektional verarbeiten.
Beim Erstellen der Bindungen werden in den Dialogfeldern für die Transporteigenschaften „WCF-Custom“ und „WCF-CustomIsolated“ die Standardwerte der ReaderQuotas-Attribute verwendet
In den Dialogfeldern WCF-Custom und WCF-CustomIsolated Transporteigenschaften werden die ReaderQuotas-Attributwerte als null angezeigt. Beim Erstellen der Bindungen werden jedoch folgende Werte verwendet:
| attribute | BESCHREIBUNG | Wert |
|---|---|---|
| maxArrayLength | Eine positive Ganzzahl, die die maximal zulässige Länge eines Arrays angibt. | 16384 |
| maxBytesPerRead | Eine positive Ganzzahl, die angibt, wie viele Bytes pro Lesevorgang maximal zurückgegeben werden dürfen. | 4096 |
| maxDepth | Eine positive Ganzzahl, die angibt, wie groß pro Lesevorgang die maximal zulässige Schachtelungstiefe für Knoten ist. | 32 |
| maxNameTableCharCount | Eine positive Ganzzahl, die angibt, wie viele Zeichen in einem Tabellennamen maximal zulässig sind. | 16384 |
| maxStringContentLength | Eine positive Ganzzahl, die angibt, wie viele Zeichen im Inhalt eines XML-Elements maximal zulässig sind. | 8192 |
Die WCF-Empfangsspeicherorte werden möglicherweise deaktiviert, wenn Sie den WCF-Adaptertyp, aber nicht die Adresse ändern.
Wenn Sie den Adaptertyp ändern (beispielsweise den WCF-Adaptertyp von „WCF-NetTcp“ in „WCF-Custom“ mit NetTcp-Bindung), die Adresse aber beibehalten, wird der Empfangsspeicherort möglicherweise deaktiviert, weil im Endpunkt-Manager ein Cacheproblem auftritt. Führen Sie eine der folgenden Aktionen aus, um dieses Problem zu umgehen:
Starten Sie den Dienst „BTSNTSvc“ neu.
Ändern Sie die URI in eine andere Adresse, speichern Sie diese, ändern Sie die URI dann wieder in die ursprüngliche Adresse, und speichern Sie schließlich diese.
Die WCF-Aktion, die in der Orchestrierung festgelegt ist, setzt nicht die Aktionseinstellung im statischen Sendeport außer Kraft.
Wenn Sie wcf festlegen . Aktionskontexteigenschaft in der Orchestrierung. Sie müssen das Feld Aktion im Dialogfeld WCF-Adaptertransporteigenschaften leer lassen. Wenn Sie auch eine Aktion im statischen Sendeport angeben, wird wcf verwendet. Die in der Orchestrierung festgelegte Aktionskontexteigenschaft wird durch den Wert überschrieben, den Sie im statischen Sendeport festlegen.
Weitergeben einer Fehlermeldung wird in einem Sendevorgang, der als Transaktion erstellt ist, nicht unterstützt.
Mit der Option Fehlernachricht weitergeben in den Sendeports solicit-response können Sie die Nachrichten, die bei der ausgehenden Verarbeitung fehlschlagen, an eine abonnierende Anwendung weiterleiten. Wenn jedoch auch das Kontrollkästchen Transaktionen aktivieren im Dialogfeld Transporteigenschaften aktiviert ist und die Transaktion abgebrochen oder nicht verwendet werden kann, wenn die Fehlerantwort beim Adapter eingeht, können Sie die Fehlermeldungen nicht an abonnierte Anwendungen weitergeben.
Die MSMQ-Clusterressourcengruppe muss neu gestartet werden, bevor im Verlauf des Clusterfailovers die BizTalk-Host-Clusterressourcengruppe neu gestartet wird
In einem Szenario mit Failovercluster muss die MSMQ-Clusterressourcengruppe, wenn ein Failover erfolgt, neu gestartet werden, bevor die BizTalk-Host-Clusterressourcengruppe neu gestartet wird. Wenn Sie diese Vorgehensweise nicht einhalten, kann es vorkommen, dass die MSMQ-Empfangsspeicherorte deaktiviert werden. Zum Umgehen dieses Problems können Sie die BizTalk-Host-Clusterressourcengruppe so einstellen, dass sie von der MSMQ-Clusterressourcengruppe abhängig ist. Dadurch ist sichergestellt, dass die MSMQ-Clusterressourcengruppe vor der BizTalk-Host-Clusterressourcengruppe gestartet wird. Alternativ können Sie dieses Problem umgehen, indem Sie die BizTalk-Host-Clusterressourcengruppe neu starten.
Es wird ein Fehler angezeigt, wenn Sie Nachrichten an einen WCF-Dienst senden, für den „wsFederationHttpBinding“ im Endpunkt verwendet wird.
Es wird eine Fehlermeldung angezeigt, die wie die folgende aussieht:
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.".
Dieses Verhalten ist beabsichtigt. WCF-Adapter können keine Nachrichten an die WCF-Dienste senden, die wsFederationHttpBinding in ihren Endpunkten verwenden.
Im Verarbeitungs-Assistenten für BizTalk-WCF-Dienste können Sie keine Nachrichtentypen oder Porttypen aus der WSDL auswählen.
Im Verarbeitungs-Assistenten für BizTalk-WCF-Dienste können Sie keine Nachrichtentypen oder Porttypen aus der WSDL auswählen, wenn Sie die WCF-Dienste importieren. Zum Umgehen dieser Beschränkung können Sie mit dem folgenden Code die Schemas abrufen und anschließend Ihren BizTalk-Projekten die gewünschten Schemas hinzufügen:
svcutil.exe /t:metadata http://service/metadataendpoint
Im Verarbeitungs-Assistenten für BizTalk-WCF-Dienste können unidirektionale und Anforderungsantwort-Operationen nicht kombiniert werden.
Im Verarbeitungs-Assistenten für BizTalk-WCF-Dienste können Sie nicht die Porttypen importieren, in denen unidirektionale und Anforderungsantwort-Vorgänge kombiniert sind. Zum Umgehen dieses Problems können Sie das Hilfsprogramm für ServiceModel-Metadaten („svcutil.exe“) verwenden, um die Porttypen zu generieren.
Mit dem BizTalk WCF-Dienstverbrauchs-Assistenten können Sie beim Abrufen der WSDL keine Zertifikatanmeldeinformationen festlegen.
Im Verarbeitungs-Assistenten für BizTalk-WCF-Dienste können keine Anmeldeinformationen für Zertifikate festgelegt werden, wenn die WSDL abgerufen wird. Um dies zu umgehen, können Sie das ServiceModel Metadata Utility Tool verwenden, um die WSDL- und XSD-Dateien aus den WCF-Diensten zu generieren, die Sie verwenden möchten, wobei die Zertifikatanmeldeinformationen in der svcutil.exe.config-Datei festgelegt sind, und sie dann in den BizTalk WCF-Dienstnutzungs-Assistenten importieren, indem Sie auf der Seite Metadatenquelle die Option Metadatendateien (WSDL und XSD) auswählen.
WCF-Adapter unterstützen keine unidirektionalen Operationen.
Sie erhalten eine Fehlermeldung ähnlich der folgenden, wenn Sie WCF-Dienste nutzen, die mit den WCF-Adaptern veröffentlicht wurden (mit Ausnahme des WCF-NetMsmq Empfangsadapters), wenn die IsOneWay-Eigenschaft auf Clientseite auf true festgelegt ist. Dies liegt daran, dass die System.ServiceModel.OperationContractAttribute.IsOneWay-Eigenschaft von WCF-Diensten, die mit den WCF-Adaptern veröffentlicht wurden (mit Ausnahme von Diensten, die mit dem WCF-NetMsmq Empfangsadapter veröffentlicht wurden) selbst für die unidirektionalen Empfangsspeicherorte auf FALSE festgelegt ist.
The channel received an unexpected input message while closing. Your Channel.Close() calls are not synchronized.
Sie erhalten eine Fehlermeldung ähnlich der folgenden, wenn Sie die WCF-Dienste nutzen, die mit der auf true festgelegten IsOneWay-Eigenschaft angegeben sind. Die Nachrichten, die Sie von BizTalk Server gesendet haben, werden angehalten und können fortgesetzt werden.
The request operation at net.tcp://localhost:8088/MyService/tcp did not receive a reply within timeout 00:01:00.
Es kann ein Arbeitsspeicherverlust auftreten, wenn Nachrichten über WCF-NetMsmq-Bindung an MSMQ-Warteschlangen gesendet werden, die keine Transaktionswarteschlangen sind.
Es kann ein Arbeitsspeicherverlust im BizTalk NT-Dienst auftreten, wenn Nachrichten über WCF-NetMsmq-Bindung an MSMQ-Warteschlangen gesendet werden, die keine Transaktionswarteschlangen sind. Dies kann auftreten, wenn Sie Nachrichten über WCF-NetMsmq-Transport oder über „netMsmqBinding“ mit WCF-Custom-Transport an MSMQ-Warteschlangen senden, die keine Transaktionswarteschlangen sind.
Um das Problem zu beheben, müssen Sie .NET Framework 3.0-Hotfix installieren, der im KB-Artikel 936512 unter https://go.microsoft.com/fwlink/?LinkId=92962beschrieben ist. Für den Hotfix ist kein Neustart des Systems, aber ein Neustart des BizTalk NT-Diensts erforderlich, der die Sendeports hostet, die die WCF-NetMsmq-Bindung verwenden.
Beim Kommunizieren mit Apache-Webservern über den WCF-BasicHttp-Adapter können Ausnahmen auftreten.
Wenn Sie den WCF-BasicHttp-Adapter mit Transportsicherheit verwenden, um mit einem Apache-Webserver zu kommunizieren, wird möglicherweise eine Ausnahme wie im folgenden Beispiel angezeigt:
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
Zum Umgehen dieses Problems müssen Sie für die Kommunikation mit den Apache-Webservern statt des WCF-BasicHttp-Adapters den WCF-Custom-Adapter wie folgt verwenden:
Erstellen Sie einen Sendeport, und legen Sie den Transporttyp auf WCF-Custom fest.
Wählen Sie im Dialogfeld WCF-Benutzerdefinierte Transporteigenschaften auf der Registerkarte Bindung in der Dropdownliste Bindungstyp die Option customBinding aus.
Klicken Sie unter CustomeBindingElement mit der rechten Maustaste auf httpTransport, und klicken Sie dann auf Erweiterung entfernen.
Klicken Sie mit der rechten Maustaste auf CustomeBindingElement, und klicken Sie dann auf Erweiterung hinzufügen.
Wählen Sie im Dialogfeld Bindungselementerweiterung auswählen die Option httpTransport aus, und klicken Sie dann auf OK.
Klicken Sie auf httpTransport, und legen Sie dann im Bereich Konfiguration den Wert von keepAliveEnabled auf False fest.
Klicken Sie auf textMessageEncoding, und legen Sie dann im Bereich Konfiguration den Wert von messageVersion auf fest
Soap11WSAddressing10.Möglicherweise müssen Sie weitere Eigenschaften konfigurieren.
BizTalk Server kann nicht mit WCF-Clients arbeiten, die für Konversationen über mehrere Hops „ClientViaBehavior“ verwenden
WCF-Clients verwenden „ClientViaBehavior“, wenn das unmittelbare Netzwerkziel nicht der beabsichtigte Verarbeiter der Nachricht ist. Auf diese Weise werden Konversationen über mehrere Hops ermöglicht, wenn die aufrufende Anwendung nicht unbedingt das endgültige Ziel kennt. Wenn Sie ClientViaBehavior angeben und die Adresse für An auf einen Remotedienst festlegen, in dem BizTalk Server als Vermittler fungiert, erhalten Sie eine Fehlermeldung ähnlich der folgenden:
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