I created a .NET 4.5 web application in VB. This app generates sales orders in GP 2010 with eConnect 11.0. I accomplished this by adding references (NOT service references) to the API DLLs. The programming works. I have successfully generated sales orders from my local machine and from a standalone web server.
However, when I deploy the same application to a web farm made up of 2 ARR servers, 2 SQL servers, and 2 web servers, the application fails to generate a sales order. In this configuration the web application content is located in a share. The exact error messages I receive are:
The pipe name could not be obtained for net.pipe://localhost/Microsoft/Dynamics/GP/eConnect/EntityOperations.
The pipe name could not be obtained for the pipe URI: Access is denied. (5, 0x5)
I have done an exboritant amount of research on this. I have installed eConnect on the web servers and the SQL cluster servers. I have verified the service is running on all servers. I have verified the service is set to automatically start. I believe I have pinpointed the issue, but I just don't know how to resolve.
Apparently, netNamedPipeBinding is for single machine use only. Because this is a web farm, it won't work. I've confirmed this by moving the content directly onto each web server instead of the share. When I do that, it works. Once I move the content back to the share, it fails again. I don't know much about these binding/endpoint options, so I don't know how or if I can reconfigure the eConnect service to accept a different method such as netTcpBinding. Thoughts?
*This post is locked for comments
Very nice job JJ.
If I can find the time, I'll give this a try on a single machine environment to replicate it and get familiar with it as an option.
Thanks for following up to post your success and the instructions for making the change.
This is an external web applications so it is accessed from the web and then comes into the same domain.
Thanks for update. Are users are going to enter data from same domains or different domains?
Thanks
Sandip
<system.serviceModel> <diagnostics wmiProviderEnabled="true"> <messageLogging logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" /> </diagnostics> <bindings> <netTcpBinding> <!--The following Buffer Sizes are required in order to handle large XML messages in eConnect--> <binding name="eConnectTcpConfig" 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> </netTcpBinding> </bindings> <services> <service behaviorConfiguration="eConnectServiceBehavior" name="Microsoft.Dynamics.GP.eConnect.Service"> <endpoint address="EntityOperations" binding="netTcpBinding" bindingConfiguration="eConnectTcpConfig" name="eConnectServiceEndpoint" contract="Microsoft.Dynamics.GP.eConnect.IEconnect"> <identity> <dns value="localhost" /> </identity> </endpoint> <host> <baseAddresses> <!--Net Pipe (NamePipes) creates an IPC call to this eConnect Service--> <add baseAddress="net.tcp://localhost/Microsoft/Dynamics/GP/eConnect/" /> </baseAddresses> </host> </service> </services> <behaviors> <serviceBehaviors> <behavior name="eConnectServiceBehavior"> <!--Leaves this to true in order to receive Exeption information in eConnect--> <serviceDebug includeExceptionDetailInFaults="true" /> <!--This settings turns on Metadata Generation. Metadata allows for consumers to add service references in Visual Studio--> <serviceMetadata httpGetEnabled="true" httpGetUrl="http://localhost/Microsoft/Dynamics/GP/eConnect/mex"/> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel>
SUCCESS! I finally got this to work the way I wanted. As I suspected, I needed to find a way to use a different binding than netNamedPipe. What is working for me is netTcp. Here are the details for anyone else that may run into this issue.
That's it. That was all I need to do to make this work on a web farm. No need to create a separate web service. :-)
I will still stick to my suggestion. Create webService and use it to any platform. Local or cross !!
Thanks
sandip
Hi JJ,
I was unable to get a share working in my environment. I received various generic IIS errors when I pointed to a share, and couldn't figure out how to get it working.
If the solution works well with the content local, I would compromise for now and just setup a batch file to update the files on both web servers when you need to do a deployment.
If you really, really need the content to be shared, I'm open to doing a GoToMeeting with you and your boss to see if he can replicate the shared content setup in my development environment. If so, I can then try and figure out the problem. But given the effort involved, I think local content is the path of least resistance.
No worries on using "he". It happens all the time in cyberspace from going by my nickname, J.J.
Thanks again Steve. Unfortunately this is something I've been trying to troubleshoot on the side which doesn't give me much time. My boss took care of setting up the share and it's settings in IIS, so I can't give you any guidance there. Sorry.
I only suspect a problem with cross-machine access for the pipe because it only breaks when I move the content from local to the share. So I'm thinking it is trying to execute from the SQL Server that houses the share. That is where the eConnect DLL that is part of the Bin folder of the application then ends up. So my thought is that when the application calls the eConnect DLL from the Bin folder on the share it is running on the SQL Server opposed to the web server. I hope that makes sense.
Hi JJ,
(Sorry for saying "He" in my last post!)
Unfortunately, I am not an IIS expert, so I'm unable to get my web service to work when pointing to a UNC path. I get various IIS HTTP errors. But when I move my content locally, it works fine.
I'm going to have to read up on how to properly configure IIS with remote content on a share. If you have any web sites handy with guides on properly configuring IIS with a remote content share, I'm open to reviewing them.
Based on your domain setup, I suppose it could be a security issue between your web servers and the SQL Server, but when I see anything about the eConnect "pipe", I typically think of a local issue on the machine running the eConnect code.
I changed the app pool identity from ApplicationPoolIdentity to the same user that the eConnect service runs as. This user is in the Administrators group on both the web servers. I should probably mention that these web servers our outside of our domain because they are Internet facing while the network share and SQL cluster are in the domain. I used the following article to help me install the eConnect service for this architecture - support.microsoft.com/.../2534520. The same user is setup on all machines (econnsrv) and I use .\econnsrv so that I can use these credentials across machines. Again, this system works for a single web server architecture (or when the content is kept local on each web farm server). While I troubleshoot this issue, I'm running my application on a different web server, also outside the domain, that talks to a SQL server inside as well as our GP server. Let me know if I can provide any more detail that will help. Thanks.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 291,134 Super User 2024 Season 2
Martin Dráb 229,928 Most Valuable Professional
nmaenpaa 101,156