Partager via

Bonnes pratiques pour le déploiement d’une application

  • Article

Cette rubrique répertorie les meilleures pratiques que vous devez suivre dans le déploiement d’applications BizTalk.

Déploiement d’une application BizTalk

Documenter les procédures de déploiement d’applications

  • Assurez-vous que toutes les procédures utilisées dans le déploiement d’application sont documentées en détail, afin de disposer d’un enregistrement de la façon dont le déploiement a été effectué et de savoir comment déployer davantage ou annuler le déploiement. Tout ce qui n’est pas scripté doit être documenté avec des étapes détaillées. Cela doit inclure la documentation des modifications apportées aux systèmes externes et le déploiement de composants tiers.

    Déploiement d’applications de script

  • Scriptez autant d’étapes de déploiement d’applications que possible. Le script réduit le risque d’erreur humaine pendant le processus de déploiement.

Création d’une application BizTalk

Script de création de fichiers d’application et de .msi BizTalk

  • BtsTask.exe pouvez être utilisé pour scripter la création d’applications BizTalk. Si la création des applications est scriptée, les packages peuvent être générés automatiquement à l’aide d’un processus automatisé sur un serveur de build. Pour plus d’informations sur la création de scripts pour la création d’applications, consultez Déploiement et gestion d’applications BizTalk.

Déploiement d’un assembly BizTalk

Ne jamais déployer un assembly de Visual Studio sur un ordinateur de production

  • Pendant le processus de développement, un développeur doit souvent redéployer des assemblys à partir de Visual Studio. Pour activer le redéploiement, Visual Studio peut annuler le déploiement, supprimer la liaison, arrêter et désinscrire les artefacts inclus dans les assemblys. Bien que tout ceci soit nécessaire et approprié à l'environnement de développement, cela peut entraîner des conséquences inattendues et indésirables dans l'environnement de production. Pour cette raison, en plus d’empêcher quiconque de déployer un assembly à partir de Visual Studio sur un ordinateur de production, nous vous recommandons de ne jamais installer Visual Studio sur un ordinateur de production.

  • En outre, ne faites jamais référence à une base de données de production à partir d'un ordinateur exécutant Visual Studio.

Ajout d’artefacts à une application BizTalk

Groupement d'artefacts associés dans une même application

  • Placez autant que possible les artefacts associés dans la même application BizTalk. Vous pouvez gérer et déployer les artefacts dans une seule entité, et ainsi simplifier la gestion. Vous avez la possibilité de grouper les artefacts qui prennent en charge le même processus d'entreprise ou ceux qui réalisent les mêmes fonctions au sein d'une application.

    Déploiement d'artefacts partagés dans une application distincte

  • Si les artefacts doivent être partagés par plusieurs applications, déployez-les dans une application distincte. Si, par exemple, deux applications partagent le même schéma, placez ce dernier dans une application distincte. Nous vous recommandons de procéder ainsi, car un seul artefact d’un groupe BizTalk peut avoir un identificateur unique local (LUID). Un LUID se compose du nom de l’artefact et éventuellement d’autres attributs. Si vous incluez un artefact dans une application, puis que vous créez une référence à partir d’une autre application, l’application de référence peut ne pas fonctionner correctement lorsque vous arrêtez l’application contenant l’artefact.

    La méthode conseillée s'applique à tous les types d'artefact sauf pour les fichiers, comme les fichiers Readme (Lisezmoi) et les scripts, qui sont ajoutés à l'application en tant que type Fichier d'artefact, En effet, plusieurs artefacts de fichiers portant le même nom peuvent être déployés dans un groupe BizTalk. Vous pouvez par conséquent utiliser un fichier ayant le même nom dans plusieurs applications. Dans ce cas, l’arrêt d’une application n’aura pas d’impact sur l’autre application. Pour plus d’informations sur l’ajout d’artefacts de fichier, consultez Comment ajouter un fichier à une application.

    Déploiement de site Web partagé dans une application distincte

  • Si plusieurs solutions d'entreprise doivent se partager un même site Web, déployez ce dernier dans une application distincte. En effet, lorsque vous désinstallez une application BizTalk, le répertoire virtuel du site Web qui fait partie de l'application est supprimé, même si le site est en cours d'exécution. Et si le site Web est partagé avec une autre solution d'entreprise, cette dernière ne fonctionnera plus correctement.

    Déploiement de stratégies partagées dans une application distincte

  • Si plusieurs applications utilisent la même stratégie, vous devez la déployer dans une application distincte plutôt que de créer une référence d'une application à l'autre, car lorsque vous arrêtez une application, ses stratégies ne sont plus déployées. Si vous arrêtez une application contenant une stratégie utilisée par une autre application, la stratégie ne fonctionnera plus dans l'application.

    Déploiement de certificats partagés dans une application distincte

  • Si vous utilisez un certificat sur un port d'envoi ou un emplacement de réception dans plusieurs applications, vous devez déployer le certificat dans une application distincte, puis référencer cette application depuis les autres applications qui utilisent le certificat, Cela est dû au fait qu’un seul artefact d’un groupe BizTalk peut avoir un seul LUID. Vous ne pourrez donc pas importer le même certificat dans deux applications différentes. Si vous tentez d'importer deux applications utilisant le même certificat, la première importation réussira, la seconde non. Dans ce cas, l'utilisation de l'option d'importation Remplacer ne résout pas le problème, étant donné que le certificat que vous souhaitez remplacer existe dans une autre application.

Exportation et importation d’une application BizTalk

Lors du déploiement de fichiers de .msi volumineux, vous devrez peut-être augmenter le délai d’expiration de transaction par défaut des composants COM+ utilisés par BizTalk Server pour déployer des applications

  • Si vous tentez de déployer un fichier .msi très volumineux (plus de 100 Mo), il se peut que l’application ne soit pas déployée dans le délai de transaction par défaut des composants COM+ utilisés par BizTalk Server pendant le déploiement de l’application. Si les transactions associées à ces composants COM+ expirent avant la fin du déploiement, le déploiement échoue. Si vous déployez des fichiers .msi très volumineux, envisagez d’utiliser l’une des approches suivantes pour atténuer ce problème :

  • Déployez plusieurs fichiers .msi plus petits au lieu d’un fichier .msi volumineux.

    • Augmentez le délai d’expiration de transaction par défaut de 3 000 secondes associé aux composants Microsoft.BizTalk.ApplicationDeployment.Group et Microsoft.BizTalk.Deployment.DeployerComponent dans l’interface de gestion des services de composants. Ces composants appartiennent respectivement aux applications COM+ Microsoft.BizTalk.ApplicationDeployment.Engine et Microsoft.Biztalk.Deployment. Pour plus d’informations, consultez Définition du délai d’expiration de la transaction.

    Empêcher les liaisons d’être remplacées

  • Pour éviter que les liaisons de l'application exportée ne remplacent les liaisons de l'application dans laquelle vous importez le fichier .msi, ne sélectionnez pas le fichier de liaison en tant que ressource à exporter pendant l'opération d'exportation.

    Vérifiez que le fichier .msi est sécurisé

  • Un fichier .msi peut contenir des données sensibles. Veillez à prendre des mesures pour vous assurer que le fichier est sécurisé. Pour plus d’informations sur la sécurité des fichiers .msi, consultez Sécurité et Windows Installer.

    Vérifiez que le fichier de liaison est sécurisé

  • Un fichier de liaison peut contenir des données sensibles. Veillez à prendre des mesures pour vous assurer que le fichier est sécurisé.

    Planifier les exportations lorsque personne n’apporte de modifications à un artefact

  • Planifiez des opérations d’exportation pendant les heures où les utilisateurs ne sont pas susceptibles d’apporter des modifications aux artefacts. Cela peut être important, car si un utilisateur modifie un artefact basé sur une base de données, un répertoire virtuel, un certificat ou une stratégie pendant qu’une opération d’exportation est en cours, les modifications ne seront pas reflétées dans le fichier .msi exporté.

Importation d’une application BizTalk

Script de l’importation de fichiers .msi

  • BtsTask.exe pouvez être utilisé pour scripter l’importation de fichiers .msi BizTalk existants. Pour plus d’informations sur les scripts .msi l’importation de fichiers, consultez Déploiement et gestion d’applications BizTalk.

    Notes

    Le livre blanc s’applique également aux BizTalk Server.

  • Vous pouvez ajouter des scripts à exécuter en tant que scripts de prétraitement ou de post-traitement. Toutefois, vous devez inclure la logique dans vos scripts pour case activée variables d’environnement afin de déterminer le contexte dans lequel le script s’exécute (une importation, une installation ou une désinstallation) et traiter en conséquence. Pour plus d’informations sur l’utilisation de scripts de prétraitement et de post-traitement, consultez Utilisation de scripts de prétraitement et de post-traitement pour personnaliser le déploiement d’applications.

    Vérifier l’existence d’artefacts référencés

  • Lorsqu’une application que vous importez a une référence à une autre application, BizTalk Server vérifie que l’application référencée existe. Toutefois, il ne vérifie pas que les artefacts sur lesquels votre application a des dépendances sont inclus dans l’application référencée. Lorsque vous importez une application qui a des dépendances à des artefacts dans une autre application, nous vous recommandons de vérifier que l’application référencée contient le ou les artefacts requis.

    L’importation à partir d’un fichier .msi empêche le stockage d’assemblys modifiés dans le global assembly cache

  • Pour mettre à jour les artefacts dans une application, importez les artefacts modifiés ou mis à jour à partir d’un fichier .msi dans l’application. Si vous n’utilisez pas de fichier .msi pour importer les artefacts, vous devez mettre à jour tous les serveurs du groupe en stockant les assemblys modifiés dans le global assembly cache.

    Groupes de traitement hôtes pour mettre à jour un sous-ensemble de serveurs totaux

  • Lors de la mise à jour d’artefacts dans une application, vous devez normalement mettre à jour tous les serveurs d’un groupe BizTalk. Toutefois, si vous utilisez des groupes de traitement hôtes, vous devez uniquement mettre à jour un sous-ensemble du nombre total de serveurs dans le groupe.

    Si une opération d’importation expire, fractionnez l’application en fichiers .msi supplémentaires

  • Une opération d’importation expire si sa durée dépasse 3 600 secondes. Si vous tentez d’importer un fichier .msi et que l’opération expire, vous devez diviser le contenu de l’application en plusieurs .msi fichier en réexportant l’application et en sélectionnant un sous-ensemble d’artefacts à exporter. Pour plus d’informations sur l’exportation d’une application dans un fichier .msi, consultez Exporter une application BizTalk.