Recently, I’ve begun questioning whether I should bother using the Dynamics GP Web Services or simply write my own against eConnect. In the past I’ve done both. I’ve written several integrations using the Dynamics GP Web Services. I’ve also written a couple where I wrote my own custom web service against eConnect. Specifically, there were cases where I needed to develop GL integrations that used Analytical Accounting, functionality provided by eConnect but not Web Services.
My latest conundrum has come about because I have a client I’ve written three integrations for using Web Services. An enhancement they’ve asked for requires me to integrate invoices and returns and then apply them to each other. It appears that this is doable through the taRMApply node (though I haven’t had a chance to try it yet) but not available through Web Services.
So now it looks like I need to create a custom web service, outside of the Dynamics GP Web Service security domain, to simply implement the apply functionality. Beyond the missing eConnect functionality I’ve developed a few other pet peeves:
- I have a <50% success rate on a first time install of Web Services. Sometimes a repair or reinstall will work. Often a support ticket on PartnerSource is required (I’ve noted that when entering a PartnerSource support ticket Web Services Installation is now a separate category from Web Services).
- I can’t add an Active Directory group to a role assignment. I must add individual users.
- You must pass complex objects to the methods so they can’t easily be called by InfoPath or SharePoint Designer workflows. OK, I can’t really be too hard on them for this as I’m not sure how you easily generically build a web service to allow an integration to pass an AP document header and distributions in a simple web method, but still it means I’m writing my own web services.
- Performance, especially that first call, leaves something to be desired.
- Significantly less extensibility than eConnect and as far as I can tell unable to make use of any eConnect extensions.
OK, so when it does meet your requirements it works quite well. It also has an exceptionally robust role based security model I certainly wouldn’t want to have to reproduce, but quite frankly it’s overkill for what I need it for.
So I think for now I’m going to lean towards a roll your own web service model on top of eConnect and wait to see what GP 11 holds in store.
Let me know what your thoughts are on this.
Posts
I tend to agree with you. I have been doing 2 projects with the Dynamics Web Services and had more problems than anything else.
ReplyDeleteThanks for the article. We are looking into different ways to integrate with Dynamics GP. Right now we are using Integration Manager and our custom .NET Winform app. Web services is something I am looking into, as well as eConnect. We specialize in eCommerce integrations for Dynamics GP, so we would like to have real-time data capabilities. We currently do not have that, close, but not real-time. Also, we install our app on the client server running Dynamics GP, so when they make a change to a security policy, etc. it has the potential to effect our application. So if there is a way to integrate Dynamics GP from a web service call or some other method that would be worth looking into. Any ideas? comments? suggestions? Thanks again.
ReplyDeleteThe first thing to keep in mind is to never assume that you'll have access to GP 100% of the time. Your ecommerce site may have a 99.999% up time but GP is probably going to be located on a companies internal server with a lesser grade of internet connectivity and with uptime expectations more in the weekday 9 to 5 range when the finance department is working.
ReplyDeleteWith that in mind, you'll want to have some caching and queuing mechanism on both ends.
On the inbound side (web site to GP) I would recommend looking at creating some custom, externally accessible web services on the GP end. These would have only the functionality you need (create orders, update inventory, etc.) and utilize eConnect (either the COM+ objects or the stored procs themselves as noted in another post) to send data to GP. You would have some sort of service on the web server end that would send updates in real-time if it could connect to GP, or cache them if it could not.
On the outbound side (GP to web site) for thing such as updating inventory amounts, items, order fulfillment status etc., you can look at the eConnect Transaction Requester Service. With this, eConnect publishes changes to documents, such as orders and invoices, to a GP table and/or Microsoft Message Queue. You could then write a service that listens to the queue and updates the website.
Anyway, just a few thoughts. If you're looking for more detail, don't hesitate to ask here or by sending me a message on LinkedIn (my profile link should be at the top left of this page).
If we talk about deployment of the project using only eConnect vs Project using web services, which will demand less work at client side.
ReplyDeleteAs my company was looking something demands less work after project is done. Say End Client don't have installed anything But GP only (No eConnect or Web Services)
Web Services will generally require less work on the client side as the web services only need to be installed on the server. If you're using the eConnect COM objects you'll need to install the eConnect Runtime on each workstation and make sure that DTC is properly configured. I've had some difficulty with that in the past.
ReplyDeleteAnother option is to look at using the eConnect stored procedures directly. In this case all you need is a SQL connection. This is not well documented but I have a couple of posts regarding that:
http://dynamicsgpgeek.blogspot.com/2010/01/my-adventures-using-econnect-stored.html
That is the easiest to setup from a client standpoint but due to the lack of documentation can be a bit of fun to get working correctly.