Basics of Drupal Quickbooks Integration

Companies with an online store traditionally face a dilemma: both the retail and the accounting applications need to access the data describing products, customers and orders. Rarely are these two business processes colocated on a network map. Online retail occurs on a webserver in the cloud, while accounting occurs either on a local machine or on a server in a company's local network. Switchback took on the task of connecting the accounting (Quickbooks) and retail (D7 Commerce) pieces of online commerce.

Switchback will be releasing a Quickbooks Web Connect module for Drupal Commerce.

First some background. The Quickbooks accounting platform uses a service oriented approach to make connections with external retail databases. The protocol is SOAP, and QWC is the client. 

The Drupal services module is the other half of the equation. On the Drupal side, the stack goes: soap_server -> services -> switchback custom resource handlers -> commerce -> D7 core. The Quickbooks Webconnector (QWC - included free with Quickbooks) client authenticates using a regular drupal session. Since a QWC update cycle consists of an unknown number of requests, QWC uses the Drupal session token as an identifier to maintain a single session per update. We wrote a simple authenticate function to check if a provided session token is valid: 

global $user; 

// load the session. if valid, will populate $user

_drupal_session_read($sid);

if (user_access('access quickbooks SOAP', $user)){

  return true;

}

See http://developer.intuit.com/qbsdk-current/doc/pdf/qbwc_proguide.pdf for a breakdown of the RPC requests made by QWC. Requests that come after authenticate must have some way of validating a session token of one kind or another.

After we confirm the identity of the Quickbooks client, we craft XML strings representing data to be returned to Quickbooks, and return these from our sendRequestXML method. For useful examples of the various QBXML formats, see http://www.consolibyte.com/wiki/doku.php/quickbooks_example_qbxml. 

By far the most confusing part of this task was getting the WSDL description to work. You have to use the WSDL provided by Intuit. Fortunately, the SOAP server module provides a hook_soap_server_wsdl through which you can override the dynamically created WSDL for an endpoint. 

But ... Intuit's WSDL file interacts strangely with soap server. We found that the actual argument structure passed into our resource callback functions was different than what the QWC guide specified. Here is an example of one of our resources callbacks with the correct argument structure for use with SOAP server:
 

function commerce_qb_webconnect($request){

  $return->serverVersionResult = '1.0';

  return $return;

}

The variables come in as a stdClass object with properties matching what the guide examples claim to be separate variables. Also, the resource callbacks must return a single stdClass object with one property with name matching the formula [rpc method name]Result, e.g. serverVersion must have property serverVersionResult.

The Ubercart folks posted a tutorial and some example code for a Quickbooks integration module that does not user services or SOAP server. They have some useful links in their resources section. You better have a version of IE handy though if you want to read the onscreen xml reference though. Intuit loves their Microsoft - do a view source for a good laugh :).

Programmers: if you are interested in learning about integration with Drupal and Quickbooks, please get in touch to compare notes and resources.

Users: Switchback's Quickbooks integration module is on the way for Drupal 7!