Suggestion de rapport pour la gestion de Microsoft Dynamics CRM 4.0 – Partie 3

Voici une troisième suggestion de rapport. Ce type de rapport peut être développé facilement à l’aide Microsoft SQL Server Report Builder, sans connaissances poussées en développement. Cependant, les requêtes T-SQL pour puiser et filtrer les données sont plus complexes que celles utilisées pour les deux rapports précédents. Cela demande également une connaissance particulière de la structure de la base de donnée de CRM.

Ce rapport aborde un tout autre volet. Dans Microsoft Dynamics CRM 4.0, vous avez la possibilité d’enregistrer une quantité remarque de plugins. Lorsque vous mettez en place un déploiement très personnalisé, la liste de plugins peut devenir longue et difficile à gérer. Le Plugin Registration Tools pour Microsoft Dynamics CRM vous présente certes la liste des plugins d’une façon complète, mais peu conviviale à des fins de références. Le rapport à donc comme but d’afficher d’une façon compréhensible la liste des plugins enregistrés dans Microsoft Dynamics CRM.

Voici comment vous pourriez filtrer les données à afficher :

Par entités sur lesquelles les plugins sont branchés :

Selon le mode du plugin, Synchrone ou Asynchrone. Notez qu’il existe d’autres modes, dans ce cas-ci, ils sont inclus dans (Select All)

Selon l’état du plugin : Activé ou Désactivé. Intéressant d’avoir la liste de plugins qui ont été désactivés, par exemple lors d’essais.

Un tel rapport pourrait, par exemple, vous permettre de :

• Connaitre la liste complète des plugins enregistrés dans Microsoft Dynamics CRM. Le Plugin Registration Tools ne présente pas les plugins systèmes par exemple.
• Suivre l’évolution des plugins et garder un historique au besoin.
• Repérer facilement des plugins qui auraient été désactivés.

Voici un exemple de présentation du rapport :

L’exemple ci-dessus ne contient que des plugins natifs. Si vous avez enregistré des plugins personnalisés, vous les remarquerez facilement par l’Assembly Name ou la Description.

Pour générer un tel rapport, vous devrez puiser les données dans la base de données suivante :

• <Organisation>_MSCRM

Et utiliser les tables suivantes :

• EntityView
• PluginType
• SdkMessage
• SdkMessageFilter
• SdkMessageProcessingStep

Colonnes utilisées pour les filtres:

• EntityView.PhysicalName
• SdkMessageProcessingStep.Mode
• SdkMessageProcessingStep.StateCode
• PluginType.AssemblyName

Ce rapport, bien que plus complexe à mettre en place, facilitera votre gestion de Microsoft Dynamics CRM.

Suggestion de rapport pour la gestion de Microsoft Dynamics CRM 4.0 – Partie 2

Voici la deuxième suggestion de rapport. Ce type de rapport peut être développé facilement à l’aide Microsoft SQL Server Report Builder, sans connaissances poussées en développement.

Ce rapport complète le premier. Il vous permet de connaitre le résultat des demandes d’exécution de rapport. Encore une fois, les données affichées sont filtrées selon une plage de temps afin de pouvoir comparer des plages des temps.

Un tel rapport pourrait, par exemple, vous permettre de :

• Connaître le résultat exact des demandes, selon le rapport.
• Connaître les rapports qui prennent trop de temps à être générés : Timeout.
• Obtenir de l’information sur les niveaux de service
• Repérer les problèmes suite à la mise à jour d’un rapport.

Voici un exemple de présentation du rapport :

Pour générer un tel rapport, vous devrez puiser les données dans la base de données suivante :

• ReportServer

Et utiliser les tables suivantes :

• ExecutionLog
• Catalog

Colonnes utilisées pour le filtre:

• ExecutionLog.TimeStart
• ExecutionLog.TimeEnd

Ce rapport facile à mettre en place facilitera votre gestion de Microsoft Dynamics CRM.

Suggestion de rapport pour la gestion de Microsoft Dynamics CRM 4.0 – Partie 1

Voici une première suggestion de rapport. Ce type de rapport peut être développé facilement à l’aide Microsoft SQL Server Report Builder, sans connaissances poussées en développement.

Dans cet exemple, vous trouverez le temps d’exécution pour chacune de vos demandes de  rapports. Les données affichées sont filtrées selon une plage de temps. Il est donc facile de comparer une journée avec une autre, une semaine avec une autre, un mois avec un autre… vous comprenez le principe.

Un tel rapport pourrait, par exemple, vous permettre de :

• Connaître le temps moyen d’exécution, selon le rapport.
• Connaître les rapports qui consomment le plus de ressources au niveau de la base de données.
• Obtenir de l’information sur les niveaux de service
• Confirmer l’amélioration ou la dégradation de performance suite à la mise à jour d’un rapport.
• Repérer le traitement d’exécution d’un rapport qui consomme le plus de temps, en millisecondes : DataRetrieval, Rendering ou Processing.

Voici un exemple de présentation du rapport :

Pour générer un tel rapport, vous devrez puiser les données dans la base de données suivante :

• ReportServer

Et utiliser les tables suivantes :

• ExecutionLog
• Catalog

Colonnes utilisées pour le filtre:

• ExecutionLog.TimeStart
• ExecutionLog.TimeEnd

Ce rapport facile à mettre en place facilitera votre gestion de Microsoft Dynamics CRM.

Microsoft Dynamics CRM 4.0 Update Rollup 8

Juste à temps pour les fêtes!

La mise à jour cumulative 8 de Microsoft Dynamics CRM est sortie depuis peu.

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=c53b2916-6b93-4092-bdd3-a394c96ca000

Cette fois-ci, tous les composants sont disponibles:

• Server
• Email Router
• Data Connector
• Client Outlook
• MUI
• Data Migration Manger

“Although Microsoft Office 2010 is still in beta and is not officially supported, Microsoft Dynamics CRM 4.0 was tested together with Microsoft Office 2010. Additionally, issues can be logged by the Microsoft Dynamics CRM Support team. However, the hotfix to resolve the issues may not be available until Microsoft Office 2010 releases. Office 2010 64-bit versions will not be supported in Microsoft Dynamics CRM 4.0.”

CRM 4.0 sur Office Outlook 2010 Beta et Windows Seven: Installation Hack

Bon, c’est simplement pour s’amuser! En attendant un client CRM qui supporte Outlook 2010.

Setup:

Microsoft Dynamics CRM 4.0 Outlook Client 32bits

Microsoft Office Outlook 2010 Beta 64 bits

Windows 7 64 bits

Lancer l’installation du client CRM.

Hummm… le bouton Next est désactivé. L’assistant d’installation ne permet pas d’installer le client CRM sur une version d’Outlook non supportée.  Allons jouer dans le registre!

Créer la clé MSCRMClient puis DWORD (32-bit) IgnoreChecks = 1

Réessayons! Cliquez sur Back

Puis sur Next

Wouhou! Le bouton Next est activé grâce à la clé de registre.

Voilà!

Le problème, c’est que le Configuration Wizard est plus futé. Il supprime la clé de registre avant chaque vérification de pré requis…

Encore un bouton Next de désactivé!

Bon, voici exactement l’étape où on bloque. L’assistant supprime la clé de registre IgnoreChecks avant de faire la vérification des pré requis. Même si vous créez la clé, elle sera effacée à cette étape…

Essayons d’être plus vite que lui!

Source pour créer la clé de registre

Qu’on lance en boucle infinie avec un script batch.

On exécute le batch.

Laissez le script rouler en boucle pendant que vous cliquez sur Back puis sur Next pour revenir à l’étape System Requirements.

Et voilà le travail! Le bouton est activé!  Hahaha

Bon, d’accord, méthode doûteuse d’installer! Mais quand même, on s’amuse comme on peut!

Microsoft Dynamics CRM 4.0 Indexing Service

Le service d’indexation est requis pour le fonctionnement de Microsoft Dynamics CRM… rien d’excitant.

Microsoft Dynamics CRM utilise ce service uniquement pour indexer les fichiers d’aide du CRM. Le service d’indexation doit donc être installé et démarré aussi bien sur le serveur que les clients pour Outlook avec mode hors ligne. (Outlook client with offline mode)

Cependant, le service d’indexation peut prendre une quantité considérable de ressources sur le serveur où est installé Microsoft Dynamics CRM. Voir CPU et Page Fault.

En ajoutant le service d’indexation au serveur, le service crée automatiquement un index, nommé System, qui inclus tous les répertoires sur tout les disques locaux attachés au système d’exploitation. Un autre index, nommé Web est ajouté lorsque IIS est installé. En activant le service, les catalogues par défaut sont aussi démarrés et utilisent les ressources du système.

 

Arrêtez l’indexation des autres catalogues pour maximiser l’utilisation des ressources du serveur. Laissez uniquement le catalogue Microsoft CRM Help.

Vous pourriez aussi arrêter l’indexation de Microsoft CRM Help et l’application fonctionnerait probablement. Cependant cette approche n’est pas supportée par Microsoft.

Sous Windows Server 2003, le service d’indexation se trouve dans la console gestion de l’ordinateur, dans Services and Applications.

Sous Windows Server 2008,  http://bradmarsh.net/index.php/2008/01/07/2008-server-where-is-indexing-service/

Performance des Workflows et traitements asynchrones

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

Importation d’entités personnalisées

Si vous importez une grande quantité de personnalisations ou des entités généreusement modifiées, vous pouvez être confronté à des messages d’erreur comme ceux-ci :

—

Source : MSCRMWebService

Category : None

Event ID : 19457
Customization Import failed. Error: ExecuteNonQuery requires an open and available Connection.
—

Source: ASP.NET

Category: Web Event

Event ID: 1309

Event code: 3001

Event message: The request has been aborted.
Exception type: HttpException
Exception message: Request timed out.

Request path: /tools/systemcustomization/ImportCustomizations/…

—

Deux articles publiés dans la base de connaissance de Microsoft peuvent vous venir en aide

• http://support.microsoft.com/kb/918609
• http://support.microsoft.com/kb/956330

Malheureusement, il est bien possible que cela ne règle pas votre problème et que vous ne soyez toujours pas en mesure d’importer l’ensemble des personnalisations. Voici une suggestion pour y arriver :

1)      Dans Settings – Customizations, cliquez sur Import Customizations

2)      Choississez l’Import File puis cliquez sur Upload

3) Sélectionnez seulement une entité à la fois puis cliquez sur Import Selected Customizations

4)      Répétez l’étape 3 pour chacune des entités personnalisées à importer.

5)      Lorsque chacune des entités aura été importée individuellement, cliquez sur More Actions, puis sur Import All Customizations

6)      Publier toutes les personnalisations
Un peu d’explications, quand même : Il semble que le mécanisme d’importation de personnalisations ne soit pas extrêmement robuste. En fait, il nous abandonne au moment d’importer beaucoup d’entités personnalisées d’un seul coup et également lorsqu’on importe un petit groupe d’entités mais très personnalisées. La suggestion ci-dessus propose de charger le fichier d’import, d’importer les entités fortement personnalisées une par une puis finalement d’importer le fichier au complet.  De plus, il est important de noter que lorsque les entités sont importées une par une, les nouvelles relations vers de nouveaux attributs ne sont pas importés. C’est pour cela qu’il est primordial de réimporter l’ensemble du fichier de perso d’un seul coup avant de publier les modifications. Cela nous assure que toutes les relations entre les entités personnalisées sont importées.

Des ajustements ont été apportés dans l’Update Rollup 6 concernant l’importation de personnalisations.

Suivre le progrès de l’importation de personnalisations

L’importation de personnalisations peut générer une quantité considérable de maux de têtes. La situation devient particulièrement délicate lorsque vous importez un grand nombre de personnalisations d’un seul coup. Il se peut aussi que l’importation se corse lorsque vous importez des entités personnalisées dans un environnement complexe.

Malheureusement, l’interface de Microsoft Dynamics CRM 4.0 ne présente pas de façon trop granulaire le progrès effectué lors de l’importation de personnalisations :

Malheureusement, vous ne trouvez pas d’information dans les vues Filtrées dbo.FilteredImport, dbo.FilteredImportConfig, dbo.FilteredImportFile, dbo.FilteredImportLog ou dbo.FilteredImportMap.  Ces dernières contiennent plutôt les entrées relatives aux importations de données.

Pour avoir un niveau plus intéressant de détails concernant l’avancement de l’importation de personnalisations, exécuter la requête SQL suivante :

USE [MicrosoftCRM_MSCRM]
GO
SELECT * FROM dbo.[ImportJobBase] WITH (NOLOCK)
ORDER BY dbo.[ImportJobBase].[CreatedOn] DESC
--WHERE ImportJobID = '2E0CAEC7-D3BC-DE11-8053-0050569F2C14'

Avec la date et l’heure, déterminez l’entrée qui correspondant à la tâche d’importation en question.

USE [MicrosoftCRM_MSCRM]
GO
SELECT [CreatedOn], [Data] FROM dbo.[ImportJobBase] WITH (NOLOCK)
--ORDER BY dbo.[ImportJobBase].[CreatedOn] DESC
WHERE ImportJobID = '2EECAEC7-D3BC-DE11-8053-0050569F2C14'

Copier le contenu de la colonne Data dans un fichier XML

<?xml version="1.0" encoding="utf-8"?>
<importexportxml>
  <entities>
    <entity result="success" errorcode="0" errortext="">campaignactivity</entity>
    <entity result="success" errorcode="0" errortext="">reportcategory</entity>
    <entity>appointment</entity>
    <entity result="success" errorcode="0" errortext="">opportunity</entity>
    <entity result="success" errorcode="0" errortext="">uom</entity>
    <entity result="success" errorcode="0" errortext="">salesorder</entity>
    <entity>fax</entity>
    <entity>incidentresolution</entity>
    <entity result="success" errorcode="0" errortext="">pricelevel</entity>
    <entity result="success" errorcode="0" errortext="">bulkoperation</entity>
    <entity result="success" errorcode="0" errortext="">report</entity>
    <entity result="success" errorcode="0" errortext="">letter</entity>
    <entity result="success" errorcode="0" errortext="">salesliterature</entity>
    <entity result="success" errorcode="0" errortext="">role</entity>
    <entity result="success" errorcode="0" errortext="">productpricelevel</entity>
    <entity result="success" errorcode="0" errortext="">customeraddress</entity>
    <entity result="success" errorcode="0" errortext="">list</entity>
    <entity result="success" errorcode="0" errortext="">opportunityproduct</entity>
    <entity result="success" errorcode="0" errortext="">activitypointer</entity>
    <entity result="success" errorcode="0" errortext="">email</entity>
    <entity result="success" errorcode="0" errortext="">invoicedetail</entity>
    <entity result="success" errorcode="0" errortext="">contact</entity>
    <entity result="success" errorcode="0" errortext="">territory</entity>
    <entity result="success" errorcode="0" errortext="">uomschedule</entity>
    <entity result="success" errorcode="0" errortext="">contract</entity>
    <entity result="success" errorcode="0" errortext="">subject</entity>
    <entity result="success" errorcode="0" errortext="">team</entity>
    <entity result="success" errorcode="0" errortext="">campaign</entity>
    <entity result="success" errorcode="0" errortext="">account</entity>
    <entity result="success" errorcode="0" errortext="">invoice</entity>
    <entity result="success" errorcode="0" errortext="">campaignresponse</entity>
    <entity result="success" errorcode="0" errortext="">transactioncurrency</entity>
    <entity result="success" errorcode="0" errortext="">businessunit</entity>
    <entity result="success" errorcode="0" errortext="">phonecall</entity>
    <entity result="success" errorcode="0" errortext="">task</entity>
    <entity result="success" errorcode="0" errortext="">systemuser</entity>
    <entity result="success" errorcode="0" errortext="">serviceappointment</entity>
    <entity result="success" errorcode="0" errortext="">template</entity>
    <entity result="success" errorcode="0" errortext="">salesorderdetail</entity>
    <entity result="success" errorcode="0" errortext="">quotedetail</entity>
    <entity result="success" errorcode="0" errortext="">lead</entity>
    <entity result="success" errorcode="0" errortext="">quote</entity>
    <entity result="success" errorcode="0" errortext="">mailmergetemplate</entity>
    <entity result="success" errorcode="0" errortext="">product</entity>
    <entity result="success" errorcode="0" errortext="">incident</entity>
  </entities>
  <nodes>
    <node result="success" errorcode="0" errortext="">sitemap</node>
    <node result="success" errorcode="0" errortext="">isvconfig</node>
    <node result="success" errorcode="0" errortext="">relationshiproles</node>
  </nodes>
  <settings>
    <setting result="success" errorcode="0" errortext="">outlookSynchronization</setting>
    <setting result="success" errorcode="0" errortext="">marketing</setting>
  </settings>
  <securityroles></securityroles>
  <workflows></workflows>
  <languages>
    <language />
  </languages>
</importexportxml>

Vous aurez une idée des entités qui ont été importées avec succès, et celles qui ont moins bien passées.

Microsoft Dynamics CRM Security Model

Excellent point de départ pour comprendre le modèle de sécurité de Microsoft Dynamics CRM 4.0

https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=fb4bb16b-586f-4aae-aa4b-790023e95b61

Très sensiblement le même matériel que vous retrouverez dans les cours de Microsoft, publié gratuitement.