–merci à Stéphane de mon équipe qui a pris le temps de troubleshooter le problème remonté par un lecteur et surtout d’en faire une KB–
Introduction
Un package parent appelle un package enfant. Chacun déclare son LogProvider avec sa configuration. La configuration du package enfant est récupérée dans le package Parent.
Etant donné que l’initialisation du logging SSIS s’effectue avant les événements de validation et de chargement de la configuration, comment peut-on faire pour paramétrer à l’exécution le provider utilisé par le logging parent et enfant évidemment ?
Situation
Soit un package « parent.dtsx » qui appelle via une tâche « Execute package Task » un package « child.dtsx ».
Nous souhaitons logguer les événements parents et enfants dans un fichier définit à l’exécution.
Solution
Pour faire court, il ne faut pas mettre les Log Provider au design-time mais à l’exécution via une option de DTExec (ou du SQL Agent, c’est pareil). Par contre, la chaine de connexion du log doit exister dans le package.
Configuration des packages
Désactiver le logging du package parent et des packages enfants (Menu SSIS > Logging)
Dans le package parent, ajouter un gestionnaire de connexion (Connection Manager) correspondant au type de log souhaité : File Connection pour logguer dans un fichier, OLEDB connection pour logguer dans une base de données, etc.
Dans notre exemple, le File Connection Manager « logging.txt » est ajouté. Il sera la destination de nos logs.
Une variable nommée « loggingVar » est ajoutée dans le namespace du package parent.
Dans les propriétés du connection manager logging.txt, une expression est créée mappant la propriété « connection string » du connection manager vers la variable loggingVar.
Exécution
L’exécution du package se fait avec la commande dtexec standard en ajoutant le flag de logging et en précisant son provider.
dtexec /f parent.dtsx /L "DTS.LogProviderTextFile;logging.txt" /SET \package.Variables["User::loggingVar"].Value;parent_and_child.log
Dans cet exemple, le log est placé dans le fichier « parent_and_child.log » situé dans le même répertoire que le package parent.
La commande correspond à :
- /f: le package (du système de fichier) à exécuter : parent.dtsx
- /L : active le logging. L’argument suivant détermine le provider et le Connection Manager utilisé pour le logging séparé par un point-virgule. Dans notre exemple, il s’agit du provider pour fichier DTS.LogProviderTextFile et du Connection Manager logging.txt.
- /SET : pour affecter une variable de package. La variable affectée est loggingVar.
L’affectation de la variable par le SET se fait avant l’initialisation du logging dans ce cas. Le Connection Manager est bien affecté au fichier parent_and_child.log, puis le logging s’initialise sur le provider fichier texte sur le Connection Manager.
Le LogProvider fourni à DTExec est bien transmis aux enfants.
Le fichier de log obtenu est le suivant :
Pour logguer dans une base de données, il faut changer le connection manager « logging.txt » par un connection manager de type adéquat (oledb connection manager, par exemple) et changer dans la commande dtexec le provider par DTS.LogProviderSQLServer.
Encore une fois, tous les honneurs à Stéphane.
Business Geek 
Je me suis interrogé à savoir pourquoi je n’avais jamais rencontré ce problème. A priori c’est parce que naturellement je n’utilise jamais de configuration en « parent package » sur des paramètres qui sont requis en exécution stand-alone (le child qui se lance tout seul sans être appelé par le master). Et cela même si le child ne devrait jamais être lancé seul.
Y a-t-il une raison particulière pour opérer en « parent package » plutôt que passer la chaîne requise par une configuration XML (directe ou par variable d’environnement)?
Dans le cas contraire à mon sens il vaut mieux changer le mode de configuration. L’avantage principal étant une meilleure maintenabilité. En effet on se souvient toujours d’aller voir l’onglet « Package Configuration » dans SSIS alors qu’on oublie toujours qu’il existe du paramétrage dans les lignes d’appel de DTEXEC. En cas de dysfonctionnement ça évite de s’arracher les cheveux 🙂
Cela dit, merci pour ce rappel, j’avais carrément oublié qu’on pouvait déclencher le log au moment de l’appel !
Je pense que c’est une question d’habitude en effet.
Moi je suis à fond pour le parametrage dans DTExec (et donc dans l’agent quand je l’utilise).
De toute façon, ça va être de l’histoire ancienne avec 2012.