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 Server
Azure SQL Managed Instance
SQL Server Service Broker fournit une prise en charge native de la messagerie et de la mise en file d’attente dans le Moteur de base de données SQL Server et Azure SQL Managed Instance. Les développeurs peuvent créer plus facilement des applications perfectionnées qui utilisent les composants de Moteur de base de données pour la communication entre des bases de données disparates, et créer des applications fiables et distribuées.
Quand utiliser Service Broker ?
Utilisez les composants de Service Broker pour implémenter des fonctionnalités natives de traitement des messages asynchrones dans la base de données. Les développeurs d'applications qui utilisent Service Broker peuvent distribuer les charges de données sur plusieurs bases de données sans développer des mécanismes de messagerie et de communication complexes. Service Broker réduit le travail de développement et de test car Service Broker gère les chemins de communication dans le contexte d’une conversation. Les performances sont aussi meilleures. Par exemple, les bases de données front-end prenant en charge des sites Web peuvent enregistrer des informations et envoyer les tâches gourmandes en traitement dans une file d’attente des bases de données back-end. Service Broker garantit que toutes les tâches sont gérées dans le contexte des transactions afin d’assurer une fiabilité et une cohérence techniques.
Vue d’ensemble
Service Broker est un framework de remise de message qui vous permet de créer des applications natives orientées service dans la base de données. Contrairement aux fonctionnalités classiques de traitement des requêtes qui lisent constamment les données des tables et les traitent pendant le cycle de vie des requêtes, les applications orientées service ont des services de base de données qui échangent les messages. Chaque service a une file d’attente où les messages sont placés jusqu’à ce qu’ils soient traités.
Les messages dans les files d’attente peuvent être récupérés à l’aide de la commande Transact-SQL RECEIVE , ou par la procédure d’activation appelée chaque fois que le message arrive dans la file d’attente.
Créer des services
Note
Un service cible doit exposer un ou plusieurs contrats. Si vous créez un service sans contrat, il ne pourra pas recevoir de messages. Les messages envoyés semblent réussir, mais les messages restent sur le sys.transmission_queue de l’initiateur .
/*
In this example, the initiator must then use ON CONTRACT [DEFAULT] and a MESSAGE TYPE [DEFAULT]. [DEFAULT] is a delimited identifier for the built‑in contract and isn't a T‑SQL keyword, so it must be bracketed or quoted.
*/
CREATE QUEUE dbo.ExpenseQueue;
GO
CREATE SERVICE ExpensesService
ON QUEUE dbo.ExpenseQueue ([DEFAULT]);
Envoyer des messages
Les messages sont envoyés sur la conversation entre les services à l’aide de l’instruction SEND Transact-SQL. Une conversation est un canal de communication établi entre les services à l’aide de l’instruction Transact-SQL BEGIN DIALOG.
-- Begin a dialog
DECLARE @dialog_handle AS UNIQUEIDENTIFIER;
BEGIN DIALOG @dialog_handle
FROM SERVICE ExpensesClient
TO SERVICE N'ExpensesService'
ON CONTRACT [DEFAULT];
-- Send a message
SEND ON CONVERSATION (@dialog_handle)
MESSAGE TYPE [DEFAULT] (N'<Expense ExpenseId="1" Amount="123.45" Currency="USD"/>');
Le message est envoyé à ExpensesService et placé dans dbo.ExpenseQueue. Étant donné qu’aucune procédure d’activation n’est associée à cette file d’attente, le message reste dans la file d’attente jusqu’à ce que quelqu’un le lise.
Traiter les messages
Les messages placés dans la file d’attente peuvent être sélectionnés à l’aide d’une requête SELECT standard. L’instruction SELECT ne modifie pas la file d’attente et supprime les messages. Pour lire et extraire les messages de la file d’attente, vous pouvez utiliser l’instruction RECEIVE Transact-SQL.
RECEIVE TOP (1)
conversation_handle,
message_type_name,
TRY_CAST (message_body AS NVARCHAR (MAX)) AS message_body_text
FROM dbo.ExpenseQueue;
GO
Une fois que vous avez traité tous les messages de la file d’attente, vous devez fermer la conversation à l’aide de l’instruction END CONVERSATION Transact-SQL.
-- Drain any remaining target conversations for the from the queue
DECLARE @conversation_hdl AS UNIQUEIDENTIFIER;
WHILE EXISTS (SELECT 1 FROM dbo.ExpenseQueue)
BEGIN
RECEIVE TOP (1) @conversation_hdl = conversation_handle FROM dbo.ExpenseQueue;
END CONVERSATION @conversation_hdl;
END
GO
Documentation de Service Broker
Pour plus d’informations sur Service Broker, consultez :
-
Instructions du langage de définition de données pour les instructions
CREATE,ALTERetDROP - instructions Transact-SQL
- Affichages catalogue relatifs à Service Broker (Transact-SQL)
- Vues de gestion dynamique liées à Service Broker (Transact-SQL)
- utilitaire ssbdiagnose (Service Broker)
Vous pouvez également consulter la documentation publiée précédemment pour les concepts de Service Broker et pour les tâches de développement et de gestion.
Nouveautés dans Service Broker
Service Broker et Azure SQL Managed Instance
L’échange de messages Service Broker entre instances d’Azure SQL Managed Instance et l’échange de messages entre SQL Server et Azure SQL Managed Instance sont actuellement en préversion publique :
-
CREATE ROUTE:le port spécifié doit être 4022. Voir CREATE ROUTE (Transact-SQL). -
ALTER ROUTE:le port spécifié doit être 4022. Voir ALTER ROUTE (Transact-SQL).
La sécurité du transport est prise en charge, tandis que la sécurité des dialogues n’est pas :
-
CREATE REMOTE SERVICE BINDINGn’est pas pris en charge.
Service Broker est activé par défaut et ne peut pas être désactivé. Les options suivantes ALTER DATABASE ne sont pas prises en charge :
ENABLE_BROKERDISABLE_BROKER
Aucune modification importante n’a été introduite dans SQL Server 2019 (15.x). Les modifications suivantes ont été introduites dans SQL Server 2012 (11.x).
Les messages peuvent être envoyés à des services cibles (multidiffusion).
La syntaxe de l’instruction SEND a été étendue afin de permettre la multidiffusion grâce à la prise en charge de plusieurs descripteurs de conversation.
Les files d’attente indiquent l’heure de mise en file d’attente du message.
Les files d’attente ont une nouvelle colonne, message_enqueue_timequi indique la durée pendant laquelle un message a été dans la file d’attente.
La gestion des messages empoisonnés peut être désactivée
Les instructions CREATE QUEUE et ALTER QUEUE peuvent désormais activer ou désactiver la gestion des messages parasites en ajoutant la clause POISON_MESSAGE_HANDLING (STATUS = ON | OFF). La vue du catalogue sys.service_queues comporte désormais la colonne is_poison_message_handling_enabled pour indiquer si le message poison est activé ou désactivé.
Prise en charge des groupes de disponibilité dans Service Broker
Pour plus d’informations, consultez Service Broker avec les groupes de disponibilité Always On (SQL Server).