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
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.
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:
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.
I recently co-authored a Microsoft sponsored whitepaper with Cynthia Papas of the accounting firm Parente Randolph on how to deploy and configure SQL Server 2008 in a compliance with the Payment Card Industry Data Security Standards (PCI DSS) (click here to download the whitepaper and here to replay the TechNet webcast).
Although this paper is about SQL 2008 in general and PCI DSS in particular, I wondered how it might apply to my Dynamics GP clients. The reality is that few of them do credit card processing out of Dynamics GP and so don’t need to comply with PCI DSS. However, here in Massachusetts we’ve enacted the Mass. Privacy regulations that go into affect 1/1/2001 and cover the protection of personal information such as Social Security Numbers, driver’s license numbers, bank account numbers etc. Many other states have similar regulations (I believe the Mass. ones are based on California’s). In addition there’s HIPPA, SOX, and on and on. And the reality is is that it’s just good business to protect your customer, vendor and employee data.
So other than credit card numbers, what sort of data might be sitting in GP to protect? A couple of months ago I had to fix a companies 1099 data. Stored in the Vendor master table were hundreds of 1099 vendors with their unencrypted SSNs. Same would be true if you’re running payroll through GP.
If you’re a healthcare provider and billing out of GP, in all likelihood there’s medical data in those invoices that come under the jurisdiction of HIPPA.
If you use EFT with your customers or vendors you’re storing bank account numbers for them.
Most of these regulations deal with not only the protection (access control and encryption) of the data but also auditing the viewing of the data. SQL 2008 helps on both these fronts.
First, with Transparent Data Encryption (TDE), SQL will encrypt the entire database, as well as log and backup files, in a way that the consuming application (in this case Dynamics GP), need know nothing about.
Additionally, SQL 2008 offers built-in auditing, including audits on SELECT statements (no need to use SQL Profiler). Unlike most homegrown or off the shelf auditing tools, SQL 2008’s auditing capabilities are not based on triggers and work asynchronously, thus having a minimal impact on performance.
There’s more detail in the whitepaper as well as on Microsoft’s site and other third party sites. The thrust of this entry is to get you thinking about whether there’s data in your GP databases that needs to be protected and might it be worth considering an upgrade to SQL 2008 to do that given the risk of identity theft and its associated liabilities.
Support Note: To my knowledge, only Dynamics GP 10.0 SP2 and above supports SQL Server 2008.
Posts
All Comments
