Dynamics GP and SQL Server 2008 Reporting Services

As of Dynamics GP 10.00 Service Pack 3, SQL Server 2008, including Reporting Services is now supported.  One little item to note however, is that in the Reporting Tools Setup, Reporting Services Tab, the Report Server URL needs to reference the ReportService2005.asmx web service file instead of the ReportService.asmx file as the ReportService.asmx file no longer exists.

As such the URL should be:

http://MySSRSServer/ReportServer/ReportService2005.asmx

Quick ODBC Administrator Tip When Installing Dynamics GP on 64bit Systems

We’ve started to run across clients requesting that we install Dynamics GP clients on systems with 64bit operating systems.  One of the first issues we came across was not being able to find the Dynamics ODBC DSN.  A DSN created by the Dynamics GP install was not visible in the ODBC Administrator tool and a DSN created in the Administrator tool was not visible to Dynamics.

It turns out that the default ODBC Administrator tool under the Windows Administrative Tools menu on a 64bit OS is the 64bit version for 64bit ODBC.  Since Dynamics is still a 32bit app we need to find and run the 32bit ODBC Administrator tool.  The executable is Odbcad32.exe and is located in the %systemdrive%\Windows\SysWoW64 folder.

eConnect + Custom Web Service vs. Dynamics GP Web Services

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.