2010-09-08 4 views
0

J'utilise la méthode QBXML pour communiquer avec QuickBooks sur une machine locale (pas à distance, n'utilisant pas de connecteur Web).QuickBooks SDK, en utilisant Perl, fonctionne dans la console de commande, pas en tant que CGI?

J'ai un script très basique qui se connecte simplement à QuickBooks et vérifie si un client existe ou non. Le script fonctionne parfaitement lorsqu'il est exécuté via la console de commande (Windows XP) mais le même script exact, sans modification, ne fonctionne pas lorsqu'il est exécuté en tant que CGI. Lorsqu'il est exécuté en tant que CGI, le script n'obtient pas de réponse XML de QuickBooks. Tout le reste semble fonctionner exactement la même chose - juste aucune réponse XML reçue de QuickBooks.

Je me cognais la tête contre un mur pendant 2 heures hier soir en essayant de comprendre ... pas de succès.

+0

Où se trouve le script CGI? Utilisez-vous un serveur Web démarré en tant que service système ou sous votre compte d'utilisateur sur la même machine? –

Répondre

2

En général, lorsque quelque chose fonctionne sur la ligne de commande, mais pas dans un autre environnement, cela signifie que des variables d'environnement sont manquantes ou un problème de permissions.

Vous pouvez diagnostiquer les variables d'environnement en disant

#!/usr/bin/perl 

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

à la fois sur la ligne de commande et par CGI.

+0

Avec une «print» Content-type: texte/plain \ n \ n "" en haut, bien sûr. – mob

+0

@mobrule Merci, je suis vraiment hors de mon jeu aujourd'hui. –

0

Il s'avère que ce n'était pas le code ou l'environnement, il semble que pour cette situation particulière (QB SDK, OLE/XML) la possibilité d'obtenir une réponse XML de QuickBooks sous Apache en tant que service était le problème. Apache fonctionnant via la console a fonctionné. Bien sûr, ce n'est pas réalisable car j'en ai besoin pour fonctionner en tant que service, donc j'utiliserai Abyss Web Server à la place, ce qui a bien fonctionné.

+0

Oui, ou exécutez Apache sous un autre utilisateur, pas SYSTEM, qui par défaut n'a pas accès au réseau. – MkV

0

Les connexions SDK de bureau QuickBooks sont refusées lorsqu'elles sont appelées à partir d'un service. C'est une restriction délibérée imposée par intuition, mais les raisons n'ont jamais été divulguées à ma connaissance. L'application doit s'exécuter dans le contexte d'un utilisateur connecté connecté pour établir la connexion. Je ne sais pas pourquoi le serveur Web Abyss a fonctionné, fonctionne-t-il sous un compte associé et login?

Avant, il était possible d'ouvrir une connexion SDK à partir d'un service, mais la restriction de compte est apparue il y a plusieurs années sans fanfare ni explication. Il existe un moyen de contourner ce problème: vous pouvez utiliser DCOM pour lancer le demandeur SDK en tant que processus distinct, puis utiliser la configuration DCOM pour affecter un compte approprié au processus DCOM. Vous pouvez trouver des détails sur la façon de le faire dans la documentation du SDK et les forums Intuit.

0

Paul, il s'est avéré qu'Abyss avait le même problème, j'avais pensé au départ qu'il fonctionnait comme un service. Au redémarrage, même problème que Apache. En tout cas, j'ai également remarqué beaucoup d'instabilité lors de la modification du fichier QB lorsque QB n'était pas en cours d'exécution & n'avait pas le fichier ouvert. Pas la meilleure configuration mais pour l'instant le plus important est que ce sur quoi je travaillais fonctionne, enfin, sans comportements bizarres ou erreurs. Donc, la conclusion est:

  • Si faire des choses QB SDK via des services Web, au moins si le serveur Web est en cours d'exécution sur le même système que QB, le serveur Web doit être exécuté à partir de la commande (comme une console application) et pas un service.

  • Il est préférable de ne pas autoriser l'application intégrée à apporter des modifications aux fichiers QB lorsqu'ils sont fermés & QB n'est pas en cours d'exécution. Celui-ci est plus ennuyeux mais pour l'instant je vais juste aller avec ce qui fonctionne.

  • Je vais ignorer la solution de contournement DCOM pour l'instant, je ne suis pas habitué à le faire via Perl.

J'aimerais juste que le traitement QB soit plus rapide. Sur un netbook 1,6 GHz pour les tests, il faut de 6 à 20 secondes pour effectuer un traitement minimal. Pourtant, la vitesse obtenue en automatisant beaucoup plus de choses que de compenser la lenteur du traitement.

Questions connexes