Pouvez-vous appeler un webservice à partir du code TSQL ?

StackOverflow https://stackoverflow.com/questions/33449

  •  09-06-2019
  •  | 
  •  

Question

Existe-t-il un moyen d'appeler depuis une procédure stockée ou une fonction TSQL vers un service Web ?

Était-ce utile?

La solution

Oui, vous pouvez créer comme ça

CREATE PROCEDURE CALLWEBSERVICE(@Para1 ,@Para2)
AS
BEGIN
    Declare @Object as Int;
    Declare @ResponseText as Varchar(8000);

    Exec sp_OACreate 'MSXML2.XMLHTTP', @Object OUT;
    Exec sp_OAMethod @Object, 'open', NULL, 'get', 'http://www.webservicex.com/stockquote.asmx/GetQuote?symbol=MSFT','false'
    Exec sp_OAMethod @Object, 'send'
    Exec sp_OAMethod @Object, 'responseText', @ResponseText OUTPUT
    Select @ResponseText
    Exec sp_OADestroy @Object
END

Autres conseils

Bien sûr, tu peut, mais c'est une très mauvaise idée.

Comme les appels de service Web peuvent prendre un temps arbitraire et échouer de manière aléatoire, en fonction du nombre de jeux de contre-attaque joués sur votre réseau à ce moment-là, vous ne pouvez pas dire combien de temps cela va prendre.

Au strict minimum, il faut probablement une demi-seconde au moment où il crée le XML, envoie la requête HTTP au serveur distant, qui doit ensuite analyser le XML et renvoyer une réponse.

  1. Quelle que soit l'application qui a fait le INSERT INTO BLAH La requête qui a provoqué le déclenchement du service Web devra attendre qu'elle se termine.À moins que ce ne soit quelque chose qui se produit uniquement en arrière-plan, comme une tâche planifiée quotidienne, les performances de votre application vont exploser.

  2. Le code appelant le service Web s'exécute dans le serveur SQL et utilise ses ressources.Comme il faudra beaucoup de temps pour attendre la requête HTTP, vous finirez par utiliser beaucoup de ressources, ce qui nuira encore une fois aux performances de votre serveur.

Pas dans le code T-SQL lui-même, mais avec SQL Server 2005 et versions ultérieures, ils ont permis d'écrire des procédures stockées CLR, qui sont essentiellement des fonctions dans le code .NET, puis de les exposer en tant que procédures stockées pour la consommation.Vous avez la plupart du framework .NET à portée de main pour cela, je peux donc voir la consommation d'un service Web possible grâce à cela.

Il est un peu long d'en discuter en détail ici, mais voici un lien vers un Article MSDN sur le sujet.

Je ne ferais pas cela pour un trafic intense ou des tâches critiques, CEPENDANT, si vous n'avez PAS besoin de recevoir des commentaires d'un service, alors c'est en fait une bonne chose à faire.

Voici un exemple de ce que j'ai fait.

  1. Déclencheurs d'insertion et de mise à jour sur une table
  2. Déclencheur appelé Stored Proc qui transmet les données JSON de la transaction à un point de terminaison de l'API Web qui les insère ensuite dans un MongoDB dans AWS.

Ne faites pas de vieux XML

JSON 

EXEC sp_OACreate 'WinHttp.WinHttpRequest.5.1', @Object OUT;
EXEC sp_OAMethod @Object, 'Open', NULL, 'POST', 'http://server/api/method', 'false'
EXEC sp_OAMethod @Object, 'setRequestHeader', null, 'Content-Type', 'application/json'
DECLARE @len INT = len(@requestBody)

Exemple complet :

Alter Procedure yoursprocname

 @WavName varchar(50),
 @Dnis char(4) 

    AS
BEGIN

    SET NOCOUNT ON;


DECLARE @Object INT;
DECLARE @Status INT;


DECLARE @requestBody NVARCHAR(MAX) = '{
"WavName": "{WavName}",
"Dnis": "{Dnis}"
}'


SET @requestBody = REPLACE(@requestBody, '{WavName}', @WavName)
SET @requestBody = REPLACE(@requestBody, '{Dnis}', @Dnis)


EXEC sp_OACreate 'WinHttp.WinHttpRequest.5.1', @Object OUT;
EXEC sp_OAMethod @Object, 'Open', NULL, 'POST',  'http://server/api/method', 'false'
EXEC sp_OAMethod @Object, 'setRequestHeader', null, 'Content-Type', 'application/json'
DECLARE @len INT = len(@requestBody) 
EXEC sp_OAMethod @Object, 'setRequestHeader', null, 'Content-Length', @len
EXEC sp_OAMethod @Object, 'send', null, @requestBody
EXEC sp_OAGetProperty @Object, 'Status', @Status OUT
EXEC sp_OADestroy @Object

Dans les versions antérieures de SQL, vous pouviez utiliser soit un processus stocké étendu, soit xp_cmdshell pour exécuter et appeler un service Web.

Non pas que l’une ou l’autre de ces architectures ressemble à une architecture décente – mais il faut parfois faire des choses folles.

Vous pouvez le faire avec les objets VB intégrés.

Vous créez d’abord un objet VB de type « MSXML2.XMLHttp » et vous utilisez cet objet pour toutes vos requêtes (si vous le recréez à chaque fois, attendez-vous à une lourde pénalité de performances).

Ensuite, vous introduisez cet objet, certains paramètres, dans une procédure stockée qui appelle sp_OAMethod sur l'objet.

Désolé pour l'exemple imprécis, mais une recherche rapide sur Google devrait révéler comment la méthode vb-script est effectuée.

--

Mais la version CLR est bien... BEAUCOUP plus simple.Le problème avec l’appel de services Web est qu’ils ne peuvent pas suivre le rythme du moteur de base de données.Vous obtiendrez de nombreuses erreurs qui ne pourront tout simplement pas suivre.

Et rappelez-vous, les SERVICES Web nécessitent à chaque fois une nouvelle connexion.La multiplicité entre en jeu.Vous ne voulez pas ouvrir 5 000 connexions socket pour traiter un appel de fonction sur une table.C'est fou !

Dans ce cas, vous devrez créer une fonction d'agrégation personnalisée et utiliser CELA comme argument à transmettre à votre service Web, ce qui renverra un ensemble de résultats... vous devrez ensuite le rassembler.C'est vraiment une façon délicate d'obtenir des données.

Si vous travaillez avec des niveaux de compatibilité SQL 2000 et que vous ne parvenez pas à effectuer l'intégration Clr, consultez http://www.vishalseth.com/post/2009/12/22/Call-a-webservice-from-TSQL-(Stored-Procedure)-using-MSXML.aspx

J'ai travaillé pour de grandes entreprises mondiales à travers le monde, en utilisant des bases de données Oracle.Nous consommons des services Web à tout moment via DB avec des procédures de magasin et aucun problème, même ceux à fort trafic.Tous à usage interne, je veux dire sans accès à Internet, uniquement à l’intérieur de l’usine.Je recommanderais de l'utiliser, mais en faisant très attention à la façon dont vous le concevez

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top