Considérations relatives à la réception de notifications de requête à l’aide de l’adaptateur SQL
Cette rubrique présente certaines considérations et meilleures pratiques à garder à l’esprit lors de l’utilisation de l’adaptateur SQL pour recevoir des notifications de requête à partir d’une base de données SQL Server.
Considérations lors de l’utilisation de l’adaptateur pour recevoir des notifications
Vous devez tenir compte des éléments suivants lors de l’utilisation de l’adaptateur SQL pour recevoir des notifications de requête :
L’adaptateur SQL reçoit la notification de requête de SQL Server, puis transmet simplement la notification aux clients de l’adaptateur. L’adaptateur ne fait pas la distinction entre les notifications pour différentes opérations (c’est-à-dire, l’adaptateur ne dispose d’aucune information indiquant si une notification particulière concerne une opération d’insertion ou une opération de mise à jour).
Le message de notification d’une opération n’est pas affecté par le nombre d’enregistrements affectés par cette opération. Par exemple, quel que soit le nombre d’enregistrements insérés, mis à jour ou supprimés dans une table de base de données SQL Server, le client d’adaptateur ne reçoit qu’un seul message de notification.
Nous recommandons que l’application cliente de l’adaptateur contienne la logique permettant d’interpréter le type de notification reçue de SQL Server. Le type de notification peut être déterminé en extrayant les informations à partir de, l’élément <Info> du message de notification reçu. Voici un exemple de message de notification reçu pour une opération d’insertion :
<Notification xmlns="http://schemas.microsoft.com/Sql/2008/05/Notification/"> <Info>Insert</Info> <Source>Data</Source> <Type>Change</Type> </Notification>
Notez la valeur dans l’élément <Info> . Cette valeur fournit des informations sur l’opération pour laquelle le message de notification a été reçu. Votre application doit disposer des fonctionnalités permettant d’extraire la valeur dans l’élément <Info> , puis, en fonction de la valeur, d’effectuer les tâches suivantes. La rubrique Traiter les messages de notification pour effectuer des tâches spécifiques dans SQL à l’aide de BizTalk Server contient des instructions sur la façon d’extraire la valeur dans l’élément <Info>. Un tutoriel détaillé qui effectue des tâches similaires est également disponible dans Tutoriel 2 : Employé - Processus de bon de commande à l’aide de l’adaptateur SQL.
Dans l’idéal, une fois que l’application cliente a reçu une notification pour un enregistrement spécifique, cet enregistrement doit être mis à jour afin que des notifications supplémentaires ne soient pas reçues. Par exemple, considérez une table Employee qui a une colonne État . Pour tous les nouveaux enregistrements insérés dans la table Employee , la valeur dans la colonne État est toujours « 0 », de sorte que la table se présente comme suit :
Nom de l'employé Statut John 0 Pour recevoir des notifications pour l’enregistrement nouvellement inséré, le client d’adaptateur définit la propriété de liaison NotificationStatement comme suit :
SELECT Employee_ID, Name FROM dbo.Employee WHERE Status=0
Notes
Vous devez spécifier spécifiquement les noms de colonnes dans l’instruction, comme indiqué dans cette instruction SELECT. En outre, vous devez toujours spécifier le nom de la table ainsi que le nom du schéma. Par exemple, dbo. Employé.
Après avoir reçu la notification, l’application cliente doit réinitialiser la valeur de la colonne État à « 1 » afin que l’instruction de notification ne fonctionne plus sur l’enregistrement. Pour ce faire, l’application cliente doit effectuer une opération de mise à jour sur la table Employee . Après l’opération De mise à jour, le même enregistrement dans la table Employee se présente comme suit :
Nom de l'employé Statut John 1 Il est intéressant de noter que l’opération de mise à jour envoie à nouveau une notification au client d’adaptateur et que l’ensemble du processus est répété. Par conséquent, l’application cliente doit avoir la logique requise pour ignorer ces notifications indésirables.
Si la propriété de liaison NotifyOnListenerStart a la valeur true, le client d’adaptateur reçoit un message de notification chaque fois que l’emplacement de réception démarre. Pour plus d’informations sur l’utilisation de la propriété de liaison et l’interprétation du message de notification, consultez Recevoir des notifications de requête après une répartition de l’emplacement de réception dans SQL à l’aide de BizTalk Server.
Orchestration classique pour la réception de notifications
Cette section décrit le flux d’orchestration classique pour la réception de notifications à l’aide de l’adaptateur SQL.
La première chose que l’orchestration doit faire est de déterminer le type de notification reçue, notamment :
Indique si la notification a été reçue après le redémarrage d’un emplacement de réception.
Indique si la notification a été reçue pour une opération sur une table de base de données, telle que Insert, Update ou Delete.
L’orchestration doit inclure une forme Expression et une requête xpath pour déterminer le type de message reçu.
Une fois le type de notification déterminé, l’orchestration doit inclure un bloc de décision pour effectuer des actions spécifiques en fonction du type de notification reçu. Pour ce faire, l’orchestration doit inclure une forme Decide , qui comprend un bloc Rule et un bloc Else :
Dans le bloc Règle , vous devez spécifier la condition, puis inclure des formes d’orchestration pour effectuer certaines opérations si la condition est remplie.
Dans le bloc Else , vous devez inclure des formes d’orchestration pour effectuer certaines opérations si la condition n’est pas remplie.
Les détails des exigences précédentes sont décrits dans Traiter les messages de notification pour effectuer des tâches spécifiques dans SQL à l’aide de BizTalk Server. Un tutoriel détaillé est également disponible dans tutoriel 2 : Employé - Processus de bon de commande à l’aide de l’adaptateur SQL.