2

I have got a Azure Function APP, HTTP trigger calling a webservice and passing on Soap message containing XML. (hosted via APP service plan) Locally, using VS2019 the function successfully reaches the web service and receives response within 25 seconds or less. When published to Azure, the function timesout only after < 23 Seconds.

I get a HTTP server 500 error back: 2021-10-20T09:54:46.263 [Error] Executed 'XXXX' (Failed, Id=0cc4db22-f9ba-4c5d-9f6e-ecd1da394333, Duration=22131ms)A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Update: this has been resolved by creating a virtual network for all outbound requests for the function app https://learn.microsoft.com/en-us/azure/azure-functions/functions-how-to-use-nat-gateway.

Zain
  • 21
  • 3
  • Please provide enough code so others can better understand or reproduce the problem. – Community Oct 20 '21 at 10:16
  • Could you please have a look at durable function https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview?tabs=csharp – AjayKumarGhose Oct 20 '21 at 17:36

2 Answers2

0

You can try to reach to the SOAP webservice that your are trying to hit from the kudu console of your function app. see details at https://github.com/Azure/azure-functions-host/issues/957 , most likely the outbound IP address of azure is not whitelisted by your server hosting the SOAP webservice.

Anand Sowmithiran
  • 2,591
  • 2
  • 10
  • 22
  • hi @Anand Sowmithiran, thanks for your response. I tried a curl via the kudu console and it also timed out. I had IT monitor requests on the firewall for the webservice and they said they did not receive any requests to their firewall to begin with. When i tried the same when ran through VS the request went through. how is it different calling it after it being published than when calling it locally beside the IP address? – Zain Oct 20 '21 at 17:33
  • so, that proves that request does not go upto the webserver. next, you need to check if your webserver name resolves in your kudu console. check using nslookup, tracert commands. – Anand Sowmithiran Oct 21 '21 at 05:26
  • I used tcpping.exe on the kudu and couldnt reach it. the question is why can i reach it when running the code from visual studio and not reach when the code is deployed? what extra layer is deployed Azure function adding to we have in the visual studio? – Zain Oct 21 '21 at 09:04
  • @Zain, the function app is hosted in a VM that is inside the azure network..so that is entirely different than when you run locally in your system, you cannot expect the network connectivity to be present. Your webservice is hosted on a server which does not allow azure network, or not exposed to public internet at all, check with your network admin of that webservice. – Anand Sowmithiran Oct 21 '21 at 11:05
  • the webservice is exposed to public internet and we can reach it from a browser. we have also whitelisted all the outbound IP addresses from the function. the service is not getting any requests at all, so probably issue is on the Function's side. I am wondering if an extra component needs to be added to function so it can talk an external web service like a NAT Gateway. Thanks – Zain Oct 21 '21 at 11:50
  • @Zain in your Azure portal, in your function app, go to Networking tab and check the outbound addresses and whitelist the webserver's IP that you are trying to reach. Also, ensure if TLS/SSL is enabled if your webservice expects https only traffic. – Anand Sowmithiran Oct 21 '21 at 12:45
0

Thank you Jerry Liu posting your suggestion as an answer to help other community members.

"It is expected. Http request has a fixed timeout setting on Azure site. See Azure Web App timeout setting of 230s. In this aspect, there's no difference between Azure Web app and Http trigger Azure Function.

There is a 230 second (i.e. a little less than 4 mins) timeout for requests that are not sending any data back. After that, the client gets the 500 you saw, even though in reality the request is allowed to continue server side.

As for how to bypass this limitation, if it's not necessary to get an immediate feedback like httpresponse, you can use queue trigger to do your job.

Otherwise, have a look at Durable function. You could send an http request to start an orchestrator and get a response that it starts successfully and so on. The work is being processed in orchestrator and activity function and we don't need to worry about time out(as they are non-http trigger as well)."

AjayKumarGhose
  • 4,257
  • 2
  • 4
  • 15
  • hi Ajay, thanks for your response. the request times out <23 seconds not 230 seconds. The request does not reach the external web service at all, so it must be some network/security issue. – Zain Oct 21 '21 at 11:45