Zur Veranschaulichung, wie einfach das ganze umzusetzen ist, wird das an einem einfachen Beispiel dargestellt:

Bei folgendem Datenflusstask soll die Lookup-Query dynamisch erstellt werden um den Tabellennamen aus einer Paket-Variablen zur Laufzeit zu ermitteln. Der Wert dieser Variablen kann dann z.B. aus der Paketkonfiguration stammen oder er kann in einem ForEach-Container zugewiesen werden um den gleichen Datenfluss mehrmals mit jeweils einer anderen Quell-Tabelle für den Lookup durchzuführen.

Die Quellabfrage für den hier verwendeten „Lookup Price“ in folgendem Datenflusstask kann wie folgt dynamisiert werden:

Der Datenflusstask, in dem sich der jeweilige Lookup-Task befindet hat eine Eigenschaft „SqlCommand“ die über eine Expression dynamisiert wird. Also Rechtsklick in den Datenflusstask und „Eigenschaften“ auswählen.

Auf die Schaltfläche mit den drei Punkten klicken. Es öffnet sich ein Editor für die Eigenschaften des Datenflusstasks

In dem Eigenschaftenausdrucks-Editor die Eigenschaft [LKP Price].[SqlCommand] auswählen. Hierbei ist „LKP Price“ der Name des jeweiligen Lookups. Es gibt für jeden Lookup in dem Datenflusstask eine solche Eigenschaft. Nach Auswahl der richtigen Eigenschaft den Ausdrucksgenerator öffnen durch Klick auf die Schaltfläche mit den vier Punkten am Ende der Zeile.

Dort die Abfrage eintragen. Die Variabel @[User::sTable] enthält den entsprechenden Tabellennamen. Die Variabel kann dann zur Laufzeit mit dem gewünschten Wert versehen werden. Lediglich die Metadaten (Anzahl der Columns, die Namen der Columns und deren Datentypen) müssen denen der Tabelle entsprechen, mit deren Metadaten das Paket entwickelt wurde. Sonst würde es zu einem Fehlerabbruch kommen.

Es wurde gezeigt, wie die Quellabfrage für einen Lookup im Full-Cache-Modus zur Laufzeit angepasst werden kann. Das ging bei SSIS in Versionen vor 2008 so nicht. Vorteile kann diese Vorgehensweise dann bringen, wenn der gleiche Datenfluss mehrmals ausgeführt wird und dann die für die jeweilige Ausführung benötigte Datenmange mittels einer angepassten where-Klausel eingeschränkt werden kann. Eine dynamische Auswahl der verwendeten Tabelle ist wie gezeigt auch sehr leicht möglich und mag in dem einen oder anderen Szenario hilfreich sein.

Eine Suche sollte nicht getroffene Zeilen einfach ausleiten, um diese zu verwerfen. Im BIDS war dies auch überhaupt kein Problem. Als Ziel für die umgeleiteten (ungültigen) Zeilen diente ein Multicast. Das Ausführen auf dem SQL Server führte immer wieder zum Fehler, unabhängig von Sprache und Adressbreite von DTEXEC auf dem Server. Die Fehlermeldung deutete auf einen Fehler beim Input in die Suche hin, was mich erst mal dazu bewog Datentypen in alle möglichen Richtungen zu casten und zu konvertieren, um hier einen Fehler auszuschließen.

Die Fehlermeldung lautete: Beschreibung: SSIS-Fehlercode ‘DTS_E_PROCESSINPUTFAILED’. Fehler bei der ProcessInput-Methode in der Komponente ‘Suche’ (25) mit dem Fehlercode 0×80070057 beim Verarbeiten der Eingabe ‘Eingabe der Suche’ (26). Die identifizierte Komponente hat einen Fehler von der ProcessInput-Methode zurückgegeben. Der Fehler ist komponentenspezifisch.

Nach vielen Tests und ein wenig Recherche im Netz fand ich einen Blogeintrag, der einen ähnlichen Fehler beschreibt (http://social.msdn.microsoft.com/Forums/en-US/sqlintegrationservices/thread/9de27db3-6bde-4b71-950c-c3031399b45c).

Allerdings bezog sich dieser auf die Ausführung als Child bzw. Parent Paket. Nach einem Test wurde jedoch klar: es scheint vergleichbar zu sein.

Meine Lösung sah dann folgendermaßen aus:

· Den Lookup habe ich so eingestellt, dass ein Nicht-Treffer-Fehler ignoriert wird.

· Dies führt dazu, dass in die Column ein NULL geschrieben wird.

· Mit einem darauffolgenden Bedingten Teilen (Conditional Split) habe ich die Zeilen mit dem NULL in der Column dann rausgeworfen.

Und siehe da, sowohl im BIDS, als auch auf dem Server läuft das Paket nun ohne Fehler durch. Der Fehler scheint gelegentlich auf 2005 und 2008, 2008 R2 vorzukommen. Ich hatte leider noch keine Gelegenheit auf 2012 zu testen.

Timo Kroll

Senior Consultant

- Beim Anlegen einer neuen MDS-Datenbank kann man den Konfigurationsdialog zwar bis zum Ende durchklicken, allerdings scheitert der Installationsvorgang an einer ellenlangen, wenig aussagekräftigen .NET-Fehlermeldung, deren genaue Ausprägung ich aus Gründen der Übersichtlichkeit am Ende dieses Beitrages nachreichen werde

- Beim Einbinden einer vorhandenen MDS-Datenbank bleibt man beim Auswahl-Dialog der Datenbank auf halber Strecke stecken, da die Auswahlbox deaktiviert bleibt (siehe Screenshot)

Nach etwas Recherche habe ich den Grund gefunden: Offensichtlich darf es in der SQL Server Instanz keine Datenbanken geben, die sich im Offline-Modus befinden. Ist das der Fall, scheitern sämtliche Installationsversuche der Master Data Services.

Abschließend noch mein (nicht ganz überraschender) Lösungsvorschlag: entweder man schaltet betroffende Datenbank vorübergehend in den Online-Modus oder, wenn dies nicht möglich ist, man hängt sie vorübergehend ganz aus der Instanz aus.

Ob sich das Problem auch im SQL Server 2012 ergibt, konnte ich bisher nicht Erfahrung bringen.

Und hier wie versprochen noch die Fehlermeldung:

Microsoft.MasterDataServices.Configuration.ConfigurationException: Data is Null. This method or property cannot be called on Null values. —> System.Data.SqlTypes.SqlNullValueException: Data is Null. This method or property cannot be called on Null values.

at System.Data.SqlClient.SqlBuffer.get_String()

at Microsoft.MasterDataServices.Configuration.DatabaseUtilities.GetDatabases(DatabaseServerInformation server)

at Microsoft.MasterDataServices.Configuration.Commands.NewMasterDataServicesDatabase.InternalProcessRecord()

at Microsoft.MasterDataServices.Configuration.Commands.ConfigurationCmdlet.ProcessRecord()

at System.Management.Automation.CommandProcessor.ProcessRecord()

— End of inner exception stack trace —

at Microsoft.MasterDataServices.Configuration.InstanceManager.Execute(Command command)

at Microsoft.MasterDataServices.Configuration.InstanceManager.CreateMasterDataServicesDatabase(DatabaseServerInformation serverInformation, DatabaseInformation databaseInformation)

at Microsoft.MasterDataServices.Configuration.UI.MdsDatabase.CreateNewDatabase()

Microsoft hat diesen Trend frühzeitig erkannt und betreibt seit November 2008 seine Cloud-Computing-Plattform Windows Azure. Im Rahmen eines akademischen Projektes der Hochschule für Technik und Wirtschaft aus Berlin wurden in Zusammenarbeit mit ixto vom Oktober 2011 bis Januar 2012 die aktuellen Möglichkeiten einer Cloud-driven BI-Lösung auf Basis von Microsoft-Technologien evaluiert.

Welche Microsoft-Technologien wurden betrachtet?

Die Windows Azure Cloud-Service Plattform umfasst drei Dienste:

• Windows Azure stellt Rechenkapazität und Speicherplatz zur Verfügung
• Microsoft SQL Azure stellt eine relationale Datenbank zur Verfügung
• Windows Azure AppFabric stellt Infrasturkturdienste für verteilte Anwendungen zur Verfügung

In diesem Blog Beitrag wird nur auf SQL Azure eingegangen. SQL Azure ist ein Cloud-basierter hochverfügbarer und skalierbarer relationaler Datenbankservice auf Basis der SQL Server-Technologien, der über das Internet erreichbar ist. Der Service SQL Azure Data Sync ermöglicht eine bidirektionale Synchronisation von Daten zwischen SQL Azure und SQL Azure sowie zwischen SQL Azure und SQL Server. Die Bereitstellung von Berichten und Auswertung von Daten ermöglicht der Service SQL Azure Reporting. Für die Betrachtung wurde auch Office 365 mit SharePoint Online sowie Microsoft Excel PowerPivot und Microsoft SharePoint Server mit SQL Server PowerPivot für SharePoint verwendet.

Was wurde gemacht?

Mit Hilfe von SQL Azure wurde eine Berichtslösung realisiert. Der lokale Datenbestand wird nach einer definierten Regel mit dem Datenbestand innerhalb der Cloud abgeglichen und gegebenenfalls aktualisiert. Dieser aktuelle Datenbestand ist die Grundlage für die ebenfalls in der Cloud realisierten Berichte, die somit weltweit verfügbar sind.

Kommen wir nun zu den Ergebnissen unserer Arbeit:

Was waren die Ergebnisse?

Es wird ein Cloud-basiertes Reporting auf einer einheitlichen Datenbasis ermöglicht. Berichte können über verschiedene Standorte hinweg unabhängig von einer unternehmenseigenen Infrastruktur per Webbrowser abgerufen oder in andere Anwendungen eingebettet werden. Es wird ein Cloud-basiertes Reporting auf einer einheitlichen Datenbasis ermöglicht. Berichte können über verschiedene Standorte hinweg unabhängig von einer unternehmenseigenen Infrastruktur per Webbrowser abgerufen oder in andere Anwendungen eingebettet werden.

Die PowerPivot-Unterstützung im SharePoint Server ermöglicht hingegen die Bereitstellung von voll funktionstüchtigen PowerPivot-Reports über die SharePoint-Plattform. SQL Azure Reporting stellt mit dem Reporting Portal eine Cloud-driven Berichterstellung zur Verfügung. Wir konnten Datenbestände synchronisieren, eine Unterstützung von SISS-Paketen und anderer ETL-Funktionalitäten wird es erst in naher Zukunft geben. Zudem fehlt noch eine PowerPivot-Unterstützung in SharePoint Online von Office 365, um Slicer oder Datenschnitten online verstellen zu können. Eine komplette Business Intelligence-Lösung, die alle Komponenten in der Cloud vereint,  ist sind zurzeit noch eingeschränkt umsetzbar.

Wie sicher sind die Daten?

Die SQL Azure-Firewall verhindert sämtliche Zugriffe auf den SQL Azure-Server, bis zugriffsberichtige Computer auf Grundlage ihrer Ursprungs-IP-Adresse definiert werden. Zusätzlich können zu SQL Azure Datenbanken nur mit SSL verschlüsselte Verbindungen aufgebaut werden.

Was sind die Vorteile?

Mit Windows Azure erreichen sie eine weltweite Erreichbarkeit ihrer Berichte bei einer garantierten Verfügbarkeit von 99,9% und unter hohen Sicherheitsvorkehrungen. Unabhängig von der lokalen Infrastruktur können Datenbestände in der Cloud synchronisiert werden. Besonders von Vorteil ist die dynamische Skalierbarkeit der Azure Kapazitäten (Bandbreite und Speicherplatz).

Natürlich dürfen  die Sicherheits- und Datenschutzaspekte nicht außeracht gelassen werden, sondern müssen individuell geklärt werden.

Ein kurzer Ausblick

Mit dem SQL Azure Data Explorer wird Cloud-driven ETL-Funktionalität mit Veröffentlichung vom SQL Server 2012 möglich werden. Seit Dezember 2011 kann ein Testzugang vom Data Explorer unter https://dataexplorer-signup.sqlazurelabs.com/beantragt werden.

Der Data Explorer funktioniert als Client-Anwendung sowie als Cloud-Service und ermöglicht dem Benutzer bei Verwendung einer eigenen Skript-Sprache Daten aus verschiedenen Datenquellen zu laden, konvertieren und anzureichern. Allerdings ist er ohne Workflow-Engine ausgestattet, d.h. ermöglicht keine Automatisierung.

Zusammenfassung

Wenn Sie interessiert sind an einer Cloud-driven Business Intelligence Lösung oder an den auf Microsoft-basierten Cloud-Services, dann setzen sie sich mit uns in Verbindung.

Bilder:

Abbildung des fertig konfigurierten DataSync

Abbildung eines Dashboards zur Demonstration des SQL Azure Reporting bei Verwendung der Contoso Retail Testdaten und der SQL Azure Database mit DataSync

Um LINQ to SharePoint benutzen zu können muss man sich als erstes die Entity Classes generieren lassen. Zum Generieren der Klassen wird die SPMetal.exe benutzt, zu finden unter: „C:\Program Files\Common Files\Microsoft Shared\ Web Server Extensions\14\BIN“.

Öffnen Sie die cmd.exe und navigieren Sie zu dem oben angegeben Pfad in dem sich die SPMetal.exe befindet. Anschließend geben Sie den Befehl zum generieren der *.cs Datei ein.

/web:Site
/code:OutputFile
/Language:OutputLanguage

Nach der Eingabe des Befehls wird die Datei “LINQToSharePoint.cs” im „BIN“ Order generiert.
 

Jetzt können wir die Datei zu unserem SharePoint-Projekt hinzufügen und benutzen.

Das Testprojekt besteht aus einem einfachen VisualWebpart, einer DAL Klasse und aus der generierten LINQToSharePoint.cs.

Die DAL Klasse dient zur Kommunikation zwischen SharePoint und dem Webpart.
Wenn wir die LINQToSharePoint.cs öffnen sehen wir ganz oben die generierte DataContext Klasse.

public partial class LINQToSharePointDataContext : Microsoft.SharePoint.Linq.DataContext

{

    #region Extensibility Method Definitions

    partial void OnCreated();

    #endregion

    public LINQToSharePointDataContext(string requestUrl) :

        base(requestUrl)

    {

        this.OnCreated();

    }

    [Microsoft.SharePoint.Linq.ListAttribute(Name = "Fruits")]

    public Microsoft.SharePoint.Linq.EntityList<FruitsItem> Fruits

    {

        get

        {

            return this.GetList<FruitsItem>(“Fruits”);

        }

    }

}

Weiter unten finden wir die Klasse „FruitsItem“ welche eine Zeile in der Fruits Liste darstellt. Diese beinhaltet alle notwendigen Properties um auf die Listeneinträge zuzugreifen.

[Microsoft.SharePoint.Linq.ContentTypeAttribute(Name = "Item", Id = "0x01", List = "Fruits")]

public partial class FruitsItem : Item

{

    private System.Nullable<double> _price;

    private System.Nullable<Color> _color;

    #region Extensibility Method Definitions

    partial void OnLoaded();

    partial void OnValidate();

    partial void OnCreated();

    #endregion

    public FruitsItem()

    {

        this.OnCreated();

    }

    [Microsoft.SharePoint.Linq.ColumnAttribute(Name = "Price", Storage = "_price", FieldType = "Currency")]

    public System.Nullable<double> Price

    {

        get

        {

            return this._price;

        }

        set

        {

            if ((value != this._price))

            {

                this.OnPropertyChanging(“Price”, this._price);

                this._price = value;

                this.OnPropertyChanged(“Price”);

            }

        }

    }

    [Microsoft.SharePoint.Linq.ColumnAttribute(Name = "Color", Storage = "_color", FieldType = "Choice")]

    public System.Nullable<Color> Color

    {

        get

        {

            return this._color;

        }

        set

        {

            if ((value != this._color))

            {

                this.OnPropertyChanging(“Color”, this._color);

                this._color = value;

                this.OnPropertyChanged(“Color”);

            }

        }

    }

}

Die LINQToSharePointDataContext Klasse benötigen wir zum Auslesen der Listen. Ich habe zum Auslesen eine Methode in der DAL.cs mit dem Namen „GetFruits“ angelegt, in der die LINQToSharePointDataContext Klasse instanziiert wird.

        public EntityList<FruitsItem> GetFruits(string server)

        {

            LINQToSharePointDataContext data = new LINQToSharePointDataContext(server);

            EntityList<FruitsItem> fruitList = data.GetList<FruitsItem>(“Fruits”);

            return fruitList;

        }

Der Rückgabetyp der Methode ist teil der Microsoft.SharePoint.Linq Assembly. Als Listen Element geben wir ein FruitsItem an.

Wenn wir die LINQToSharePointDataContext Klasse instanziiert haben können wir diese benutzen und die „GetList“ Methode aufrufen. In den spitzen Klammern geben wir an von welchem Typ die Listenelemente sein sollen. In der runden Klammer geben wir die Liste an die ausgelesen werden soll.

Nach der Ausführung der „data.GetList“ Methode haben wir eine EntityList die mit den Items der Fruits Liste gefüllt ist.

_data ist unsere Instanziierte DAL Klasse. Mit dieser rufen wir die GetFruits Methode auf und bekommen die EntityList mit den Items aus der Fruit Liste zurück.

//GetFruits

EntityList<FruitsItem> fruitList = _data.GetFruits(_server);

ddlFruits.DataSource = fruitList;

ddlFruits.DataTextField = “Title”;

ddlFruits.DataBind();

Die EntityList können wir direkt an die DataSource einer DropDownList binden. Das Ergebnis sieht dann wie folgt aus:

Sie sehen also, dass LINQToSharePoint einem sehr viel Arbeit abnehmen kann und man, nachdem man die DataContext Klasse instanziiert hat, eine Liste in nur einer Zeile auslesen kann.

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.