2010-02-01 4 views
9

Je suis un débutant à SSIS/C# (je suis généralement un développeur Java) alors excuses si c'est une question vraiment stupide.SSIS et de ré-utiliser C#

Essentiellement, le problème est le suivant: J'ai deux tâches de flux de données qui chargent des données et les exportent vers un format de fichier plat hérité. Le formatage est effectué par une tâche de script (C#).

Ce que je voudrais faire est de partager un code commun entre les deux. par exemple. Je pourrais créer une classe de base commune, puis l'étendre pour mes deux tâches de script différentes.

Cependant, il semble que SSIS ne le prévoie pas vraiment.

Est-ce que quelqu'un sait s'il existe un moyen d'accomplir ce que je veux faire?

+0

Copie possible de [SSIS: comment réutiliser le script dans un composant de script dans un autre package?] (Http://stackoverflow.com/questions/6692779/ssis-how-do-you-reuse-script-in- a-scripting-component-in-another-package) –

Répondre

10

Vous avez raison de dire qu'il n'y a pas de moyen simple de le faire directement depuis SSIS.

Dans un récent projet, nous avons pris deux approches différentes, toutes deux assez bien fonctionné en fonction de ce que vous devez faire:

  1. Créer une classe utilitaire (comme une simple bibliothèque de classe) et la référence à partir de vos tâches de script. C'est fait à peu près la même chose que n'importe quel autre type de référence. Si vous utilisez .NET 3.5, n'oubliez pas que vous devrez mettre à jour la version manuellement dans les tâches de script puisque SSIS est par défaut à 2.0. Nous avons également trouvé que si nous voulions une certaine réutilisabilité dans l'ensemble utilitaire (ne pas compter sur des noms de variables codés en dur, etc.), le paquet devait encore avoir une assez grande quantité de "setup" pour utiliser les scripts utilitaires.

  2. Créez un composant de flux de données personnalisé. Il s'agit d'un processus beaucoup plus complexe, mais en fin de compte, nous ferons de notre mieux pour éviter la duplication de code. Généralement, le codage du flux de données réel est assez simple et pas très différent d'un composant de script, mais le code de configuration varié dont vous aurez besoin peut compliquer les choses. Il n'y a pas beaucoup de soutien dans SSIS pour quand quelque chose ne va pas. Conduit à beaucoup de travail de détective sur notre projet.

Si vous envisagez d'utiliser quelque chose en grande quantité et que vous vous êtes engagé à vous débarrasser autant que possible du code standard, 2 est l'option préférée. Si cela est utilisé quelques endroits ici et là, considérez l'approche simple de 1.

+0

le lien dans l'autre réponse donne une étape-par-étape pour # 1 –

1

Je suis assez sûr qu'il est possible d'accéder aux assemblys .NET dans les scripts SSIS. Donc vous pourriez le faire de cette façon. Voir the article "Accessing .NET assemblies with SSIS" sur SQL Server Central.

+0

Ceci est fondamentalement une bonne étape par étape pour # 1 dans la première réponse –

0

Je crois que vous devrez créer un assembly ou un webservice pour que cela fonctionne.

0

Ceci ne résout pas complètement votre problème mais aide à ne pas avoir à recréer toutes les classes chaque fois que vous en avez besoin (je fais aussi ne souhaite pas déployer d'assemblys référencés pour mon projet actuel). Premièrement, vous avez besoin d'une copie maîtresse de vos classes, vous pouvez les copier à partir d'une tâche de script existante en utilisant le même processus ci-dessous, mais à l'envers.

  1. Ouvrez l'éditeur pour la tâche de script et le cliquez sur Explorateur de propriété sur le fichier du projet (le ST_ [Guid]), dans la fenêtre Propriétés vous verrez l'emplacement du dossier du projet.(Cet emplacement recréé à chaque fois que vous modifiez la tâche de script)

  2. Dans l'explorateur, copiez vos classes dans ce dossier

  3. Sur le projet Explorer, cliquez sur l'icône « Afficher tous les fichiers »

  4. Faites un clic droit sur vos fichiers et ajouter au projet

-1

probablement trop tard pour y répondre, mais vous pouvez cliquer sur la solution et ajouter une classe là. Ensuite, lorsque vous entrez dans vos scripts, vous pouvez ajouter un objet existant et rechercher la classe que vous avez créée précédemment. Pour moi, il a été localisé par la solution pour le projet. N'avez pas passé par le déploiement ou quoi que ce soit pour cela, mais au moins vous pouvez accéder à la classe à travers les scripts individuels.

+0

Cela fonctionne mais a des inconvénients importants. Chaque script est compilé avec sa propre copie du code 'partagé' et à moins que vous ne touchiez chaque tâche qui utilise le fichier référencé, les modifications apportées au code partagé n'auront aucun effet. Autrement dit, ils ne recompileront pas automatiquement si la source partagée change. – bielawski