9

from my research it looks like there are basically 3 options.

1: Using COM
2: Using A Webservice and the web connector
3: Using a 3rd party component (and there appears to be quite a few)

Each of these options present a problem for me:
1: I was told I cant use COM
2: This solution seems very hokey to me since I am needing to integrate from a windows service
3: Some of these solutions are rather expensive.

I looks like I am going to have to go the 3rd party route and there are two front runners in my mind:

1: QODBC (http://www.qodbc.com/usa.html)
2: AccessBooks (http://www.synergration.com/AccessBooksUpdater/default.aspx)

My questions, dear reader, are as follows:

1: Which solution (com, web service, which 3rd party) would you use?
2: Why would you choose it over the other options?
3: Is there some other option that I have missed?

iamkrillin
  • 6,798
  • 1
  • 24
  • 51
  • 1
    For a windows service, COM interop seems like the best solution out of those. – Chris Marisic Aug 16 '11 at 19:30
  • Despite the fact that it can be a little messy, what's wrong with using COM? – JP Richardson Aug 16 '11 at 19:51
  • @JP, We'll call it a business requirement – iamkrillin Aug 16 '11 at 20:01
  • 1
    I don't believe the requirement is flawed, as developers we make decisions every day about which technologies we incorporate into the software we write. Sometimes those decisions are based on money, sometimes they are based on other factors (productivity gains, not wanting to deal with a particular technology, etc). – iamkrillin Aug 16 '11 at 20:27
  • Thanks for your input guys. I'm going to evaluate futher – iamkrillin Aug 16 '11 at 22:03

4 Answers4

8

I used the Quickbooks SDK because I was developing a import tool for a friend and we didn't have the luxury of buying a 3rd party library.

I started developing it as a web service, but I had to fall back after realizing that, not only does we need to deploy the redistribuable of the Quickbooks SDK on the server, but we also needed Quickbooks itself to be installed. And more often than never, Quickbooks displayed a dialog, which on a server is bad.

As long as that dialog was open, Quickbooks SDK would refuse any connection to it.

I ended up doing it as a pure C# Winform application. From there, its rather strait-forward.

At the heart of the program was a quickbook session class that handled the session and the message

public static class Quickbooks
{
    public static QuickbookSession CreateSession()
    {
        return new QuickbookSession();
    }
}

public class QuickbookSession : IDisposable
{
    /// <summary>
    /// Initializes a new instance of the <see cref="QuickbookSession"/> class.
    /// </summary>
    internal QuickbookSession()
    {
        this.SessionManager = new QBSessionManager();

        this.SessionManager.OpenConnection2(
            ConfigurationManager.AppSettings["QuickbooksApplicationId"],
            ConfigurationManager.AppSettings["QuickbooksApplicationName"],
            Utils.GetEnumValue<ENConnectionType>(ConfigurationManager.AppSettings["QuickbooksConnectionType"]));

        var file = Quickbook.QuickbookDatabaseFilePath;
        if (string.IsNullOrEmpty(file))
        {
            file = ConfigurationManager.AppSettings["QuickbooksDatabaseLocalPath"];
        }

        this.SessionManager.BeginSession(file, Utils.GetEnumValue<ENOpenMode>(ConfigurationManager.AppSettings["QuickbooksSessionOpenMode"]));
    }

    /// <summary>
    /// Gets the Quickbook session manager that is owning this message.
    /// </summary>
    public QBSessionManager SessionManager { get; private set; }

    public QuickbookMessage CreateMessage()
    {
        return new QuickbookMessage(this.SessionManager);
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            // get rid of managed resources
        }

        this.SessionManager.EndSession();
        this.SessionManager.CloseConnection();

        System.Runtime.InteropServices.Marshal.ReleaseComObject(this.SessionManager);
    }
}

After that, it was simple a matter of creating a session, creating a message and appending the different query.

using(var session = Quickbooks.CreateSession())
{
    // Check if the job already exist
    using (var message = session.CreateMessage())
    {
        var jobQuery = message.AppendCustomerQueryRq();
        jobQuery.ORCustomerListQuery.CustomerListFilter.ORNameFilter.NameFilter.Name.SetValue("something");
        jobQuery.ORCustomerListQuery.CustomerListFilter.ORNameFilter.NameFilter.MatchCriterion.SetValue(ENMatchCriterion.mcContains);

        var result = message.Send();

        // do stuff here with the result
    }
}

This code is far from being bullet proof from the many pitfall of Quickbooks. The Quickbooks SDK is also rather slow. For example, retrieving the list of supplier takes about 2 minutes for about 1000 suppliers.

Pierre-Alain Vigeant
  • 22,635
  • 8
  • 65
  • 101
  • 1
    If the integration is on the same company file, or the file is already configured to accept integration with you app's signature, then dialogs should not be showing. As long as the file is configured with always-allow. – xanadont Nov 06 '11 at 02:20
  • There are so many reason why Quickbooks could display a dialog other than the Authorized Application dialog. – Pierre-Alain Vigeant Jan 16 '14 at 18:49
5

I have decided to go with another product not mentioned above called "QuickBooks ADO.NET Data Provider" it is apparently made by the same folks who make the QuickBooks integrator product

The reasons I chose it...

1) It has a remote access component
You install the remote server, and you can access your QuickBooks data from anywhere on your network

2) The remote access component can run as a service
Nuff said

3) Provides a SQL style interface to the QuickBooks data
4) Does some auto magic caching to speed up the data access

iamkrillin
  • 6,798
  • 1
  • 24
  • 51
  • 1
    If avoiding COM is a hard requirement then, I hate to tell you, but nearly every method you use to automate QB will break the requirement. QB's API *is* COM and no matter what abstraction you use it will ultimately be on top of a layer of COM. That said, this doesn't apply to im/exporting of IIF files. – xanadont Nov 06 '11 at 02:17
  • This i realize, the requirement was that we didnt mess with COM so as long as it was hidden all is well – iamkrillin Nov 07 '11 at 17:39
2

I used the QuickBooks integrator from nSoftware on a project that I was on. It is way easier than using the QuickBooks SDK and the support is great. That product has been around for around 8 years.

http://www.nsoftware.com/ibiz/quickbooks/

Greg Finzer
  • 6,714
  • 21
  • 80
  • 125
  • Do you by chance know off hand if you can run the remote connector as a service? Did you need to have the sync available all the time? If so, how did you work around the connector component? – iamkrillin Aug 17 '11 at 01:26
  • When I used it a while ago, it almost felt like opening a database connection. You would add a customer, then the products, and then the invoice for the customer and then the lines on the invoice and then close the connection. – Greg Finzer Aug 22 '11 at 18:58
1

While I am sure there are some cases in which it will not work, my first direction of attack would be the Quickbooks SDK found at the Intuit developer center.

Gregory A Beamer
  • 16,870
  • 3
  • 25
  • 32
  • The intuit developer center is where I done my research: they present a COM interface and the web service connector, they also list a variety of 3rd party components. – iamkrillin Aug 16 '11 at 19:24