eConnect Error: Unrecognized error 232 (0xe8)

A couple of weeks ago, a client was testing Microsoft Dynamics GP 2010 R2 and reported that some of their postings from an external system were not arriving in GP (these postings are transferred using eConnect).

When I installed eConnect I enabled Journalling on the econnect_incoming queue so we would have a record of messages which had been submitted. After receiving the error I went to make sure the messages had reached the GP server (Start menu » Control Panel » Administrative Tools » Computer Management » Services and Applications » Message Queuing » Private Queues » econnect_incoming » Journal Messages);

Postings to Payables Management and the General Ledger were showing in the list of journal messages so the next step was to check the Event Viewer for eConnect (Start menu » Control Panel » Administrative Tools » Computer Management » System Tools » Event Viewer » Applications and Services Logs » eConnect);

There were three errors showing up for eConnect all with the same error description;

The full error description;

eConnect Incoming Service Version=11.0.0.0
Message Label:PaymentPostingBatch844
mscorlib
System.ServiceModel.CommunicationException: There was an error writing to the pipe: Unrecognized error 232 (0xe8). ---> System.IO.IOException: The write operation failed, see inner exception. ---> System.ServiceModel.CommunicationException: There was an error writing to the pipe: Unrecognized error 232 (0xe8). ---> System.IO.PipeException: There was an error writing to the pipe: Unrecognized error 232 (0xe8).
   at System.ServiceModel.Channels.PipeConnection.StartSyncWrite(Byte[] buffer, Int32 offset, Int32 size, Object& holder)
   at System.ServiceModel.Channels.PipeConnection.WriteHelper(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout, Object& holder)
   --- End of inner exception stack trace ---
   at System.ServiceModel.Channels.PipeConnection.WriteHelper(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout, Object& holder)
   at System.ServiceModel.Channels.PipeConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   at System.ServiceModel.Channels.BufferedConnection.WriteNow(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout, BufferManager bufferManager)
   at System.ServiceModel.Channels.BufferedConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   at System.ServiceModel.Channels.ConnectionStream.Write(Byte[] buffer, Int32 offset, Int32 count)
   at System.Net.Security.NegotiateStream.StartWriting(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.NegotiateStream.ProcessWrite(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   --- End of inner exception stack trace ---
   at System.Net.Security.NegotiateStream.ProcessWrite(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.NegotiateStream.Write(Byte[] buffer, Int32 offset, Int32 count)
   at System.ServiceModel.Channels.StreamConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   --- End of inner exception stack trace ---

Server stack trace: 
   at System.ServiceModel.Channels.StreamConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   at System.ServiceModel.Channels.StreamConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout, BufferManager bufferManager)
   at System.ServiceModel.Channels.FramingDuplexSessionChannel.OnSend(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.OutputChannel.Send(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Microsoft.Dynamics.GP.eConnect.IServiceInterface.CreateEntity(String connectionString, String xml)
   at Microsoft.Dynamics.GP.eConnect.ServiceProxy.CreateEntity(String connectionString, String xml)
   at Microsoft.Dynamics.GP.eConnect.eConnectMethods.EntityImportImplementation(String connectionString, String sXML, Boolean isTransaction)
   at Microsoft.Dynamics.GP.eConnect.eConnectMethods.CreateEntity(String connectionString, String sXML)
   at Microsoft.Dynamics.GP.eConnect.Incoming.eConnect_Incoming.MyReceiveCompleted(Object source, ReceiveCompletedEventArgs asyncResult)

I did some investigation and couldn’t really find anything relevant to Microsoft Dynamics GP and eConnect but some suggestions in general that this may be a timeout issue. I hunted down the configuration xml (C:\Program Files\Microsoft Dynamics\eConnect 11.0\Service\Microsoft.Dynamics.GP.eConnect.Service.exe.config) and looked for the following section;

<binding name="eConnectNamedPipeConfig" closeTimeout="00:10:00" 
   sendTimeout="00:02:00" transferMode="Buffered" hostNameComparisonMode="StrongWildcard" 
   maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
   <readerQuotas maxDepth="60" maxStringContentLength="2147483647"
      maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
   <security mode="Transport">
      <transport protectionLevel="EncryptAndSign" />
   </security>
</binding>

I amended the two timeout values (highlighted below) and made them both 20 minutes;

<binding name="eConnectNamedPipeConfig" closeTimeout="00:20:00"
   sendTimeout="00:20:00" transferMode="Buffered" hostNameComparisonMode="StrongWildcard" 
   maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
   <readerQuotas maxDepth="60" maxStringContentLength="2147483647"
      maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
   <security mode="Transport">
      <transport protectionLevel="EncryptAndSign" />
   </security>
</binding>

Unfortunately, the above setting was still resulting in an intermittent error. Even more unfortunately, my part in the investigation ended at this point as I left the company for a new opportunity and this blog post remained incomplete.

My former colleague, Andrew Cooper, took over the investigation and has kindly emailed the solution. He found the answer on the PartnerSource Knowledge Base, by searching for a slightly different but related error message, in KB article 2539263 (available to everyone on the Microsoft Help And Support site) and has kindly passed the answer onto me so I can complete this blog post;

<binding name="eConnectNamedPipeConfig" closeTimeout="00:20:00"
   sendTimeout="00:20:00" receiveTimeout="infinite" transferMode="Buffered" hostNameComparisonMode="StrongWildcard" 
   maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
   <readerQuotas maxDepth="60" maxStringContentLength="2147483647"
      maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
   <security mode="Transport">
      <transport protectionLevel="EncryptAndSign" />
   </security>
</binding>

The issue is that the WCF service-oriented application can remain active for only ten minutes without activity after which it is dropped. The above change, adding receiveTimeout=”infinite”, keeps it active and prevents the error we were seeing.