Connect to already open Quickbooks instance via QBXML

Question

I'm trying to help a client who has a web application (ASP/C#) that integrates with Quickbooks via the QBXML SDK.

I want to open up a connection to an already active QuickBooks instance in a user session.

The relevant code in question:

    if (rp == null)
        rp = new RequestProcessor2();

    if (!connected)
    {
        rp.OpenConnection2("IMS", "Internal Management System", QBXMLRPConnectionType.localQBD);
        connected = true;
    }

    if (xticket == null)
        xticket = rp.BeginSession(cfg.qbfile, QBFileMode.qbFileOpenMultiUser);

As is, this will attempt to launch a new instance of Quickbooks via DCOM, which is not a viable option. Following the QBSDK documention, I attempted to pass null to BeginSession's first argument, which should use the open qbw file.

However, instead of the expected action of connecting to the running instance of Quickbooks, it launches a new instance, eventually yielding the error:

"If the QuickBooks company data file is not open, a call to the "BeginSession" method must include the name of the data file."

The IIS AppPool running the web app uses the same user as the Quickbooks instance I'm trying to connect to.

This was all set up by a third party who is no longer available, and, of course, they left no documentation whatsoever on how this system was supposed to work. Any assistance would be welcome.

Answer 1

I managed to create an acceptable workaround to my problem, for anyone trying something similar. (Which, honestly, I don't recommend. I'm working with legacy code here.)

First, a brief overview of my research:

The QBXml interface with QuickBooks uses COM requests in order to communicate. Now, for whatever reason, whether design, bug, or limitation in COM, Quickbooks cannot communicate across LSA Logon Sessions. In practice, this means that the same console session that Quickbooks is running under must also run the QBXml code. Additionally, both Quickbooks and your application must have the same UAC elevation status.

I found no way to get IIS to reliably launch Quickbooks. The individual who setup this system before me managed to do so through some very... unorthodox methods. It was incredibly flaky, and the cause of multiple issues.

Regardless, I did manage an acceptable workaround, in the form of IIS Express. IIS Express can run under a standard user session. As such, running both Quickbooks and the web app (through IIS Express) under the same Logon Session allowed them to communicate successfully.

It is not a permanent solution, as there are drawbacks to running a service such as this in a standard user paradigm, but it is an acceptable workaround, and will allow my client to run their business while we refactor. I plan to first decouple the portions of the app that communicate with Quickbooks, moving them into their own codebase. This will allow the web facing portions of the app to operate in a more standard manner, and communicate with the QB integration code through a more reliable means than COM calls.

Thanks to Keith Palmer for helping point me in the right direction.