Downgrade von SQL Server Integration Services (SSIS) Projekten und Paketen mit SQL Server Data Tools (SSDT)

Sind im Rahmen eines Microsoft SQL Server Integration Services (SSIS) Projekts mehrere Entwicklungs-, Test- und Produktionsumgebungen im Einsatz und basieren diese Umgebungen auf unterschiedlichen Microsoft SQL Server Versionen stellt sich relativ schnell die Frage bzgl. der Auf- und Abwärtskompatibilität der erzeugten SSIS-Pakete.

Die Frage nach der Abwärtskompatibilität von SSIS-Paketen trat zuletzt innerhalb eines Kundenprojekts auf, bei dem SSIS-Pakete, die noventum-seitig auf Basis des Microsoft SQL Servers 2016 entwickelt worden waren, in die Microsoft SQL Server 2012-basierte Entwicklungsumgebung des Kunden transferiert und integriert werden mussten.

Grundsätzlich gab es zwei denkbare Herangehensweisen:

1. Downgrade der SSIS-Pakete innerhalb der 2016er Entwicklungsumgebung von noventum und anschließender Transfer der 2012er SSIS-Pakete in die Kundenumgebung
2. Transfer der 2016er SSIS-Pakete in die Kundenumgebung und Downgrade innerhalb der 2012er Entwicklungsumgebung des Kunden

Um eine Entscheidung für eine der beiden Alternativen treffen zu können, muss neben der SQL Server Version ebenso die Version des eingesetzten Entwicklungswerkzeuges (SQL Server Data Tools [SSDT] oder Business Intelligence Development Studio [BIDS]) berücksichtigt werden.

In der Vergangenheit war die Entwicklung von SSIS-Paketen bestimmter SQL Server Versionen eng an die Version des Entwicklungswerkzeuges gekoppelt. SSIS-Pakete für den SQL Server 2008 R2 mussten mit der 2008er Version von BIDS entwickelt werden und Pakete für den SQL Server 2014 erforderten eine Entwicklung mit der 2013er Version von SSDT. Seit der Version 2015 verfügt SSDT über eine eingebaute Abwärtskompatibilität. Demnach können mit SSDT 2015 sowie mit SSDT 2017 auch SSIS-Projekte für ältere SQL Server Versionen entwickelt werden. Hierfür muss lediglich die Zielversion unter Project Properties à Configuration Properties à General à TargetServerVersion angegeben werden.

Für Alternative 1 ist also ein denkbarer Lösungsweg, das SSIS-Projekt zu kopieren, dieses mit SSDT 2015 oder 2017 zu öffnen, die TargetServerVersion herabzusetzen, das Projekt zu speichern und die gewünschten SSIS-Pakete in das Kundensystem zu transportieren und zu importieren.

Für Alternative 2 muss zunächst die Verfügbarkeit von SSDT 2015 oder 2017 vorausgesetzt werden, um die Funktionalität bzgl. der Abwärtskompatibilität zu erhalten und ein Downgrade der SSIS-Pakete durchführen zu können. Mit SSDT 2015/2017 lässt sich das SSIS-Projekt in der Entwicklungsumgebung des Kunden öffnen (bitte untenstehenden Hinweis beachten) und die transferierten 2016er SSIS-Pakete lassen sich über die Standardfunktionalität von SSDT importieren. Beim Import werden die Zielversionen des SSIS-Projekts und die Zielversionen der importierten SSIS-Pakete abgeglichen und ggf. findet dabei ein automatisches Up- oder Downgrade der SSIS-Pakete statt.

Die Einführung einer höheren SSDT-Version wurde beim Kunden bereits gewünscht und diskutiert und konnte letztlich problemlos parallel neben der vorherigen Version installiert werden.

Damit waren die Voraussetzungen für Alternative 2 geschaffen und Alternative 2 wurde letztlich zur Umsetzung gewählt. Maßgebend waren die Tatsachen, dass lediglich einzelne SSIS-Pakete transferiert werden sollten und es sich nicht um das Transferieren eines gesamten SSIS-Projektes handelte. Zudem waren über das automatische Downgrade während des Imports in SSDT keine zusätzlichen Aufwände für die Versionsanpassung zu erwarten.

Hinweise:

Bei der Umsetzung des beschriebenen Lösungsweges sind folgende Fallstricke zu beachten:

Vorsicht: Automatisches Upgrade beim Öffnen von SSIS-Projekt

Wenn ein älteres SSIS-Projekt mit SSDT 2015 oder 2017 geöffnet wird, versucht SSDT das Projekt über den SSIS Package Upgrade Wizard zu upgraden. Um dies zu umgehen und auch nach Öffnen des Projekts eine ältere Zielversion von SQL Server beizubehalten, kann die Projektdatei vor dem Öffnen angepasst und die Zielversion über das TargetServerVersion Property hinzugefügt werden.

 

Vorsicht: Versions- oder Add-On-spezifische Funktionen können verloren gehen

Funktionen, die spezifisch für höhere SQL Server Versionen sind oder dem SSIS-Projekt über Add-Ons hinzugefügt wurden, können während des Downgrades der SSIS-Pakete verloren gehen und führen anschließend zu Fehlern. Im Kundenprojekt war dies der Fall bzgl. der Verwendung von Xtract IS Data Source Komponenten (Anbindung von SAP) der Theobald Software GmbH. Nach dem Downgrade konnte die Data-Source-Komponente nicht mehr geöffnet werden.

Die Komponente musste also gegen die entsprechende 2012er Version ausgetauscht werden. Über die im Texteditor geöffnete XML-Definition des SSIS-Pakets war ersichtlich, dass die Properties der Data Source nach wie vor vorhanden waren. Um diese Einstellungen nicht zu verlieren und erneut eingeben zu müssen, gelang es, die Version der Komponente wie folgt manuell im Texteditor herabzusetzen:

Dieses Vorgehen sollte jedoch mit Vorsicht verwendet werden, da hierbei vorausgesetzt wird, dass außer der Versionsbezeichnung keinerlei Unterschiede in den Definitionen und den Properties der unterschiedlichen Versionen der Komponenten vorliegen.

Links:

Eine umfassende Beschreibung der Abwärtskompatibilität für SSIS-Projekte gibt der folgende Beitrag von Koen Verbeeck: https://www.mssqltips.com/sqlservertip/4253/backwards-compatibility-in-sql-server-data-tools-for-integration-services/