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

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.

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.

Mit ein bischen Glück findet man eine geeignete Karte im .shp (Shape) – Format im www und kann diese ganz einfach importieren. Was aber ist zu tun, wenn man keine passende Datei findet oder wenn etwas visualisiert werden soll, wovon nur ein Foto existiert?

Dieser Beitrag soll Ihnen die (technischen) Voraussetzungen erläutern, aus einem einfachen Bild eine Shape-Datei anzufertigen und diese in Ihren Bericht einzubinden.

Vorbereitung:

Karte suchen – am besten ohne Beschriftungen und nur in 2 Farben gehalten (s/w).
Hinweis: bei bestimmten Karten sind für einige Vektorisierungsprogramme die Trennungen bestimmter Bereiche nicht erkennbar. Bildbearbeitung notwendig!
Beste Ergebnisse erzielt man, wenn der Hintergrund und die Trennlinien weiß sind (gleich gefärbt) und die einzelnen zu vektorisierenden Bereiche schwarz sind (in einer Farbe gehalten) und keine störenden Pixel vorhanden sind.

weitere Voraussetzungen:

- Programm zum vektorisieren der Karte (z.B. Photoline, Freeware).
- Programm, welches Vektordateien konvertieren kann (um das gewünschte .shp Format zu erhalten [Cad2Shape]).
- Programm mit welchem man Metadaten pflegen kann (bestimmten Ebenen die gewünschten Daten zuzuordnen [fGis]).

Karte

Findet man nur eine derartige Karte, wäre zu einer Bearbeitung zu raten.
(oder man vektorisiert selbst)

Quelle: http://www.strolchundmiez.de/img/berl_bez.gif

Vektorisieren:

Bei den Vektorisierungsprogrammen kann man meistens die Genauigkeit einstellen mit der die gewünschte Fläche vektorisiert wird. Entstehen zu viele Polygone bei der Vektorisierung, können diese ausgeblendet werden.
Wer viel Zeit und Erfahrung hat, kann das Vektorisieren auch manuell vornehmen.

Konvertieren

Beim Konvertieren ist darauf zu achten, dass bei den Optionen „Polygon“ auswählt wird, da es sich um Flächen handelt. Ansonsten muss das Programm die Shape-Dateien erstellen können, die wir für den Import benötigen.

Metadaten pflegen

Die Metadaten legen fest, zu welchem Shape ein bestimmter Wert zugeordnet ist.
Mit einem Programm wie „fGis“ lässt sich die Shape-Datei öffnen und bearbeiten.
Dazu einfach die Tabelle mit den einzelnen Shapes öffnen und die gewünschten Daten einpflegen und abspeichern.

Nun ist die Shape-Datei bereit für den Import.

Wer das Prinzip verstanden hat und sich an anspruchsvolleren Projekten versuchen will, wie zum Beispiel Karten mit genauen Koordinaten auszuwerten, den könnte folgender Link interessieren:

http://www.raumberg.at/Unterricht/GIS/UZR_GI_PU_01.pdf

Die Datenbank

Zunächst sollte Klarheit darüber herrschen, welche Datenbankobjekte übertragen werden müssen. Vorbildliche Naturen können diese Frage mit einem Blick in die Historie ihrer professionellen Versionsverwaltung (natürlich inklusive Application LifeCycle Management) sogar des Nächtens im Halbschlaf beanworten (vielleicht haben sie auch mit Zettel und Stift mitgeschrieben), aber auch wenn diese Professionalität des Vorgehens nicht erreicht werden kann oder soll, gibt es es nützliche Hilfsmittel, die uns auf unter die Arme greifen helfen. Das OpenSource-Tool OpenDBDiff bietet die Möglichkeit, zwei Datenbank-Stände miteinander zu vergleichen. Es entsteht dabei ein SQL-Skript, dass ausgeführt auf der Zieldatenbank die ausgewählten Objekte synchronisiert. Dabei sei angemerkt, dass hierbei eigentlich nur Tabellenobjekte kritisch sind, da sich alle anderen, wie Views, Stored Procedures und User-Defined Functions, auch durch Löschen und Neu-Anlegen auf den gleichen Stand bringen lassen. Aber wenn wir OpenDBDiff ohnehin gestartet haben, sparen wir uns die Mühe.

Der zweite Schritt besteht im Abgleich von Steuerdaten, die zumeist in Konfigurationstabellen schlummern. Dazu kann uns das Tool TableDiff dienen, mit dessen Hilfe Unterschiede in Tabellendaten abgeglichen werden, indem auch hier SQL-Skripte generiert werden. Das Tool ist Bestandteil der SQL Server Installation und lässt sich zumeist unter C:\Program Files\Microsoft SQL Server\100\COM finden und aufrufen, wobei der Pfad je nach SQL Server Version und dessen Installationsverzeichnis varieren kann. TableDiff geht dabei tabellenweise vor, weshalb es sich anbietet, eine Batchdatei zu programmieren, die den Aufruf pro Tabelle automatisiert.

rem Server festlegen

set sserver=localhost

set dserver=localhost

rem Datenbanken festlegen

set sdb=AdventureWorksDW

set ddb=AdventureWorksDW2008

rem Pfade definieren

set exepath=”C:\Program Files\Microsoft SQL Server\100\COM\tablediff.exe”

set destfolder=D:\SQL

rem Schema festlegen

set schema=dbo

for %%t in (dimCurrency dimScenario) do (

%exepath% /sourceserver %sserver% /sourcedatabase %sdb% /sourceschema %schema%  /sourcetable %%t /destinationserver %dserver% /destinationdatabase %ddb% /destinationschema %schema% /destinationtable %%t -f “%destFolder%\changeScript(%schema%_%%t).sql”

)

Wir haben nun eine Reihe von SQL-Skripten, die nur noch auf der Zieldaten ausgeführt werden müssen, um die Datenbankstruktur in einen identischen Zustand zu bringen.

SSIS-Pakete und Cube-Defintionen

Es gilt nun, sowohl SSIS-Pakete und Cube-Definitionen zu übertragen. Dies ist etwas einfacher, da sowohl für SSIS- als für SSAS-Projekte einen Deployment-Wizard existiert, der uns das Bereitstellen auf dem Zielsystem (fast) vollständig abnimmt. Im Falle von SSIS-Paketen besteht weiterhin die Möglichkeit, auf das Kommandozeilenwerkzeug dtutil zurückzugreifen, das, eingebettet in eine Batch-Datei, das Bereitstellen der Pakete nach einem Doppelklick automatisch übernehmen kann. Da wir selbst in kleineren Projekten intensiven Gebrauch von der SSIS-Paketkonfiguration machen, haben wir auch wenig Mühe damit, Informationen wie Server- oder Datenbanknamen zu aktualisieren. SSAS-Cubes  müssen nur noch verarbeitet werden und sind damit direkt bereit zum Einsatz. Aber auch hier gilt es, eine gewisse Vorsicht an den Tag zu legen, da doch der ein oder andere Fallstrick lauert. Einer dieser Fallstricke sind Cube-Rollen, die ohne weitere Konfiguration auf dem Zielserver überschrieben werden. Doch auch wenn wir dies explizit verhindern wollen (die entsprechende Option im Deployment Wizard heißt Retain Roles und Members), ist leider nicht immer gewährleistet, dass die bestehende Konfiguration erhalten bleibt. Hier hat sich der Workaround etabliert, die Rollendefinition auf dem Produktivserver zu sichern (Zu finden im entsprechenden Bereich in der XMLA-Datei, also der Datenbankdefinition, auf der SSAS-Datenbank) und nach dem Deployment zurückzuspielen.

Die Berichte

Für SSRS-Berichte hat sich ein ein Werkzeug bewährt, dass es uns ermöglicht, Berichte direkt vom (Test)Berichtsserver herunterzuladen und auf den (Produktiv)Berichtsserver zu übertragen. Dazu wird neben den Berichtsdefinitionen in Form von .rdl-Dateien eine Batchdatei generiert, in der nur noch die URL des Zielsystems hinterlegt werden muss. Nach einem Doppelklick können wir und zurücklehnen und die Deployment-Show genießen.

Fazit

Mit dem vorgestellen Vorgehen und Werkzeugen ist es uns, ein recht elegantes Deployment unserer BI-Solution auf entfernte Umgebungen vorzunehmen. Großer Vorteil dabei ist die Möglichkeit, weite Teile durch Batch-Dateien und Konfigurationen zu automatisieren und damit den Aufwand mehrmaliger Deployments zu merklich reduzieren.

Gegeben ist eine Hilfstabelle wo für jede Kennzahl der Name, den Wertebereich (z.B. 20 – 70 für das Alter) und die Anzahl der gewünschten Buckets (z.B. 5 für das Alter, womit jedes Bucket einen Bereich von 10 Jahren abdeckt) enthält. Die Hilfstabelle “Kennzahlen_Bucketdefinition” enthält in unserem Beispiel zwei Kennzahlen: Alter und Einkommen.

Abgespeichert wird für jedes der erzeugten Buckets ein Datensatz mit dem Start und dem Ende des Intervalls sowie die Bezeichnung der Kennzahl, um die es geht. Zusätzlich wird eine fortlaufende Nummerierung der Buckets erzeugt. In diesem Beispiel werden für jede Kennzahl zwei zusätzliche Buckets erzeugt, nämlich eines für alle Werte, die kleiner als der Startwert des Wertebereichs sind (nach unten offen) und eines für alle Werte, die größer als der Endwert des jeweiligen Wertebereichs sind (nach oben offen). Auf die Erzeugung dieser zusätzlichen Buckets kann je nach Anwendungszweck natürlich in der Realität auch verzichtet werden.

Bei der Umsetzung der Anforderung wird ein rekursiver allgemeiner Tabellenausdruck verwendet, der eine kurze und einfache Umsetzung ermöglicht. Es wird dabei zunächst die Startmenge (Rekursions-Anker) festgelegt, die aus dem jeweils ersten Bucket-Datensatz für jede Kennzahl besteht (das nach unten offene Startintervall gekennzeichnet mit NULL als Startwert). Auf diese Menge wird dann das rekursive Statement ausgeführt, das für jeden Datensatz in der Startmenge den Nachfolgedatensatz erzeugt. Darauf folgend wird für die Ergebnismenge (die erzeugten Nachfolgedatensätze)  wiederrum das rekursive Statement aufgerufen. Das wird dann für jede Zwischenschritt-Ergebnismenge ausgeführt, bis nach einem Schritt keine Zeilen mehr in der Ergebnismenge sind, dann bricht die Rekursion ab. Das wird in unserem Beispiel erreicht, wenn die Bucket-Nummer den vorgegebene Wert für die maximale Anzahl an Buckets erreicht hat. Das jeweils letzte Bucket für jede Kennzahl wird als oben offen erzeugt (NULL als Endwert).

Der Abfrage für den rekursiven allgemeinen Tabellenausdruck (CTE – Common Table Expression) sieht wie folgt aus:

;WITH MyCTE AS

(
–1. Teil (Anchor): festes Statement als Start der Rekursion (erstes Bucket):
– erstes Bucket = Pufferbucket für alle Werte, die kleiner sind als die Bucket-Range; daher unten offen

SELECT
Kennzahl_Name,
BucketNr=1,
BucketStart = CONVERT(decimal(18,2),NULL),
BucketStop = CONVERT(decimal(18,2),Intervall_Start),
BucketLength = CONVERT(decimal(18,2),(Intervall_Ende-Intervall_Start)/ (Buckets_Anzahl)),
maxBuckets = Buckets_Anzahl+2
FROM Kennzahlen_Bucketdefinition

UNION ALL
–2. Teil (Recursive): dynamisches (rekursives) Statement
– letztes Bucket = Pufferbucket für alle Werte, die größer sind als die Bucket-Range; daher oben offen

SELECT
Kennzahl_Name,
BucketNr=BucketNr+1 ,
BucketStart=ISNULL(BucketStop,0),
BucketStop=CASE WHEN BucketNr+1 < maxBuckets THEN CONVERT(decimal(18,2), Bucketstop+BucketLength) ELSE NULL END,
BucketLength,
maxBuckets
FROM MyCTE WHERE BucketNr+1 <= maxBuckets
)

SELECT Kennzahl_Name,BucketNr,BucketStart,BucketStop FROM MyCTE
ORDER BY Kennzahl_Name, BucketNr
OPTION (MAXRECURSION 32767 );

Das Ergebnis des Aufruf sieht wie gewünscht aus:

:

Anmerkungen: Um Uneindeutigkeiten bezüglich des Schlüsselwortes WITH zu vermeiden, muss bei einer CTE-Definition in einem Batch (außer es ist die erste Anweisung) die Anweisung vor WITH mit einem Semikolon abgeschlossen werden. Es ist also ganz praktisch immer ein Semikolon vor WITH zu schreiben, um das nicht zu übersehen.
Der  Wert für MAXRECURSION ist optional. Er gibt die maximal erlaubte Anzahl von Rekursionsschritten an. Wird der Wert nicht explizit gesetzt, gilt übrigens der serverweite Default-Wert 100. Die CTE-Abfrage würde dann beim 101-ten Rekursionsschritt eine Ausnahme auslösen. Wird der Wert auf 0 gesetzt, ist die Rekursionstiefe unbegrenzt, was aber bei fehlerhaft geschriebenen CTEs zu einer Endlosschleife führen kann.