Overview

There used to be several methods for communicating with QuickBooks:

  1. QuickBooks Foundation Classes. This method uses a .NET library to access QuickBooks directly on a the machine on which QuickBooks is running.
  2. Remote Desktop Server. As the name implies, RDS uses a server component which acts as the intermediary between QuickBooks and a browser-based web application.
  3. QuickBooks WebConnector. Uses Simple Object Access Protocol, or SOAP, to communicate between QuickBooks and Web Services running on a server. With QBWC, the initial connection originates in QuickBooks.
  4. Scripting using a QBXML ActiveX component, which requires the use of Internet Explorer.

QuickBooks Foundation Classes (QBFC)
One of our project requirements is that our application runs in a browser. Also, we don't do any .NET programming, so for us, that would exclude QBFC entirely.

Remote Data Server (RDS)
RDS uses a client/server architecture. It was originally meant to allow several computers on a LAN to communicate via VBScript and an RDS client application with the machine running QuickBooks and the RDS server component. Earle West of Transactional Web and some other clever individuals figured out that RDS uses SOAP for communicating between the machines, and by using the PHP nuSOAP library, extended the nuSOAP soap_client class to communicate directly between a web server and QuickBooks.

Intuit was alarmed when the method and a link to the PHP class was posted on the Intuit developer forums. RDS was never intended to be used in this manner. Intuit responded by issuing many stern warnings regarding the safety of this method. In fact, the RDS server component was absent from the SDK for years while Intuit figured out a way around what they considered an unacceptably high risk. (Eventually, Intuit released QuickBooks WebConnector, the subject of the next section).

Intuit's reluctance to support this unplanned use of RDS stemmed from the fact that to use RDS over the Internet, one would have to open a port in the firewall (TCP 3790, by default). That could leave a company's financial data exposed to all of the evil that lurks on the web.

When experimenting with RDS over the net, I've tried to limit the possibility of trouble by filtering the IP address at my router to only the server hosting the web application. SSL is a functional requirement for RDS, and SSL requires a certificate and a dedicated IP address, so by locking that down, you are avoiding much of the risk. SSL also limits the possibility of someone intercepting the data enroute.

The main issue, besides having to open your firewall, is that RDS is very slow to respond. We're talking up to 20 seconds. Over the LAN, it's more like 5-10 seconds, but still, it's unnervingly slow. For that reason, I've given up action on it for the time being.

In the last SDK release, version 7, RDS suddenly reappeared. It's known as RDS version 5 now, and I haven't had a chance to experiment with it yet.

QuickBooks WebConnector (QBWC)
QuickBooks WebConnector is the new kid on the block. Unlike RDS, QBWC does not use client/server architecture. Instead, it uses a Web Services model. Instead of the server making a request to QuickBooks, it is QuickBooks that calls the server. For this reason, one normally doesn't have to open a port in the firewall (communications that are initiated from behind the firewall are usually allowed by default with most routers that a small business would purchase).

The most significant drawback is that you have to wait for QBWC to contact the server, so some form of message queuing usually needs to be employed at the server. You can set a scheduled time for QBWC to automatically make server requests.

Scripting using an ActiveX Component used to be possible before the latest version, although the documentation noted that it was not permitted. Like RDS, Intuit has closed off access to this method.