Putting to Rest Four Myths About Microsoft Dynamics GP Integration Manager

December 22 2009

It's year-end and my client, an advanced IT infrastructure and managed outsourcing solutions provider, is going live on Microsoft Dynamics GP. At first glance you may ask, "What's so special about that?"

About Mariano Gomez

More about Mariano Gomez


sendow's picture

Hi Mariano, Thanks for the article. I've actually never heard myths 2, 3, and 4 before, and would be puzzled if anyone brought them up as weaknesses of IM--so on those I agree with you. But for #1, I would argue that "scalable" may not be the best term to use. It seems that you are describing Integration Manager's performance, or capacity to import large volumes of transactions--not necessarily it's scalability, which denotes a capacity to be "expanded" to "handle growing amounts of work" . In some specific circumstances, yes, IM may have "acceptable" performance for importing X number of transactions, but that's is contingent upon several factors and is subjective. For instance, importing 100 GL transactions using the eConnect destination adapters may be relatively fast. But when you have to import SOP transactions with serialized inventory and line level taxes, you must use a standard adapter for a transaction that is significantly "larger" and which takes much longer to import. For example, I would never recommend IM to import 10,000 of those SOP transactions a day in a time sensitive environment. As for scalable, I would personally never claim that IM is scalable. If the performance of an IM integration was unacceptable, what options do you have to make it scale? Run it on multiple computers? I wouldn't want to recommend such a solution to an enterprise IT team. eConnect and .NET on the other hand have many options for true scalability. Queuing, multi-threading, and multiple federated instances are just a few examples. A conversation that I have frequently with clients, which I think is relevant to your article is: What is the difference between IM and eConnect, and when would I use one vs. another? Having had this conversation more times than I can count, I offer the following guidelines to clients. 1) If you need to import transactions that are not supported by IM, you will have to use eConnect or some other custom integration. Project Accounting and Analytical Accounting are two common culprits. 2) If you want your integrations to be fully automated, you should use eConnect and .NET. Yes, it is technically possible for IM to be automated with duct tape and twine, but it isn't pretty. On the other hand, a .NET integration can be developed to run via Windows Task Scheduler or as a Windows Service, making the process of automation much simpler and much more reliable, all without requiring an active GP session. 3) If you have a complex data source or a complex integration, an eConnect .NET integration has much more flexibility and a much more powerful toolset for meeting the integration requirements. Editing and debugging VBScript in that horrible IM code window is no match for Visual Studio, .NET, and eConnect. One example is a client that needed to import complex XML files with over 60,000 lines that contained standard and drop ship Purchase Orders and standard and drop ship SOP Orders. IM couldn't even begin to read that XML file, let alone validate it prior to import, let alone have the line-item level events to process the transactions appropriately. 4) If you need to create many integrations, IM may be more cost effective. If a client needs 5, or 6, or 8 different integrations, it is often more cost effective to pay the $3k or $5k for the appropriate IM license than to pay a consultant to develop all of those integrations from scratch (assuming IM can do the job). IM lowers the marginal cost of each new integration, whereas each eConnect integrations must typically be developed separately, which requires billable hours. 5) And finally, volume. If a client needs to import more than 1,000 transactions a day, and if the client anticipates any type of transaction growth, I recommend that the client consider eConnect. As I mentioned above, it depends on the type of transaction and many other details, but this is the generic number that I offer clients to help them understand their choice. Most clients I've spoken with are clearly in one category or another--low volume or high volume, so it isn't usually a difficult choice. Thanks, Steve Endow Dynamics GP Certified Trainer Dynamics GP Certified Professional

mepacy's picture

Hi Steve I'm looking at a problem where using the eConnect adapter to integrate Inventory transactions gets stuck at around 100 transactions. It looks like eConnect opens 100 processes, but doesn't close them and the integrations therefore stops. As a stop gap they're using a standard integration for IM but would like to use the eConnect adapter so they don't have to open GP. I haven't tested this yet myself but saw your article and thought you may be able to offer me some quick advice as to whether this is a common complaint. Using eConnect itself is not an option as the user is the one creating the integrations and would be unlikely to want to spend any money in that area. Regards Mike Pacy Dynamics GP Certified Professional

sendow's picture

Hi Mike, That is definitely not an eConnect issue or limitation. I would check your variables and loops to make sure that you are not re-instantiating objects, and step through your code to determine the cause. I'm not sure what you mean by "opens 100 processes". If you are creating 100 process, that is definitely a problem with your app and not with eConnect. I have eConnect integrations that import tens of thousands of transactions at once with no issues whatsoever, so high volume is not a problem at all. Steve Endow Dynamics GP Certified Trainer Dynamics GP Certified Professional

Hector's picture

I think IM has many good features, especially ease of use but for high volume transactions it could be not suitable. I had to replace an AR integration with IM that was taking close to 4 days to run with eConnect it took 2 hours. In this case, the client was extremely pleased not only because it was more efficient with eConnect but also because they could now invoice clients more rapidily and of course that improved the invoice to cash cycle. Hector De Jesus Trujillo

mgomezb's picture

Hector, Thanks for your input. I have seen many reasons for poor IM performance, ranging from poor Dynamics GP hardware platform -- after all, IM depends on GP's performance -- all the way to poor SQL Server configuration. I am not advertising IM as a replacement to eConnect, but rather a solution that customers may consider under certain circumstances. The best solution is the one that delivers the results expected by the client. In my client's case they knew what to expect and had the resources to dimension their environment accordingly -- they are a hardware and infrastructure services provider. MG.-

mgomezb's picture

Steve, Thanks for the pretty detailed explanation and I definately appreciate your readership. I have to be clear that my client has considered IM as a temporary solution to a complete migration away from the AS/400 platform and not a permanent solution to application integration. Nonetheless, this has not scared my client from putting together the necessary hardware (and software) in place to make IM *perform* optimally. I will not dispute the scalability points you bring up, but I tend to suggest IM in batch processing type environments as supposed to real-time high volume processing which is what I believe you are referring to when you reference the 10,000 SOP transactions with serials and a large number of line items. As for you points about the differences between IM and eConnect, you are dead on. If I had to simplify your 5 points, the choice between IM and eConnect is especially driven by cost and level of automation -- high volume/low volume is relatively subjective. In my client's case, they wanted a certain degree of automation and not necessarily real time data transfer. After all, IM can be automated to a certain degree, but still be able to work on demand if needed. On the other hand, my client's instructions were pretty clear: they did not want to spend excesive time developing and maintaining a solution and wanted users to be responsible for their transactions. Could we have developed a pretty interface to eConnect allowing users to interact with the integration? Certainly could have, but not what the client wanted given the time and budget constraints, and other priorities in place. Thanks for your overall input and please keep reading. I welcome all your comments and appreciate your perspective. MG.-

bagwellk's picture

Thanks Steve, that was one of the best replies I have ever read. Your experience is very consistant with my own. IM is not performance-related solution. That's a little detail that someone should know.