SSIS-Components.net

Vor ein paar Wochen hat Microsoft einem ersten Benutzerkreis Zugang zu ihrem neuen “Data Explorer” Cloud Service gewährt. Am 13.12. wurde der SQL Azure Labs Codename “Data Explorer” Client in einer öffentlichen Variante nachgelegt.

Der “Data Explorer” ist eine Anwendung, mit der Daten aus verschiedenen Daten geladen, konvertiert, angereichert und wieder ausgegeben werden können. Wer jetzt an ein ETL Tool denkt, der liegt meiner Ansicht nach eigentlich gar nicht so verkehrt. Jedoch handelt es sich bei dem “Data Explorer” nicht um eine komplexe “Workflow-Engine” mit der vollständig automatisierte Prozesse inkl. Fehlerbehandlung usw. aufgesetzt werden können, sondern eher um ein Programm, das zum bearbeiten und verarbeiten einzelner, gezielter Datenquellen dient.

 

     

 

Mit dem Data Explorer werden sogenannte Mashups erstellt, die Daten aus den verschiedensten Quellen konsumieren können. Hierzu gehören SQL Datenquellen, Web-Seiten, Data Feeds, Sharepoint Listen, der Windows Azure Marketplace, verschiedene Dateien wie Excel oder CSV, Data Explorer Mashups, die direkte Texteingabe oder Daten die über Formeln generiert und geladen werden. Dateien können nicht nur vollständig importiert werden, sondern es kann auf diese auch verlinkt werden, wodurch dann auch Änderungen aus den Quellen übernommen werden.

Der “Data Explorer” besitzt eine Vielzahl von Funktionen, mit denen die Daten verarbeitet werden können, derzeit sind diese in die Kategorien “Filter”, “Order”, “Column Names” und “Transform” gruppiert. Hierunter befinden sich z.B. Funktionen wie Umbenennen, Löschen von Zeilen oder Spalten, Zusammenführen oder Trennen von Spalten oder auch z.B. eine Funktion namens “Fill Down”, mit der NULL Werte in einer Spalte mit einem speziellen Wert aufgefüllt werden können.

Sehr nett finde ich die Verwendung der aus dem Web bekannten “Breadcrumbs” als Navigation für die Verarbeitungshistorie der Daten.

Der Anwender kann über diese Breadcrumbs an jede beliebige Stelle innerhalb der einzelnen Schritte zurückspringen oder einzelne Verarbeitungsschritte löschen.

Die mit dem Client erstellten Daten können derzeit nur als “.import”-Datei gespeichert werden, einem Austauschformat zwischen den Clients oder der Azure Version. Mit der Installation des Clients wird aber auch ein Excel Plugin installiert, mit dem Daten direkt aus den Workspaces des lokalen Data Explorers in Excel importiert werden können. Über die Azure-Version können Mashups auch online publiziert werden. Die so publizierten Mashups stehen als OData Feed zur Verfügung oder können direkt als Excel und CSV Datei heruntergeladen werden.

Allgemein finde ich den Data Explorer einen sehr guten Ansatz um Daten aufzubereiten. Speziell die Möglichkeit Daten über die integrierte Formula Language zu laden bietet einem umfangreiche Möglichkeiten. Derzeit reagiert die Client Version leider noch ein bisschen träge.

Auf der Seite Learn More about Microsoft Codename "Data Explorer" hat Microsoft umfangreiche Videos zur Verfügung gestellt, die einen sehr guten Einblick in das Programm liefern. Jamie Thomson hat in seinem Blog mit Data Explorer walkthrough – Parsing a Twitter list und Querying RSS feed subscriber count on Google Reader using Data Explorer‏ auch zwei sehr gute Artikel veröffentlicht, die intensiver auf die integrierte Formula Language eingehen.

Sonstiges Data Explorer, Azure, Jamie Thomson, Datenqualität

Bei der Erstellung eines SQL Server Reports mit einer Weltkarte kam es bei mir die Tage leider immer wieder zu folgenden Fehlermeldungen:

 

 

 

Erst später ist mir bewusst geworden, das der Report mit meiner eingebetteten Weltkarte eine Größe von ca. 10 MB hat.

Der Fehler an dieser Stelle ist eigentlich bekannt und auch eigentlich kein direkter Fehler, erst recht nicht der der SQL Server Reporting Services. ASP.NET Anwendungen sind prinzipiell so konfiguriert, dass nur Dateien mit einer max. Größe von 4MB (28 MB im IIS 7) auf den Server übertragen werden können. Die Einstellung selber lässt sich durch Anpassungen an der web.config beheben, jedoch wird hiervon im Rahmen von Security Best Practices abgeraten.

Das Problem liegt aber eigentlich an den Shape-Dateien. Möchte ich nämlich folgenden Report darstellen

 

so beinhalten die Daten auch die folgende Informationen:

 

Ähnliche detaillierte Daten sind auch in der oberen Region von Canada oder an der Küste von Chile zu finden. Diese Menge an Daten, die wahrscheinlich für die meisten Anwender und einer einfachen Darstellung der Erde viel zu komplex sind, sind primär dafür zuständig, dass die Daten nicht auf den Server geladen werden können.

Eine Möglichkeit den Report kleiner zu bekommen, ist den ShapeFile inkl. der DBF Datei auf einen ReportServer zu laden, jedoch gilt auch hier die oben angesprochene Größenbeschränkung und hilft damit nicht wirklich weiter.

Eine weitere Möglichkeit die Größe des Reports zu verkleinern ist alle nicht benötigten Daten zu entfernen. Hiermit meine ich im ersten Moment Daten aus der zum ShapeFile gehörenden dbase Datei. Hier werden häufig viele Felder mitgeliefert die später nicht im Bericht verwendet und/oder angezeigt werden.

Eine weitere Möglichkeit den Bericht bzw. die Datenmengen zu verkleinern, ist es die ShapeFiles direkt im BIDS oder im Report Builder zu bearbeiten und nicht benötigte Polygone zu löschen.

Zumindest bei meiner Weltkarte sind jedoch beide Methoden nicht ausreichend um die Daten so zu reduzieren, dass der Bericht auf dem Server gespeichert werden kann. Und dabei würden meine “neuen” Karten mit Sicherheit noch nicht einmal jedem so gut gefallen.

 

 

Grundsätzlich kann man an der Stelle sagen, die Daten nicht im Report zu speichern sondern diese dynamisch - wie oben angesprochen - aus einem ShapeFile oder von einem SQL Server zu laden ist wesentlich besser.

Hier zeichnet sich natürlich der Vorteil des SQL Servers gegenüber den ShapeFiles ab, da ich keiner direkten Größenbeschränkung unterliege. Habe ich meine Spatial Data im SQL Server gespeichert und nicht im Bericht eingebettet, so kommt meiner Beispielreport auf gerade einmal 20 KB.

Möchte ich Daten aber dennoch in meinem Bericht einbetten, so kann ich die einmal aus dem SQL Server geladenen Daten ganz einfach per Maus-Click wieder in meinen Bericht einbetten, womit der Bericht dann allerdings nur noch ca. 450 KB groß wird. Beim Einbetten der Daten wird nur der sichtbare Bereich der Daten eingebettet und dabei die Daten drastisch reduziert. Hat alleine Chile mit der stark zerklüfteten Küste aus dem ShapeFile heraus noch eine Größe von knapp 400 KB, so kommt das Land beim Einbetten der Daten aus dem SQL Server nur noch auf knapp 8 KB, die oben im Screenshot dargestellte Vergrößerung der Falklandinseln spart über 30 KB. Zu finden sind die entsprechenden Daten im übrigen jeweils in der RDL-Datei unter <VectorData>, im den darauf folgenden Tags <MapFields> sind auch die aus der DBF zugeordneten Daten wiederzufinden.

Um ShapeFiles in den SQL Server zu Laden kann man meine SSIS ShapeFileSource oder das Programm Shape2SQL von Morten Nielsen verwenden.

Nützliche Informationen zum Download von Spatial Data findet sich in meinem Blog Beitrag Geodaten – Teil 1 oder auch im Blog Beitrag “Addresses for geographical Data, ESRI-Shapefiles and other SQL Server geographical related stuff” meines PASS RGV Kollegen Andreas Wolter.

Sonstiges Spatial Datam, SSRS, geocoding, Shapefiles, ShapeFileSource

Workflows innerhalb der Integration Services habe ich bisher primär über “Constraints” und bei komplexeren Abläufen zusammen mit speziellen Einschränkungen abgebildet. In einem aktuellen Projekt bin ich darüber gestolpert, wie Workflows fast ausschließlich über das aktivieren und deaktivieren - also der Eigenschaft “Disable” – eines Tasks erstellt wurden.

Da diese unterschiedliche Herangehensweise zu einer doch recht kontroversen Diskussion geführt hat, habe ich im Folgenden einmal ein Szenario mit beiden Vorgehensweisen nachgebaut, um die Unterschiede genauer zu erklären.

Das Demo-Paket hat 3 verschiedene Abläufe:

1. Task 2 so wie der Rest des Paketes werden nicht ausgeführt
2. Task 3 wird nicht ausgeführt, Task4 und Task5 sollen dennoch ausgeführt werden
3. Task A und Task B sollen nicht ausgeführt werden.

 

Das Paket wird dafür mit verschiedenen Variablen versehen, über die die einzelnen Abläufe gesteuert werden.

Der wichtigste Unterschied zwischen den beiden Varianten gleich vorweg:

Tasks die deaktiviert werden unterbrechen nicht den Ablauf eines Paketes sondern werden übersprungen bzw. ausgelassen.

 

Disable

Im ersten Schritt ist die Variante “Disable” zu sehen. Hier werden die Tasks und Sequenzcontainer über die jeweilige Expression “Disable” aktiviert bzw. deaktiviert.

Durch den installierten BIDS Helper sieht man in dem Paket über die magentafarbenen Ecken sehr gut wo Expressions gesetzt worden sind und dadurch das Paket beeinflusst wird.

Ablauf 1: Der gesamte relevante Teil des Paketes wird in einen Sequenzcontainer ausgelagert. Wenn der Task 2 - und somit das gesamte weitere Paket - nicht ausgeführt werden soll, wird der Sequenzcontainer “Sequenz A” über die Expression auf “Disable” gesetzt.

Ablauf 2: Task3 wird über die Expression auf “Disable” gesetzt. Da der Task nur “übersprungen” wird, werden Task4 und Task5 weiterhin ausgeführt.

Ablauf 3: Wie bei Ablauf 1, wird der gesamte Ablauf wieder in einen Sequenzcontainer ausgelagert und dieser durch die Expression auf “Disable” gesetzt. An dieser Stelle existiert kein Unterschied in der Handhabung zu Ablauf 1.

 

Constraints

Um diese Abläufe über “Constraints” und Ausdrücke zu realisieren, wird ein anderes Konzept verwendet. Die “Constraints” in dem Paket werden an verschiedenen Stellen mit Ausdrücken erweitert, zu sehen an dem jeweiligen Funktionszeichen .

 

 

 

Ablauf 1: Innerhalb des “Constraint” wird ein Ausdruck ausgewertet. Ist dieser True, so wird der nächste Task ausgeführt.

Ablauf 2: Ist die entsprechende Variable True, so wird Task3 ausgeführt, ist die Variable False, so wird Task4 ausgeführt. Zusätzlich muss für die verweisenden “Constraints” auf Task4 die Option “Logischer OR-Operator. Eine Einschränkung muss zu ‘True’ ausgewertet werden.” aktiviert sein. Dies wird in diesem Fall durch die gestrichelten Linien der Constraints angezeigt. Somit wird sichergestellt, dass entweder Task3 ausgeführt wurde oder der Ausdruck innerhalb des “Constraints” von Task2 auf Task4 gültig ist.

Ablauf 3: Wieder wird ein Ausdruck innerhalb des “Constraints” ausgewertet. Die Einschränkung von TaskA auf TaskB gibt an, das TaskB bei Erfolg ausgeführt werden muss, wodurch TaskB nicht ausgeführt wird, wenn Task nicht ausgeführt wird.

 

 

Und wo ist der Unterschied?

Grundsätzlich können mit beiden Optionen die jeweiligen Ziele erreicht werden, wenn man den Unterschied der beiden Varianten beachtet.

Ein deaktivierter Task wird übersprungen, ein nicht erfüllter Constraint beendet den entsprechenden “Zweig”.

Möchte man also einen Task überspringen, so kann man diesen deaktivieren oder man muss eine zusätzliche Umleitung um diesen Task erstellen.

     

Auch wenn die Unterschiede nicht wirklich sehr groß zu sein scheinen, ist es aus meiner Sicht nicht empfehlenswert, Workflows über das deaktivieren von Task zu erstellen – auch wenn es hier mit Sicherheit Ausnahmen geben mag.

Grundsätzlich finde ich Abläufe, die über die Constraints erstellt werden wesentlich logischer, da man sehr schnell sieht, wo Besonderheiten sind und dadurch den Ablauf besser versteht. Die Anzahl an Sequenzcontainer die für das de-/aktivieren verwendet werden, macht ein Paket wesentlich komplexer. Hinzu kommt noch, das es ohne den installierten BIDS Helper nicht ersichtlich ist, wann und wo Tasks deaktiviert werden.

 

 

Tasks die beim Start eines Paketes bereits deaktiviert sind, werden im BIDS bei der Ausführung weiterhin deaktiviert angezeigt. Dies kann während des Debuggens erheblich zu Verwirrungen führen.

Die Paketprotokollierung greift nicht vollständig, wenn Tasks beim Start eines Paketes deaktiviert sind.

Als rein subjektive Beobachtung – ich hab hier keine wirklichen Test gemacht - finde ich, das komplexere Pakete mit vielen Sequenzcontainer beim Laden erheblich länger für die Validierung brauchen als äquivalente Pakete, bei denen der Workflow über Constraints erstellt worden sind.

Über Feedback würde ich mich freuen, besonders wenn mir jemand einen Situation nennen kann, in der es Vorteilhafter ist, Tasks zu deaktivieren anstatt den Workflow entsprechend anzupassen.

Sonstiges Disable, Constraint, Control Flow