I've come across some really bad Dynamics GP integrations. I had one where the developer made a really pretty user interface with their own company logo and fancy controls and dynamic layout, but the import simply didn't work and the developer didn't know the difference between a debit and credit.
Then I saw another one where the developer wrote their own massive stored procedures to import GL and AP transactions into GP tables (I'm hoping that was done before eConnect existed). Scary stuff.
I got a call last week about an old integration that stopped working when a customer tried to set it up on a new Windows 7 x64 machine. The integration fails with two errors. The first appears to indicate that it encountered an error when it tried to read the source data file. And the second error says that the Crystal Reports runtime is not installed correctly.
Say what?
I got a copy of the .NET executable and decompiled it to try and find some clues. I found the section of code that is failing when reading the data file, but it isn't obvious why it is failing--the developer didn't bother to output any error messages in their error handling code, just a useless "There were errors loading data" message.
So then I move on and look for the Crystal Reports reference. Sure enough, the application relies on Crystal Reports version 10.2.3600. For those of you with long memories, Crystal Reports 10 is from around 2004. I have a copy of it, but my version isn't 10.2.3600, so I'm guessing it won't help. So now we're stuck digging around an old machine to try and find the right Crystal DLLs and see if we can get the import working again, and worrying that there may be some compatibility issue with Windows.
So why does a GP integration use Crystal Reports? Apparently the developer thought it would be super cool if he used Crystal Reports to display errors. No joke. So if the import has an error, the application launches a Crystal Reports runtime window to display the errors...in a Crystal Report.
So in a nice paradox, the application is encountering an error, and it then tries to display the Crystal Report to present the error, but Crystal Reports isn't working, so we get another error, and we are unable to see what the first error is.
They could have gone with a dialog box. They could have used a text box. They could have written to a text log file. They could have sent an email. All of those options would have been much simpler, easier, and worked just fine. But no, they had to get all fancy and bill the client a few more hours to build a Crystal Report just to display errors. Face palm. And now that 2004 version of Crystal Reports is ancient and is preventing the app from working on a newer version of Windows.
If you are developing an eConnect integration, or any simple business application for that matter, please just keep it simple. There is no need to Bedazzle a basic application like a data import. And when the application lasts for years and years and needs to be upgraded as the client upgrades GP, the simple application will be easier to upgrade, maintain, and support.
The developer who wrote this integration with Crystal Reports did not impress anyone, yet left a legacy of hassle and frustration due to a poor design choice.
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.
No comments:
Post a Comment