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.
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.
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.
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.
Useful information and highly described Chris. Appreciate it. Thanks...
Looking toward the GP 13 Web Client, isn't it going to be necessary to recode customizations that use eConnect to use web services instead?
The Web Client is an additional option for using the Microsoft Dynamics GP client application. You still have the locally installed and Terminal Server/Citrix options, but will now have a new option which should be more cost and resource effective than Terminal Server.
It does not affect eConnect or Web Service integrations at all. Both of these options will continue to be available. Note that Web Services sits on top of eConnect. It exposes a subset of the eConnect objects as Web Services.
Note: The web client version 1 will have limitations with VBA and Visual Studio Tools winforms.
Posting from Janakiram at Dynamics Blogger
Nice post, completely agree with all of your points. I also definitely like how the web services moved into WCF. Hope to keep seeing more of the same from GP.
Where's the Like button?? Thanks, Chris - great article! :)
I hate to be the nagging little old lady in the room (don't get me wrong, this was by far one of the best write ups I've seen on the subject). However, you went straight to the throat with "web services is better than eConnect", I guess making it really your own preference. Web services has its place in distributed application integration scenarios, but for simple, everyday application integration, eConnect may prove faster (as you don't have the extra architecture layer to traverse as mentioned above) and much easier to address, especially now that you can reference it as a service or an assembly from within your VS solution - dispite having to deal with serialization and deserialization of XML documents.
You also forgot to mention that the infrastructure required to support web services demands IIS, something that most companies are trying to stay away from if at all possible. This is perhaps the reason why most applications like SSRS and even Management Reporter have been rewritten to break their dependency on IIS.
The way I see it, preference is a big player in the tools selected by a developer, however economic impact is a big aspect that most companies will consider before deciding which tool to select nowadays.
Mariano Gomez, MVP
How am I going to be able to co-present with you now that all I see is you with stooped shoulders and a knitted shawl over your head?
Web Services for Dynamics GP 2010 and the upcoming 2013 release should not have a requirement for IIS since it is implemented as a WCF service. I have it on a Windows 7 laptop and IIS is not installed. It did have an IIS dependancy for GP 10.0 so that is something to consider.
I agree that personal preference and economic impact both play important factors. Thanks for your feedback on the post!
Posting by Mariano Gomez, The Dynamics GP Blogster
Posting by Vaidy Mohan at Dynamics GP - Learn & Discuss
I have GP 2010 on-premises. Last I knew, eConnect was extra licensing cost. Is that true for web services as well?
The licensing requirements for WS/eConnect are the same.
PLEASE READ BEFORE POSTING
Please only post comments relating to the topic of this page.
If you wish to ask a technical question, please use the links in the links section (scroll down, on right hand side) to ask on the Newsgroups or Forums. If you ask on the Newsgroups or Forums, others in the community can respond and the answers are available for everyone in the future.