Discussion :

[geof]

Bonjour,

Je debute sur SQL Serveur 2005...
J'ai fait plusieurs packages avec Integrations Services, dont certains se reposent sur des fichiers de configuration en xml.
Ces fichiers de configuration ont leur chemin d'accès en dur dans mes packages.
Je voulais savoir comment faire, pour que lors du deploiement sur le serveur de production je puisse lui dire en "live", lors du déploiement, où aller chercher les fichiers de configuration.

Si qqn pouvait me montrer la marche à suivre...

Merci d'avance.

[geof]

petit up...
Je suis tj tres interessé par le sujet, si qqn veut bien m'orienter.
Merci

[geof]

Bon j'ai fait ma recherche, et apparemment on peut à l'aide de variables d'environnement, spécifier simplement le chemin d'accès des fichiers de configuration XML.
Par contre la facon de mettre à jour ces variables est encore floue pour moi...
qqn a une piste?

[ddoc]

Pour cela

->une variable d'environnement => correspondant à ton fichier de configuration.
->un fichier xml -> correspondant au mapping de tes variables.
->lors du lancement de ton package, un batch set la variable d'environnement que va utiliser ton package pour s'autoconfigurer.

Cordialement,
Alexandre BARAULT

[geof]

ok, mais t es allé un peu vite pour moi...
un batch set, c'est un fichier .bat dans lequel j'initialise mes variables d'environnement?
Comment se lance t-il?
Peux tu me donner un peu plus d'explication? Je debute dans le SSIS...

[sunshine2004]

Bonjour
soit tu utilises des variables d'environement
soit lors du deployement: le fichier de configuration est crée dans le meme repertoire que le package.(si tu utilises l'utilitaire de deployement)

sinon en production comment tu executes ton package?
la commande :
dtexec / f "chemin et nom du package" /ConfigFile "chemin et nom du fichier de configuration"

[geof]

Bonjour
soit tu utilises des variables d'environement
soit lors du deployement: le fichier de configuration est crée dans le meme repertoire que le package.(si tu utilises l'utilitaire de deployement)

sinon en production comment tu executes ton package?
la commande :
dtexec / f "chemin et nom du package" /ConfigFile "chemin et nom du fichier de configuration"

bonjour,

bin justement je ne sais pas...on est pas encore passé à l'étape de production.
Je suis en train de faire des tests, c'est pour ca que je me pose des questions.
Concernant la ligne de commande, elle permet de lancer le package?
Donc au préalable j'ai copier mon package et le fichier de configuration sur le serveur, et ensuite je lance le package par ligne de commande. je suis bon?
Dans ce cas là, le fichier de configuration ne doit pas etre forcement à l'emplacement spécifié dans le package, le chemin se met à jour?

Dans mon cas j'ai une 20aine de package qui doivent etre executés dans un certain ordre (j'ai créé un job).
Il faudrait donc que je lance 20 fois la ligne de commande, package par package?
Il faut le faire à chaque fois que le package s'execute?

tu vois c'est pas bin clair dans ma tete...

[Reskibil]

Bah dejà tu peux faire un package qui appelle les 20 autres dans le bon ordre. Ca te fait plus qu'un seul package a lancer.

[geof]

c'est une idée, je ne savais pas qu'on pouvait appeler des packages par un autre package...Je vais regarder ca.

[geof]

pas trouver comment faire un package "parent" qui execute mes autres packages...
La je suis parti sur une solution d'un fichier .bat qui appelle un fichier .vbs.
Dans le .bat je met à jour les variables d'environnement (elles sont affectées du chemin des fichiers de configuration de mes packages) et dans le .vbs j'execute mes packages.

L'avantage c'est qu'on peut mettre à jour facilement les fichiers de configurations, mais ce qui me dérange c'est qu'on est endehors de management studio...

si qqn a une meilleure solution concernant le déploiement et l'execution de packages SSIS (lié à des fichiers de configurations, ce qui sous entend que les fichiers peuvent avoir un chemin différent entre le poste de production et le poste de dev.), je suis preneur!!!

merci en tant cas pour votre aide.

[geof]

maintenant ca fonctionne trop bien...
Je m'explique, meme si le chemin des fichiers de configuration, que j'affecte à mes variables d'environnement, n'est pas valide (le nom du repertoire n'existe pas), tout se passe bien...je n'ai aucune erreur et mes packages s'executent avec succes.

si qqn a une explication à me donner, parce que là je suis perdu...

merci d'avance

[maverickbj]

Salut,

En fait c'est normal je pense que t'as tout simplement pas attaché ta variable à la connectionstring du fichier de configuration. Du coup il prend toujours le chemin en dur. D'ailleurs je crois pas qu'on puisse le faire ?

Sinon pour exécuter des packages à partir d'un package parent tu utilises les
Execute Package Task dans le control flow.

Sinon tu peux aussi utiliser le SQL Server Agent pour lancer tes packages et la tu peux choisir l'emplacement de ton fichier de config ... Tu peux même programmer l'exécution de tes packages ....

Bon courage

[geof]

nickel, j'avais pas vu qu'on pouvait définir les fichiers de configuration dans les parametres du travail que j'avais créé dans SQL agent.

merci bien!!

cependant j'ai d'autres questions qui en decoulent...
Faut-il tout de meme paramétrer les fichiers de configuration à la création du package?
Est ce que le chemin du fichier de configuration va etre modifier dynamiquement au parametrage du travail dans SQL Agent?

avec ces infos là je serais au top!!

[geof]

j'ai refait le test, spécification des fichiers de configurations dans SQL Agent, ensuite je vais modifier le nom du repertoire contenant mes fichiers de config, j'execute mon pakage et j'ai tj pas d'erreur!!
J'ai vérifié dans SSIS, en edition de package, j'ai bien mon fichier de configuration qui est relié à 'connectiostring'...
je suis tj dans le flou...

[maverickbj]

Oui il vaut mieux que tu paramètres ton fichier de configuration à la création du package. Comme ça tu peux choisir ce que tu veux avoir dans ton fichier de config.

Sinon regarde dans l'historique du job que t'as créé où il est allé cherché le fichier de config. Tu en sauras certainement plus. Ca doit être certainement un truc que t'as oublié quelque part.

++

[geof]

c'est pas marqué dans l'historique du job où il est allé chercher le fichier de config...en tout cas je ne vois pas où...
normalement il n'aurait pas pu trouvé le fichier de config vu que le chemin etait faux.

[maverickbj]

Effectivement dans le SQL Server Agent quand il s'exécute avec succés il met pas où il va chercher le fichier de config.

Quand tu as créé le step qui appelle ton package il y a un tab qui s'appelle command line là tu vois la commande que le SQL Server Agent exécute. Tu peux la poster? Du coup tu peux voir si il va chercher ton fichier de config au bon encroit. La commande doit ressembler à un truc comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
 
/FILE "C:\Documents and Settings\test_sql\Desktop\eServicesTemp_extract.dtsx"  /CONFIGFILE "C:\Documents and Settings\test_sql\Desktop\eServicesTemp_extract.dtsconfig" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING E

[geof]

/SQL "\MAJ" /ServeurName/CONFIGFILE "C:\Documents and Settings\GeofUser\Mes documents\Visual Studio 2005\Projects\AlimentationDW\MAJ.dtsConfig" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING E

je pense que c'etait ca que tu me demandais...

Donc avant mont test j'ai modifier le nom du repertoire 'AlimentationDW' en 'AlimentationDW1', physiquement dans l'explorateur windows...

[geof]

est ce que par hasard, sql agent n'agirai pas comme il suit:
si le chemin du fichiers de config n'est pas valide, il récupere le chemin du fichier que j'ai défini en edition du package?
Petite info j'ai deployer à l'ai de de l'utilitaire créer a la generation du package, c'est un "*.SSISDeploymentManifest".
Au cas où ca ferait qqch...

[maverickbj]

Ah oui c'est possible !

Tu peux déjà modifier le fichier de config en mettant une mauvaise chaine de connection par exemple pour une connexion à une BD et voir ce que ça fait !

Si il continue à bien tourner ça veut dire qu'il va pas voir dans ton fichier de config.

Là il va chercher le .dtsx dans SQL Server. Essai de lui dire d'aller chercher le .dtsx directement dans le dossier de ton projet. En mettant quand tu crées le step FileSystem dans package Source. Moi je fais comme ça et si il trouve pas le fichier de config je peux te dire qu'il est pas content .