Exploiter une architecture hautement disponible

de réduire les erreurs et de restaurer le système au plus vite.

Ceci n’est pas nouveau mais du point de vue BizTalk, il existe néanmoins des spécificités sur d’une part la supervision et d’autre part la mise à jour des applications.

Les éléments qu’il faut à minima superviser sont :

• Les « receive location » : elles peuvent se retrouver désactivées (plus de réception de messages) si la ressource à laquelle elles accèdent n’est toujours pas disponible après le nombre de tentatives configurées. Exemple : un serveur FTP sur lequel BizTalk va chercher des fichiers est indisponible.
• Les « send ports » : s’ils sont arrêtés, les applications ne recevront plus de messages (NB : cet arrêt peut être volontaire, de manière à effectuer une maintenance sur l’application cible).
• Les Host Instances : un arrêt d’un Host Instance signifie généralement une défaillance grave, par exemple, la non isponibilité des bases BizTalk. Ici aussi, l’arrêt peut être volontaire.
• Les messages suspendus : il s’agit de messages qui n’ont pas pu être traités et sont considérés en erreurs.
• Les orchestrations suspendues.

NB : Un outil du type Microsoft System Center Operations Manager (SCOM) peut être utile pour mettre cette supervision. SCOM par ailleurs dispose d’un pack de management pour BizTalk qui inclut ses règles et bien d’autres.

Il est également possible de faire la supervision de manière proactive : BizTalk inclut un ensemble de compteurs de performances qui permettent de détecter les surcharges d’activité. Le dernier point, mais certainement pas le moins important, concerne les mises à jour des applications BizTalk. Il s’agit par ailleurs beaucoup plus d’une problématique de développement que d’exploitation.

BizTalk offre des mécanismes permettant, dans la grande majorité des cas, d’effectuer une mise à jour sans ou quasiment sans interruption de service. Il faut cependant respecter quelques règles.

On distinguera trois types de mise à jour :

• Les changements de configuration (exemple : rajout ou modification d’un port d’envoi) qui pourront être effectués directement.
• Les mises à jours ne nécessitant pas de redéploiement (exemple : correction d’un mapping).
• Les mises à jour nécessitant un versionnement.

Le deuxième cas pourra être géré de manière transparente par remplacement des binaires et redémarrage des Host Instances. Enfin, le dernier cas nécessite l’installation de la nouvelle version en parallèle de la suivante puis le re-routage des flux d’entrée.  Le point important est ici d’avoir bien pris en compte la gestion des versions dès le début du projet.