Lasset die Daten zu mir kommen
Werbung
3 Lasset die Daten zu mir kommen 113 Import der Umsatzdaten des Unternehmens aus dem Altsystem 114 Die Data Transformation Services des SQL Server 2000 116 Die Neuerungen im SQL Server 2005 Import der Umsatzdaten des Unternehmens aus dem Altsystem Der erste Schritt ist getan: Für die wichtigsten Daten der Edikta GmbH gibt es jetzt SQL Server-Tabellen, die aber noch überwiegend leer sind. Der Übergang in diese neue Welt muss für die Firma aber noch realisiert werden, denn bisher ist die gesamte Buchhaltung und die Produktionsplanung hauptsächlich mit Excel-Tabellen realisiert worden – für die Lagerbestände hat mal ein Mitarbeiter eine Access-Datenbank gestrickt, und der Vertrieb erhält die neuesten Verkaufszahlen regelmäßig als Textdatei per E-Mail zugeschickt. Jetzt müssen alle diese Daten in den SQL Server importiert werden – teils nur einmalig, teils muss dies auch regelmäßig zeitgesteuert wieder erfolgen. Die Buchhaltung schließlich traut dem Ganzen noch nicht so recht und wünscht sich ihre Daten als automatischen Excel-Export wieder zurück. Ein erster Blick auf die Altdaten zeigt, dass sich dort auch sehr viel Müll angesammelt hat: In den Excel-Tabellen stehen in vielen Spalten, die eigentlich Geldbeträge enthalten sollten, Dinge wie »k.A.«, »NN« oder »--,--«, die Kosten stehen mal in Euro, mal in Dollar in der Spalte und haben davor » « oder »$« stehen, kurz: Es muss auch viel aufgeräumt und umgerechnet werden. Zunächst wird diese Aufgabe an die Entwickler herangetragen, die natürlich, Entwickler, die sie nun mal sind, sofort ihr Visual Studio starten und für die Importe eigene Programme schreiben wollen. Der IT-Leiter kann dann gerade noch rechtzeitig eingreifen und dies verhindern! Mit Recht wendet er ein, dass ein selbst geschriebenes Importprogramm zwar sehr schick ist, dass es dann aber wieder nur von den Entwicklern angepasst und erweitert werden kann, und die haben doch wirklich schon genug zu tun. Er schlägt vor, für diese Aufgabe die neuen Integration Services von SQL 2005 zu verwenden, und damit die Kopiervorgänge als stets wiederholbare »Pakete« abzuspeichern. Für diese Pakete gibt es eine grafische Oberfläche, die die Bearbeitung auch ohne große Programmierkenntnisse möglich macht. Und als die Entwickler erst sehen, wie schön man die Integration Services auch programmieren kann, machen sie sich 113 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) doch mit großer Freude ans Werk. Schließlich werden einige Abteilungen übergangsweise noch weiter mit ihren Altlösungen arbeiten, und die neu hinzugekommenen Werte müssen inkrementell importiert werden. Wie schon in Kapitel 1 im Abschnitt »This is not your father’s DTS« beschrieben, betritt man bei den neuen SQL Server Integration Services, die die Nachfolge der enorm beliebten Data Transformation Services (DTS) antreten, wirklich eine neue Welt. Aus der Praxis wissen wir, dass die allermeisten Nutzer des SQL Server 2000 Bekanntschaft mit diesem mitgelieferten Import-Export-Tool gemacht haben, und für die meisten war es ein positives Erlebnis. Die Popularität dieses Werkzeugs in der Entwicklerszene war schon kurz nach seinem Erscheinen gewaltig. Legendär sind die vielen Kunden, die ausschließlich z. B. mit Oracle-Datenbanken arbeiten, die aber, von den Import/Export-Möglichkeiten enttäuscht, extra SQL ServerLizenzen gekauft haben, allein um die DTS verwenden zu können. Das ist vor allem verständlich, wenn man weiß, dass andere ETL-Tools1 wie Trillium oder Informatica natürlich mehr können als die DTS, aber dafür auch gerne mal Lizenzgebühren in der Höhe von Jahresgehältern kosten! Die SQL Server Integration Services versuchen nun die Erfolgsgeschichte der DTS bruchlos fortzusetzen. Das betrifft zum einen den Funktionsumfang (der stark erweitert wurde), zum anderen die Grundbegriffe (die gleich geblieben sind). Um den leichteren Übergang in die neue Welt der Integration Services zu schaffen, betrachten wir noch einmal die wesentlichen Komponenten der Vorgänger-Version im Überblick. Dann werden die vergleichbaren Objekte der neuen Version im Detail vorgestellt, bevor wir gemeinsam ein erstes Integration Services Import-Paket erzeugen. Und schließlich erzählen wir noch von unseren liebsten neuen Features! Die Data Transformation Services des SQL Server 2000 Die Data Transformation Services erschienen erstmalig auf dem Markt als integrierter Bestandteil des SQL Server 7.0. Die OLAP-Dienste, die ebenfalls mit dem SQL Server 7.0 eingeführt wurden, sollten zur Realisierung von Data Warehouses2 dienen. Grundlegender Gedanke dabei war, diese Data Warehouses über die DTS mit Daten aus den verschiedensten Produktionsdatenbanken, den so genannten OLTP-Systemen3 zu beliefern. Später erkannte Microsoft das große Potential der DTS und erweiterte im SQL Server 2000 den Funktionsumfang erheblich. Die DTS sind das ETL-Werkzeug des SQL Servers zur Übertragung von Daten, aber auch von Datenbankobjekten und Datenbanken selbst. DTS nutzt OLE DB, um unterschiedlichste Datenquellen anzusprechen. Dadurch werden Verbindungen zwischen SQL Servern und anderen Datenbanksystemen, aber auch zu Text- oder Tabellenkalkulationen ermöglicht. DTS ist quasi 1 ETL bezeichnet den gesamten Extract-Transform-Load-Prozess des Daten-Imports und Daten-»Veredelung« bis hin zur Bereitstellung der Daten für die Nutzer. 2 Data Warehouses oder ihre kleinen Brüder, die »Data Marts«, sind »nur lesen«-Datenbanken, in denen man Daten aus verschiedenen Quellsystemen sammelt, um sie zu analysieren. Um die Abfragen schneller zu machen, wird dabei oft auch die Struktur vereinfacht (weniger Tabellen). 3 OLTP steht dabei für »Online Transaction Processing«, im Gegensatz zur Datenanalyse mit OLAP, dem »Online Analytical Processing«. 114 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) eine universelle Schnittstelle zum Zugriff auf alle Daten, die in einfachen Zeilen- und Spaltenformaten gegliedert sind. Datenübertragsvorgänge werden in so genannten DTS-Paketen entwickelt. Diese Pakete sind ein geschlossener Behälter (Container), in dem die für den jeweiligen Arbeitsschritt benötigten DTS-Komponenten definiert und programmiert werden. Solche Komponenten können Verbindungen, Tasks, Transformationen und der Workflow sein; sie sind natürlich innerhalb jedes Paketes verschieden oder werden in unterschiedlicher Anzahl benötigt. DTS-Verbindungen Eine DTS-Verbindung (Connection) stellt eine Verbindung zu einer anzusteuernden Datenquelle her. SQL Server 2000 nutzt innerhalb der DTS so genannte »OLE DB Data Provider« für die unterschiedlichsten Verbindungen. Die älteren und noch weit verbreiteten ODBC-Schnittstellen werden mit Hilfe der angebotenen Provider für ODBC in ihr entsprechendes OLE DBGegenstück für den SQL Server übersetzt. Darüber hinaus gibt es entsprechend vorgefertigte Anbindungen für Datenquellen wie HTML-Seiten oder Textdateien. Damit man die angebundenen Datenquellen auch nutzen kann, werden in den DTS vordefinierte Arbeitsvorlagen bereitgestellt, die DTS-Tasks. DTS-Tasks, Transformationen und Workflows Abhängig von der Datenquelle und dem Bestimmungsort der Daten sind unterschiedliche Verarbeitungsabläufe notwendig. Um verschiedenste Arbeitschritte zu ermöglichen, sind im DTS als Tasks bezeichnete Vorlagen verfügbar. Mit diesen Tasks kann man einen Datentransfer flexibel programmieren. Der Funktionsumfang ist für das Erstellen durchaus komplexer Datenübertragungsanwendungen ausgelegt. Sollten die von Haus aus vorhandenen StandardTasks nicht ausreichen, so können eigene benutzerdefinierte Tasks (»Custom-Tasks«) im DTSPaket eingebunden werden; dies sind COM-Dlls, die man im Visual Studio selbst programmieren kann. Dadurch ist es möglich, den Funktionsumfang gemäß dem eigenen Bedarf zu erweitern und anzupassen. Für die Transformation von Spalten stehen innerhalb der Tasks Daten transformieren form Data«)- und Datengesteuerte Abfrage (»Data Driven Query«) unterschiedliche nen zur Verfügung. Die Möglichkeiten erstrecken sich hier vom einfachen Kopieren Anwenden von String- und Datums-Funktionalitäten bis hin zur Verwendung von Skripten für spezielle Spaltentransformationen. (»TransFunktioüber das ActiveX- Über den Workflow wird der interne logische Ablauf eines DTS-Pakets festgelegt und gesteuert. Dieser verläuft zwischen den zuvor definierten Objekten wie Tasks und Verbindungen. Der Workflow stellt drei Zustands-Optionen zur Verfügung. Da ein DTS-Paket zwei Beendigungszustände bei der Ausführung eines Objektes kennt, bei Erfolg und bei Fehler, kann durch den Workflow dem betreffenden Endzustand begegnet werden und eine daran orientierte Reaktion erfolgen. Ist diese Unterscheidung nicht nötig, kann durch die dritte Workflow-Option auch unabhängig vom Beendigungszustand bei Abschluss reagiert werden, beispielsweise um eine von Erfolg oder Misserfolg unabhängige Meldung anzuzeigen. Dieser grundsätzliche Aufbau von DTS-Paketen hat natürlich in seiner Basis auch in der neuen Server-Version Bestand. Was ist nun allerdings neu in den Data Transformation Services des Lasset die Daten zu mir kommen 115 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) SQL Servers 2005? Es wird Zeit für einen genaueren Blick auf die SQL Server Integration Services. Die Neuerungen im SQL Server 2005 Neu ist, dass der SQL Server 2005 eine strikte Trennung zwischen Datenbank-Verwaltung und Anwendungsentwicklung verfolgt. Die Applikationsentwicklung erfolgt nun ausschließlich im Business Intelligence Development Studio. Das BI Development Studio ist die Integration der Visual Studio.NET-Entwicklungsumgebung für den SQL Server. Somit zeichnen sich auch im Bereich der ehemaligen DTS, wo man ja die Pakete früher direkt in der Administrationsoberfläche, dem »Enterprise Manager« entwarf, starke Veränderungen ab. SQL Server Integration Services Im Zuge der fünfjährigen Weiterentwicklung wurden die DTS völlig neu entwickelt und in SQL Server Integration Services (SSIS)4 umbenannt. Im Gegensatz zum SQL Server 2000 ist die Verwaltungsoberfläche, das Management Studio, nicht mehr Entwicklungsumgebung für die IS-Pakete, sondern ausschließlich für das Ausführen der auf dem Server hinterlegten (»bereitgestellten«) Pakete verantwortlich. Die IS-Paketentwicklung erfolgt im Business Intelligence Development Studio und ist dort, wie in .NET üblich, als eigenes Projekt realisiert. Dies bedeutet auch, dass man unterschiedliche Entwicklungsstände der Pakete in Versionsverwaltungstools wie »Visual Source Safe« ablegen kann, was die Arbeit im Team an größeren ETLProjekten erleichtert. Ein ganz neuer Bestandteil der IS ist der im Betriebssystem des Servers laufende WindowsDienst mit dem Namen – man höre und staune – »SQL Server Integration Services«. Dieser ist standardmäßig nach der Installation ausgeschaltet und muss gesondert gestartet werden. Dabei kann er dann auch gleich konfiguriert werden, sodass er beim nächsten Systemstart – wie die anderen Serverdienste – automatisch hochgefahren wird. Nötig ist das allerdings nicht etwa dafür, dass die Kopieraufträge etwa unter der Kennung dieses Dienstes laufen, sondern nur dafür, dass man sich Statusinformationen von aktuell laufenden Ladevorgängen abrufen kann. Integration Services-Projekt Zu einem Projekt können ein oder auch mehrere IS-Pakete gehören, die über das Projekt selbst zu einer zusammenhängenden Lösung (»Solution«) zusammengefasst werden. Durch die Kapselung mehrerer Pakete in einer Lösung wird das übergreifende Zusammenwirken der Einzelpakete erleichtert. Weitere Pakete können innerhalb eines bestehenden Projektes problemlos neu erzeugt werden. Bereits existierende Pakete werden einem Projekt hinzugefügt und sind danach Bestandteil dieser Lösung. Auf die gleiche Art und Weise lassen sich Pakete vom Projekt entkoppeln, ohne gleich gelöscht zu werden. Der Entwicklungsumgebung eines Projektes können während der Konstruktion der IS-Pakete unterstützende Datenquellen (»Data Sources«) und Datenquellensichten (»Data Source 4 Der Begriff ist zum Zweck der Vollständigkeit aufgeführt und wird im weiteren Verlauf als Integration Services (IS) bezeichnet. Die Abkürzung »SSIS« ist bei den Amerikanern zwar üblicher, hat aber im deutschen Kulturkreis irgendwie einen üblen Beigeschmack. 116 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Views«) hinzugefügt werden, die auch nur in der Entwurfsphase zur Verfügung stehen. Die Pakete des Projekts können sie innerhalb der Entwicklungsumgebung gemeinsam nutzen. Nach der Weitergabe (»Deployment«) und während der Laufzeit auf dem Server ist der Zugriff auf diese Datenquellen nicht möglich. Dafür benötigt jedes Paket eigene, definierte Verbindungen, die unabhängig vom Projekt sind und über den Verbindungs-Manager (»Connection Manager«) definiert und verwaltet werden. Integration Services-Pakete im Überblick Der wesentliche Unterschied zur Vorgängerversion innerhalb der IS-Pakete besteht auch hier in einer strikten Trennung der Kontrollflusssteuerung vom eigentlichen Datenfluss. Ein Paket besteht immer aus einer Ablaufsteuerung) (»Control Flow«) und optional aus einem oder mehreren Datenflusstasks (»Data Flows«). Ablaufsteuerung Die Ablaufsteuerung besteht aus logisch miteinander verbundenen oder auch in so genannten Containern zusammengefassten Tasks. Die Tasks sind die kleinsten in der Ablaufsteuerung enthaltenen Ausführungseinheiten, wobei der Datenflusstask (»Data Flow Task«) die eigentliche Datenfluss-Pipeline darstellt, die gesondert implementiert werden muss. Die logische Aufeinanderfolge der Tasks, schon als Workflow bekannt, verknüpft die Objekte untereinander mit den bekannten Bedingungslogiken bei Erfolg, bei Fehler und bei Abschluss. Die in der Ablaufsteuerung enthaltenen Tasks sind durch Container gruppierbar und bilden damit eine zusammenhängende logische Einheit bezüglich des äußeren Workflow. Innerhalb dieser Container werden die enthaltenen Tasks dann über eine innere Workflow-Logik miteinander verbunden. An dieser Stelle ist eine Abgrenzung des inneren vom äußeren Task-Ablauf durch den Container zu erkennen. Zusätzlich sind die Container dazu gedacht, die in ihnen gruppierten Tasks als Schleife auszuführen, eine neue Fähigkeit, die bei der Vorversion noch schmerzhaft gefehlt hat. Abbildung 3.1 zeigt eine Ablaufsteuerung in der Übersicht. Lasset die Daten zu mir kommen 117 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Abbildung 3.1: IS-Paket-Designer mit Tasks innerhalb der Ablaufsteuerung Datenfluss Der Datenfluss (»Data Flow«) ist ein Task der Ablaufsteuerung; in ihm werden dann wirklich die Daten übertragen. In der Ablaufsteuerung ist er als ungefüllter Baustein enthalten, der ohne weitere Entwicklung ineffektiv bleibt. Im Datenfluss sind aber auch weitere spezifische Tasks enthalten, die speziell auf die Übertragung und Transformation von Daten aus verschiedensten Quellen und mit den unterschiedlichsten Zielen abgestimmt sind. Die Bandbreite reicht vom Textdatei-Zugriff über Aggregat-Funktionen und programmierbare Visual Basic.NET-Skripte bis hin zum Zusammenfassen oder »Splitten« von Datenabfrage-Ergebnissen für eine getrennte oder zusammengefasste Übergabe der Ergebnisse. Die Komponenten werden wie in der Ablaufsteuerung in logischer Abfolge miteinander verbunden. Dabei ist der Output des vorhergehenden Tasks der zu bearbeitende Input für den anschließenden Task. Näheres wird dazu später noch im Abschnitt »Flatfilequelle und Verbindungs-Manager-Editor für Flatfiles« ausgeführt. Abbildung 3.2 zeigt Ablaufsteuerung und Datenflusstasks im Überblick. 118 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Abbildung 3.2: Zusammenhang zwischen Ablaufsteuerung und Datenfluss Wie in der Abbildung zu erkennen, ist der gesamte Designer umfangreicher gestaltet als beim SQL Server 2000. Sämtliche im BI Development Studio enthaltenen Komponenten basieren auf .NET. Neben den getrennt zu entwickelnden Ablaufsteuerungen und Datenflusstasks ist eine umfangreiche Verwaltung von Ereignishandlern (»Event Handlern«) verfügbar. Ereignishandler Der Ereignishandler (»Event Handler») gibt uns die Möglichkeit, auf die Ereignisse eines Paketes, Tasks oder Containers zu reagieren, die von einem dieser Objekte während der Laufzeit ausgelöst werden. Jedes Objekt und das Paket selbst besitzen eigene Ereignishandler, die eine Reihe von Ereignissen beinhalten, auf die wir wahlweise reagieren können. In jedem dieser Zustände stehen, genau wie bei der Programmierung eines Paketes, eine Ablaufsteuerung und wiederum optional auch Datenflusstasks zur Verfügung. Damit ist es möglich, über jeden dieser wählbaren Zustände ein weiteres IS-Paket, z. B. für einen alternativen Ablauf, zu implementieren. Abbildung 3.3 zeigt rechts die programmierbaren Ereignisse des Ereignishandlers für einen ausgewählten Task der ursprünglichen Ablaufsteuerung. Lasset die Daten zu mir kommen 119 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Abbildung 3.3: Beispiel für einen umfangreichen Ereignishandler Da jedes hier angelegte Objekt selbst wieder Ereignisse auslöst, besteht die Möglichkeit, innerhalb des gerade bearbeiteten Ereignisses – denn es handelt sich ja auch um ein IS-Paket – weitere Ereignishandler zu integrieren. Das heißt, jedes hier aktivierte und entwickelte Ereignis stellt wieder ein eigenes IS-Paket dar. Damit lässt sich eine abhängige, durch die Ereignishandler geschachtelte Struktur alternativer Ablaufmöglichkeiten erzeugen, die an das Paket gebunden sind und mit ihm zusammen gespeichert werden. Jedes implementierte Ereignis ist selbst ein Paket und unterstützt diese Funktionalität in vollem Umfang. Eine Struktur verschachtelter Ereignisse zeigt Abbildung 3.4 Abbildung 3.4: Darstellung der Verschachtelungsmöglichkeiten des Ereignishandlers Die abgebildete Strukturierung zeigt eine erweiterte Steuerung des Paketablaufes durch eine gezielte Reaktion auf vordefinierte Ereignisse des Ereignishandlers. Damit können also innerhalb eines Paketes weitere vollständige Paket-Logiken entwickelt und eingebunden werden. Das bedeutet, dass ein IS-Paket jetzt unter Umständen aus mehreren ineinander geschachtelten Paketlogiken besteht, und das noch zusätzlich zum ohnehin möglichen Workflow. Durch die Erweiterung mit Ereignishandlern kann man also jetzt IS-Pakete flexibler und umfangreicher gestalten als in der vorherigen Version. Klar, dass dadurch auch die Fehlersuche 120 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) viel komplexer wird. Deshalb tut es gut zu wissen, dass es auch einen ebenfalls neuen, integrierten Debugger gibt. Integration Services-Debugger Die Entwicklungsumgebung ist mit einem Debugger ausgerüstet, der die Fehlersuche beim Entwerfen von Paketen unterstützt. Beim Standardlauf eines Paketes in der Business Intelligence Development Studio-Umgebung ist der Debugger grundsätzlich eingeschaltet. Er kann aber über den Menüeintrag Debuggen/Starten ohne Debuggen umgangen werden. Eine neue Möglichkeit bei der IS-Entwicklung sind die Haltepunkte (»Breakpoints«). Sie können auf die einzelnen Zustände des Ereignishandlers gesetzt sein, wie z. B. OnPreExecute oder OnInformation. Das heißt aber nicht, dass auch ein Ereignishandler für dieses Ereignis in diesem Task existieren muss. Die Haltepunkte arbeiten lediglich mit den gleichen Ereignissen, die auch der Ereignishandler nutzt. Abbildung 3.5. zeigt die Haltepunkte-Konfiguration eines Tasks. Dieses Task-Menü steht uns nur in der Ablaufsteuerung zur Verfügung und ist durch einfachen Rechtsklick auf den Task unserer Wahl und die anschließende Menüwahl Haltepunkte bearbeiten zu erreichen. Abbildung 3.5: Konfigurationsmenü der Haltepunkte eines Ablaufsteuerungstasks Wie in der Abbildung gut zu erkennen ist, haben wir hier nicht nur die Wahl zwischen den unterschiedlichsten Ereignissen, sondern auch noch die Möglichkeit festzulegen, wann unser Haltepunkt aktiviert werden soll. Ein kleines Beispiel dazu: Wir haben eine Schleife in unserem Paket eingebaut, und in jedem der Testdurchläufe tritt ab der zweiten von insgesamt zehn Wiederholungen der Schleife ein Fehler auf. Nun wäre es recht anstrengend, wenn jedes Mal während der Fehlersuche schon beim ersten Auftreten eines Fehlers der Haltepunkt ausgelöst würde. Interessant wäre es ja, den dritten oder vierten Punkt zu untersuchen. Es ist ja nicht ungewöhnlich, in alternativen Abläufen mit bestimmten Fehlertoleranzen zu arbeiten. Um das zu ermöglichen, kann hier über den Typ der Trefferanzahl (»Hit Count Type«) bzw. über die Trefferanzahl) (»Hit Count«) die Bedingung und nötige Anzahl des Auftretens für jedes zur Verfügung stehende Ereignis festgelegt werden. Der Typ der Trefferanzahl sagt dabei aus, ob der Haltepunkt z. B. bei immer, gleich oder größer als oder mehrfach ausgelöst werden soll. Die Lasset die Daten zu mir kommen 121 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Trefferanzahl selbst gibt die Anzahl an, wie oft das definierte Ereignis eintreten muss, um den Haltepunkt zu aktivieren. Für unser Beispiel würde das bedeuten, dass wir den Typ der Trefferanzahl des Ereignisses OnError auf den Eintrag Trefferanzahl ist gleich und die Trefferanzahl selbst auf die Anzahl 3 setzen müssen, um den Haltepunkt beim dritten auftretenden Fehler zu aktivieren. Damit stoppt die Ablaufsteuerung dann, wenn das von uns definierte Ereignis zum dritten Mal auftritt, und das Paket wird an der von uns konfigurierten Position unterbrochen; das kann wahlweise ein Task oder auch ein Container sein. Über weitere Debug-Optionen kann man dann den Zustand des Paketes und seiner Komponenten während der Laufzeit näher betrachten. Unabhängig davon wird beim Ausführen eines Paketes im Debug-Modus in einem AusgabeFenster der während des Paketlaufes gesetzte Erfolg- oder Misserfolgstatus mit entsprechender Meldung angezeigt. Meistens wird der auftretende Fehler dabei näher erläutert, was für die Fehlersuche innerhalb des Paketes während der Entwicklung hilfreich ist. Wird ein Paket im Debug-Modus gestartet, so zeigen farbliche Kennzeichnungen der Komponenten beim Durchlauf deutlich den Ausführungszustand an. Die farblich gekennzeichneten Ausführungszustände kann man auf Abbildung 3.6 in Aktion sehen. Abbildung 3.6: Paketdurchlauf mit den Ausführungszuständen der Tasks Neben der farblichen Kennzeichnung der einzelnen Ausführungsschritte lässt sich der Ablauf eines Paketes anhand der Status-Registerkarte im Zusammenhang betrachten. Dabei wird das Paket und jeder innerhalb des Paketes tatsächlich ausgeführte Task mit einer Start- und Endzeit sowie einer Ausführungsdauer ausgewiesen. Die Darstellung richtet sich dabei nach dem real durchlaufenen Workflow und lässt ungenutzte Tasks unberücksichtigt. 122 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Die Darstellung des Prozessablaufes, wie in Abbildung 3.7 zu sehen, ist keine grundlegend neue Innovation des SQL Server 2005. In der Vorversion wurde die Ausführung eines Paketes ebenfalls grafisch dargestellt und die durchgeführten Tasks inklusive Ausführungszeiten ausgegeben. Die neue Prozesslaufübersicht ist jedoch wesentlich übersichtlicher gegliedert, und sie gibt die Durchführungsdauer im Gegensatz zum Vorgänger mit einer Genauigkeit von tausendstel Sekunden an, was die Prüfung von Performancegewinnen bei der Entwicklung von Alternativlösungen vereinfacht. Abbildung 3.7: Zusammenhängender Paketablauf in der Status-Registerkarte Nun schauen wir uns im folgenden Abschnitt die Realisierung von Paketen etwas genauer an. Dabei werden wir das erste Beispielpaket für einen Datenimport aus einer Textdatei in eine SQL Server Tabelle gemeinsam entwickeln. Entwicklung von Integration Services-Paketen auf dem SQL Server 2005 Der Softwareentwickler, der sich zum ersten Mal den neuen Integration Services gegenübersieht, wird sich vielleicht durch die vertraute Visual Studio-Umgebung nicht ganz so fremd fühlen. Für den Administrator oder den Data Warehouse-Designer ist es unbekanntes Terrain, das sich da vor ihm auftut. Um das Hineinfinden in diese Umgebung zu erleichtern, ist es vielleicht am besten, wenn man sich einmal an das System setzt und einen einfachen Import selbst durchführt. Zur nachfolgenden gemeinsamen ersten Paket-Entwicklung auf dem SQL Server ist eine entsprechende Server- und Business Intelligence Development Studio-Umgebung erforderlich. Dazu muss man eine Instanz des SQL Server 2005 zusammen mit der Entwicklungsumgebung Lasset die Daten zu mir kommen 123 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) auf einem Rechner installiert haben. Ist dies geschehen, betrachten wir uns erst einmal das mitgelieferte Portierungswerkzeug des SQL Servers. Migration von Paketen aus dem SQL Server 2000 Die denkbar einfachste Variante zur Übernahme bestehender DTS-Pakete aus den Vorversionen des SQL Servers ist die Benutzung eines von Microsoft im BI Development Studio integrierten Paketmigrations-Assistenten (»SSIS Migration Wizard«). Dieser dient dazu, DTSPakete der Serverversionen 7.0 und 2000 in ein IS-Projekt im BI Development Studio zu übertragen. Die Portierung kann entweder durch eine direkte Verbindung zum Quellserver der Pakete durchgeführt werden, oder man bindet die Pakete als so genannte Strukturierte Speicherdateien (»Structured Storage Files«) ein, sofern diese vorher von DTS gespeichert worden sind. Strukturierte Speicherdateien sind Sicherungen der bisherigen Pakete im Dateiformat .dts. Über einen intuitiven Dialog mit dem Assistenten wird die Zusammenstellung der zu portierenden Pakete vereinfacht. Wahlweise kann der Start des Assistenten über den Menü-Eintrag Projekt/DTS 2000-Paket migrieren oder per Rechtsklick auf den Ordner SSIS-Pakete (»SSIS Packages«) ausgewählt und gestartet werden. Der Paketmigrations-Assistent importiert danach die ausgesuchten Pakete in das geöffnete Projekt und übernimmt dabei den Workflow, die Serververbindungen sowie angelegte Variablen und deren Werte in vollem Umfang. Es sind jedoch ausschließlich DTSPakete portierbar, die keine selbst entwickelten Benutzerdefinierten Tasks (»Custom Tasks«) enthalten. Damit eignet sich der Paketmigrations-Assistent nur zur Übernahme von Paketen, die ausschließlich aus den klassischen Tasks der herkömmlichen DTS zusammengesetzt sind. Das sind traurige Nachrichten für die vielen Entwickler, die Mannjahre in DTS-Pakete gesteckt haben, die maßgeblich mit Eigenentwicklungen bestückt sind. Leider lag gerade in der leichten Erweiterungsmöglichkeit für viele der Hauptgrund, DTS einzusetzen. Weil die Migration von alten DTS-Paketen mit dem Assistenten nur eingeschränkt möglich ist, muss man jedes Paket neu entwerfen, das Eigenentwicklungen enthält. Dabei gibt es natürlich die Möglichkeit, aus einer Kopie des Originalpaketes sämtliche Eigenanpassungen zu entfernen, um wenigstens das Grundgerüst der Standard-Tasks per Assistent übertragen zu können. Realisierung von Paketen Betrachten wir uns nun jedoch die Realisierung eines neuen Paketes genauer, das dazu dienen soll, Daten aus einer Excel- bzw. .csv-Datei5 auszulesen und in eine dafür vorgesehene Tabelle des SQL Servers zu übertragen. Dazu werden einerseits eine entsprechende Zieltabelle auf dem SQL Server und andererseits ein entsprechendes IS-Projekt benötigt, in welchem das Paket für den Import von Daten – hier sind es Kundenadressen – entworfen wird. Die .csvDatei hat folgenden Inhalt und wartet lediglich auf das Auslesen durch das zu entwickelnde ISPaket. KundenNr Titel 1 2 5 Dr. Anrede Name Vorname Strasse Herr Peter Schmidt Im Winkel Herr Ulrich Lehmann Hauptstrasse HausNr PLZ Wohnort 2 12345 München 43 54321 Freiburg CSV-Dateien können aus einer Excel-Datei heraus erzeugt werden und bilden die tabellarische Struktur der XLS-Daten mit Hilfe von einfachen Trennzeichen (Tabulator, Komma, Semikolon) im Textformat ab. 124 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) KundenNr Titel Anrede Name Vorname Strasse HausNr PLZ Wohnort 3 Frau Ulrike Schulze Nebengasse 12 34521 Hannover 4 Frau Karolin Müller Gartenweg 56 24531 Dortmund 5 Herr Hans Strasser Am Brunnen 17 a 42531 Hamburg Tabelle 3.1: Beispieldaten für einen IS-Import Die vorgegebene Tabelle 3.1 enthält die zu importierenden Kundendaten, wobei die Spaltenbezeichnungen in der ersten Zeile enthalten sind. Um die Möglichkeiten der Integration Services darzustellen, beginnen wir zuerst mit der Erzeugung des entsprechend notwendigen ISProjektes im Business Intelligence Development Studio, welches man nach der Installation des SQL Servers im Programmordner Start/Programme/Microsoft SQL Server 2005 vorfindet. Nach dem Start des BI Development Studio legen wir zuerst ein neues Projekt an, wobei wir uns im Dialog für ein IS-Projekt entscheiden, welchem dann eine entsprechende Bezeichnung (in unserem Fall ISProjekt_Kunden) zuteil wird. Bitte nicht vergessen, das Ablageverzeichnis für dieses Projekt festzulegen, damit aufwändige Suchaktionen nach den Projektdateien unnötig bleiben. Mit der Bestätigung dieses Dialoges wird das erste IS-Projekt ins Leben gerufen und als leere Projektmappe (»Solution«) implementiert. Standardmäßig wird ein IS-Paket angelegt und dem Entwickler ebenfalls ungefüllt zur Verfügung gestellt. Abbildung 3.8 zeigt das erzeugte zusammenhängende Projekt. Abbildung 3.8: Standard-Projektlösung nach dem Anlegen eines Projektes Um nun den einfachen Import der Kundendaten in eine SQL Server Tabelle zu verwirklichen, muss zuerst die Ablaufsteuerung und danach der Datenfluss des Paketes »Package.dtsx« entworfen und für den Datenimport spezifiziert werden. Der erste Import – das erste Paket Für die erste Version unseres Kundendatenimports wird innerhalb des Ablaufsteuerung zuerst ein Datenfluss angelegt. Dies erfolgt durch dessen Auswahl innerhalb der bereitgestellten Toolbox, in der sämtliche nutzbaren Tasks der Ablaufsteuerung bereitliegen. Der so erzeugte Datenfluss kann nun weiter entwickelt werden. Durch einen Wechsel auf die Registerkarte Datenfluss, stehen uns plötzlich ganz andere Tasks als in der Ablaufsteuerung zur Verfügung. Die Tasks des Datenflusses sind unterteilt in Datenflussquellen (»Sources«), Datenflusstransformationen (»Transformations«) und Datenflussziele (»Destinations«) und sind damit eigens für Datenübertragungen ausgelegt. Zwischen Quelle und Ziel der Daten können damit jede Menge Datentransformationen durchgeführt werden, doch dazu kommen wir später, im Abschnitt »Datentransformationen mit Tasks«. Lasset die Daten zu mir kommen 125 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Für den Zugriff auf die aus dem Excel heraus erzeugte .csv-Datei benötigen wir nun eine Flatfilequelle (»Flat File Source«) aus der zur Verfügung gestellten Toolbox. Diese können wir einfach per Drag&Drop dem Paket hinzufügen. Interessant ist an dieser Stelle, dass der so erzeugte Task sofort als fehlerhaft ausgewiesen wird, da noch keine Verbindung angelegt oder andere Einstellungen vorgenommen worden sind. Also definieren wir zuerst unsere neu erzeugte Datenquelle. Flatfilequelle und Verbindungs-Manager-Editor für Flatfiles Im Konfigurationsmenü unter dem Punkt Verbindungs-Manager (»Connection Manager«) muss man nun entweder eine neue Verbindung zur Datei anlegen, oder man benutzt eine vordefinierte Verbindung, falls die gewünschte Dateianbindung schon existiert. Bereits definierte Verbindungen bleiben erhalten, selbst wenn der Task entfernt wird, der sie benutzt hat; sie müssen gesondert gelöscht werden. Wenn die Verbindung neu erzeugt wird, befinden wir uns im nächsten Konfigurationsmenü – dem Menü für den Verbindungs-Manager-Editor für Flatfiles (»Flat File Connection Manager»«). Dieser Manager wird DTS-Entwicklern der 2000er Version in seiner Oberfläche nicht völlig unbekannt sein. Im Menüpunkt Allgemein (»General«) kann man die Verbindung genauer bezeichnen und die einzulesende Datei über den Dateibrowser genau definieren. Das sieht dann für unser Szenario wie in Abbildung 3.9 aus. Abbildung 3.9: Verbindung zu einer Textdatei herstellen – erstes Menü Ebenfalls bekannt aus der Vorgängerversion sind die Einstellungen des Menüpunktes Spalten (»Columns«), in dem ersichtlich und damit prüfbar wird, dass die erste Zeile der .csv -Datei tatsächlich als Spaltenbezeichnung für die Importdaten genutzt wird, und dass die Trennzeichen zwischen den Datenspalten auch ordnungsgemäß funktionieren. 126 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Abbildung 3.10: Verbindung zu einer Textdatei herstellen – zweites Menü Bis hier entspricht die Konfiguration der DTS-Pakete dem SQL Server 2000. Spannend wird es nun im Menüpunkt Erweitert (»Advanced«), der mit seiner Bezeichnung für sich selbst spricht. An dieser Stelle kann bereits aus der Verbindung heraus jede Spalte gesondert spezifiziert werden. Das bezieht sich insbesondere auf die Spaltenbezeichnung und den Datentyp. Um das Entwicklerleben zu versüßen, hat Microsoft in diesem Menü eine »Typ-Vorschlagsfunktion« integriert. Damit wird eine automatisierte Quelldatenanalyse ermöglicht. Die Tiefe der Analyse ist durch Angabe der zu prüfenden Zeilenanzahl selbst bestimmbar! Das System ermittelt die potentiellen Datentypen anhand des Quelldatei-Inhaltes. Die passenden Vorschläge werden dann im erweiterten Einstellungskontext der Verbindung angeboten und für jede der Spalten eingetragen. Damit wäre dann das Verbindungs-Manager-Menü definiert und für den weiteren Verlauf nutzbar. Abbildung 3.11: Verbindung zu einer Textdatei herstellen – drittes Menü Lasset die Daten zu mir kommen 127 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Im Anschluss daran stellen wir mit der noch nicht abgeschlossenen Konfiguration der Flatfilequelle den Verweis zwischen der Verbindung und dem Datenfluss her. Die definierte Verbindung des Tasks wird dazu genutzt, die spezifizierten Spalten aus der Verbindung zur Textdatei zu übernehmen und dem anschließenden Task als Ausgabe-Spalten bereitzustellen. Dabei können die Spalten wiederum direkt bezeichnet werden, um sie später besser zuordnen zu können. Wir besitzen damit im Gegensatz zur Vorversion also zwei Ansatzpunkte, um Datenspalten direkt aus der Datei heraus bezeichnen zu können. Das Mapping der Spalten aus der Textdateiverbindung und dem Task ist im Menü Spalten (»Columns«) – richtig, das existiert in der Flatfilequelle auch noch einmal – übersichtlich angeordnet und erlaubt uns im Bereich Externe Spalte (»External Column«) (das sind die Spalten der Verbindung zur Textdatei) eine komfortable Spaltenauswahl per Dropdown-Menü. Die Ausgabespalte (»Output Column«) bildet den Bereich der Task-Ausgabe ab, der den sich anknüpfenden Tasks als Eingabespalten zur Verfügung gestellt wird. Und genau hier liegt die zweite Möglichkeit der Spaltenbezeichnung, wie man in der Abbildung 3.12 am Beispiel der »Kundennummer« sieht. Abbildung 3.12: Spaltenzuweisung der Flatfile-Verbindung im Quelleneditor für Flatfiles Das Zusammenwirken von Verbindung zur Textdatei und Task stellt die Daten der .csv-Datei generell für die weitere Verarbeitung bereit. In unserem Beispiel werden wir nun direkt dazu übergehen, diese Daten in eine SQL Server-Tabelle zu überführen. SQL Server-Ziel Dazu benötigen wir ein SQL Server-Ziel (»SQL Server Destination«) innerhalb des Datenflusses, die man genauso leicht per Drag&Drop hinzufügen kann. Nun muss diese noch konfiguriert werden, was sofort durch das im Task enthaltene Fehlersymbol ersichtlich wird. Wir öffnen einfach mit einem Doppelklick das Konfigurationsmenü und landen wieder umgehend bei den Einstellungen zum Verbindungs-Manager. Viele werden jetzt eine Warnung mit folgendem Wortlaut bekommen haben: »Diese Komponente besitzt keine verfügbaren Eingabespalten« 128 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) (»This component has no available input columns«). Ja, genau – bevor wir das SQL ServerZiel konfigurieren, sollte auch klar sein, was es zu verarbeiten hat. Deshalb stellt man an dieser Stelle zuerst die Verbindung zur Quelle – also zu der zuvor definierten Flatfilequelle – her und stellt damit deren Ausgabedaten zur Verarbeitung bereit. Dazu ziehen wir den grünen Pfeil der Quelle (»Source«) auf das Ziel (»Destination«). Das war es schon. Nun konfigurieren wir den Verbindungs-Manager. Bei Klick auf die Schaltfläche Neu (»New«) stellt sich dieser ein wenig anders dar als zuvor. Wir wollen einen Zugriff zum SQL Server konfigurieren, man erzeugt aber nur eine neue OLE DB-Verbindung, die auf den SQL Server zugreifen soll. Abbildung 3.13 zeigt das Konfigurationsmenü mit erfolgreichem Verbindungstest. Abbildung 3.13: Konfiguration des OLE DB Verbindungs-Manager Also suchen wir uns an dieser Stelle den Ziel-Server und auf diesem die Ziel-Datenbank für unsere zu überführenden Kundendaten heraus. Dann ist die erste OLE DB-Verbindung konfiguriert, und wird auch sogleich für das SQL Server-Ziel verwendet. Die Abbildung 3.14 zeigt uns das Konfigurationsmenü im Zusammenhang. Lasset die Daten zu mir kommen 129 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Abbildung 3.14: Erzeugen einer Tabelle durch Konfiguration des SQL ServerZiels Interessant an dieser Stelle ist weniger, dass wir auf der zuvor definierten Datenbank die ZielTabelle wählen können, sondern dass es auch möglich ist, innerhalb dieses Kontextes eine ZielTabelle zu erstellen. Das wirklich Nützliche dabei ist aber, dass man nur durch das Drücken der Neu-Schaltfläche eine CREATE TABLE-Anweisung in SQL-Syntax erhält, die in Struktur und verwendeten Datentypen genau der Ausgabe der Flatfilequelle entspricht. Abbildung 3.15: Spaltenzuweisung zwischen Eingabespalten und gerade erzeugten Spalten der Tabelle 130 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Damit ist es nicht notwendig, zuvor eine mit Struktur und Datentypen übereinstimmende SQL Server Tabelle von Hand auf dem Server zu erzeugen, die bei einer Änderung der Datenimportstruktur innerhalb des Paketes als Zieltabelle ohnehin nicht mehr zu gebrauchen wäre. Wie in Abbildung 3.15 gut zu erkennen, findet vom System eine automatisierte Spaltenzuordnung statt, wenn Eingabe- und Zielspalten die gleiche Bezeichnung tragen. Dies kann natürlich manuell angepasst werden bzw. muss sogar manuell durchgeführt werden, wenn die Bezeichnungen keine Übereinstimmung aufweisen. Damit wäre der erste Datenfluss fertig gestellt und bereit für den Testlauf, um die ersten Daten zu übertragen. Bereitstellung und zeitgesteuerte Ausführung Ist das erste Paket erst einmal fertig gestellt und getestet, kommt in der Regel der nächste Schritt, nämlich die Bereitstellung (»Deployment«), des Pakets; auf einen Server, auf dem es dann gespeichert liegt, und auf dem es in Zukunft auch zeitgesteuert ausgeführt werden kann. Diese Bereitstellung ist nur mit dem gesamten Projekt und nicht für einzelne Pakete durchführbar. Dazu muss durch einen Rechtsklick auf das Projekt im Projektmappen-Explorer der Menüeintrag Eigenschaften des Projektes geöffnet werden. Danach öffnet sich das in Abbildung 3.16 dargestellte Konfigurationsmenü des Projekts. Nun wählen Sie den Eintrag Bereitstellungsprogramm (»Deployment Utility«), und die beiden ersten Einträge, wie in der Abbildung zu sehen, setzen Sie auf True. Abbildung 3.16: Konfiguration des Projektes für die Bereitstellung Die Angabe des DeploymentOutputPath erzeugt unter Verwendung des Standardeintrags den Ordner Deployment im Verzeichnis Projekt-Name/bin, in dem sämtliche für die Weitergabe notwendigen Dateien hinterlegt werden. Diese Einstellungen bestätigen Sie mit OK und wechseln nochmals mit einem Rechtsklick auf das Projekt. Dort wählen Sie nun den Eintrag Erstellen (»Build«), und das System erzeugt die nötigen Bereitstellungsdateien. Danach befindet sich, wenn es zu keinem Fehler kommt, im beschriebenen Ordner Deployment eine Datei mit der Endung SSISDeploymentManifest. Beim Starten dieser Datei öffnet sich der in Abbildung 3.17 Lasset die Daten zu mir kommen 131 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) abgebildete Paketinstallations-Assistent (»SSIS Package Installer«), mit dessen Hilfe nun die Pakete auf den von uns gewählten SQL Server übertragen werden, wo sie anschließend ausführbar hinterlegt sind. Abbildung 3.17: Integration Services Paketinstallations-Assistent Dialog Aber wie wird dieses Paket nun immer wieder z.B. jede Nacht um 23:00 ausgeführt? Dazu muss man aus der Entwurfsoberfläche zum SQL Server Management Studio wechseln und das eben übertragene Projekt mit einem oder mehreren enthaltenen Paketen ausführen. Bei oberflächlicher Betrachtung sind diese gar nicht vorhanden. Sind sie aber schon – es existiert nur kein eigener Ordner dafür in der Oberfläche, wie es beim SQL Server 2000 der Fall war. Als erfahrene Entwickler wissen wir natürlich eines: Es muss nicht alles zu sehen sein, was physisch vorhanden ist. Lassen Sie sich deswegen nicht beirren, und legen Sie einfach im SQL Server-Agent einen neuen Auftrag (»Job«) an. Dort klicken Sie auf Schritte (»Steps«) und anschließend auf Neu (»New«); im Dropdown-Menü wählen Sie den Eintrag für die IS-Pakete. Danach suchen Sie noch den richtigen Server aus (vorzugsweise den, auf dem wir gerade das Projekt bereitgestellt haben) und klicken auf den Erweiterungsbutton unter dem Eintrag Paket: Da sind sie dann auch, wie in Abbildung 3.18 zu sehen, die mit viel Mühe, Schweiß und Liebe entwickelten Pakete. Nun nehmen Sie nur noch die bereits bekannten Einstellungen vor und schon haben Sie das erste Paket als Job auf dem Server integriert. 132 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Abbildung 3.18: SQL Server-Agent Konfiguration Nützliche und neue Tasks der Ablaufsteuerung Eine der nützlichsten Features der DTS von SQL 2000 besteht darin, dass man eigene Variablen, so genannte DTSGlobalVariables, für ein Paket erzeugen kann, auf deren Inhalt man dann aus jedem Paketschritt heraus zugreifen kann. Meist geschieht dieser Zugriff aus selbst geschriebenen Skripten, und die »alten Hasen« der DTS fragen sich mit Sicherheit, was wohl ActiveX-Skripte in den Integration Services zu leisten im Stande sind. Nun, die Benutzung von ActiveX-Skripten ist nach wie vor möglich, sie werden bei Nutzung des PaketmigrationsAssistenten auch ohne Mängelanzeigen übernommen. Der Zugriff auf die Variablen des ISPaketes wird dagegen nicht mehr unterstützt. Das neue Konzept der Entwicklung erlaubt diesbezüglich nur die Nutzung von VB.NET-Skripten. Damit ist man gezwungen, sämtliche vorhandenen ActiveX-Skripte, die die Variablen eines Paketes be- und verarbeiten, in entsprechende VB.NET-Anwendungen umzuschreiben. Das führt bei einigen Anwendungen, die mit ActiveX-Skripten gespickt sind, zu einem erheblichen Aufwand. Demgegenüber steht allerdings die verbesserte Handhabung von Paketvariablen innerhalb der Integration Services, die über die einmalige Mühe bei der Umstellung hinwegtrösten sollte. Lasset die Daten zu mir kommen 133 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Variablen des IS-Paketes und Task ‘Paket ausführen’ Die Übersicht und Handhabung der in einem Paket definierten Variablen ist deutlich erweitert worden. Im so genannten Paket-Explorer (»Package Explore«r) sind sämtliche im Paket verfügbaren Komponenten enthalten und nach Objektkategorien übersichtlich gegliedert. So findet man unter dem Eintrag Variablen (»Variables«) die gesamte Reihe der im Paket verwendbaren Variablen wieder. Neu daran ist die Erweiterung um systemeigenen Paketkonstanten mit lesendem Zugriff. Alle zusätzlich von uns erzeugten Variablen sind farbig hervorgehoben. Auch diese sind über die Einstellung ihrer Eigenschaften für einen schreibenden Zugriff sperrbar, um die unabsichtliche Änderung von einmal fest zugewiesenen Werten unterbinden zu können. Neu ist auch, dass ungefüllte Variablen, die erst während der Laufzeit ihre Werte zugewiesen bekommen, bei Beendigung des Paketes wieder vollständig geleert werden. Das heißt, im Gegensatz zum vorhergehenden DTS bleiben uns gesetzte Laufzeitwerte (von uns selbst eingetragen oder von anderen Tasks gesetzte Werte) nicht in den Variablen erhalten. Damit sind Skripte, mit denen man beim Start eines Pakets die Variablen erst mal leeren musste (»Sind sie denn auch wirklich leer?«) entbehrlich. Abbildung 3.19 zeigt uns hier sehr übersichtlich die Zusammenstellung der IS-Paketvariablen. Abbildung 3.19: Nutzer- und SystemVariablen des IS-Paketes Besonders kompliziert wird es, wenn man diese Variablen von einem Paket an das andere übergeben möchte. Will man seinen ETL-Vorgang in verschiedene Pakete zerlegen, also modularisieren, ist dies unabdingbar! Bei den DTS ging das auch schon, aber manche Nutzer hatten sicherlich bisher ihre Probleme dabei, den verwirrenden Dialog des Tasks ‚Paket ausführen’ (»Execute Package Task«) bezüglich der Übergabe von Variablen an ein weiteres auszuführendes Paket (»Child Package«) schnell und sauber zu konfigurieren. Dabei war auch die Rückgabe von ermittelten Werten an die Variablen des aufrufenden Paketes nur indirekt möglich, nämlich nur, indem man den kompletten Aufruf des Kind-Pakets über ActiveX-Skripte realisiert und komplett auf den Task ‚Paket ausführen’ verzichtet. Auch diese ActiveX-Skripte, die den Task ‚Paket ausführen’ ersetzen sollten, sind nun mit den Integration Services entbehrlich. Der Workflow, der sich an das aufgerufene Paket anschließt, bekommt auch den Ausführungsstatus (was ehemals ja nicht immer reibungslos verlief) völlig unproblematisch gemeldet und reagiert entsprechend seiner Logik. Über einen Ereignishandler 134 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) sind an dieser Stelle auch erweiterte alternative Reaktionen für verschiedenste Ausführungszustände möglich. Die Übernahme von Variablen durch ein Kind-Paket stellt sich zudem als völlig unkompliziert heraus. In dem Konfigurationsmenü, das in Abbildung 3.20 dargestellt ist, kann man dem Kind-Paket den Zugang zu Parametern des Vater-Paketes mit wenigen Schritten erlauben. Das vereinfacht die bislang verwirrende Handhabung von Wertübergaben zwischen Paketen der herkömmlichen DTS erheblich. Die Kenner werden bei genauerem Hinsehen an dieser Stelle ein wenig überrascht sein, denn bei den Wertzuweisungen der Variablen müssen die Variablennamen in beiden Paketen unterschiedlich sein, im Gegensatz zur DTS-Variante! Identische Bezeichner waren ja vorher die Voraussetzung dafür, Wertübergaben zwischen Paketen überhaupt realisieren zu können. Nun ist es notwendig, unterschiedliche Namen für die Variablen zu vergeben, sonst wird der übergebene Wert der Vater-Variablen von der gleich bezeichneten lokalen Variablen des Kind-Paketes überdeckt. HINWEIS: Wenn man den Task ‚Paket ausführen’ benutzt, werden dem Kind-Paket sämtliche Variablen des aufrufenden Vater-Paketes vom System zur Verfügung gestellt. Damit kann ohne eine Konfiguration grundsätzlich auf die Variablen des Vater-Paketes zugegriffen werden. Durch einfache Werteänderung der Variablen im Vater-Paket lassen sich auch Rückgabewerte vom Kind- an das Vater-Paket umsetzen. Dies ist im Konfigurationsmenü nicht enthalten, aber man kann es über Skripte realisieren. Die zugewiesenen Werte bleiben nachhaltig für den restlichen Paketdurchlauf erhalten und stehen auch nach der Beendigung des Kind-Paketes zur Verfügung. Das Ganze ist aber nur dann möglich, wenn im Kind-Paket keine gleich benannte Variable existiert, weil diese durch ihren lokalen Status den Zugriff auf die Variable im Vater-Paket verhindert. Abbildung 3.20: Konfiguration eines IS-Paketes zur Übernahme von Variablen Lasset die Daten zu mir kommen 135 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Somit kann mit dem VariableDispenser der VB.NET-Skripte (mehr dazu im folgenden Abschnitt) direkt auf die Variablen im Vater-Paket zugegriffen und auch deren Wert nachhaltig verändert werden. Will man über das Konfigurationsmenü direkte Zuweisungen vornehmen, so sei darauf hingewiesen, dass die Einstellungen zur Übernahme von Vater-Variablen im Menü des Kind-Paketes (Menü-Aufruf über SSIS/Paketkonfigurationen) von uns vorgenommen werden müssen. Dies war bisher ebenfalls im Vater-Paket zu erledigen. ACHTUNG: Bereits konfigurierte Zuweisungen von Variablen im Menü Paketkonfigurationen behalten ihre Gültigkeit auch dann, wenn dieses Menü später wieder deaktiviert wird. Der angesprochene Paketkonfigurationsplaner kann überhaupt etwa das, was der Task ‚Dynamische Eigenschaften’ (»Dynamic Properties Task«) bei DTS konnte: dynamische Einstellungen zur Laufzeit an das Paket übergeben. Die Übergabe dynamischer Werte (wie z. B. der Name des aktuellen Nutzers, der Servername etc.) ist für jede Paketkomponente über den Paketkonfigurations-Assistenten komfortabel einzurichten. Im Gegensatz zum SQL Server 2000 kann der Entwickler aber nicht mehr alle Eigenschaften der Komponenten eines Paketes während der Laufzeit verändern, was ja in der 2000er-Version sogar mehrfach geschehen konnte. Das neue Entwicklungskonzept erlaubt lediglich beim Starten eines Paketes dynamische Initialisierungen, um potentiellen Fehlern bei mehrfachen Änderungen innerhalb eines Paketdurchlaufes vorzubeugen. Wer aber dennoch mehr Dynamik und individuelle Anpassungen braucht, der kann dies durch die Integration der VB.NET-Skripte erreichen. Skriptentwicklung in VB.NET Die Entwicklungsumgebung für VB.NET-Skripte ist besser umgesetzt als ihr Vorgänger, der auf ActiveX basierte. Grundlage der VB-Skripte bilden die in die Umgebung integrierten Programmierunterstützungen des Visual Studio.NET, Syntax Highlighting und IntelliSense, das zur automatisierten Vervollständigung programmierter Elemente dient und dadurch enorm hilfreich ist. Damit lässt es sich bedeutend komfortabler entwickeln! Der zusätzliche Vorteil für den Programmierer liegt in der eingebetteten Echtzeit-Syntaxkontrolle, mit der Logiken, Objekte und Ausdrücke während der Code-Entwicklung analysiert und bei auftretenden Mängeln, wie z. B. Datentypproblemen oder nicht zusammenpassenden Objekten, mit einem zusätzlichen Hilfstext hervorgehoben werden. 136 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Abbildung 3.21: ActiveX- und VB.NET-Skript im direkten Vergleich Diese Unterstützung der Programmierung spart uns Zeit bei der Entwicklung bzw. Fehlersuche. Gerade eine komplexe Anwendung, die umfangreich mit Skripten realisiert werden muss, wird von den Vorteilen der VB.NET-Umgebung profitieren können. Abbildung 3.21 zeigt den direkten Vergleich zwischen beiden Skriptarten. Hier ist deutlich der Unterschied zwischen den Skriptentwicklungen zu erkennen. Entwickler des Visual Studio werden sich von der Oberfläche her wie zu Hause fühlen, sind aber in der Wahl der Sprache etwas eingeschränkt: Die einzige implementierte Entwicklungssprache für Skripte innerhalb der Integration Services ist derzeit VB.NET. Schauen wir uns nun als nächstes den Task ‚SQL ausführen’ (»Execute SQL Task«) an, der in den DTS oft zu Schwierigkeiten führte, speziell wenn man ihn für gespeicherte Prozeduren verwendet hat. Gespeicherte Prozeduren und der Task ‚SQL ausführen’ Ein Problem, das mit den neuen Integration Services behoben wurde, ist der Aufruf von gespeicherten Prozeduren des SQL Servers. Wie beim Vorgänger ist der Task ‚SQL ausführen’ für die Ausführung von einfachen SQL-Anweisungen vorgesehen. Dazu gehört prinzipiell auch der Aufruf parametrisierter gespeicherter Prozeduren (»Stored Procedures«), was aber bislang in DTS sehr schwierig war, besonders wenn man Ausgabewerte aus der Prozedur erwartet. In der zugehörigen SQL Anweisung werden die Ein- und Ausgabeparameter über den Platzhalter »?« realisiert und wie folgt im Task ‚SQL ausführen’ eingetragen. EXEC test_procedure ? OUTPUT, ? Lasset die Daten zu mir kommen 137 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Der bekannte Aufruf einer Prozedur auf dem Server würde mit definierten Parametern dagegen wie folgt aussehen: EXEC test_procedure @param1 OUTPUT, @param2 = 'test-string' Der Platzhalter »?« im Task ‚SQL ausführen’ wird bei der Ausführung durch festgelegte PaketVariablen ersetzt und vervollständigt damit die Anweisung. Die Zuweisung der Variablen zu den entsprechenden Parametern nimmt man im Konfigurationsmenü des Tasks vor. Abbildung 3.22 zeigt den Task bei der Zuweisung der Variablen. Abbildung 3.22: Zuweisung von Variablen an Parameter des SQL Tasks Mit diesen Einstellungsoptionen ist die Parameterübergabe aus dem Katalog der zur Verfügung stehenden Variablen unkompliziert und übersichtlich – im Gegensatz zur Vorversion. Aus der Prozedur zurückgegebene Output-Werte werden auch an das Paket zurückgegeben, den dafür vorgesehenen Variablen zugewiesen und lassen sich im Anschluss problemlos verarbeiten. Damit sind zeitraubende Beschäftigungen mit diesem Task Vergangenheit, und selbst entwickelte Alternativ-Lösungen zum Aufruf gespeicherter Prozeduren, wie man sie häufig fand, sind ebenfalls entbehrlich geworden. Das Ausführen von DTS 2000 Paketen Monate, ja sogar Jahre der Entwicklung und Wartung der DTS-Pakete auf dem SQL Server 2000, und nun können sie nicht einmal mit dem Assistenten auf die neue Server-Version übertragen werden? Das werden viele Entwickler denken, es ist aber so schlimm auch wieder nicht. Zum Ausgleich dafür gibt es einen Task ‚DTS 2000-Paket ausführen’ (»Execute DTS Package Task«), der die Pakete dort wo sie sind und wie sie sind ausführt. Einfach Servernamen angeben und Login eintragen, dann das Paket aussuchen und starten lassen. Wahlweise können wir hier auch wieder mit den Strukturierten Speicherdateien (.dts-Dateien) im alten Format arbeiten, das macht die Angelegenheit noch einfacher, da hier der Server und Login-Eintrag nicht nötig sind. Sogar im SQL Server Management Studio gibt es einen eigenen Ordner in der Oberfläche, in dem die herkömmlichen und mit viel Schweiß und Mühe geschaffenen DTSPakete einen Zufluchtsort finden. 138 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Abbildung 3.23: Konfigurationsmenü des Tasks DTS 2000-Paket ausführen Der FTP-Task der Integration Services Eine hilfreiche Möglichkeit, innerhalb der Integration Services-Pakete erzeugte oder modifizierte Daten in andere Systeme zu übertragen, ist der FTP-Task6. Im DTS hatte dieser Task leider nur lesenden Zugriff auf Dateien in einer FTP-Verbindung, aber er konnte während der Ausführung eines Paketes Dateien durch den FTP-Zugang abrufen. Die überarbeitete Version dieser Komponente stellt nun sogar mehrere Dateioperationen bereit. Neben der realisierten Übertragung von Dateien aus dem Paket heraus können nun auch Verzeichnisoperationen, wie z. B. das Anlegen oder Löschen eines Ordners oder einer Datei durchgeführt werden. Das Konfigurationsmenü zeigt uns die Abbildung 3.24. 6 FTP ist die Abkürzung für eine Übertragungsart des Netzwerkes und bedeutet File Transfer Protocol Lasset die Daten zu mir kommen 139 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Abbildung 3.24: Operationen des FTP-Tasks Wie hier gut zu sehen ist, wurde auch hier viel Mühe investiert, den Funktionsumfang weit reichend auszudehnen, und das ist auch gut so, schließlich liegen viele große Datenbanken auf UNIX-Systemen, mit denen es sich über FTP vortrefflich kommunizieren lässt. Schleifen der IS – For-Schleife und Foreach-Schleife Erstmalig in die IS-Entwicklung integriert sind Schleifenlogiken zum wiederholten Ausführen zusammenhängender Tasks. Die Schleifen werden in Containern ausgeführt und grenzen die enthaltenen Komponenten von den restlichen Tasks des Paketes ab. Es existieren zwei Arten von Schleifencontainern, der For-Schleifencontainer (»For Loop Container«)und der ForeachSchleifencontainer (»Foreach Loop Container«). Beide führen die integrierten Tasks bis zum Erreichen einer vordefinierten Abbruchbedingung durch. Der Unterschied zwischen beiden Schleifencontainern besteht in der Definition der Abbruchbedingung: Im For-Schleifencontainer wird über einen einfachen Ausdruck, der ein boolesches Ergebnis liefert, die Abbruchbedingung an den Container übergeben. Ein einfaches Beispiel dafür wäre eine Paketvariable, die während des Schleifendurchlaufes inkrementiert wird, bis sie irgendwann die Abbruchbedingung erfüllt. Abbildung 3.25 zeigt den For-Schleifen-Editor (For Loop Editor) mit einem gültigen Ausdruck, der auf einer Paketvariablen beruht. Zu beachten dabei ist auf jeden Fall, dass der Ausdruck zum Abbruch der Schleife von »falsch« auf den Zustand »wahr« wechseln muss, um die Schleife zu beenden. Über diese Abbruchlogik stolpert man als Entwickler öfter mal! Abbildung 3.25: Konfigurationsmenü des ForSchleifencontainers 140 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Der andere der beiden Schleifencontainer bietet eine komfortable Möglichkeit der Entwicklung von dateigestützten Datenimporten, wie dies etwa in unserem ersten Import-Beispiel geschehen ist. Der Foreach-Schleifencontainer kann ebenfalls die in ihm enthaltenen Tasks bis zum Erreichen einer Abbruchbedingung wiederholen. Durch einen vordefinierten, so genannten Foreach-Dateienumerator (»For Each File Enumerator«) erhalten wir Zugriff auf die Dateien des angegebenen Verzeichnisses. In Abbildung 3.26 ist zu sehen, wie man auf die .csv-Dateien des C:\Import-Verzeichnisses zugreifen kann. Die Schleife des Importprozesses wird für jede im Verzeichnis enthaltene .csv-Datei durchlaufen, was auch gleichzeitig die Abbruchbedingung definiert. Damit wir Zugriff auf den kompletten Pfad der Quelldatei erhalten, müssen wir in den Einstellungen des Enumerators die Option Vollqualifiziert (»Fully qualified«) auswählen. Mit dem Anlegen und Konfigurieren dieses Schleifencontainers wird vom System eine zusätzliche Paketvariable erzeugt, die bei jedem Schleifendurchlauf den vollständigen Pfad der Datei enthält, die jetzt gerade aktuell verarbeitet wird. Abbildung 3.26: Konfigurationsmenü des Foreach-Schleifencontainers Mit Hilfe dieser Systemvariablen können wir innerhalb eines VB.NET-Skripts den Dateipfad inklusive des Dateinamens als Zeichenkette bearbeiten. In den Skripten sind dann mit Hilfe des Pfades auch Dateioperationen wie Verschieben oder Löschen möglich, sodass jeder erfolgreiche Schleifendurchlauf die importierte Datei beispielsweise in einen Unterordner mit der Bezeichnung importiert verschiebt. Diese essentiell bedeutende Variable des Schleifencontainers wird in VB.NET-Skripten unter dem Namen EnumeratedValue zur Verfügung gestellt. Lasset die Daten zu mir kommen 141 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Entwicklungsunterstützende Funktionen Flexible Taskoptionen Als hilfreich und praktisch für den Entwickler erweist sich die Deaktivierungsoption (»Disable«) einzelner Tasks innerhalb der Ablaufsteuerung. Die damit gesperrten Tasks werden bei der Ausführung nicht berücksichtigt, und auch augenfällig optisch gekennzeichnet, wie in Abbildung 3.6 schon zu sehen war. Das hat den wesentlichen Vorteil, dass man z. B. für einen Testlauf unnötige Abschnitte des Paketes nicht entfernen muss – man schließt sie lediglich vom Durchlauf aus. Komplette Teilprozesse können dabei variabel hinzu- oder abgeschaltet werden. Das ist insbesondere dann ein Zeitgewinn, wenn bereits implementierte komplexe Prozesse beim Hinzufügen und Testen weiterer Tasks ausgeklammert werden können. Erweiterte Verbindung für Textdateien Die schon in unserem Import-Beispiel verwendete Flatfile-Verbindung zu einer Textdatei ist in den Integration Services optionsreicher gestaltet. So kann neben den bisherigen Grundfunktionen und Einstellungen zusätzlich die Eigenschaft jeder einzelnen Quellspalte definiert werden. Die wichtigste Neuerung dabei stellt die Einstellung des Datentyps dar, was angesichts der Tatsache, dass die Quelle ja eine reine Textdatei ist, überraschend ist. Man kann damit aber schon aus der Verbindung heraus festlegen, welche Zieldatentypen diese Quellspalte besitzen soll. Bei Nutzung der zusätzlichen Vorschlagsfunktion, die den Datentyp durch das Prüfen des Dateiinhalts ermittelt, kann man die Tiefe der Quelldatenanalyse durch Festlegen der zu prüfenden Zeilenanzahl beschränken. Die zu dieser Verbindung gehörende Flatfilequelle verbindet die Verbindung zur Textdatei mit dem Datenfluss. Er ist jedoch weder für Datentransformationen gedacht, noch bindet er eine Zieltabelle an die Quellspalten der Textdatei. Zweck dieses Tasks ist es, eine gezielte Bezeichnung der Spalten zu ermöglichen und bei Bedarf Einstellungen an Quell- und Zieldatentypen zu verändern. Die Ausgabe dieses Tasks dient für die im Workflow nachfolgenden Tasks als entsprechende Eingabe. Wie bereits andeutet, erfolgen Transformationen von Daten nicht weiterhin innerhalb eines einzelnen Tasks. Der zusammenfassende Task ‚Daten transformieren’ (»Data Transformation Task«) der DTS existiert nicht mehr und wird durch eine Aufteilung in mehrere einzelne Tasks ersetzt. So ist beispielsweise die vorher enthaltene Lookup-Funktionalität, die für jeden Datensatz eine Abfrage in einer anderen Datenbank ausführt, als eigenständiger Task ausgegliedert worden. Ebenso neu wie nützlich sind auch die Transformationen Abgeleitete Spalte (»Derived Column Task«) und Bedingtes Teilen (»Conditional Split Task«), die beide im nächsten Abschnitt betrachtet werden. Datentransformationen mit Tasks Der für Transformationen von Quelldaten bedeutendste Task des neuen DTS bildet der funktionsreiche Task Abgeleitete Spalte . Dieser übernimmt die Ausgabe anderer Tasks als Eingabe und ermöglicht die Anwendung umfangreicher Funktionen und Operatoren, um die eingehenden Daten zu bearbeiten. Die Möglichkeit, den ankommenden Datensätzen zusätzliche Spalten für den zusammenhängenden Output hinzuzufügen, ist für den Entwickler von großem Vorteil. Für diese zusätzlichen wie auch die eingehenden Spalten stehen mathematische Funktionen, Stringfunktionen, Datums- und Zeitfunktionen sowie Typenumwandlungen zur Verfü- 142 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) gung. Eine Liste von Operatoren ermöglicht sogar mathematische Operationen mit den Werten eingehender Spalten oder Paketvariablen untereinander. Derart umfangreiche Datenumformungen waren in den DTS nur unter Verwendung von ActiveX-Skripten realisierbar, die aber der Performance immer wenig zuträglich sind, weil für jede Zeile einzeln eine Skripting Engine gestartet werden muss. Abbildung 3.27: Ausschnitt aus dem Funktionsumfang des abgeleitete Spalte-Tasks Das Beispiel in der Abbildung 3.27 zeigt die Möglichkeiten der Transformationen bestehender Spalten sowie die Erzeugung neuer und zusätzlicher Spalten. Dabei wird eine Stringfunktion zum Entfernen von Leerzeichen benutzt, mit einer Datumsfunktion wird der Importzeitpunkt festgehalten, und zwei Zusatzspalten werden mit Werten von zuvor angelegten Paket-Variablen gefüllt. Dieser Task fasst seine Eingabespalten und Zusatzspalten zu einem Ausgabestrom zusammen und stellt sie so den anknüpfenden Tasks wieder als Eingabe zur Verfügung. Der Task Bedingtes Teilen sieht in seiner Einstellungsoberfläche dem Task Abgeleitete Spalte äußerst ähnlich, dient aber dazu, eingehende Spalten basierend auf einem Entscheidungskriterium in zwei Datenströme aufzuteilen. Durch das bedingte Teilen erhalten wir eine Trennbedingung für die Ausgabe dieses Tasks, der wieder unterschiedlichen Ziel-Tabellen zugeordnet werden kann. Damit wäre zum Beispiel eine Trennung in verschiedene Ausgabedateien für jeden Postleitzahlbereich möglich. Lasset die Daten zu mir kommen 143 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Abbildung 3.28:Trennbedingung »Fall 2« als Eingabedaten für anknüpfenden Task zuweisen In der anschließenden Selektion der definierten Trennbedingung lassen sich dann problemlos die so aufgeteilten Daten zuweisen, wie das in Abbildung 3.28 gut zu erkennen ist. Damit kann der Entwickler recht einfach die Trennung von Daten durch komplexe Prüfbedingungen realisieren. In diesem Zusammenhang kommen wir nun zu unserem letzten Feature. Daten-Viewer des Datenflusses Innerhalb der Ablaufsteuerung haben wir ja nun mehrere Möglichkeiten gesehen, als Entwickler auf den Ablauf des Pakets Einfluss zu nehmen, vom Deaktivieren der Tasks bis zu den Haltepunkten. Nun wäre es ja recht angenehm, auch den Datenfluss irgendwie überprüfen zu können, und siehe da: es ist möglich! Der zwischen den einzelnen Tasks laufende Datenfluss kann »angezapft« werden, um etwa sehen zu können, wie eigene Berechnungen oder Funktionen die Daten verändert haben, bevor sie an den nächsten Task übergeben werden. Interessant dabei ist, dass der Inhalt des Datenflusses auf mehrere Arten betrachtet werden kann. So haben wir die Wahlmöglichkeit zwischen einem einfachen Raster über ein konfigurierbares Histogramm bis hin zu Diagrammen spezifischer Daten. Und das nicht nur einzeln, sondern für jeden Datenfluss und mit sämtlichen Optionen auf einmal. Damit können übertragene Daten nicht nur kontrolliert, sondern sogar während der Übertragung ausgewertet werden. Abbildung 3.29 zeigt das Konfigurationsmenü in der Übersicht. 144 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) Abbildung 3.29: Daten-Viewer des Datenflusses in der Übersicht Selbstverständlich gibt es noch viele neue Funktionalitäten mehr, und ganz bestimmt haben wir das Wichtigste und Spannendste vergessen. Jeder Autor, der ein Buch über Integration Services schreiben darf, in dem jedes Feature gebührend gewürdigt werden muss, ist nicht zu beneiden! In diesen wenigen Seiten konnten wir eigentlich nur versuchen, etwas Appetit zu machen. Aber um wenigstens die Richtung klar werden zu lassen, in die es für die Integration Services geht, wird es Zeit, noch einmal alles zusammenzubringen. Zusammenfassung Die Implementierung von ETL-Prozessen ist in der neuen SQL Server Version im Vergleich zur bisherigen Entwicklung grundlegend verändert. Grund dafür ist das verbesserte Entwicklungskonzept, im Zusammenhang mit der neuen Entwicklungsumgebung. Die IS-Pakete sind nicht weiterhin reiner Bestandteil des Servers. Ihre Erstellung wurde komplett in ein Client-Tool ausgegliedert, die Speicherung erfolgt lokal als .dtsx-Datei in einem zusammenhängenden Projektverzeichnis. Der projektorientierte Aufbau der Entwicklungsumgebung ermöglicht eine Sicherung der unterschiedlichen Entwicklungsstände in verschiedenen Versionen, wie dies in Visual Studio.NET-Projekten üblich ist. Dieser Aspekt wirkt sich für den Programmierer auch positiv aus, wenn er zwischen alternativen Lösungsansätzen umschalten muss. Die Gliederung der Paketoberfläche ist sehr übersichtlich. Innerhalb der unterschiedlichen Registerkarten eines Paketes wie Ablaufsteuerung, Datenfluss, Ereignishandler und PaketExplorer sind die Komponenten gut strukturiert und überschaubar gegliedert. Insgesamt wurde Lasset die Daten zu mir kommen 145 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9) das Erscheinungsbild der IS-Umgebung für die Entwicklung komfortabler gestaltet und ist intuitiver als in der vorherigen Version. Die verbesserte Skript-Programmierung in der neu integrierten Entwicklungsumgebung ist besonders gut gelungen. Es ist kaum noch ein vorher existenter Mangel übrig geblieben! Die Ausführung der gespeicherten Prozeduren, die Wertübergaben von und an ausgeführte Pakete sowie die Handhabung von Paketvariablen im Allgemeinen sind deutlich verbessert worden. Als förderlich für die einfache und leicht erlernbare Paketentwicklung haben sich die flexibleren Einstellungsmöglichkeiten der einzelnen Paketkomponenten herausgestellt. So ist durch die Kapselung mehrerer Tasks jetzt eine Gruppierung von Komponenten möglich, wodurch die unterschiedlichen Schleifenformen benutzbar werden. Bei einem Import von Daten über .csvDateien ist die erweiterte Verbindung zu Textdateien sehr unterstützend und hilfreich. Weil spezielle Transformationsfunktionen ausgegliedert worden sind, wurde eine Vielzahl neuer Tasks geschaffen, die umfangreiche Be- und Verarbeitungsmöglichkeiten von Daten im Datenfluss eines Paketes zulassen. Ein gutes Beispiel dafür sind die Transformationen Abgeleitete Spalte und Bedingtes Teilen, die dem Entwickler übersichtlich und verständlich eine Fülle von Funktionen für die Datenbe- und -verarbeitung bereitstellen. Dabei stellt jeder in den Datenfluss eingebundene Task die eingehenden und ausgehenden Datenspalten in anschaulichen Mappings gegenüber. Fazit: Man müsste sich mal mit den Integration Services und einem Laptop für drei Wochen auf eine einsame Insel zurückziehen können… 146 Kapitel 3 Rupprecht Dröge, Markus Raatz: SQL Server 2005 - Konfigurierung, Administration, Programmierung - 2. Auflage. Microsoft Press 2006 (ISBN 978-3-86063-997-9)
