Que sont les plugins et à quoi servent-ils ?
Les plugins Dynamics 365 sont des composants de logique métier personnalisés qui s'exécutent côté serveur dans le cadre de l'événementiel. Ils agissent comme des gestionnaires d'événements qui s'exécutent en réponse à des opérations de données spécifiques telles que Créer, Mettre à jour, Supprimer ou des actions personnalisées. Les plugins vous permettent d'étendre les fonctionnalités natives de Dynamics 365 sans modifier la plateforme principale. documentation officielle des plugins.
Pensez aux plugins comme des intercepteurs qui se situent entre la requête de l'utilisateur et la transaction de base de données. Lorsqu'un utilisateur crée un enregistrement de compte, votre plugin peut valider les données, les enrichir avec des informations provenant de systèmes externes, déclencher des workflows, ou empêcher complètement l'opération en fonction des règles métier.
Cas d'usage courants
- Validation des données : Appliquer des règles métier complexes qui dépassent la validation standard des champs
- Enrichissement des données : Remplir automatiquement les champs basés sur des calculs ou des sources de données externes
- Intégration : Synchroniser les données avec des systèmes externes comme ERP, plateformes marketing ou bases de données héritées
- Automatisation : Déclencher des processus complexes en plusieurs étapes qui ne peuvent pas être gérés par les workflows seuls
- Audit : Créer des pistes d'audit personnalisées ou des journaux de conformité au-delà des fonctionnalités standard
Le pipeline d'exécution des événements
Le pipeline d'exécution des événements est le cœur de l'architecture des plugins. Chaque opération de données dans Dynamics 365 passe par une série d'étapes, et les plugins peuvent s'enregistrer sur des étapes spécifiques pour intercepter et modifier l'opération. cadre événementiel.
Étapes du pipeline
Étape 10 : PreValidation
S'exécute en dehors de la transaction de base de données. Idéal pour les opérations qui ne nécessitent pas de capacité de rollback ou lorsque vous devez échouer rapidement avant des opérations coûteuses. Utilisez ceci pour une validation légère ou des données qui ne feront pas partie de la transaction.
Étape 20 : PreOperation
S'exécute à l'intérieur de la transaction de base de données, avant l'opération principale. C'est là que réside la plupart de la logique métier. Vous pouvez modifier l'entité cible, effectuer des calculs ou appeler des services externes. Les modifications effectuées ici sont incluses dans la transaction.
Étape 30 : MainOperation
Réservé à l'usage interne de la plateforme. Les développeurs ne peuvent pas enregistrer de plugins personnalisés sur cette étape.
Étape 40 : PostOperation
S'exécute à l'intérieur de la transaction de base de données, après que l'opération principale soit terminée. Utilisez ceci lorsque vous avez besoin du GUID de l'enregistrement (pour les opérations de création) ou lorsque vous devez effectuer des opérations basées sur les valeurs finales validées. Idéal pour déclencher des mises à jour d'enregistrements liés ou appeler des systèmes externes.
Comprendre les messages
Les messages représentent les opérations spécifiques que vous interceptez. Les messages courants incluent Créer, Mettre à jour, Supprimer, Récupérer, RécupérerMultiple, et de nombreuses opérations spécialisées comme Fusionner, Assigner ou DéfinirÉtat. référence des messages d'entité.
Chaque message a un contexte spécifique et des données disponibles. Par exemple, le message Créer fournit l'accès à l'entité cible en cours de création, tandis que Mettre à jour fournit à la fois la cible (attributs modifiés uniquement) et l'enregistrement complet via les images.
Considérations critiques sur les messages
- Message de mise à jour : Ne contient que les attributs modifiés dans la Cible. Utilisez les images pour accéder aux champs non modifiés.
- Message de suppression : Reçoit une EntityReference dans la Cible, pas un objet Entity complet.
- Actions personnalisées : Peuvent avoir des paramètres d'entrée/sortie accessibles via context.InputParameters et context.OutputParameters.
- Attributs filtrés : Peuvent enregistrer un plugin pour se déclencher uniquement lorsque des attributs spécifiques changent, réduisant les exécutions inutiles.
Pre-Image et post-image : votre machine à remonter le temps
Les images d'entité sont des instantanés de l'enregistrement à différents points du pipeline. Elles sont absolument critiques pour les scénarios de mise à jour où vous devez comparer les anciennes et nouvelles valeurs ou accéder aux champs qui n'ont pas été modifiés. images d'entité et contexte d'exécution.
Pre-Image (Image Avant)
Un instantané de l'enregistrement avant l'opération. Disponible dans les étapes PreOperation et PostOperation pour les opérations de mise à jour et de suppression. Utilisez les pre-images pour :
- Comparer les anciennes vs nouvelles valeurs pour détecter des changements spécifiques
- Accéder aux champs qui n'étaient pas inclus dans le message de mise à jour
- Préserver les valeurs originales pour la logique d'audit ou de rollback
- Prendre des décisions basées sur l'état précédent
Post-Image (Image Après)
Un instantané de l'enregistrement après l'opération. Uniquement disponible dans l'étape PostOperation. Contient l'état fusionné de tous les changements incluant les valeurs par défaut, les champs calculés et les valeurs remplies par le système. Utilisez les post-images pour :
- Accéder à l'état final complet de l'enregistrement
- Obtenir les valeurs générées par le système comme CreatedOn ou ModifiedBy
- Lire les valeurs des champs calculés ou de cumul
- Déclencher la logique basée sur l'état validé
⚠️ Conseil de performance :
Sélectionnez toujours des attributs spécifiques lors de l'enregistrement des images au lieu de récupérer toutes les colonnes. Chaque image nécessite une requête de base de données, donc minimisez l'impact sur les performances en ne demandant que ce dont vous avez besoin.
Exécution synchrone vs asynchrone
Plugins synchrones
S'exécutent immédiatement et bloquent l'opération de l'utilisateur jusqu'à la fin. L'interface utilisateur affiche un indicateur de chargement et attend que votre plugin termine. Les plugins synchrones s'exécutent dans la même transaction de base de données que l'opération déclencheuse.
Quand utiliser synchrone :
- Validation des données qui doit empêcher l'opération
- Modifications des données de l'opération en cours
- Opérations qui doivent se terminer avant que l'utilisateur continue
- Opérations rapides (moins de 2 secondes de temps d'exécution)
Limitations :
- Limite de timeout de 2 minutes avant terminaison automatique
- Mauvaise expérience utilisateur si les opérations sont lentes
- Ne peut pas valider un travail partiel - transaction tout ou rien
Plugins asynchrones
S'exécutent en arrière-plan en utilisant la file d'attente System Job (AsyncOperation). L'opération de l'utilisateur se termine immédiatement, et le plugin traite séparément. Les plugins asynchrones échoués peuvent être automatiquement réessayés.
Quand utiliser asynchrone :
- Opérations de longue durée (rapports, mises à jour en masse, appels API externes)
- Opérations non critiques qui peuvent tolérer des délais
- Scénarios d'intégration où une réponse immédiate n'est pas requise
- Opérations sujettes à des échecs transitoires qui bénéficient d'une logique de réessai
Considérations :
- Pas de temps d'exécution garanti - dépend de la profondeur de la file d'attente
- Ne peut pas modifier les données de l'opération déclencheuse
- Doit gérer les cas où l'enregistrement original a changé ou a été supprimé
- PreImage/PostImage sont persistées mais consomment du stockage
Bonnes pratiques d'enregistrement des plugins
Ordre d'exécution et classement
Lorsque plusieurs plugins s'enregistrent sur le même message et la même étape, l'ordre d'exécution est déterminé par la valeur d'Ordre d'Exécution (Rang). Les nombres plus bas s'exécutent en premier. Documentez toujours pourquoi un ordre spécifique est requis. Outil d'enregistrement des plugins.
Filtrage des attributs
Pour les messages de mise à jour, spécifiez toujours les attributs filtrés pour éviter les exécutions inutiles de plugins. Votre plugin ne se déclenche que lorsque ces attributs spécifiques sont modifiés, améliorant considérablement les performances.
Déploiement
- Utilisez le mode d'isolation : sandbox (requis pour les environnements en ligne)
- Signez les assemblies avec une clé de nom fort
- Déployez via des Solutions pour une gestion ALM et un contrôle de version appropriés guide ALM
- Testez en progression développement → UAT → production
- Ne déployez jamais directement en production sans tests
Gestion des erreurs et sécurité
Lancez toujours InvalidPluginExecutionException pour les erreurs attendues avec des messages conviviaux. Laissez les exceptions inattendues remonter naturellement - elles seront automatiquement journalisées. Utilisez le service de traçage pour le débogage, mais n'exposez jamais d'informations sensibles dans les messages d'erreur. bonnes pratiques des plugins.
Les plugins s'exécutent dans le contexte de sécurité de l'utilisateur appelant par défaut. Utilisez l'impersonnation avec parcimonie et uniquement lorsque vous avez besoin de privilèges au niveau système. Validez et assainissez toujours les données provenant des entrées utilisateur. impersonnation dans les plugins.
Conclusion
Maîtriser le développement de plugins Dynamics 365 nécessite une compréhension approfondie du pipeline d'événements, du contexte d'exécution et des contraintes de la plateforme. En choisissant la bonne étape, le bon mode et les bonnes options d'enregistrement, vous pouvez construire des solutions efficaces et maintenables qui étendent parfaitement les capacités de Dynamics 365. Priorisez toujours les performances, gérez les erreurs avec élégance et testez minutieusement dans des environnements isolés avant de déployer en production.