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 Professional. He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.
http://www.precipioservices.com
4 comments:
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
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
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.
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
Post a Comment