Del via


Brug lagrede procedurer med Fabric API til GraphQL

Microsoft Fabric API til GraphQL gør det nemt at forespørge på og mutere data fra en Fabric SQL-database og andre Fabric-datakilder, f.eks. Data Warehouse og Lakehouse, med stærkt indtastede skemaer og et omfattende forespørgselssprog, der giver udviklere mulighed for at oprette en intuitiv API uden at skrive brugerdefineret serverkode. Du kan bruge lagrede procedurer til at indkapsle og genbruge kompleks forretningslogik, herunder inputvalidering og datatransformation.

Hvem bruger lagrede procedurer med GraphQL

Lagrede procedurer i GraphQL er værdifulde for:

  • Dataingeniører , der implementerer datavalidering, transformation og behandlingsprocesser i Fabric SQL-databaser
  • Backend-udviklere , der eksponerer kompleks forretningslogik fra Fabric-lagre gennem moderne GraphQL-API'er
  • Applikationsarkitekter designer sikre, performante API'er, der indkapsler forretningsregler inden for Fabric-platformen
  • Databaseudviklere moderniserer eksisterende Fabric SQL-databaselagrede procedurer med GraphQL-grænseflader

Brug lagrede procedurer, når du har brug for server-side logik til datavalidering, komplekse beregninger eller flertrins databaseoperationer.

Denne artikel demonstrerer, hvordan man kan eksponere en lagret procedure gennem en GraphQL-mutation i Fabric. Eksemplet implementerer en produktregistreringsarbejdsgang med servervalidering, datatransformation og ID-generering – alt indkapslet i en lagret procedure og tilgængeligt via GraphQL.

Forudsætninger

Før du begynder, skal du bruge en Fabric SQL-database med eksempeldata:

  1. I dit Fabric-arbejdsområde vælger du Ny Item>SQL-database (forhåndsvisning)
  2. Giv din database et navn
  3. Vælg Eksempeldata for at oprette de nødvendige tabeller og data

Dette skaber AdventureWorks-eksempeldatabasen, som inkluderer SalesLT.Product tabellen brugt i dette eksempel.

Scenarie: Registrer et nyt produkt

Dette eksempel skaber en lagret procedure til registrering af nye produkter med indbygget forretningslogik:

  • Validering: Sikrer at ListPrice er højere end StandardCost
  • Datatransformation: Skriver produktnavnet med stort og normaliserer produktnummeret
  • ID-generering: Tildeler automatisk det næste tilgængelige ProduktID

Ved at indkapsle denne logik i en lagret procedure sikrer du ensartet datakvalitet uanset hvilken klientapplikation der indsender dataene.

Trin 1: Opret den lagrede procedure

Opret en T-SQL lagret procedure, der implementerer produktregistreringslogikken:

  1. I din SQL-database vælger du Ny forespørgsel

  2. Udfør følgende udsagn:

    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;
    
  3. Vælg Kør for at oprette den lagrede procedure

  4. Efter oprettelsen vil du se RegisterProduct under Stored Procedures i SalesLT-skemaet . Test proceduren for at sikre, at den virker korrekt:

    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
    

Trin 2: Opret en GraphQL-API

Opret nu et GraphQL API, der eksponerer både tabellerne og den gemte procedure:

  1. I SQL-databasebåndet vælger du Nyt API for GraphQL
  2. Giv dit API et navn
  3. I Hent-data-skærmen vælger du SalesLT-skemaet
  4. Vælg de tabeller, du vil eksponere, og den lagrede procedure RegisterProduct
  5. Vælg indlæsning

Hent dataskærm til at vælge tabeller og procedurer i API til GraphQL.

GraphQL-API'en, skemaet og alle fortolkere genereres automatisk i sekunder baseret på SQL-tabellerne og den lagrede procedure.

Trin 3: Kald proceduren fra GraphQL

Fabric genererer automatisk en GraphQL-mutation for den lagrede procedure. Mutationsnavnet følger mønsteret execute{ProcedureName}, så RegisterProduct-proceduren bliver executeRegisterProduct.

For at teste mutationen:

  1. Åbn API'et i forespørgselseditoren

  2. Udfør følgende mutation:

    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
       }
    }
    

Mutation i GraphQL API-portalen, der viser resultaterne.

Bemærk, hvordan den lagrede procedures forretningslogik automatisk behandler inputtet:

  • "graphQL swag" bliver til "Graphql swag" (med stort begyndelsesbogstav)
  • "gql-swag-001" bliver til "GQL-SWAG-001" (med store bogstaver)
  • ProductID genereres automatisk som det næste sekventielle nummer

Bedste praksis

Når man bruger lagrede procedurer med API til GraphQL:

  • Returner resultatsæt: Fabric genererer automatisk mutationer for lagrede procedurer, der bruger OUTPUT eller returnerer resultatsæt. De returnerede kolonner bliver GraphQL-mutationens returtype.
  • Indkapsl forretningslogik: Hold validering, transformation og komplekse beregninger i den lagrede procedure i stedet for i klientkoden. Dette sikrer konsistens på tværs af alle applikationer.
  • Håndter fejl elegant: Brug THROW sætninger til at returnere meningsfulde fejlmeddelelser, som kan fremmes via GraphQL API'en.
  • Overvej ID-generering: Brug kun brugerdefineret ID-genereringslogik (som at øge MAX), hvis du ikke bruger identitetskolonner. For produktionsscenarier er identitetskolonner normalt mere pålidelige.
  • Dokumentparametre: Brug klare parameternavne, der oversættes godt til GraphQL-feltnavne.

Ved at eksponere lagrede procedurer gennem Fabric API for GraphQL kombinerer du SQL's procedurelogik med GraphQL's fleksible forespørgselsgrænseflade og skaber robuste og vedligeholdelsesvenlige dataadgangsmønstre.