QuickBooks SDK, using Perl, works in command console, not as CGI?

Question

I'm using the QBXML method to communicate with QuickBooks on a local machine (not remotely, not using web connector).

I have a very basic script which just connects to QuickBooks and checks to see if a Customer exists or not. The script works perfectly when run through the command console (Windows XP) but the same exact script, no changes, doesn't work when run as a CGI.

When run as a CGI, the script does not get a response XML from QuickBooks. Everything else seems to function exactly the same - just no XML response received from QuickBooks.

I was banging my head against a wall for 2 hours last night trying to figure it out... no success.

Answer 1

In general, when something works on the commandline, but not in another environment it means you are missing environment variables or have a permissions problem.

You can diagnose the environment variables by saying

#!/usr/bin/perl

print "Content-type: text/plain\n\n"
print "$_ => $ENV{$_}\n" for keys %ENV;

on both the commandline and through CGI.

Answer 2

It turns out it wasn't the code or the environment, it seems that for this particular situation (QB SDK, OLE/XML) the ability to get a response XML from QuickBooks when running under Apache as a service was the problem. Apache running via console worked. Of course, that's not workable as I need it to run as a service so I'll be using Abyss Web Server instead, which it worked fine under.

Answer 3

QuickBooks desktop SDK connections are rejected when called from a service. This is a deliberate restriction imposed by intuit, but the reasons have never been disclosed to my knowledge. The application must run in the context of an interactive logged in user to establish the connection. I'm not sure why the Abyss Web Server worked, is it running under an account associate with and interact login?

It used to be possible to open an SDK connection from a service, but the account restriction appeared several years ago with no fanfare or explanation. There is a way around this problem: you can use DCOM to launch the SDK requestor as a separate process, then use DCOM configuration to assign an appropriate account to the DCOM process. You can find details on how to do this in the SDK documentation and the Intuit forums.

Answer 4

Paul, it turned out Abyss had the same issue, I had thought when it initially installed that it was running as a service. On reboot, same issue as Apache. In any case, I also noticed a lot of instability when making changes to the QB file when QB wasn't running & didn't have the file open. Not the best setup but for now the most important thing is that what I was working on works, finally, without odd behaviors or errors. So the conclusion is:

• If doing QB SDK stuff via web services, at least if the web server is running on the same system as QB, the web server has to be run from the command (as a console app) and not a service.

• It's best not to allow the integrated application to make changes to QB files when they're closed & QB isn't running. This one is more annoying but for now I'm just gonna go with what works.

• I'll skip the DCOM workaround for now, not familiar with doing that via Perl.

I just wish the QB processing were faster. On a 1.6GHz netbook for testing it takes anywhere from 6-20 seconds to do minimal processing. Still, the speed gotten from being able to automate loads of stuff more than makes up for the processing slowness.