SQL Server 2005: XML und SOAP Webservices · gespeichert und für relationale Abfragen zur...
24
Fallbeispiele 275 7 Fallbeispiele
Transcript of SQL Server 2005: XML und SOAP Webservices · gespeichert und für relationale Abfragen zur...
Fallbeispiele
275
7 Fallbeispiele
Fallbeispiele
276
7 Fallbeispiele Um einen Überblick über die Notwendigkeit der Erzeugung von XML-Daten aus relati-onalen Daten und ihre Umwandlung in wiederum relationale Daten zu gewinnen, folgt ein kurzes Beispiel, das die allgemeine Architektur einer Import-/ Export-Schnittstelle und eine (De)Serialisierungsschnittstelle auf Basis von T-SQL beschreibt. Solche Im-port-/Export-Schnittstellen können notwendig sein, weil andere Systeme bestimmte Datenausschnitte der exportierenden Datenbank benötigen, oder weil die eigene Daten-bank als Ziel für solche Daten vorhanden ist. Dies können genauso Buchungs- und Reservierungssysteme wie Untersuchungs- und Analysesysteme, die auf Basis mehrerer Datenbanken, die möglicherweise sogar verschiedene Hersteller zum Hintergrund ha-ben, erstellt werden, sein. Techniken der Serialisierung und Deserialisierung können dann interessant sein, wenn per XML die Serialisierung durchgeführt werden soll und die Daten nicht in Form einer reinen XML-Datei gespeichert werden soll, sondern statt-dessen die Daten relational zerlegt und in einer Datenbank gespeichert werden sollen. Dies ist auch dann eine interessante Lösung, wenn bspw. eigene, auf XML-basierte Dateiformate benötigt werden. In diesem Fall würde die Serialisierung sowohl für die Speicherung im Dateisystem mit einer spektakulären Endung (und natürlich nicht .xml) als auch für die Speicherung in der Datenbank zum Einsatz kommen.
7.1 De-/Serialisierung von Objekten Serialisierung bedeutet, dass der Zustand eines Objekts in eine Zeichenkette zerlegt wird. Dies ist im Normalfall eine in jeder objektorientierten Sprache bereits vorhandene Möglichkeit. Es entstehen dabei automatisch generierte Zeichenketten, die durchaus kein XML-Format besitzen (müssen). Im Normalfall kann man allerdings durchaus diese Zeichenkette lesen und verstehen, da in irgendeiner Art und Weise eine Schlüssel-Werte-Liste abgebildet wird und die Namen der Felder/Eigenschaften mit ihren zugehö-rigen Werten in dieser langen Zeichenkette erscheinen. Um Collections, die wiederum Objekte enthalten können, oder Arrays ranken sich dann bspw. noch zusätzliche Zei-chen wie eckige oder geschweifte Klammern, um die gesamten Daten sowie die einzel-nen Einträge zu unterscheiden. Es besteht darüber hinaus auch die Möglichkeit, den Objektzustand in einer Datenbank zu speichern.
Fallbeispiele
277
7.1.1 XML-Serialisierung als relationale Zerlegung
Neben der automatischen Serialisierung in eine beliebige, jedoch von der Programmier-sprache vorgegebene Zeichenkette gibt es auch die Möglichkeit, eine eigene Serialisie-rung vorzunehmen. Dies ist je nach Programmiersprache einfacher oder schwieriger. Mit .NET ist es besonders einfach; sofern man dann auch noch die XML-Standardserialisierung verwendet, ist es genauso einfach wie eine Zerlegung in einer einfachen Programmiersprache wie PHP. Es besteht allerdings immer auch die Mög-lichkeit, eine eigene Serialisierung zu schreiben, was vom Schwierigkeitsgrad wiederum ein wenig von der Programmiersprache abhängt. Für die Überlegung dieses Abschnitts genügt es, dass eine solche Möglichkeit besteht und dass darüber hinaus die Daten in eine relationale Datenbank und/oder eine Textdatei gespeichert werden sollen.
Durch die Serialisierung ist es möglich, den Objektzustand dauerhaft zu speichern. Dies erlaubt es, ein Objekt in eben diesem Zustand zu einem späteren Zeitpunkt wieder zu aktivieren. In Software, die keine Datenbank benötigt, könnte dies bspw. ein Spielzu-stand (Armeeaufbau, Kampfsituation, erreichte Punktestand, Fähigkeiten) sein. Kommt eine Datenbank ins Spiel, dann handelt es sich möglicherweise um die Situation, dass die Daten für die Verwendung durch andere Benutzer (Projektverwaltung) dauerhaft gespeichert und für relationale Abfragen zur Verfügung stehen wollen. Eine solche Serialisierung in XML ermöglicht es darüber hinaus auch noch, sehr einfach ein eige-nes Dateiformat zu erstellen. Die in XML-serialisierten Objektzustände stellen dann das Dateiformat dar, welches im Dateisystem gespeichert und nachher wieder durch die Software eingelesen werden kann.
Die erste Abbildung stellt die Architektur einer solchen Serialisierungsschnittstelle zunächst grob, die zweite Abbildung dagegen etwas genauer dar. In der ersten Abbil-dung sieht man unten zunächst die Datenbank, in der Mitte die Schnittstelle, welche in XML-Format die Daten erwartet, zerlegt und in der Datenbank speichert und dann spä-ter in XML zusammensetzt und zurückliefert. In vielfältiger Weise ist dies überhaupt das Grundprinzip einer über XML realisierten Import-/ Exportschnittstelle, wobei aller-dings in diesem besonderen Fall die Datenübertragung für den besonderen Prozess von Serialisierung und Deserialisierung zum Einsatz kommt. Die Abbildung zeigt dann im oberen Bereich auf der linken Seite die Software, in der die übermittelten Daten wieder in Objekte umgewandelt werden oder welche die Objekte serialisiert und speichert. Auf der rechten Seite der Abbildung ist eine XML-Datei angegeben, die mit einer eigenen Endung das Dateiformat der Anwendung zeigt. In dieser Datei befindet sich nichts an-deres als die XML-Darstellung, welche von der Schnittstelle erzeugt bzw. erwartet wird.
Fallbeispiele
278
Die Schnittstelle selbst sammelt aus verschiedenen Tabellen, in denen die Daten relatio-nal zerlegt sind, die benötigten Datensätze und stellt sie in einem selbst definierten XML-Format zusammen. Hier kann man sich zusätzlich vorstellen, wie Parameter zu Filterzwecken genutzt werden, um bestimmte Objektzustände nach Parametern auszu-wählen. Dies ist dann auch das Format, welches von der Schnittstelle für den Import, d.h. für den Speichervorgang erwartet wird. In diesem Fall sendet die Software eine XML-Darstellung an die Schnittstelle, deren Aufgabe darin besteht, diese Darstellung relational zu zerlegen.
Bereich 2Bereich 1
XML-Schnitt-stelle
Datenbank
Tab 1 Tab 2 Tab 2
XML-Schnitt-stelle
Tab 1 Tab 2 Tab 3
... ...
Software.xml
Abbildung 4.1: Prinzip der Serialisierung
Die zweite Abbildung greift die erste noch einmal auf, variiert sie allerdings ein wenig, indem sie etwas mehr Details zeigt. Dieses Mal ist wiederum auf der linken unteren Seite die Datenbank angezeigt, welche sowohl die Tabellen als auch die Schnittstelle enthält. Darüber ist die Software angegeben, die nun offensichtlich aus mehreren Objek-ten besteht. Diese Objekte können einzeln oder zusammengesetzt in der Datenbank bzw. natürlich auch im Dateisystem gespeichert werden. In diesem Fall muss es einen
Fallbeispiele
279
Serialisierer geben, der in der Lage ist, die verschiedenen Eigenschaftswerte der Objek-te in eine XML-Darstellung zu zerlegen und der Schnittstelle zu übergeben. Unten sieht man wiederum die verschiedenen Tabellen, welche die relationale Darstellung der ü-bermittelten Objektdaten repräsentieren. Sofern es mehrere Schnittstellen gibt, welche der Reihe nach mit Teil-XML-Darstellungen aufgerufen werden, würde dieser Tabel-lenverbund dann auch einen sachlogischen Sinnzusammenhang abbilden.
ProzedurFunktion
Sicht
Datenbank
Tabelle 1 Tabelle2 Tabelle 3
ProzedurFunktion
Sicht
Tabelle 1 Tabelle 2 Tabelle 3
... ...
ObjektObjekt Objekt ObjektObjekt Objekt
Software
Abbildung 4.2: Technik der Serialisierung
Als mögliche Lösungen für die konkrete Implementierung einer solchen Schnittstelle stehen für den Export Prozeduren, Funktionen und Sichten, für den Import dagegen hauptsächlich Funktionen und Prozeduren zur Verfügung. Während eine Funktion rechtsseitig einer Zuweisung aufgerufen werden kann und ihre XML-Daten daher in Form des Rückgabewerts zurückliefert, wird normalerweise eine Prozedur verwendet, welche über einen Ausgabeparameter die benötigten Daten der Anwendung zur Verfü-
Fallbeispiele
280
gung stellt. Eine Prozedur ist auch geeignet, XML-Daten entgegenzunehmen und sie dann passend zu zerlegen. Eine Funktion bietet zwar auch eine analoge Möglichkeit an, Parameter zu empfangen, sie muss allerdings auch einen Rückgabewert liefern, der möglicherweise gar nicht benötigt wird. Eine Sicht eignet sich insbesondere für die Zusammenstellung der Daten im Bereich des Exports.
7.1.2 Beispiele
Die Möglichkeiten von Serialisierung und Deserialisierung sollen aufgrund einer abge-wandelten und vereinfachten Product2-Tabelle veranschaulicht werden. Dabei ver-wendet man auf der einen Seite eine Prozedur, die ein XML-Resultset zurückliefert, und auf der anderen Seite eine SELECT…FOR XML-Abfrage, welche die XML-Daten direkt aus der Datenbank abruft. Neben diesen beiden Lösungsansätzen für die Deserialisie-rung zeigt das Beispiel noch, wie das Zurückschreiben von Datensätzen durch Seriali-sierung funktioniert, sodass aus einem Objekt in der Software zunächst XML wird, welches eine Prozedur umwandelt, um das Objekt schließlich wieder in einer relationa-ler Tabelle zu speichern. Bei der Vorstellung der Deserialisierung zeigt das Beispiel auch noch, wie man die Standarddeserialisierung und das DOM einsetzen kann, um die XML-Daten aus der Datenbank abzurufen bzw. im Klienten weiterzuverarbeiten. Eine letzte Möglichkeit besteht nun noch darin, einen Webdienst zu verwenden. Dieser liefert dann als Antwort eine XML-Struktur in Form einer SOAP-Nachricht mit dem seriali-sierten Objekt, während die Anfrage des Klienten den Serialisierungsvorgang abbildet. Dies entspricht allerdings im Wesentlichen den Techniken, die schon vorgestellt wur-den, als die Verwendung von komplexen Nachrichten eingeführt wurde, sodass dies nicht noch einmal aufgegriffen wird.
7.1.2.1 Vorbereitung im MS SQL Server
Auf dem Server sind einige Vorbereitungen zu treffen, um ein funktionstüchtiges Bei-spiel erstellen zu können. Zunächst benötigt man eine Datenstruktur, die im einfachsten Fall aus einer einzigen Tabelle besteht. Es ist auch möglich, eine verschachtelte Struktur aus einer Eltern-Kind-Tabellenverknüpfung zu erstellen, die dann sowohl in der Soft-ware als auch nachher beim Speichervorgang wieder zerlegt wird. Es ließe sich darüber hinaus auch noch eine XML-Spalte vorstellen, die komplexe Inhalte enthält, welche man weder in der Daten- noch in der Anwendungsschicht zerlegen möchte. Im aktuellen Beispiel handelt es sich um eine sehr vereinfachte Darstellung der Product-Tabelle mit nur fünf Spalten. Diese haben drei verschiedene Datentypen, sodass man sich auf der Klientenseite dem Problem der Typumwandlung gegenüber sieht.
Fallbeispiele
281
CREATE TABLE Production.Product2 (
ProductID int IDENTITY(1,1) NOT NULL PRIMARY KEY,
Name varchar(30) NOT NULL,
ProductNumber nvarchar(25) NOT NULL,
ListPrice money NOT NULL,
StandardCost money NOT NULL)
712_01.sql: Tabelle für Beispieldaten
Die Daten stammen direkt aus der gewöhnlichen Product-Tabelle, die man mit Hilfe einer INSERT…SELECT-Anweisung überträgt.
INSERT INTO Production.Product2
(Name, ProductNumber, ListPrice, StandardCost)
SELECT TOP 5 Name, ProductNumber, ListPrice, StandardCost
FROM Production.Product
WHERE ListPrice > 0
712_01.sql: Übernahme von Daten
Wie oben schon erwähnt, kann man sich verschiedene Objekte denken, die aus einer relationalen Struktur XML-Daten nach außen liefern. Im Rahmen der Diskussion einer Import-/Exportschnittstelle, die das Thema des folgenden Abschnitts bildet, kann es hier Funktionen, Prozeduren und auch XML-Sichten geben. Die verschiedenen Objekte erfordern zwar unterschiedlichen Quelltext, doch das Grundprinzip ist natürlich dassel-be, sodass es an dieser Stelle genügen soll, nur eine Prozedur zu verwenden. Diese lie-fert auch die XML-Daten nicht als Parameter zurück, sondern kapselt nur eine Abfrage, welche XML-Daten zurückliefert.
CREATE PROCEDURE Production.GetProduct(
@vProductNumber nvarchar(25))
AS BEGIN
SELECT * FROM Production.Product2 AS Product
WHERE ProductNumber = @vProductNumber
FOR XML AUTO, ELEMENTS
END
712_01.sql: Prozedur mit XML-Rückgabe
Fallbeispiele
282
Um wiederum XML-Daten entgegen zu nehmen, lassen sich Prozeduren oder Funktio-nen betrachten. Sichten dürften wohl in diesem Bereich eher selten anzutreffen sein, da die XML-Daten ja nicht direkt gespeichert werden sollen, sondern erst noch zerlegt werden müssen. Ob hier dann eine Sicht in Kombination mit einem Trigger, der die Datenzerlegung durchführt, geeignet ist, ist schlecht vorstellbar, weil eine Reihe von Funktionen und Prozeduren vielmehr die Möglichkeit bieten, eine Anwendungsschnitt-stelle anzubieten. Die Prozedur, die im nachfolgenden Quelltext präsentiert wird, erwar-tet für die Aktualisierung von Produktdaten also nun einen nvarchar(max)-Parameter, der mit Hilfe von openxml() relational zerlegt und dann für die Aktualisierung ver-wendet wird. Eine Einfüge-Operation wäre mit diesen relationalen Daten ebenfalls über Variable oder direkt über eine INSERT…SELECT-Anweisung denkbar.
CREATE PROCEDURE Production.UpdateProduct(
@vProductXML nvarchar(max))
AS BEGIN
-- Variablen
DECLARE @vProductID int,
@vName nvarchar(30),
@vProductNumber nvarchar(25),
@vListPrice money,
@vStandardCost money,
@idoc int
-- Standardzerlegung und gleichzeitige Eintragung
EXEC sp_xml_preparedocument @idoc OUTPUT, @vProductXML
SELECT @vProductID = ProductID,
@vName = Name,
@vProductNumber = ProductNumber,
@vListPrice = ListPrice,
@vStandardCost = StandardCost
FROM OPENXML(@idoc, '/Product',2)
WITH (ProductID int,
Name varchar(50),
ProductNumber varchar(25),
ListPrice money,
Fallbeispiele
283
StandardCost money)
-- Aktualisierung
UPDATE Production.Product2
SET Name = @vName,
ProductNumber = @vProductNumber,
ListPrice = @vListPrice,
StandardCost = @vStandardCost
WHERE ProductID = @vProductID
END
712_01.sql: Prozedur mit XML-Übernahme
7.1.2.2 Verwendung im .NET-Klienten
In der Klientenanwendung benötigt man für die Datenstrukturen, die in der Datenbank gespeichert werden und in der Anwendung entweder als Transfer- oder sogar als Ge-schäftsobjekte in Frage kommen, eine objektorientierte Repräsentation. Wie bei ver-schiedenen Entwurfsmustern für die Datenzugriffsschicht oder das Domänenmodell kann man hier entweder nur die Felder/Spalten bereitstellen oder auch unmittelbar die Datenzugriffsmethoden und/oder sogar die Geschäftsmethoden programmieren. Da für dieses Beispiel keine Geschäftsmethoden notwendig sind und der Datenzugriff über die Serialisierungs-schnittstelle erfolgt, ist die Klasse Product besonders kurz. Im nach-folgend abgedruckten Quelltext sind darüber hinaus auch noch die öffentlichen Eigen-schaften gelöscht. Neben diesen kann man sich also nun noch je nach eingesetzter Schichtung und Programmiertechniken diverse Methoden sowie wenigstens einen Kon-struktor denken, welcher für die Eigenschaften Werte entgegen nimmt, wenn das Objekt in der Anwendung gefüllt und nicht aus der Datenbank abgerufen wird.
namespace Serialisierung
{
public class Product /* um get/set gekürzt*/
{
private int mProductID;
private string mProductNumber;
public string ProductNumber
private string mName;
Fallbeispiele
284
private double mListPrice;
private double mStandardCost;
}
}
Serialisierung/Product.cs: Gekürzte objektorientierte Tabellenabbildung
In einer Klasse namens ProductSerializer befinden sich nun drei Methoden, von denen zwei den Datenabruf und die dritte die Datenspeicherung/-aktualisierung durch-führen. Dabei zeigt die Methode GetProductStandard(), wie die Standarddeseriali-sierung genutzt wird, um aus einer XML-Struktur wieder ein Objekt zu erstellen. Dabei ist die Entsprechung zwischen XML-Struktur und objektorientierter Übersetzung genau passend, d.h. die Klasse trägt den Namen des XML-Eltern-Elements und die einzelnen Eigenschaften entsprechen den Kind-Elementen dieses Eltern-Elements.
Zunächst erstellt man eine Datenbankverbindung, deren Verbindungszeichenkette in einer Eigenschaft der Klasse gespeichert wird. Um das XML aus der DB abzurufen, erstellt man ein XmlDocument-Objekt. Da die Prozedur GetProduct die XML-Daten direkt als relationale Ergebnismenge zurückliefert, kann man mit Hilfe eines XmlRea-der-Objekts die Daten aus der Prozedur abrufen. Dazu setzt man die ExecuteXmlRea-der()-Methode von SqlCommand ein.
Nachdem man die XML-Nachricht aus der Datenbank eingelesen hat, kann man die eigentliche Deserialisierung mit Hilfe eines XmlSerializer-Objekts durchführen. Sie besitzt eine Deserialize()-Methode, die eine so direkte Entsprechung unmittelbar auflöst.
public Product GetProductStandard(string ProductNumber) {
XmlDocument document = new XmlDocument();
using (SqlConnection connection = new SqlConnection(ConnectionString)) {
SqlCommand cmd = new SqlCommand("Production.GetProduct", connection);
cmd.Parameters.Add("@vProductNumber", SqlDbType.NVarChar);
cmd.Parameters["@vProductNumber"].Value = ProductNumber;
cmd.CommandType = CommandType.StoredProcedure;
connection.Open();
Fallbeispiele
285
XmlReader reader = cmd.ExecuteXmlReader();
document.Load(reader);
connection.Close();
}
XmlSerializer serializer = new XmlSerializer(typeof(Product));
XmlParserContext context = new XmlParserContext(null, null, null, XmlSpace.None);
XmlTextReader read = new XmlTextReader(document.OuterXml, XmlNodeType.Element, context);
Product product = (Product)serializer.Deserialize(read);
return product;
}
Serialisierung/ProductSerializer.cs: Standardserialisierung
Alternativ zu einem DB-Objekt, das XML-Daten zurückliefert, steht es dem Entwickler natürlich auch frei, mit Hilfe einer FOR XML-Abfrage direkt XML aus der Datenbank abzurufen. Dies verbirgt zwar nicht die Komplexität der Datenstrukturen, ermöglicht aber dennoch die Vorteile des XML-Abrufs zu nutzen. Diese liegen insbesondere in der – wie gerade gesehen – schnellen Erzeugung eines Objekts auch bei vielen Eigenschaf-ten. Die nachfolgende Methode zeigt allerdings neben der direkten Abfrage noch eine andere Alternative, nämlich die Erzeugung eines Objekts aus dem DOM-Dokument bzw. aus dem XmlDocument-Objekt mit individuellem Abruf der XML-Elemente.
Man verwendet wie zuvor einen XmlReader, um die XML-Daten aus der Abfrage zu lesen, und die Load()-Methode von XmlDocument, um die Daten zu übernehmen. Die SelectSingleNode()-Methode ist dann die einfachste Lösung, um die einzelnen Knoten in der XML-Struktur auszulesen und die Textknoteninhalte in die Objekteigen-schaften zu übernehmen. Bei dieser Variante ist es auf der einen Seite zwar möglich, individuelle Werte zu übernehmen, doch muss man auf der anderen Seite auch für die Datentypzuordnung selbst sorgen. Dies zeigen die verschiedenen TryParse()-Verwendungen, um die double- und int-Werte aus den XML-Daten umzuwandeln.
public Product GetProductDOM(string ProductNumber) {
XmlDocument document = new XmlDocument();
Fallbeispiele
286
String CommandString = @"SELECT * FROM Production.Product2 AS Product
WHERE ProductNumber = @vProductNumber
FOR XML AUTO, ELEMENTS";
using (SqlConnection connection = new SqlConnection(ConnectionString)) {
SqlCommand cmd = new SqlCommand(CommandString, connection);
cmd.Parameters.Add("@vProductNumber", SqlDbType.NVarChar);
cmd.Parameters["@vProductNumber"].Value = ProductNumber;
connection.Open();
XmlReader reader = cmd.ExecuteXmlReader();
document.Load(reader);
connection.Close();
}
Product product = new Product();
XmlNode root = document.SelectSingleNode("Product");
product.ProductNumber = root.SelectSingleNode( "ProductNumber").InnerText;
product.Name = root.SelectSingleNode("Name").InnerText;
bool result;
double wert;
result = double.TryParse(root.SelectSingleNode( "ListPrice").InnerText.Replace(".", ",") , out wert);
if (result) {
product.ListPrice = wert;
}
result = double.TryParse(root.SelectSingleNode( "StandardCost").InnerText.Replace(".", ",") , out wert);
if (result) {
product.StandardCost = wert;
}
Fallbeispiele
287
int ID;
result = int.TryParse(root.SelectSingleNode( "ProductID").InnerText, out ID);
if (result) {
product.ProductID = ID;
}
return product;
}
Serialisierung/ProductSerializer.cs: Eigene DOM-Serialisierung
Schließlich müssen die Daten auch wieder aus der Anwendung in die Datenbank zu-rückgeschrieben werden. Dazu kann man eine entsprechende Prozedur einsetzen, wel-che die XML-Daten erwartet, zerlegt und neu speichert oder aktualisiert. Dazu ist es lediglich wichtig, die Objekteigenschaften in eine XML-Zeichenkette umzuwandeln, wozu man ein Objekt der Klasse StringWriter verwendet, die bei der Instanziierung ein Objekt vom Typ StringBuilder erwartet. Die Methode Serialize() der Klasse XmlSerializer ist dann in der Lage, eine Zeichenkette in XML-Form zu erzeugen, die unter Verwendung des StringWriter-Objekts eine entsprechende Zeichenkette erzeugt. Diese Zeichenkette übergibt man dann ganz einfach dem Parameter der ent-sprechenden DB-Prozedur, die sich um die Datenverarbeitung kümmert.
public void UpdateProduct(Product product) {
XmlSerializer serializer = new XmlSerializer(typeof(Product));
StringBuilder builder = new StringBuilder();
using (StringWriter writer = new StringWriter(builder)) {
serializer.Serialize(writer, product);
}
String ProductXML = builder.ToString();
using (SqlConnection connection = new SqlConnection(ConnectionString)) {
SqlCommand cmd = new SqlCommand("Production.UpdateProduct", connection);
cmd.Parameters.Add("@vProductXML", SqlDbType.NVarChar);
cmd.Parameters["@vProductXML"].Value = ProductXML;
Fallbeispiele
288
cmd.CommandType = CommandType.StoredProcedure;
connection.Open();
cmd.ExecuteNonQuery();
connection.Close();
}
}
Serialisierung/ProductSerializer.cs: Eigene DOM-Serialisierung
Auch wenn die vorgestellten Methoden bereits sehr gut geeignet sind, auch die Klien-tensicht vorstellbar zu machen, folgt nun noch in einer anderen Klasse die Main()-Methode, mit der die verschiedenen Methoden getestet werden können. Dabei ruft man zunächst mit der Standard-Deserialisierung ein gewöhnliches Produkt ab, ändert seine Eigenschaften und aktualisiert es mit der Serialisierungsmethode, um dann die verän-derten Daten mit der DOM-Deserialisierung wieder abzurufen.
namespace Serialisierung {
class Program {
static void Main(string[] args) {
ProductSerializer serializer = new ProductSerializer();
Product product = serializer. GetProductStandard("SA-M237");
Console.WriteLine("Standardserialisierung");
Console.WriteLine("-----------------------");
Console.WriteLine( product.Name + " " + product.ProductNumber + " " + product.ListPrice);
Console.WriteLine("Aktualisierung");
product.ListPrice = product.ListPrice * 1.4;
product.StandardCost = product.StandardCost * 1.4;
product.Name = product.Name + " New";
serializer.UpdateProduct(product);
Console.WriteLine("-----------------------");
Console.WriteLine("DOM-Serialisierung");
product = serializer.GetProductDOM("SA-M237");
Fallbeispiele
289
Console.WriteLine("DOM - Serialisierung");
Console.WriteLine( product.Name + " " + product.ProductNumber + " " + product.ListPrice);
Console.ReadLine();
}
}
}
Serialisierung/Program.cs: Test von De-/Serialisierung
7.2 Datenaustausch Neben der zuvor diskutierten Lösung zur (De-)Serialisierung ist vermutlich die Einrich-tung einer Import-/Export-Schnittstelle eine häufigere Aufgabenstellung. Sie soll in diesem Abschnitt diskutiert werden.
7.2.1 Export
Neben dieser speziellen Möglichkeit der Serialisierung sind es vor allen Dingen die klassischen CSV-basierten Import-/Export-Schnittstellen, welche durch XML-Techniken abgelöst werden. Zunächst soll die allgemeine Architektur des Export-Vorgangs beschrieben werden. Die Grundbausteine des gesamten Systems lassen sich auf der allgemeinen Ebenen der Beschreibung für beide Richtungen nutzen und tauchen daher sowohl für den Import- als auch für den Export-Vorgang auf.
In der Datenbank selbst befinden sich verschiedene relationale Tabellen, deren Daten-bestand im Hinblick auf den Export-Vorgang die Quelle darstellen. Für dieses Ziel kann zusätzlich auch die Einrichtung einer Sicht mit einer möglichst guten relationalen Ab-bildung der Zieldatenstruktur oder wenigstens einer zusammenfassenden Struktur hilf-reich sein. Diese Sicht ist ebenfalls in der Abbildung oberhalb der beiden Beispieltabel-len platziert. In dieser Sicht befinden sich die sich wiederholenden Gruppen von Eltern-Kind-Hierarchien, wenn die beiden Tabellen in einer 1:n-Beziehung zueinander stehen. In einem 1:1-Fall ist dies natürlich nicht der Fall. Hier würden nur die entsprechenden Spalten quasi nebeneinander gestellt.
Grundsätzlich muss man unterscheiden, ob der Exportvorgang zu konkreten XML-Dokumenten und damit auch Dateien führt, oder ob es sich um reine Datenströme han-
Fallbeispiele
290
delt. Während die Datenströme in jedem Fall nur auf Bedarf erzeugt werden und damit nicht notwendigerweise mit Hilfe von zeitgesteuerten DB-Jobs erzeugt werden können, kann hier auch keine zusätzliche Speicherung möglich sein. Daher werden die XML-Datenströme sowohl in Form eines Webservices als auch durch Interaktion mit einem Formular erzeugt und bereitgestellt. Die Dokumente dagegen werden als physische Dateien erzeugt und können auf unterschiedliche Weise in einem öffentlichen Ord-ner(verzeichnis) platziert und damit erneut persistent gespeichert werden. In vielen Fällen dürften dies auch FTP- oder WebDAV-Ordner sein, die über eine sichere Ver-bindung genutzt werden können.
Die Abbildung gibt keine Informationen darüber, wie die entsprechenden XML-Daten tatsächlich erzeugt werden. Dies ist in einer späteren Abbildung thematisiert. Stattdes-sen teilt ein senkrechter Strich die gesamte Grafik, um die beiden Hemisphären von zwei Unternehmen zu kennzeichnen. Es muss sich selbstverständlich nicht notwendi-gerweise um den Austausch von Daten zwischen zwei Unternehmen handeln, sondern es könnten auch Beziehungen zwischen zwei Abteilungen oder allgemein zwischen zwei unterschiedlichen Systemen sein.
Auf der Seite von Unternehmen B, welches hier im Rahmen des Export-Vorgangs die Daten erhält, gibt es ebenfalls unterschiedlich Möglichkeiten, wie die Daten abgerufen werden. Dies ist im Gegensatz zur Datenerzeugung sehr wohl dargestellt.
1. Im ersten Fall stellt Unternehmen A auch eine Webanwendung zur Verfügung, welche nach einem entsprechenden Login die Daten quasi zum Download anbietet. Dabei muss man sich diesen Download durchaus nicht so vorstellen, dass tatsächlich Dateien aus einem Ordner abgerufen werden, sondern dass die Benutzeranforderung zu einem Extraktionsvorgang führt, welcher flüchtig einen Datenstrom erstellt. Hierbei liegt die Softwareentwicklung aufseiten von Unternehmen A, dem Datenlieferanten, während Unternehmen B nur die von Unternehmen A bereitgestellten Zugangswege nutzt.
2. In einem zweiten Fall bietet Unternehmen A einen Webservice an. Dies bedeutet zwar auch, dass der wesentliche Teil der Softwareentwicklung bzgl. der Datenverteilung aufseiten von Unternehmen A liegt, doch können die Daten im Normalfall nur über Software von Unternehmen B auch tatsächlich abgerufen werden. Hier interagiert ein Benutzer des Zielsystems mit einem von Unternehmen B erstellten Web- oder Desktopanwendungsformular, welches in Wirklichkeit auf den Webservice zugreift. Diese Variante erlaubt die gleichen Möglichkeiten und Alternativen wie durch das direkt von Unternehmen A angebotene Web-Formular. Auch hier erzeugt Unternehmen A die Exportdaten nicht in Form von Dateien,
Fallbeispiele
291
sondern nur als flüchtigen Datenstrom. Hier ist ebenfalls eine Benutzerinteraktion vonnöten, um die Extraktion anzustoßen. Sollte dagegen aus Leistungs- oder Sicherheitsgründen eine solche unmittelbare Interaktion mit dem Exportmodul aufseiten von Unternehmen A unerwünscht sein, so bietet sich dennoch eine Möglichkeit an, über ein selbst erstelltes Formular auf den öffentlichen Ordner von Unternehmen A zuzugreifen. In einer weiteren Variation lässt sich sogar ein Webservice denken, welcher Unternehmen B die Möglichkeit bietet, mit einem solchen Ordner zu interagieren.
3. In einem dritten Fall wird die gerade eben genannte Möglichkeit noch einmal deutlicher aufgegriffen. Hier bietet Unternehmen A einen öffentlichen Ordner auf Basis von FTP, WebDAV oder einem sonstigen Prinzip an, auf den das Unternehmen B entweder direkt, über ein Formular oder auch über eine Import-Software zugreift. Insbesondere die letzte Möglichkeit führt eine weitere grundsätzliche Variante in diese Architektur ein. Während in den ersten beiden Fällen zunächst nur ein menschlicher Akteur von Unternehmen B den Import-Vorgang für sein Unternehmen durchführte, besteht natürlich sowohl beim Webservice als auch beim öffentlichen Ordner die Möglichkeit, eine eigene Software zu verwenden, welche zeitgesteuert oder auf Basis sonstiger Anstöße und Ereignisse den Importvorgang automatisch durchführt.
Die Erzeugung der XML-Daten ist über unterschiedliche T-SQL-Techniken möglich. Sie wurden in den vorherigen Abschnitten erläutert und sollen in diesem Zusammen-hang für die Realisierung dieser Import-/Export-Schnittstelle noch einmal aufgeführt werden. Die einzelnen Lösungen haben unterschiedliche Vor- und Nachteile, die teil-weise nur auf Grundlage des Zielschemas (Komplexität, Umfang, Tie-fe/Hierarchieanzahl) oder der Datenmenge für eine bestimmte Schnittstelle bewertet und letztendlich auch ausgewählt werden können. In allen Fällen hat man die Wahl, ob die erzeugte XML-Struktur als Datei gespeichert oder als XML-Datenstrom zurückge-geben wird. Auf die Möglichkeit, einen Webservice oder einen Windows-Dienst/eine Server-Komponente zu erstellen, wird nicht eingegangen, da dies noch tiefer gehende Kenntnisse der MS SQL Server-Programmierung erfordert.
Fallbeispiele
292
Tabelle 1 Tabelle 2
Datenbank
Sicht
Web-Formular
Web Service
Benutzer
Benutzer
Unternehmen A Unternehmen B
Formular
Export-software
FTP-Verzeichnis / Öffentlicher Ordner
XML
XML
Prozedur
Funktion<xml-strom/>
<xml-strom/>
Abbildung 4.3: Funktionsweise des Exports
Funktion: Eine Funktion ermöglicht die Erzeugung von XML-Daten mit allen XML-Techniken von T-SQL und liefert die Daten über einen Rückgabewert zurück. Sofern die Daten in einem anderen T-SQL-Programm benötigt werden oder eine Funktion besonders gut zum Einsatz kommen kann, ist dies die richtige Wahl. Dies ist insbesondere der Fall, wenn eine SQL-Anweisung die XML-Daten liefern soll und die äußere Anwendung einen solchen Datentyp verarbeiten kann. Die Übergabe von Parametern für Filter gelingt über die Übergabeparameter.
Prozedur: Eine Prozedur liefert die Daten nur über einen Ausgabe-Parameter. Im Normalfall gibt es allerdings eine Vielzahl an äußeren Programmier-sprachen, welche genau diesen Ausgabeparamter viel einfacher abfangen können als den Rückgabewert einer Funktion. Teilweise ist es auch in der äußeren
Fallbeispiele
293
Programmiersprache einfacher, eine Prozedur aufzurufen als eine Funktion. Die Übergabe von Parametern für Filter gelingt über die Übergabeparameter.
Sicht: Eine Sicht stellt in Form einer virtuellen Tabelle die Möglichkeit dar, XML-Daten so anzubieten, dass man eine einfache Abfrage nutzen kann. In diesem Fall muss allerdings sicher gestellt sein, dass die äußere Anwendung dieses Abfrageergebnis auch verarbeiten kann. Eine Filterung der Daten kann dann über T-SQL durchgeführt werden, was zu umfangreicheren Filtermöglichkeiten führt als eine begrenzte Anzahl an Parametern. Durch den Einsatz von T-SQL für die Filterung können hier fast beliebige Filteranweisungen ad hoc angegeben werden, die ansonsten in einer Prozedur/Funktion von vorneherein vorbereitet sein müssten.
7.2.2 Import
Der Import-Vorgang ist nicht nur aus einfach nachzuvollziehenden Gründen das zum Export passenden Pendant. Dieser Umstand wirkt sich auch sehr auf die allgemeine Architektur der Import-/Export-Schnittstelle aus. In der nachfolgenden Abbildung sind lediglich die Pfeile in ihrer Richtung vertauscht, und die Grafik erfordert eine andere Leserichtung, nämlich in diesem Fall von rechts nach links. Bedeutsam ist, dass auf der einen Seite natürlich auch verschiedene Wege genutzt werden können (Export über Webservice, Import dagegen über Upload-Formular), dass aber grundsätzlich auch die Option besteht, beide Vorgänge über den gleichen Kanal durchzuführen, sofern ein wechselseitiger Datenaustausch überhaupt innerhalb des Systemumfangs liegen soll.
Die drei oben genannten Schnittstellen sind also in auch in dieser Lösung vorhanden.
1. Im ersten Fall stellt Unternehmen A für den Datenimport eine Web-Anwendung zur Verfügung, welche nach einem entsprechenden Login die Daten für einen Upload-Vorgang entgegennimmt. Hier wird vermutlich tatsächlich von Unternehmen B eine physische Datei erstellt, die das Exportmodul als Variante auch erst im Rahmen der gesamten Transaktion aus den vorhandenen Daten generiert.
2. In einem zweiten Fall bietet Unternehmen A einen Webservice an. Dies bedeutet zwar auch, dass der wesentliche Teil der Softwareentwicklung bzgl. der Datenverteilung aufseiten von Unternehmen A liegt, doch können die Daten im Normalfall nur über Software von Unternehmen B auch tatsächlich übertragen werden. Hier interagiert ein Benutzer des Zielsystems mit einem von Unternehmen B erstellten Web- oder Desktopanwendungsformular, welches in Wirklichkeit auf den Webservice zugreift. Diese Variante erlaubt die gleichen Möglichkeiten und Alternativen wie durch das direkt von Unternehmen A angebotene Web-Formular.
Fallbeispiele
294
Hier erzeugt Unternehmen B die Exportdaten nicht in Form von Dateien, sondern nur als flüchtigen Datenstrom, der als Webservice-Anfrage verschickt wird. Alternativ wird er sogar aus Dateien gewonnen. Hier ist gleichfalls eine Benutzerinteraktion vonnöten, um die Übertragung anzustoßen. Sollte dagegen aus Leistungs- oder Sicherheitsgründen eine solche unmittelbare Interaktion mit dem Importmodul aufseiten von Unternehmen A unerwünscht sein, so bietet sich dennoch eine Möglichkeit an, über ein selbst erstelltes Formular auf den öffentlichen Ordner von Unternehmen A zuzugreifen. In einer weiteren Variation lässt sich sogar ein Webservice denken, welcher Unternehmen B die Möglichkeit bietet, mit einem solchen Ordner zu interagieren und Dateien in diesem Order abzulegen
3. In einem dritten Fall wird die gerade eben genannte Möglichkeit noch einmal deutlicher aufgegriffen. Hier bietet Unternehmen A einen öffentlichen Ordner auf Basis von FTP, WebDAV oder einem sonstigen Prinzip an, auf den das Unternehmen B entweder direkt, über ein Formular oder auch über eine Export-Software zugreift. Insbesondere die letzte Möglichkeit führt eine weitere grundsätzliche Variante in diese Architektur ein. Während in den ersten beiden Fällen zunächst nur ein menschlicher Akteur von Unternehmen B den Export-Vorgang für sein Unternehmen durchführte, besteht natürlich sowohl beim Webservice als auch beim öffentlichen Ordner die Möglichkeit, eine eigene Software zu verwenden, welche zeitgesteuert oder auf Basis sonstiger Anstöße und Ereignisse den Exportvorgang automatisch durchführt.
Die nachfolgende Abbildung zeigt die unterschiedlichen Varianten anhand der vorher schon verwendeten Struktur, wobei die einzige Änderung in der Umkehrung der Pfeil-richtung besteht, die den Datenverkehr symbolisieren.
Für die Realisierung einer solchen Import-Schnittstelle lassen sich am besten folgende Techniken nutzen. Die Realisierung über einen Webservice, eine Server-Komponente oder einen Windows-Dienst erfordert fortgeschrittene T-SQL/.NET-Kenntnisse und soll hier nicht behandelt werden.
Prozedur: Eine Prozedur erwartet als Übergabeparameter die XML-Daten und zerlegt sie relational. Als Ausgabeparameter kann dann eine Erfolgsmeldung übergeben werden. Im Normalfall ist dies die beste Lösung.
Funktion: Eine Funktion erwartet die Daten ebenfalls als Übergabeparameter, kann insbesondere auch eine Erfolgsmeldung als Rückgabewert liefern. Sie muss allerdings in Form eines längeren T-SQL-Skripts genutzt werden und auf der
Fallbeispiele
295
rechten Seite der Zuweisung erscheinen, was nicht immer gewünscht/vorteilhaft sein wird.
Tabelle: Eine Tabelle kann über einen INSERT-Befehl die XML-Daten erwarten, validieren und dann speichern. Ein Trigger oder eine weitere Prozedur könnte sie dann weiter relational zerlegen. Dies erlaubt die Zwischenspeicherung von XML-Daten zur Kontrolle durch einen Benutzer oder eine Automatik, die nicht unmittelbar mit dem Speichervorgang gleichzeitig abläuft.
Tabelle 1 Tabelle 2
Datenbank
Sicht
Web-Formular
Web Service
Benutzer
Benutzer
Unternehmen A Unternehmen B
Formular
Import-software
FTP-Verzeichnis / Öffentlicher Ordner
XML
XML
Prozedur
Funktion<xml-strom/>
<xml-strom/>
Abbildung 4.4: Import
Die Ausführungen haben vor allen Dingen die einzelnen Wege gezeigt, in denen eine Übertragung von Daten stattfinden kann und mit welchen Werkzeugen sie tatsächlich durchgeführt wird. Diese Werkzeuge wurden in anderen Kapiteln schon weitestgehend
Fallbeispiele
296
beschrieben. Sie haben allerdings auch gezeigt, wie viele Untervarianten und zusätzli-che Möglichkeiten dem Entwickler bzw. dem Planer offen stehen, eine solche Schnitt-stelle zu realisieren. Allein solche Überlegungen, wie bei unterschiedlichen ein- oder ausgehenden Datenströmen ein Zwischenformat zu benutzen, eröffnet eine ganz neue Dimension der Architektur, die in Abhängigkeit der zu behandelnden XML-Strukturen sehr viel Arbeit ersparen kann – oder natürlich auch Arbeit bedeuten kann, wenn die Formate und Algorithmen doch nicht so zahlreich werden wie vorausgesetzt.
7.2.3 Beispiele
Durch die Tatsache, dass der Datentyp xml an jeder Stelle zum Einsatz kommen kann, an der auch ein anderer Datentyp wie int oder nvarchar zum Einsatz kommen könn-te, ergeben sich viele Möglichkeiten, XML-Daten zu liefern, zu speichern oder zu über-nehmen Daher sollen die nachfolgenden Beispiele das gesamte Kapitel nur abrunden und die erwähnte Tatsache noch einmal illustrieren. Andere Beispiele, Funktionen, Prozeduren oder Sichten zu erstellen, sind auch schon an anderer Stelle gefallen. Die Möglichkeit, diesen Datentyp als Tabellendatentyp zu verwenden, wurde in jedem Fall mehrfach vorgeführt, sodass dies in diesem letzten Abschnitt ausfallen kann.
7.2.3.1 Sicht
Eine Sicht kann XML-Daten zurückliefern, wobei man in diesem Fall zwischen einer Sicht wählen kann, die ausschließlich XML zurückliefert, oder einer solchen, die neben anderen Spalten mit beliebigen Datentypen auch noch eine oder mehrere XML-Spalten besitzt. Das nachfolgende Beispiel zeigt eine Sicht, die ausschließlich XML zurücklie-fert. In diesem Fall ist nicht viel zu tun, außer eine Abfrage zu erstellen, die das ge-wünschte XML bereitstellt. Insbesondere die Spalte, in der das XML später abgerufen werden kann, muss namentlich benannt werden, da ansonsten eine Fehlermeldung aus-gelöst wird.
CREATE VIEW vProductXML (Product) AS
SELECT ProductID AS ID, Name, Size, ListPrice
FROM Production.Product AS Product
FOR XML AUTO, ROOT('Product-List')
723_01.sql: Erstellung einer Sicht
Diese Sicht lässt sich dann abfragen, wobei in diesem Fall nur ein nvarchar(max)-Datentyp in der Spalte Product erzeugt wird, sodass SELECT Product FROM vPro-
Fallbeispiele
297
ductXML eine lange Zeichenkette und keine Möglichkeit für weitere Einschränkungen bietet. Man erhält als Ergebnis:
Product
------------------------------------------------------------
<Product-List><Product ID="1" Name="Adjustable Race" ListPrice="0.0000"/>...
(1 Zeile(n) betroffen)
7.2.3.2 Prozedur
Eine Prozedur kann auf zweierlei Arten mit XML umgehen: entweder liefert sie XML über einen Ausgabeparameter oder eine Abfrage zurück, oder sie ist in der Lage, XML über einen Übergabeparameter zu akzeptieren. In diesem letzten Fall könnte man sich – wie zuvor erläutert – vorstellen, dass mit OPENXML eine relationale Zerlegung in einem Schritt oder mit sonstigen T-SQL-Anweisungen die Zerlegung in mehreren Schritten stattfindet. Die nachfolgend erstellte Prozedur liefert wie eine Sicht XML über eine Abfrage zurück. Wie jeder Prozedur, die eine Ergebnismenge liefert, lässt sich hier sehr einfach ein Parameter für einen Filter übergeben.
CREATE PROCEDURE pProductXML (@price money) AS
SELECT ProductID AS ID, Name, Size, ListPrice
FROM Production.Product AS Product
WHERE ListPrice <= @price
FOR XML AUTO, ROOT('Product-List')
723_02.sql: Erzeugung einer Prozedur
Diese Prozedur kann dann mit EXEC pProductXML @price = 200 getestet werden und liefert ein XML-Dokument (keine Zeichenkette) zurück. Man erhält als Ergebnis:
XML_F52E2B61-18A1-11d1-B105-00805F49916B
--------------------------------------------------------------
<Product-List><Product ID="1" Name="Adjustable Race" ListPrice="0.0000"/>...
Fallbeispiele
298
7.2.3.3 Funktion
Eine Funktion kann wie eine Prozedur XML durch einen Übergabeparameter erwarten und verarbeiten; sie kann jedoch auch XML durch ihren Rückgabeparameter zurücklie-fern. Dies erfordert lediglich, diesen Datentyp anzukündigen und entsprechende Daten über die RETURN-Anweisung auch tatsächlich nach einer Abfrage oder einer schrittwei-sen Zusammensetzung zurückzuliefern.
CREATE FUNCTION fProductXML (
@price money
)
RETURNS XML
AS BEGIN
DECLARE @productList XML
SET @productList = (
SELECT ProductID AS ID, Name, Size, ListPrice
FROM Production.Product AS Product
WHERE ListPrice <= @price
FOR XML AUTO, ROOT('Product-List'))
RETURN @productList
END
723_03.sql: Erzeugung einer Funktion
Diese Funktion lässt sich dann über SELECT dbo.fProductXML(1000) testen und liefert wie die Prozedur ein XML-Dokument zurück.
