Forstå Pre-validation i en Plugin Pipeline

Når man arbejder med Dataverse (tidligere kendt som Common Data Service), er en dyb forståelse af plugin-eksekveringspipelinen afgørende for at skrive robust og effektiv kode. Pipelinen er den proces, en dataoperation, såsom oprettelse, opdatering eller sletning af en post, gennemgår. Hvert trin i denne proces giver udviklere mulighed for at indsætte brugerdefineret logik. Et af de mest fundamentale, men ofte misforståede, stadier er Pre-validation. At forstå dets formål, og hvordan det adskiller sig fra de andre stadier, er nøglen til at bygge pålidelige og performante løsninger.

Denne artikel vil tage et dybdegående kig på Pre-validation stadiet. Vi vil udforske, hvorfor det eksisterer, hvad dets primære anvendelsesformål er, og hvordan dets placering uden for databasetransaktionen påvirker den måde, vi designer vores plugins på. Vi vil også sammenligne det med de andre stadier i pipelinen for at give en komplet forståelse af hele processen.

De Forskellige Stadier i Plugin Pipelinen

Når Dataverse modtager en anmodning om at udføre en handling, f.eks. at opdatere en kundepost, passerer denne anmodning gennem en veldefineret række af stadier. Det er vigtigt at kende dem alle for at kunne placere sin brugerdefinerede logik korrekt.

• Pre-validation (Før-validering): Dette er det allerførste stadie, hvor brugerdefineret kode kan køre. Det sker, før systemet overhovedet har startet en databasetransaktion. Formålet her er at validere inputdata.
• Pre-operation (Før-handling): Dette stadie kører lige før, systemet udfører hovedhandlingen (f.eks. selve databaseopdateringen). Det er det første stadie, der er inden for databasetransaktionen.
• Main Operation (Hovedhandling): Her udfører Dataverse-platformen selve datahandlingen. Dette stadie kan ikke tilpasses med plugins.
• Post-operation (Efter-handling): Dette stadie kører umiddelbart efter, at hovedhandlingen er fuldført, men stadig inden for den samme databasetransaktion. Her kan man reagere på den netop udførte handling.
• Async Operation (Asynkron Handling): Dette er et separat stadie, der kører helt uden for den oprindelige proces og transaktion. Det bruges til langvarige opgaver, der ikke skal blokere brugeren.

Et Dybdegående Kig på Pre-validation

Pre-validation er unikt, fordi det er det eneste synkrone stadie, der befinder sig uden for en databasetransaktion. Denne egenskab definerer fuldstændigt dets formål og anvendelsesområde.

Formålet med Pre-validation

Hovedformålet med Pre-validation stadiet er, som navnet antyder, at validere de data, der kommer ind i systemet. Fordi det kører før nogen databaseoperation er påbegyndt, er det det mest effektive sted at afvise en ugyldig anmodning. Hvis din logik i dette stadie finder, at dataene ikke overholder forretningsreglerne, kan du kaste en undtagelse (en `InvalidPluginExecutionException`). Dette vil stoppe hele processen med det samme og returnere en fejlmeddelelse til brugeren eller det kaldende system.

Fordelene ved at gøre dette i Pre-validation er:

1. Performance: Systemet undgår den omkostning, der er forbundet med at starte en databasetransaktion, kun for at skulle rulle den tilbage igen, hvis data er ugyldige. Transaktioner er ressourcekrævende, så tidlig afvisning sparer systemressourcer.
2. Klarhed: Det adskiller valideringslogik fra forretningslogik. Pre-validation handler om at tjekke, om anmodningen overhovedet er gyldig, mens senere stadier handler om at udføre handlinger baseret på en gyldig anmodning.

Hvad kan man gøre i Pre-validation?

Typiske opgaver i dette stadie inkluderer:

• At kontrollere, om påkrævede felter er udfyldt baseret på værdien af andre felter.
• At validere formater, f.eks. om et telefonnummer eller postnummer har det korrekte format.
• At sikre, at en bruger har de nødvendige rettigheder til at udføre en bestemt type handling, som går ud over standard sikkerhedsmodellen.
• At modificere de indkommende data. Ja, du kan rent faktisk ændre værdierne på de felter, der sendes til pipelinen, før de når transaktionen. For eksempel kan du standardisere et input ved at konvertere det til store bogstaver.

Databasetransaktionen: Alt eller Intet

For at forstå forskellen mellem Pre-validation og Pre-operation fuldt ud, er det nødvendigt at forstå, hvad en databasetransaktion er. En transaktion er en samling af en eller flere databaseoperationer, der behandles som en enkelt, atomisk enhed. Det betyder, at enten alle operationer inden for transaktionen lykkes og gemmes permanent, eller ingen af dem gør. Hvis en fejl opstår midt i processen (f.eks. i Post-operation stadiet), vil databasen automatisk 'rulle tilbage' (rollback) alle de ændringer, der er foretaget siden transaktionens start. Dette sikrer dataintegriteten.

Da Pre-validation er uden for denne transaktion, vil en undtagelse her ikke forårsage en rollback – for der er intet at rulle tilbage endnu. Fra og med Pre-operation stadiet er alle dataændringer (både dem, dit plugin laver, og dem, systemet laver) beskyttet af denne 'alt-eller-intet'-mekanisme.

Sammenligning af Pipeline Stadier

For at give et klart overblik, er her en tabel, der sammenligner de synkrone stadier.

Hvad med Asynkrone Operationer?

Det er også værd at nævne det asynkrone stadie. Når transaktionen er fuldført og gemt (committed), kan systemet sætte en asynkron opgave i kø. Dette sker helt adskilt fra den oprindelige pipeline. Fordelen er, at brugeren ikke skal vente på, at den potentielt langvarige opgave bliver færdig. Ulempen er, at den ikke er en del af transaktionen. Hvis den asynkrone opgave fejler, vil de oprindelige dataændringer ikke blive rullet tilbage.

Eksempler på asynkrone opgaver:

• Sende en bekræftelses-e-mail.
• Integrere med et eksternt system via et API-kald.
• Udføre komplekse beregninger, der tager flere sekunder.

Når Pipelines Kalder Pipelines

En interessant og vigtig situation opstår, når et plugin selv udfører en dataoperation. Forestil dig, at et plugin i Post-operation for en 'Konto'-opdatering opretter en ny 'Kontakt'-post. Denne oprettelse af en kontakt vil starte sin egen, separate plugin-pipeline.

Her er det afgørende at forstå: Fordi den oprindelige 'Konto'-opdatering allerede har startet en databasetransaktion, vil hele den nye 'Kontakt'-pipeline, inklusive dens Pre-validation stadie, køre inden for den oprindelige transaktion. Dette er en undtagelse fra reglen om, at Pre-validation normalt er uden for transaktionen. Det sikrer, at hvis noget går galt under oprettelsen af kontakten, kan hele operationen (både kontoopdateringen og kontaktoprettelsen) rulles tilbage som en samlet enhed.

Ofte Stillede Spørgsmål (FAQ)

Kan jeg ændre data i Pre-validation stadiet?

Ja, det kan du. Du kan modificere de data, der er i hukommelsen (target entity), før de bliver sendt videre til næste stadie. Dette er nyttigt til at rense eller standardisere inputdata.

Hvad sker der, hvis min plugin kaster en undtagelse i Pre-validation?

Hele operationen afbrydes øjeblikkeligt. Ingen databasetransaktion vil blive startet, og ingen data vil blive ændret i systemet. Brugeren vil modtage den fejlmeddelelse, du angiver i din undtagelse.

Hvorfor er Pre-validation uden for databasetransaktionen?

Det er designet sådan af performance-hensyn. Det er meget hurtigere at afvise en ugyldig anmodning, før systemet bruger ressourcer på at starte en transaktion, som alligevel bare skulle annulleres.

Hvornår skal jeg bruge Pre-operation i stedet for Pre-validation?

Brug Pre-operation, når din logik er afhængig af at være en del af 'alt-eller-intet'-transaktionen. Hvis du f.eks. skal opdatere en relateret post og vil være sikker på, at den opdatering rulles tilbage, hvis hovedhandlingen fejler, så skal logikken placeres i Pre-operation eller senere.

Hvordan kan jeg se, om min asynkrone operation er kørt?

Du kan overvåge status for asynkrone operationer i tabellen 'System Jobs' (logisk navn: `asyncoperation`) i Dataverse. Her kan du se, om de er fuldført, venter, eller har fejlet.