12/06/2001
En af de første store udfordringer, når man begynder at arbejde med Dynamics CRM plugins, er at få en dyb forståelse for, hvordan udførelseskonteksten (execution context) fungerer. Kort sagt indeholder konteksten al den information, der er relevant for, hvordan og hvornår et plugin eksekveres. Den kan give dig svar på spørgsmål som: Hvilken post udløste dette plugin? Hvilken CRM-bruger startede processen? Man kunne let antage, at konteksten altid indeholder samtlige felter fra den pågældende entitet, men det er desværre ikke tilfældet. Typisk vil en opdateringsanmodning (Update) kun indeholde de felter, der rent faktisk blev ændret. Dette skaber en klassisk hovedpine for udviklere: Hvordan får man adgang til de data, man har brug for, men som ikke er direkte tilgængelige i konteksten?
To Løsninger på et Almindeligt Problem
Når du står i en situation, hvor du har brug for at tilgå felter, der ikke er inkluderet i konteksten, har du grundlæggende to muligheder. Disse to metoder har hver deres fordele og ulemper, og valget mellem dem kan have stor betydning for dit systems ydeevne og vedligeholdelse.

1. Den Traditionelle Metode: Retrieve-anmodningen
Den mest almindelige og ofte først lærte metode er at hente en reference til Organisation Service i dit plugin og derefter bruge en Retrieve-anmodning til at hente de specifikke felter, du mangler. Da konteksten altid indeholder GUID'et for den post, der er blevet ændret, er dette en relativt ligetil operation. Ulempen er dog, at det introducerer et ekstra servicekald til databasen for hver eksekvering af dit plugin. På et system med høj belastning kan mange af disse ekstra kald hurtigt blive en flaskehals og forringe den generelle systemydelse markant.
2. Den Elegante Metode: Pre- og Post-Entity Images
En mere avanceret og ofte overset metode er at anvende enten et Pre- eller Post-Entity Image. Et Entity Image er i bund og grund et øjebliksbillede (snapshot) af en CRM-post, som platformen gemmer enten lige før (Pre-Image) eller lige efter (Post-Image) databasehandlingen er fuldført. Disse 'billeder' konfigureres, når du registrerer dit plugin, og giver dig direkte adgang til de feltværdier, du har brug for, uden at skulle foretage et ekstra servicekald.
Fordelene ved at Bruge Entity Images
Hvorfor skulle man så gøre sig den ekstra umage at konfigurere og bruge Entity Images? Fordelene er betydelige og kan gøre dit arbejde både lettere og mere effektivt.
- Før-og-efter sammenligninger: Med Pre-Entity Images får du et snapshot af data, før de blev ændret. Dette er uundværligt i scenarier, hvor du skal sammenligne en gammel værdi med en ny og udføre en handling baseret på resultatet. Den eneste alternative løsning ville være at bruge et skjult felt til at gemme den gamle værdi, hvilket er en klodset og mindre elegant løsning.
- Forbedret ydeevne: Den mest markante fordel er undgåelsen af ekstra
Retrieve-kald. Ved at have de nødvendige data tilgængelige direkte i konteksten via et image, reducerer du belastningen på CRM's webtjenester. Dette kan forhindre unødvendige forsinkelser i dit plugin og bidrage til en mere stabil og responsiv platform. - Renere kode: Din kode bliver mere logisk og lettere at læse, da du ikke skal inkludere logik til at hente yderligere data. Du kan blot tilgå Pre- eller Post-Image-samlingerne direkte fra konteksten.
Er der en Hage? Begrænsninger og Vigtige Overvejelser
Selvom Entity Images er et kraftfuldt værktøj, er der et par ting, du skal være opmærksom på.
- Besked-specifikke begrænsninger: Ikke alle plugin-beskeder (messages) understøtter images. Som en logisk konsekvens kan du ikke få et Pre-Image på en
Create-besked (da posten ikke eksisterede før), og du kan heller ikke få et Post-Image på enDelete-besked (da posten ikke længere eksisterer efter). - Understøttede beskeder: De mest almindelige beskeder, der understøtter begge typer images, er
Update,Assign,SetStateogMerge. - Manuel konfiguration: Det er afgørende at huske, at du manuelt skal registrere hvert image i Plugin Registration Tool. Selvom du refererer til et image i din kode, vil det ikke eksistere under kørsel, medmindre det er korrekt konfigureret. Glemmer du dette, vil dit plugin fejle med en `KeyNotFoundException`.
Sammenligningstabel: Retrieve-anmodning vs. Entity Image
| Egenskab | Retrieve-anmodning | Entity Image |
|---|---|---|
| Ydeevne | Lavere (kræver ekstra databasekald) | Højere (data er allerede i konteksten) |
| Adgang til 'før'-tilstand | Nej (henter kun den aktuelle tilstand) | Ja (via Pre-Entity Image) |
| Implementering i kode | Kræver opsætning af service-klient og kald | Direkte adgang fra kontekst-objektet |
| Konfiguration | Ingen ekstra konfiguration nødvendig | Kræver manuel opsætning i Plugin Registration Tool |
| Typisk Anvendelse | Når komplekse, relaterede data skal hentes | Før/efter-logik, adgang til uændrede felter |
Praktisk Implementering: Trin-for-Trin Guide
Lad os se på, hvordan man implementerer Pre- og Post-Images. Eksemplet herunder vil sammenligne værdien af feltet 'Firmanavn' (companyname) på en Lead-entitet før og efter en opdatering. Hvis værdien er ændret, sendes en e-mail til en salgschef.
Trin 1: Koden i dit Plugin
I din plugin-kode skal du først hente konteksten. Derefter kan du tjekke, om Pre- og Post-Entity Image-samlingerne indeholder dit registrerede image. Koden til at hente værdierne kan se således ud:
// Hent Pre- og Post-images fra konteksten Entity preLead = context.PreEntityImages["Image"]; Entity postLead = context.PostEntityImages["Image"]; // Hent den specifikke feltværdi fra hvert image string preCompanyName = preLead.GetAttributeValue<string>("companyname"); string postCompanyName = postLead.GetAttributeValue<string>("companyname"); // Sammenlign værdierne og udfør handling if (preCompanyName != postCompanyName) { // Din logik for at sende en e-mail eller udføre en anden handling her }Bemærk, at "Image" er det alias, vi giver vores image under konfigurationen. Det er afgørende, at dette navn matcher præcist.
Trin 2: Registrering i Plugin Registration Tool
Når din kode er bygget og implementeret, skal du konfigurere den i Plugin Registration Tool.
- Registrer dit plugin og opret et nyt trin (step) som normalt. Sørg for at vælge den korrekte besked (f.eks.
Update) og den primære entitet (f.eks.lead). - Højreklik på det trin, du lige har oprettet, og vælg "Register New Image".
- Et nyt vindue åbnes. Her skal du konfigurere både dit Pre- og Post-Image.
Trin 3: Konfiguration af dine Images
I konfigurationsvinduet skal du angive følgende:
- Image Type: Vælg både Pre Image og Post Image.
- Name: Angiv et navn. Det er god praksis at bruge det samme som Entity Alias.
- Entity Alias: Dette er det vigtigste felt. Det er det navn/den nøgle, du bruger i din kode til at hente imaget (i vores eksempel: "Image"). Det skal matche 100%.
- Parameters: Her angiver du, hvilke attributter (felter) der skal inkluderes i dit image. Som standard er alle felter inkluderet, men for optimal ydeevne bør du kun vælge de felter, du rent faktisk har brug for i din plugin-logik. I vores eksempel ville vi kun vælge feltet `companyname`.
Når alt er sat op, kan du teste dit plugin. Når en brugere ændrer firmanavnet på en Lead, vil dit plugin blive udløst, sammenligne de gamle og nye værdier og udføre den definerede handling.
Ofte Stillede Spørgsmål (OSS)
Kan jeg bruge Entity Images til alle typer plugin-beskeder?
Nej, det kan du ikke. Som nævnt er der begrænsninger. Du kan ikke få et Pre-Image på en `Create`-besked eller et Post-Image på en `Delete`-besked. De er primært designet til beskeder som `Update`, `Assign`, og `SetState`, hvor en eksisterende post ændres.
Hvad sker der, hvis jeg glemmer at konfigurere et Image i Plugin Registration Tool?
Dit plugin vil fejle under kørsel. Når din kode forsøger at tilgå `context.PreEntityImages["DitAlias"]`, vil den kaste en `KeyNotFoundException`, fordi nøglen "DitAlias" ikke findes i samlingen. Dette er en af de mest almindelige fejlkilder, når man arbejder med images for første gang.
Er det bedre kun at vælge de felter, jeg har brug for i "Parameters"?
Ja, absolut. Selvom det er nemt at vælge "All Attributes", er det en klar best practice kun at specificere de felter, du har brug for. Dette minimerer den mængde data, der skal behandles og gemmes i konteksten, hvilket bidrager til en bedre overordnet ydeevne.
Kan jeg have mere end ét Pre- eller Post-Image for det samme trin?
Ja, det kan du godt. Du kan registrere flere images med forskellige Entity Alias-navne og forskellige sæt af attributter. Dette kan være nyttigt i komplekse plugins, hvor forskellige dele af din logik kræver adgang til forskellige datasæt.
Konklusion: Et Kraftfuldt Værktøj i din Værktøjskasse
Entity Images er et fantastisk værktøj, der har sin tid og sit sted. Hvis du har brug for at hente data fra relaterede poster, er en Retrieve-anmodning stadig den eneste vej frem. Men i de mange tilfælde, hvor du blot har brug for adgang til flere felter på den post, der udløste plugin'et, eller har brug for at udføre før/efter-logik, er Entity Images en langt mere effektiv og elegant løsning. De reducerer unødvendig systembelastning, gør din kode renere og kan spare dig for betydelig udviklingstid. Enhver seriøs CRM-udvikler bør gøre sig bekendt med dem og aktivt overveje at bruge dem, hvor det er muligt.
Hvis du vil læse andre artikler, der ligner Optimer dine CRM Plugins med Entity Images, kan du besøge kategorien Sundhed.
