eConnectException: There was no endpoint listening at net.pipe://localhost/Microsoft/Dynamics/GP/eConnect/EntityOperations

(0) Share

Report

Posted on by Community Member

Dynamics GP 2016 eConnect.

Running .NET client code that links to the eConnect dlls (Microsoft.Dynamics.GP.eConnect.dll and Microsoft.Dynamics.GP.eConnect.Serialization.dll). I have verified that service "eConnect for Microsoft Dynamics GP 2016 Integration Service" is running on the server. And, in fact, the code runs fine when executed on the server but it throws the exception referenced in the subject of this post when run from a client machine.

Any ideas, please?

Thanks!

*This post is locked for comments

I have the same question (0)

All responses (12)

Answers (0)

Tim Wappat 5,711 on at

Like (0)

Report

The address the client is trying to connect to is localhost, i.e. on the client when on the client.

This obviously works when running on the server as the localhost is where the service end point is, move to client and that client does not have the service, hence the error.

You need to change your .config of your application so the uri is pointing at the server.

Might be worth reading up on WCF too.

Tim.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thank you, very much. Yes, I had already noticed that and I tried modifying the App.config file of the client application by adding the following entry:

<add key="ServiceAddress" value="net.pipe://<GP server NETBIOS name or FQDN here>/Microsoft/Dynamics/GP/eConnect/EntityOperations" />

However, the client continues to receive the same exception and the exception continues to refer to 'localhost' - not to the GP server name specified in the App.config entry)

Also, just to reiterate, please notice that the client is attempting to use eConnect by simply adding a reference to the .NET library Microsoft.Dynamics.GP.eConnect.dll and NOT by adding a 'Service Reference' to the "eConnect for Microsoft Dynamics GP 2016 Integration Service"

I imagine that, behind scenes, the Microsoft.Dynamics.GP.eConnect.dll library is, in turn, using WCF to communicate with the "eConnect for Microsoft Dynamics GP 2016 Integration Service" running on the server. But I thought that the client is expected to be oblivious to that.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

OK, here is an update:

Even though I still can't get eConnect.dll to read the configuration settings from App.config, I manage to read and write the 'ServerAddress' configuration value in code using the Configuration object from eConnect.dll. And so, I set explicitly the GP server name (either NETBIOS or FQDN) in code:

"Microsoft.Dynamics.GP.eConnect.Configuration.ServiceAddress = $"net.pipe://{server}/Microsoft/Dynamics/GP/eConnect/EntityOperations"

Unfortunately, the exception still occurs (although this time, it reflects the value specified for the GP Server name):

Either

"eConnectException: There was no endpoint listening at net.pipe://<GP server NETBIOS name>/Microsoft/Dynamics/GP/eConnect/EntityOperations"

or

"eConnectException: There was no endpoint listening at net.pipe://<GP server FQDN>/Microsoft/Dynamics/GP/eConnect/EntityOperations"

However, when I run the client code on the server it works fine - whether I set the name to any of 'localhost', '<NETBIOS name>', or '<FQDN>' .

Any ideas?

Thanks.

Was this reply helpful? Yes No
Tim Wappat 5,711 on at

Like (0)

Report

Sorry I was going out the door as I gave the previous reply.

The reason I said to read up on WCF is, because although Named Pipes technically can be made to work between machines, in the WCF implementation of Named Pipes, it is for inter-process communication within the machine only.

Instead use NetTcpBinding if you want to go between machines.

Oh, and check your machine firewall settings to open up the port you choose to use.

Tim.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thank you Tim. I must be missing something here. My understanding is that here are two distinct approaches to creating a .NET client for eConnect:

1) The first approach is to link to .NET eConnect libraries by adding a reference to up to two DLLs:

- Microsoft.Dynamics.GP.eConnect.dll and

- Microsoft.Dynamics.GP.eConnect.Serialization.dll

This is the approach we are pursuing. In this case WCF is not 'visible' to the client (I.e.: Adding those references does not modify the client's app.config file, etc.). There are no visible WCF parameters that I can modify. From the perspective of the .NET client, we are simply adding a reference to a .NET library (DLL) that, in turn, communicates with an eConnect integration service - presumably by communicating with the Integration Service through the use of named pipes.

2) The second approach to writing a .NET client for eConnect involves the use of (from the documentation)... "The eConnect Integration Service [which] is a Windows service that enables you to use the eConnect business objects from a .NET application. You can use the eConnect Integration Service instead of the Microsoft.Dynamics.GP.eConnect assembly. To use the eConnect Integration Service, you use a WCF service from your application. A WCF service gives you more flexibility but configuring and using the service can become complex. "

The second approach is *not* the path we are pursuing.

I hope this makes sense and thanks again for your help. So, for the first approach, what are we missing?

Was this reply helpful? Yes No
Tim Wappat 5,711 on at

Like (1)

Report

I think we are on the same wavelength. Brevity of forum posting just makes it more drawn out than is ideal!

For anyone following this thread, this is the architecture of eConnect:

As you correctly guessed in one of the earlier posts, you can see that the .NETAssembiles go via the eConnect Integration Service, using WCF under the hood.

The quote above is basically saying that you can miss out the eConnect assembly and talk to the WCF endpoint directly (even using another programming language, for instance).

You say you are using the eConnect assembly, I get that, but it still is using WCF under the hood which is why you are getting a WCF endpoint error.

What is wrong?

Well if you are using net.pipe: as your protocol then the "eConnect Integration Service" (a windows service) needs to be installed and running on the client machine. Your .NET classes will talk to the integration service via WCF and the integration service will take the database connection passed to it to interact with the Dynamics GP database using SQL.

So if you are getting the error you are getting, I have to assume that you are not installing the eConnect integration service on the client machines, or it is not running. You can solve this by installing it, or working out why the windows service is not running and continue to connect to "localhost".

However when I work with eConnect I don't like having another "moving part" involved that can go wrong, so I don't like to have to install and keep the eConnect windows service running on all our hundreds of client machines.

Instead I change the WCF config to point at the server where the integration service is installed (doesn't have to be the DB server, but usually would be a fair choice). Then I add an additional end point, with protocol to set use tcp, as pipes won't work between machines. The integration service is no longer on localhost and needs to traverse the network, hence need to use another transport protocol.

I have to add an extra endpoint on the server service config and restart the service and change the client WCF configuration to point at the server and port I configured. Luckily I'm comfortable with WCF so this is not a big deal, others may find it easier not to mess with WCF and just configure the windows integration service on the client machines. Its balancing up skills and architecture I guess.

I hope this gives a better picture of where I was coming from and helps you get sorted!

In your case, it sounds like you just want to put the WCF config back to localhost, install the integration service on the client machine, check the database connection string you are using is specifying the server and I guess it will then work.

Tim.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

I have found it:

In my scenario, property RequireProxyService of class eConnectMethods has to be set to false when the client code is not running on the GP server

Thanks for your help!

Was this reply helpful? Yes No
Tim Wappat 5,711 on at

Like (0)

Report

Excellent news.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi, Tim. My previous post crossed paths with yours so I didn't address your last response. Thank you, so much, for taking the time to provide such detailed explanations. Truly appreciated! And yes, we were on the same page. However, it is apparent now that pipes work just fine across machines (so must be named pipes, which was my understanding) OR there is an arrow missing in the documentation diagram going directly from the eConnect .NET assemblies to the Business Objects bypassing the eConnect Integration service: The .NET client working on a machine that does not have the integration service installed!

BTW, in my .NET client Visual Studio solution there is not WCF config file anywhere. This is why I was confused before. It is not required and so there should be none.

Thank you again, this has been enlightening and I hope it can help others in this community if they ever face a similar situation.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi, I am having this same issue as normally we have GP installed on the terminal server and the database server. Going forward with our GP 2018 installation and architecture structure, we were told that GP is not needed to be installed on the database server and that it would help with our performance. But now when setting up integration, I still have the integration files on the database server like before without eConnect installed on the database server (due to not installing GP on the database server anymore). When xml files are trying to integrate into our GP system, we receive the error message stated above. I need help trying to figure out how to fix the issue with this naming pipe and the no endpoint listening problem. Please advice and thank you in advance!

Was this reply helpful? Yes No