Vous pouvez remarquer des problèmes de performances avec les Workflows dans Microsoft Dynamics CRM 4.0 dans un déploiement de grande envergure.
Habituellement, vous aurez déjà ajouté la clé de registre suivante afin de supprimer automatiquement les Workflows complétés.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM
DWORD AsyncRemoveCompletedWorkflows = 1
Cette configuration est tirée de l’article:
« The AsyncOperationBase and WorkflowLogBase tables grow very large and performance issues occur when you use many workflows in Microsoft Dynamics CRM 4.0
KB968755
Cependant, cette clé s’applique seulement aux entrées des tables AsyncOperationBase et WorkflowLogBasequi possèdent un OperationType correspondant à 10. Donc seulement les opérations de type Workflows seront supprimées lorsqu’elles seront complétées.
Pour connaitre le nom d’une opération que vous voyez dans la table AsyncOperationBase, référez-vous au SDK de Microsoft Dynamics CRM, ou en ligne :
AsyncOperationType Class: http://msdn.microsoft.com/en-us/library/bb930133.aspx
AsyncOperationStatus Class: http://msdn.microsoft.com/en-us/library/bb930132.aspx
Il ne faut pas oublier que, le fait de configurer la clé de registre ci-dessus, ne supprime pas les vieilles entrées de la table AsyncOperationBase : elle épure seulement les nouvelles. Ceci dit, si vous configurez cette clé un certain temps après le déploiement, vous devez supprimer des entrées dans AsyncOperationBase. L’article KB968520 explique clairement comment faire le ménage. Cette étape est primordiale!
« Performance is slow if the AsyncOperationBase table becomes too large in Microsoft Dynamics CRM 4.0 »
Malgré tout, vous réaliserez après un certain temps que la table AsyncOperationBase se remplit rapidement et que les performances se dégradent à nouveau malgré la modification expliquée plus haut.
Exécutez d’abord cette requête SQL pour connaitre le nombre d’entrées qui pourraient être supprimées :
USE MicrosoftCRM_MSCRM
GO
SELECT COUNT(AsyncOperationId)
FROM AsyncOperationBase WITH (NOLOCK)
WHERE OperationType in (1, 9, 12, 25, 27, 10)
AND StateCode = 3 AND StatusCode IN (30,32)
Ensuite, pour connaitre le type d’opérations qui peuvent être supprimées :
SELECT OperationType, COUNT(*)
FROM AsyncOperationBase WITH (NOLOCK)
WHERE OperationType in (1, 9, 12, 25, 27, 10)
AND StateCode = 3 AND StatusCode IN (30,32)
GROUP BY OperationType
Avec le KB968755 expliqué plus haut, vous ne devriez pas avoir de résultat pour l’OperationType 10, car il correspond aux Workflows et sont supprimés automatiquement.
Ceci peut répondre à votre besoin si vous utilisez seulement des Workflows. Si vous utilisez les Plugins à grande échelle, ce qui est fort probable, cela ne sera pas suffisant!
Lorsque vous utilisez vigoureusement les plugins que vous avez ajoutés, vous remarquerez beaucoup d’entrées dans la table AsyncOperationBase pour l’OperationType 1. Ce type correspond aux Workflows Expension Tasks ou Events. Par défaut, ces entrées ne sont pas épurées automatiquement. (Bien souvent, même si le DeletionStateCode est changé.)
Pour que les Events soient épurés automatiquement, il faut mettre en place une deuxième clé de registre :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM
DWORD AsyncRemoveCompletedJobs = 1
« The Workflow Expansion Task records cause the AsyncOperationBase table in the MSCRM database to grow too large in Microsoft Dynamics CRM 4.0»
KB957871
Ah oui… j’ose espérer que c’est le cas, mais vous devez au moins avoir mis en place la mise à jour cumulative 3 de Microsoft Dynamics CRM 4.0 pour que les clés de registre soient prises en compte.
Donc en résumé, pour garder performantes les tables utilisées par le service de traitements asynchrones, il faut :
- Avoir bien planifié l’utilisation des Workflows et des Plugins dans CRM 4.0
- Effectuer le ménage initial des tables
- Supprimer automatiquement les Completed Workflows via la clé de registre.
- Supprimer automatiquement les Workflow Expension Tasks via l’autre clé de registre.
- Lire le Optimizing and Maintaining Performance Microsoft Dynamics CRM 4.0
