The issue is as follows. I use a WCF-Custom sendport but I keep getting the following error message:
The adapter failed to transmit message going to send port “SndAppResponse1ToTrc.REST” with URL “http://hatch.bap-a.rfsinternal.net:8081/rest”. It will be retransmitted after the retry interval specified for this Send Port. Details:”System.TimeoutException: The HTTP request to ‘http://hatch.bap-a.rfsinternal.net:8081/rest/ApplicationResponse’ has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout. —> System.Net.WebException: The request was aborted: The request was canceled. at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult) at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelAsync
Request.CompleteGetResponse(IAsyncResult result) — End of inner exception stack trace —
I’m using Wireshark for troubleshooting and I can see the message is sent via the proxy server.
That’s the reason the message is never received by the target system. The question is: how can I prevent the message from being sent via the proxy server? This is what I found.
Selecting “Do not use proxy” from the send port does not mean no proxy will be assigned. There’s a hierarchy in proxy assignment:
Define proxy server at the send port when configuring the transport type (or adapter). Not possible for all transport types. Possible for Http, not possible for WCF-Custom.
BizTalk App Config (BTSNTSvc.exe).
Machine Config (64 bits).
Local IE user setting.
Specification on send port:
Very straight forward, below an example of a HTTP send port:
And an example of a WCF-Custom port. Less obvious, mind the settings marked in red:
Specification in NTSNTSvc.exe.config or machine.config.
The following code example uses the defaults from the Internet Explorer proxy, specifies the proxy address, and bypasses the proxy for local access and contoso.com.
If the defaultProxy element is missing altogether, the proxy settings from Internet Explorer will be used.
<add address=”[a-z]+.contoso.com” />
local IE user settings
If you specify a proxy server via Internet Explorer, you actually set the proxy settings at the system level. This might seem strange but it is definitely the case and can easily be overlooked. It can even get more confusing. Suppose you double checked in IE, that you are not using a proxy. That still doesn’t mean no proxy is used. Suppose you log into the BizTalk box using the account running the BizTalk host. If you now set the proxy in IE under these user settings, the ProxyEnabled setting for this user will be set to true in the registry. Not only will the proxy settings be picked up, but also the IE “Automatically detect settings” configuration. This can adversely impact BizTalk processing.
You can check if any user has ProxyEnabled set to true via RegEdit. Click Edit/Find and search for proxy. It’s possible that you find multiple proxy settings. These have to be removed, just to be sure they do not adversely affect BizTalk processing. You can try and logon with different users to remove the setting via RegEdit, but that’s like searching for a needle in a haystack. That’s because you can’t easily see in the registry editor to which user the proxy settings belong.
Solution: In the end it turned out that my specification of the WCF-Custom port (uses proxy by default) were false. After changing the settings of the webHttpBinding it worked.