Réception de notifications
De nombreuses applications ne nécessitent aucun code afin de pouvoir recevoir ou traiter des notifications portant sur des requêtes. Si l'abonnement aux notifications est géré par un objet SqlDependency, ce dernier effectue automatiquement le suivi de l'abonnement. Lorsqu'un message de notification arrive, l'objet SqlDependency lance un appel au gestionnaire d'événements enregistré dans l'objet SqlDependency. Grâce à cette approche, aucun travail particulier n'est requis afin de pouvoir recevoir la notification. Une application utilisant SqlDependency n'a ainsi pas besoin de recevoir ni de traiter les messages de notification.
À l'opposé, si l'application utilise une demande de notification, elle doit effectuer le suivi de la file d'attente et réagir en conséquence au message de notification. Dans ce cas, vous devez développer une application chargée de traiter les messages du service recevant les notifications. Il se peut que l'application demandant la notification soit celle également chargée de traiter le message, à moins que vous optiez pour développer une application distincte pour recevoir et réagir au message de notification de la requête.
SQL Server conserve une trace des abonnements aux notifications en combinant les identificateurs de notification et la requête même transmise. Si une application demande une notification pour deux requêtes différentes utilisant le même ID de notification, SQL Server crée alors deux abonnements portant le même ID de notification. Ceci étant dit, si une application demande une notification pour la même requête avec le même ID de notification à deux reprises, SQL Server crée alors un seul abonnement avec le délai d'attente indiqué dans la deuxième demande.
Les applications s'exécutant dans la base de données sont généralement des procédures stockées activées par la file d'attente lorsqu'un message arrive. Ces procédures stockées peuvent aussi bien être écrites en Transact-SQL qu'en un langage de programmation .NET. Des approches moins courantes consistent à exécuter l'application en tant que tâche planifiée ou en utilisant une tâche au démarrage du système afin d'exécuter une procédure stockée de façon continue en arrière-plan.
Les applications s'exécutant hors de la base de données utilisent généralement une des approches suivantes pour recevoir les messages :
L'application peut interroger régulièrement la file d'attente afin de savoir si un message est arrivé.
Elle peut utiliser la clause WAITFOR de l'instruction RECEIVE afin de bloquer l'exécution d'un traitement ou d'une procédure stockée portant sur une instruction RECEIVE jusqu'à ce que cette dernière renvoie au moins une ligne.
L'application peut créer une notification pour l'événement QUEUE_ACTIVATION de la file d'attente chargée de recevoir la notification. Elle peut ainsi suivre l'état du service recevant l'événement d'activation par le biais d'une des deux stratégies précédemment citées.
Des approches moins courantes permettent d'inclure l'activation du suivi de la file d'attente via WMI ou l'écriture d'une procédure stockée s'appuyant sur le CLR (Common Language Runtime) qui prend des mesures externes en réponse à un message.
Comme les dialogues de notification de requêtes contiennent toujours un seul message de notification, une application traitant les notifications de requêtes doit mettre fin à la conversation après la réception d'un message. Dans le cas contraire, le dialogue finit par dépasser le délai d'attente imparti. Si tel est le cas, SQL Server consigne une erreur de dépassement de délai d'attente dans le journal des erreurs de SQL Server.
Pour plus d'informations sur l'écriture d'une application utilisant Service Broker, consultez Avantages de la programmation avec Service Broker. Pour plus d'informations sur le démarrage d'une application utilisant Service Broker, consultez Choix d'une stratégie de démarrage.