Por: Koen Verbeeck | Atualizado: 2018-07-31 | Comentários (13) | Relacionado: Mais > Desenvolvimento de Serviços de Integração

Problema

SQL Server Data Tools (SSDT) é o ambiente de desenvolvimento para criação e manutenção de pacotes e projetos de Serviços de Integração (SSIS). Historicamente, não havia compatibilidade retroativa, o que significa que com uma versão mais recente do SSDT, você não poderia criar pacotes SSIS para uma versão mais antiga do SSDT. Desde o lançamento do SQL Server 2016, o SQL Server Data Tools suporta compatibilidade retroativa até o SQL Server 2012. Esta dica explica a nova funcionalidade.

Solução

Introdução

Histórico, cada versão do SQL Server tinha uma versão complementar de um ambiente de desenvolvimento de businessintelligence. Este era sempre ou um conjunto de templates instalados no Visual Studio, ou se o Visual Studio ainda não estivesse presente, um shellof Visual Studio capaz apenas de lidar com projetos de BI. Com esta ferramenta, você poderia desenvolver projetos de Serviços de Integração, Serviços de Análise e Serviços de Relatórios. Inicialmente, esta ferramenta foi chamada de Business Intelligence Development Studio ou BIDS. No SQL Server 2012, ela foi renomeada para SQL Server Data Tools. No entanto, o Microsofthad também possui outro produto chamado SQL Server Data Tools; com esta ferramenta você pode criar e gerenciar projetos de banco de dados SQL Server. A ferramenta de BI estava disponível na mídia de instalação do SQL Server, enquanto a ferramenta de banco de dados era um download separado (e gratuito). Como isto causou alguma confusão, SSDT foi renomeado para SQL ServerData Tools for Business Intelligence ou SSDT-BI. Desde o SQL Server 2016, as ferramentas de BI estão agora acopladas com a ferramenta de banco de dados e todo o conjunto de ferramentas é agora chamado de Ferramentas de Dados do Servidor SQL ou SSDT. Uma visão geral:

• SQL Server 2005 – Visual Studio 2005 (BIDS)
• SQL Server 2008 e 2008R2 – Visual Studio 2008 (BIDS)
• SQL Server 2012 – Visual Studio 2010 (SSDT, disponível em SQL Server installationmedia) ou Visual Studio 2012 (SSDT-BI, disponível como download separado)
• SQL Server 2014 – Visual Studio 2013 (SSDT-BI, disponível como download separado)
• SQL Server 2016 – Visual Studio 2015 (SSDT, disponível como download separado e incorpora projetos de banco de dados também)
• SQL Server 2017 – Visual Studio 2015 ou Visual Studio 2017 (SSDT)

O problema aqui era que o SSIS não tinha nenhum suporte para compatibilidade com versões anteriores.Por exemplo, se você queria desenvolver pacotes para o SQL Server 2008, você precisava do VisualStudio 2008. Se você queria desenvolver para o SQL Server 2014, você precisava do Visual Studio2013. Com Visual Studio 2013, você não poderia desenvolver projetos SSIS para SQL Server2008 ou qualquer outra versão do SQL Server, exceto para o SQL Server 2014. Isso significava que se você trabalhasse com várias versões do SSIS, acabaria com muitas versões diferentes do Visual Studio na sua máquina de desenvolvimento.

Os últimos lançamentos do SSDT (desde o SQL Server 2016) resolvem esses problemas: introduzindo a compatibilidade com versões anteriores você pode usar uma única versão do SSDT para desenvolver e manter versões de projetos SSIS de 2012 até 2017 e posteriores. É importante notar que SSAS e SSRS suportam compatibilidade com versões anteriores já há algum tempo.

SSIS e compatibilidade com versões anteriores

O resto desta dica foi escrita usando a versão do Visual Studio 2015 SSDT, juntamente com o SQL Server 2016. Todos os conselhos dados nesta dica são válidos também para versões anteriores.

Primeiro de tudo, precisamos instalar a última versão do Visual Studio 2015SSDT versão de pré-visualização. Quando você abre a mídia de instalação do SQL Server 2016, você pode encontrar um link para a página de download. Ele também contém um link para a página de download do SQL Server Management Studio (SSMS), uma vez que agora também é um download separado.

Criar um novo projeto

Quando você adiciona um novo projeto, você pode ver que agora é possível criar projetos de banco de dados e projetos de BI também no SSDT.

Nas propriedades do projeto, você pode definir a versão alvo do SSIS que o SSDT irá usar para este projeto.

A versão alvo padrão é o SQL Server 2016 (em versões posteriores do SSIS que será a versão mais recente do SQL Server). O SQL Server 2014 e SQL Server 2012 também são suportados, enquanto as versões mais antigas (2005 e 2008) não o são. Se você tiver projetos mais antigos que o SQL Server 2012, você precisará atualizá-los antes de poder usar a última versão do SSDT.

A partir do momento em que a versão alvo estiver definida, a caixa de ferramentas do SSIS se adaptará de acordo. Forexample, no SQL Server 2016 há novas tarefas Hadoop disponíveis e você pode baixar tarefasAzure do pacote de recursosAzure.

Ao definir a versão para o SQL Server 2014, todas essas novas tarefas desaparecerão da caixa de ferramentas SSIS. O mesmo é válido para as transformações de fluxo de dados introduzidas no SQL Server 2016.

Ao alterar a versão de um projeto, você receberá um aviso de que os pacotes existentes podem ser alterados:

Se você usar a funcionalidade do SQL Server 2016, você receberá um erro após configurar a versão alvo para uma versão anterior ao abrir o pacote:

O pacote ainda será aberto, mas as tarefas, transformações ou gerentes de conexão ofensivas podem desaparecer, ou você não será capaz de abrir um editor. É possível que mudar de volta para o SQL Server 2016 não resolva o problema: o objeto ainda pode estar quebrado. Nesse caso, não há outra opção senão remover o objeto e adicioná-lo novamente.

No momento da escrita, existem alguns bugs ao alternar entre as versões alvo. Você pode encontrar uma lista no post do blog MSDN What’s New for SSIS 2016 RC0? É possível que alguns deles já estejam corrigidos quando você ler isto.

Quando você tem seus próprios componentes personalizados no SSIS, você precisa pegar alguns extrasteps para fazê-los funcionar com a propriedade da versão alvo. SQL Server MVP Joost vanRossum explica como você pode fazer isso em seu blog postSwitching Target Server Versions para componentes personalizados.

Adicionando pacotes existentes ao projeto

Quando você adiciona um pacote SSIS existente de uma versão anterior ao projeto – por exemplo um pacote SSIS 2012 para um projeto 2016 – o pacote será atualizado para combinar com a versão alvo.

Quando as versões coincidem, nenhuma atualização é feita, é claro, o pacote é diretamente adicionado ao projeto. Você também pode adicionar pacotes de uma versão superior ao projeto,SSIS irá tentar baixá-los.

Testing shows however you can not always trust this message. Mesmo com uma mensagem de sucesso, o pacote pode ser quebrado se você usar apenas componentes do SQL Server 2016.

Abrir um projeto existente

Quando você usa SSDT 2015 para abrir um projeto criado com uma versão anterior do SSDT,o assistente de atualização fará automaticamente o pontapé inicial. Isto significa que todos os pacotes são actualizados para o SQL Server 2016.

Embora você ainda possa fazer o downgrade do projecto de volta para a versão anterior, ir através do processo de actualização é talvez algo que você não quer. Como alternativa, você pode editar o arquivo do projeto e adicionar a seguinte linha:

Isso fará o SSDT 2015 pular o assistente de atualização e abrir diretamente o projeto com a versão alvo correta. Para o SQL Server 2014, você muda o SQLServer2012 para o SQLServer2014, é claro. Embora este trabalho pareça funcionar, editar manualmente o XML do arquivo do projeto não é realmente suportado. O meu conselho é criar um novo projecto vazio, definir a versão alvo e depois começar a adicionar pacotes.

Control Flow Parts

Control flow parts are introduced in the tipSQL Server Integration Services 2016 Control Flow Templates Introduction (they have been renamed from templates to parts). Surpreendentemente, você ainda pode trabalhar com peças de fluxo de controle se a sua versão alvo não for o SQL Server2016. Isto é possível porque eles são um recurso de tempo de projeto e não influenciam como os pacotes realmente funcionam. No exemplo aqui eu criei um novo projeto com a versão alvo definida para o SQL Server 2014. Criei uma parte simples de controle de fluxo e adicionei-a ao pacote.

Debugar o pacote não é um problema.

E você também pode executar o pacote dentro de um catálogo SSIS SQL Server 2014:

Conclusão

A propriedade Versão Servidor de Destino introduz compatibilidade retroativa para o projeto SSIS no SSDT 2015. Com esta nova capacidade, uma antiga ferida do SSIS foi definitivamente corrigida: você pode usar apenas uma versão do Visual Studio para gerenciar projetos SSIS diferentes. A boa notícia é que com SSDT 2015 e mais tarde, você também pode usar partes de controle de fluxo em seus projetos mais antigos!

Passos seguintes

• Para mais informações sobre as diferentes versões do SQL Server Data Tools:
  • TheSSDT Evolution
  • SQL 2014 CTP1, onde está o meu BIDS?
• Para mais informações sobre as peças do Control Flow, veja o TipSQL Server Integration Services 2016 Control Flow Templates Introduction.
• Para mais dicas do SQL Server 2016, você pode usar esta visão geral.

Last Updated: 2018-07-31>

>

>

>

>

>

>

Sobre o autor

>Koen Verbeeck é um profissional de BI, especializado na pilha de BI da Microsoft com um particular amor pelo SSIS.
Ver todas as minhas dicas