I want to have a schedule running an Invantive Cloud App made with assistance from Invantive to synchronize Visma.net data to Azure SQL. Firstly, I have a curl that works, but I do not have a server to schedule it on. Thus I was recommended Azure Automation and runbooks, which is a cloud PowerShell in essence.
This works fine for small data transfers, but when I do the larger tables, the script runs for about 15 minutes and then stops with the following error message:
Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a receive. At line:4 char:8 + $res = Invoke-WebRequest -Uri "https://app-online.cloud/apps/4e6378a4 … + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
Alternatively, the Invantive App Online server can have closed the connection. Maximum runtime for a request on Invantive App Online and Invantive Bridge Online is 6 hours, but something may have a caused an earlier end.
It is unclear why a HTTP 202 is needed. A HTTP 202 according to the specification is for asynchronous requests, whereas execution here takes place synchronously.
Best is to ask the Azure-people to extend the topic here.
The abortion of the job after 258 seconds (which is close to 256 seconds) might relate to another topic, in which after exactly 256 the download is finished. It seems related to an internal time-out of Invantive Cloud when no data (no single row) at all is returned during 256 seconds, which is happening here since another identical request is still running.
Please include the monitor request value in the blue bar in an answer. Using that information it can be looked up.
With this information we will try to fine-tune the behaviour.
Please note that the job does not start at all, since an itgentmm022 message is displayed:
itgentmm022
Another identical active request is currently taking up the single available slot.
Wait till the other request finishes.
Best is to wait for the other request to finish or try to use “Abort Request” on it. In case another user runs the request, it is not possible to abort it for a normal user.
So best solution is to re-run the request and run it alone for now. In the App Online Monitoring a user can see whether he has it already running.