Da: Koen Verbeeck | Aggiornato: 2018-07-31 | Commenti (13) | Correlati: More >Sviluppo dei servizi di integrazione
Problema
SQL Server Data Tools (SSDT) è l’ambiente di sviluppo per creare e mantenere i pacchetti e i progetti di Integration Services (SSIS). Storicamente, non c’era compatibilità all’indietro, il che significa che con una versione più recente di SSDT, non si potevano creare pacchetti SSIS per una versione precedente di SSDT. Dal rilascio di SQL Server 2016, SQL Server Data Tools supporta la compatibilità all’indietro fino a SQL Server 2012. Questo suggerimento spiega la nuova caratteristica.
Soluzione
Introduzione
Storicamente, ogni versione di SQL Server aveva una versione di accompagnamento di un ambiente di sviluppo di business intelligence. Questo era sempre un insieme di modelli installati in Visual Studio, o se Visual Studio non era già presente, uno shello di Visual Studio in grado di gestire solo progetti di BI. Con questo strumento, si potevano sviluppare progetti di Integration Services, Analysis Services e Reporting Services.Inizialmente, questo strumento era chiamato Business Intelligence Development Studio o BIDS.In SQL Server 2012, è stato rinominato in SQL Server Data Tools. Tuttavia, Microsof aveva anche un altro prodotto chiamato SQL Server Data Tools; con questo strumento si potevano creare e gestire progetti di database SQL Server. Lo strumento di BI era disponibile sul supporto di installazione di SQL Server, mentre lo strumento del database era un download separato (e gratuito). Poiché questo ha causato una certa confusione, SSDT è stato rinominato in SQL ServerData Tools for Business Intelligence o SSDT-BI. Da SQL Server 2016, gli strumenti di BI sono ora accoppiati con lo strumento di database e l’intero set di strumenti è ora chiamato SQL Server Data Tools o SSDT. Una panoramica:
- SQL Server 2005 – Visual Studio 2005 (BIDS)
- SQL Server 2008 e 2008R2 – Visual Studio 2008 (BIDS)
- SQL Server 2012 – Visual Studio 2010 (SSDT, disponibile sul supporto di installazione di SQL Server) o Visual Studio 2012 (SSDT-BI, disponibile come download separato)
- SQL Server 2014 – Visual Studio 2013 (SSDT-BI, disponibile come download separato)
- SQL Server 2016 – Visual Studio 2015 (SSDT, disponibile come download separato e incorpora anche progetti di database)
- SQL Server 2017 – Visual Studio 2015 o Visual Studio 2017 (SSDT)
Il problema qui era che SSIS non aveva alcun supporto per la compatibilità all’indietro.Per esempio, se si voleva sviluppare pacchetti per SQL Server 2008, era necessario VisualStudio 2008. Se si voleva sviluppare per SQL Server 2014, era necessario Visual Studio2013. Con Visual Studio 2013, non si potevano sviluppare progetti SSIS per SQL Server2008 o qualsiasi altra versione di SQL Server eccetto SQL Server 2014. Questo significava che se si lavorava con diverse versioni di SSIS, si finiva per avere molte versioni diverse di Visual Studio sulla propria macchina di sviluppo.
Le ultime versioni di SSDT (da SQL Server 2016) risolvono questi problemi: introducendo la compatibilità all’indietro si può usare una sola versione di SSDT per sviluppare e mantenere versioni di progetti SSIS dal 2012 fino al 2017 e oltre. È importante notare che SSAS e SSRS supportano la compatibilità all’indietro già da tempo.
SSIS e la compatibilità all’indietro
Il resto di questo suggerimento è stato scritto utilizzando la versione SSDT di Visual Studio 2015, insieme a SQL Server 2016. Tutti i consigli dati in questo suggerimento sono validi anche per le versioni successive.
Prima di tutto dobbiamo installare l’ultima versione di Visual Studio 2015SSDT preview release. Quando si apre il supporto di installazione di SQL Server 2016, si può trovare un link alla pagina di download. Contiene anche un link alla pagina di download di SQL Server Management Studio (SSMS), dato che ora anche questo è un download separato.
Creazione di un nuovo progetto
Quando si aggiunge un nuovo progetto, si può vedere che ora è possibile creare progetti di database e progetti BI anche in SSDT.
Nelle proprietà del progetto, puoi impostare la versione target di SSIS che SSDT userà per questo progetto.
La versione target predefinita è SQL Server 2016 (nelle versioni successive di SSIS sarà la versione più recente di SQL Server). Anche SQL Server 2014 e SQL Server 2012 sono supportati, mentre le versioni più vecchie (2005 e 2008) non lo sono. Se hai progetti più vecchi di SQL Server 2012, dovrai aggiornarli prima di poter usare l’ultima versione di SSDT.
Una volta impostata la versione di destinazione, il toolbox SSIS si adatterà di conseguenza. Per esempio, in SQL Server 2016 ci sono nuovi task Hadoop disponibili e si possono scaricare i task Azure dal feature pack Azure.
Quando si imposta la versione su SQL Server 2014, tutti questi nuovi task spariranno da SSIS Toolbox. Lo stesso vale per le trasformazioni del flusso di dati introdotte in SQL Server 2016.
Quando si cambia la versione di un progetto, si otterrà un avviso che i pacchetti esistenti potrebbero essere modificati:
Se però si utilizzano le funzionalità di SQL Server 2016, si otterrà un errore dopo aver impostato la versione di destinazione a una versione precedente quando si apre il pacchetto:
Il pacchetto si aprirà comunque, ma i task, le trasformazioni o i connectionmanager incriminati potrebbero scomparire, o non sarete in grado di aprire un editor. È possibile che il passaggio a SQL Server 2016 non risolva il problema: l’oggetto potrebbe essere ancora rotto. In questo caso non c’è altra opzione che rimuovere l’oggetto e aggiungerlo di nuovo.
Al momento della scrittura, esistono un paio di bug quando si passa da una versione all’altra. Potete trovare un elenco nel post del blog MSDNWhat’s New for SSIS 2016 RC0? È possibile che alcuni di questi siano già stati risolti quando leggete questo.
Quando avete i vostri componenti personalizzati in SSIS, è necessario prendere alcuni extra passi per farli funzionare con la proprietà della versione di destinazione. SQL Server MVP Joost vanRossum spiega come è possibile farlo nel suo post sul blogSwitching Target Server Versions for custom components.
Aggiungimento di pacchetti esistenti al progetto
Quando si aggiunge un pacchetto SSIS esistente da una versione precedente al progetto – per esempio un pacchetto SSIS 2012 a un progetto 2016 – il pacchetto verrà aggiornato per corrispondere alla versione di destinazione.
Quando le versioni corrispondono, non avviene alcun aggiornamento, ovviamente, il pacchetto viene aggiunto direttamente al progetto. Puoi anche aggiungere pacchetti da una versione superiore al progetto, SSIS cercherà di fare il downgrade.
Il test mostra comunque che non puoi sempre fidarti di questo messaggio. Anche con un messaggio di successo, il pacchetto può essere rotto se si usano solo componenti di SQL Server 2016.
Apertura di un progetto esistente
Quando si usa SSDT 2015 per aprire un progetto creato con una versione precedente di SSDT, la procedura guidata di aggiornamento si attiva automaticamente. Questo significa che tutti i pacchetti vengono aggiornati a SQL Server 2016.
Anche se è possibile riportare il progetto alla versione precedente, passare attraverso il processo di aggiornamento è forse qualcosa che non vuoi. In alternativa, puoi modificare il file di progetto e aggiungere la seguente linea:
Questo farà sì che SSDT 2015 salti la procedura guidata di aggiornamento e apra direttamente il progetto con la versione corretta. Per SQL Server 2014, si cambia SQLServer2012 in SQLServer2014, naturalmente. Anche se questo work around sembra funzionare, la modifica manuale dell’XML del file di progetto non è realmente supportata. Il mio consiglio è quello di creare un nuovo progetto vuoto, impostare la versione di destinazione e poi iniziare ad aggiungere i pacchetti.
Control Flow Parts
Le parti del flusso di controllo sono state introdotte nel suggerimentoSQL Server Integration Services 2016 Control Flow Templates Introduction (sono state rinominate da templates a parts). Sorprendentemente, si può ancora lavorare con le parti del flusso di controllo se la versione di destinazione non è SQL Server2016. Questo è possibile perché sono una caratteristica del design-time e non influenzano il funzionamento effettivo dei pacchetti. Nell’esempio qui ho creato un nuovo progetto con la versione di destinazione impostata su SQL Server 2014. Ho creato una semplice parte di flusso di controllo e l’ho aggiunta al pacchetto.
Il debug del pacchetto non è un problema.
E si può anche eseguire il pacchetto all’interno di un catalogo SSIS SQL Server 2014:
Conclusione
La proprietà Target Server Version introduce la compatibilità all’indietro per il progetto SSIS in SSDT 2015. Con questa nuova capacità, una vecchia piaga di SSIS è stata finalmente risolta: puoi usare solo una versione di Visual Studio per gestire i tuoi diversi progetti SSIS. Si raccomanda di impostare la versione del server all’inizio del progetto e di non cambiarla troppo spesso perché potrebbe portare a dei problemi.La buona notizia è che con SSDT 2015 e successivi, puoi anche usare parti di control flow nei tuoi vecchi progetti!
Passi successivi
- Per maggiori informazioni sulle diverse versioni di SQL Server Data Tools:
- TheSSDT Evolution
- SQL 2014 CTP1, dov’è il mio BIDS?
- Per maggiori informazioni sulle parti di Control Flow, controlla il suggerimentoSQL Server Integration Services 2016 Control Flow Templates Introduction.
- Per altri suggerimenti su SQL Server 2016, puoi usare questooverview.
Ultimo aggiornamento: 2018-07-31
Informazioni sull’autore
Koen Verbeeck è un professionista della BI, specializzato nello stack Microsoft BI con un amore particolare per SSIS.Vedi tutti i miei consigli
- Altri consigli sulla Business Intelligence…