In Kettle esiste una funzionalità, ben nascosta a dire la verità, che permette di sostituire tutti i parametri di una connessione esistente, sia quelli normalmente parametrizzabili nel corso dell’ETL sia quelli non parametrizzabili.

Prestando attenzione al dialetto del motore, è possibile creare job e trasformazioni in cui anche il tipo di database sia parametrico.

Come si può fare?

Innanzitutto, è importante ricordare che la priorità di lettura delle connessioni è la seguente:

1) repository

2) file shared.xml

3) trasformazione

Per cui, per sfruttare la sovrascrittura delle connessioni da uno shared object, non si può lavorare in un repository.

Cliccando prima con il tasto destro del mouse sulla connessione che ci interessa (in questo esempio è una connessione a un SQL Server ed è chiamata “connessione”) e poi su Share, Kettle crea un file shared.xml nella cartella predefinita dal parametro KETTLE_SHARED_OBJECTS (si veda il file kettle.properties).

Questo file contiene tutti i dettagli di “connessione”.

Rinominiamo quindi il file shared.xml appena creato in shared_sqlserver.xml. Possiamo ripetere questi passaggi, creando tanti xml quanti sono i motori di database che ci interessano, e rinominandone ognuno di conseguenza.

Ora possiamo creare una trasformazione di test, definire una connessione a un qualsiasi motore che non sia SQL Server, e salvarla come “connessione”. E’ fondamentale che nei job e nelle trasformazioni del nostro ETL la connessione abbia lo stesso nome di quella con cui intendiamo sostituirla..

A questo punto apriamo le Transformation Properties, e in Miscellaneous impostiamo “Shared Objects File” come ${SHARED_CONNECTION}.

Ora lanciamo la trasformazione, e valorizziamo (per comodità, a mano) la variabile SHARED_CONNECTION come shared_sqlserver.xml.

Una volta terminata la trasformazione, se apriamo la connessione “input”, vediamo che la connessione che abbiamo creato è stata sovrascritta dalla connessione al SQL Server memorizzata nel file shared_sqlserver.xml.

Questo approccio è efficace nel caso in cui si debba progettare un ETL adatto al deploy in una serie di ambienti in cui non sia nota, al momento dello sviluppo, la tecnologia dei database che verranno utilizzati in produzione.

E’ possibile così creare un ETL fortemente parametrizzato, che possa generare un datawarehouse su un motore “generico”, e in cui la fase di configurazione sia minima.