Conseils pour la conception de votre adaptateur

Cette section présente des astuces et des conseils compilés par les développeurs des adaptateurs durant leur conception.

Les propriétés du gestionnaire doivent être des chaînes si elles sont utilisées comme configurations par défaut

Il semble intéressant d’utiliser les propriétés de la feuille de propriétés du gestionnaire généré par XSD comme valeurs par défaut pour leurs propriétés Location , car si la valeur n’est pas définie dans Location , le runtime utilise automatiquement la valeur définie dans le gestionnaire. Mais cela entraîne plusieurs problèmes.

D'abord, cela ne permet pas de savoir si la valeur présentée au moteur d'exécution doit être remplacée ou pas. Pour le savoir, il faut définir une certaine notion NULL pour les valeurs et effectuer un test par rapport à cette valeur. Le problème avec les feuilles de propriétés XSD de BizTalk Server est que seules les chaînes acceptent la valeur NULL. Même si vous voulez que votre adaptateur utilise des paramètres par défaut par l'intermédiaire de ce test NULL et si vous êtes prêt à restreindre l'adaptateur aux types de chaînes, celui-ci reste exposé à une interface utilisateur assez curieuse.

Les feuilles de propriétés générées par XSD prennent uniquement en charge la définition d’une propriété sur NULL en cliquant avec le bouton droit sur la propriété, à quel moment un menu contextuel nullify ? s’affiche et la propriété peut être définie sur NULL. Aucun retour visuel ne vous permet de savoir si une propriété est NULL.

Éléments à prendre en compte lors de l'implémentation de l'Assistant Génération de schémas

Les programmeurs aiment utiliser dans leurs codes des modèles d'objets fortement typés. La manipulation du XML dans le code peut sembler maladroit et risqué au premier abord. Mais quelques astuces et une utilisation réfléchie de l'aide offerte par .NET Framework peuvent grandement simplifier les choses.

Ne créez pas des documents XML avec concaténation de chaînes

L'une des pires erreurs relatives à l'utilisation du XML est d'essayer de le générer à partir de la concaténation des chaînes et d'imprimer des instructions dans la mémoire. Cela consomme énormément de temps processeur et de mémoire. Même pour un extrait XML insignifiant, il est plus simple d'utiliser un outil comme XmlWriter ou un objet Document Object Model (DOM). Si vous utilisez XmlWriter, ne choisissez pas la fonction d'écriture brute, car l'enregistreur ne conserve pas l'état du document.

Au moment de l'exécution, XmlWriter est préférable au XML DOM car des problèmes de forte consommation de la mémoire sont connus avec le DOM. Cependant, au stade de la configuration ou de la conception, ces problèmes ne se posent pas. Le DOM facilite l'utilisation des requêtes XPATH, ce qui peut représenter un outil supplémentaire utile.

Pensez à définir le squelette de votre document XML en tant que ressource

Si vous générez un gros document XML à partir d'un outil de conception et que ce document généré suit toujours la même structure de base, pensez à faire du squelette du fichier XML une ressource du projet, pour pouvoir le modifier plus facilement si besoin.

Chargez le code dans un DOM puis étoffez votre document en utilisant XPATH pour choisir le nœud à ajouter. Dans ce cas, vous créez un fichier Web Services Description Language (WSDL). L'Assistant stocke le fichier WSDL squelette dans une ressource et ajoute les pièces enfants XSD (XML Schema Definition). Il utilise selectNode avec un XPath pour trouver le bon parent. Il s'agit du code de l'interface utilisateur : la performance n'est donc pas en question et l'implémentation qui en résulte est propre, robuste et durable.

Pensez à placer le processus de traitement dans le pipeline BizTalk

En général, les adaptateurs construits chez Microsoft ne gèrent pas le traitement des messages en fonction du format et l'envoient dans le pipeline BizTalk. Les adaptateurs pour les sources de données structurées mais non-XML en sont un bon exemple.

Dans ce cas, l'adaptateur ne fait que recevoir les données et le pipeline BizTalk les analyse et les convertit en équivalent XML. Le composant pipeline devient ainsi une pièce réutilisable de l'architecture.

Faites en sorte que le comportement de l'adaptateur soit configurable

Parmi les leçons tirées du programme bêta d'adaptateurs MQSeries, retenez que tous les clients ne se satisfont pas du même comportement. Cela est particulièrement vrai pour la gestion des erreurs et le classement. La solution est de faire en sorte que le comportement de l'adaptateur soit configurable. Vous pouvez stipuler que l'adaptateur prenne en charge le classement, que les échecs soient déplacés dans la file d'attente des messages interrompus ou qu'ils forcent l'adaptateur à interrompre le traitement et à se désactiver. Rendre de tels comportements configurables peut simplifier de manière significative la vie de vos clients, lorsqu'ils ont besoin d'écrire des orchestrations ou des scripts complexes externes à BizTalk Server afin d'arriver au même résultat.

Permettez la corrélation avec les files d'attente de messages

De nombreuses plateformes de messagerie acceptent l'adjonction d'un ID de corrélation dans l'en-tête des messages afin de pouvoir prendre en charge un scénario requête-réponse au niveau de l'application. Exemples : MQSeries, MSMQ et SQL Service Broker. Il peut sembler intéressant de mapper le modèle requête-réponse du système de messagerie externe sur un adaptateur envoi-réponse dans BizTalk Server. Cependant, cela n'a pas de sens, vu l'endroit où s'effectuent les transactions. En fait, un envoi vers le système de messagerie externe nécessite une validation transactionnelle avant que l'autre extrémité de la file d'attente ne voit les données. La réception doit également être une transaction distincte.

La solution de BizTalk Server consiste à :

• utiliser des ensembles de corrélations dans l'orchestration ;

• Configurer deux ports distincts : l’un pour l’envoi et l’autre pour la réception

  Dans les cas simples, l'orchestration spécifie l'ID de corrélation associé au message par l'adaptateur. Il est transmis à l'adaptateur en tant que propriété de contexte du message. Dans un cas plus complexe, le scénario demande au système de messagerie externe d’allouer l’ID. Dans ce cas, il peut être renvoyé du port d’envoi à l’orchestration avec un message de réponse. Ce message de réponse sert uniquement à transmettre l'ID et ne représente pas le vrai message de réponse.

Notes

Il existe une condition d'engorgement dans le moteur d'orchestration, de sorte que la vraie réponse au message peut l'emporter sur la réponse d'ID depuis l'envoi. Cette condition d'engorgement doit être gérée dans l'orchestration elle-même.