Verwenden von gespeicherten Prozeduren mit fabric-API für GraphQL

Die Microsoft Fabric-API für GraphQL erleichtert das Abfragen und Ändern von Daten aus einer Fabric SQL-Datenbank und anderen Fabric-Datenquellen, wie etwa einem Data Warehouse und Lakehouse. Mit stark typisierten Schemata und einer umfangreichen Abfragesprache können Entwickler eine benutzerfreundliche API erstellen, ohne benutzerdefinierten Servercode zu schreiben. Sie können gespeicherte Prozeduren verwenden, um komplexe Geschäftslogik zu kapseln und wiederzuverwenden, einschließlich Eingabeüberprüfung und Datentransformation.

Wer gespeicherte Prozeduren mit GraphQL verwendet

Gespeicherte Prozeduren in GraphQL sind nützlich für:

Datentechniker implementieren Datenüberprüfungs-, Transformations- und Verarbeitungsworkflows in Fabric SQL-Datenbanken
Back-End-Entwickler , die komplexe Geschäftslogik aus Fabric-Warehouses über moderne GraphQL-APIs verfügbar geben
Anwendungsarchitekten entwerfen sichere, leistungsfähige APIs, die Geschäftsregeln innerhalb der Fabric-Plattform kapseln
Datenbankentwickler modernisieren vorhandene gespeicherte Fabric SQL-Datenbankprozeduren mit GraphQL-Schnittstellen

Verwenden Sie gespeicherte Prozeduren, wenn Sie serverseitige Logik für die Datenüberprüfung, komplexe Berechnungen oder mehrstufige Datenbankvorgänge benötigen.

In diesem Artikel wird veranschaulicht, wie Sie eine gespeicherte Prozedur über eine GraphQL-Mutation in Fabric verfügbar machen. Im Beispiel wird ein Produktregistrierungsworkflow mit serverseitiger Überprüfung, Datentransformation und ID-Generierung implementiert– alle in einer gespeicherten Prozedur gekapselt und über GraphQL zugänglich.

Voraussetzungen

Bevor Sie beginnen, benötigen Sie eine Fabric SQL-Datenbank mit Beispieldaten:

Wählen Sie in Ihrem Fabric-Arbeitsbereich die SQL-Datenbank "Neues Element>"(Vorschau) aus.
Geben Sie Ihrer Datenbank einen Namen
Wählen Sie Beispieldaten aus, um die erforderlichen Tabellen und Daten zu erstellen.

Dadurch wird die AdventureWorks-Beispieldatenbank erstellt, die die SalesLT.Product in diesem Beispiel verwendete Tabelle enthält.

Szenario: Registrieren eines neuen Produkts

In diesem Beispiel wird eine gespeicherte Prozedur zum Registrieren neuer Produkte mit integrierter Geschäftslogik erstellt:

Überprüfung: Stellt sicher, dass "ListPrice" größer als "StandardCost" ist.
Datentransformation: Schreibt den Produktnamen groß und normalisiert die Produktnummer.
ID-Generierung: Weist automatisch die nächste verfügbare ProductID zu.

Indem Sie diese Logik in einer gespeicherten Prozedur kapseln, stellen Sie unabhängig davon, welche Clientanwendung die Daten übermittelt, konsistente Datenqualität sicher.

Schritt 1: Erstellen der gespeicherten Prozedur

Erstellen Sie eine gespeicherte T-SQL-Prozedur, die die Produktregistrierungslogik implementiert:

Wählen Sie in Ihrer SQL-Datenbank "Neue Abfrage" aus.

Führen Sie die folgende Anweisung aus:

CREATE PROCEDURE SalesLT.RegisterProduct
  @Name nvarchar(50),
  @ProductNumber nvarchar(25),
  @StandardCost money,
  @ListPrice money,
  @SellStartDate datetime
AS
BEGIN
  SET NOCOUNT ON;
  SET IDENTITY\_INSERT SalesLT.Product ON;

  -- Validate pricing logic
  IF @ListPrice <= @StandardCost
    THROW 50005, 'ListPrice must be greater than StandardCost.', 1;

-- Transform product name: capitalize first letter only
  DECLARE @CleanName nvarchar(50);
  SET @CleanName = UPPER(LEFT(LTRIM(RTRIM(@Name)), 1)) + LOWER(SUBSTRING(LTRIM(RTRIM(@Name)), 2, 49));

  -- Trim and uppercase product number
  DECLARE @CleanProductNumber nvarchar(25);
  SET @CleanProductNumber = UPPER(LTRIM(RTRIM(@ProductNumber)));

  -- Generate ProductID by incrementing the latest existing ID
  DECLARE @ProductID int;
  SELECT @ProductID = ISNULL(MAX(ProductID), 0) + 1 FROM SalesLT.Product;

  INSERT INTO SalesLT.Product (
    ProductID,
    Name,
    ProductNumber,
    StandardCost,
    ListPrice,
    SellStartDate
  )
  OUTPUT 
    inserted.ProductID,
    inserted.Name,
    inserted.ProductNumber,
    inserted.StandardCost,
    inserted.ListPrice,
    inserted.SellStartDate
  VALUES (
    @ProductID,
    @CleanName,
    @CleanProductNumber,
    @StandardCost,
    @ListPrice,
    @SellStartDate
  );
END;

Wählen Sie "Ausführen" aus, um die gespeicherte Prozedur zu erstellen.

Nach der Erstellung wird "RegisterProduct" unter "Gespeicherte Prozeduren " im SalesLT-Schema angezeigt. Testen Sie das Verfahren, um zu überprüfen, ob es ordnungsgemäß funktioniert:

DECLARE @RC int
DECLARE @Name nvarchar(50)
DECLARE @ProductNumber nvarchar(25)
DECLARE @StandardCost money
DECLARE @ListPrice money
DECLARE @SellStartDate datetime

-- TODO: Set parameter values here.
Set @Name = 'test product'       
Set @ProductNumber = 'tst-0012'
Set @StandardCost = '10.00'
Set @ListPrice = '9.00'
Set @SellStartDate = '2025-05-01T00:00:00Z'

EXECUTE @RC = \[SalesLT\].\[RegisterProduct\] 
   @Name
  ,@ProductNumber
  ,@StandardCost
  ,@ListPrice
  ,@SellStartDate
GO

Schritt 2: Erstellen einer GraphQL-API

Erstellen Sie nun eine GraphQL-API, die sowohl die Tabellen als auch die gespeicherte Prozedur verfügbar macht:

Wählen Sie im Menüband der SQL-Datenbank die Option "Neue API" für GraphQL aus.
Geben Sie Ihrer API einen Namen
Wählen Sie im Bildschirm " Daten abrufen " das Schema "SalesLT" aus.
Wählen Sie die Tabellen aus, die Sie verfügbar machen möchten, und die gespeicherte RegisterProduct-Prozedur .
Wählen Sie "Laden" aus.

Die GraphQL-API, das Schema und alle Resolver werden automatisch in Sekunden basierend auf den SQL-Tabellen und gespeicherten Prozeduren generiert.

Schritt 3: Aufrufen der Prozedur aus GraphQL

Fabric generiert automatisch eine GraphQL-Mutation für die gespeicherte Prozedur. Der Mutationsname folgt dem Muster execute{ProcedureName}, sodass das RegisterProduct-Verfahren wird executeRegisterProduct.

So testen Sie die Mutation:

Öffnen der API im Abfrage-Editor

Führen Sie die folgende Mutation aus:

mutation {
   executeRegisterProduct (
    Name: " graphQL swag ",
    ProductNumber: "gql-swag-001",
    StandardCost: 10.0,
    ListPrice: 15.0,
    SellStartDate: "2025-05-01T00:00:00Z"
  ) {
ProductID
    Name
    ProductNumber
    StandardCost
    ListPrice
    SellStartDate
   }
}

Beachten Sie, wie die Geschäftslogik der gespeicherten Prozedur die Eingabe automatisch verarbeitet:

"graphQL swag" wird "Graphql swag" (großgeschrieben)
"gql-swag-001" wird zu "GQL-SWAG-001" in Großbuchstaben umgewandelt
ProductID wird automatisch als nächste sequenzielle Zahl generiert.

Bewährte Methoden

Bei Verwendung gespeicherter Prozeduren mit API für GraphQL:

Ergebnismengen zurückgeben: Fabric generiert automatisch Mutationen für gespeicherte Prozeduren, die OUTPUT Ergebnismengen verwenden oder zurückgeben. Die zurückgegebenen Spalten werden zum Rückgabetyp der GraphQL-Mutation.
Kapseln Sie Geschäftslogik: Behalten Sie Validierung, Transformation und komplexe Berechnungen in der gespeicherten Prozedur und nicht im Clientcode bei. Dadurch wird Konsistenz in allen Anwendungen gewährleistet.
Behandeln Sie Fehler ordnungsgemäß: Verwenden Sie THROW Anweisungen, um aussagekräftige Fehlermeldungen zurückzugeben, die über die GraphQL-API angezeigt werden können.
Erwägen Sie die ID-Generierung: Verwenden Sie nur benutzerdefinierte ID-Generierungslogik (wie das inkrementierende MAX-Verfahren), wenn Sie keine Identitätsspalten verwenden. Bei Produktionsszenarien sind Identitätsspalten in der Regel zuverlässiger.
Dokumentparameter: Verwenden Sie klare Parameternamen, die gut in GraphQL-Feldnamen übersetzt werden.

Indem Sie gespeicherte Prozeduren über die Fabric-API für GraphQL verfügbar machen, kombinieren Sie die Leistungsfähigkeit der SQL-Prozedurlogik mit der flexiblen Abfrageschnittstelle von GraphQL, wodurch robuste und verwendbare Datenzugriffsmuster erstellt werden.

Feedback

War diese Seite hilfreich?

Last updated on 2026-01-21