"The underlying connection was closed" ...the saga of an unexpected error

Shen-Tat

Hi Community,

I have a server deployed workflow that uses the older SharePoint List Input tool to pull filter data into the flow from a business-maintained list. MicroSoft's help pages list the above error as potentially a credentialling or potentially a communication problem on SharePoint's server side--while this error appears nowhere that I can find in Alteryx help pages.

Since the new SharePoint Input tool requires AMP Engine be turned on, which is currently not allowed by my org with Server, I cannot simply swap out the old for new, in order to test whether this component is the culprit for my scheduled runs failing. The flow was working like clockwork until Dec 6th, when it started failing on Server. I can still run it fine from Developer, so tracking down what this error is getting difficult. I cannot prove it's this and I cannot prove it's not. So, I don't know where to turn to diagnose nor fix the issue.

The tool id's listed in the error and returned to me by Server (tool numbers that do not match any of the tools in either my parent, nor my macro flows) are not pointing me to the failure either.

I utilize in the flow a Command Tool to copy zip files into a temp storage folder (so server can access the files) and a call to instantiate a Power Shell script to unzip those prior to consuming the file contents. So, the failure may be on any of these aspects.

Has anyone run into this error and if so, do you have any advice on tracking down the failure?

apathetichell

Reading just the error message - my hunch would be that this relates to a network or DB connection between the Server and another device (either a worker node, a sharedrive, a DB or Sharepoint)....  This seems like a timeout. I think for next steps I'd be curious if you could limit the amount of data passing through your workflow and see if that effects the error. The hypothesis is that a shorter run time might reduce the error.

I don't use AMP so I support your company's decision. I do use Python ---> which I expect your company would not allow you to use. One note -> I would manage the Python Venvs on the Server/Workers and execute via CLI if possible to make sure that the Python environments matched what I needed. I'd look into connecting to Sharepoint via Python. I'm not an Azure/Sharepoint guy so I'd have to dig into the Python packages which I don't have the time for.