In questo post parleremo di un task di trasformazione che può essere utilizzato anche come sorgente dati. Si tratta dello Script Component Task, il quale, non appena aggiunto all’interno di un DataFlow, richiede subito come deve essere configurato.
Ci sono tre metodologie di utilizzo:
- Sorgente
- Trasformazione
- Destinazione
Qui noi ci occuperemo di parlare dello Script usato come sorgente.

Script Component Task (Source)


A differenza della maggior parte dei task di sorgente, lo Script Component non richiede necessariamente un connection manager per essere configurato. Al contrario, necessita della configurazione di uno (o più) Buffer di output, ovvero oggetti contenenti metadati relativi ai dati che si vogliono veicolare verso i task successivi.
Ma passiamo alla configurazione del task. Eseguendo un doppio click sul task otteniamo la maschera seguente:


La prima sezione proposta è quella che gestisce gli Input e gli Output, e quindi le eventuali colone sorgenti del task (che a noi non interessano, in quanto il nostro script è già una sorgente e non riceve dati da nessuno) e le effettive colonne di output, ovvero quelle che poi andranno a veicolare i dati che passeranno da questo task ai successivi.
Tramite i pulsanti definiti nell’area 2 è possibile aggiungere o rimuovere quelli che sono definiti “Output”, ovvero i buffer, e le “Colonne” ovvero i campi del buffer dei dati, i veri e propri metadati. Ad ogni aggiunta l’area 1 subirà le conseguenti modifiche, il tutto corredato dalla definizione di tipi di dati e lunghezze di ogni colonna, nell’area 3. Una volta definito l’output è possibile andare a definire l’algoritmo di popolamento del buffer, spostandosi sulla sezione script:


Come per uno Script Task del Control Flow, è possibile dichiarare eventuali variabili di sola lettura e/o di lettura/scrittura, con le stesse modalità, e quindi i nomi di variabile devono essere Comma Separated e Case Sensitive. Poi vi è la proprietà Precompile, che indica a SSIS se precompilare lo script o farlo a runtime. Lasciando a True questa proprietà, le dimensioni del pacchetto aumentano, ma le prestazioni sono migliori.
All’interno degli script, l’oggetto che ci permette di accedere alle colonne definite in un buffer (output) segue la seguente naming convention:

<nome assegnato all’output>Buffer
 
Per ogni campo creato, esso espone una proprietà pubblica di sola scrittura di nome simile a quello della colonna (rimuove gli underscore e gli spazi).
Nell’esempio di prima (foto sulla sezione input output), le tre colonne definite nell’output 0 saranno nello script espresse come:

Output0Buffer.Colonna1
Output0Buffer.Colonna2
Output0Buffer.Colonna3
 
Se venisse aggiunto un altro output, ad esempio “MieColonne”, con una sola colonna chiamata “descrizione”, potremo accedere, nello script, a:

MieColonneBuffer.descrizione
 


Clickando sul tasto “Progetta Script..” (Design Script..), così come per lo script task del Control Flow, si apre l’editor di Visual Studio For Applications. Per uno Script Component del Data Flow, vi sono però metodi ben precisi da utilizzare. Ecco una semplice panoramica dei più usati:

Public Overrides Sub CreateNewOutputRows()
Consente la creazione di nuove righe di output, tramite il metodo <VarOutput>Buffer.AddRow()
 
Public Overrides Sub PostExecute()
Consente l’esecuzione di codice dopo il processo degli input e degli output
 
Public Overrides Sub PreExecute()
Consente l’esecuzione di codice prima del processo degli input e degli output
 
Public Overrides Sub ProcessInput(ByVal InputID As Integer, ByVal Buffer As
Microsoft.SqlServer.Dts.Pipeline.PipelineBuffer)
Utile per effettuare logiche sulla riga che si sta processando
 
Questi sono i più comuni, ma consiglio di dare una letta alla documentazione in linea di Integration Services per ricavare maggiori informazioni sull’interfaccia IDTSRuntimeComponent90 e sulle classi PipelineComponent e ScriptComponent.
La maggior parte delle logiche, di solito, viene racchiusa all’interno del metodo CreateNewOutputRows, che è infatti quello di default. Questo metodo consente l’aggiunta di righe nel buffer di output, e rende i dati visibili al task successivo.
Il metodo da utilizzare è AddRow, esposto da ogn buffer dichiarato nella sezione input output.
L’ultima sezione è quella che riguarda i connection manager, in cui è possibile aggiungere i gestori alle connessioni che potremmo dover utilizzare all’interno di uno script.


Ogni connessione aggiunta nella maschera, è automaticamente creata quando ci si sposta nello script. E potremo accedervi nel seguente modo:

Me.Connections.<NomeConnessione>
 
A questo punto l’oggetto avrà le proprietà relative al ConnectionManager, tra cui, ad esempio, la ConnectionString.


La sezione dei ConnectionManager è facoltativa, si possono leggere dati da file xml, file di testo, db, completamente tramite script, senza passare da un gestore di connessioni. Certo è che il suo utilizzo facilita la scrittura del codice, poiché è il ConnectionManager che si occupa di connettersi alla sorgente dati, automaticamente.
Una volta definito lo script, le colonne di output e le eventuali connessioni, la sorgente è pronta per essere utilizzata.

Di solito questo tipo di sorgente viene considerata quando proprio le altre non soddisfano i requisiti del problema. C’è un caso specifico in cui preferisco dare priorità agli script source ed è la sostituzione di una sorgente dati particolare, di cui parleremo nel prossimo post, la XML Source, che insieme al suo adapter, non dà elasticità sufficienti per ciò che riguarda la manutenzione. Come vedremo, è sufficiente cambiare appena la struttura del file (non la quantità dei nodi di un modello consolidato, ma la struttura dell’xml) per costringere lo sviluppatore a riscrivere da capo tutte le XML Source. E questo non è molto comodo. Script source è una valida soluzione.
Stay Tuned!!