> Data > Maintenez vos lots dans l’ignorance

Maintenez vos lots dans l’ignorance

Data - Par Kirk Haselden - Publié le 24 juin 2010
email

Imaginez le scénario suivant : vous venez de finaliser la création d’un lot dans SQL Server Integration Services (SSIS). Vous l’avez testé avec différentes entrées et tout semble fonctionner à merveille. La gestion des erreurs est adaptée, vous partagez les lots qui isolent la logique commune en tant que sous-lots, vous disposez de gestionnaires d’événements qui vous informent de problèmes éventuels dans les lots ou qui gèrent la sortie des erreurs de la tâche de flux de données.Cette dernière se déroule rapidement et sans accroc dans votre environnement de développement. Ensuite, vous transférez le lot sur le serveur de production et patatras ! Des erreurs se produisent et plus rien ne semble fonctionner. Cette situation a-t-elle un air de déjà vu ?

Les lots SSIS sont étroitement liés à leur environnement d’exécution. Ils référencent des dossiers et fichiers sur certains lecteurs, se connectent à des serveurs spécifiques, sont à l’écoute d’événements particuliers et assurent d’autres fonctions liées à l’environnement. Même si la création d’un lot simple est relativement facile, la tâche peut prendre des allures de défi si elle consiste à écrire un lot encore capable de s’exécuter correctement dès lors qu’il est déployé sur un autre ordinateur.

Ce défi est l’un des plus courants auxquels les utilisateurs de SSIS sont confrontés. Bien que SSIS propose certains outils pour résoudre ces questions, il n’est pas toujours évident d’identifier la bonne approche ou de savoir comment appliquer les outils en question.

Cet article se propose d’expliquer comment utiliser les configurations SSIS et les expressions de propriété afin de résoudre le problème des lots dépendants de l’emplacement. Il présente une méthodologie générale permettant de simplifier le déploiement des lots et une approche aux problèmes les plus fréquents concernant leur portabilité. En appliquant ces concepts et pratiques aux situations rencontrées dans votre environnement, vous pouvez réduire l’incidence d’un échec des lots au cours de leur déploiement.

Maintenez vos lots dans l’ignorance

Les problèmes liés au déplacement d’un lot surviennent lorsque ce dernier référence des ressources (telles que dossiers et fichiers) dont les emplacements sont spécifiques à un ordinateur donné. Dans ce cas, si vous déployez le lot sur un autre ordinateur, les références codées en dur aux ressources peuvent ne plus être valides. Par exemple, sur un ordinateur, vous pouvez avoir un dossier situé sur le lecteur D et servant à stocker les fichiers plats entrants à traiter. Si vous déplacez le lot sur une autre machine, cette dernière n’a peut-être pas de lecteur D, d’où la nécessité d’utiliser un autre emplacement pour vos fichiers plats, par exemple le lecteur Z. Parfois, les solutions à ces types de problèmes sont simples. Dans notre exemple, vous pouvez utiliser la commande système « subst » pour créer une nouvelle lettre de lecteur. Néanmoins, cette approche peut être source de confusion et être difficile à gérer sur le long terme.

Ces références codées en dur sont la cause la plus courante du problème de dépendance vis-à-vis de l’emplacement. Même si vous ne déplacez jamais un lot vers un autre ordinateur, vous n’êtes pas à l’abri de ce type de problème car l’environnement autour du lot peut changer. Ces modifications peuvent prendre la forme suivante : changement du nom du serveur, défaillance de disques durs, modification des partages et départ d’utilisateurs de l’entreprise. Il vous faut un moyen de mettre à jour facilement les lots afin de prendre en compte ces évolutions. Si les références à de telles ressources changeantes sont codées en dur dans le lot et si l’une d’elles vient à être modifiée, vous devrez appliquer les nouveaux paramètres à chaque lot qui référence la ressource en question. Si les lots concernés sont nombreux, la gestion résultante peut tourner au cauchemar.

Vous avez besoin d’un moyen d’isoler le lot de l’environnement dans lequel il fonctionne, ou de le « maintenir dans l’ignorance » afin qu’il n’ait aucune référence codée en dur aux ressources. Il vous faut aussi un moyen simple de configurer le lot afin qu’il continue de fonctionner dans un environnement en évolution. Il serait encore plus judicieux de pouvoir fournir des paramètres via des configurations entraînant une auto-adaptation du lot. Je désigne ces lots sous le vocable « lots à capacité d’autoréconciliation ou d’auto-guérison ».

Un tel lot accepte certains paramètres de base en entrée et crée ses propres références valides aux ressources. Bien que le thème de la configuration et du déploiement des lots soit vaste et puisse effleurer de nombreuses solutions différentes, cet article fournit un canevas utilisable pour isoler vos lots de l’environnement, tout en proposant un mécanisme simple d’ajustement aux modifications environnementales.

Téléchargez gratuitement cette ressource

IBM Cloud Pak for Security : Quelles avancées avec IDC ?

IBM Cloud Pak for Security : Quelles avancées avec IDC ?

IBM Cloud Pak for Security est une plateforme de sécurité intégrée ouverte conçue pour fournir des éclairages approfondis sur les menaces pour plusieurs environnements. Découvrez comment obtenir des informations sur les menaces et les risques, orchestrer les actions, automatiser les réponses sans devoir faire migrer vos données.

Data - Par Kirk Haselden - Publié le 24 juin 2010