BI 2008 Migration: Reporting Services (3/3)

Im dritten und letzten Teil meiner Serie BI 2008 Migration möchte ich über Vorgehensweisen zur Reportmigration und Deployment sowie meine Erfahrungen dazu berichten.

Bei SSRS 2008 ergaben sich einige Neuerungen. Die bedeutendste ist sicherlich die Einführung des Tablix-Elementes, das bisherige Tabellen, Matrizen und Listen ersetzt. Tabellen sind die mit Abstand am häufigsten eingesetzten Reportelemente. Diese können auch verschachtelt sein und sollen natürlich auch nach der Migration auf die 2008er Version problemlos funktionieren – in unseren Migrationsprojekten war das erfreulicherweise sehr gut erfüllt. Als Ansätze stehen hierzu Backup/Restore, Visual Studio und Eigenentwicklungen zur Diskussion.

Ähnlich wie Analysis Services verfügt Reporting Services über eine eigene Datenbasis. Diese besteht aus den beiden SQL Server Datenbanken

  • ReportServer
  • ReportServerTempDB

Beide Datenbanken sind voneinander abhängig. Die ReportServer Datenbank enthält alle Reports, Datenquellen, Verzeichnisse, Sicherheitseinstellungen und weitere Objekte in verschlüsselter Form. Damit der Reporting Services Dienst die ReportServer-Datenbank Inhalte entschlüsseln kann, wird ein entsprechender Encryption Key benötigt. Dieser wird mit der Reporting Services 2005 Configuration erstellt. Nach einfachem Backup/Restore der beiden Datenbanken wird auf der Zielumgebung der Encryption Key mittels Reporting Services Configuration Manager 2008 wieder eingelesen. Danach sollten alle Reports 1:1 auf der neuen Umgebung bereit stehen.

Das klingt einfach – ist es auch. Doch meist zieht im Rahmen des Migrationsprojektes auch der Datenbank-Server um, und wir haben ja in den Datenquellen noch überall die Verweise auf die 2005er Datenquellen! Bei wenigen Reports kann der Administrator die Anpassungen manuell über den Berichts-Manager durchführen. Ähnlich verhält es sich mit dem Deployment über Visual Studio 2008, jedoch hat der Entwickler meist keinen Content Manager Zugriff auf produktive Systeme.

Als Alternative zu Backup/Restore der SSRS Datenbanken bieten sich automatisierbare Eigenentwicklungen an, die den Reporting Services Dienst über SOAP ansprechen. Der Entwickler kann damit die RDL-Dateien plus eine aktualisierte Konfigurationsdatei an das operative Team übergeben, welches dann das Deployment automatisiert ausführt.

Für den Report-Entwickler ergeben sich nach meiner Erfahrung keine Probleme. Beim Öffnen eines RS 2005 Projektes mit Visual Studio 2008 wird aber zunächst nur das Projektfile migriert. Die Reports werden in das neue RDL Format überführt, wenn man sie einzeln öffnet und abspeichert.

Fazit: Der Entwickler kann die Reports problemlos nach 2008 überführen. Beim Deployment sehr vieler Reports auf die neuen Server in großen Enterprise-Umgebungen sind automatisierbare Eigenentwicklungen de facto unverzichtbar.

BI 2008 Migration: Integration Services (2/3)

Im zweiten Teil dieser Serie über die Migration von SQL Server 2005 Business Intelligence Anwendungen schauen wir uns an, wie Integration Services Pakete nach SSIS 2008 migriert werden können.

Microsoft selbst liefert ein detailliertes Dokument zur Migration nach SQL Server 2008, jedoch möchte ich in diesem Artikel weitere praktische Erfahrungen einfließen lassen.

Beim Öffnen eines Integration Services 2005 Projektes mit Visual Studio 2008 startet der Upgrade Wizard ganz automatisch und führt die Umwandlung in das neue Projekt- und Paket-Format durch. Im Hintergrund passiert jedoch viel mehr: Die verwendeten nativen Microsoft Komponentenreferenzen (Data Flow Task, Data Source u.a.) werden in Referenzen auf die neuen 2008er DLLs überführt. So weit, so gut. Doch was ist mit den selbst entwickelten Komponenten, den Custom Components?

Gerade hier leistet der Upgrade Wizard wertvolle Dienste. Damit dieser erkennt, welche neuen Komponenten den alten entsprechen, werden Mapping-Dateien ausgewertet, die diesen Zusammenhang definieren. Für jede Komponente stellt der Entwickler eine Datei beliebigen Namens zum Zeitpunkt der Migration bereit. Mapping-Dateien haben folgenden Aufbau:

   1: <?xml version="1.0" ?>

   2: <Mappings xmlns="http://www.microsoft.com/SqlServer/Dts/UpgradeMapping.xsd">

   3:     <ExtensionMapping

   4:         tag="$$Short Description$$"

   5:         

   6:         oldAssemblyStrongName="$$AssemblyName.ClassName$$, $$AssemblyName$$, Version=1.0.0.0, Culture=neutral, PublicKeyToken=$$Token$$"

   7:         

   8:         newAssemblyStrongName="$$AssemblyName.ClassName$$, $$AssemblyName$$, Version=2.0.0.0, Culture=neutral, PublicKeyToken=$$Token$$"

   9:     />

  10: </Mappings>

Die mit $$ umschlossenen Identifier müssen individuell angepasst werden. Befinden sich entsprechende Dateien im neuen SQL Server Unterverzeichnis DTSUpgrade Mappings, so versucht der Upgrade Wizard alle Referenzen der alten Komponente (“oldAssemblyStrongName”) im SSIS Paket auf die neue zu aktualisieren. Und schon ist das Paket mit der neuen Komponente einsatzbereit. Ach ja: Die neue Komponente sollte natürlich auf dem Rechner vorhanden sein!

Ganz so komfortabel ist die Migration von Script Tasks manchmal jedoch nicht. Der Upgrade Wizard überführt den Script Code zwar in die neue Entwicklungsumgebung, kann jedoch inhaltlichen Anpassungsbedarf nicht erkennen. Dazu gehört beispielsweise die textuelle Verwendung des SQL Providernamens (neu SQLNCLI10) sowie Referenzen auf alte Libraries in Strings. Deshalb ist schon noch etwas Aufmerksamkeit gefragt um diese Probleme zu erkennen.

Gute Dienste leistet hierbei der Upgrade Advisor. Dieses Tool untersucht alle Pakete in einem ausgewählten Verzeichnis und zeigt als Analyseergebnis u.a. die verwendeten Script Tasks an. Diese Ergebnisliste ist manuell abzuarbeiten und damit jedes Skript auf mögliche Probleme zu untersuchen.

Abschließend noch ein Tipp: Verwenden Sie keine SSIS-Pakete mit Punkten im Dateinamen. Der Upgrade Advisor schneidet nämlich den Namen des Ergebnispaketes sofort nach dem ersten Punkt ab. Pakete mit gleichem Namensraum-Benennungsschema würden sich gegenseitig überschreiben und das Ergebnis der Migration unbrauchbar machen.

Beherzigen Sie jedoch die erwähnten Hinweise, sollte einer erfolgreichen Paketmigration nichts mehr im Wege stehen.

BI 2008 Migration: Analysis Services (1/3)

Keine Frage – SQL Server 2008 spielt mit in der obersten Liga der Datenbanksysteme. Im Gegensatz zu anderen Anbietern integriert Microsoft Business Intelligence Komponenten mit in das Produktrelease des Datenbanksystems. Diese Marktstrategie trug dazu bei, dass MS Produkte mit zu den Marktführern im BI Bereich gehören.

Viele Firmen entwickelten ihre BI-Anwendungen mit SQL Server 2005 und möchten nun auf die seit 2010 verfügbare Version 2008 R2 migrieren. In dieser dreiteiligen Artikelserie möchte ich über meine Erfahrungen mit verschiedenen Lösungsansätzen der Migration von BI-Anwendungen von SQL Server 2005 nach 2008 R2 berichten. Eine sehr detaillierte Beschreibung liefert Microsoft selbst im Technical Upgrade Guide. Von praktischer Bedeutung ist insbesondere die dort beschriebene Side-By-Side Migration auf neue Server.

Die Überführung existierender SQL Server 2005 Datenbanken nach 2008 gelingt erstaunlich problemlos. Man kann sowohl ein mit dem SQL Management Studio 2005 (SSMS) erstelltes Backup mit SSMS 2008 über Restore als Datenbank verfügbar machen als auch aus einem Backup aus SSMS 2008. Auch Datenbank Setup-Skripte der Version 2005 laufen problemlos auf SQL Server 2008.

Bei Analysis Services gibt es ebenfalls zwei Migrationsstrategien. Zum einen kann die AS-Datenbank über Deployment Skripte im XMLA Format in der Zielumgebung neu erzeugt werden. Dann muss ein Reprocessing erfolgen, um die AS DB mit Daten aus der relationalen DB zu befüllen. Der zweite Ansatz überträgt die AS DB mit Backup/Restore auf die Zielumgebung. Beide Strategien verlaufen normalerweise problemlos. Doch Achtung: Microsoft hat die Verbindungsprovider umgestellt. Für SQL Verbindungen ist dieser nun SQLNCLI10, für OLAP-Verbindungen MSOLAP.4. Dies ist in den ConnectionStrings in den Data Sources der AS DB bzw. im Deployment Skript zu überprüfen und gegebenenfalls zu editieren.

image

Die Migrationsstrategie mit Backup/Restore der AS DB bringt Zeitvorteile gegenüber dem Ansatz des neu Erstellens/Reprocessing. Beim Backup wird die AS DB nämlich mindestens 50% komprimiert. Der Vorteil kommt insbesondere in produktiven Umgebungen zum Tragen, wenn ein zuverlässiges Filecopy-Tool verwendet wird um die AS DB auf den neuen Server zu kopieren.

Auf der anderen Seite kann mit einem neuen Deployment und Reprocessing auch ein neues Release verknüpft werden. Läßt sich der mit dem Reprocessing verbundene Zeitbedarf produktiv planen, ist diese Migrationsstrategie flexibler.

Bei einem Migrationsprojekt sind diese und andere Aspekte vorher zu diskutieren und auch Zeitmessungen bei Testmigrationen durchzuführen. Die SDX AG kann Sie hierzu kompetent beraten und die optimale Strategie für Ihre Umgebung ausarbeiten.

Eigene Komponenten für SSIS (Teil 2)

Teil 1 der kleinen Serie zu eigenen Komponenten in SSIS finden Sie >hier<

SQL Server Integration Services (SSIS) ist das Tool der Wahl bei  der Konsolidierung verschiedener Datenquellen. Makroskopische Aufgaben werden in SSIS zu Paketen zusammengefasst, die wiederum aus atomaren Tasks zusammengesetzt sind. Microsoft liefert bereits von Haus aus eine Vielzahl nativer Tasks mit, doch offene Architektur und .NET-Basierung ermöglichen auch Eigenentwicklungen mit vertretbarem Aufwand. In diesem Zusammenhang spricht man von Custom Components.

In Teil 1 dieser Serie haben wir das Anlegen eines Visual Studio Projektes zur Erstellung einer Custom Component und die Abfolge der Methodenaufrufe in SSIS betrachtet. Heute wollen wir die Aufgaben der wichtigsten Methoden und die Einbindung der Komponente in SSIS näher beleuchten.

Zieht der SSIS Paketentwickler eine Komponente von der Toolbox auf die Design-Fläche der Data Flow Task, so wird die Methode ProvideComponentProperties() der Komponente aufgerufen. Darin platziert der Komponentenentwickler das Anlegen von Metadaten d.h. Objekte, die die Komponente für die Erfüllung ihres Zweckes benötigt. Hierzu gehören Input- und Output-Datenflusspfade sowie Properties. Der Zugriff erfolgt über Collections der Eigenschaft ComponentMetaData, die aus der Ableitung von PipelineComponent verfügbar wird. Im Codebeispiel wird ein Standard Input- und ein Standard-Output Datenflusspfad angelegt sowie ein Custom Property “Statuswert” hinzugefügt:

   1: public override void ProvideComponentProperties()

   2: {

   3:     // Metadata entfernen soweit vorhanden

   4:     base.RemoveAllInputsOutputsAndCustomProperties();

   5:  

   6:     // Standard Input/Output Pfad mit Index 0 anlegen

   7:     base.ProvideComponentProperties();

   8:  

   9:     // Informationen für den SSIS Paketentwickler

  10:     ComponentMetaData.ContactInfo = "SDX AG, Frankfurt";

  11:  

  12:     // Eine Eigenschaft vom Typ Int32 hinzufügen

  13:     IDTSCustomProperty100 prop = ComponentMetaData.CustomPropertyCollection.New();

  14:     prop.Name = "Statuswert";

  15:     prop.Value = 0;

  16:     prop.TypeConverter = "System.Int32";

  17: }

Nach Einbindung in SSIS (siehe unten) sieht der Paketentwickler folgende Eigenschaften der Custom Component, wobei automatisch sichergestellt wird, dass nur Zahlen für Statuswert eingegeben werden können:

image

Weitere wichtige Methoden, in denen Funktionalität zu platzieren ist, sind:

  • AquireConnections() : Stellt die Verbindung zu einem Connection Manager her um Zugriff auf Datenbank-Verbindungen zu erhalten
  • PreExecute() : Mapping von Output-Spalten mit Datenpuffer-Inputspalten während der Paketausführung um Objekt-IDs für Datenzugriffe zu erhalten
  • ProcessInput() : Zugriff auf Dateninhalte während der Paketausführung
  • PostExecute() : Abschließende Aktionen wie Cleanup intern benutzter Objekte
  • ReleaseConnections() : Schließen der Verbindung zu einem Connection Manager

Eine Einführung in die konkrete Implementierung dieser und weiterer Methoden gibt das Tutorial Creating a Custom Transformation Component.

Um nun die Custom Component für SSIS verfügbar zu machen, wird die Assembly (DLL) in das SQL Server Unterverzeichnis PipelineComponents kopiert und im Global Assembly Cache registriert. Danach kann über die Toolbox im SSIS Designer die neue Komponente im Tab SSIS Data Flow Items hinzugefügt werden. Dazu sind jedoch administrative Rechte erforderlich.

image

Bei Ausführung von Komponenten in einer Data Flow Task in einer Visual Studio Debug Session beobachtet man ganz allgemein einen portionsweisen Datentransfer von einer Datenquelle zu einem Datenziel. SSIS organisiert den Datentransfer intern mit Hilfe eines Buffers, der zur Laufzeit gefüllt wird. Ist der aktuelle Buffer voll, wird er an den Input der nächsten Datenfluss Tasks weitergereicht. Daraus ergibt sich unter anderem, dass die Methode ProcessInput() mehrfach zur Laufzeit aufgerufen wird; nämlich je einmal pro Buffer und einmal abschließend. Dies ist bei der Entwicklung zu berücksichtigen.

Wie oben beschrieben, wird durch ProvideComponentProperties() jeweils ein Input- und ein Output Datenflusspfad verfügbar gemacht, so dass unsere Komponente den Inhalt des Buffers weiterreichen kann.

image

Fazit: Die Entwicklung eigener Komponenten für Integration Services ist die Königsklasse der ETL-Prozessentwicklung. Damit lassen sich spezifische Aufgaben elegant lösen und ermöglichen die Wiederverwendbarkeit in allen SSIS Paketen.

Die Entwicklung eigener Komponenten erfordert jedoch fundierte Kenntnisse SSIS interner Vorgänge. Die SDX AG unterstützt Sie gerne mit Beratung,  Entwicklung und Produktivnahme von Custom Components.

Eigene Komponenten für SSIS (Teil 1)

SQL Server Integration Services (SSIS) ist das Tool der Wahl bei  der Konsolidierung verschiedener Datenquellen. Makroskopische Aufgaben werden in SSIS zu Paketen zusammengefasst, die wiederum aus atomaren Tasks zusammengesetzt sind. Microsoft liefert bereits von Haus aus eine Vielzahl nativer Tasks mit, doch offene Architektur und .NET-Basierung ermöglichen auch Eigenentwicklungen mit vertretbarem Aufwand. In diesem Zusammenhang spricht man von Custom Components.

Das Entwickeln von Custom Components bietet sich an, wenn bestimmte Vorgänge mit nativen Tasks nicht oder nur aufwändig zu realisieren sind und Wiederverwendbarkeit wichtig ist.

Um eine Custom Component zu erstellen, legt man mit Visual Studio ein neues Projekt mit dem Template Class Library an. Über die Referenz PipelineHost wird die auf COM Libraries basierende SSIS Infrastruktur dem .NET Entwickler als managed Wrapper zur Verfügung gestellt.

Für Datenflusskomponenten leitet man die eigene Klasse von PipelineComponent ab. Dabei lassen sich über das Attribut DtsPipelineComponent Eigenschaften wie Typ, Icon und Anzeigename spezifizieren.

   1: [DtsPipelineComponent(// Benutzt SSIS zur Gruppierung für Toolbox-Einträge

   2:                       ComponentType = ComponentType.Transform,

   3:                       // Wird in SSIS in Eigenschaften der Task angezeigt

   4:                       DisplayName = "SDXPerfStat",

   5:                       // Wird in SSIS in Eigenschaften der Task angezeigt

   6:                       Description="Gathering Performance Statistics",

   7:                       // Bild für die CustomComponent im SSIS Data Flow Task

   8:                       IconResource = "SDXPerfStat.performance.ico")]    

   9: public class SDXPerfStat : PipelineComponent

  10: {

  11:     // HIER WEITERE METHODEN FÜR DAS SSIS FRAMEWORK EINFÜGEN

  12: }

Im Laufe des Designs und der Ausführung eines SSIS Paketes treten mehrere Events auf, die auch bei der Paketentwicklung im SSIS Tab Event Handlers sichtbar sind. SSIS ruft nun nach Einbindung der Custom Component in eine Data Flow Task entsprechende Methoden auf, die die Basisklasse PipelineComponent bereitstellt. Der Komponentenentwickler kann nun je nach funktionalem Bedarf keine, eine oder mehrere Methoden der Basisklasse überschreiben um eigene Funktionalität abzubilden. Die wichtigsten dieser Methoden sind im folgenden Aufrufschema dargestellt (links Ausführungsmodus, rechts Designmodus des SSIS-Paketes).

EventMethoden 

Jede dieser Methoden erfüllt spezifische Aufgaben. Beispielsweise überprüft Validate() ob sich die Komponente in einem ordnungsgemäßen Status befindet. Der Komponentenentwickler definiert, welche Prüfungen durchgeführt werden.

In Validate() wird typischerweise überprüft, ob die richtige Anzahl von Input- und Output-Spalten der Komponente vorhanden ist oder ob Eigenschaften richtig gesetzt sind. Entsprechend wird Validate() im SSIS Designmodus mehrfach aufgerufen, damit bei Bearbeitung der Eigenschaften im Advanced Editor jederzeit der Gültigkeitsstatus der Komponente überprüft wird. Validate() gibt an SSIS darüber Informationen zurück mittels eines Kategoriewertes (Corrupt, NeedsNewMetadata u.a.) und eines Fehlertyps. Zum Vergleich eine gültige und zwei ungültige Custom Components im SSIS Designer.

 StatusComp

In der nächsten Folge dieser Serie betrachten wir weitere Methoden und die Einbindung von Custom Components in SSIS.

FileWatcher Task mit SSIS Bordmitteln

Ein typisches Problem in einem produktiven Integration Services Umfeld ist das Erkennen der Fertigstellung eines vollständigen Satzes von Input-Dateien aus Quellsystemen. SSIS soll normalerweise erst starten, wenn der vollständige Satz an Quelldateien vorliegt. Üblicherweise wird der SSIS-Start produktiv jedoch zu festgelegten Zeiten ausgeführt.

Hat das Quellsystem den vollständigen Satz an Input-Dateien noch nicht erzeugt, ist der gesamte ETL-Vorgang eventuell wertlos. Ist das Quellsystem dagegen schon längere Zeit fertig, wird womöglich in der Produktion wertvolle Zeit verschenkt.

Ein Lösungsansatz liegt darin, dass das Quellsystem eine Ready-Datei als Indikator für die Bereitstellung aller Quelldateien erzeugt. SSIS muss jetzt nur noch in regelmäßigen Abständen nach dieser Datei suchen, jedoch nicht ewig warten. Es soll möglich sein, eine Uhrzeit als späteste Startzeit zu setzen. Und das geht so:

  1. Anlegen von zwei String Variablen PackageStartTime und ReadyFilePath. Diese werden beim Paketstart als Parameter gesetzt.
  2. Im Paket wird ein ForLoop Container FLC WaitForReadyFile sowie eine Boolean Variable Wait angelegt, die als EvalExpression ausgewertet wird. Im ForLoop Container wird eine Script Task SCR CheckReadyFile platziert, die u.a. diese Variable setzt.
  3. In der Script Task werden PackageStartTime, ReadyFilePath sowie die aktuelle Uhrzeit ausgewertet. Ist die Ready-Datei noch nicht vorhanden und die späteste Startzeit noch nicht erreicht, bleibt User::Wait auf False und die Loop fährt fort. Der Code verwendet dazu Thread.Sleep(). Ausschnitt:
       1: try

       2: {

       3:     // PackageStartTime (Format 00:00) in dHour und dMin aufspalten

       4:     // ...

       5:     // Späteste erlaubte Startzeit

       6:     DateTime dtMax = DateTime.Today.AddHours(dHour).AddMinutes(dMin);

       7:     // Existiert die Ready-Datei schon ?

       8:     Boolean bReadyFileExists = 

       9:         File.Exists(Dts.Variables["ReadyFilePath"].Value.ToString());

      10:     // Späteste Startzeit erreicht?

      11:     if (DateTime.Now >= dtMax)

      12:     {

      13:         Dts.Variables["Wait"].Value = false;

      14:     }

      15:     // Späteste Startzeit noch nicht erreicht, existiert Ready File schon?

      16:     else if (bReadyFileExists)

      17:     {

      18:         Dts.Variables["Wait"].Value = false;

      19:     }

      20:     // Keine der Abbruchbedingungen erfüllt. Weiter warten.

      21:     else

      22:     {

      23:         Thread.Sleep(WAITING_MINUTES * 60 * 1000);

      24:     }

      25: }

      26: catch(Exception ex)

      27: {

      28:     // Ein Fehler ist aufgetreten. Fehlerhandling + Sofort weiterlaufen

      29:     // ...

      30:     Dts.Variables["Wait"].Value = false;

      31: }

      32:  

  4. Im Anschluss an den ForLoop Container können dann die weiteren Paketobjekte angefügt werden. Das Paket sieht jetzt beispielsweise so aus: Package
  5. Am Ende der Paketausführung nicht vergessen die Ready-Datei wieder zu löschen falls immer der gleiche Name dafür verwendet wird.
  6. Beim Starten des Paketes mit dem SSIS Execute Package Utility können die angesprochenen Paketvariablen mit der Option /SET gesetzt werden.

Ergebnis: Nach dem Starten des Paketes verbleibt die Ausführung so lange in der ForLoop bis die späteste Startzeit erreicht ist oder die Ready-Datei bereitgestellt wurde. Danach wird die weitere Verarbeitung fortgesetzt.

Fazit: Bereits mit SSIS-Bordmitteln lässt sich eine produktionsfähige Filewatcher-Funktionalität aufbauen. Custom Components wie z.B. Konesans Filewatcher Task sind hierzu nicht unbedingt erforderlich. Damit gestaltet sich die Produktivnahme besonders einfach und flexibel.

Konfigurierbare Dateisuche mit Foreach Loop

Wer Dateien aus einem Verzeichnis mit SSIS verarbeiten möchte, verwendet üblicherweise einen Foreach Loop Container mit einem File Enumerator und gibt das Verzeichnis und die Dateimaske an. Leider lässt sich aber hier nur eine einzige Dateimaske verwenden. Doch was tun wenn ein Verzeichnis mehrere Dateien mit unterschiedlichen Namen enthält oder mehrere Verzeichnisse berücksichtigt werden sollen? Etwa mehrere Foreach Loop Container mit jeweils der gleichen Verarbeitung?

Abhilfe schafft hier das Zusammenspiel zweier Foreach Loop Container die aus einer XML Datei gespeist werden. Und das geht so:

  1. Anlegen eines äußeren Foreach Loop Containers, nennen wir ihn FLC DirSpec.
  2. Im Scope von FLC DirSpec zwei String-Variablen anlegen, und zwar FileSpec und Directory. Diese Variablen sollen mit Werten aus einer XML-Datei gefüllt werden und an die innere Loop weitergereicht werden.
  3. Anlegen einer XML-Datei, wobei Directory und FileSpec als Attribute angegeben werden.
       1: <?xml version="1.0" encoding="utf-8" standalone="yes"?>

       2: <Directories>

       3:  

       4:     <DirSpec Directory="D:TestdirDir1" FileSpec="*.zip" />

       5:     <DirSpec Directory="D:TestdirDir1" FileSpec="*.pdf" />

       6:     <DirSpec Directory="D:TestdirDir2" FileSpec="*.bmp" />

       7:  

       8: </Directories>

  4. In der äußeren Loop FLC DirSpec den Enumerator NodeList einstellen und als EnumerationType ElementCollection auswählen. Als OuterXPathString wird mit DirectInput der Eintrag /Directories/DirSpec (siehe Struktur XML-Datei) angegeben und als InnerXPathString @* (alle Attribute) gesetzt. In Variable Mappings sollen entsprechend der Attribut-Reihenfolge in der XML-Datei die Variablen User::Directory und User::FileSpec eingetragen werden.
  5. Jetzt wird die innere Foreach Loop als FLC Filepath angelegt. Diese Loop ist vom Typ FileEnumerator und für die eigentliche Dateisuche verantwortlich. Dazu müssen im Expression Editor Directory und FileSpec auf die in Schritt 4 gefüllten User-Variablen zugeordnet werden.
  6. Anlegen einer Ergebnisvariable User::Filepath und diese eintragen in Variable Mappings bei FLC Filepath. Darin steht dann später bei Paketausführung der vollständige Pfad einer gefundenen Datei.
  7. Innerhalb von FLC Filepath kann nun die eigentliche Dateiverarbeitung platziert werden, die auf die Variable User::Filepath zugreift und für jede gefundene Datei aufgerufen wird. Das Paket sieht damit beispielsweise so aus:ForeachLoop

 

 

 

 

 

 

 

 

 

Ergebnis: Bei Paketausführung wird die XML-Datei von der äußeren Loop gelesen und das Verzeichnis und die Dateimaske jeweils an die innere Loop weitergegeben. Diese sucht dann in den realen Verzeichnissen nach entsprechenden Dateien. Für jede gefundene Datei wird die Verarbeitungsroutine aufgerufen.

Fazit: Durch die Kombination zweier Foreach Loop Container mit einer Konfigurationsdatei kann die Dateisuche sehr flexibel mit SSIS Bordmitteln verwirklicht werden. Es lassen sich auch weitere Konfigurationselemente hinzufügen um beispielsweise Rekursion bei der Dateisuche einzuschalten. Königsdisziplin ist natürlich die Entwicklung eigener Custom Components. Der Aufwand lohnt sich insbesondere wenn spezielle Anforderungen abgedeckt werden sollen und dies standardmäßig nicht ohne weiteres möglich ist.