Dynamics Database. Company Information.

So, first, I have to say that Steve has been putting me to shame with his prolific blog posts the past few weeks. Believe it or not, I am alive and working. Busy but not crazy, just enjoying the changing of the seasons here. We have had some lovely fall weather the past week, a nice little break before the reality of winter sets in.

In an attempt to challenge Steve's dominance of the blog lately, I thought I would share a reminder of sorts as it relates to the Dynamics database. I know I am guilty of sometimes minimizing the significance of the Dynamics database, particularly when it comes to what version of the database is restored if there is a system failure. Of course, I remind the client that if security settings, yadda, yadda, yadda have changed since the backup then they will lose those changes. But, generally, security settings are not changed all that often and the difference between restoring a Dynamics database from this week versus last week is often minimal if a difference exists at all.

But today I received a reminder of the importance of the Dynamics database when it comes to company setup. Yes, I said company setup. Of course, the vast majority of company setup information is stored in each company's database. But there are a few critical pieces that are actually stored in the Dynamics database. So, if your restore point is prior to when those setup pieces were completed for a company, then you will indeed have issues with that company.

• Company Master (Setup>>Company>>Company): If you restore the the Dynamics database to a point prior to when the company was actually created, it will not be part of the Company Master table and therefore will not be available for selection when logging in or defining security. The best route here (in my humble opinion) is to run through GP utilities to create the company, and then just restore a backup of the company database over the new empty company created. This ensures that all system tables are properly populated with the company information. However, this approach does not mean that your original company settings stored in the Dynamics database would be recovered. You would still need to return to Setup>>Company>Company to complete the setup, and don't forget the critical Options window. The company setup options can have significant impact on how the company functions with regards to taxes, distributions, and other items.
• Multicurrency Access (Setup>>System>>Multicurrency Acccess): This stores the company access to specific currencies and exchange tables. You might have all of your multicurrency setup completed, but if this piece does not exist in the Dynamics database you will run in to multiple errors trying to use multicurrency. As this is a pretty simple access window, setting it up manually if the data is missing is usually the simplest solution.
• Intercompany (Setup>>System>>Intercompany): If used, this defines the intercompany relationships for Dynamics GP. Again, this is a pretty simple setup window, so the quickest solution is to re-enter the configuration manually if the data is missing for the company.
• Security (Setup>>System>>Security Roles, Security Tasks, Alt/Mod Forms and Reports, User Security): As I mention above, any security defined for the new company will be missing, if you restore the Dynamics database to a point prior to the set up being completed.

Well, that's my list of items that are sometimes forgotten when restoring a Dynamics database to a point earlier than the creation/setup of a new company. Of course, let me know if I missed anything or if you have any tips/tricks to share.

Dynamics GP Visual Studio Tools AddIns Won't Load

I have been working with a client over the last week to troubleshoot a problem where VS Tools AddIn DLLs will not load on their Dynamics GP 9 server.

Normally the "installation" of a Dynamics GP add in is very simple--just copy the DLL to the AddIns directory, then launch GP, and it works.  It's a wonderfully easy and reliable deployment process.

However, with Dynamics GP 9, there are two small caveats.  First, the Visual Studio Tools runtime must be installed.  Second, the AddIn directly does not exist by default, so it must be created.  Pretty simple tasks.

The client dutifully installed the VS Tools runtime, then created the AddIns sub-directory in his GP application directory.  He then installed the third party product, which copied three DLLs to the AddIns directory.

But when he launched GP, the AddIn didn't load.

He then tried uninstalling the add in, uninstalling VS Tools Runtime, and then reinstalling both.  Nada.

Thinking that maybe there was a problem with the third party add in, we tried the sample Freight Estimator add in.  But even that wouldn't load.

We then checked permissions, but he was logged in as a local Administrator on the Server 2003 machine, and he was using the sa login for GP.  We even checked directory permissions on the Dynamics GP application directory and the AddIns directory, and opened up permissions on both of those to see if that helped.  Still wouldn't work.

We then checked the path of the icons used to launch GP to verify that it was the same directory where the AddIns were installed.  All looked good.


Having exhausted all of the standard troubleshooting steps, we submitted a support case.  The support engineer had us verify all of the same tests to make sure we didn't miss anything.  He then sent us a simple test add in DLL that would display a message box as soon as it loaded, but even that didn't work.

The client finally had a streaming session with the support engineer who eventually used the Process Monitor tool to trace the behind the scenes GP activity.  In the 137,000 records that scrolled by, the engineer eventually found a strange error.

Dynamics GP was getting a path not found error when trying to read and write to the AddIns folder.  What was strange was that the path that was listed in the Process Monitor log was \\remoteserver\data\Apps\GP9\Dictionaries\AddIns.

The very sharp engineer then took a look at the client's Dynamics.set file.  Everything looked normal, except for one line.  The Dynamics.dic file path was set to the same network share as the Reports.dic and Forms.dic.  For some reason, the client's IT staff had made the Dynamics.dic a shared dictionary.

Putting the two together, he noticed that Dynamics GP was looking for an AddIns directory in the same location as the shared Dynamics.dic file.  He, and I, thought (assumed?) that GP looked for the AddIns subdirectory in the same location as the Dynamics.exe and Dynamics.set, but apparently this is not the case.  It seems that GP expects the AddIns subdirectory to be in the same directory as the Dynamics.dic file.  Normally, the Dynamics dictionary is located in the local GP application directory, and there is no reason to share it, so that statement is usually true--but only by coincidence.

Having deduced this much, they modified the Dynamics.set file to point to the local Dynamics.dic, and viola, the AddIns suddenly started working.

Kudos to the Dynamics GP developer tools support team for tracking this one down!

eConnect 2010 Service Pack 1 Released!

If you haven't heard yet, Dynamics GP 2010 Service Pack 1 was just released.  Make sure to read all that fun fine print before you dive in, as always.


https://mbs.microsoft.com/customersource/downloads/servicepacks/mdgp2010_patchreleases.htm


But of slightly more interest to me at the moment is the news that eConnect 2010 Service Pack 1 was also just released.

https://mbs.microsoft.com/customersource/downloads/servicepacks/MDGP2010_eConnectservicepackshotfixes

There are separate msp files for x86 and x64.

The fix list hasn't been published as of this post, but I'll likely be applying it to my GP 2010 development servers soon.

Partial Explanation of eConnect 2010 "Distributed Transaction" Warnings

In my last post, I discussed an issue where my Windows Event Log filled up with thousands of eConnect 2010 warning messages saying "Distributed transaction was used."

Many thanks to guru Louis for responding to the post and giving me some great info explaining what the eConnect 2010 "Distributed Transaction was used" warning meant and why it might be occurring.

First, just a reminder that eConnect 2010 is working great, and my data was importing into GP 2010 just fine--I'm only receiving warnings, not errors, so they are not interfering with my integration.  I just happened to notice the hundreds of warnings because my Event Log filled up.

Louis explained that for performance reasons, distributed transactions are not used or enabled by default with eConnect 2010, so what I am seeing is eConnect 2010 issuing a warning to let me know that my import is incurring the extra overhead of a distributed transaction.  He then offered some pointers to track down why my import was invoking distributed transactions.

In the case of my customer import, I wasn't intentionally doing anything related to a distributed transaction, and honestly, before today I didn't know enough about them to know why or when they might be used.  I checked my connection string to confirm that it wasn't changing during my import, and I confirmed that I hadn't enabled any settings to turn them on.

I then went ahead and upgraded the eConnect 9 SOP invoice and cash receipt imports that would accompany the customer import.  I was afraid they would have the same problem, but to my surprise, neither wrote a single entry to the eConnect event log.  They worked perfectly.  Hmmm.

So it was only my customer import that issued the warnings, which seemed really strange.  The customer record is quite simple, so I couldn't imagine what would require a transaction.

And then I remembered something.  As part of my customer import, I am importing e-mail addresses.  And as all good students of GP and eConnect know, there is no handy e-mail address field on the customer window.  It's tucked back in the Internet Information window in GP, and in the taCreateInternetAddresses and CMPInternetAddressType in eConnect.  So...what if sending these with the customer record were somehow causing eConnect to  invoke a distributed transaction?

So I commented out the code that adds the internet address type to my customer XML, and re-ran my integration.  Viola!  No entries in my eConnect event log!  Hmmm, so for some reason the presence of the customer internet addresses is triggering a distributed transaction on one of my servers. 

This is a great find, but as the title says, it's only a partial explanation.  This problem only occurs on my 32-bit server, and doesn't occur on my 64-bit server or the client's 64-bit server.  So my guess at this point is that it might be a configuration issue with my 32-bit machine, or a quirk in the 32-bit version of eConnect 2010.

Fortunately it isn't a show stopper, just a head scratcher, so it won't interfere with my client's GP 2010 upgrade schedule. And in the process, I learned alot more about eConnect 2010 alot faster than I would have if everything worked perfectly.

From that learning, I have a few more ideas for eConnect 2010 posts on deck...

eConnect 2010 Fills Event Log with Warning "Distributed Transaction was used"

After converting a Dynamics GP eConnect 9 integration to eConnect 2010, I was doing some testing, and everything looked fine.  Customers were being created in GP 2010, and everything was working smoothly. However, after several rounds of testing, I received an error:

The event log file is full

It took me a few seconds to understand what this meant--was this referring to the Windows Event Log?  This was a bit puzzling, since my integration isn't writing to the Event Log directly.  I opened the Event Viewer and poked around, but didn't see much.  But when I then selected the eConnect event log, I saw hundreds of Warning messages that had filled the log to it's default capacity of 512K (and overwrite events older than 7 days).

All of these eConnect warnings had no Event ID, and all had a Description that starts with this annoying message:

The description for Event ID ( 0 ) in Source ( Microsoft.Dynamics.GP.eConnect ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. 

Finally, half way down the Description, this information was provided:


The following information is part of the event: Distributed Transaction was used

This could be caused by new connection strings used within each xml document, but reusing the base transaction scope.

Configuration Setting 'ReuseBaseTransaction' is by default FALSE. Remove this configuration setting, or set it to FALSE if this was not the expected behavior.


Uhhhh, okay.  I am not doing anything special regarding "Distributed Transactions", so this didn't mean much to me, and after reviewing the eConnect 2010 Installation guide and Developer's guide, I couldn't find any reference to Distributed Transactions or the ReuseBaseTransaction parameter.

I even check the Microsoft.Dynamics.GP.eConnect.Service.exe.config, and ReuseBaseTransaction is not a default parameter, so I'm not yet sure where that might be located.

After doing more testing, it appears that for every customer record that I submit to the eConnect 2010 CreateEntity method, over 300 of these warning messages are recorded in the eConnect event log.  Pretty haywire.  To keep the Warnings from causing problems with the integration, I increased the size of the eConnect log and set it to overwrite events as needed.

At 10pm, lacking any other bright ideas, I compose the text for a support case and forward it to the GP partner that I'm working with for submission.  After a few e-mail exchanges, he asks if I've tried the integration on another server.  Brilliant, and painfully obvious idea that just didn't occur to me late at night.

So at 11pm, I install a fresh copy of GP 2010 and eConnect 2010 on another server, get my Visual Studio project setup, and then run the integration.  No Warnings.  In fact no activity at all in the eConnect Event Log.  Clean as a whistle, as my grandmother says.

So, the good news is that the error appears to only occur on one of my servers.  The not so good news is that Server A is a 32-bit Server 2003 machine with SQL 2005, and Server B is a 64-bit Server 2008 machine with SQL 2008.  Since the servers are so different, and since there are separate 32-bit and 64-bit eConnect 2010 installs, it is quite possible that the different configurations played a role in Warning vs. No Warning.  And the bad news is that I don't yet know what the Warning means or what is causing it.


I'll be converting two other integrations to eConnect 2010 and deploying them on the client's test server, so we'll see if the Event Log Warnings occur there.  I'll post an update if I learn more.


UPDATE:  Please see my follow up post on this topic.


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

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

My blog has moved!  Please visit the new blog at:  https://blog.steveendow.com/

I will no longer be posting to Dynamics GP Land, and all new posts will be at https://blog.steveendow.com

Thanks!



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

http://www.precipioservices.com

Compliments to the Dynamics GP Documentation Team

At the 2009 Dynamics GP Technical Conference in Fargo, I met a member of the Dynamics GP team that maintained the technical documentation, such as the eConnect and Visual Studio Tools help files.  (Sorry, it was a year ago and I don't remember is name...although I probably have his card somewhere...)

I told him that I used the eConnect Programmer's Guide help file constantly as a reference, so he told me that if I found any issues or had any suggestions, that I should definitely use the "Documentation Feedback" link at the bottom of every page in the help file.  He assured me that they do receive the feedback, and that every submission is reviewed.

Since then, I've found a few small typos or discrepancies in the GP 10 documentation, and I've submitted feedback for those to get corrected.  And sure enough, I have received a response from someone on the documentation team for every submission.

Well, today I was finally digging into the eConnect 2010 Programmer's Guide help file, and I was thrilled to see that they had reorganized the XML Schema Reference section.  The help file now lists the Type objects in the Content pane on the left, effectively adding an additional level of navigation to the Content pane.

This seemingly small change is a huge improvement, making it much easier to quickly find Types and Nodes, whereas in the eConnect 10 file, I had to page down through the list of Types and Nodes.

I really appreciate this change, and the fact that they are obviously paying attention to the details and looking to improve the documentation.  So, I just clicked on that Documentation Feedback link at the bottom of the help file and sent them my thanks!

Give it up for the documentation team!  Yeah!  (And the crowd goes wild...)