Distinction entre le flux de données, le flux de contrôle et la gestion des événements.

2005 DTS, le concept de flux de données inclut toutes les activités effectuées par les utilisateurs pour extraire, transformer et charger les données. Le flux de contrôle englobe tous les processus constitutifs d’un environnement donné pour la gestion de l’ETL, y compris l’exécution du flux de données. SQL Server 2005 DTS comporte également des gestionnaires d’événements qui autorisent une exécution non séquentielle du flux de contrôle, basée sur les événements générés par les tâches et d’autres objets au sein d’un lot. La nouvelle version de DTS différencie clairement le flux de données, le flux de contrôle et la gestion des événements, par un affichage dans des surfaces distinctes de l’interface.

Utilisation minimale du disque. Pour que DTS devienne un outil ETL véloce, il fallait éliminer les opérations inutiles d’écriture et de lecture sur le disque et de déplacement de mémoire. Comme les solutions ETL peuvent être particulièrement complexes, elles nécessitent généralement une forme de mise en cache sur disque et de nombreuses opérations de déplacement et d’allocation de mémoire. Dans certains cas, l’utilisation du disque est inévitable, par exemple lors de l’extraction et du chargement de données, ou de l’agrégation ou du tri d’ensembles de données trop volumineux par rapport à  la mémoire disponible. Mais, dans nombre de cas, les déplacements de mémoire et la mise en cache ne sont pas nécessaires. Le pipeline permet d’éviter les situations qui peuvent l’être en optimisant l’utilisation de la mémoire et en limitant les déplacements de mémoire aux cas absolument nécessaires.

Amélioration de l’évolutivité. Pour être reconnu comme une plate-forme ETL d’entreprise, SQL Server 2005 DTS devait être capable d’évoluer. Les utilisateurs travaillant dans des structures relativement petites peuvent avoir besoin d’exécuter DTS sur du matériel courant moins puissant, mais plus économique, alors que les utilisateurs des environnements d’entreprise voudront l’adapter à  des ordinateurs de production SMP. SQL Server 2005 DTS résout ce problème d’évolutivité en utilisant plusieurs threads dans un seul processus. Cette approche est plus efficace et nécessite moins de mémoire que plusieurs processus. SQL Server exploite cette capacité d’adaptation avec succès et nous avons décidé de l’employer pour DTS.

Reconnaissance du lien entre développement et programmation.
Les utilisateurs expérimentés de DTS savent que le développement de lots DTS s’apparente fortement à  l’écriture de code, mais la version de DTS utilisée dans SQL Server 2000 n’effectue pas bien ce lien entre les deux mondes. En revanche, SQL Server 2005 DTS fournit un environnement de développement professionnel qui inclut les projets, le déploiement, la configuration, le débogage, le contrôle de source et les exemples de code. Les créateurs de lots disposeront ainsi des outils nécessaires pour écrire, dépanner, gérer, déployer, configurer et mettre à  jour efficacement les lots dans un environnement de développement parfaitement supporté.

Amélioration de l’organisation des lots.
A mesure qu’ils gagnent en taille et en complexité, les lots peuvent parfois être surchargés et devenir inintelligibles. Pour répondre aux attentes des utilisateurs concernant la gestion de lots plus volumineux, notre équipe a ajouté plus de structure pour ceux-ci et proposé des méthodes améliorant la gestion des objets dans chaque lot. Par exemple, le runtime DTS, lequel contient le flux de contrôle DTS, comporte désormais des conteneurs qui isolent des éléments d’un lot en éléments plus petits, faciles à  organiser. Les conteneurs peuvent inclure d’autres conteneurs et tâches, de sorte que les utilisateurs sont en mesure de créer une hiérarchie d’éléments au sein du lot.

Une étendue (ou portée) est désormais associée aux variables SQL Server 2005 DTS. Autrement dit, les variables d’un conteneur sont visibles uniquement de celui-ci et de ses enfants. Les conteneurs aident également les utilisateurs à  définir l’étendue d’une transaction en configurant ladite transaction dans un conteneur. Comme un lot peut avoir plusieurs conteneurs, il accepte la création de plusieurs transactions indépendantes. Les utilisateurs peuvent aussi activer et désactiver l’exécution d’un conteneur et de ses enfants, une fonction particulièrement utile lorsque vous essayez d’isoler des éléments du lot en vue du débogage ou du développement de nouveaux lots. Dans SQL Server 2005 DTS Designer, les utilisateurs peuvent réduire les conteneurs afin de simplifier le lot visible et de le visualiser comme une collection d’éléments constitutifs. Les variables prennent en charge les espaces de nom, ce qui rend plus commode le processus d’identification et supprime toute ambiguïté dans les noms qu’elles utilisent. Toutes ces fonctionnalités permettent aux utilisateurs de simplifier les lots complexes.

Elimination des accès non contrôlés aux lots. Dans SQL Server 2005 DTS, le pointeur de lot n’est plus passé aux tâches et celles-ci n’ont donc plus de moyen d’examiner en détail le lot et son contenu. Ce changement de conception décourage les accès non contrôlés et a une incidence profonde sur le mode de création des lots DTS dans SQL Server 2005 car cette version applique la création de lots déclarative, un processus similaire au codage. Le changement simplifie également la maintenance, le dépannage, le débogage, la mise à  jour et la modification de lots car la logique de ces derniers est exposée dans DTS Designer, au lieu d’être masquée dans une tâche.

Dans SQL Server 2005 DTS, les tâches se servent parfois du pointeur du lot pour accéder de manière incontrôlée aux éléments internes du lot dans lequel elles s’exécutent. Cette pratique est usuelle pour la tâche de script ActiveX. L’utilisation des scripts est souhaitable, mais une telle mise en oeuvre de la tâche de script ActiveX crée des lots difficiles à  comprendre et à  dépanner. Elle rend également plus ardue leur mise à  jour. Par exemple, la mise à  jour automatique d’un lot qui utilise une tâche de script ActiveX pour exécuter une boucle à  l’intérieur du lot est une opération difficile car un utilitaire de mise à  jour devra analyser le script et le modifier afin qu’il fonctionne avec le nouveau modèle d’objet. La poursuite de la prise en charge de tâches qui accèdent au modèle d’objet du lot rendra également difficile la mise à  jour des lots vers de futures versions de DTS. De même, ce type d’accès incontrôlé aux lots est déconseillé, car dans SQL Server 2005 DTS, les tâches risqueraient d’interférer avec tous les services fournis par le runtime DTS, d’où des résultats imprévisibles
La suppression des accès incontrôlés a eu une incidence sur l’ensemble des fonctionnalités du runtime DTS. Nombre de ses nouvelles fonctionnalités proposent d’autres méthodes d’exécution des fonctions fournies dans les versions antérieures de DTS par la tâche de script ActiveX et la tâche Propriétés dynamiques. SQL Server 2005 DTS inclut de nouveaux conteneurs de boucle et mappages de propriétés et de nouvelles configurations et expressions qui ciblent directement le vide fonctionnel créé par ce changement. Ces nouvelles fonctionnalités font l’objet d’un meilleur support et elles sont plus cohérentes et gérables que les solutions que vous codez vous-même.

Qu’en est-il de la tâche de script ActiveX ? Bien qu’elle dispose d’une nouvelle interface utilisateur plus puissante, avec le débogage et l’aide intégrées, la saisie semi-automatique et la technologie Intellisense, la tâche de script ActiveX, comme toutes les autres tâches, se contente de fournir uniquement un comportement de tâche et ne peut plus modifier le lot pendant l’exécution.

Isolation des tâches dans le flux de contrôle. La fonctionnalité de flux de contrôle dans DTS, jusqu’à  présent axée sur les tâches, réoriente l’essentiel de son activité sur le runtime. Bien que les tâches continuent de définir le comportement des lots, dans SQL Server 2005 DTS, le runtime pilote tous les aspects relatifs à  l’ordre d’exécution du flux de contrôle, au bouclage, à  l’arrêt des lots, à  la configuration, à  la gestion des événements, aux connexions et aux transactions. Ainsi, les tâches deviennent des objets relativement isolés, qui n’accèdent pas directement au lot, à  d’autres tâches ou à  des ressources externes. Elles fonctionnent exclusivement dans leur domaine d’attribution et uniquement avec les paramètres transmis par le runtime DTS. Un conteneur spécial, intitulé Taskhost ou « hôte de tâches », impose la plupart de ces limites. Les Taskhosts sont généralement transparents pour le créateur de lots et ils appliquent un comportement par défaut pour le compte des tâches. Certains des avantages procurés par le Taskhost sont subtiles, mais l’un d’eux est important en ce sens où il simplifie l’écriture d’une tâche qui gère les nouvelles fonctionnalités telles que les points d’arrêt et la journalisation.

Les gestionnaires de connexion constituent une autre fonction qui étend le contrôle du runtime sur l’environnement d’exécution des tâches. Ils sont similaires aux connexions dans la version SQL Server 2000 de DTS, mais ils ont une portée plus étendue et sont plus importants. Dans SQL Server 2005 DTS, les tâches et autres objets utilisent les gestionnaires de connexion pour accéder à  toutes les ressources externes, y compris les données des bases de données, les fichiers plats, les pages Web et les serveurs FTP. Le recours à  ces gestionnaires permet au runtime DTS de valider, détecter et signaler toute utilisation d’une source ou destination non valide par une connexion. Les utilisateurs sont aussi en mesure d’identifier plus facilement les ressources auxquelles un lot accède. Comme l’accès aux ressources est confiné aux gestionnaires de connexion et non réparti sur l’ensemble du lot, dans des propriétés peut-être mal connues ou difficiles à  localiser sur les tâches, ces gestionnaires simplifient la configuration, la maintenance et le déploiement des lots.

Amélioration de l’extensibilité. L’équipe de développement de Microsoft DTS a écrit SQL Server 2005 DTS dans l’optique d’en faire une véritable plate-forme. Pour moi, cela veut dire que les utilisateurs peuvent incorporer DTS dans leurs applications, écrire des composants personnalisés et les intégrer à  DTS, écrire des interfaces utilisateur pour la gestion de DTS ou encore employer celui-ci conformément à  sa vocation d’origine, à  savoir comme utilitaire de déplacement des données. L’extensibilité contribue largement à  faire de la nouvelle mouture de DTS une plate-forme et non un simple utilitaire. Les clients peuvent continuer d’écrire des tâches et transformations personnalisées dans SQL Server 2005 DTS, mais le produit contient de nouvelles options qui leur permettent d’effectuer ces opérations en utilisant du code géré écrit en C#, Visual Basic, .NET et dans d’autres langages .NET. Par ailleurs, il continue de gérer l’écriture de composants personnalisés avec Visual Basic (VB) 6.0, C++ et d’autres langages de développement natifs.
La nouvelle version inclut également plus de types de composants extensibles. Auparavant, la connectivité était assurée uniquement via des connexions OLE DB. Désormais, SQL Server 2005 DTS inclut les connexions de type HTTP, FTP, OLE DB, WMI (Windows Management Interface), fichiers plats, fichiers et d’autres, et les utilisateurs peuvent écrire leurs propres connexions si ces dernières ne sont pas disponibles. S’ils souhaitent prendre en charge de nouveaux protocoles, voire de nouvelles technologies d’accès aux données, ils peuvent créer de nouveaux types de connexions en conséquence, sans modifier les autres composants DTS. La fonction de connexion extensible profite à  Microsoft et aux clients. Elle facilite en effet la tâche d’ajout de connexions pour Microsoft et permet aux clients de ne pas se limiter à  ce que propose l’éditeur.

Dans SQL Server 2005 DTS, le runtime gère intrinsèquement le bouclage par le biais de deux nouvelles constructions de boucle prenant la forme de conteneurs. Le conteneur Forloop évalue une expression définie par l’utilisateur au début de chaque itération, alors que le conteneur Foreachloop est itéré une fois pour chaque élément dans une collection fournie par l’utilisateur en employant un nouveau type d’objet appelé Foreachenumerator. Dans la mesure où ces constructions de boucle sont des conteneurs, les utilisateurs peuvent placer des tâches et d’autres conteneurs à  l’intérieur, puis exécuter leur contenu plusieurs fois. SQL Server 2005 DTS est fourni avec plusieurs objets Foreachenumerator, notamment des énumérateurs de type SMO (SQL Server Management Object), collection générique, liste de noeuds, XML, ADO, fichier et multi-éléments. Les objets Foreachenumerator sont également extensibles. Par conséquent, si les utilisateurs souhaitent prendre en charge des collections personnalisées, ils peuvent écrire leurs propres énumérateurs.

SQL Server 2005 DTS gère un autre nouveau type d’objet appelé log provider ou fournisseur de journal. Ces objets gèrent tous les détails de la création d’entrées de journal pour une destination et un format donnés. Les utilisateurs peuvent écrire facilement leurs propres fournisseurs de journal si ceux proposés par le produit ne répondent pas à  leurs besoins. La nouvelle version sera livrée avec plusieurs types de fournisseur de journal, notamment Text, XML, event log, SQL Server Profiler et SQL Server.

Le pipeline est également extensible. Il est possible d’écrire des adaptateurs et des transformations de données personnalisés venant s’intégrer à  celui-ci. Les utilisateurs peuvent aussi écrire des adaptateurs de source de données de pipeline, afin de prendre en charge un format de source particulier, d’analyser les données et de les placer sur le pipeline. De même, les adaptateurs de destination de données de pipeline supportent l’extraction des données du pipeline et leur chargement au niveau de la destination. Les transformations de pipeline sont des composants qui modifient les données à  mesure qu’elles traversent le pipeline. SQL Server 2005 DTS propose plusieurs options pour l’écriture d’adaptateurs et de transformations de données de pipeline, notamment l’utilisation du code natif, du code géré ou la transformation de script géré (Managed Script Transform).