Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
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:
- I dit Fabric-arbejdsområde vælger du Ny Item>SQL-database (forhåndsvisning)
- Giv din database et navn
- 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:
I din SQL-database vælger du Ny forespørgsel
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;Vælg Kør for at oprette den lagrede procedure
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:
- I SQL-databasebåndet vælger du Nyt API for GraphQL
- Giv dit API et navn
- I Hent-data-skærmen vælger du SalesLT-skemaet
- Vælg de tabeller, du vil eksponere, og den lagrede procedure RegisterProduct
- Vælg indlæsning
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:
Åbn API'et i forespørgselseditoren
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 } }
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
OUTPUTeller 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
THROWsæ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.