Considérations importantes relatives à la mise à jour d'applications
Vous trouverez ci-dessous d'importantes remarques à prendre en considération avant de mettre une application à jour, en particulier si celle-ci est exécutée dans un environnement de production.
Considérations d’ordre général
Les tiers et les règles sont visibles au niveau des groupes. L'ajout de tiers et de règles peut donc perturber les autres applications.
Si vous annulez le déploiement d'un artefact dont dépend un autre artefact, le déploiement de l'artefact dépendant doit être annulé au préalable.
Notes
La console Administration de BizTalk Server affiche un avertissement pour vous empêcher d'annuler le déploiement des artefacts dans le mauvais ordre.
Si un assembly BizTalk dans une application existante est mis à jour, vous devrez peut-être redémarrer les instances hôtes pour que les modifications prennent effet. Le redémarrage d’un instance hôte arrête toutes les autres applications qui s’exécutent sur l’instance hôte.
Si vous utilisez Visual Studio pour déployer une application dans un environnement de production (ce que nous vous déconseillons fortement) et que l'option Redémarrer les instances d'hôte est définie sur True dans les propriétés de projet, toutes les instances d'hôte redémarreront lorsque vous déploierez l'application, y compris celles qui ne sont pas associées à l'application. Ce processus interrompra toutes les autres applications exécutées sur les instances d'hôte de l'ordinateur local.
Pour mettre à jour un assembly BizTalk Server (contenant une orchestration, un schéma ou un mappage) déployé comme application BizTalk, vous pouvez effectuer l'une des opérations suivantes :
Effectuez un déploiement côte à côte. Vous pouvez généralement modifier de façon appropriée l'assembly plus récent en incrémentant sa version. Cela a pour effet d'attribuer aux deux assemblys un nom complet distinct. Pour plus d’informations, consultez Comment déployer une nouvelle version d’une application pour exécuter côte à côte avec une version existante.
Remplacez l'assembly BizTalk Server existant par un nouvel assembly. Vous devez arrêter toutes les instances de l'hôte susceptibles de charger l'assembly obsolète, remplacer ce dernier dans le GAC, puis redémarrer les instances de l'hôte.
Si vous déployez une toute nouvelle application en remplacement de l'application existante, vous devez corriger toutes les références entre les autres applications et l'application que vous remplacez.
Observations concernant la mise à jour des schémas
Si vous ajoutez un assembly à une application qui inclut un nouveau schéma avec le même type de message qu’un schéma existant dans le groupe BizTalk, le schéma avec le numéro de version le plus élevé sera utilisé lorsque la résolution de schéma se produit dans les pipelines. En outre, si un type de message fait référence à plusieurs types .NET, cette ambiguïté peut entraîner l’échec de l’exécution du pipeline. En effet, la recherche de schémas utilise le type de message, l'espace de noms cible et le nom de la racine de l'instance. Ceci peut se produire pour les pipelines des applications qui utilisent un schéma possédant le même type de message que le nouveau schéma. Pour plus d’informations sur la résolution de schéma, consultez Résolution de schéma dans les composants de pipeline.
Lorsque vous mettez un schéma à jour, vous devez également mettre à jour les mappages qui font référence au schéma (ou créer de nouveaux mappages), ainsi que les orchestrations reposant sur ce schéma.
Si vous incrémentez la version d'un schéma, vous devez mettre à jour la référence à ce schéma pour toutes les instances et composants de pipeline qui l'utilisent.
L'annulation du déploiement d'un schéma entraîne l'activation de la version précédente de ce schéma, si tant est qu'elle soit disponible.
Observations concernant la mise à jour des stratégies
- La version la plus élevée d'une stratégie déployée est utilisée par le moteur d'exécution BizTalk Server.