Choosing between eConnect for Microsoft Dynamics GP and Web Services for Microsoft Dynamics GP
Should I write this integration using eConnect or Web Services for Microsoft Dynamics GP? This is often a question we receive at conferences like Convergence or in support cases from both Customers and Partners. Like most questions in our field, there really is no concrete answer to this one. The answer is usually the dreaded "Well, it depends on...". What I hope to do here with this post is point out some of the differences of the two integration platforms, give you my opinion on what I like about them, and then you can decide how you would leverage them in your own projects.
Coding Differences
When you retrieve data out of Dynamics GP using Web Services, you will receive a type that inherits from a BusinessObject type and when you use eConnect you will receive a XML string that describes the data. So the deserialization process automatically takes place with GP Web Services which is handy and easier to use in my opinion. I would rather write code using Visual Studio's intellisense and interact with the object representation than have to worry about parsing the XML nodes. The following screen shots illustrate what I am talking about using an example of retrieving of a Customer from Dynamics GP.
The Customer type returned from Web Services by calling GetCustomerByKey:
The XML string for the Customer returned from eConnect by calling GetEntity method:
Additionally, the object you retrieve from Web Services is the entire object so you get all the data associated to all the properties of the object. So when you perform updates on an object after calling the GetByKey method, the entire object is sent back in which can also be helpful. An example might be if you are updating sales orders. If you perform a GetSalesOrderByKey, and then call an UpdateSalesOrder, you will be providing all the existing data for the properties related to the sales order automatically so nothing would be removed or changed. Using eConnect, you need to provide the entire sales document or some of the existing data may be changed.
The methods and their signatures for eConnect and Web Services are different also as one might expect. The eConnect methods are discussed in MSDN here. For eConnect, you provide a connection string and a XML string that describes the document or transaction you are integrating. As part of the eConnect installation, we provide a serialization assembly named Microsoft.Dynamics.GP.eConnect.Serialization.dll that you can use to help you create the XML string. Note the CreateTransactionEntity method requires the two string parameters in the screen shot below:
For Web Services which are discussed in MSDN here, you will use a specific method for the type of document or transaction you need to use. The signatures vary but all require a Context object which would provide the desired company. For write operations a Policy object is required which I will discuss below. Then you will also provide the object type (Ex: SalesReturn type for a Sales Return transaction or CustomerKey type for a GetCustomerByKey method to retrieve a Customer). The following screen shot shows the CreateSalesReturn method which requires the SalesReturn, Context, and Policy types:
Both eConnect and Web Services reference information in MSDN is very helpful. There are also sample applications for both products available. For eConnect on 64 bit computers, the sample applications will install to the C:\Program Files (x86)\Microsoft Dynamics\eConnect 11.0\eConnect Samples folder when you install eConnect 2010. For Web Services, you will need to download the SDK from here and the samples install to the C:\Program Files (x86)\Microsoft Dynamics\GPWebServicesSDK\v11\Samples folder.
Feature Differences
If transaction performance is a priority and you also want to have less complexity involved, I may lean towards recommending eConnect. This is because of the overhead introduced by the security layer of GP Web services and its serialization\deserialization process. Also, the installation for Web Services adds more SQL objects like views and tables that maintain its installation status. However, this overhead introduced by Web Services may have some definite advantages for you also and for many integrations the overhead may be negligible too. The security service layer in Web Services for Microsoft Dynamics GP is powerful and easy to take advantage of in your integrations. The idea behind it is that you can manage users or groups of users across the organization and give them access to the desired web service operations by placing them in a built-in or custom role. If a user does not have access to the web service operation, an error is raised by the security system. You manage users by using a simple MMC tool called the Dynamics Security Console under Administrative Tools.
The Dynamics Security Console also allows you to manage the Policy objects and Entity ID Assignments for Web Services. The Policy node allows you to control the Behaviors that certain operations allow. For example, the Create Sales Order Policy has a behavior called "Calculate Unit Price Behavior". You can set this so you can pass a unit price manually or you will let the system default the unit price for you.
The Entity ID Assignment node allows you to associated users to specific Dynamics GP Users, Customers, Employees, Sales Territories, Salespersons, and Vendors:
Once you have your Entity ID's setup, you can limit the records a user has access to when calling the web services methods so they only see their associated records. For example if you assign users to Salesperson ID's, then when you call GetCustomerList, you can make sure they only see the customer records assigned to their Salesperson ID. This is accomplished by using the CustomerScope property of the CustomerCriteria object. This is a very powerful feature!
The Web Services also have an Exception system that can also be used to retrieve System and Validation type exceptions whereas eConnect will just write exceptions to the eConnect event log under Event Viewer. You can view exceptions from Web Services by using the Exception Console under Administrative Tools which is another MMC tool or can you can also call Web Service operations like GetLoggedExceptionDataList to retrieve exception data. The Exception Console can also be installed on a different computer than the GP Web Services computer so it can go on multiple computers in the organization.
eConnect gives you an option to install a couple services that you may wish to take advantage of in your integration strategy. The services are called the "eConnect Incoming Service for Microsoft Dynamics GP 2010" and the "eConnect Outgoing Service for Microsoft Dynamics GP 2010". These services can only be installed on a computer that has Microsoft Message Queueing (MSMQ) enabled. If MSMQ is not enabled you will not see the option to install the services.
MSMQ provides queues which can be securely managed. The eConnect Incoming and Outgoing services interact with the Queues:
The incoming service reads a Message Queue that would contain eConnect XML messages and processes these messages by sending them to the eConnect API. The eConnect API calls the stored procedures in the Dynamics GP database at that point. It is up to the developer to write an application that interacts with the Message Queue to place the eConnect XML document in the Queue. The .Net Framework provides the System.Messaging namespace to use.
The outgoing service uses triggers on the Dynamics GP database tables that write records to the eConnect_Out table. The outgoing service pulls the records out of the eConnect_Out table and sends a XML message that describes that data into a Message Queue. It is then up to the developer to handle what to do with the Dynamics GP data sitting in the Message Queue.
To work with MSMQ using .Net, a VB sample is located under the C:\Program Files (x86)\Microsoft Dynamics\eConnect 11.0\eConnect Samples\VB DOT NET Queue Client folder. I recommend to check it out if using MSMQ is something you can consider.
Summary
In the projects I have worked on, I lean towards using GP Web Services when I can. In the end, it's just a personal preference of a better experience for me with Visual Studio and working with the business objects provided by the service. But I will say that you may end up using both integration tools in your project. I have coined this "the hybrid approach". You may use both because not all eConnect business logic is in GP Web Services. So you may start with using GP web services and come across a scenario where what you want to do is not available in the GP Web service object model. An example might be to create POP Receivings Transactions that are Shipment\Invoice types (POPTYPE=3), apply Cash Receipts, or provide your own taxes with Sales Orders. All three of these items at this point in time cannot be done with GP web services but can be done with eConnect.
Good Luck!
Chris