Ich möchte in diesem Blogbeitrag erklären, wie man Surrogate-Keys für Parent-Child-Hierarchien und die jeweilige Hierarchiestufe des Mitarbeiters anlegen kann. Dabei hilft uns die Angestellten Tabelle der AdventureWorks Datenbank. Diese findet man unter dem Tabellennamen Employee im Schema HumanResources. Der Mitarbeiter wird über die Spalte EmployeeID identifiziert und der Vorgesetzte über die Spalte ManagerID. Angestellte die keinen Vorgesetzten haben, sind mit entsprechender ManagerID auf NULL gesetzt. Dementsprechend ist der/sind die Mitarbeiter der/die keinen Vorgesetzten hat/haben, die höchste Stufe in unserer Organisation (in unserem Fall also der Chef).

Wir müssen in unserer Tabelle in der später unsere Daten landen sollen zunächst zwei zusätzliche Spalten einfügen. Das wäre zum einen die Spalte EmployeeBK und ManagerBK. Die Erklärung dazu folgt dann später im Text.

Außerdem benötigen wir in unserer Ausgangstabelle (Employee) eine Hilfsspalte (ich habe mich i.F. für istImportiert entschieden (NULL ist zulässig)) mit beliebigen Namen und dem Datentyp bit.

Als nächstes müssen wir dafür sorgen, dass alle Werte in dieser neuen Spalte den Wert 0 enthalten. Damit das Ganze gleich in SSIS passiert, ziehen wir uns einen SQL-Task auf unsere Arbeitsfläche und fügen den Befehl update [HumanResources].[Employee] set istImportiert = 0 ein.

Für den nächsten Schritt benötigen wir eine Laufvariable mit dem Datentyp Integer und dem Standardwert 0. Danach legen wir einen for-Schleifencontainer an. Nachdem Ihr die Eigenschaften festgelegt habt, legen wir einen Datenflusstask in den Container.

Vorweg schon mal die Ansicht, wie es später in unserem Datenflusstask aussehen wird:

Schritt 1

Wie üblich brauchen wir zunächst eine Quelle. Entscheidend ist hier natürlich, dass wir neben der ManagerID und der EmployeeID die Abfrage darauf einschränken, dass nur Daten geladen werden, wo der Wert für istImportiert = 0 ist.

Schritt 2

In der Komponente für bedingtes Teilen erfolgt die Überprüfung, welche Daten unsere Wurzelknoten (also unsere Manager mit dem Eintrag null) sind. Alle anderen Mitarbeiter werden als Knoten ausgegeben.

Schritt 3

Wir kümmern uns zunächst um die Mitarbeiter, die unseren Wurzelknoten repräsentieren. Dazu legen wir eine Abgeleitete Spalte mit dem folgenden Ausdruck an:

Im zweiten Teil von Schritt 3 müssen die anderen Hierarchiestufen überprüft werden. Hierfür legen wir eine Lookup Komponente an und verbinden diese mit der Ausgabe für Knoten aus der Conditional-Split Komponente. Damit wir es später nicht vergessen, ändern wir unter Allgemein die Einstellung wie nicht getroffene Einträge behandelt werden (auf Fehler ignorieren stellen). Unter Verbindung fügen wir ein SQL-Statement ein, das unsere Tabelle abfragt, in der letztendlich unsere Daten landen sollen. Jetzt kommt eine der erwähnten Spalten aus der Einleitung ins Spiel. EmployeeBK enthält später die Mitarbeiternummer welche aus EmployeeID kommt.

Wir verknüpfen die ManagerID mit EmployeeBK und lassen uns die EmployeeID (im SQL-Statement umbenannt zu EmployeeParentID) ausgeben. Überall wo wir keinen Treffer haben, wird NULL ausgegeben.

Schritt 4

Mit dem nächsten Conditional Split überprüfen wir, ob EmployeeParentID einen Wert erhalten hat oder nicht. Alle Zeilen für die es einen Treffer gibt, gehen in diesem Beispiel an die Ausgabe „Vater gefunden“.

Schritt 5

Mit Hilfe einer Union All Komponente verknüpfen wir die eingehenden Zeilen.

Schritt 6

Über die Multicast Komponente lassen wir uns Kopien des Datasets erzeugen.

Schritt 7

In der Komponente OLE DB Befehl fügen wir für unsere Quelltabelle Employee ein Update Statement ein.

Außerdem muss in den Spaltenzuordnungen EmployeeID mit Param_0 verknüpft werden.

Schritt 8

Als Erstes betrachten wir die Zuordnungen für unser Ziel (OLE_DST EmployeeNeu). Wie bereits erwähnt, stellt die EmployeeID in unserer Zieltabelle den Surrogate-Key dar. Außerdem muss darauf geachtet werden, dass unsere EmployeeParentID mit der ManagerID verknüpft wird.

Da wir uns immer noch im Schleifencontainer befinden, müssen wir im letzten Schritt dafür sorgen, dass kein Durchlauf mehr erfolgt, wenn unsere Laufvariable einen Wert ungleich 0 hat. Wir fügen eine Komponente „SQL ausführen“ (SQL UPDATE Employee) ein (siehe Bild)

und legen folgende Einstellungen fest:

Wenn noch nicht geschehen, muss im ResultSet unsere Laufvariable ausgegeben werden.

Hierarchiestufe

Da ich abschließend wissen möchte, wie viele Vorgesetzte ein Mitarbeiter über sich hat, benötige ich eine zusätzliche Variable, die für jeden Durchlauf des Containers hochgezählt und dann in unsere Zieltabelle weggeschrieben wird. Hierfür lege ich zunächst eine Variable (iHierarchiestufe) mit dem Datentyp integer an (Startwert steht auf 1) und ergänze meine Zieltabelle um die Spalte Hierarchiestufe. Den Wert der Variablen füge ich mit Hilfe der Komponente „abgeleitete Spalte“ in eine neue Spalte ein.

Außerdem muss ich noch das Mapping wie in Schritt 8 beschrieben ergänzen falls nicht schon geschehen.

Natürlich muss dem Schleifencontainer noch mitgeteilt werden, dass unsere Variable pro Durchlauf hochgezählt wird (AssignExpression). Die Einstellung dafür bitte dem Bild For-Schleifen-Editor entnehmen.

Abschließend schauen wir uns noch das Ergebnis für unsere Zieltabelle „EmployeeNeu“ an. Im ersten Durchlauf finden wir genau einen Mitarbeiter der keinen Vorgesetzten hat. Er steht dementsprechend an erster Stelle in der Hierarchie.

Erster Durchlauf:

Im zweiten Durchlauf (zweite Ebene in der Hierarchie) haben wir schon mehr Mitarbeiter getroffen. Die ehemalige EmployeeID aus der Quelltabelle befindet sich nun in der Spalte EmployeeBK. Unter ManagerBK finden wir die zugehörige Kennzeichnung des Vorgesetzten (ManagerID aus der Quelltabelle). Unter ManagerID befindet sich der neu erzeugte Surrogate Key.

Zweiter Durchlauf:

Da alle weiteren Hierarchiestufen nach dem gleichem Schema gefüllt werden, spare ich mir an dieser Stelle die Fotos für die nächsten Durchläufe. Viel Spaß beim Ausprobieren.

Wenn ich euch mit dieser Anleitung helfen konnte, ihr weitere Fragen, Anmerkungen, Verbesserungsvorschläge oder Lösungen habt, freue ich mich auf Kommentare!

Auf die Property kann nicht direkt zugegriffen werden. Stattdessen wird der Property ExecValueVariable eine Package-Variable zugeordnet. In diese wird dann zur Laufzeit des Paketes die Anzahl der Zeilen, die von der ausgeführten SQL-Anweisung betroffen waren, eingetragen. Diese Variable kann im weiteren Package-Ablauf verwendet werden. Für die Anzahl der Zeilen wird eine Int-Variabel verwendet, die in disem Beispiel iExecValue genannt wird.

Als nächstes wird ein Execute-SQL-Task erstellt, der die Beispiel-Tabelle Example mittels einer DELETE-Anweisung leert. Die Tabelle enthält 3 Datensätze und somit erwarten wir die Zahl 3 als Anzahl der betroffenen Zeilen. Im Editor des Tasks wird die Connection ausgewählt und die Anweisung „DELETE FROM Example“ als Direkteingabe eingegeben.

Durch Rechtsklick auf den Task und Auswahl von „Eigenschaften“ wird der Eigenschaften-Editor des Tasks geöffnet. Da wird der Property ExecValueVariable über die Dropdpwn-Liste die vorher angelegte Variabel iExecValue aus.

Um nach Start des Paketes das Ergebnis zu prüfen, setzen wir einen Breakpoint auf das PostExecute-Ereignis des Tasks (Rechtsklick auf den Task, Haltepunkte bearbeiten wählen und dann den Eintrag für „OnPostExecute“ anhaken). Damit kann direkt nach Ausführung des SQL-Tasks geprüft werden, ob die Variable tatsächlich die gewünschte Anzahl der betroffenen Zeilen enthält.

Anschließende wird das Paket ausgeführt. Bei Erreichen des Breakpoints fügen wir über Debuggen->Fenster->Überwachungsfenster1. Dort tippen wir in die Namensspalte den Namen unserer Variabel ein. Anschließend sehen wir, dass unsere Variable tatsächlich die Anzahl der von der SQL-Anweisung betroffenen Zeilen enthält:

#

Es kann auch eine Stored Procedure aufgerufen werden, die wie in unserem Beispiel eine DELETE-Anweisung ausführt. In der Stored Procedure darf dann nicht SET NOCOUNT ON“ verwenden, da dann die Zahl der betroffenen Zeilen nicht ermittelt wird.

In dem Beispiel kann TRUNCATE nicht verwendet werden, da bei TRUNCATE nicht zeilenweise gelöscht wird, wie bei DELETE. Bei TRUNCATE werden stattdessen die Datenseiten der betroffenen Tabelle deallokiert.

Vorab exemplarisch die Struktur,  wie in SAP die Darstellung der Kostenstellgruppen aussieht:

Zunächst habe ich die betroffenen Tabellen (SETHEADER, SETHEADERT, SETNODE und SETLEAF) in eine SQL Server Datenbank importiert. SETHEADER enthält den Topknoten. Hier erhält man über den Wert in Settype die Information, ob der Oberknoten (parent) weitere Subknoten (childs) besitzt. Ist dies der Fall, signalisiert das der Buchstabe S. Wenn es keine Subknoten gibt, steht für settype ein B. Über den Wert in SETCLASS kann man die Suchergebnisse einschränken. Für die Kostenstellengruppe wählt man 0101, Kostenartengruppen = 0102 und Profit-Center-Gruppen = 0106.

SELECT DISTINCT

       [SAP_SETHEADER].[MANDT]

      ,[SAP_SETHEADER].[SETCLASS]

      ,[SAP_SETHEADER].[SUBCLASS]

      ,[SAP_SETHEADER].[SETNAME]

      ,[SETTYPE]

      ,[CREDATE]

      ,[CRETIME]

      ,[UPDUSER]

      ,[UPDDATE]

      ,[UPDTIME]

      ,[SAPRL]

      ,[TABNAME]

      ,[FIELDNAME]

      ,[ROLLNAME]

      ,[DESCRIPT]

  FROM [sap_demo_cgl].[dbo].[SAP_SETHEADER]

  INNER JOIN SAP_SETHEADERT ON SAP_SETHEADER.SETNAME = SAP_SETHEADERT.SETNAME

  where SAP_SETHEADER.SETNAME = ‘C1′

  AND SAP_SETHEADER.SETCLASS = 0101

Anmerkung: Den join auf SETHEADERT führe ich durch, damit ich den genauen Namen der Kostenstellengruppe erhalte.

Möchte man nun mehr über die Subknoten erfahren, begibt man sich mit dem Wert aus Setname in die Tabelle SETNODE.

Das Ergebnis zeigt, dass es für diesen Knoten weitere Subknoten (SUBSETNAME) gibt. Man kann nun entweder in die Tabelle SETHEADER gehen und dort überprüfen ob es weitere Subknoten für den SUBSETNAME gibt, oder man ändert einfach den Wert aus der vorherigen Abfrage.

SELECT DISTINCT

       SAP_SETNODE.[MANDT]

      ,SAP_SETNODE.[SETCLASS]

      ,SAP_SETNODE.[SUBCLASS]

      ,SAP_SETNODE.[SETNAME]

      ,[LINEID]

      ,[SUBSETCLS]

      ,[SUBSETSCLS]

      ,[SUBSETNAME]

      ,[SEQNR]

      ,[DESCRIPT]

  FROM [sap_demo_cgl].[dbo].[SAP_SETNODE]

  INNER JOIN SAP_SETHEADERT ON SAP_SETNODE.SETNAME = SAP_SETHEADERT.SETNAME

  WHERE SAP_SETNODE.SETNAME = ‘C1200′

  AND SAP_SETNODE.SETCLASS = 0101

Hat man die letzte Hierarchiestufe erreicht, kann man mit den Wert für SETNAME in der Tabelle SETLEAF alle SETS für die jeweilige Gruppe anzeigen lassen.

Für einen join auf die Tabelle der Kostenstellenstammsätze (CSKS) verwende ich folgendes Statement:

Die Kostenartenstammsätze befinden sich übrigens in der Tabelle CSKA und die Profit Center Stammdaten in der Tabelle CEPC.

Mit Hilfe eines Self-Joins kann man sich die Kostenstellenhierarchie auch übersichtlich mittels einer Abfrage anzeigen lassen.

SELECT DISTINCT

          Rootknoten.[SETCLASS] as Kostenstelle

         ,Rootknoten.[SETNAME] as KST_Key_Level1

         ,Level1Knoten.[DESCRIPT] as KST_Name_Level1

         ,Kind_1.[SETNAME] as KST_Key_Level2

         ,Level2Knoten.[DESCRIPT] as KST_Name_Level2

         ,Kind_2.[SETNAME] as KST_Key_Level3

         ,Level3Knoten.[DESCRIPT] as KST_Name_Level3

         ,Kind_2.[SUBSETNAME] as KST_Key_Level3

         ,Level4Knoten.[DESCRIPT] as KST_Name_Level4

         ,VALFROM

         ,VALTO

         ,SAP_CSKS.KOKRS

         ,SAP_CSKS.KOSTL

  FROM   [sap_demo_cgl].[dbo].[SAP_SETNODE] Rootknoten

  INNER JOIN dbo.SAP_SETNODE Kind_1 on Rootknoten.SUBSETNAME = Kind_1.SETNAME

  INNER JOIN dbo.SAP_SETNODE Kind_2 on Kind_1.SUBSETNAME = Kind_2.SETNAME

  INNER JOIN dbo.SAP_SETLEAF  on Kind_2.SUBSETNAME = dbo.SAP_SETLEAF.SETNAME

  INNER JOIN dbo.SAP_SETHEADERT Level1Knoten on Rootknoten.SETNAME = Level1Knoten.SETNAME

  INNER JOIN dbo.SAP_SETHEADERT Level2Knoten on Kind_1.SETNAME = Level2Knoten.SETNAME

  INNER JOIN dbo.SAP_SETHEADERT Level3Knoten on Kind_2.SETNAME = Level3Knoten.SETNAME

  INNER JOIN dbo.SAP_SETHEADERT Level4Knoten on Kind_2.SUBSETNAME = Level4Knoten.SETNAME

  INNER JOIN dbo.SAP_CSKS on SAP_CSKS.KOSTL between valfrom and valto

  WHERE

  Rootknoten.SETNAME = ‘C1′

  AND Level1Knoten.LANGU = ‘Z’

  AND Level2Knoten.LANGU = ‘Z’

  AND Level3Knoten.LANGU = ‘Z’

  AND Level4Knoten.LANGU = ‘Z’

Hier kann man sehr schön sehen, dass die Kostenstellengruppe C1 (KST_KEY_Level1) die Gruppe C1000 (KST_Key_Level2) enthält, welche u.a. die Gruppen C1200, C1300 und C1400 (KST_Key_Level3) besitzt. 

Ich habe die Description Language eingeschränkt, damit mir die japanischen und russischen Erklärungen nicht angezeigt werden. Beachten Sie bitte, dass eine Kostenstellengruppe mit obiger Abfrage allerdings auch nicht angezeigt wird, wenn die gewählte Sprache für eine Kostenstellengruppe in der Tabelle SETHEADERT nicht vorhanden ist.

In diesem Beitrag möchte ich eine Möglichkeit erläutern, die so simpel ist, dass der ein oder andere vielleicht gar nicht erst daran gedacht hat – frei nach dem Motto: „Ich seh‘ den Wald vor lauter Bäumen nicht“.

Nehmen wir an, es handelt sich bei unserer Zahl um einen Prozentwert, dessen Anzahl der Nachkommastellen wir auf 5 begrenzen und im Falle der Überschreitung einen Fehler ausgeben lassen wollen (z.B. wenn die Zielspalte in der Datenbank nicht mehr als 5 zulässt). Dies würde sich zwar mit einfachen Mitteln realisieren lassen, jedoch unter Umständen nicht immer zum gewünschten Ergebnis führen.

Angenommen es handelt sich um den Wert 12,1234500 – so würden die beiden letzten Nachkommastellen nach „Schema-F“ abgeschnitten und ein Fehler erzeugt werden. Da es sich in diesem Falle aber um das Abschneiden von lediglich zwei nullen handelt und somit der numerische Wert trotzdem unverändert und somit gültig bleibt, muss hier eine andere Lösung her.

Wie? Ganz einfach! Man vergleiche die Zahl mit sich selbst – und zwar konvertiert in einen Gleitkommawert mit 5, sowie mit 6 Nachkommastellen. Das ganze könnte dann z.B. so aussehen:

(DT_NUMERIC, 10, 5)Wert == (DT_NUMERIC, 10, 6)Wert

Die folgende Abbildung sollte das Prinzip noch einmal veranschaulichen und weitere Erläuterungen überflüssig machen

Es gibt Bugs, die sind, wenn man sie denn kennt und zu umschiffen weiß, eher amüsant als ärgerlich. Zumeist sind sie längst bekannt und zaubern ein Lächeln ins Gesicht des Eingeweihten, wenn er diesem beim Entwickeln einmal mehr begegnet. Und doch kann es passieren, dass sich ein solcher Bug eben doch nicht überall herumgesprochen hat, was dann oftmals zu Unmut und Verwirrung führt.

Ein Klassiker dieser Art ist der Suche-Task der Integration Services 2005 in deutscher Sprachversion. Dieser birgt nämlich einen gemeinen Fallstrick, der oft zu wirren ETL-Paketen führt, wenn man auch nur einen einzigen Mausklick vergisst. Der Sachverhalt ist folgender: Nach erfolgter Definition der Spalten-Zuordnungen für die Übereinstimmungsbedingungen und Auswahl der entsprechenden Spalten in der Verweistabelle vergisst der Task anscheinend seine Konfiguration der Spalten, nachdem man die Einstellungen mit OK bestätigt und sich der Dialog schließt. Konkret könnte das Ganze ungefähr so ausschauen:

Nach dem Bestätigen verschwindet aber die eben neu hinzugefügte Spalten wie von Geisterhand wieder:

Auch nach erneutem Öffnen des Konfigurationsdialogs hat es den Anschein, als wäre hier niemals etwas eingestellt worden. Die eingangs erwähnten wirren ETL-Pakete entstehen nun durch den Workaround, dass man eine oder mehrere Spalten vorher angelegt, etwas durch den Abgeleitete Spalte-Task, und in der Suche diese mit dem nachgeschlagenen Wert überschreibt. Dies funktioniert nämlich anstandslos.

Dabei gibt es einen viel effektiveren Weg, an seine Nachschlage-Spalten zu kommen: ein Mausklick an der richtigen Stelle im Konfigurationsdialog. Der entscheidende Punkt ist nämlich die Dropdown-Box „Suchvorgang“. Der aufmerksame Entwickler sieht den Unterschied: Hier gibt es die Option „Als neue Spalte hinzufügen“ mit einem großen A an erster Stelle. Die Standard-Auswahl beginnt mit einem kleinen A:

Und dies ist auch schon des Rätsels Lösung: wenn man sich nun die einzig auswählbare Option entscheidet, klappt es mit der neuen Spalte ohne Probleme. Offensichtlich haben die Integration Services hier Probleme mit den angebotenen Optionen dieses Dialogs und der erlaubten Auswahl. Ein Blick auf die Metadaten beweist: die neue Spalte ist tatsächlich vorhanden:

Wohlgemerkt betrifft dies unseres Wissens nur SSIS 2005 in deutscher Sprache und könnte durch den ein oder anderen Patch in einigen Versionen auch behoben worden sein. Nichtsdestotrotz begegnen wir immernoch regelmäßig der kritischen Version und auch unter den Entwicklern hat sich das vorgestellte vorgehen noch nicht bis in die hintersten Ecken herumgesprochen.

Hinzufügen von Leistungsindikatoren

OK, unter dem Zweig “Leistung / Überwachungstools / Leistungsüberwachung” (bzw.  “Performance / Monitoring Tools / Performance Monitor”) findet sich zunächst die bekannte Sicht mit den von links nach rechts fortschreitenden, bunten Kurven. Klickt man auf den grünen Plus-Knopf, so kann man noch etliche Counter mehr hinzufügen; für uns natürlich speziell die des SQL Servers und der Analysis Services.

Welche man dabei wählt, ist eine im Web viel diskutierte Wissenschaft für sich; da ist noch Material für viele, viele Blog-Einträge drin! Aus Performance-Gründen macht man in der Regel zwei Dinge:

1. Nicht einfach alle Leistungsindikatoren wählen, wenn wir wirklich visuell etwas beobachten wollen, sondern nur 10-30 Counter, die man noch im Fenster im Auge behalten kann.

2. Die Leistungsüberwachung nicht auf dem Rechner laufen lassen, der überwacht wird, sondern sich mit “Leistungsindikatoren auswählen von Computer” von einem anderen Rechner aus mit dem Server verbinden:

Leider dauert es, sobald man das Feld mit dem Rechnernamen verlassen hat, immer einige Sekunden, bis sich die Counter-Liste darunter auf die des Remote-Servers aktualisiert hat. In dieser Zeit sieht man garnix, nicht einmal eine Sanduhr, also Geduld, bitte!

Skalierung von Leistungsindikatoren

Oftmals beginnt jetzt eine endlose Mühe: Die Hälfte der neuen Counter hängen ganz oben auf der “100”, die andere Hälfte krebsen bei der “0” herum, wie die folgende Abbildung beispielhaft zeigt:

Mit Hilfe der “Skalierung” (“Scale”) kann man das für jeden Counter individuell einstellen, im Fenster “Eigenschaften von Leistungsüberwachung” (“Performance Monitor Properties”). Ganz schön mühsam! Man kann aber auch einfach alle interessanten Counter in der unteren Liste markieren und per Rechtsklick sagen “Ausgewählte Leistungsindikatoren skalieren” (“Scale selected counters”). Schon wählt perfmon selbst eine Skalierung, die jeden Counter sinnvoll zwischen 0 und 100 platziert, etwa so:

Na, das sieht doch schon viel besser aus!

Performance Monitor Counter speichern

Nachdem man mit der Auswahl und der Skalierung der Leistungsindikatoren schon so viel Mühe gehabt hat, möchte man die Liste natürlich irgendwie “persistieren”. Sonst müsste man nach einem Abmelden oder einem Neustart die ganzen Counter neu zusammenstellen! Wie das geht, ist nicht ganz offensichtlich: man braucht wieder einen Rechtsklick auf die untere Liste, aber diesmal auswählen “Einstellungen speichern unter…” (“Save Settings As…”), und als Zielformat .html wählen!

Die so gewonnene Datei kann aber nicht einfach so in einen neuen perfmon wieder eingelesen werden, oh nein: man muss sie mit dem Texteditor der Wahl öffnen, den ganzen Inhalt markieren und in die Zwischenablage kopieren. Dann geht man in eine neue, ggf. noch leere Leistungsüberwachung und klickt im Menü oben auf die Taste “Leistungsindikatorenliste einfügen” (“Paste Counter List”); Strg-V tut’s auch. Das fügt die Counter aus der .html-Datei der neuen Instanz hinzu!

Auf diese Weise kann man sich im HTML-Format ein paar nette Listen mit Leistungsindikatoren bereithalten, die man dann an jedem neuen Server geschwind aus der Tasche zieht und anwendet. Aber Halt: der neue Server heißt ja anders! Kein Problem: wenn man beim hinzufügen der Counter brav über “Select counters from computer”, wie oben beschrieben, gearbeitet hat, dann steht der Name des Quellservers lesbar in der .html-Datei, und er kann mit Suchen und Ersetzen leicht ausgetauscht werden.

An dieser Stelle möchte ich mich gar nicht darüber ärgern, dass beim Betriebssystem die Namen der Counter auf deutsch übersetzt wurden (z.B. “Physikalischer Datenträger / Aktuelle Warteschlangenlänge”); bei Anwendungen wie beim SQL Server aber englisch geblieben sind. Babel, du bist nicht fern!

Daten aus Leistungsindikatoren aufzeichnen lassen mit Sammlungssätzen

Für den, der sich für so was interessiert, ist es spannend genug, jetzt den bunten Kurven stundenlang zu folgen, alle anderen fühlen sich an den Blick ins Glasfenster ihrer laufenden Waschmaschine erinnert und möchten die Ergebnisse gerne abspeichern, um sie an den Performance Tuner ihrer Wahl zu mailen. Dazu gibt es die "Sammlungssätze”

(“Data Collector Sets”), eine Auswahlliste aus Countern, deren Daten dann in eine .blg-Datei geschrieben werden. Diese Dateien, die standardmäßig auf dem Systemlaufwerk im Verzeichnis /perflogs zu liegen kommen, kann man durch Doppelklick dann wieder im perfmon öffnen und inspizieren! Dumm nur, dass bei mir das unter

http://technet.microsoft.com/en-us/library/cc722148.aspx beschriebene Verfahren, wie man aus den Countern einer laufenden Leistungsüberwachung einen Sammlungssatz generiert, nicht funktioniert, auf keinem mir zur Verfügung stehen den Rechner. Wer herausfindet, wie es geht, wird herzlich um einen Kommentar gebeten! Bis dahin bleibt nur: manuell wieder zum untersuchten Server verbinden, einzeln aus der Liste heraussuchen und so weiter.

Es gibt Probleme, wenn man die Projekte zwischen beiden Versionen hin- und herschiebt…und die sind leider sehr versteckt!

Hier ein Beispiel, welches in diesen Zusammenhang die Problematiken mit Flatfile-Connection-Managern aufzeigt. Zum Nachvollziehen bitte einfach dem hier beschriebenen Ablauf folgen:

SSIS-Package im BIDS-2008-Nicht-R2 öffnen:
im FlatFile-ConnectionManager als Textqualifier “ eintragen und Paket speichern

SSIS-Package im BIDS-2008-R2 öffnen:
im ConnectionManager ist als Textqualifier immernoch “ eingetragen.
jetzt OK drücken und dann speichern

SSIS-Package wieder im BIDS-2008-Nicht-R2 öffnen:
Jetzt steht dort _x0022_ direkt im Klartext als Textqualifier.
( _x0022_ ist eigentlich die XML-Quellcode-Kodierung für “).

Dementsprechend problematisch wird der Datei-Import über die NichtR2-SSIS-Runtime
Die Anführungszeichen sind nämlich noch in allen Spalten enthalten und sämtliche Zahlen-konvertierungen schlagen fehl. Dies ist natürlich sehr schwer nachzuvollziehen, da im BIDS-R2 alles normal aussieht, man sieht das _x0022_ wirklich nur, wenn man das Paket in einem Nicht-R2-BIDS öffnet.

Ich hoffe, dies kann Euch bei ähnlichen Problemstellungen helfen.

Das Problem begegnet uns immer dann, wenn in der Datenbank Werte in einer anderen Granularität gespeichert werden (in diesem Fall monatsgenau) als diese von der darauf aufsetzenden Anwendung geliefert werden (diese erlaubt nur jahresgenaue Werte). Für spätere Auswertungen oder Änderungen möchten wir monatsgenaue Werte speichern, ohne den korrekten Jahreswert (die Summe der 12 Monate) zu verlieren.

Auch hier führen wieder viele Wege nach Rom, daher zeige ich im ersten Teil neben der eigentlichen Problemstellung und dem Kern der Lösung eine von vier (!) Möglichkeiten die ich gefunden habe um die Aufgabe zu lösen.

Zunächst einmal überlege ich mir geeignete Ausdrücke um die oben genannte Anforderung innerhalb eines SSIS-Datenfluss’ umsetzen zu können. Für die Monate 1 bis 11 genügt folgender Ausdruck:

(DT_NUMERIC,6,2)(Value / 12)

Der Monat 12 erfordert eine Sonderbehandlung, welche durch folgenden Ausdruck gewährleistet wird:

(DT_NUMERIC,6,2)(Value – (DT_NUMERIC,6,2)(11 * (DT_NUMERIC,6,2)(Value / 12)))

Im Grunde ermittelt dieser Ausdruck die Differenz zwischen dem Jahreswert und der Summe der 11 Monatswerte um den Wert für Monat 12 zu berechnen. Beachten Sie dabei, dass es egal ist ob bei der Ermittlung der Monatswerte ab- oder aufgerundet oder gar abgeschnitten wird (was hier der Fall ist), der Wert für Monat 12 wird stets korrekt ermittelt.

Einer der naheliegendsten Wege um diese Logik umzusetzen ist die Nutzung eines Cross Joins zwischen dem Jahreswert und 12 Monaten. Damit wird der Jahreswert von einer Zeile auf 12 Zeilen verteilt. Anschließend kann in einem “Abgeleitete Spalte”-Task der Wert mit Hilfe der oben beschriebenen Ausdrücke manipuliert werden.

Folgender Screenshot zeigt den Datenfluss und zwei Data Viewer: einen nach dem Cross Join und einem nach dem Anwenden der Ausdrücke. Beachten Sie, dass sich der Wert für Monat 12 von allen anderen unterscheidet um einen korrekten Jahreswert zu gewährleisten.

Im zweiten Teil zeige ich drei (!) weitere Vorgehensweisen, sowie die Ergebnisse eines Performancetests um zu ermitteln, wie sich die unterschiedlichen Wege im produktiven Einsatz bewähren könnten.

Da es sich bei Excel jedoch nicht um eine Server Applikation für Hintergrundanwendungen handelt sind bei dem Einsatz dort einige Fallstricke zu umschiffen.

In Folge werden wir einen kleinen Windows Service entwickeln, der in der Lage ist en Verzeichnis zu überwachen, Excel Dateien dort zu lesen, zu modifizieren und sie in ein Ausgabe Verzeichnis zu kopieren. Hierzu müssen Visual Studio, die Microsoft Interop Assemblies als auch Microsoft Excel auf dem Entwicklungssystem installiert sein.

Erstellung des Windows Service Projektes

Wir benutzen dafür die entsprechende Projektvorlage unter Visual C# / Windows

Zusätzlich benötigen wir die Referenz auf die entsprechende Excel Interop Assembly: Microsoft.Office.Interop.Excel (14.0.0.0).

Nachdem Sie die automatisch generierte Service Komponente umbenannt haben, benötigen wir Routinen zur Installation des Service. Diese können am einfachsten über das Kontext Menü im Komponenten Designer erstellt werden.

Der letzte Teil der Vorbereitungen ist die Erstellung eines Setup Projektes als Teil der Solution. Wir benutzen auch hier wieder die entsprechende Vorlage, und fügen die Primäre Ausgabe unseres Projektes hinzu. Und zum Abschuss fügen wir die Primäre Ausgabe auch noch einmal zu den Benutzerdefinierten Aktionen hinzu, um die weiter oben bereits generierten Installations Routinen für den Service auch während des Setups ausführen zu lassen.

Für die Deinstallation muss diese Aktion natürlich auch ausgeführt werden.

Implementierung der Logik

Nachdem wir nun alle Vorbereitungen getroffen haben können wir nun zu dem interessanterem Teil der Entwicklung kommen.

Da der Service als Hintergrund Applikation laufen soll erstellen wir einen Service Loop mittels eines Threads den wir starten und stoppen können. Wir wechseln hierzu in die Code Ansicht unserer Service Komponente, und implementieren den Rumpf dieser Schleife.

public partial class BlogExcelService : ServiceBase

{

private bool ServiceShouldRun { get; set; }

private Thread ServiceRunner { get; set; }

public BlogExcelService()

{

InitializeComponent();

}

protected override void OnStart(string[] args)

{

ServiceRunner = new Thread(new ThreadStart(ServiceLoop));

ServiceShouldRun = true;

ServiceRunner.Start();

}

protected override void OnStop()

{

if (ServiceRunner != null && ServiceShouldRun && ServiceRunner.IsAlive)

{

ServiceShouldRun = false;

ServiceRunner.Join(10000);

}

}

protected void ServiceLoop()

{

while (ServiceShouldRun)

{

Thread.Sleep(3000);

}

}

}

Die eigentliche Implementierung unserer wiederkehrenden Aufgaben können wir nun innerhalb der Methode ServiceLoop implementieren. D.h. als erstes selektieren wir alle Excel Dateien im Eingangsverzeichnis, und bewegen sie in ein Bearbeitungsverzeichnis. Dort werden diese Dateien geöffnet, ein neues Blatt eingefügt und nach dem Speichern in das Ausgabeverzeichnis verschoben.

protected void HandleNewFiles()

{

var inputDirectory = new DirectoryInfo(Settings.Default.InputPath);

foreach (var file in inputDirectory.GetFiles(“*.xlsx”))

{

var tempFilename = Settings.Default.TempPath + @”\” + file.Name;

var outputFilename = Settings.Default.OutputPath + @”\” + file.Name;

file.MoveTo(tempFilename);

var tempFile = new FileInfo(tempFilename);

EditFile(tempFile);

tempFile.MoveTo(outputFilename);

}

}

protected void EditFile (FileInfo f)

{

var excelApp = new Application() {DisplayAlerts = false, Visible = false};

var workbook = excelApp.Workbooks.Open(f.FullName);

var sheet = workbook.Sheets.Add() as Worksheet;

var cell = sheet.Range["A1"];

sheet.Name = “ExcelService”;

cell.Value2 = “Hello World”;

workbook.Save();

workbook.Close();

excelApp.Quit();

Marshal.FinalReleaseComObject(cell);

Marshal.FinalReleaseComObject(sheet);

Marshal.FinalReleaseComObject(workbook);

Marshal.FinalReleaseComObject(excelApp);

}

Da wir uns in einem lang laufendem Prozess befinden, ist es notwendig die über Interop verbunden COM Objekte wieder frei zu geben, da diese sonst Memory Leaks oder verwaiste Excel Prozesse hinterlassen können. Dieses erreichen wir über die Aufrufe am Ende der Edit File Methode.

Zum Debuggen verfügt Visual Studio leider über keinen direkten Start Typen für unser Projekt, d.h. wir werden uns mit einem kleinem Umweg dorthin begeben müssen. Wir installieren als erstes den Service über das Kontextmenü des Setup Projektes.

Dabei müssen während der Installation auch die Zugangsdaten des Ausführenden Benutzers übergeben werden. Während der Entwicklung benutzt man entweder schon das Zielkonto oder das eigene. Die Berechtigungen dieses Benutzers werden benötigt um Verzeichnisse zugreifbar zu machen oder Datenbankverbindungen zu autorisieren.

Nachdem wir den Service über die Service Console gestartet haben verbinden wir uns mit dem Dienstprozess aus Visual Studio heraus.

Jetzt sind wir in der Lage unseren Service zu debuggen, und stoßen auf einen Fallstrick:

Sobald wir eine Excel Arbeitsmappe im Input Verzeichnis hinterlegen kommt es zu folgender Fehlermeldung:

Der Service wird zwar mit den Berechtigungen des eingegebenen Benutzerkontos ausgeführt, jedoch wird das System Profil als Umgebung geladen. Da Excel ein Benutzerapplikation ist setzt sie auch ein Desktopverzeichnis im Profil voraus, jedoch besitzen weder Windows 2008 und Windows 7 diese standardmäßig im Profil.

Erzeugen Sie je nach Plattform folgende Verzeichnisse:

Wenn wir jetzt den Service ausführen können wir fehlerfrei unsere Excel Dateien modifizieren:

Mögliche weitere Fehlerquellen können sein, dass kein Standarddrucker eingerichtet ist, oder dass der Service Benutzer keine Berechtigungen auf die verwendeten Verzeichnisse hat.

Letze Worte

.NET und Excel bieten vielseitige Möglichkeiten. Man sollte aber immer daran denken, dass Excel kein Serverprodukt ist, und somit immer damit gerechnet werden muss, das Benutzerinteraktion erforderlich sein kann. Jedoch sind die allermeisten Eigenheiten programmatisch umschiffbar.

… be a good ninja .. use C#

Andreas Schwarzer

Fachbereichsleiter SharePoint und Anwendungsentwicklung
ixto GmbH

In Abbildung 1 ist das Klassendiagramm des ExcelButlers dargestellt. Unter „Methods“ sind die implementierten Methoden aufgelistet. Hier könnte man mit der Methode OpenWorkbook() ein bestehenden Excel-Dokument öffnen, mit der Methode InsertCellContent() beschrieben und mit der Methode SaveAndClose() wieder abspeichern.

Abbildung 1: Ansicht des Klassendiakgramms des ExcelButlers

Doch bevor das überhaupt möglich ist sind einige vorbereitende Schritte zu tun. Wenn man vor hat ein Excel-Dokument innherhalb eines SSS-Paketes mit dem ExcelButler dort zu befüllen, müsste eine C#-Konsolenapplikation im Visual Studio erstellt werden. Zu Beginn ist bei den Verweisen der Verweis zur Microsoft.Office.Interop.Excel .NET-Komponente hinzuzufügen. In Abbildung 2 ist das dargestellt. Anschliessend muss die Komponente mit der using-Direktive im Code eingebunden werden:

using Excel = Microsoft.Office.Interop.Excel;

Abbildung 2: Hinzufügen der .NET-Komponente

Nun kann sofort die ExcelButler-Klasse instanziiert werden:

ExcelButler butlerinstanz = new ExcelButler();

Nach Schaffung des C#-Objektes butlerinstanz muss mit ihrer Hilfe nun eine Excel-Instanz erzeugt werden:

butlerinstanz.CreateExcelInstance(true, out error);

Nach Ausführen des Befehls CreateExcelInstance mit dem ersten Parameter Visible = true öffnet sich sofort Excel, was der Entwickler am Bildschirm beobachten kann. Wenn nach Entwicklungsabschluss später die Excel-Dateien automatisiert innherhalb eines SSIS-Paketes erzeugt werden sollen, muss der Visible-Parameter auf false gesetzt werden, um eine fehlerlose Excel-Generierung im Hintergund zu bewerkstelligen.

Nun kann mit der Methode OpenWorkbook ein bestehendes Dokument geöffent und in die Excel-Instanz geladen werden. In Abbildung 3 ist diese Routine beispielhaft dargestellt.

Abbildung 3: Ansicht eines Code-Ausschnittes für die Routine OpenWorkbook()

Nun ist es möglich mit den zur Verfügung stehenden Routinen (zum Beispiel InsertCellContent) die Excel-Datei beliebig zu befüllen:

butlerinstanz.AddWorkbook(out error);

butlerinstanz.AddWorksheet(“testblatt”, out error);

butlerinstanz.InsertCellContent(1, 1, “testwert”, out error, “testblatt”);

butlerinstanz.InsertCellContent(1, 2, “testwert”, out error, “testblatt”);

Nun könnte eine Datenbankverbindung geöffnet warden eine Datenbankabfrage gemacht werden, die Ergebnisse dieser Abfrage in ein DataSet geschrieben werden und anschliessen das DataSet iteriert werden und mit InsertCellContent an beliebige Zellen im Excel-Dokument Werte geschrieben werden. Nach Beschreiben der Excel-Datei ist das Dokument mit der Routine SaveAndClose() abzuspeichern und zu schliessen.

Abbildung 4: Einbindung des ExcelButlers in ein SSIS-Paket

Schlussendlich kann man die komplette Erstellung der Excel-Datei nun in ein SSIS-Paket einbinden. Hierzu sind zu Beginn die im Excel-Dokument anzuzeigenden Daten bereitzustellen und anschliessend in einem Prozess-Ausführ-Task die Konsolenapplikation, bei Bedarf mit Parameterübergabe, auszuführen (siehe Abbildung 4).

Zusammenfassend sind also folgende Schritte zu tun:

1. in einem herkömmlichen SSIS die im Excel anzuzeigenden Daten bereitstellen (für vereinfachten späteren Lesezugriff idealerweise in einer extra für dieses Zweck geschaffenen Persistierungstabelle)

2. C#-Konsolenapplikations-Projekt im Visual-Studio erstellen, .NET-Komponente einbinden, ExcelButler-Instanz erzeugen und Excel mit Visible = false öffnen

3. Innerhalb der Konsolenapplikation Datenbankverbindung öffen und die in Punkt 1 beschriebene Persistierungstabelle abfragen und iterieren und in jedem Iterationsschritt Excel mit InsertCellContent() befüllen

4. Excel mit SaveAnClose() speichern und schliessen

5. Die C#-Main-Rountine mit dem Process-Exit-Code = 0 verlassen

Als Hinweis sei an dieser Stelle noch gesagt, dass empfindliche Code-Stelllen in der Konsolenapplikation, wie beispielsweise das Abfragen von Datenbanken, in Try-Catch-Blöcke gekapselt werden sollten und die Exceptions kontrolliert aufgefangen werden sollten. Bei eventuell auftretenden Fehlern sind dann enstprechend sinnvolle Exit-Codes zu vergeben (zum Beipiel: -3, Datenbankserver nicht verfügbar, oder: -4, keine Zugriffsberechtigung auf das Verzeichnis XY zum Abespeichern der Excel-Datei). Diese Codes sollte die Main-Rountine dann zurückliefern (Beispiel: return -7) und das SSIS-Paket wird diese Codes auswerten und so Fehler erkennen.

Das wars, so einfach und komfortabel kann das sein.