SSIS-Pakete verteilen

Dieser Artikel soll erklären, welche einfache Möglichkeit es gibt, um Pakete zu verteilen, ohne die Konfiguration in den Paketen ändern zu müssen.

Hier soll im speziellen auf besonders einfache Pakete eingegangen werden, die nur über Verbindungsmanager zu SQLServern verfügen. Kompliziertere Konfigurationen von Pfaden und ähnlichem sind besser über Variablen und Konfigurations-Dateien zu erstellen. Wie dies geht, ist in der Online-Doku beschrieben.
Zum besseren Verständnis beschreibe ich zwei Szenarien und den dazugehörigen Lösungsweg.

Szenario 1 - Ein Paket, mehrere Server

Es soll ein Paket erstellt werden, was auf verschiedene Server verteilt wird, ohne dass weitere Änderungen im Paket notwendig sind. Dieses Paket soll z. B. Daten von einem anderen Server auf den lokalen Server holen. Das gleiche Paket soll auf dem Entwicklungssystem die Daten von einer anderen Entwicklungsmaschine holen, auf dem Produktionssystem von einem anderen produktiven System.
Eine Beispielanwendung könnte die Füllung eines Data-Warehouse sein. Es existieren zwei Verbindungen

  • Server der Daten liefert
  • Server mit dem Data-Warehouse

Lösungsweg

Alias anlegen

Der Trick ist die Definition eines Alias-Namens für die Serververbindungen. Während der Entwicklung sollten die Aliase auch auf dem Entwicklungs-PC angelegt sein, denn diese werden verwendet, wenn man das Paket lokal ausführt. Später müssen die Aliase auch auf dem Entwicklungsserver und den produktiven Maschinen angelegt werden, auf denen dieses Paket laufen soll. Man überlege sich hierzu vorher eine geeignete Namenskonvention, damit man den Überblick behält. Bei mir hat sich die Namensgebung nach Anwendungsfall bewährt. Servernamen haben im Alias nichts mehr zu suchen.

Man ruft also zuerst den SQLServer Konfigurations-Manager auf. Unter SQL Native Client-Konfiguration befindet sich ein Zweig Aliase. Dort kann man über das Kontext-Menü eine neuen Alias anlegen. Den Namen des Servers habe ich in diesem Beispiel mit einem Platzhalter belegt, in der Realität kommt dort der Servername hin.

Dies wiederholt man auch für die zweite Verbindung. Danach kann man diese Aliase im SQL Server Business Intelligence Development Studio verwenden.

Paket erstellen und verteilen

Danach kann das Paket ganz normal erstellt, getestet und verteilt werden. Wenn es zum ersten mal auf dem Entwicklungssystem per Job laufen soll, werden auch dort die Aliase benötigt. Falls der Lauf zufriedenstellend war, kann es auf das produktive System gebracht werden. Die Aliase werden dort entsprechend angelegt, zeigen aber natürlich auf andere Systeme als in der Enwicklung. Das Paket selber muss nicht geändert werden!

Szenario 2 - Ein Paket, ein Server

Es soll nur ein Paket erstellt werden, was auf einem zentralen Server liegt. Je nachdem, welcher Server dieses Paket aufruft, sollen Daten von oder zu einem anderen System transferiert werden. Das gleiche Paket soll also bei Aufruf vom Entwicklungssystem die Daten zu einer anderen Entwicklungsmaschine bringen, bei Aufruf vom Produktionssystem aber zu einem anderen produktiven System.
Eine Beispielanwendung könnte ein Paket zum zentralen Monitoring sein. Es existieren zwei Verbindungen

  • Server der Daten liefert
    Server der die Daten zentral sammelt

Lösungsweg

Alias anlegen

Das Vorgehen wurde bereits im Szenario 1 beschrieben und unterscheidet sich nicht hiervon.

Paket erstellen und verteilen

Danach wird ein Paket erstellt, welche diese beiden Aliase verwendet. Es wird danach lediglich auf einem zentralen Server bereitgestellt. Eine weitere Verteilung erfolgt nicht. Nur zur Unterscheidung zwischen Versionen, die in Entwicklung sind und Versionen, die produktiv sind, werden wohl wenigstens zwei zentrale Server benötigt. Im Falle der Entwicklung, können aber sowohl beide Aliase auf dasselbe System zeigen, als auch die Bereitstellung des Paketes auf demselben System erfolgen.

Wenn zum ersten mal auf dem Entwicklungssystem ein Job laufen soll, der dieses Paket verwendet, werden auch dort die Aliase benötigt. Es werden aus Sicht des Servers die lokalen Definitionen für den Alias verwendet, nicht die Definitionen des Servers, auf dem das Paket gespeichert wurde. Falls der Lauf zufriedenstellend war, muss auf dem produktiven System lediglich die Definition der Aliase durchgeführt werden. Das zentral abgelegte Paket muss nicht geändert werden. Dann erzeugt man noch einen Job mit dem Aufruf des Paketes, was auf dem zentralen System liegt und alle produktiven Server verwenden immer die gleiche Version des Paketes.

Und was ist mit den Reporting-Services?

Übrigens funktioniert dieser Trick auch sehr gut bei den Reporting-Services. Verwendet man auch hier Alias-Namen, kann man in der Entwicklung den gleichen Report verwenden wie in der Produktion, und sieht doch andere Daten!

Fazit

Dieser Artikel soll zeigen, wie über die Definition von Aliasen für Serververbindungen die Entwicklung und Verteilung von Paketen vereinfacht wird. Ausserdem wird gezeigt, wie einfach sichergestellt werden kann, dass mehrere Server immer die gleiche Version eines Paketes verwenden.