Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
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 frontales prenant en charge les sites Web peuvent enregistrer des informations et mettre des tâches intensives en file d'attente dans des bases de données principales. 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 Transact-SQL SEND. 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 Transact-SQL RECEIVE.
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 Transact-SQL END CONVERSATION.
-- 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 service Broker
Pour plus d’informations sur Service Broker, consultez :
-
Instructions De langage de définition de données pour
CREATE,ALTERetDROPinstructions - instructionsTransact-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 Manage Instance est 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 pour activer la multidiffusion en prenant en charge plusieurs handles de conversation.
Les files d'attente exposent le temps d'empilement des messages.
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 incohérents peut être désactivée
Les instructions CREATE QUEUE et ALTER QUEUE ont désormais la possibilité d’activer ou de désactiver la gestion des messages incohérents en ajoutant la clause. POISON_MESSAGE_HANDLING (STATUS = ON | OFF) L’affichage sys.service_queues catalogue a maintenant la colonne is_poison_message_handling_enabled pour indiquer si le message incohérent 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).