I am new to C# development and to eConnect and Web Services for Dynamics GP. From some sources I have picked up the notion that Web Services is somewhat limited in its functionality and sometimes it is necessary or desirable to build one's own web service on top of eConnect.
I am wondering, can someone explain what that would entail at a high level?
Most of the features available in eConnect are exposed through Web Services for Dynamics GP with a few exceptions. For example, it is not possible to explicitly specify taxes on sales orders using GP Web Services while this can be done using eConnect. I would encourage you to review the GP Web Services documentation to be sure your integration needs are covered.
GP Web Services adds an additional layer on top of eConnect. It uses eConnect in the back end. It provides a separate security layer and exception handlers. This may be of benefit in your environment if you have these needs, however it comes at a cost as the installation and maintenance of GP Web Services is not trivial.
I have on several occasions developed what you are asking about. I simply created a C# WCF service that encapsulated eConnect calls. Installation and maintenance is much easier because I control the specifics of the service myself. Plus I am able to better encapsulate my logic and obfuscate it from any other applications. Of course, you would need to consider security and exception handling logic just like any other service you create.
For example, my WCF service could have a very simple operation like:
string CreateCustomer(name, address);
In the logic of the service I would perform all of the eConnect calls and return the customer number that was created.
Ultimately the answer is "it depends". I would choose GP Web services if I had need for strict security on an entity by entity basis (access to sales orders but not purchase orders on a user by user basis), or if I was building a commercial product that I wanted to be installed on multiple different installations of Dynamics GP. If GP Web Services are already installed and in use at a client's location, I will try to use them if possible to maintain a consistent environment.
If a client does not already have GP Web Services installed and they need a simple interface for interacting with Dynamics GP, I might choose to create my own WCF to encapsulate the logic and make the integration as simple as possible for the consumer of the service.
Another thing to consider is that there are several things in Dynamics GP that cannot be done with eConnect or GP Web Services such as field service or manufacturing integrations. In those cases I will often create my own WCF and use eConnect where possible and SQL updates where eConnect doesn't cover the functionality.
Be sure to think about your integration needs today and what you are likely to need in the future so that your architecture decision will hold up in the long term.
Also read this excellent article for more details about choosing between eConnect and GP Web Services.