Monday, March 5, 2012

eConnect 2010 / 2013 Error: There was an error writing to the pipe: The pipe is being closed

By Steve Endow

When you run an eConnect 2010 or 2013 integration, it may display this error when the code calls CreateTransactionEntity:

There was an error writing to the pipe: The pipe is being closed.

I recall seeing this a while ago in some testing, but I didn't think much of it at the time.  Well, it cropped up again, this time on both my development server and the client's workstation for a GL JE integration.

The quick fix to this is to close the integration and relaunch it, and it will then import fine.

Fortunately, there is a publicly accessible KB article available that describes the issue and the resolution.

I'm not a WCF expert, but it seems odd that this is happening since my code is re-instantiating the eConnect objects each time it is run, so it isn't as if my code is somehow hanging on to an idle instance of eConnect--at least not explicitly.  What is also odd is that I've developed dozens of integrations, but haven't had to deal with this error before.  I'm pretty sure this isn't the first customer that has left the integration open for more than 10 minutes, so it could be that the error does not occur for some integrations.

Fortunately, the fix described in the KB article is very simple, and should resolve the issue permanently. 

Locate the eConnect service config file in the eConnect service directory:

GP 2010:  C:\Program Files\Microsoft Dynamics\eConnect 11.0\Service


GP 2013:  C:\Program Files\Microsoft Dynamics\eConnect 12.0\Service

And then add the receiveTimeout="infinite" parameter to the config file, save the file, and then restart the eConnect service.

<binding name="eConnectNamedPipeConfig" closeTimeout="00:10:00" sendTimeout="00:02:00" receiveTimeout ="infinite" transferMode="Buffered" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">

That should resolve the "pipe is being closed" issue.

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter


Unknown said...

Any ideas surface if the receiveTimeout setting has already been added to the config file (it was added in June 2017)?

Steve Endow said...

Hi Chad,

I don't think I've seen this specific error after modifying the eConnect service config file and restarting the service.

Does the error occur between two separate integration runs?

My only thought at the moment is to triple check the service config file on the correct machine, verify that the receiveTimeout setting is in the correct location, etc.


Unknown said...

I believe the sendTimeout value is in play in this situation. It was revealed the client's file was 10k+ records and they said it took a long time. We had them try a file with 10 records and it processed successfully. They are going to explore breaking up the file into 2-4 files for processing. Thanks for your time and consideration.