This is great great news. To introduce myself, my name is Ryan, and I wrote one of the first PHP apps for integrating w/ the Web Connector using my company's old osCommerce store. We then started to develop Ubercart with the full intention of bringing QBWC support to Ubercart so we can migrate our company. Well... this hasn't happened yet. : )

So... your module is very exciting to me, and I'd love to help out in any way and make sure that Ubercart can export things like customers, products, and invoices (and import things like accounts, vendors, etc.). To that end, I'd like to know if any collaboration will be possible.

If so... please let me know. It'd be nice to know a little more about your design principles. It seems you're just supporting PHP 5. Is that correct? Also, are you developing against a specific version of qbxml or with a specific QuickBooks in mind?

You can either respond through this issue or contact me directly and close this out.

Thanks for your work!

Comments

allie micka’s picture

Hi Ryan,

At this point it's fairly preliminary and a bit philosophical. Like most everything I write, it's strictly API and communications interface.

* The QB module basically just parses the requests and responses to/from QBXML. You send it an array ( e.g. a search query or an update request ) and it bakes the XML. Because the XML structure for QBXML is pretty basic ( mostly elements, few attributes ) I wrote a simplistic array-to-qbxml generator.

The QB module might also include additional setting that are pertinent to Quickbooks / Drupal as a whole, including views integration, etc.

Once you have QBXML, you need to feed it to Quickbooks somehow. This work is all based on work I've done over the years to access Quickbooks directly via COM on a Windows box. Naturally, that's not going to work! RDS seems dead in the water, and Intuit is parading around their Web Connector. So QBWC it is!

The Web Connector works by installing a settings file ( a QWC file ) onto your quickbooks machine. This settings file indicates a URL where your web service(s) are hosted, and how often to hit that URL ( think cron.php ). So, writing a QB web service means hosting a QBXML-aware application on your site. One that receives QBXML and returns QBXML.

I expect you understand all this, Ryan, but this is all in the interest of catching up. Note that I haven't mentioned anything about any products, users, payments, or anything else. I'm just focussing on what it takes to listen for requests and return responses and understand QBXML. It shouldn't be the API's job to enforce any further business rules. If I did that, I'd be stressing about syncing and maintaining relationships to some other module (Ubercart, for example) and this functionality wouldn't be available for support / contribution by other modules (e.g. Pay ). Since I'm syncing with LDAP, Drupal's just an intermediary anyway.

So, In the settings page, you will be able to set security, credentials and other user-specific information, and then download the QWC file that tells your Quickbooks machine where to look and how often. That's it!

When requests come in, QBWC authenticates and then calls hook_qbwc_request and hook_qbwc_response . Hopefully, this is flexible enough to allow module(s) to provide and respond to quickbooks queries. For the request hook, your module will return an array that is baked into QBXML and returned. For the response hook, your module returns a numeric value from 1-100 that indicates percent complete.

Right, so that's the basic framework. Drupal is an intermediary for me - I have customer information in LDAP and usage information in PostgreSQL and time tracking information elsewhere; so it's important that I can leave this flexible instead of wearing someone else's straight jacket.

However, one module I may plan on shipping with this is a user sync module, perhaps mapping profile and/or bio fields to QB fields via Token. I could see how this would be a useful centerpiece for any/all QB-using modules. Maybe that's a good place to start?