Il logging di Sql Server Integration Services non è sicuramente una cosa agevole come poteva esserlo prima, con i DTS di SQL Server 2000. Infatti, con essi, era molto semplice allegare un semplice file di log relativo all'esecuzione del pacchetto. Bastava infatti indicare la posizione su cui salvare i risultati del pacchetto, ed il file veniva creato a runtime. Inoltre nei job di schedulazione del pacchetto era possibile indicare il file di log nello stesso identico modo.
In Integration Services invece, abbiamo l'obbligo di definire un provider all'interno del package (text, sql engine, ecc..) che avrà la funzione di rendere disponibile il log a runtime (o visibile dal JOB). Tramite JOB non è più possibile indicare il percorso di tale file e l'unico modo per ottenere quello che si poteva avere son SQL Server 2000 è quello di creare un text provider all'interno del SSIS per poi richiamarlo nel JOB.
Ho trovato queste metodologie piuttosto macchinose ed inoltre sono incappato in un bel problema. Premetto che il progetto a cui sto lavorando ha una logica di logging abbastanza complessa. Si basa infatti sulla possibilità di partire da un DB centralizzato che organizza le connessioni all'interno di tutti i SSIS, tramite l'utilizzo di una variabile che discrimina quali Database utilizzare all'interno dei workflow.
Consideriamo che, per specifiche del progetto, il logging deve essere scritto su Database diversi (per poter poi utilizzare le tabelle popolate con reporting services), database che devono essere configurati automaticamente tramite la suddetta variabile (quella che imposta tutte le connessioni, che si riferische al cliente per cui "gira" il SSIS).
Ogni cliente avrà il suo database di log il quale dovrà essere dinamicamente nominato (tramite expression).
Tramite i test dell'amico Davide Mauri si è scoperto che le "Configuration" degli Integration Services, ovvero quelle configurazioni che vengono eseguite negli eventi di startup del pacchetto, non si comportano come ci si aspettava.. O meglio, la successione degli eventi del pacchetto prima dell'esecuzione effettiva non corrisponde
a quella che ci aspettavamo.
Ed è:
Inizio Logging
Validazione Pacchetto
Caricamento Parent Package Variables
Caricamento delle Espressioni
Avvio dell'esecuzione del pacchetto..
Di conseguenza, se il logging inizia prima di poter configurare il database su cui il logging stesso dovrebbe scrivere, ci si trova davanti ad un bel dilemma..
Insomma, dopo tanti test, sempre eseguite da Davide, si è scoperto che per ottenere il dinamismo nel nome del database di destinazione del log, fin dall'inizio, è necessario utilizzare le Environment Variables (variabili di ambiente), il che può comportare alcuni problemi di manutenzione, causa la natura di queste variabili.