June 2010 Entries

Two posts on one day? Is he on his holidays? Yes!

We had a lot of trouble with this error:

...Error Description: System.ServiceModel.CommunicationException: An error (The request was aborted: The request was canceled.) occurred while transmitting data over the HTTP channel....

You find a few posts about it in the www but the answers are somewhat conflicting and not very nice. No, I will not tell you the answer in this post, because we still do not really have it, but I want to show you how to perform one step that might lead you closer to it.

The error occurs under high load only in one of our environments. Of course the production environment.. Thank you, Mr. Murphy...

We are using a rather complicated Orchestration structure and make a lot of WCF-calls from BizTalk to WCF-Services. As a binding we use WCFBasicHttpBinding with SSL and Basic Authentication. Most of the posts in the www point to setting the KeepAlive-flag to false. MS-Suport asked us to it, too. But this is not a property present in the usual WCFBasicHttpBinding. So we had to switch to customBinding in WCF-Custom Transport. I was not able to find posts about how to do that and had to try out a few things until I was successful. To save you some time, here is what worked:

  1. Import the custom-binding that was created when generating the service-reference (switching completely from DynamicPort to a static Port, but that is another story...)
  2. Configuring the Transport I switched the BindingType in Binding to "customBinding"
  3. Remove the "httpTransport" extension and add a "httpsTransport" extension, as you want to use SSL. You have to remove "httpTransport" first because otherwise "httpsTransport" will not show up in the extensions.
  4. Move "httpsTransport" to the last place of the extensions, otherwise BizTalk/WCF does not like it...
  5. In "httpsTransport" set "authenticationScheme" to "Basic"
  6. Here you can set "keepAliveEnabled" to "false" and other important properties like "maxReceivedMessageSize", too!
  7. In the "textMessageEncoding" node you have to set "messageVersion" from "Default" to "Soap11WSAddressingAugust2004" as you want to use basicHttp under the hood. Under "textMessageEncoding" you will find the "ReaderQuotas", too.
  8. In the "Credentials"-tab set username and password for basic authentication, or use SSO

When trying for the first time with the newly created SendPort I got an error that communication with the service could not be established. The binding was changed to custom-binding so that was not too surprising...

To make things a little easier I exported a web.config in the "Import/Export"-tab in the WCF-Custom Transport Properties and adjusted the web.config of the service I called based on the exported web.config. Here we were fortunate enough that the Service is under our control and it is a WCF-service...

Now it works all fine. If it really helps us with error we will find out soon. To be continued...

*****

Update: All the work did not help with the error at all. It turned out it was the service on the other side producing the error. But I don't know what has been changed to get it working.

You created classes from your XML-Schemas (using XSD.exe for example) and want to use them in BizTalk. There may be several reasons for and against doing it. But I do not want to discuss that here. Just assume you want to do it. ;-)

After you deployed your BizTalk App and start sending the first messages to your ReceiveLocation with an XML Receive Pipeline of a MessageType that a schema and a class exist for. BizTalk is not able to decide whether  class or schema should be used and  gives you a nice error in the event log: 

There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, .....

 Reason: Cannot locate document specification because multiple schemas matched the message type http://myschema...#Order.

 

When you have a look at the schemas in the BTS-Admin-Console you discover that you have two Schemas listed there with identical namespaces and root-names, resulting in identical MessageTypes.

To show BizTalk which Assembly it should use you can use the property "DocumentSpecNames" in the configuration of the XMLReceive Pipeline of your ReceiveLocation. Just type or paste the full strongname of the Assembly and the type that should be used, e.g. MySchemas.Schemas.Order, Schema.Order, Version=1.0.0.0, Culture=neutral, PublicKeyToken=88c5c240c6b0ed6f.

Please ignore the namespaces in my post. They are just for demonstration... ;-)

 

Posted On Friday, June 25, 2010 9:54 AM | Feedback (0)
Filed Under [ BizTalk ]