Service Broker SQL Server 2005 by lpl27890

VIEWS: 0 PAGES: 30

									                                                    Service Broker.
                                                  Utilisation dans SQL
                                                     Server 2005 et
                                                 intégration avec .NET
                                                            2.0




                                               Document

1,     avenue     de   l’Europe
                                               Auteur               Sébastien Pertus
                                               Email                sebastien.pertus@bewise.fr
                                               Web                  www.bewise.fr
Campus 1 – Bâtiment F                          Version              1.0
                                               Nombre de pages      16
                                               Date de création     30/10/2006
31400                  Toulouse



Tél.    05   61   75    13   13



Fax    05    61   75    47   97



Web             www.bewise.fr


SARL au capital de 99.869 € – RCS B421750381 Toulouse – APE 722 Z
                            1 Introduction _______________________________ 4
                            2 Définition et mise en place ____________________ 5
                               2.1 Définition du Service Broker _____________________ 5
                               2.2 Description de l’architecture des composants du Service
                               Broker _________________________________________ 5
                               2.3 Mise en route du Service Broker __________________ 6
                            3 Mise en place de notre architecture _____________ 7
                               3.1 Les messages ________________________________ 7
                                 3.1.1 Création d’un message ________________________________ 7
                                 3.1.2 Stockage des messages créés ___________________________ 8
                                 3.1.3 Modification, suppression d’un message. __________________ 8
                               3.2 Les contrats (Contract) _________________________ 9
                                 3.2.1 Création d’un contrat __________________________________ 9
                                 3.2.2 Stockage des contrats _________________________________ 9
                                 3.2.3 Modification, suppression d’un contrat ___________________ 10
                               3.3 Les files d’attente (Queue) _____________________ 10
                                 3.3.1 Création d’une file d’attente ___________________________ 10
                                 3.3.2 Stockage des files d’attente ___________________________ 10
                                 3.3.3 Requêter une file d’attente ____________________________ 11
                               3.4 Les Services ________________________________ 12
                                 3.4.1 Création d’un Service ________________________________ 12
                                 3.4.2 Stockage des services ________________________________ 13
                               3.5 Conclusion sur l’installation de notre architecture ___ 14
                            4 Utilisation de notre architecture _______________ 15
                               4.1 La conversation______________________________ 15
                                 4.1.1   Création de notre conversation : ________________________         15
                                 4.1.2   Création du message : _______________________________             15
                                 4.1.3   Début de la conversation (SEND) _______________________           15
                                 4.1.4   Débogage : Vérification des files d’attente ________________      16
                                 4.1.5   Réception du message envoyé (RECEIVE) ________________            17

                            5 Scripts à retenir ____________________________ 18
                            6 ServiceBrokerInterface ______________________ 20
                               6.1 Présentation ________________________________ 20
                                 6.1.1 Introduction ________________________________________ 20
                                 6.1.2 A noter ____________________________________________ 20
                               6.2 Le modèle objet _____________________________ 21
                                 6.2.1 Message ___________________________________________ 21
                                 6.2.2 Conversation _______________________________________ 22
                                 6.2.3 Service ____________________________________________ 24
                               6.3 Notre exemple ______________________________ 26
                                 6.3.1 Principe ___________________________________________ 26
                                 6.3.2 Récapitulatif des scénarios possibles _____________________ 26




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                                 6.3.3 Projet Initiateur _____________________________________ 27
                                 6.3.4 Projet Target _______________________________________ 29

                            7 Conclusion ________________________________ 30




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            1 Introduction
                            L'objectif de cet article est de comprendre le fonctionnement du Service Broker,
                            nouveauté introduite avec SQL Serveur 2005. Nous aborderons la mise en place de
                            l’architecture d’un service de messagerie supportée par le service broker

                            Notre exemple se déclinera en trois parties:

                                 1. Mise en place de l’architecture que nous utiliserons.
                                 2. Un traitement purement SQL : Apprendre à utiliser le Service Broker via
                                    une séquence de requêtes.
                                 3. Une application .Net 2.0, de type Windows Forms, qui contiendra une classe
                                    encapsulant tous les appels au service broker.

                            Les différents projets sont réalisés en Visual C#.NET et le Framework 2.0.50727.
                            La base de données utilisée est AdventureWorks, base de données exemple du SDK
                            SQL Server 2005.

                            Note : Pour l’exemple, L’adresse du serveur SQL Serveur 2005, utilisé dans les
                            chaines de connexion, correspondra à une instance locale, du type
                            « (local)\sql2005 »

                            Le code source associé à cet article peut être téléchargé à l’adresse suivante :
                            http://www.bewise.fr/download/articles/codearticle38.zip.




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            2 Définition et mise en place


                            2.1 Définition du Service Broker

                            Microsoft SQL Server 2005 intègre Service Broker, une nouvelle technologie
                            permettant de créer des applications distribuées fiables et évolutives recourant de
                            façon intensive aux bases de données.
                            Le Service Broker fait entièrement parti du moteur de SQL Server 2005.
                            Le principe même du Service Broker, se base sur le système de messages placés en
                            file d’attente.
                            Dans une instance SQL Server unique, Service Broker fournit un modèle de
                            programmation asynchrone solide.

                            D’une manière générale, il est utile d’interagir avec le Service Broker dans 2 cas :

                                 -    Les applications de base de données utilisant la programmation asynchrone
                                      pour raccourcir le temps des réponses et accroître la capacité de traitement
                                      de l'application.
                                 -    Les bases de données souhaitant communiquer entre elles, sans se soucier
                                      des divers problèmes dus aux évènements externes (réseau etc...)




                            2.2 Description de   l’architecture                                            des
                            composants du Service Broker
                            Le service Broker est composé de plusieurs objets de base de données :

                                     Des Messages : Ce sont les messages échangés
                                         o Un message sera défini par son type : XML, String, voir binaire

                                     Un Contrat : un contrat va s’établir entre un initiateur (Initiator) et une
                                      cible (Target), ainsi que le type de message.

                                     Des files d’attente : C’est l’espace de stockage de nos messages, que ce
                                      soit du coté initiateur que coté cible. Cette file d’attente peut être
                                      représentée sous forme de table et peut très bien être requêtée.

                                     Des Services : Ces composants précisent l’architecture généraliste : Ils
                                      définissent les types de message et les conversations ainsi que le stockage
                                      des messages.




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            2.3 Mise en route du Service Broker
                            Le Service Broker SQL Server 2005 est activé par base.
                            Vous avez donc la possibilité, sur une instance 2005, d’activer ou désactiver le
                            servie broker d’une ou plusieurs bases de données.

                            Comment vérifier si le service Broker est actif sur votre base de données ?
                            Utilisez une requête qui vous retourne l’ensemble des informations de votre base.

                            Note : La requête suivante utilise une vue système sys.database. N’hésitez pas à
                            jeter un coup d’œil aux autres résultats qui peut renvoyer cette vue, très utile dans
                            certains cas (le notre par exemple)

                            Vérification du service broker sur la base de données AdventureWorks

                            SELECT is_broker_enabled
                            FROM sys.databases
                            WHERE name = 'AdventureWorks';


                            De base, le service broker est activé sur une nouvelle base de données créée.
                            Par contre, sur la base de données exemple AdventureWorks, celui-ci a été
                            désactivé.
                            Pour activer le service Broker, il faut modifier la base, en passant par une ALTER
                            DATABASE :

                            ALTER DATABASE AdventureWorks SET ENABLE_BROKER



                            A contrario, pour désactiver le service Broker d’une base de données, utilisez la
                            syntaxe :

                            ALTER DATABASE AdventureWorks SET DISABLE_BROKER



                            Note : Pensez à bien fermer toutes les connexions ouvertes à votre base de
                            données lors de votre ALTER DATABASE, sinon votre requête n’arrivera jamais à
                            s’exécuter !




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            3 Mise en place de notre architecture

                            Une fois le service Broker activé, nous allons pouvoir créer notre architecture.
                            La première chose à établir étant les messages qui vont transiter entre l’initiateur
                            et la cible



                            3.1 Les messages
                            Le message est donc la source qui va transiter dans notre conversation.
                            Chaque message possède une identité propre.
                            Il connait la conversation à laquelle il appartient ainsi qu’un numéro de séquence,
                            permettant de l’ordonner dans notre conversation.
                            Le Service Broker utilise ces deux informations pour faire respecter la hiérarchie de
                            passage et l’affectation sur la bonne conversation.
                            Quant au contenu du message, il est bien sur décidé par l’application !
                            Nous avons par contre possibilité de spécifier une validation nécessaire du message
                            (facultatif), qui sera vérifié par le Service Broker, au besoin.

                            Comment est stocké notre message par le Service Broker ? Il est indépendant du
                            type que nous allons spécifier. Il est donc stocké sous la forme la plus permissive :
                            VarBinary(max)




                            3.1.1 Création d’un message
                            CREATE MESSAGE TYPE MonMessage VALIDATION = NONE



                            Les Validations possibles:

                                     NONE : Le message est sans validation.
                                     EMPTY : Le message doit être vide.
                                     WELL_FORMED_XML : Le message doit être au standard XML
                                     VALID_XML WITH SCHEMA COLLECTION schema_collection_name : Le
                                      message doit être au standard XML, et vérifié par un schéma associé


                            Dans notre exemple, nous allons supposer que notre émetteur émet un message
                            qui ne nécessite pas de validation (une simple chaine de caractère) mais que notre
                            cible, en réponse, émettra un message de type XML.

                            CREATE MESSAGE TYPE BewiseMessageEmetteur VALIDATION = NONE
                            CREATE MESSAGE TYPE BewiseMessageReponse VALIDATION = WELL_FORMED_XML




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            3.1.2 Stockage des messages créés
                            SQL Server 2005 stocke les types de messages en interne, et vous avez possibilité
                            de voir ces messages dans votre arborescence :




                            Note : Il existe déjà différents type de messages à votre disposition. Si vous
                            examinez le message DEFAULT (clic droit, voir le script de création) vous
                            obtiendrez :

                            CREATE MESSAGE TYPE [DEFAULT] AUTHORIZATION [dbo] VALIDATION = NONE


                            Soit un message qui ne possède pas de validation mais utilisable uniquement par le
                            schéma dbo.

                            Note : Dans notre cas, ce message existant pourrait très bien remplacer le message
                            de notre initiateur (BewiseMessageEmetteur)

                            Note : Tout message créé sans spécifier d’autorisation, l’autorisation sera affectée
                            automatiquement au créateur du message.



                            3.1.3 Modification, suppression d’un message.
                            Il est possible d’utiliser l’interface de gestion de SQL Server 2005 (clic droit, drop)
                            ou bien passer par des séquences SQL :

                            Comment vérifier l’existence d’un message ?
                            Utiliser la vue sys.service_message_types

                            ALTER MESSAGE TYPE TestMessageAlter VALIDATION = NONE


                            IF EXISTS (SELECT * FROM sys.service_message_types WHERE name = N'
                            TestMessageAlter')
                            DROP MESSAGE TYPE TestMessageAlter




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            3.2 Les contrats (Contract)

                            Un contrat définit les types de messages qu'une application utilise pour accomplir
                            une tâche.
                            Il représente l'accord passé entre deux services qui permet à chaque service
                            d'envoyer des messages d’un type précis, en vue de réaliser une tâche précise.
                            Les définitions de contrats demeurent en permanence dans la base de données où
                            le type est créé.



                            3.2.1 Création d’un contrat
                            Si nous reprenons notre exemple, nous avons donc un contrat qui définit que
                            l’initiateur va envoyer un message de type BewiseMessageEmetteur et que la cible
                            renverra un message de type BewiseMessageReponse

                            CREATE CONTRACT [BewiseContract]
                               (
                                    [BewiseMessageEmetteur] SENT BY initiator,
                                    [BewiseMessageReponse] SENT BY target
                               )




                            3.2.2 Stockage des contrats
                            Comme les messages, SQL Server 2005 stocke les contrats en interne et vous
                            pouvez de la même façon les examiner et les retrouver dans l’arborescence de
                            votre instance :




                            Si on examine le contrat de base, DEFAULT, on retrouve un contrat du type :

                            CREATE CONTRACT [DEFAULT] AUTHORIZATION [dbo]
                               (
                                    [DEFAULT] SENT BY ANY
                                )



                            Ce contrat est permissif et spécifie qu’un message de type DEFAULT, peut (ou pas)
                            être envoyé par l’initiateur ou la cible.




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            3.2.3 Modification, suppression d’un contrat
                            Il est possible d’utiliser l’interface de gestion de SQL Server 2005 (clic droit, drop)
                            ou bien passer par des séquences SQL.

                            Comment vérifier l’existence d’un contrat ?
                            Utiliser la vue sys.service_contracts

                            IF EXISTS (SELECT * FROM sys.service_contracts WHERE name = N'BewiseContract')
                            DROP CONTRACT [BewiseContract]


                            Note : Il est impossible de modifier un contrat. Il est nécessaire de le supprimer de
                            le recréer.




                            3.3 Les files d’attente (Queue)
                            Les files d’attente stockent les messages.
                            Le Service Broker gère les files d'attente et affiche une vue similaire à celle d'une
                            table pour chaque file d'attente.
                            Nous allons donc pouvoir requêter ces files d’attente, ne serait ce que pour des
                            raisons de débogage évident.



                            3.3.1 Création d’une file d’attente
                            Si nous reprenons notre exemple, nous avons deux types de messages, régis par
                            un contrat entre un initiateur et une cible.

                            Nous allons donc créer deux files d’attente, une contenant les messages émis par
                            l’initiateur et une contenant les messages émis par la réponse de la cible :

                            CREATE QUEUE [BewiseTargetQueue]
                            CREATE QUEUE [BewiseInitiatorQueue]




                            La création de votre file d’attente peut être effectuée avec quelques options.
                            Les plus intéressantes à noter sont :

                            STATUS (ON / OFF) : déclare la file d’attente active ou non active.
                            RETENTION (ON / OFF) : Spécifie que la file d’attente doit garder en mémoire les
                            messages tant que la conversation n’est pas terminée (peut affecter les
                            performances)



                            3.3.2 Stockage des files d’attente

                            Comme les messages ou les contrats, les files d’attente sont stockées en interne,
                            vous avez donc possibilité de les visionner dans l’arborescence de votre instance
                            SQL Server 2005 :




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            3.3.3 Requêter une file d’attente
                            Il est parfois nécessaire de requêter une file d’attente, pour vérifier si un message
                            est bien parti, ou arrivé dans la bonne file d’attente.
                            Un simple ordre SELECT devrait nous convenir :

                            Select * from dbo.BewiseTargetQueue


                            On peut noter dans le résultat                du Select,      quelques     colonnes renvoyées,
                            intéressantes :

                            Note : vous allez voir des colonnes de type « service ». Ce point est abordé dans un
                            prochain paragraphe.

                            Nom de la colonne                   Description

                            status                              État du message.
                                                                0= Message reçu
                                                                1= Prêt
                                                                2= Pas encore terminé
                                                                3= Message envoyé conservé

                            queuing_order                       Numéro d'ordre du message dans la file d'attente.

                            conversation_handle                 Descripteur de la conversation dont ce message fait
                                                                partie.

                            message_sequence_number Numéro de                      séquence       du       message   dans   la
                                                    conversation.

                            service_name                        Nom du service auquel la conversation est destinée.

                            service_contract_name               Nom du contrat respecté par la conversation.

                            message_type_name                   Nom du type de message décrivant le message.

                            validation                          Validation utilisée pour le message.
                                                                E= Vide
                                                                N= Aucune
                                                                X= XML

                            message_body                        Contenu du message.

                            message_id                          Identificateur unique du message.




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            3.4 Les Services
                            Ils représentent des points de terminaison adressables pour des conversations.
                            Les messages Service Broker sont envoyés d'un service à l'autre.
                            Un service spécifie une file d'attente pour la conservation des messages et précise
                            les contrats pour lesquels le service peut être la cible.

                            Un Service utilise les Files d'attente pour stocker leurs messages.
                            Un Service envoi un message à un autre service.
                            Un Service ne peut envoyer de messages autres que ceux qui lui sont associés via
                            son contrat.



                            3.4.1 Création d’un Service

                            Dans notre exemple, une conversation, bidirectionnelle, a lieu entre un initiateur et
                            une cible. Il existe un contrat régissant le type de message de chacun.

                            La création des deux services :

                            CREATE SERVICE [BewiseRequestService]
                                    ON QUEUE [BewiseTargetQueue]

                            CREATE SERVICE [BewiseResponseService] ON QUEUE [BewiseInitiatorQueue]
                               (
                                    [BewiseContract]
                               )




                            Le service BewiseRequestService va placer sur la file d’attente BewiseTargetQueue
                            un ensemble de message qui n’ont pas de contrat particulier.


                            Le   service    BewiseResponseService              va placer sur   la file d’attente
                            BewiseInitiatorQueue un ensemble                  de messages régis par le contrat
                            BewiseContract.




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            3.4.2 Stockage des services

                            Comme les messages, les contrats et les files d’attente, les services sont stockés en
                            interne, vous avez donc possibilité de les visionner dans l’arborescence de votre
                            instance SQL Server 2005 :




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            3.5 Conclusion sur l’installation de notre
                            architecture

                            Nous venons de créer et mettre en place l’architecture de notre exemple.
                            Si nous reprenons nos informations sous forme de schéma, nous avons une
                            architecture qui peut être représentée sous la forme :

                            Définition du contrat des messages :




                            Définition des deux services établissant une conversation bidirectionnelle :




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            4 Utilisation de notre architecture

                            Maintenant, notre architecture mise en place, nous allons pouvoir utiliser, via nos
                            deux services, notre messagerie, via une conversation que nous allons créer.




                            4.1 La conversation
                            Lors de l’utilisation de notre architecture, nous allons créer une conversation.
                            La conversation n’est pas un objet géré dans SQL Server 2005, ce n’est qu’un
                            concept.
                            La conversation va représenter l’ensemble des messages, régis par un contrat,
                            échangés entre deux services, du premier message ouvrant la conversation,
                            jusqu’au dernier message clôturant la conversation.
                            La conversation peut être donc représentée sous la forme d’un Guid,
                            (uniqueidentifier)



                            4.1.1 Création de notre conversation :
                            DECLARE @conversationHandle uniqueidentifier


                            Nous n’attribuons pas de valeur à notre variable @conversationHandle, celle-ci sera
                            obtenu et affecté par SQL Server 2005 dans une prochaine instruction.



                            4.1.2 Création du message :
                            Comme précisé précédemment, le message stocké l’est sous la forme VarBinary. Il
                            est donc utile d’entreprendre un cas sur celui-ci.
                            Le type de message sera de type BewiseMessageEmetteur, qui ne possède pas de
                            validation particulière (VALIDATION = NONE)

                            Declare @msg varbinary(max)
                            Set @msg = cast('Hello World' as varbinary)




                            4.1.3 Début de la conversation (SEND)
                            Il ne reste plus qu’à débuter la conversation.
                            Cette instruction va devoir regrouper tous les éléments nécessaires à la
                            conversation, comme

                                     Le Handle de la conversation
                                     Le service émetteur
                                     Le nom du service cible
                                     Le contrat régissant les messages
                                     Les options (encryptions, timeout etc …)




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            BEGIN DIALOG @conversationHandle
                                    FROM SERVICE    [BewiseResponseService]
                                    TO SERVICE      'BewiseRequestService'
                                    ON CONTRACT     [BewiseContract]
                                    WITH ENCRYPTION = OFF, LIFETIME = 600;



                            Note : Pourquoi le service cible est-il une chaine de caractère et le service
                            émetteur, le véritable nom ?
                            La conversation est lancée depuis la machine émettrice, qui connait forcément le
                            service émetteur. Par contre le service cible n’est pas forcément la même machine,
                            voir la même instance SQL Server 2005.
                            Il est donc normal de passer une chaine de caractère.

                            Une fois la conversation lancée, il ne reste plus qu’à faire partir notre message,
                            avec une instruction de type SEND

                            SEND ON CONVERSATION @conversationHandle
                               MESSAGE TYPE [BewiseMessageEmetteur] (@msg)


                            La création d’une conversation doit forcément être encapsulé dans une transaction.
                            Il est de donc de bon aloi de débuter tout ceci par un

                            Begin Transaction


                            Et finir par un

                            Commit Transaction




                            4.1.4 Débogage : Vérification des files d’attente
                            Notre message est parti sur la file d’attente. Nous pouvons vérifier le contenu des
                            files d’attente :

                            Examinons la file d'attente cible pour vérifier que le message a bien été envoyé.
                            Puis récupération de ce message (n’oubliez pas de re-caster le VarBinary)

                            select * from [BewiseTargetQueue]

                            select cast(message_body as varchar(MAX)) from [BewiseTargetQueue]


                            Resultat : Hello World

                            Notre file d’attente cible contient bien le message envoyé par
                            l’émetteur

                            Examinons la file d’attente de l’initiateur :

                            select * from [BewiseInitiatorQueue]


                            Résultat : Vide




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            Notre file d’attente émettrice ne contient pas d’enregistrements (le service cible n’a
                            pas encore répondu, puisque nous ne lui avons pas encore demandé de traiter le
                            message reçu)


                            4.1.5 Réception du message envoyé (RECEIVE)

                            Le service cible peut traiter les messages en file d’attente, grâce à l’instruction
                            RECEIVE


                            RECEIVE top(1)
                               @message_type_name = message_type_name,
                               @conversationHandle = conversation_handle,
                               @message_body = message_body
                            FROM [BewiseTargetQueue]


                            Cette instruction ressemble fortement à un Select classique, si ce n’est que le
                            RECEIVE va clôturer et réaffecter le message traité.




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            5 Scripts à retenir
                            Il est parfois (souvent !) utile de déboguer, tester, comprendre les rouages de nos
                            conversations.
                            Voici quelques vues systèmes utiles et qui peuvent souvent bien vous renseigner
                            sur l’état du Service Broker SQL Server 2005 :


                                     Vue sys.services

                            SELECT * FROM sys.services

                            Enumère l’ensemble de services créés et utilisables.


                                     Vue sys.service_contracts


                            SELECT * FROM sys.service_contracts


                            Enumère les contrats créés et utilisables


                                     Vue sys.service_message_types

                            SELECT * FROM sys.service_message_types


                            Enumère l’ensemble des types de messages.



                                     Vue sys.service_queues

                            Select * from sys.service_queues


                            Enumère l’ensemble des files d’attente.


                                     Vue sys.conversation_endpoints

                            Select * from sys.conversation_endpoints


                            Enumère l’ensemble des conversations en cours ainsi que leur état.

                            Note : L’état d’une conversation peut être :

                                 1. SO Started outbound. La conversation a démarré mais aucun message n’a
                                    été envoyé.
                                 2. SI Started inbound. Un premier message a été envoyé par l’initiateur, mais
                                    aucun message n’a été reçu par le Target
                                 3. CO Conversing. La conversation est établie entre l’initiateur et le Target.
                                    Une fois cet état atteint, la conversation se déroule. Cet état est un état de
                                    « bonne santé » d’une conversation.




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                                 4. DI Disconnected inbound : Le Target a envoyé une commande de END
                                    CONVERSATION. Cette conversation reste dans cet état tant que l’initiateur
                                    n’a pas lui-même envoyé un ordre END CONVERSATION.
                                 5. DO Disconnected outbound. L’initiateur de la conversation a envoyé un
                                    ordre END CONVERSATION. Cette conversation reste dans cet état tant que
                                    le Target n’a pas lui-même envoyé un ordre END CONVERSATION.
                                 6. ER Error. Une erreur est survenue sur la conversation. Il est utile dans ce
                                    cas là de regarder l’état des colonnes Error, Severity, et State.
                                 7. CD Closed. La conversation est terminée. Une fois la conversation en état
                                    CD, celle-ci sera purgée dans un délai de 30 minutes.



                                              Script utile de maintenance corrective


                            Il peut arriver, surtout pendant les phases de développement, que vos
                            conversations soient dans un état temporaire, et laisser à l’abandon.
                            Voici un script qui vous permettra de purger le Service Broker et revenir ainsi à un
                            état stable et initial.
                            Attention, ce script purge et efface définitivement toutes vos conversations !

                            DECLARE @HANDLE UNIQUEIDENTIFIER
                            DECLARE C CURSOR FAST_FORWARD FOR SELECT CONVERSATION_HANDLE FROM
                            SYS.CONVERSATION_ENDPOINTS
                            OPEN C;
                                    FETCH NEXT FROM C INTO @HANDLE;
                                    WHILE @@fetch_status = 0
                                    BEGIN
                                    END CONVERSATION @HANDLE WITH CLEANUP
                                    FETCH NEXT FROM C INTO @HANDLE;
                                    END
                            CLOSE C;
                            DEALLOCATE C;
                            GO




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            6 ServiceBrokerInterface

                            6.1 Présentation

                            6.1.1 Introduction
                            ServiceBrokerInterface est un projet .Net 2.0, développé en C#, livré en standard
                            dans les samples SQL Server 2005.

                            Le but de cette deuxième partie est d’utiliser cette interface, que nous allons
                            intégrer dans une petite application simple de « gestion de demandes »

                            L’idée est simple : Pouvoir envoyer des demandes, avec ou sans demande de
                            réponses d’un coté (l’initiateur), et réceptionner ces demandes pour les valider ou
                            non si nécessaire, de l’autre (le Target)



                            6.1.2 A noter
                            Attention, l’assembly ServiceBrokerInterface ne crée pas l’ensemble des types,
                            contrats et services dans la base de données. Il est donc nécessaire de les avoir
                            créés au préalable.




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            6.2 Le modèle objet
                            ServiceBrokerInterface mappe les différents scripts SQL que nous utiliserions « à la
                            main ». Il est donc logique de retrouver sous forme d’objets des concepts connus :


                            6.2.1 Message
                            Le message est la classe de base, utilisée dans ServiceBrokerInterface.
                            Comme un message SQL Server, celui est contraint par son contrat et son corps
                            doit être au format Binaire.
                            Un message est aussi définit par son type. Comme indiqué précédemment, le type
                            doit être déjà connu en base de données.

                            Note : La classe message contient déjà les types de messages standard, comme le
                            type Error ou End (il en existe plusieurs, n’hésitez pas à regarder les commentaires
                            de la classe)


                            Diagramme de la classe message :




                            Exemple de création d’un message :

                            Pour créer un message, la seule difficulté réside dans le fait de passer à la propriété
                            Body un flux binaire.
                            Nous allons donc utiliser un objet de type MemoryStream (qui est un flux en
                            mémoire) et encoder une chaine de caractère :

                                    // Création du message
                                    Microsoft.Samples.SqlServer.Message monMessage = new
                            Microsoft.Samples.SqlServer.Message();
                                    monMessage.Type = "BewiseInitiatorMessage";
                                    monMessage.Validation = "NONE";

                                      // Ecriture du message
                                      MemoryStream body = new MemoryStream(Encoding.ASCII.GetBytes(text));
                                      monMessage.Body = body;




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            6.2.2 Conversation
                            L’objet Conversation expose, notamment les méthodes :


                                 -    Send() : Envoie un message sur la conversation
                                 -    End() : Stoppe une conversation. (Attention à ne pas oublier d’appeler
                                      cette méthode coté Initiateur et coté Target)
                                 -    Receive() : Reçoit l’ensemble des messages de la conversation
                                 -    CleanUp (): Termine une conversation et effectue un Clean Up (Attention,
                                      cette méthode ne doit être utilisée uniquement qu’en phase de
                                      développement et ne devrait jamais être utilisée dans un environnement de
                                      production

                            Les propriétés de la classe Conversation

                                 -    Handle : Guid de la conversation en cours.
                                 -    Service : Service qui a créé la conversation.


                            Diagramme de la classe Conversation :




                            Comment créer une conversation ?

                            On crée une conversation par le biais de la classe Service : Voir paragraphe
                            suivant




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            Exemple d’envoi de message :

                            Pour envoyer un message sur une conversation créée, il suffit d’appeler la méthode
                            Send

                            Note : Comme nos requêtes, l’utilisation des méthodes d’un objet conversation (et
                            plus généralement des diverses méthodes des objets ServiceBrokerInterface)
                            doivent être encapsulées dans une transaction :

                            conn = new SqlConnection(ConnectionStringAdv);
                            conn.Open();
                            tran = conn.BeginTransaction();

                            // Envoi de la demande
                            dialog.Send(monMessage, conn, tran);

                            tran.Commit();
                            conn.Close();



                            Exemple de réception d’un message :

                            Une fois envoyé, une conversation (coté Target) peut recevoir l’ensemble des
                            messages, via la méthode Receive :

                            Note : Le service réceptionnant les messages, se doit de récupérer l’ensemble des
                            messages des conversations existantes sur une file d’attente ! Il NE FAUT PAS
                            tenter de récupérer une conversation particulière (via sa propriété Handle), car le
                            Handle généré par le service Target n’est pas (forcément) le même que celui
                            généré par le service Initiateur.

                            Note : Dans l’exemple suivant, je pars du principe que le flux contenu dans le
                            message est de type Texte, j’utilise donc un simple StreamReader pour en lire le
                            contenu, avec la méthode ReadToEnd().

                            while ((currentConversation = myService.GetConversation(conn, tran)) != null)
                            {
                              myDialog = currentConversation;

                                while ((message = currentConversation.Receive()) != null)
                                {
                                  StreamReader sr = new StreamReader(message.Body);
                                  Console.WriteLine(sr.ReadToEnd()) ;
                                }

                                tran.Commit();
                                tran = conn.BeginTransaction();

                            }




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            6.2.3 Service
                            La classe Service, par définition est le porteur de la conversation. C’est elle qui crée
                            la conversation, ou récupère l’ensemble des messages de l’ensemble des
                            conversations.

                            Les principales méthodes à utiliser sont :

                                 -    BeginDialog() : Démarre une conversation
                                 -    GetConversation() : Récupère une conversation


                            Les principales propriétés sont :

                                 -    Name : Nom du service
                                 -    State : Etat du service
                                 -    WaitForTimeout : Temps imparti pour récupérer un message d’une
                                      conversation


                            Diagramme de la classe Service :




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            Exemple de création d’un Service :


                            Attention ! Soyons bien d’accord, ServiceBrokerInterface ne crée pas un service en
                            base de données, il récupère un service existant !

                            Note : Comme nos scripts, l’utilisation des méthodes d’un objet service (et plus
                            généralement des diverses méthodes des objets ServiceBrokerInterface) doit être
                            encapsulée dans une transaction :

                            conn = new SqlConnection(Properties.Settings.Default.ConnectionStringAdv);
                            conn.Open();
                            tran = conn.BeginTransaction();

                            // Récupération du service Initiateur
                            client = new Service("BewiseInitiatorService", conn, tran);

                            // Nombre de message à récupérer par itération
                            client.FetchSize = 1;

                            tran.Commit();
                            conn.Close();



                            Exemple de création d’une conversation :

                            Une fois le service récupéré, l’initiateur peut créer et établir une conversation (sous
                            transaction), comme suit :

                            conn = new SqlConnection(ConnectionStringAdv);
                            conn.Open();
                            tran = conn.BeginTransaction();

                            // Début de la conversation avec le service distant
                            dialog = client.BeginDialog("BewiseTargetService", null,
                                     "BewiseContract", TimeSpan.FromMinutes(20), false,
                                     conn, tran);

                            tran.Commit();
                            conn.Close();




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            6.3 Notre exemple


                            6.3.1 Principe

                            L’exemple fournie dans le code répond à un cahier des charges simple de gestion
                            de demandes :

                            Un employé fait une liste de demandes à envoyer et demande ou non une réponse
                            d’approbation.

                            Un approbateur reçoit l’ensemble des demandes des employés et donne, si besoin,
                            une approbation.




                            6.3.2 Récapitulatif des scénarios possibles

                            1) L’initiateur envoie une liste de demandes mais ne demande pas de validation



                                                        1) Messages

                                                                     2) End Dialog


                                                                                                      3) Confirm End




                            2) L’initiateur envoie une liste de demandes et demande une validation


                                                             1) Messages



                                                                            2) Réponse

                                                                 3) End Dialog


                               4) Confirm End




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            6.3.3 Projet Initiateur

                            6.3.3.1 Initialisation

                            Le projet initiateur va lors de son lancement récupérer le Service Initiateur, appelé
                            BewiseServiceInitiator.

                            Avant de lancer une demande, l’initiateur doit Créer une nouvelle liste de
                            demandes : Le clic sur ce bouton va tout simplement créer une conversation entre
                            le service BewiseServiceInitiator et un service nommé BewiseServiceTarget, le tout
                            encapsulé dans une transaction, évidemment :

                            conn = new SqlConnection(Properties.Settings.Default.ConnectionStringAdv);
                            conn.Open();
                            tran = conn.BeginTransaction();

                            // Début de la conversation avec le service distant
                            dialog = client.BeginDialog(
                                                "BewiseTargetService",
                                                null,
                                                "BewiseContract",
                                                TimeSpan.FromMinutes(20),
                                                false,
                                                conn,
                                                tran);

                            tran.Commit();
                            conn.Close();


                            Note : Vous aurez remarqué l’utilisation d’un TimeSpan, qui indique le temps
                            maximal de durée de la conversation et la chaine « BewiseContract » qui est le
                            contrat établi pour les types de messages Initiateur et Target




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            6.3.3.2 Les 3 processus disponibles

                            Le projet Initiateur peut alors accomplir 3 taches différentes :

                                 1) Envoyer une liste de demandes, sans demande de retour d’approbation
                                 2) Envoyer une liste de demandes, et demander un retour d’approbation
                                 3) Récupérer la réponse d’approbation.

                            Concrètement,

                                 1) L’initiateur crée une conversation qu’il clôture (méthode End()) à la fin. La
                                    conversation est donc en sens unique et sur une seule occurrence

                            La     méthode      End     génère    donc     un     message                    de     type
                            http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog  que                  l’on   pourra
                            récupérer coté Target.


                                 2) L’initiateur crée une conversation qu’il ne clôture pas. Il sera donc apte à
                                    récupérer l’approbation, et la clôturer à ce moment.

                            Pour récupérer le message End, il est utile de tester le type de message reçu :

                            if ((message.Type ==
                            "http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog") ||
                             (message.Type == "http://schemas.microsoft.com/SQL/ServiceBroker/Error"))

                            {
                                      myDialog.End(conn, tran);
                            }
                            else
                            {
                                      StreamReader sr = new StreamReader(message.Body);
                                      lblResultDemandes.Text = sr.ReadToEnd();
                            }



                                 3) Récupérer une réponse d’approbation (pour peu qu’il l’ait demandé !)

                            Au retour du message, ne pas oublier de clôturer la conversation pour que son état
                            passe bien à CO (Closed)




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            6.3.4 Projet Target


                            6.3.4.1 Initialisation

                            Le projet Target va lors de son lancement récupérer le Service Target, appelé
                            BewiseServiceTarget.
                            Il est établit que chaque message reçu possède un délai delta de réception de 2
                            secondes.



                            6.3.4.2 Les 2 processus disponibles

                            Le projet Target peut alors accomplir 2 taches différentes :

                                 1) Récupérer les demandes et ne pas envoyer de réponse
                                 2) Récupérer les demandes et envoyer une réponse

                            Concrètement, lors de la réception des messages si le service Target reçoit un
                            message de fin de conversation, il ne peut pas renvoyer de réponse, le service
                            initiateur ayant mis fin à la conversation, et n’acceptant plus de messages.
                            Si ce n’est pas la cas, le service Target peut renvoyer une réponse.

                            Dans les 2 cas, le service Target confirme la fin de conversation (dans le cas 1) ou
                            met fin à la conversation (cas 2) (ce sera à l’initiateur de confirmer la fin de
                            conversation)




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97
                            7 Conclusion

                            Nous avons vu dans cet article les 3 concepts utilisables autour de l’architecture du
                            Service Broker SQL Server 2005 :

                                 1) Installation et préparation des messages, contrats et services.
                                 2) Utilisation et création d’une conversation via des scripts TSQL
                                 3) Utilisation     et    création    d’une    conversation      via l’assembly
                                    ServiceBrokerInterface, intégré dans un projet Windows Forms 2.0




1, avenue de l’Europe, Campus 1 – Bâtiment F  31400 Toulouse  Tél. 05 61 75 13 13  Fax 05 61 75 47 97

								
To top