Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :
SQL ServerAzure SQL Managed Instance
Cet article décrit les options d’activation de Service Broker.
Service Broker prend en charge une messagerie asynchrone et mise en file d’attente. Étant donné que les conversations peuvent durer des jours, des mois ou des années, nombre d'applications utilisent l'activation pour évoluer dynamiquement. Cette section décrit quelques stratégies courantes de démarrage d’une application qui utilise Service Broker.
Stratégies de démarrage
Les stratégies de démarrage d'une application se décomposent en quatre grandes catégories :
Activation interne
Activation basée sur des événements
Tâche planifiée
Tâche de démarrage
Chaque stratégie d'activation comporte des avantages. Une application peut associer ces différentes stratégies. Par exemple, une application peut utiliser l’activation interne avec un petit nombre de lecteurs de file d’attente la plupart du temps, mais à certains moments de la journée, il peut démarrer davantage de lecteurs de file d’attente.
Activation interne
Avec l’activation interne de Service Broker, un moniteur de file d’attente Service Broker active directement une procédure stockée lorsqu’il est nécessaire. Il s'agit souvent de l'approche la plus simple. En utilisant l’activation directe d’une procédure stockée, vous n’avez pas besoin d’écrire du code supplémentaire dans l’application pour gérer l’activation. Cependant, l’activation interne nécessite que l’application soit écrite sous forme de procédure stockée SQL Server. Avec l'activation interne, vous écrivez l'application de sorte qu'elle se ferme lorsqu'il n'y a plus de messages à traiter.
Activation basée sur des événements
Certaines applications s'exécutent en réponse à un événement spécifique. Par exemple, vous pouvez exécuter une application lorsque l’utilisation du processeur sur l’ordinateur tombe sous un certain niveau, ou vous pouvez exécuter une application de journalisation lorsqu’une nouvelle table est créée.
L’activation externe de Service Broker est un cas spécial d’activation basée sur des événements. Pour l'activation externe, l'application démarre en réponse à l'événement QUEUE_ACTIVATION.
Pour les événements qui peuvent être déclenchés par des notifications d’événements, vous pouvez combiner l’activation basée sur les événements avec l’activation interne de Service Broker. Dans ce cas, vous utilisez l'activation interne sur la file d'attente qui reçoit la notification d'événement. La procédure stockée d'activation reçoit le message de notification et démarre l'application.
Pour d’autres événements, vous pouvez utiliser SQL Server Agent pour démarrer des travaux sur l’ordinateur où SQL Server s’exécute. Vous pouvez écrire une application qui surveille les événements WMI (Windows Management Instrumentation) à partir d'un ordinateur distant. L’application peut démarrer une tâche quand un événement WMI se produit sur l’ordinateur qui exécute SQL Server.
Dans le contexte de l'activation basée sur des événements, une application se ferme en principe lorsqu'il n'y a plus de messages à traiter.
Tâche planifiée
Avec une tâche planifiée, une application est activée suivant une planification définie. Cette stratégie est pratique pour les applications de traitement par lots. Une application qui s'exécute en tant que tâche planifiée peut se fermer lorsqu'il n'y a plus de messages à traiter, ou le programme peut se fermer à un moment précis.
Par exemple, une application qui traite des commandes pour un fournisseur peut stocker les messages dans la journée puis traiter les messages la nuit pour générer une commande unique pour le fournisseur. Dans ce cas, l’application peut utiliser un travail SQL Server Agent pour démarrer l’application à une heure spécifique chaque nuit.
Tâche de démarrage
Certaines applications ne démarrent qu’une fois, généralement quand l’ordinateur démarre ou lors du démarrage de SQL Server. Une procédure stockée de démarrage dans SQL Server, une application dans le groupe de démarrage de Windows ou un service Windows sont des exemples de ces tâches. Dans ce cas, l'application s'exécute sans interruption et traite les messages au fur et à mesure qu'ils arrivent. Une application qui s’exécute en continu ne nécessite pas de temps de démarrage lorsqu’un message arrive dans la file d’attente. Toutefois, étant donné que l’application ne quitte pas lorsqu’il n’y a pas de messages, le programme consomme des ressources même s’il n’y a pas de travail pour le programme.
Cette stratégie peut être utile pour une application qui traite un flux de messages constant et qui consomme une quantité relativement importante de ressources au démarrage.