SSIS (Sql Server Integration Services) non è l’evoluzione dei DTS di Sql Server 2000 ma un prodotto completamente nuovo, riscritto.
Sicuramente ha comunque qualcosa di simile, anche se, per fortuna, il tutto si riduce alla filosofia, non agli strumenti.
In questo articolo parleremo delle differenze sostanziali tra Integration Services e il suo predecessore, sottolineando i vantaggi e i limiti che il nuovo prodotto presenta.

Parallelismo con DTS

Può venire comodo fare un parallelismo, soprattutto per chi ha già usato i DTS.

La differenza più evidente è che SQL Server 2005 fornisce una piattaforma di sviluppo (Business Intelligence Development Studio, BIDS) per scrivere gli Integration Services (i pacchetti). Quindi non si ha più la console Enterprise Manager come in SQL Server 2000. Il vantaggio è quello che ora si ha una vera e propria piattaforma di sviluppo distaccata; non un’interfaccia sulla console, completamente atipica. Ci troviamo di fronte alla separazione tra sviluppo di Business Intelligence e Server di Database, che in effetti sono proprio due ambienti completamente differenti.

I SSIS, vengono salvati in una solution di Visual Studio come file dall'estensione .dtsx. In fase di deploy potranno essere salvati anche nel repository di SQL Server 2005, ma in fase di sviluppo rimangono sul filesystem. E anche questo consente di dividere lo sviluppo dalla fase di deploy, come se si trattasse della pubblicazione di un web site o della distribuzione di un’applicazione Win32.

I file dtsx prodotti sono XML e quindi leggibili anche con blocco note, mentre prima erano “File di archiviazione strutturata”, leggibili solo dal designer di DTS. Un vantaggio può essere l’intervento manuale sulle connectionstring, visibili e modificabili su questi XML. Lo svantaggio, è che non sono informazioni criptate.

Il designer è stato notevolmente migliorato e rende molto più leggibile le applicazioni scritte. E’ diviso in più sezioni: il control flow, il data flow e l'event handler.
Il primo è il vero e proprio flusso di controllo, quello che prima veniva implementato con i workflow, costituito da task e da relativi precedence constraints.

DTS – lo stage



SSIS – il control flow



I precedenti constraint (le frecce) finalmente possono essere corredati di condizioni su variabili del pacchetto (che permettono la scelta di un ramo piuttosto che di altri) e uniti secondo operatori AND/OR (in modo da dare la possibilità di seguire logiche condizionate e più complesse).
Prima non era possibile eseguire task in base a condizioni. E già questo è un grande vantaggio.



Il data flow è il designer delle trasformazioni di dati, è il container delle logiche implementate sui dati, costituito anch'esso (e questa è la grande novità) da task e da connettori che rappresentano proprio i dataflow (le trasformazioni).

DTS – una trasformazione



SSIS – N trasformazioni all’interno di un dataflow posto nel control flow



Prima si poteva fare molto poco. Solo qualche copia colonna, qualche script, ma non si aveva per nulla il controllo sulle traformazioni. Ora, e questo è il grande vantaggio, è possibile scrivere logiche molto complesse, senza diminuire le prestazioni (dipende sempre che si fa). Come si vede dall’immagine precedente, SSIS ci fornisce un insieme di task dedicati alle sorgenti di dati, alle trasformazioni, ed alle destinazioni. Sia per gli OLTP che per gli OLAP.

I constraint (sempre le frecce) che indicano il flusso di dati e non più, come nel control flow, il flusso logico di controllo, possono essere corredati di DataViewers, ovvero da tabelle riassuntive (o grafici) dei dati che stanno transitando da quella particolare pipeline. Questo aumenta di molto le potenzialità della fase di debug dei packages. Altro vantaggio, poiché in DTS il debug e la tracciabilità non esistevano nemmeno.

Nel dataflow, ogni constraint porta con se i metadati di trasformazione e di resultset che escono da ogni task. Questo a volte è uno svantaggio, poiché queste informazioni sono tutte case sensitive, e quindi basta un piccolo cambiamento (anche di un alias di una colonna di una select) per dover riadattare tutto il flusso logico. Fortunatamente, a volte, SSIS se ne accorge e riesce a rimettere tutto in ordine. Ma non è sempre così.
Poi, i metadati sono tutti fortemente tipizzati, perciò i mapping non possono avere conversioni di tipo implicite, sorgenti, destinazioni e trasformazioni devono avere metadati di tipo identico. Rimane un limite di sviluppo, ma d’altro canto, riduce al minimo gli errori sostanziali sui dati, aumentandone anche la sicurezza e l’integrità.

L’Event Handler è il gestore di eventi. Si possono selezionare eventi da un elenco e, per ognuno di essi, definire una logica così come nel control flow. Ogni volta che a runtime si scatena uno degli eventi selezionati, viene eseguita la logica indicata. Molto utile per un semplice log, all'evento onError, ad esempio:



Anche questo, in quanto mancante in DTS, è un vantaggio implicito.

Vi è poi un quarto tab, il package explorer, che permette di navigare il pacchetto tramite il suo object:



Altra differenza è che alcuni task sono definiti container (for each, for loop, sequence container) e possono contenere altri task, chiudersi ed aprirsi per occupare meno spazio. Inoltre offrono la possibilità di iterare una determinata logica su collezioni di oggetti. Chi ha utilizzato DTS, sa quanto questo sia un vantaggio. I cicli e le iterazioni erano complessi da realizzare e solo workaround potevano bypassare il problema della loro mancanza.



E ancora, le connessioni non sono più nel designer come per i DTS, ma vi è un'area per i cosiddetti connection Managers, che fungono da data source per gli oggetti che utilizzano connessioni.
Il conseguente vantaggio è quello di separare il concetto di connessione (e quindi di gestore di connessione) da quello di trasformazione.

DTS (all’interno del designer, condiviso per workflow, trasformazioni e connessioni)



SSIS – I connection Manager (separati dal resto)



Non dimentichiamo le variabili. Non sono più globali, ma in ottica Framework.NET (e quindi orientata all’oggetto), sono stati introdotti Scope differenti.
Ad esempio, posso avere variabili di visibilità pacchetto, variabili accessibili solo da un task, variabili accessibili solo da un container. Maggior ordine, rafforzamento di concetti quali “ambito di visibilità”.

Si ha poi la possibilità di impostare dei breakpoint differenti sui task, ed insieme a questi, la modalità di debug risulta molto potente. E’ anche possibile eseguire il controllo del SSIS ricevendo in visualizzazione il colore del task (rosso - errore, giallo - esecuzione, verde - eseguito correttamente).


Poi, vi sono finestre per la per la gestione delle Expressions, ovvero espressioni scritte dall’utente (valutate a runtime) che vanno ad impostare i valori di proprietà pubbliche di ogni oggetto. Ogni task, connection manager, container, infatti, possiede un elenco di caratteristiche editabili con questa nuova funzionalità. Di conseguenza, le espressioni sono fortemente legate all’oggetto in cui vengono definite, non più legate ad un task apposito, come succedeva per DTS.

DTS – il task assegna proprietà dinamiche



SSIS – le expressions per il task



Le espressioni sono definibili tramite un editor nativo ed hanno un linguaggio proprietario. L’immagine seguente ne da un’anteprima. Notare che tutte le variabili e le funzioni utilizzabili sono disponibili negli spazi in alto. E’ sufficiente trascinare gli oggetti nella sezione “Espressione”. Il tasto “Valuta Espressione” mostra il risultato della valutazione di ciò che abbiamo scritto. Attenzione che le variabili indicate, a runtime, avranno probabilmente valori differenti da quelli visibili con quest’anteprima.


Il SSIS può essere configurato come riavviabile, impostando transazioni di cui fare ROLLBACK in caso di minimo errore. Questo è un vantaggio vero e proprio, in quanto consente di poterlo lanciare più volte, senza alterare la situazione in corso sull’eventuale Database.

Per concludere, il SSIS non mantiene le modifiche effettuate sulle variabili e sugli oggetti. Anche questo è un vantaggio. DTS, infatti, manteneva lo stato dell’ultima esecuzione, rendendo difficoltosa la manutenzione della sicurezza in caso di “rilancio” del pacchetto e impedendo un semplice trasporto da un server ad un altro. A volte era addirittura necessario uno script che elimina tutti i dati di connessione di un server, impostando i nuovi, anche solo per aprirlo in design. Ora tutto ciò che viene eseguito, modifica lo stato della progettazione del SSIS a runtime ma a fine esecuzione, tutto torna come configurato all’inizio.

Conclusioni

Queste sono le principali differenze tra i due prodotti, soprattutto a livello di designer, ma ve ne sono altre, sul logging, su come si usano i task, sullo storage dei SSIS, e via discorrendo.
Già da qui però, si capisce quali siano i miglioramenti, soprattutto sulla gestione degli sviluppi e sulla monitorizzazione In realtà ci vorrebbe un libro solo per evidenziare i cambiamenti.