QBXML メソッドを使用して、ローカル マシン上の QuickBooks と通信しています (リモートではなく、Web コネクタを使用していません)。
QuickBooks に接続して Customer が存在するかどうかを確認するだけの非常に基本的なスクリプトがあります。このスクリプトは、コマンド コンソール (Windows XP) を介して実行すると完全に機能しますが、CGI として実行すると、まったく同じスクリプト (変更なし) は機能しません。
CGI として実行すると、スクリプトは QuickBooks から応答 XML を取得しません。他のすべてはまったく同じように機能しているように見えます.QuickBooksからXML応答を受信していないだけです.
昨夜、頭を壁に2時間ぶつけていましたが、それを理解しようとしました...成功しませんでした.
一般に、何かがコマンドラインでは機能するが、別の環境では機能しない場合は、環境変数がないか、権限の問題があることを意味します。
次のように言って環境変数を診断できます
#!/usr/bin/perl
print "Content-type: text/plain\n\n"
print "$_ => $ENV{$_}\n" for keys %ENV;
コマンドラインと CGI の両方で。
サービスから呼び出されると、QuickBooks デスクトップ SDK 接続が拒否されます。これは直感による意図的な制限ですが、その理由は私の知る限り明らかにされていません。接続を確立するには、対話型のログイン ユーザーのコンテキストでアプリケーションを実行する必要があります。Abyss Web Server が機能した理由がわかりません。ログインに関連付けられたアカウントで実行されているのですか?
以前は、サービスから SDK 接続を開くことができましたが、数年前にアカウント制限が登場し、ファンファーレや説明はありませんでした。この問題を回避する方法があります。DCOM を使用して SDK リクエスターを別のプロセスとして起動し、DCOM 構成を使用して適切なアカウントを DCOM プロセスに割り当てることができます。これを行う方法の詳細については、SDK ドキュメントと Intuit フォーラムを参照してください。
コードや環境ではなかったことが判明しました。この特定の状況 (QB SDK、OLE/XML) では、Apache をサービスとして実行しているときに QuickBooks から応答 XML を取得する機能が問題だったようです。コンソール経由で実行されているApacheは機能しました。もちろん、サービスとして実行する必要があるため、これは機能しません。代わりに、問題なく動作する Abyss Web Server を使用します。
ポール、Abyss にも同じ問題があることが判明しました。最初にインストールしたとき、サービスとして実行されていると思っていました。再起動すると、Apache と同じ問題が発生します。いずれにせよ、QB が実行されておらず、ファイルが開かれていないときに QB ファイルに変更を加えると、多くの不安定性にも気付きました。最適なセットアップではありませんが、今のところ最も重要なことは、私が取り組んでいたものが最終的に奇妙な動作やエラーなしで機能することです. したがって、結論は次のとおりです。
Web サービス経由で QB SDK を実行する場合、少なくとも Web サーバーが QB と同じシステムで実行されている場合、Web サーバーはサービスではなくコマンドから (コンソール アプリとして) 実行する必要があります。
QB ファイルが閉じられていて QB が実行されていない場合は、統合アプリケーションが QB ファイルを変更できないようにすることをお勧めします。これはもっと厄介ですが、今のところ、うまくいくものを使います。
Perl 経由での回避策に慣れていないので、今のところ DCOM の回避策はスキップします。
QB の処理がもっと速くなればいいのにと思います。テスト用の 1.6 GHz ネットブックでは、最小限の処理を実行するのに 6 ～ 20 秒かかります。それでも、処理の遅さを補う以上に、多くのものを自動化できることから得られる速度.