Plugins ontwikkelen voor Dynamics 365: de basis goed

Wat zijn plugins en waarom zijn ze nodig?

Dynamics 365-plugins zijn componenten met eigen bedrijfslogica die server-side draaien binnen het event framework. Ze fungeren als event handlers die worden uitgevoerd als reactie op specifieke gegevensbewerkingen zoals Create, Update, Delete of aangepaste acties. Met plugins breidt u de standaardfunctionaliteit van Dynamics 365 uit zonder het kernplatform aan te passen. officiële plugindocumentatie.

Zie plugins als interceptors tussen het verzoek van de gebruiker en de databasetransactie. Wanneer een gebruiker een accountrecord aanmaakt, kan uw plugin de gegevens valideren, verrijken met informatie uit externe systemen, workflows starten of de bewerking volledig tegenhouden op basis van bedrijfsregels.

Veelvoorkomende toepassingen

• Gegevensvalidatie: Complexe bedrijfsregels afdwingen die de standaard veldvalidatie overstijgen
• Gegevensverrijking: Velden automatisch invullen op basis van berekeningen of externe gegevensbronnen
• Integratie: Gegevens synchroniseren met externe systemen zoals ERP, marketingplatforms of legacydatabases
• Automatisering: Complexe processen met meerdere stappen starten die workflows alleen niet aankunnen
• Auditing: Eigen audittrails of compliancelogging opzetten die verder gaan dan de standaardfuncties

De event execution pipeline

De event execution pipeline is het hart van de pluginarchitectuur. Elke gegevensbewerking in Dynamics 365 doorloopt een reeks fasen, en plugins kunnen zich op specifieke fasen registreren om de bewerking te onderscheppen en aan te passen. event framework.

Fasen van de pipeline

Berichten (messages) begrijpen

Berichten staan voor de specifieke bewerkingen die u onderschept. Veelvoorkomende berichten zijn Create, Update, Delete, Retrieve en RetrieveMultiple, plus heel wat gespecialiseerde bewerkingen zoals Merge, Assign of SetState. referentie van entiteitsberichten.

Elk bericht heeft een eigen context en eigen beschikbare gegevens. Het Create-bericht geeft bijvoorbeeld toegang tot de doelentiteit die wordt aangemaakt, terwijl Update zowel het doel (alleen de gewijzigde attributen) als het volledige record via images aanlevert.

Belangrijke aandachtspunten per bericht

• Update-bericht: Bevat in de Target alleen de gewijzigde attributen. Gebruik images om ongewijzigde velden te lezen.
• Delete-bericht: Ontvangt een EntityReference in de Target, geen volledig Entity-object.
• Aangepaste acties: Kunnen invoer- en uitvoerparameters hebben, toegankelijk via context.InputParameters en context.OutputParameters.
• Gefilterde attributen: U kunt een plugin zo registreren dat hij alleen afgaat wanneer specifieke attributen wijzigen, wat onnodige uitvoeringen beperkt.

Pre-image en post-image: uw tijdmachine

Entity images zijn momentopnamen van het record op verschillende punten in de pipeline. Ze zijn onmisbaar in Update-scenario's waarin u oude en nieuwe waarden moet vergelijken of velden nodig hebt die niet zijn gewijzigd. entity images en execution context.

Pre-image (vóór de bewerking)

Een momentopname van het record vóór de bewerking. Beschikbaar in de fasen PreOperation en PostOperation voor Update- en Delete-bewerkingen. Gebruik pre-images om:

• oude en nieuwe waarden te vergelijken en specifieke wijzigingen te detecteren
• velden te lezen die niet in het Update-bericht zaten
• oorspronkelijke waarden te bewaren voor audit- of rollbacklogica
• beslissingen te nemen op basis van de vorige toestand

Post-image (na de bewerking)

Een momentopname van het record na de bewerking. Alleen beschikbaar in de fase PostOperation. Bevat de samengevoegde toestand van alle wijzigingen, inclusief standaardwaarden, berekende velden en waarden die het systeem invult. Gebruik post-images om:

• de volledige eindtoestand van het record te lezen
• door het systeem gegenereerde waarden zoals CreatedOn of ModifiedBy op te halen
• waarden van berekende of rollupvelden te lezen
• logica te starten op basis van de vastgelegde toestand

Synchrone versus asynchrone uitvoering

Synchrone plugins

Worden onmiddellijk uitgevoerd en blokkeren de bewerking van de gebruiker tot ze klaar zijn. De gebruikersinterface toont een laadindicator en wacht tot uw plugin klaar is. Synchrone plugins draaien in dezelfde databasetransactie als de bewerking die ze start.

Wanneer kiest u synchroon:

• Gegevensvalidatie die de operatie moet voorkomen
• Wijzigingen aan de gegevens van de huidige operatie
• Bewerkingen die klaar moeten zijn voordat de gebruiker verdergaat
• Snelle bewerkingen (minder dan 2 seconden uitvoeringstijd)

Beperkingen:

• Time-out van 2 minuten, waarna de uitvoering automatisch wordt afgebroken
• Slechte gebruikerservaring als bewerkingen traag zijn
• Geen gedeeltelijke commit mogelijk: de transactie slaagt volledig of helemaal niet

Asynchrone plugins

Worden op de achtergrond uitgevoerd via de wachtrij voor systeemtaken (AsyncOperation). De bewerking van de gebruiker wordt meteen voltooid en de plugin werkt apart verder. Mislukte asynchrone plugins kunnen automatisch opnieuw worden uitgevoerd.

Wanneer kiest u asynchroon:

• Langlopende bewerkingen (rapporten, bulkupdates, externe API-aanroepen)
• Niet-kritieke bewerkingen die vertraging verdragen
• Integratiescenario's waarin geen onmiddellijk antwoord nodig is
• Bewerkingen die gevoelig zijn voor tijdelijke fouten en baat hebben bij retrylogica

Overwegingen:

• Geen gegarandeerde uitvoeringstijd: hangt af van de lengte van de wachtrij
• Kan de gegevens van de startende bewerking niet meer wijzigen
• Moet rekening houden met een oorspronkelijk record dat intussen gewijzigd of verwijderd is
• PreImage/PostImage worden bewaard, maar verbruiken opslag

Best practices voor pluginregistratie

Uitvoeringsvolgorde en rangorde

Wanneer meerdere plugins op hetzelfde bericht en dezelfde fase geregistreerd zijn, bepaalt de waarde Execution Order (rang) de volgorde. Lagere nummers worden eerst uitgevoerd. Documenteer altijd waarom een specifieke volgorde nodig is. Plugin Registration Tool.

Filterattributen

Geef bij Update-berichten altijd filterattributen op om onnodige plugin-uitvoeringen te vermijden. Uw plugin gaat dan alleen af wanneer precies die attributen wijzigen, wat de prestaties sterk verbetert.

Deployment

• Gebruik isolatiemodus Sandbox (verplicht voor online omgevingen)
• Onderteken assemblies met een strong-name key
• Rol uit via solutions voor degelijke ALM en versiebeheer ALM-richtlijnen
• Test in de volgorde ontwikkeling → UAT → productie
• Rol nooit rechtstreeks uit naar productie zonder te testen

Foutafhandeling en beveiliging

Gooi voor verwachte fouten altijd een InvalidPluginExecutionException met een duidelijke melding voor de gebruiker. Laat onverwachte exceptions gewoon doorstromen: ze worden automatisch gelogd. Gebruik de tracing service om te debuggen, maar toon nooit gevoelige informatie in foutmeldingen. best practices voor plugins.

Plugins draaien standaard in de beveiligingscontext van de aanroepende gebruiker. Gebruik impersonatie spaarzaam en alleen wanneer u privileges op systeemniveau nodig hebt. Valideer en zuiver altijd gegevens die uit gebruikersinvoer komen. impersonatie in plugins.

Conclusie

Wie plugins voor Dynamics 365 goed wil ontwikkelen, moet de event pipeline, de execution context en de beperkingen van het platform grondig begrijpen. Door de juiste fase, uitvoeringsmodus en registratieopties te kiezen, bouwt u efficiënte, onderhoudbare oplossingen die de mogelijkheden van Dynamics 365 naadloos uitbreiden. Geef altijd voorrang aan prestaties, handel fouten netjes af en test grondig in afgeschermde omgevingen voordat u naar productie uitrolt.