Bruk lagrede prosedyrer med Fabric API for GraphQL

Microsoft Fabric API for GraphQL gjør det enkelt å spørre og mutere data fra en Fabric SQL-database og andre Fabric-datakilder, for eksempel Data Warehouse og Lakehouse, med sterkt skrevne skjemaer og et rikt spørringsspråk, slik at utviklere kan opprette en intuitiv API uten å skrive egendefinert serverkode. Du kan bruke lagrede prosedyrer til å innkapsle og bruke kompleks forretningslogikk på nytt, inkludert inndatavalidering og datatransformasjon.

Hvem bruker lagrede prosedyrer med GraphQL

Lagrede prosedyrer i GraphQL er verdifulle for:

• Dataingeniører implementerer datavalidering, transformasjon og prosesseringsarbeidsflyter i Fabric SQL-databaser
• Backend-utviklere eksponerer kompleks forretningslogikk fra Fabric-lagre gjennom moderne GraphQL-API-er
• Applikasjonsarkitekter som designer sikre, ytelsesfulle API-er som kapsler inn forretningsregler i Fabric-plattformen
• Databaseutviklere moderniserer eksisterende Fabric SQL-databaselagrede prosedyrer med GraphQL-grensesnitt

Bruk lagrede prosedyrer når du trenger serverside-logikk for datavalidering, komplekse beregninger eller flerstegs databaseoperasjoner.

Denne artikkelen demonstrerer hvordan man kan eksponere en lagret prosedyre gjennom en GraphQL-mutasjon i Fabric. Eksempelet implementerer en produktregistreringsarbeidsflyt med servervalidering, datatransformasjon og ID-generering – alt innkapslet i en lagret prosedyre og tilgjengelig via GraphQL.

Prerequisites

Før du begynner, trenger du en Fabric SQL-database med eksempeldata:

1. I ditt Fabric-arbeidsområde, velg New Item>SQL-database (forhåndsvisning)
2. Gi databasen ditt et navn
3. Velg Eksempeldata for å lage nødvendige tabeller og data

Dette oppretter AdventureWorks-eksempeldatabasen, som inkluderer SalesLT.Product tabellen brukt i dette eksempelet.

Scenario: registrere et nytt produkt

Dette eksempelet lager en lagret prosedyre for registrering av nye produkter med innebygd forretningslogikk:

• Validering: Sikrer at ListPrice er høyere enn StandardCost
• Datatransformasjon: Skriver produktnavnet med stor forbokstav og normaliserer produktnummeret
• ID-generering: Tildeler automatisk neste tilgjengelige produkt-ID

Ved å kapsle inn denne logikken i en lagret prosedyre, sikrer du konsistent datakvalitet uansett hvilken klientapplikasjon som sender inn dataene.

Trinn 1: Opprett den lagrede prosedyren

Lag en T-SQL-lagret prosedyre som implementerer produktregistreringslogikken:

1. Velg Ny spørring i SQL-databasen din

2. Utfør følgende utsagn:

   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. Velg Kjør for å opprette den lagrede prosedyren

4. Etter opprettelse vil du se RegisterProduct under Lagrede prosedyrer i SalesLT-skjemaet . Test prosedyren for å bekrefte at den fungerer riktig:

   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
   

Trinn 2: Opprette en GraphQL-API

Nå oppretter du et GraphQL API som eksponerer både tabellene og den lagrede prosedyren:

1. I SQL-databasebåndet, velg Nytt API for GraphQL
2. Gi API-et ditt et navn
3. I Hent-data-skjermen velger du SalesLT-skjemaet
4. Velg tabellene du vil eksponere og den lagrede prosedyren RegisterProduct
5. Velg last

GraphQL API, skjema og alle resolvers genereres automatisk i sekunder basert på SQL-tabeller og lagret prosedyre.

Trinn 3: Kall prosedyren fra GraphQL

Fabric genererer automatisk en GraphQL-mutasjon for den lagrede prosedyren. Mutasjonsnavnet følger mønsteret execute{ProcedureName}, så RegisterProdukt-prosedyren blir executeRegisterProduct.

For å teste mutasjonen:

1. Åpne API-et i spørringseditoren

2. Utfør følgende mutasjon:

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

Legg merke til hvordan den lagrede prosedyrens forretningslogikk automatisk behandler inputen:

• "graphQL swag" blir til "Graphql swag" (med stor forbokstav)
• "gql-swag-001" blir til "GQL-SWAG-001" (med store bokstaver)
• ProductID genereres automatisk som neste sekvensielle nummer

Anbefalte fremgangsmåter

Når man bruker lagrede prosedyrer med API for GraphQL:

• Returner resultatsett: Fabric genererer automatisk mutasjoner for lagrede prosedyrer som bruker OUTPUT eller returnerer resultatsett. De returnerte kolonnene blir GraphQL-mutasjonens returtype.
• Kapsl inn forretningslogikk: Hold validering, transformasjon og komplekse beregninger i den lagrede prosedyren i stedet for i klientkoden. Dette sikrer konsistens på tvers av alle applikasjoner.
• Håndter feil elegant: Bruk THROW setninger for å returnere meningsfulle feilmeldinger som kan vises gjennom GraphQL API.
• Vurder ID-generering: Bruk kun tilpasset ID-genereringslogikk (som å øke MAX) hvis du ikke bruker identitetskolonner. For produksjonsscenarier er identitetskolonner vanligvis mer pålitelige.
• Dokumentparametere: Bruk klare parameternavn som oversettes godt til GraphQL-feltnavn.

Ved å eksponere lagrede prosedyrer gjennom Fabric API for GraphQL, kombinerer du kraften i SQLs prosedyrelogikk med GraphQLs fleksible spørringsgrensesnitt, og skaper robuste og vedlikeholdbare datatilgangsmønstre.

Relatert innhold

• Fabric API for GraphQL Editor
• SQL-database i Microsoft Fabric