Migration der Pakete

Um eine Migration von durchzuführen öffnet man einfach eine bestehende Solution/Projekt in BIDS 2010 oder fügt ein 2008 R2 Projekt einer Denali-Solution hinzu. Es wird erkannt dass es sich bei dem geöffneten Projekt um ein zu migrierendes Projekt handelt und der Conversion Wizard startet automatisch.

Nun hat man die Möglichkeit ein Backup des Projektes vor der Migration anzulegen.

Es wird darauf hingewiesen, dass die einzelnen Bestandteile des Projektes währende der Migration ausgecheckt werden, wenn das Projekt unter einer Sourcenverwaltung verwendet wird, z.B. im Zusammenspiel mit dem TFS.

Anschließend startet der SSIS Package Upgrade Wizard, in dem die Pakete ausgewählt werden, die migriert werden sollen.

Im nächsten Fenster wählt man die Optionen aus, mit denen die Migration durchgeführt wird. Die erste Option “Update connection strings to use new provider names” führt dazu, dass die Connection auf die neuen Provider (z.B. SQL Datenbank, SSAS Cube) angepasst werden.
Durch “Validate upgraded packages” wird das Paket nach der Migration validiert.
Mit der Option ”Create new package ID” werden die Package GUIDs während der Migration neu vergeben, wie es auch mit Hilfe des BIDS-Helper möglich ist.
Die letzte Option “Continue upgrade process when a package upgrade fails” sorgt dafür, dass die Migration fortgeführt wird, auch wenn die Migration eines Paketes fehlschlägt.

Es folgt noch mal eine Zusammenfassung und danach beginnt die Migration. Ist die Migration durchgeführt erschein ein Fenster, welches die Ergebnisse der Migration anzeigt. In diesem Beispiel schlägt die Migration fehl, weil die Pakete eine SQL 2008 R2 Connection enthalten, auf dieser Entwicklungsumgebung aber nur SQL Denali und kein SQL 2008 R2 Treiber installiert ist. Zudem ist die Validierung der Pakete eingeschaltet.

Hier ein Auszug der Message Details, die man erhält, wenn man auf die Message aus dem vorherigen Fenster klickt. Die Fehlermeldungen sagen aus, dass das Paket eine Connection auf eine SQL 2008 R2 Datenbank enthalten, dafür aber auf der Umgebung kein Treiber installiert ist. In diesem Fall ist das auch so richtig, da die Connection auch auf SQL Denali umgestellt werden soll.

Um die Migration trotz dem Fehler im Connection-String durchzuführen, kann man einen Schritt zurückgehen, und die Validierung ausschalten. Danach wird die Migration noch mal durchgeführt und das Ergebnis sieht folgendermaßen aus.

Öffnet man jetzt ein migriertes Paket sieht man im Connection Manager ein Symbol, dass darauf hindeutet, dass etwas mit der Connection nicht in Ordnung ist.

Nach der Auswahl des richtigen Treibers (Native OLE DBMicrosoft OLE DB Provider for SQL Server) funktioniert die Connection auch wieder.

Bisher ist das Projekt allerdings noch in der alten Projektstruktur(legacy deployment model). Dies wird auch hinter dem Projektnamen angezeigt.

Das Projekt bzw. die einzelnen Pakete sind jetzt auch schon voll funktionsfähig und könnten so auch in einer produktiven Umgebung eingesetzt werden. Möchte man allerdings die ganzen neuen Features nutzen wie Umgebungskonfiguration, Projekt Parameter oder Paket Parameter konvertiert man das Paket in das project deployment model.

Daraufhin startet erneut ein Wizard, der die bestehende Configuration, Dependencies usw. in die neue Projektstruktur migriert. Es werden wieder die Pakete ausgewählt, die mit in die neue Projektstruktur übernommen werden sollen.

Wenn man einen Hierarchischen Aufbau von Paketen hat d.h. wenn ein Paket ein anderes Paket aufruft, werden die Referenzen auf die auszuführenden Pakete ausgewählt. Zur Erinnerung: Beim neuen SSIS in Denali passiert alles im Kontext eines SSIS-Projektes. Standardmäßig wird auch immer ein Projekt deployed, keine einzelnen Pakete. Daher wird keine File- oder SQLServer-Referenz auf die Child-Pakete mehr benötigt. Es wird einfach auf andere Pakete im Projekt referenziert.

Als nächstes wird ausgewählt, welche Konfigurationen in die Projektkonfiguration übernommen werden sollen. Dabei werden sämtliche Konfigurationen(Config File, Parent Configuration usw) angeboten.

Man hat die Möglichkeit festzulegen, in welchen Scope die neue Konfiguration(Projekt, Paket) soll, welche Default-Werte gesetzt werden sollen, und auch festzulegen, ob Konfigurationen erforderlich sind. Ist eine Konfiguration erforderlich, braucht diese zur Ausführung auf jeden Fall einen konfigurierten Wert. Ansonsten können die entsprechenden Pakete nicht gestartet werden.

Als Ergebnis erhält man eine Solution, die folgenden Aufbau hat. Im folgenden Screenshot sieht man die neuen Items Projekt Parameter und Projekt Connection Manager.

Öffnet man die Project.params erhält man folgende Sicht. Die angezeigten Parameter können, bzw. müssen(wenn sie Required sind) während der Laufzeit in das Projekt reingegeben werden.

Fazit

Bei Standard Paketen die keine Custom Components haben, klappt die Migration relativ einfach und intuitiv. Wenn man eigene Custom Components oder auch Custom Components von Drittanbietern verwendet, müssen diese auch noch migriert werden.

In der CTP gibt es noch leichte Probleme bei einzelnen Paketen, z.B. dass die DataSourcen nicht immer richtig migriert werden. Zudem wurde bei meiner Testmigration der Provider der Connection nicht auf den Denali SQL Server Treiber umgestellt. Das musste dann manuell erfolgen.