Howdy Dynamics GP Community! From Austin TX with Love :)
Well, I'm in the throws of a very interesting project. My computer science geek is having a hay day, that is for sure. I'm doing a custom integration. The application that is doing the integration or sync'ing of data is a .NET 4.0 C# WPF application. On my customers side, I am talking to a WCF compliant End point to do CRUD operations. On the Dynamics side, there are number of options. Prior to this project, I had no experience with Microsoft Dynamics, but I have a lot of experience with MS-SQL, XML and Web Services, both ASMX and WCF. So off we go.
The Integration Challenge - What to use on the Dynamics Side? Direct MS-SQL calls, eConnect or GP Web Services? There is a lot written about that. Here are a few of the links that have helped me navigate that question:
- Good High Level Overview of the options from our friend Sandip Jadhav - http://sandipdjadhav.blogspot.com/2010/04/types-of-integration-method-with.html
- Choosing between eConnect for Microsoft Dynamics GP and Web Services for Microsoft Dynamics GP by Chris Roehrich - http://blogs.msdn.com/b/developingfordynamicsgp/archive/2012/04/27/choosing-between-econnect-for-microsoft-dynamics-gp-and-web-services-for-microsoft-dynamics-gp.aspx
- Circumnavigate the entire GP Web Service framework and create a custom web service talking to eConnect. http://stackoverflow.com/questions/16491637/create-your-own-web-service-on-top-of-dynamics-gp-econnect
I really like working with Objects in Visual Studio instead of XML, call me spoiled by intellisense, cause I am. As you probably already know, the schema of the Dynamics GP MS-SQL DB, is cryptic to say the least. So trying to avoid direct SQL calls seemed like a good idea, but as I got into it more and more, avoiding making direct SQL calls and having to search through the exquisitely confusing data model of Dynamics GP is pretty much unavoidable. The GP Web Services security plugin is just good form when dealing with Accounting data. From a liability point of view, I'd rather be able to say that Microsoft built the security layer rather than me. Also, the GP Web Security plugin integrates with active directory, which SysAdmins will appreciate. I also like the Web Services exception handling plugin. Its handy for sure, but mostly just isolates Dynamics exceptions from other system exceptions found in the event viewer.
So, we decided to go with Dynamics Web Services initially to do our integration. Off we go. First hurdle. I'd like to be able to get the human readable description of ProjectBudget.ProjectBudgetkey.CostCategoryKey so our application can display that same ProjectBudgetCostCategory as Dynamics. Guess what? Not provided functionality via GP Web Services... hmmm... so, how to address?
This is where the meat of this discussion comes in. The next layer of customizing GP Web Services. GP Web Service Extensions or a Custom Web Service? What to use, when and why. I haven't found much out there about this and there certainly isn't much out there about the level of effort between both.
Oh the ways we Computer Scientist love to skin that cat. ;) You can see my post on Cost Category Description here: https://community.dynamics.com/gp/f/32/p/23679/222111.aspx#222111 In this post, you'll get to see me create a GP Web Service Extension and also get step by step instruction of how to debug a GP Web Service Extension.
Web Service Extensions are actually pretty easy to create, especially when compared with a custom web service. In a rare occurrence, Microsoft's Documentation about how to create both a Web Service Extension and/or a Custom Web Service, is actually REALLY GOOD. Step by step for dummies type documentation. http://msdn.microsoft.com/en-us/library/cc508802.aspx I knocked my first Web Service Extension out in a day. Also highlighted in that post is how to debug a web service extension.
Here is the the elevator pitch of Web Service Extensions. Mostly, any object in GP Web Services that has real data in it, not a Summary Object, extends a base class BusinessObject. BusinessObject.Extension provides a framework for attaching custom XML to said BusinessObject. So, to get my Cost Category Description, I extended the ProjectBudget - http://msdn.microsoft.com/en-us/library/cc508336.aspx with some XML. I had to make a custom SQL Call to the DB to get the data, then build the XML document and then attach it to BusinessObject.Extension. Why I say, that its pretty much unavoidable to deal with the cryptic nature of the GP MS-SQL Database Schema.
A great resource for navigating the beautiful DB structure of Dynamics GP is http://www.gptablereference.com/ As well, inside the the SDK (2010), C:\Program Files (x86)\Microsoft Dynamics\GP 10.0 SDK\Content\DatabaseDiagrams, VISIO diagrams can be found by module for the database. I have also found some SQL scripts that find column names from System Tables pretty useful.
So now I have an list of ProjectBudget items,which are projects broken down by Cost Category WITH human readable Cost Category Descriptions being returned inside the extension. Yeah! The returned list of ProjectBudgets gives me everything I need to populate our application, projects by cost category that are human readable. This works because this gives me all projects with all cost categories, which is what I need.
Next challenge. PayCodes. Unlike creating a web service extension for project.costcategory, creating a employeepaycode extension that gives me the human readable paycode description doesn't guarantee me that I will get a comprehensive list of the paycodes available in Dynamics. I'll get a list back of all of the paycodes taht have been associated with an employee, but not the comprehensive list. As our friends in London Underground like to say, Mind the Gap! So, what to do? In comes the Custom Web Service. I have to create my own BusinessObject derived class and add it as a Custom Web Service, PayCodes.
So, how I see the line between and extension and custom web service. If you want to attach some BusinessObject specific data to a specific instance of a BusinessObject that is NOT part of the GP standard Web Services API, you can do this pretty easily with a GP Web Services Extension. If you want some data from Dynamics Web Services that won't give you a comprehensive look by attaching it to an included BusinessObject, you have to create your own derived BusinessObject and and then create a Custom Web Service around it. http://msdn.microsoft.com/en-us/library/dd996562.aspx
Custom Web Services is a much more complicated process. It requires the ability to create stored procedures, write SQL, understand and perform XML XSLT transformations, install and configure eConnect, create eConnect XML documents and a good if not full understanding of how to create a WCF end point and further how to decipher the Dynamics Web Services Framework. There is a lot more to do to create a Custom Web Service.
I'm going to dive into creating a Custom Web Service and I'll outline my experience in this post so others may hopefully, gain some knowledge from my experience.
Matt