In der letzten Woche, parallel zum PASS Summit 2015 hat Microsoft die CTP 3 vom SQL Server 2016 herausgebracht, die man hier herunterladen kann. Eine der zahlreichen Neuerungen, die Möglichkeit in SSIS mit Control Flow Templates zu arbeiten, möchte ich in diesem Artikel einmal vorstellen. Neben dem SQL Server 2016 CTP 3 habe ich Visual Studio 2015 und die SSDT Tools für Visual Studio 2015 eingesetzt.
Wenn man ein neues SSIS-Projekt erstellt fällt auf, dass es nun einen weiteren Ordner, den Ordner Control Flow Templates gibt. 
Klickt man hier mit der rechten Maustaste drauf kann man ein neues Control Flow Template erstellen.
Es ist auch möglich ein vorhandenes Template zu verwenden. Dieses Template muss nicht unbedingt in das Projekt importiert werden, sondern man kann auch einfach eine Verknüpfung zu einem Template in einem anderen Projekt erstellen.
So könnte man beispielsweise eine Bibliothek mit SSIS-Templates als eigenes Projekt anlegen und in den eigentlichen SSIS-Projekten dann auf diese Templates verzweigen.
In ein Template kann man alles einbauen, was man sonst auch so in ein SSIS-Paket bauen kann. Die einzige Restriktion hier ist, dass man alles in einen Sequenz-Container packen muss. Ich habe hier mal ein Beispiel-Template gebaut:
Dieses Template kann man nun ein einem SSIS-Paket verwenden, d.h. wenn man ein neues SSIS-Paket baut kann man das Template per Drag & Drop in das Paket ziehen.
Dort wird das Template dann angezeigt.
Im Paket gibt es nach dem Einfügen des Templates dann nicht mehr die Möglichkeit die einzelnen Komponenten des Templates zu verändern, d.h. im Paket das das Template verwendet ist dieses selbst „read-only“. Ändert man nun das Template selbst, so werden die Änderungen am Template in alle Pakete übernommen, in denen das Template verwendet wurde. Im Beispiel fügen wir einfach einen weiteren Execute SQL Task ins Template ein:
Öffnen wir nun das Paket in dem das Template verwendet wurde gibt es eine kleine Warnmeldung
Klickt man hier auf „Yes“, so werden die Änderungen am Template ins Paket übernommen.
Grundsätzlich ist die Idee Templates anzubieten schon ziemlich gut, es gibt aber definitiv noch Verbesserungsspielraum. Nennt man beispielsweise ein Template um, so wird diese „Metadatenänderung“ innerhalb des Projektes leider nicht weitergetragen und alle abhängigen Pakete sind zunächst defekt.
Um das zu reparieren muss man entweder das Template wieder umnennen oder die entsprechenden Änderungen innerhalb der zugrundeliegenen SSIS-XML Datei nachziehen. Templates selbst können nicht in anderen Templates verwendet werden. So ist es beispielsweise nicht möglich eine Art Mehrfachvererbung zu implementieren, bei denen die SSIS-Pakete spezifischer werden, je weiter man im Vererbungsbaum nach unten geht. Verwendet man die Templates in einem echten Projekt könnte es etwas schwierig werden die Übersicht zu behalten, insbesondere wenn man im Nachhinein Änderungen an den Templates durchführt. Ich denke, dass der Name „SSIS-Templates“ etwas ungeschickt gewählt ist, da die Funktionalität die über die „SSIS-Templates“ zur Verfügung gestellt wird eher den Report-Parts in Reporting Services entspricht als dem, was man landläufig unter einem Template versteht, zumal es möglich ist mehr als ein SSIS Template in ein SSIS-Paket einzufügen, was eher dem Report-Part als einem Template entspricht. Meine abschließende Meinung zu den SSIS Templates ist, dass sie eigentlich eine gute Idee sind, dass aber momentan noch einiges implementiert werden muss damit man sie sinnvoll in einem echten Projekt verwenden kann. Soweit ich es beurteilen kann ist das, was man momentan mit den SSIS Templates machen kann genau so mit Execute Package möglich.