2010-05-16 7 views
0

Je travaille sur un projet .NET qui utilise Microsoft SQL Server. Dans ce projet, j'ai besoin d'une procédure stockée CLR (écrite en C#) qui utilise un service web distant. Ainsi, lorsque la procédure stockée est exécutée sur le serveur SQL, elle effectue des appels de service Web et envoie donc des paquets à un emplacement distant. Le problème est que lors de l'exécution du SP, je reçois: "System.Net.WebException: La demande a échoué avec le statut HTTP 403: Interdit."Comment configurer les connexions sortantes à partir d'une procédure stockée SQL?

L'utilisateur de la base de données dispose d'une autorisation complète, l'assembly CLR déployé et le SP sont même marqués "non sécurisés", j'ai essayé de le signer etc., donc tout cela ne pose pas le problème.

Lorsque j'exécute le même code C#, mais à partir d'une simple application console au lieu de SP, tout fonctionne correctement. J'ai donc commencé à suspecter un problème lié au réseau et j'avais un renifleur de paquets en cours d'exécution lors de l'exécution du SP et de la version de l'application console. Ce que j'ai réalisé, c'est que les paquets envoyés avaient des adresses IP de destination différentes: l'application console envoyait les paquets directement à l'IP du service Web tandis que le SP envoyait les paquets à un serveur proxy que nous utilisons dans notre société. En raison des politiques de réseau, ce dernier n'est pas autorisé et cela explique l'exception "403 Interdit".

Donc ma question se résume à ceci: Comment puis-je configurer le serveur SP/MS SQL pour ne pas utiliser ce proxy? Je veux qu'il envoie les paquets directement à l'adresse IP du service Web, tout comme l'application de la console de test. (encore une fois, le code C# est le même, donc ce n'est pas une question de programmation).

J'ai désactivé tous les paramètres proxy dans Internet Explorer au cas où le serveur SQL hérite de ces paramètres ou de quelque chose. Cependant, pas de chance.

Toute aide serait grandement appréciée!

Meilleures salutations, Peter

Répondre

0

L'explication la plus probable est une sorte de proxy transparent au niveau du réseau. Je discuterais du problème avec celui qui gère/administre votre réseau.

2

Ne pas effectuer d'appels Web HTTP à partir de SQL CLR.

Effectuez tous les appels de service Web à partir d'un processus externe. À moins que vous ne souhaitiez que votre serveur de production soit gelé en cas de panne de travail avec tous les threads bloqués dans les événements CLR. Tu étais prévenu.