This particular client uses the eConnect incoming queue to integrate journals and payables invoices into Dynamics GP from a housing management system.
After installing eConnect and configuring the incoming queue I set about doing a test to ensure it was working.
Unfortunately, it didn’t.
I had an issue to deal with for a client recently where messages submitted to eConnect were no longer appearing in Microsoft Dynamics GP. I did the usual things of checking the Windows Event Log and ensuring that the two eConnect services were running.
One item I tried was to submit a test message to eConnect which worked fine; so it worked for the perfectimage user I was logged in as, but no-one else. I eventually found the answer in the Properties of the econnect_incoming queue:
The permissions for the perfectimage account (Full) were still configured correctly, but, somehow, the Send Message permission on Everyone had been removed. Once this setting had been added back, people were able to submit messages to the queue without further problem.
I was recently creating an integration for a client to load some Purchase Orders into Microsoft Dynamics GP using Integration Manager. I added the source and destination adapters and then did the destination mapping. However, when I tried to run the integration I got the following error message:
DOC 1 ERROR: 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 InnterException, if present, for more details.
While I was working on the series of posts for how to install the Web Services for Microsoft Dynamics GP, I encountered a couple of problems which I thought it might be worth covering in this and the next post.
The first was to do with the eConnect Integration Service which is installed as part of the install of Web Services. The basic problem was that the service was not running;
At the end of December, Developing Microsoft Dynamics GP Business Applications, written by Leslie Vail and published by Packt Publishing was released.
I got a copy of the book in order to do a review and have decided to break the review down into multiple parts. The reason for this is that the book includes some practical examples which I have decided to do and then include the results of this in the review; after all if it is a book on developing how can you accurately review the book if you don’t use what you learn to build something?
The book is aimed at developers new to working with Microsoft Dynamics GP, so bear in mind that I am not a developer when reading my reviews. Quick synopsis of my background: I started my career as a trainee developer and moved through a variety of roles such as developer and support analyst before moving to my current position as consultant and project manager.
I oversee development teams working on additions or amendments to Microsoft Dynamics GP as well as personally undertaking some modifications using Report Writer or Modifier with VBA. So despite not being a developer, I am used to working with them and did, once upon a time, be one myself.
The first chapter of the book covers the Microsoft Dynamics GP Architecture from a high level perspective.
It covers the history of the GP interface from it’s origins with Great Plains Software, an overview of Dexterity and the development environment. There is a detailed explanation of the launch file (Dynamics.set), which included a couple of points of which I wasn’t aware, and the configuration/preferences file (Dex.ini).
The explanation of the Dex.ini file included the ExportOneLineBody switch which I didn’t know about, but for which I have an immediate use.
Leslie then goes on to explain about the structure of the tables in the SQL Database which always strikes newcomers as arcane and overly complex. Leslie explains this well with plenty of detail on both the structure, including both the physical and technical names, and how transactions move between tables as their state changes.
Chapter 1 wraps up with a detailed explanation of the UI covering how forms are constructed, how the scrolling windows work and the common buttons used on forms, scrolling windows and individual buttons.
The second chapter of the book focuses on the fundamentals of integrating applications with Microsoft Dynamics GP.
Connector for Microsoft Dynamics is a tool available from Microsoft which allows Microsoft Dynamics CRM to be integrated with one of the three Microsoft Dynamics ERP products; AX, GP and NAV.
Being a Microsoft Dynamics GP focused blog, it is the integration to Microsoft Dynamics GP I’m going to take a look at over the next couple of weeks or so depending on how quickly I get the posts written and published.
Connector for Microsoft Dynamics provides a two way integration between Microsoft Dynamics CRM and Microsoft Dynamics GP with the below diagram showing the entities which can be integrated from one system to the other;
On the Developing for Microsoft Dynamics GP blog, David Musgrave has posted an announcement that Microsoft Dynamics GP Service Pack 3 is now available.
As always with service packs to Microsoft Dynamics GP there are a multitude of downloads covering all the different related products to Dynamics GP itself such as Integration Manager and eConnect.
The morning opened with a feeling of déjà vu. A client testing Microsoft Dynamics GP reported that transactions they were posting in an external system were not appearing in GP.
After checking out the other issues I’ve seen recently (Domain Trust issues, Windows Updates restarting MSMQ and timeouts) without luck I expanded the investigation. Continue reading → eConnect Messages Not Posting To GL
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 (Continue reading → eConnect Error: Unrecognized error 232 (0xe8))