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
Un groupe de conversations désigne un ensemble de conversations connexes. Ce type de groupe permet à une application de coordonner facilement les conversations impliquées dans une tâche d'entreprise spécifique.
Chaque conversation appartient à un seul groupe de conversations. Chaque groupe étant associé à un service spécifique, toutes les conversations du groupe sont des conversations en provenance ou à destination du service rattaché. Un groupe de conversations peut contenir un nombre illimité de conversations.
SQL Server utilise des groupes de conversations pour fournir un accès EOIO (Exactly-Once-In-Order) aux messages liés à une tâche métier spécifique. Quand une application envoie ou reçoit un message, SQL Server verrouille le groupe de conversations auquel le message appartient. De cette façon, une seule session à la fois peut recevoir des messages pour le groupe de conversations. Le verrouillage du groupe de conversations garantit qu’une application peut traiter les messages de chaque conversation une seule fois dans l’ordre (EOIO, Exactly-Once-In-Order). Étant donné qu'un groupe de conversations peut contenir plusieurs conversations, l'application se sert des groupes de conversations pour identifier les messages liés à une même tâche afin de les traiter ensemble.
Un groupe de conversation n’est pas partagé entre les participants d’une conversation. Par conséquent, chacun est libre d'associer la conversation en fonction de ses attentes. Une application peut gérer des interactions complexes parmi des services, sans pour autant requérir auprès d'eux une prise en charge spéciale.
Exemples de groupes de conversation
Une application de ressources humaines peut avoir un GetEmployeeInformation service qui combine les informations d’un service de paie et les informations d’un service d’avantages sociaux. Le GetEmployeeInformation service commence une conversation avec chaque service et associe une conversation à l’autre dans le même groupe de conversation. Service Broker ajoute l'identificateur du groupe de conversations à chaque message entrant sur ces deux conversations, que le message provienne du service de la paie ou du service des avantages sociaux. Étant donné que les conversations se trouvent dans le même groupe de conversations, Service Broker fournit toutes les informations nécessaires pour que le GetEmployeeInformation service corresponde aux informations sur les avantages à l’information sur la paie, quel que soit le nombre de demandes en cours dans le GetEmployeeInformation service.
Les messages au service de paie et les messages au service avantages ne contiennent pas d’informations de groupe de conversation pour le groupe de conversation créé par GetEmployeeInformation. Chaque service fonctionne indépendamment, et seul le GetEmployeeInformation service conserve des informations sur l’ensemble de la tâche métier. Le codage et la gestion de chaque service sont facilités en maintenant ces services indépendants l'un de l'autre. Cette caractéristique présente également un avantage puisqu'un service peut continuer de fonctionner tandis que l'autre est indisponible.
Organiser l’état de l’application
L'un des avantages du groupe de conversations réside dans son identificateur, qui se révèle une clé pratique permettant d'identifier et de récupérer l'état de l'application. L'identificateur du groupe de conversations facilite la gestion de l'état de l'application dans la base de données. Si vous effectuez une tâche implique l’échange de nombreux messages au fil du temps, il est inefficace de conserver une instance de l’application en cours d’exécution simplement pour maintenir l’état de l’application. Une application évolue mieux si, entre les messages, toute donnée associée à la tâche est stockée dans la base de données, puis récupérée lorsque le message suivant lié à cette tâche est reçu. L’identificateur du groupe de conversation peut être utilisé comme clé primaire dans une table d’état fournie par un développeur d’applications pour permettre une récupération rapide de l’état associé à une tâche particulière. Pour plus d’informations sur l’utilisation de l’identificateur de groupe de conversation pour maintenir l’état, consultez Gestion de l’état.
Étant donné que SQL Server verrouille le groupe de conversations chaque fois qu’une application envoie ou reçoit un message, une application n’a pas besoin d’empêcher explicitement un autre programme de mettre à jour les mêmes données d’état en même temps. Il lui suffit de verrouiller le groupe de conversations, restaurer l'état, traiter les messages, mettre l'état à jour, puis valider la transaction.
Pour des raisons pratiques, SQL Server permet à une application de verrouiller le prochain groupe de conversations disponible sans recevoir de message. À l’aide de l’instruction GET CONVERSATION GROUP , une application peut verrouiller un groupe de conversations et restaurer l’état avant de traiter les messages. Pour plus d’informations, consultez l’instruction GET CONVERSATION GROUP .
Durée de vie du groupe de conversation
Service Broker gère la durée de vie du groupe de conversation. Vous n’avez pas besoin de créer ou de détruire explicitement un groupe de conversation. Service Broker crée un nouveau groupe de conversations dans les circonstances suivantes :
Une application commence une nouvelle conversation qui n’est pas liée à un groupe de conversation existant. Service Broker crée un nouveau groupe de conversations et attribue un nouvel identificateur à ce groupe.
Une application commence une conversation liée à un identificateur de groupe de conversation qui n’existe pas actuellement. Dans ce cas, Service Broker crée un nouveau groupe de conversations à l'aide de l'identificateur spécifié. Ceci signifie, entre autres, que vous pouvez attribuer la valeur de votre choix à un identificateur de groupe de conversations.
Service Broker reçoit le premier message d'une nouvelle conversation démarrée par un autre service. Dans ce cas, il utilise le nom du service et l'identificateur de l'instance du broker (le cas échéant) pour effectuer les opérations suivantes :
- trouver la file d'attente appropriée ;
- créer un nouveau groupe de conversations pour l'associer à la file d'attente ;
- créer un nouveau handle de conversation pour l'ajouter au nouveau groupe de conversations ;
- placer le message entrant dans la file d'attente.
Service Broker ajoute l'identificateur du groupe de conversations aux métadonnées de la conversation qui a créé le groupe de conversations. Chaque fois que Service Broker reçoit un message pour une conversation connexe au groupe de conversations, il ajoute l'identificateur du groupe de conversations à ce message avant de l'intégrer à la file d'attente.
Un identificateur de groupe de conversations est valide depuis le moment où Service Broker l'a créé jusqu'à la conclusion de toutes les conversations qui lui sont associées. Autrement dit, la validité de l'identificateur du groupe de conversations est garantie tant qu'une conversation demeure active dans le groupe.
Une application qui utilise l'identificateur du groupe de conversations pour gérer son état exploite une table d'états fournie par le développeur. L'application doit supprimer cet état à partir de la table utilisée lorsqu'elle détermine que l'état en question n'est plus nécessaire. Dans de nombreux cas, l’application supprime l’état une fois la tâche terminée correctement, ou après que les erreurs indiquent que la tâche ne peut pas être terminée. Dans ces cas-là, l'application inclut généralement la commande de suppression de l'état dans la transaction qui envoie le dernier message de réponse et conclut la conversation. Cette stratégie permet de garantir une durée de vie identique à l'état de l'application et à l'identificateur du groupe de conversations. Si l'opération d'envoi échoue, l'opération de suppression est annulée. De même, si l’opération de suppression échoue, l’opération d’envoi est rétablie et SQL Server n’envoie pas le message. Dans un cas comme dans l'autre, l'état de l'application et l'identificateur du groupe de conversations demeurent valides. Si les deux opérations se sont déroulées correctement, l'existence de l'identificateur du groupe de conversations s'achève au moment où l'état de l'application qui lui était associé est supprimé par le programme.