SQL Server 2016 pour les administrateurs IT

Découvrir Service Broker

Testez gratuitement nos 1325 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Service Broker est un outil d'échange de données asynchrone orienté message. Votre formateur vous en explique le fonctionnement à l'aide d'un exemple.
09:32

Transcription

J'aimerais vous présenter une fonctionnalité d'SQL Server qui s'appelle Service Broker, qui existe depuis longtemps, depuis une dizaine d'années, c'était en 2005, et qui permet d'échanger des informations entre serveurs SQL distants, c'est son principal intérêt. C'est une fonctionnalité qui est peu utilisée, malheureusement, mais je trouvais intéressant de vous la présenter ici, de façon à ce que vous puissiez, au besoin, choisir cette fonctionnalité, si elle correspond à vos attentes. Service Broker, comme son nom l'indique, on est - on était - en 2005, au top de la mode de l'orienté-service, donc ici, on a quelque chose qui est orienté-service. Il s'agit de fabriquer, dans un serveur SQL, des messages sous format XML, principalement, et ensuite de les envoyer à travers un canal TCP, à travers Internet, sur un autre serveur SQL. C'est très pratique si vous avez besoin d'échanger des informations à travers Internet, entre serveurs SQL distants, c'est différent de la réplication parce que la réplication est beaucoup plus connectée, elle échange des informations nativement, alors qu'ici, on va générer des messages d'un côté et les envoyer de l'autre côté. Donc, si vous avez des messages de vente qui sont générés dans des serveurs SQL qui sont disséminés dans le monde entier et vous voulez récupérer au fil de l'eau ces informations sur un serveur centralisé, par exemple, c'est un exemple d'utilisation, Service Broker est une solution très intéressante. Parce qu'elle va permettre de faire des communications asynchrones, par exemple si vous générez 10 000 messages d'un seul coup, sur un serveur, ces messages vont être stockés dans une file d'attente, ils vont pas saturer le réseau et les machines, mais ils vont être placés dans une file d'attente, donc une table SQL, une table système, et puis ils vont être envoyés au fil de l'eau de l'autre côté, à travers un canal TCP, chiffré, ils vont être récupérés de l'autre côté et les messages vont être traités ce qui permet aussi, avec du code, de réagir à ces messages. Je vous montre brièvement comment ça marche parce qu'il y a pas mal d'objets à créer. J'ai déjà activé la plupart de ces objets, mais je vais revenir sur le code pour vous montrer. Déjà, la première chose est d'activer Service Broker sur la base de données. Parce que, pour des raisons de sécurité, c'est une fonctionnalité désactivée. Je suis SysAdmin, je vais dire que j'active le Broker. Je vais dans ma base de données, je peux le faire ici. J'ai créé un schéma spécifique pour y mettre mes objets et puis l'idée, c'est que je vais générer des évaluations, comme il s'agit d'un centre d'information, un PatchaDataFormation, il peut il y avoir des formations qui sont données à l'extérieur, sur site, ce qu'on appelle de l'intra-entreprise, et on voudrait récupérer, par message, les évaluations des participants sur ces sites distants, donc je crée un schéma pour y placer des objets. Je crée une table pour y stocker les évaluations, je vais mettre simplement la date, le participant et la note, et ici, c'est une table qui va recevoir les évaluations qui viennent du serveur distant. Je vais créer ensuite un type de message, CreateMessageType, c'est un type de message, un objet propre à SQL Server et à Service Broker, je vais lui donner un nom sous forme d'URI, donc un nom unique à travers l'Internet, comme on s’envoie des messages sur un réseau hétérogène à travers Internet entre des machines qui ne se connaissent pas, a priori, on donne des noms d'objets qui sont uniques à travers Internet, et pour ça, on a un système approximatif qui s'appelle l'URI, où on commence par le nom du domaine - j'aurais pu mettre « .com » -, de façon à unifier la chose, à l'intérieur du domaine, on va mettre une sorte d'espace de nom « Évaluation » et type de message « Évaluation ». Pourquoi créer un type de message ? Parce que ça va permettre d'identifier le message qu'on envoie et qu'on reçoit, c'est juste un nom, on dit que le message que j'envoie est de tel type, on a pas plus de définition que ça. On peut le valider, mais je ne le valide pas, si c'est du XML on peut faire une validation, mais ça permet que les deux acteurs, celui qui envoie, celui qui reçoit, soient sur la même longueur d'ondes. Je ne le crée pas, parce que je l'ai déjà fait. Je vais créer, ensuite, un contrat. Le contrat, c'est pour dire tel type de message est envoyé par l'initiateur de la conversation et donc, ça permet aux deux acteurs de se mettre d'accord. et on lui donne un nom, sous forme d'URI, comme vous le voyez. Ça aussi, je l'ai fait, je crée une file d'attente CreateQueue, la file d'attente, c'est une table système SQL, dans laquelle les messages vont s'empiler, soit du côté de l'envoi, les messages qu'on va envoyer vont s'empiler dans la file d'attente, la file d'attente va être automatiquement dévidée, petit à petit, par Service Broker pour envoyer les messages, et puis, de l'autre côté, on va avoir une file d'attente de réception, qui va recevoir les messages qui sont transmis à travers Service Broker. Ici, on va faire un système qui est purement local, sur le même serveur et la même base de donnée, mais si vous faites des systèmes distants, vous allez devoir créer également des routes pour dire que pour aller de tel service à tel service, on a tel Socket, Adresse IP + port, de l'autre côté, qui va permettre de générer la conversation distante. Donc, ces files d'attente sont créées, j'ai pas besoin de le faire non plus. Mais je vais créer des services, c'est le nom extérieur ou logique de la file d'attente. La file d'attente, c'est un objet SQL Serveur, vous voyez qu'elle est dans un schéma, c'est une table, mais ça s'appelle une Queue, la différence, c'est que quand on va faire une lecture dans la Queue, ça va enlever la donnée, on va lire et enlever en même temps, et je vais créer un service pour donner un nom visible de l'extérieur, ou un nom logique à ma Queue. Donc, je crée un service sur ceci, je crée un autre service sur ceci, qui peut servir à recevoir une réponse. Service Broker peut, dans une conversation, envoyer un message, ou même envoyer plusieurs messages qui seront envoyés dans l'ordre et qui seront traités de l'autre côté dans l'ordre, mais on peut aussi faire en sorte qu'il y a un message de retour, dans une conversation, pour qu'il y ait une validation ou un Acknowledgment de la part du receveur. Donc, je vais faire une procédure d'envoi, procédure stockée, qui génère le message, sous forme de XML, je génère un format XML pour l'évaluation. Je commence un dialogue de tel service vers tel service, vous voyez que le service local, on le connaît, donc on fait un identifiant, le service distant, on ne le connaît pas, puisque ce n'est pas un objet local à la machine, donc on le met sous forme de chaîne de caractère. Et on va dire, on va faire une conversation, de tel service vers tel service distant, sur tel contrat, on sait quel est le type de message grâce au contrat, on chiffre ou on ne chiffre pas et quelle est la durée de la conversation. On envoie dans la conversation, on dit « j'envoie ce message, qui est de tel type », et puis, au besoin, on termine la conversation pour dire : « c'est fini, », « le message est envoyé et je ne m'en occupe plus ». Ensuite on part en asynchrone, c'est traité par Service Broker sans que le code n'ait plus besoin de s'en occuper. La procédure de réception, c'est de l'autre côté, du côté du serveur distant. On va faire une réception, Receive Top 1, pour dire qu'on va lire dans la file d'attente, on prend le premier message qui vient et on le traite. Et quand on fait un receive, on lit et on efface de la file d'attente. C'est pour ça que je ne l'ai pas fait ici, mais ça vaut vraiment la peine de le mettre dans une transaction explicite, c'est-à-dire, on ferait un Begin Transaction ici, et puis ensuite, à la fin, un Commit Transaction ou un Roll Back, de façon à ce que, si le message n'a pas pu être traité, il reste dans la file d’attente, il y ait une annulation de cette transaction de traitement et qu'on puisse le retraiter ensuite. Et, ce que je fais, simplement, c'est que j'insère, j'extraie de mon XML les données et j'insère dans ma table de réception. Et je termine la conversation, ou je termine la conversation avec une erreur en cas de problème. Lorsque tout ceci est fait, cette deuxième procédure va bien entendu sur le serveur distant, si on faisait quelque chose de distant, ici, on fait une sorte de pseudo-distribué, tout est sur la même base de données, on va modifier la file d'attente de réception, au niveau du serveur distant pour dire « quelle est l'activation ? », l'activation se fait à travers la procédure qu'on vient de voir. L'activation, ça veut dire que lorsque, dans la file d'attente, un message est déposé, ça va déclencher automatiquement l'exécution de cette procédure qui va lire le message. Et puis on va voir combien on peut faire de lectures sur la file d'attente en même temps, on peut avoir plusieurs procédures qui s'exécutent en parallèle. Tout ceci est fait. Je vous montre un test, j'exécute ma procédure d'envoi, j'attends quelques secondes et puis je fais un Select de ma table de réception, il y a dû y avoir un envoi, file d'attente d'envoi, envoi vers la file d'attente de réception, traitement par l'activation et le déclenchement de la procédure stockée, et donc, je devrais en avoir deux parce que j'ai déjà fait un essai avant d’enregistrer, voilà, j'ai bien deux messages et ça a fonctionné. Voilà une petite démo pour vous montrer l'intérêt de cette technologie.

SQL Server 2016 pour les administrateurs IT

Comprenez le fonctionnement et les différents modules qui composent SQL Server. Prenez en main les bases de données, les schémas, les tables, la gestion des fichiers, etc.

5h20 (55 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Spécial abonnés
Date de parution :14 mars 2017

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !