Prima di andare in ferie (da oggi ), ci siamo imbattuti in uno strano comportamento di integration services. Dico "ci siamo" perchè, un amico, Umberto, era con me al momento del verificarsi dell'anomalia, o almeno di quella sembra si tratti.
SSIS permette di abilitare Configurazioni a livello di package, le quali si occupano di valorizzare variabili e proprietà di oggetti a runtime. Ad esse si accede nel seguente modo:



Tra tutte è possibile selezionare una metodologia di passaggio dati basato su variabili del pacchetto padre. Si parte quindi da variabili del chiamante per assegnare proprietà e variabili appartenenti al SSIS figlio. Pare, però, che nel caso in cui una configurazione non si verifichi, quelle successive ad essa non siano minimamente considerate. Faccio un esempio per spiegare meglio il caso.

1) Creare un SSIS in Visual Studio, costituito solo da due variabili, src1 e src2, di tipo Int32, ed un task che chiama un altro package:



2) Creare un nuovo SSIS costituito da tre variabili, dest1, dest2, dest3, Int32 anch'esse (in quanto conterranno quelle al punto 1), ed un task qualunque, ad esempio uno script:




3) Nel package creato al punto 2) abilitare le configurazioni e crearne tre simili (ripetere la procedura, andando a puntare per "dest3" ad una variabile "src3" che non esiste nel pacchetto padre), in questo modo:



4) A questo punto, assicurarsi che la configurazione della variabile dest3 sia in testa alle altre



5) Progettare lo script per visualizzare il valore di ogni variabile:

Imports System
Imports System.Data
Imports System.Math
Imports Microsoft.SqlServer.Dts.Runtime
 
Public Class ScriptMain
   Public Sub Main()
   '
      Dim dest1 As String = Dts.Variables("dest1").Value.ToString()
      Dim dest2 As String = Dts.Variables("dest2").Value.ToString()
      Dim dest3 As String = Dts.Variables("dest3").Value.ToString()
      MsgBox("dest1: " & dest1)
      MsgBox("dest2: " & dest2)
      MsgBox("dest3: " & dest3)
      '
      Dts.TaskResult = Dts.Results.Success
   End Sub
End Class

6) Eseguire il pacchetto creato al punto 1) e controllare l'Execution Result (Risultati Esecuzione nella foto).



Il messaggio è chiaro. Il pacchetto figlio non riesce ad ottenere informazioni relative alla variabile del padre src3. Ok, è normale, non c'è. Però vorrei che notaste che nessuna delle configurazioni successive sono state valutate e quindi i valori passati dal padre, in realtà, anche se validi (come sono per src2 ed src1), non vengono mai trasportati. O meglio, se una qualunque configurazione va in errore, tutte le successive non vengono considerate. Il problema è che il tutto si riduce ad un warning, che quindi non blocca il SSIS, e l'elaborazione continua come se nulla fosse accaduto. Pensate al problema che può emergere. Non venendo mai configurate, esse utilizzano il valore che hanno fin dalla fase di progettazione del SSIS. Nel mio esempio, dest1, dest2 e dest3 sono a 0. Il che è totalmente diverso da ciò che mi aspetterei.
I messagebox che vi sono nello script confermano la mia tesi:



Non so quanto sia corretto questo comportamento. Come già anticipato, credo proprio si tratti di un'anomalia di gioventù, visto che il prodotto è agli albori. Il tutto è dimostrato dal fatto che, cambiando l'ordine delle configurazioni (ad esempio degradando la configurazione dest3 in terza posizione) le prime due vengono valutate correttamente:





Le prime due variabili sono state configurate mentre la terza, non trovata, no.

Quindi in coclusione, fate attenzione ad indicare sia nel pacchetto padre che nel figlio le variabili da configurare, in modo da non avere preoccupazioni di questo tipo. L'esito delle elaborazioni "errate" potrebbe avere epiloghi non troppo piacevoli.

Stay tuned