Partager via

Best practices on Connector implementation – Directly from a Microsoft Dynamics partner

  • Article

David Meharg, Senior Manager of Consulting at Armanino McKenna, a Microsoft Dynamics partner in California, has been implementing Connector for Microsoft Dynamics for his customers. He's using Connector to help them integrate their Microsoft Dynamics GP and Microsoft Dynamics CRM solutions.

David took the time to share with us his "best practices" for Connector implementations. We thank David for these great tips and timesavers that will help more of you have success with Connector.

1) Become familiar with Dynamics Security Console.
This is a function of Dynamics GP Web Services, not the Connector. But, this is also a key spot where policies dictate how the data coming from Dynamics CRM is handled when being processed by the Microsoft Dynamics GP web service. Some tweaks will inevitably be needed in this area. For example, Price Overrides are configured via the Security Console.

2) Determine what really needs to integrate and what simply needs to be exposed in the Dynamics CRM interface
There are many details that live in Dynamics GP that may be useful to see in Dynamics CRM. The knee-jerk reaction is to create an integration to pass those values across. In many cases, however, the default maps in the Connector do not accommodate those integrations. Rather than build an integration, perhaps a better approach is to expose the information (in real-time) via a Microsoft SSRS report. We did this for Tracking Numbers. The Tracking Number table in Dynamics GP is not an out-of-the-box, mappable field. By creating an SSRS report, where we pass the Order # value as a parameter from Dynamics CRM, we gained full visibility to all Tracking Numbers associated with orders. Additional logic can be added in the report to create a clickable link to take you to the carrier's tracking page. The same was true for us on Quantities. Dynamics GP provides a wonderful table that contains Quantity on Hand, Quantity Available, On Back Order, etc. It is very simple to provide real-time inventory status, exposed in an iFrame on the Item card in Dynamics CRM, via SSRS so that this information is visible when adding items to a Quote or Order in Dynamics CRM. Exposing data like this is often easier than trying to devise a complicated integration.

3) Watch what you type for credentials when installing Web Services for Dynamics GP
While not directly related to the Connector, Web Services for Dynamics GP is a required component that allows the Connector to work. When installing and configuring Web Services you are asked for the credentials of the domain user that is being used to run the service. It needs to be in the domain\username format. That in and of itself is not unusual, but what is unique, is that the syntax used for the entry is case sensitive. The values that you enter must be capitalized exactly how the name reads. One place to check for this is in Microsoft SQL Management Studio. As part of the installation, you needed to add this domain user as a user to the various databases involved in Dynamics GP. Check there to see what syntax was used.

4) Save maps regularly.
In the course of customizing the Connector's various entity maps, you should regularly create backups of your maps. Inevitably you will tweak a map function in such a way that an error will result. If you can identify and fix the error right away, you're in good shape. But, there are occasions, and you will undoubtedly face this a few times, where you can't identify where the error is. And, when there's an error, you can't save that map, or any other map for that matter. Should that time come, you may need to delete the map and re-import it into the Connector. Having backups of all of your maps is a life-saver. The moral of the story is to back up your work.

5) Create custom fields in Dynamics CRM before you initially configure Connector
Admittedly, this advice is not always practical, but it can certainly help. When you do a full configuration of Connector, the process looks over to Dynamics CRM and identifies all of the fields associated with a particular entity, both standard and custom. This allows Connector to present them as mappable fields. Should you do the initial configuration and then add a field to Microsoft Dynamics CRM later, that field will not automatically show up in the Connector. You must re-run the CRM configuration utility in order to read in that new field. That means stopping the service, running the config, restarting the service, etc. It takes a wee bit of time each run at it. If you piecemeal your new field additions, that all adds up. The best approach is to pre-determine as many of the custom fields needed up front, then run the CRM configuration utility. Some custom fields that are often needed include: Batch ID and perhaps some unique User Defined values for Orders; Custom Description and Site/Warehouse ID for Product Line Items.

6) Learn where to troubleshoot.
I've yet to run into an integration that worked every single time. There will always be snags, whether it be missing or mismatched data or simply an attempt to create a duplicate record. Connector logs all of its integration attempts. While it quite often will provide the necessary information to troubleshoot, the log's message is sometimes very nebulous. So, while the Connector log is the first place to look, you also need to be familiar with how to access the Exception Management Console for Web Services as well as the Event Viewer for eConnect. Fortunately, even if the log gives you an indeterminate error, you do have a clue which side of the integration is failing by looking at the Error Code: line in the Message Properties of the error. It will indicate which side recorded the problem. For example: Microsoft.Dynamics.Integration.Adapters.Gp2010::0x80131501, indicates that the failure happened on the Dynamics GP side. This would lead you to look in the Exception Management Console for more information. Here you can view the exact XML that was used during the transaction. Then, occasionally, you may find the Event Viewer log for eConnect can help define things even further. Knowing where to look is critical to quickly determining a solution.

7) Know when the integration works.
Knowing what happened when an integration fails is one thing, knowing that an integration actually went through is equally as important. There is nothing worse than to hit the "Submit to ERP," assume that it went through fine, and only find out later that it snagged in the Connector. Key indicators include: Was the record assigned an Integration Key value? For Orders, did the Name field update with the Dynamics GP Order Number? If you can identify the key fields that are updated via a round trip from Dynamics CRM to Dynamics GP and back, then you will be able to create a View of the entity that filters out everything but the "failed" integrations. Then you know that extra action may be needed on these records.

Comments

  • Anonymous
    September 19, 2011
    Char - I need to do exactly what you have listed in #2 for Tracking Numbers and GP. By chance, do you have the code for this? I would rather not reinvent the wheel if not necessary. Thanks!