Wednesday, September 22, 2010

eConnect 2010 Error: There was no endpoint listening at net.pipe

By Steve Endow

If you are working with eConnect 2010, you may run into the following error at some point:

There was no endpoint listening at net.pipe://localhost/Microsoft/Dynamics/GP/eConnect/EntityOperations that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

There are probably several possible causes of this error, but one of the simple causes is that the eConnect 2010 Integration Service is not running on your server.

On my GP 2010 server, it seems that the eConnect 2010 service installed with a Startup Type of Manual.  I installed it several months ago, but I don't recall changing the setting from Automatic to Manual.

In any event, if you notice that the "eConnect for Microsoft dynamics GP 2010 Integration Service" is not running, that would likely explain the "no endpoint listening" error that you are receiving.

Just start the eConnect 2010 Integration Service up, and then try your integration again.

If the Integration Service is running on your server, then you can check the Configuration.ServiceAddress value that you are using in your integration and confirm that you are using a valid URL.

Other than that, I'm going to be looking into the details of the protocols and ports required for the eConnect 2010 / WCF communication.  Since I ran into internal firewall issues with eConnect 10 and DTC, I want to be prepared for similar situations with eConnect 2010.

I'm in the process of migrating some GP 9 eConnect integrations to GP 2010, so I'll probably be learning more, and posting more, about eConnect 2010 in the near future.

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



12 comments:

Seth said...

We have an application that calls eConnect from within a web service to create GL transactions. Apparently, we're going to need to maintain two versions of the web service if we're to maintain compatibility with GP10 and GP2010. Any insights?
Seth

Steve Endow said...

Hi Seth,

If you are going to be running GP 10 and GP 2010 simultaneously, that is a bit unusual, but could probably be done without too much trouble.

If you have the ability to separate your source data for GP 10 vs. GP 2010, then you could just run both versions of the integration separately, which should be relatively simple and should work fine.

Or...I've never tried it, but I suppose that you could have a single integration that supports both GP 10 and GP 2010. You would just need to have some logic in the integration to determine the destination, and then call the appropriate import routine. The only minor hassle is that you'll have to maintain two versions of a few different routines in your code, making it slightly more complex, and potentially requiring a little more maintenance, depending on how your integration is designed.

If you are only upgrading from GP 10 to GP 2010, then you can just create a new version of the integration that supports GP 2010, and then test it in your GP 2010 environment. Once you are ready to go live, you can switch over to the new integration.

Does that answer your question?

Thanks,

Steve

Brian said...

I am also attempting to write a .NET application that can work dynamically with the appropriate version of eConnect depending on the clients version of GP. Having difficulty referencing the GP2010 service however. Getting the following error when calling eConnectClient() constructor...

Could not find default endpoint element that references contract 'eConnectService.eConnect' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.

We're using the following url for the service...

net.pipe://localhost/Microsoft/Dynamics/GP/eConnect/

Both eConnect10 & eConnect2010 was installed locally and was given the remote address of the machine hosting the GP database. The machine we are developing on simply has a GP clients. The machine with the GP database also has the eConnect clients installed. Checking our services on either machines shows that the Integration Services are running.

Any ideas what the problem is? Also, looking for clarification as to why we needed to install eConnect2010 locally before Visual Studio would let us reference it, even when providing a URL for the remote service on the GP database machine.

Steve Endow said...

Hi Brian,

I haven't yet used eConnect2010 as a service, so I have not used the eConnectClient constructor.

I have only used the eConnectMethods class directly through the .NET assembly. This approach has been very simple, easy to retrofit for GP 9 and GP 10 integrations, and has worked for me, so I haven't bothered to try the WCF approach.

My guess as to the reason that you are having to install eConnect 2010 on your dev machine for Visual Studio to have a reference is because the WCF net.pipe protocol / binding will only work locally, and will not work between two machines.

I haven't tried this, but one option would be to try the HTTP Metadata Generation address, which might allow you to add a remote reference in Visual Studio. That URL would be:

http://hostname/Microsoft/Dynamics/GP/eConnect/mex

Let me know if that works.

Thanks,

Steve

Junaid Ikram said...

WCF integration services are installed on my Server machine.

I have excess this WCF service on my client by using Add Service Refrence..

EConnectService.eConnectClient EConnectClient = new EConnectService.eConnectClient("eConnectServiceEndpoint1")

But When I use the Method

EConnectClient.CreateTransactionEntity(conGP, xmlDoc.OuterXml)

Exception Arises..

"There was no endpoint listening at net.pipe://srv01/Microsoft/Dynamics/GP/eConnect/EntityOperations that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details."

Please Help

Steve Endow said...

Hi Junaid,

Did you try installing eConnect 2010 on the workstation where the integration is being run?

Thanks,

Steve

Manish Jain said...

Steve, I am also running this issue. I am using GP 2010 and econnect, when everything is one box works great but now we have GP+ SQL on 1 server and Econnect service (just installed) on another server.. we are getting following errors, I checked service is up and running but not sure whats this error about? I am not sure if we need to modify the service.config file to point to sql server but that we are specifying in connection string so we shouldnt have to.. any help would be great..

Microsoft.Dynamics.GP.eConnect.eConnectException: There was no endpoint listening at net.pipe://localhost/Microsoft/Dynamics/GP/eConnect/EntityOperations that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. --->
System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at net.pipe://localhost/Microsoft/Dynamics/GP/eConnect/EntityOperations that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. ---> System.ServiceModel.AddressAccessDeniedException: The pipe name could not be obtained for net.pipe://localhost/Microsoft/Dynamics/GP/eConnect/EntityOperations. ---> System.IO.PipeException: The pipe name could not be obtained for the pipe URI: Access is denied. (5, 0x5)
--- End of inner exception stack trace ---
at System.ServiceModel.Channels.PipeSharedMemory.Open(String sharedMemoryName, Uri pipeUri)
at System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName(Uri uri, IPipeTransportFactorySettings transportFactorySettings)
--- End of inner exception stack trace ---

Steve Endow said...

Hi Manish,

You must have the eConnect service installed locally on any machine that will be running an eConnect application.

If you are going to run the integration on the SQL Server, install eConnect on that server. If you are going to run the integration on a terminal server, install eConnect on that server, etc.

Thanks,

Steve

Pranav Kulkarni said...

Steve,

Thank for this blog. I was getting the same error and was able to resolve it by installing eConnect locally on the remote PC. During the eConnect install on remote PC, it asks to provide service account which is fine. Then on the next screen it wants to add that service account to SQL server. I checked the box that said "Do not add service user to SQL server". Was that a mistake? Now I am getting errors like "Stored procedure" does not exist when I try to integrate. I thought eConnect is jsut a runtime and as long as I am passing the connection string with a user that has access to SQL GP Companies, it should work. Then why add an additional user to GP DB?

I will appreciate your insights! Thanks!

Steve Endow said...

Hi Pranav,

I recommend reading the eConnect Installation and Administration Guide. I recall that it does a good job of walking you through the installation and configuration process.

http://www.microsoft.com/en-us/download/details.aspx?id=36217

eConnect must be installed locally on each machine where an integration will run. Windows / Integrated Authentication is used to communicate with the local eConnect service, and then the eConnect service Log On As user account is used to actually access SQL Server. So you do not need to pass username/password or any credentials to eConnect as part of your .NET integration.

The domain user account that is configured in the eConnect Windows Service account must have a corresponding SQL Server login, and must be a user in the DYNAMICS database and all company databases, and must also be a member of the DYNGRP database role in ALL of the GP databases.

Hope that helps.

Steve

Jesus Otero said...

I went into this issue, the inner exception show error: "the pipe name could not be obtained for the pipe URI. Access is denied". It was caused because I was using impersonation="true" in my web app. In case you run into the same issue you can bypass it by using the following method.

private void RunOutsideImpersonation(Action action)
{
System.Security.Principal.WindowsImpersonationContext imcontext = null;
if (!System.Security.Principal.WindowsIdentity.GetCurrent().IsSystem)
{
imcontext = System.Security.Principal.WindowsIdentity.Impersonate(System.IntPtr.Zero);
}

try
{
action();
}
finally
{
// Resume impersonation
if (imcontext != null)
{
imcontext.Undo();
imcontext = null;
}
}
}

Any eConnect call should be done through this method like this:

....
string adjNumber = "";
RunOutsideImpersonation(() =>
{
adjNumber = nextGPDoc.GetNextIVNumber(Microsoft.Dynamics.GP.eConnect.IncrementDecrement.Increment, Microsoft.Dynamics.GP.eConnect.IVDocType.IVAdjustment, eConnectConStr);
});
...
or
...
RunOutsideImpersonation(() =>
{
eConnectMethods eConCall = new eConnectMethods();
eConCall.CreateEntity(eConnectConStr, xml);
});

Hope it helps.

Sergio Flores said...

Thank you, this helped!