Plug-in ou Workflow dans Dynamics CRM 4.0 ?

Plusieurs blogs et MVP indiquent sur Internet les raisons d'opter pour un plug-in ou un workflow dans Dynamics CRM 4.0. Les indications généralement précisées sont une explication de texte du guide d'implémentation de la solution et je pense que lors d'une première approche technique, on peut les résumer à ceci.

• Le workflow est issu d'un paramétrage accessible depuis l'interface tandis que le plug-in est un développement spécifique réalisé et mis en place par un développeur.
• Le workflow est déclenché par quelques événements simples (création, suppression, mise à jour d'un champ, réaffectation à un nouveau propriétaire, changement de statut ou une action manuelle) tandis que le plug-in pourra être déclenché par tout événement supporté par le SDK (par exemple, l'ajout ou la suppression d'un contact dans une liste marketing).
• Le workflow pourra créer, mettre à jour et affecter un enregistrement tandis que le plug-in ne sera limité que par le SDK.
• Le workflow est exécuté sur le serveur CRM uniquement tandis que le plug-in peut aussi s'exécuter sur le poste client (en mode offline).
• Le workflow est toujours asynchrone tandis que le plug-in peut être synchrone ou asynchrone.

Si tout cela semble simple, il existe néanmoins des pièges et la lecture récente du blog d'un MVP me donne l'occasion de le prouver ici. Ce MVP recommande tout d'abord d'utiliser la "condition d'attente" des workflows pour générer des alertes en fonction d'une date de fin modifiable par l'utilisateur : l'événement permettant de générer ce workflow est la mise à jour de cette date. Cette condition d'attente est en effet une fonctionnalité puissante et innovante de Dynamics CRM et a priori, l'idée du MPV est bonne et logique.
Mais, le MVP indique ensuite qu'une fois le workflow lancé, si la date de fin est modifiée, alors le workflow plante et reste en stand-by indéfiniment, tandis qu'un nouveau workflow est généré. Au final, le MVP recommande donc d'ajouter un développement spécifique (une dll associée au workflow) pour stopper le workflow devenu inutile !
A mon avis, 3 erreurs sont faites ici.

• Même s'il le précise, ce MVP ne tient pas réellement compte du fait que tout workflow en stand-by consomme une partie des ressources du serveur. Si la condition d'attente est longue et si le nombre de workflow risque d'être important, alors l'architecture doit être prévue en conséquence ou ce type de fontionnalité ne doit pas être utilisée.
• Dès lors qu'il n'y a pas besoin de tenir compte immédiatement de la date de fin mentionnée (par exemple, l'envoi immédiat d'un email de confirmation), il n'y a pas lieu de générer une action sur l'événement de mise à jour de cette date (création du workflow). Il suffit d'avoir un batch qui surveille régulièrement cette date et génère l'action appropriée au bon moment. Ainsi, le problème de la mise à jour de la date disparait.
• Un développement spécifique (ici, le batch) peut néanmoins laisser quelques éléments de paramétrage accessibles à l'utilisateur ou à l'administrateur. Ainsi, s'il faut générer un mail de relance 3 jours avant la date de fin, il suffit de placer ce paramètre 3 dans l'interface d'administration du CRM de sorte que le développement spécifique reste souple et que l'utilisateur ou l'administrateur peuvent le faire évoluer facilement.

Lors de la spécification d'un projet et de son chiffrage, je propose donc de compléter ma première liste comparative par une approche pragmatique pour justifier le choix d'un workflow.

• Le workflow peut être lancé manuellement, créé et mis à jour rapidement par l'utilisateur. Si l'utilisateur ou l'administrateur a besoin de cela, alors un workflow est préférable.
• Le workflow n'est pas coûteux à mettre en oeuvre. Si le budget ou si les ressources techniques sont limitées, le choix d'un workflow est préférable.
• L'exécution des workflows peut être surveillée (les étapes, les conditions ...) via l'interface, via la mise à jour de statuts et via des rapports.
• Le workflow tient compte nativement des droits d'accès de l'utilisateur.
• Le workflow manuel permet de faciliter des mises à jour en masse d'une sélection d'enregistrement (notamment sur des champs non modifiables par l'utilisateur).

Mais les workflows ont aussi leurs défauts, que le plug-in permet de contourner.

• La création et mise à jour d'un enregistrement par workflow n'indiquent pas le nom de l'utilisateur courant ayant généré l'action. Par exemple, le nom du dernier modificateur sera le nom du propriétaire du workflow, ce qui est gênant si les mises à jour sont tracées.
• Le workflow est toujours asynchrone : l'utilisateur ne voit donc pas immédiatement les mises à jour.
• Le workflow n'est pas capable de mettre à jour une liste d'enregistrement associés : par exemple, si l'adresse d'une société change, les adresses des contacts associés ne pourront pas être mises à jour par workflow.
• Le workflow peut récupérer toute les données de l'enregistrement en cours et des enregistrements associés par un lien de 1 à N uniquement. En clair, généré depuis un contact, le workflow peut récupérer l'adresse de la société du contact mais aucune donnée en provenance d'un des incidents associés à ce contact.
• Le workflow ne s'exécute que sur le serveur, les actions ne sont pas disponibles en mode offline.
• Tracer un changement et historiser les mises à jour par workflow est complexe alors que le plug-in est nativement capable de comparer les données avant et après la mise à jour de l'enregistrement.

Pour finir, en ce qui concerne les développements spécifiques, j'ajoute qu'ils permettent d'enrichir prodigieusement les workflows (ajout d'activités) et de créer par exemple des interfaces entre applications, notamment SharePoint et les ERP. Tandis qu'il est tout à fait possible d'ajouter des paramètres dans l'interface d'administration du CRM pour rendre les plug-ins et les batchs souples et réduire leurs charges de mise à jour.
En ce qui concerne les workflows, je recommande l'article du MVP Donna Edwards pour bien les paramétrer afin d'éviter que ceux-ci ne tombent en erreur.