BizTalk WCF Timeout Issue - wcf

I have a orchestration in BizTalk which is collect to data via web services from SAP.
My process is as below.
We have a SOAP service on receive port and when we get an request from SOAP we transform it to SAP RFC File format and send it to SAP. When we try to get a response from SAP we get an error when response data is big. If response message size is so big our service get a timeout error. Otherwise there is a no problem if the message size is not big.
I tried to increase timeout duration on BizTalk management console but still fails. Whatever I did, the timeout duration is always in 1 minutes.
After Adding below XML config tags to machine.config file I get an error as below figure.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config
<configuration>
<system.transactions>
<machineSettings maxTimeout="00:20:00" />
</system.transactions>
</configuration>
Below image is SAP Send Port
SAP Send Port Details
In the detail as you can see my time out duration about 10 hour but in SOAP UI I get an timeout error after 1 minute.
Below image is Receive Port
Also you can find biztalk event viewer error as below.
A response message sent to adapter "SOAP" on receive port "WebPort_SAP/MusteriFaturaT/ABC_SAP_Fatura_T_FaturaOrch_InvoiceReceivePort" with URI "/SAP/MusteriFaturaT/ABC_SAP_Fatura_T_FaturaOrch_InvoiceReceivePort.asmx" is suspended.
Error details: The original request has timed out. The response arrived after the timeout interval and it cannot be delivered to the client.
And SOAPUI response screen is blank as below

On WCF Custom send port, change the value of time out (close, open, send, receive) to increase timeout. See the link for more details
You can also use SOAPUI tool to test your web service outside BizTalk to see the response time and response size.

Problem is about SOAP UI timeout issue. When i change the timeout property of SOAP our timeout duration was increase to 110 second. 110 second is default soap timeout duration. For fix this issue you have to add below config options to web.config file.
<system.web>
<httpRuntime executionTimeout="43200" />
</system.web>
Also you have to add below configs to client app.config file.
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="IBRAHIM_SAP_Fatura_T_FaturaOrch_InvoiceReceivePortSoap" maxReceivedMessageSize="2147483647" receiveTimeout="03:00:00"
sendTimeout="02:00:00" transferMode="Streamed"/>
</basicHttpBinding>
</bindings>
</system.serviceModel>

UPDATE:
Now we have the error it is indicating that it is the client that timed out rather than BizTalk, in this case SoapUI. As per the answer from this question SoapUI: ConnectException: Connection timed out:
Default socket timeout is set to 60000 milliseconds. You can change it:
File -> Preferences -> HTTP Settings -> Socket Timeout
When you are connecting with another client, you will also have to check/set the timeouts in that.
ORIGINAL POST:
If you are using BizTalk 10 or above check the response timeout on the host is set to a value greater than a minute.
I had an issue with Timeouts as well an this was one setting I changed (in this case to the maximum).
You can set up a specific Host for large transactions where the Response timeout in minutes is changed and only those ports that need it use it.
However even after I changed that to the maximum value I encountered a timeout after 15 minutes.
For that I had to disable Use Transaction, only do this if you still encounter issues and you are retrieving data and not inserting/changing data.
The above images are from my blog post about the issue BizTalk Server Negative Acknowledgement issues in SAP and WCF.
As to setting the system.transaction setting in the config, that is rather dangerous to do as it will affect everything, not just that port.

You have to increase your timeout in the machine.config file
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config
<configuration>
<system.transactions>
<machineSettings maxTimeout="00:20:00" />
</system.transactions>
</configuration>
You must also set the property allowExeDefinition to "MachineToApplication" from "MachineOnly"

Related

signalR client cannnot reconnect

I have a website web.glidertracking.co.uk which seems to work well but after a short time it stops working.
In Firefox on the console I get the message
Firefox can't establish a connection to the server at
ws://web.glidertracking.co.uk/signalr/reconnect?transport=webSockets&messageId=d-F12111CE-A%2C2F76%7CE%2C0%7CF%2C1%7CG%2C0&clientProtocol=1.4&connectionToken=9rtmojkUsiTz1k1hGHAHq5NDVy%2Fs96KyNyrvR1YDeHsqqraESwr4ky2waZfL4MRhFykwSxLEsdKMGQkKiH6Pkd7AZ%2BF1CqjuyN0xKcgxWb9PldJXF0ILOOw4JEE7A7wZ&connectionData=%5B%7B%22name%22%3A%22aprshub%22%7D%5D&tid=8.
jquery.signalR-2.1.1.js:1622:36 This is repeated several times as the
page tries to reconnect.
In Chrome the same thing happens with the message
WebSocket connection to
'ws://web.glidertracking.co.uk/signalr/reconnect?transport=webSockets&messageId=d-50D0B86A-A%2C42E5%7CH%2C0%7CI%2C1%7CJ%2C0&clientProtocol=1.4&connectionToken=088xfYgsm2yPs1Ig2VxFqLBuwlLoKtDPWl9FKEMr3%2Bt%2F%2F56DEnBqXBQiVoG93tfRPTxprdtPtKBGnKCAyDZfpy3Z1pw1pRiz6kxAGapXXoAhUDmeCQePBXVcdltFrfgh&connectionData=%5B%7B%22name%22%3A%22aprshub%22%7D%5D&tid=0'
failed: Error during WebSocket handshake: Unexpected response code:
400
Can anyone Help me.
What is going wrong?
I would be happy to provide the code for the whole site but there is a lot of code!
Had similar issue, SignalR connection was ok, but re-connect fail with Unexpected response code: 404, or (after some manipulations with web.config) with Unexpected response code: 400.
Solved after checking & changing limitations for maxQueryStringLength, maxUrlLength, maxQueryString. in the Web.Config:
<system.web>
<httpRuntime maxQueryStringLength="32768" maxUrlLength="65536"/>
<security>
<requestFiltering>
<requestLimits maxQueryString="32768"/>
</requestFiltering>
</security>
<system.web/>
Values "32768" & "65536" just for example, check and test your own.
P.S.In our case, we had a long query string, because we send all the hub's names to the server thinking that it is necessary for reconnect. But after all we saw, that it was no nessesary.

What's the difference in WCF between Ntlm and NTLM, and how can I fix it?

I've got a WCF service that's running on IIS 6, with integrated authentication and impersonation using NTLM.
Relevant portions of Web.Config
<system.web>
<identity impersonate="true"/>
<customErrors mode="Off"></customErrors>
</system.web>
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
...
</system.web>
...
<wsHttpBinding>
<binding name="wsHttpEndpointBinding">
<security mode="Transport">
<transport clientCredentialType="Ntlm" />
</security>
</binding>
</wsHttpBinding>
I just added the aspNetCompatibility because I want to know who the user is that's logged in (at least as far as IIS is concerned). From the few searches I've done that's how you get the user.
Well, after adding that line and publishing my server I get what's possibly the stupidest error I've seen:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'.
I thought, "Well obviously they're doing a very case-sensitive comparison." So I searched my entire client solution for Ntlm and replaced all non-variable occurrences with NTLM. No luck.
My primary goal, of course is to get whatever user was authenticated through IIS+NTLM. If I'm going about it the wrong way, I'd be happy to know of an easier/better way. Otherwise, how do I tell my client (or my server) that it's OK to go ahead and authenticate?
One other possibility if you are running across this error is that you are experiencing an issue with the loopback check with NTLM. I have a service which runs self-contained on a non-domain (workgroup) server. WCF is configured using BasicHttpBinding with Transport security mode and Ntlm client credentials. When trying to access the service using https://servername it works great. If I try to access it using the FQDN (https://servername.domain.com) it fails with the same error:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'.
If you look inside the Windows security log you will see an Audit Failure with event ID 4625. In this you will see the following failure information:
Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xc000006d
Sub Status: 0x0
To resolve this you need to either add the back connect host names (preferred) or disable the loopback check. This was a security enhancement added for NTLM in Windows Server 2003 SP1 and later to close out an attack vector against the protocol. The fix, however, causes a lot of unclear error messages like this one from WCF and continues to haunt me in many obscure ways to this day.
Start Here . This should resolve your issue

WCF Connection Closed exception on the 256 call

I found an interesting error, always on call 256 in an process (there can be several running at the same time, but always the 256 call from each process will fail)
We are getting Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
An error occurred while receiving the HTTP response to [uri]. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.
What is can be wrong, it seems to be the client, but it is?
Could it be because any limitation in Windows 7 and Windows Server Web Edition?
I expect the wcf and/or TCP stack to run out of connections.
have a look here:
http://msdn.microsoft.com/en-us/library/ms731078.aspx
and see if fiddling with the idleTimeout or MaxConnections help.
Try adding a custombinding to your config.
<customBinding>
<binding name="mynettcp">
<binaryMessageEncoding />
<tcpTransport
maxPendingConnections="100"
maxPendingAccepts="10"
listenBacklog="100">
<connectionPoolSettings
idleTimeout="00:00:00"
maxOutboundConnectionsPerEndpoint="0" />
</tcpTransport>
</binding>
</customBinding>
Then in the binding attribute of your service change the value to mynettcp
I it is in my company's firewall.
Thanks for your help rene

WCF SOAP over HTTPS, WCF Test Client calls the http address and the server responds with 404

TL;DR version is at the bottom.
I have constructed three WCF web services -- one that's using .NET 4 and two that's using .NET 3.5 -- that is consumed by an Android client. The Android client performs the calls using ksoap2-android. When the services were complete and the client could make all the calls and get all the data from the services, we decided to activate HTTPS communication for the web services. They are hosted on a server running IIS.
I'm not alone on this task. I work full-time with it, mainly the Android client. I have two coworkers, both of which have a lot of other responsibilities. The first is mostly involved in the services and the second is mostly involved in the server.
I've read a lot of guides, blogs and articles on the Internet on how to enable HTTPS for a WCF web service, but still I haven't been able to completely resolve this. For the Android client to be able to consume the client, we are limited to using the basicHttpBinding, since the wsHttpBinding contains some security details that are not supported by Android, or something. I'm not sure, but I read it some forum somewhere. If I'm wrong, I'd happily be corrected!
Okay, so I'll give a short account of what I've done so far:
I've enabled transport security, this is how the binding(s) looks:
<bindings>
<basicHttpBinding>
<binding name="basicHttp" closeTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00">
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
</binding>
</basicHttpBinding>
</bindings>
I've enabled meta data publishing over HTTPS using this line of code:
<serviceMetadata httpsGetEnabled="true" />
and this:
<endpoint address="" binding="mexHttpsBinding" contract="IMetadataExchange" />
Also, my second coworker has installed a trusted certificate (a real certificate from a CA) on the IIS server and added a https binding on the server.
Okay, so far, so good. Now we could connect to the services in the browser.
When we had done this it was possible to visit the service in the browser in a secure, encrypted, manner.
The problem is that it isn't possible to make a call to the service, neither in Android nor WCF Test Client. If I call the service on the https address, I get a 404 in response. WCF Test Client returns this:
There was no endpoint listening at https://[my service address] that could accept the message. This is often caused by an incorrect address or SOAP action.
To be able to debug this, I'm using Wireshark to intercept the messages and see what really happens. I've found out that after the set up procedures (handshake, establishing trust etc.) the client sends the header and get a 101 Continue in response, after which it POSTs the body. This should be normal behavior. But then the service returns 404 Not Found. Wireshark says that the full request URI is the http address. I've configured the server to use the https address, so why does it make a call to the http address?
I've tried setting the address and listenUri attribute of the endpoint to https and http respectively and the other way around. If I do that, the server answers the request with 405 Method Not Allowed.
Is there any way to solve this? What am I missing?
What am I missing?
TL;DR version below
I'm hosting three WCF SOAP web services with IIS, one using .NET 4 and the others using .NET 3.5. I'm trying to make a call from the WCF Test Client over HTTPS. I've enabled transport security, meta data publishing over HTTPS, installed a trusted certificate and added a https binding on the server.
When I try to make a call from WCF Test Client it says that there was no endpoint listening at the address. Wireshark tells me it makes the call to the http version of the service (i.e. "http://[my address]" instead of "https://[my address]"), although it is configured to call the https address. The service returns 404 Not Found. If I set the address of the service to https and listenUri to http, I get 405 Method Not Allowed. If I do it the other way around it says that it cannot be activated. What am I missing?
I solved this by removing the endpoint and using the <protocolMapping> tag, like this:
<protocolMapping>
<add scheme="https" binding="basicHttpBinding" bindingConfiguration="basicHttps" />
</protocolMapping>

WCF connection limits

We have a WCF net.tcp service in high traffic site.
http://www.artedelcorpo.com/
It works very well for some time, then it stops and returns a timeout error.
When I restart IIS, it runs again.
Why?
Is there a limit on connections?
There is a default setting of 10 connections for the NetTcp Binding. You can increase this in the <binding> section of your config. The same is true of the timeouts - the default is 1 minute, but you can also adjust the close timeout, open timeout, receive timeout and send timeout.
<system.serviceModel>
<bindings>
<netTcpBinding>
<binding name="MyNetTcpBinding" closeTimeout="00:05:00"
openTimeout="00:05:00" receiveTimeout="00:05:00"
sendTimeout="00:05:00" maxConnections="100" />
<netTcpBinding>
</bindings>
</system.serviceModel>
The above sample will set the timeouts to 5 minutes and the max connections to 100.
See <netTcpBinding> for more detail/information.
Increasing network timeouts buys you time for the request to be processed. This can help you survive a short burst of high traffic, but it doesn't change your system throughput.
If your hardware still has some headroom in terms of memory and CPU when these problems occur, you should look at changing your concurrency throttles. This will allow more requests to be processed in parallel. The default throttle values in .NET 3.5 are actually quite conservative and this might be a quick fix (depending on your service architecture).
Here's some good examples of configuring WCF service throttles.
If your hardware is maxed out and you are still getting timeouts, its probably time to cluster the service and add another node.