Azure SQL | The .NET Blog

NL2SQL ist die SQL-Injection des agentischen Zeitalters

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

Es gibt eine Version des NL2SQL-Versprechens, die perfekt klingt: Benutzer stellen Fragen in natürlicher Sprache, Agenten generieren SQL, Daten kommen zurück. Weniger Bildschirme, weniger Abfragen, weniger Code. Einfach.

Dann denken Sie fünf weitere Minuten darüber nach.

Die Probleme, über die niemand in der Demo spricht

Schemas wurden nicht dafür entworfen, Dinge zu erklären. Kryptische Tabellennamen, inkonsistente Spaltennamen, technisch gültige Beziehungen, die ohne zusätzliche Prädikate semantisch ungültig sind — das ist normal bei Unternehmensdatenbanken. Das sind keine Bugs, das ist einfach die angesammelte Geschichte von Geschäftsänderungen. Aber wenn Sie ein Modell bitten, Absicht aus einem Schema abzuleiten, das nicht dafür entworfen wurde, Absicht zu kommunizieren, wird das Modell es trotzdem versuchen. Es gibt nicht auf. Es generiert seine bestmögliche Abfrage und gibt Ergebnisse mit Zuversicht zurück.

Modelle sind nicht deterministisch. Stellen Sie dieselbe Frage zur gleichen Datenbank zweimal und Sie könnten unterschiedliches SQL erhalten. Das Modell berechnet Wahrscheinlichkeiten, und leichte Kontextvariationen treiben unterschiedliche Ausgaben. Sie können sich nicht durch Tests zu einer Garantie vorarbeiten, dass der Agent immer die richtige Abfrage generiert.

Benutzerüberprüfung skaliert nicht. “Überprüfen Sie einfach jede Abfrage vor der Ausführung” klingt sicher. Aber das setzt voraus, dass Benutzer sowohl im Datenmodell als auch in SQL Experten sind — genau die Menschen, die die natürlichsprachliche Schnittstelle nicht brauchten. Es führt auch zu kognitiver Überlastung und einer neuen Klasse von Bestätigungsverzerrung, bei der Benutzer, die von der Abfragekomplexität überwältigt sind, ungültige Abfragen genehmigen, anstatt sie zu untersuchen.

Und dann gibt es Injection. In der traditionellen SQL-Entwicklung löste Parametrisierung Injection, weil Benutzereingaben Parameter füllten, nicht die SQL-Struktur. Mit NL2SQL generiert das Modell das SQL selbst. Der Prompt, der Schema-Kontext, der Konversationsverlauf und abgerufene Daten beeinflussen alle, was ausgeführt wird. Wenn jemand einen Prompt erstellt, der ändert, was das Modell generiert, das ist Injection — nicht auf Parameterebene, sondern auf der Ebene der Abfragegenerierung. Und anders als das Löschen einer Tabelle (offensichtlich, wiederherstellbar) erzeugt NL2SQL-Injection Abfragen, die falsche Ergebnisse ohne sichtbaren Fehler zurückgeben. Geschäftsentscheidungen werden auf falschen Daten getroffen.

Was SQL MCP Server tatsächlich löst

Hier macht der Artikel seinen nützlichsten praktischen Punkt. Anstatt einem Agenten beliebigen Schema-Zugriff zu geben und das Beste zu hoffen, stellt SQL MCP Server eine kuratierte API-Oberfläche auf Basis von Data API builder bereit.

Der Unterschied ist wichtig: Der Agent generiert kein SQL. Er ruft benannte Endpunkte auf, die vordefinierte Ergebnisformen zurückgeben. Das SQL wird einmal von einem Entwickler geschrieben und ist deterministisch. Das Nicht-Determinismus des Agenten ist auf die Auswahl welches Endpunkt aufgerufen wird, nicht auf das Konstruieren beliebiger Abfragen beschränkt.

Das ist analog zu dem, was Parametrisierung bei der SQL-Injection im traditionellen App-Modell getan hat — Sie entfernen die Fähigkeit, beliebige Abfragen aus nicht vertrauenswürdiger Eingabe zu konstruieren.

Die richtige Frage

Der Artikel sagt nicht “benutze NL2SQL nie.” Er sagt: Sei bewusst darüber, wo du es anwendest und was du exponierst. Für explorative Analyse in einer kontrollierten Umgebung, mit einem begrenzten Schema und Nur-Lese-Zugriff, könnte NL2SQL in Ordnung sein. Für Produktionssysteme, bei denen Geschäftsentscheidungen von den Ergebnissen abhängen, ist eine kuratierte API-Schicht deutlich sicherer.

Ehrlichkeit: Manche Probleme werden wirklich besser mit strukturierten Abfragen hinter benannten Endpunkten gelöst als mit natürlicher Sprache zu SQL. SQL MCP Server gibt Ihnen diese Option, ohne die agentische Schnittstelle vollständig aufzugeben.

Originalbeitrag: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

Azure SQL Kann Jetzt Embeddings Generieren — In Reinem T-SQL, Keine Anwendungsschicht Erforderlich

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

Wenn Sie jemals eine RAG-Pipeline gebaut haben, kennen Sie die Pipeline-Steuer: Ihre Daten leben in SQL, aber um Embeddings zu generieren, müssen Sie sie extrahieren, eine Embedding-API aufrufen, Batching und Ratenlimits handhaben und die Ergebnisse irgendwo vektorsuchtauglich speichern. Oft in einer völlig anderen Datenbank.

Azure SQL hat das meiste davon gerade mit zwei Features eliminiert, die jetzt allgemein verfügbar sind: CREATE EXTERNAL MODEL und AI_GENERATE_EMBEDDINGS.

Was Sie Tun

Diese beiden T-SQL-Features funktionieren als integrierte Pipeline:

CREATE EXTERNAL MODEL — registriert einen externen KI-Modell-Endpoint als benanntes Datenbankobjekt. Sie legen Ort, API-Format, Modelltyp und Anmeldeinformationen einmal fest. Überall wiederverwendbar.

AI_GENERATE_EMBEDDINGS — eine skalare T-SQL-Funktion, die das registrierte Modell aufruft und ein JSON-Array von Vektorwerten zurückgibt. Funktioniert in SELECT-, INSERT-, UPDATE- und MERGE-Anweisungen.

Zusammen bilden sie eine End-to-End-Embedding-Pipeline ohne die SQL-Engine zu verlassen.

Der Vollständige Workflow

-- Schritt 1: Registrieren Sie Ihren Embedding-Anbieter einmal
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- Schritt 2: Embeddings inline in T-SQL generieren
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Schritt 3: Mit Vektorabstand suchen
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

Das ist die gesamte Pipeline: Daten in SQL, Embeddings in SQL generiert, Ähnlichkeitssuche in SQL. Keine Orchestrierungsschicht, kein ETL, keine separate Vektordatenbank.

Unterstützte API-Formate und Optionen

In der GA-Version unterstützt API_FORMAT Azure OpenAI und OpenAI. MODEL_TYPE ist derzeit auf EMBEDDINGS beschränkt. Das PARAMETERS-JSON ermöglicht das Festlegen von Standardwerten auf Modellebene einschließlich der Anzahl der Wiederholungsversuche:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

Die Authentifizierung verwendet Datenbankzugangsdaten, sodass Geheimnisse aus Ihrem Anwendungscode herausgehalten werden.

Was Dies für .NET-Anwendungen Ermöglicht

Für .NET-Entwickler, die KI-Features auf vorhandenen SQL-Daten aufbauen, ist dies bedeutsam. Sie müssen nicht:

Daten für Embeddings in einen Zwischenspeicher extrahieren
Eine externe Embedding-Pipeline verwalten
Eine separate Vektordatenbank einrichten (obwohl Sie Azure AI Search verwenden können, wenn Sie einen vollwertigen Vektorspeicher möchten)
Die Datenzugriffsschicht Ihrer Anwendung ändern

Sie können semantische Suche zu bestehenden SQL-Anwendungen inkrementell hinzufügen, mit denselben T-SQL-Tools, die Sie bereits haben.

Fazit

RAG-Muster auf SQL-Daten sind dramatisch einfacher geworden. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL bedeutet, dass Ihre bestehende SQL-Anwendung Vektorsuche-Fähigkeiten ohne neue Infrastruktur erwerben kann.

Beide Features sind heute in Azure SQL Database und Azure SQL Managed Instance allgemein verfügbar.

Originalbeitrag: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

Azure Data Studio wird eingestellt: Azure SQL-Workflows zu VS Code migrieren

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Azure Data Studio wurde am 6. Februar 2025 eingestellt, der Support endet am 28. Februar 2026 — der empfohlene Ersatz ist VS Code mit der MSSQL-Erweiterung.

Was zu installieren ist

Drei Dinge für den Einstieg:

MSSQL-Erweiterung — suche nach „SQL Server (mssql)" im VS Code Marketplace
SQL Database Projects-Erweiterung — Schema als Code, Build-Validierung, geführte Veröffentlichung
.NET 8 SDK — vom Build-System benötigt; fehlendes SDK ist das häufigste Problem beim ersten Start

ADS-Verbindungen und Einstellungen migrieren

Die MSSQL-Erweiterung enthält das ADS Migration Toolkit, das die einmalige Migration in einem geführten Ablauf übernimmt: gespeicherte Verbindungen, Verbindungsgruppen, Einstellungen und Tastenkürzel werden automatisch importiert.

F5-Muskelgedächtnis wiederherstellen

ADS-Nutzer verlassen sich auf F5 zum Ausführen von Abfragen. Installiere die Erweiterung MSSQL Database Management Keymap, um ADS-Tastenkürzel inklusive F5 zurückzubekommen.

SQL Database Projects: Schema als Code

Rechtsklick auf ein Projekt → Veröffentlichen → Ziel konfigurieren → generierten T-SQL-Script prüfen → deployen. Die Script-Vorschau vor dem Deployment ist das zentrale Sicherheitsmerkmal. Elementvorlagen erzeugen Stubs für Tabellen, gespeicherte Prozeduren und Views — derselbe Workflow wie bei SSDT.

Häufiges Problem: eine Zielplattform-Inkompatibilität in der .sqlproj-Datei verursacht Build-Fehler, wenn das Projekt gegen eine andere SQL Server-Version erstellt wurde.

Schema Compare und Schema Designer

Die Erweiterung enthält außerdem Schema Compare (Unterschiede zwischen Projekt und bereitgestellter Datenbank) und Schema Designer (visuelle Schema-Bearbeitung ohne manuelles DDL-Schreiben).

Microsoft Fabric-Entwickler

Die Einrichtung ist identisch, aber starte zunächst im Fabric-Portal und verbinde die Datenbank zuerst mit Git, bevor du sie in VS Code öffnest. Microsoft hat einen dedizierten Leitfaden: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

Fazit

Die Migration ist ein einmaliger geführter Ablauf, kein manueller Neuaufbau. Installiere die drei Tools, führe das ADS Migration Toolkit aus, stelle die Tastenkürzel wieder her — und du bist in unter 10 Minuten wieder einsatzbereit.

Den vollständigen Artikel findest du mit Schritt-für-Schritt-Screenshots und der Fabric-spezifischen Anleitung.

SQL MCP Server auf Azure App Service — Ohne Container

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion findest du hier.

Ehrlich gesagt: Jedes Mal, wenn ich “erfordert einen Container” in einem Tutorial lese, seufze ich innerlich. Container sind großartig — bis dein Team keine Container-Strategie hat und eine scheinbar einfache Funktion hinter Orchestrierungsaufwand steckt, den niemand eingeplant hatte.

Deshalb hat mich das hier aufhorchen lassen. Der SQL MCP Server läuft jetzt auf Azure App Service — ohne Docker, ohne Kubernetes, nur mit derselben Data API Builder (DAB)-Konfiguration, die deine SQL-Datenbank über MCP, REST und GraphQL bereitstellt.

Was ist der SQL MCP Server?

Kurzer Kontext, falls du ihn noch nicht kennst. Der SQL MCP Server sitzt zwischen deinem KI-Agenten und deiner SQL-Datenbank. Statt dem Agenten direkten Datenbankzugriff zu geben (was eine schreckliche Idee wäre), stellt er Tabellen und Views als Abstraktionsschicht bereit — Entitäten mit definierten Berechtigungen.

Er basiert auf Data API Builder, was bedeutet, dass eine einzige Konfigurationsdatei MCP und REST und GraphQL gleichzeitig bereitstellt. Dein Agent spricht mit dem MCP-Endpoint. Deine klassische Anwendung spricht mit REST oder GraphQL. Gleiche Config, gleiche Runtime, unterschiedliche Oberflächen.

Das ist wirklich nützlich. Du pflegst nicht zwei separate API-Schichten.

Das Container-Problem (und die Lösung)

Das ursprüngliche Bereitstellungsmodell für den SQL MCP Server waren Container. Das funktioniert in vielen Teams gut — aber nicht in allen. Viele .NET-Teams standardisieren auf Azure App Service oder VMs. Einen Container-Runtime nur für einen SQL-Endpoint zu benötigen, fügt Reibung hinzu, die niemand angefordert hat.

Das neue Walkthrough zeigt, wie man den Container komplett überspringt. Alles läuft mit einem dab start-Befehl, gehostet auf App Service als standardmäßiger .NET 8-Webprozess.

# Data API Builder installieren
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Konfiguration initialisieren
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Eine Entität hinzufügen
dab add products --source dbo.products --permissions "authenticated:*"

# App Service Auth-Provider konfigurieren
dab configure --runtime.host.authentication.provider AppService

# Server starten
dab start

Jetzt hast du MCP unter /mcp, REST und GraphQL aus demselben Prozess, und nichts läuft in einem Container.

Authentifizierung ohne geteilte API-Schlüssel

Das ist der Teil, den ich am meisten schätze. Bei der Bereitstellung auf App Service konfigurierst du Microsoft Entra ID als Authentifizierungsanbieter. Keine geteilten Geheimnisse in Konfigurationsdateien, keine API-Schlüssel, die rotiert werden müssen.

Der Connection String bleibt in einer App Service-Umgebungsvariable (nicht in dab-config.json), und der MCP-Endpoint ist durch Plattform-Authentifizierung geschützt. Wenn du bereits auf Entra ID in deinen Azure-Workloads ausgerichtet bist, fügt sich das natürlich ein.

Für die lokale Entwicklung wechselst du in den Simulator-Modus und STDIO-Transport. Vor dem Deployment wechselst du zurück in den AppService-Modus. Klar und explizit.

Bereitstellung auf App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Dann deployst du dein DAB-Projekt über deinen bevorzugten Code-Deployment-Weg. Das Entscheidende: Es ist ein Code-Deployment, kein Container-Deployment.

Warum das für .NET-Entwickler wichtig ist

Wenn du KI-Agenten in .NET baust, wird dein Agent irgendwann mit einer Datenbank kommunizieren müssen. Der SQL MCP Server bietet eine strukturierte Möglichkeit, das zu tun, ohne rohe Connection Strings preiszugeben.

Das vollständige Walkthrough findest du im Originalbeitrag und im Beispiel-Repository auf GitHub.

Fazit

Der SQL MCP Server auf App Service ist eine solide pragmatische Option für .NET-Teams, die ihren Agenten strukturierten SQL-Datenzugriff geben möchten, ohne eine Container-Strategie zu benötigen. Probier es aus — deine Agenten werden die saubere API-Oberfläche zu schätzen wissen.

SQL Server 2025 als Agent-Ready Datenbank: Sicherheit, Backup und MCP in einer Engine

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Ich habe die Polyglot Tax Serie von Aditya Badramraju mit großem Interesse verfolgt. Teile 1-3 lieferten den Beweis für SQL Server 2025 als echte Multi-Modell-Datenbank. Teil 4 schließt die Serie mit den Teilen, die wirklich bestimmen, ob du dieser Architektur in Produktion vertrauen würdest.

Ein Sicherheitsmodell für alle Datenmodelle

Eine Row-Level Security Policy, die alle Datenmodelle abdeckt — relationale Tabellen, JSON-Events, Graph-Edges, Vektoren. Eine Policy, ein Audit, ein Nachweis.

Einheitliches Backup = Atomare Wiederherstellung

In einem polyglottes Stack bedeutet Point-in-Time Recovery fünf koordinierte Restore-Operationen und die Hoffnung, dass die Timestamps übereinstimmen. Mit einer Datenbank ist die Wiederherstellung per Definition atomar.

MCP-Integration: Agenten Ohne Hand-codierten Middleware

SQL Server 2025 unterstützt den SQL MCP Server direkt. Agenten rufen Tools auf, die Engine erzwingt Tenant-Isolierung und Column-Masking automatisch.

Fazit

Für .NET-Entwickler, die agenten-first Anwendungen auf Azure SQL bauen, verdient diese Architektur ernsthafte Überlegung. Originalpost von Aditya Badramraju: The Polyglot Tax – Part 4.

SQL MCP Server — Der richtige Weg, AI-Agenten Datenbankzugriff zu geben

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

Seien wir ehrlich: Die meisten heute verfügbaren Datenbank-MCP-Server sind beängstigend. Sie nehmen eine natürlichsprachliche Abfrage, generieren SQL im laufenden Betrieb und führen es gegen Ihre Produktionsdaten aus. Was könnte schiefgehen? (Alles. Alles könnte schiefgehen.)

Das Azure SQL-Team hat gerade den SQL MCP Server vorgestellt, und er verfolgt einen grundlegend anderen Ansatz. Als Feature von Data API builder (DAB) 2.0 gebaut, gibt er AI-Agenten strukturierten, deterministischen Zugriff auf Datenbankoperationen — ohne NL2SQL, ohne Schema-Exposition und mit vollständigem RBAC bei jedem Schritt.

Warum kein NL2SQL?

Das ist die interessanteste Design-Entscheidung. Modelle sind nicht deterministisch, und komplexe Abfragen produzieren am wahrscheinlichsten subtile Fehler. Genau die Abfragen, von denen Benutzer hoffen, dass AI sie generieren kann, sind auch diejenigen, die die meiste Prüfung erfordern, wenn sie nicht-deterministisch erzeugt werden.

Stattdessen verwendet SQL MCP Server einen NL2DAB-Ansatz. Der Agent arbeitet mit der Entitäts-Abstraktionsschicht von Data API builder und dem integrierten Query Builder, um akkurates, wohlgeformtes T-SQL deterministisch zu produzieren. Gleiches Ergebnis für den Benutzer, aber ohne das Risiko halluzinierter JOINs oder versehentlicher Datenexposition.

Sieben Tools, nicht siebenhundert

SQL MCP Server exponiert genau sieben DML-Tools, unabhängig von der Datenbankgröße:

describe_entities — verfügbare Entitäten und Operationen entdecken
create_record — Zeilen einfügen
read_records — Tabellen und Views abfragen
update_record — Zeilen ändern
delete_record — Zeilen entfernen
execute_entity — gespeicherte Prozeduren ausführen
aggregate_records — Aggregationsabfragen

Das ist clever, weil Context Windows der Denkraum des Agenten sind. Sie mit Hunderten von Tool-Definitionen zu überfluten lässt weniger Raum für das Denken. Sieben feste Tools halten den Agenten auf Denken statt Navigieren fokussiert.

Jedes Tool kann einzeln aktiviert oder deaktiviert werden:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

In drei Befehlen starten

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Das ist ein laufender SQL MCP Server, der Ihre Customers-Tabelle exponiert. Die Entitäts-Abstraktionsschicht bedeutet, dass Sie Namen und Spalten aliasieren, Felder pro Rolle beschränken und genau kontrollieren können, was Agenten sehen — ohne interne Schema-Details preiszugeben.

Die Sicherheitsgeschichte überzeugt

Hier zahlt sich die Reife von Data API builder aus:

RBAC auf jeder Ebene — jede Entität definiert, welche Rollen lesen, erstellen, aktualisieren oder löschen können, und welche Felder sichtbar sind
Azure Key Vault-Integration — Connection Strings und Secrets sicher verwaltet
Microsoft Entra + Custom OAuth — Authentifizierung auf Produktionsniveau
Content Security Policy — Agenten interagieren über einen kontrollierten Vertrag, nicht über rohes SQL

Die Schema-Abstraktion ist besonders wichtig. Ihre internen Tabellen- und Spaltennamen werden niemals dem Agenten exponiert. Sie definieren Entitäten, Aliase und Beschreibungen, die für die AI-Interaktion sinnvoll sind — nicht Ihr Datenbank-ERD.

Multi-Datenbank und Multi-Protokoll

SQL MCP Server unterstützt Microsoft SQL, PostgreSQL, Azure Cosmos DB und MySQL. Und da es ein DAB-Feature ist, bekommen Sie REST-, GraphQL- und MCP-Endpoints gleichzeitig aus derselben Konfiguration. Gleiche Entitätsdefinitionen, gleiche RBAC-Regeln, gleiche Sicherheit — über alle drei Protokolle.

Die Auto-Konfiguration in DAB 2.0 kann sogar Ihre Datenbank inspizieren und die Konfiguration dynamisch aufbauen, wenn Sie für schnelles Prototyping mit weniger Abstraktion arbeiten möchten.

Meine Einschätzung

So sollte Enterprise-Datenbankzugriff für AI-Agenten funktionieren. Nicht „Hey LLM, schreib mir SQL und YOLO es gegen Produktion." Stattdessen: eine wohldefinierte Entitätsschicht, deterministische Abfragegenerierung, RBAC bei jedem Schritt, Caching, Monitoring und Telemetrie. Es ist langweilig auf die bestmögliche Art.

Für .NET-Entwickler ist die Integrationsgeschichte sauber — DAB ist ein .NET-Tool, der MCP Server läuft als Container, und er funktioniert mit Azure SQL, das die meisten von uns bereits verwenden. Wenn Sie AI-Agenten bauen, die Datenzugriff brauchen, starten Sie hier.

Zusammenfassung

SQL MCP Server ist kostenlos, Open Source und läuft überall. Es ist der präskriptive Ansatz von Microsoft, um AI-Agenten sicheren Datenbankzugriff zu geben. Lesen Sie den vollständigen Beitrag und die Dokumentation für den Einstieg.