Objectif
Pour aller plus rapidement dans les menus de Dynamics CRM depuis votre client CRM pour Outlook, vous pouvez utiliser le dossier des Favoris d’Outlook. En effet, par simple glisser/déplacer, vous pouvez déposer un élément de navigation du plan de site de Dynamics CRM dans le dossier des Favoris. C’est un moyen simple par exemple pour avoir un raccourci vers la liste de ses contacts ou de ses comptes !

Problème
Dans Outlook 2010, un glisser/déplacer d’un dossier de Dynamics CRM dans le menu Favoris d’Outlook ne donne rien, alors que cela fonctionne parfaitement depuis le client Outlook 2007.
Solution
Le problème se résout en ajoutant une clé de registre comme indiqué ici : http://support.microsoft.com/kb/2494600/fr
Objectif
Bien souvent, les utilisateurs de Microsoft Dynamics CRM souhaiteraient disposer du même format de colonnes pour l’ensemble des vues d’une même entité, y compris pour les quatre vues systèmes (Recherche avancée, Vue associée, Recherche simple et Recherche).
Méthode standard
A partir de l’interface, la seule méthode pour configurer une vue est d’utiliser le Designer de vue depuis la zone de personnalisation des entités. Pour dupliquer une vue et reproduire son colonage, il suffit de l’éditer, puis de cliquer sur le bouton Enregistrer sous. Le système créé alors une nouvelle vue publique à partir de la vue en cours en la nommant avec le nom que vous lui spécifiez.

Problème
La fonction Enregistrer sous n’est par contre pas disponible sur les quatre vues systèmes d’une entité car celles-ci sont prédéfinies et donc existent déjà. Ce sont les vues Recherche avancée, Recherche simple, Recherche et Vue associée.
De même, il n’est pas possible de récupérer le colonage seul d’une vue existante pour le reproduire sur une autre vue publique ou sur une vue système.
Le report des colonnes, leur ordonnancement et la configuration de leur largeur doit être fait manuellement, vue par vue via le Designer ce qui s’avère vite très fastidieux.
Solution
Pour uniformiser le colonage sur toutes les vues d’une même entité, y compris sur les vues système ou des vues publiques existantes, il existe un outil très pratique sur la plateforme codeplex nommé View Layout Replicator.
La procédure est la suivante :
-
-
Décompresser le fichier zip
-
Exécuter l’outil
-
Cliquer sur le bouton Load entities pour établir une connexion avec votre organisation CRM et charger l’ensemble des entités de celle-ci
-
Sélectionner dans le panneau Source views la vue dont vous voulez reproduire le colonage
-
Sélectionner dans le panneau Target views la ou les vues sur lesquelles vous voulez que le colonage soit reproduit
-
Cliquer sur le bouton Save views puis sur Publish entities

Cet article concerne la sécurité associée à la fonctionnalité de programmation d’une détection de doublons dans Dynamics CRM via le menu Fichier > Outils > Détection des doublons.

Pour pouvoir programmer une détection de doublon sur une entité pour laquelle une règle de détection de doublon existe, vous devez avoir au moins le privilège Lire sur cette entité.
Par exemple : pour lancer une détection de doublon sur les comptes, vous devez donc avoir au minimum le privilège Lire avec le niveau d’accès adéquat pour l’entité Compte.

En plus, pour bénéficier de la notification par email à la fin de l’exécution de la tâche programmée, c’est-à-dire pour avoir accès à la case à cocher M’envoyer un courrier électronique à l’adresse () lorsque cette tâche est terminée , il vous faut au minimum le privilège Lire sur l’entité Modèle de courrier électronique :

Attention, sans ce dernier privilège, la case à cocher est grisée, rendant l’option inaccessible pour l’utilisateur.
Ci-dessous, voici l’écran avec l’option de notification active pour l’utilisateur :

Lien vers un article qui explicite plus largement la sécurité autour de la fonctionnalité de détection des doublons :
http://blogs.msdn.com/b/crm/archive/2008/04/29/duplicate-detection-security-model.aspx
Il s’agit d’une vue affichant les opportunités avec lesquelles le compte est lié par le biais des Relations. Ce type de connexion entre les comptes et les opportunités est une fonctionnalité de CRM 4.0. Cette fonctionnalité a été remplacée dans CRM 2011 par les Connexions mais subsiste néanmoins par souci de compatibilité.
Exemple :
Un compte qui joue le rôle de financier dans une opportunité apparait ainsi dans l’enregistrement opportunité :

Cette opportunité est alors visible dans l’enregistrement compte correspondant via la vue “Tous les enregistrements affiliés” :

Cette vue n’est donc pas à confondre avec la vue “Enregistrements ‘concernant’ associés” qui affiche toutes les opportunités du compte et toutes celles associées à des enregistrements eux-même associés au compte (par exemple celles associées aux contacts du compte).
Symptôme du problème
Les onglets du ruban de Dynamics CRM Online ne s’affichent pas correctement ou disparaissent dès que l’on sélectionne l’un d’eux.
ou 
Origine et solution du problème
Le problème vient de la configuration du zoom du navigateur. Pour résoudre le problème, procédez comme suit :
- Sélectionnez dans Internet Explorer le menu Options puis Zoom.
- Configurez le zoom à 100%.

- Réactualisez la page en cliquant F5.
- Les menus réapparaissent normalement.

La problématique
Le nombre d’enregistrements affichés par page dans une liste de Dynamics CRM est configurable par utilisateur à l’aide du menu Outils > Options de l’interface web de Dynamics CRM. Il est au maximum de 250, ce qui est relativement peu. Du coup, pour des besoins d’administration, par exemple pour détruire plusieurs enregistrements d’un seul coup, ou pour exécuter un workflow manuellement sur une grande quantité d’enregistrements, il peut être utile d’étendre ce nombre maximum à une valeur plus conséquente que la limite autorisée.
Proposition de solution
Une solution consiste à modifier directement le paramètre en base de données pour l’utilisateur concerné. Il s’agit de la colonne PagingLimit de la table dbo.UserSettingBase sur la ligne d’enregistrement correspondant au compte utilisateur que vous utilisez. Vous pouvez ainsi le configurer à une valeur plus intéressante, par exemple plusieurs milliers, selon le volume de données à traiter et l’opération que vous voulez réaliser.
La problématique
Dans Dynamics CRM, l’entité Contact comprend un champ nommé Nom complet représentant (comme son nom l’indique) le nom complet du contact, c’est-à-dire à la fois son prénom et son nom. Plusieurs formats sont disponibles et configurables dans la zone Paramètres > Administration > Paramètres du système par un administrateur CRM. Ainsi, il est possible de paramétrer le nom complet d’un certain Jean Dupont en “Jean Dupont” ou “Dupont Jean” ou encore “Dupont, Jean” etc…
En base, l’attribut fullname de l’entité Contact est tout simplement calculé automatiquement par le système, en concaténant les attributs firstname et lastname, selon le format choisi par l’administrateur CRM.
Le problème est que, si le format du nom complet est modifié en cours de production, seuls les nouveaux contacts insérés dans CRM auront le nouveau format défini. Tous les contacts existant conservent l’ancien format.
Ce cas se produit malheureusement fréquemment et l’on se demande comment reconfigurer l’ensemble des contacts avec le même format de nom complet pour tous.
Proposition de solution
La solution repose sur la mise à jour du prénom ou nom de tous les contacts pour provoquer le rafraichissement du nom complet sur la base du nouveau format défini. Malheureusement une telle opération manuellement n’est pas envisageable sur un volume important de contacts.
Une solution simple (que m’a soufflée Tanguy Touzard (MVP CRM) aujourd’hui à l’occasion des Techdays 2011 à Genève où nous animions ensemble une session sur l’intégration de CRM 2011 et Azure) est de provoquer la mise à jour à l’aide d’un workflow.
Le principe est le suivant :
-
créer un workflow basé sur un objet de type Contact.
-
configurer le workflow pour pouvoir le déclencher manuellement (coche “A la demande”).
-
ajouter une action de mise à jour de l'enregistrement. Configurer l’enregistrement, à l’aide des valeurs dynamiques pour que le champ “Nom” soit mis à jour avec la valeur actuelle du “Nom”, et que le champ “Prénom” soit mis à jour avec celle du “Prénom”. Cela revient à remettre les mêmes valeurs dans les deux champs, donc à ne pas réellement les modifier, mais ce qui est intéressant ici c’est que CRM prendra cela tout de même pour une modification et déclenchera ainsi le re-calcul du nom complet.


Remarque :
Si vous déclenchez le workflow à partir de la liste des contacts, vous aurez la mauvaise surprise de devoir effectuer l’opération par page d’enregistrements. Or dans CRM, le maximum d’enregistrements par page qu’il est possible de configurer est 250 seulement. Si vous avez plusieurs milliers d’enregistrement, c’est un peu gênant…
Vous trouverez une idée pour palier à cet inconvénient sur ce poste :
http://blogs.developpeur.org/cdubois/archive/2011/04/05/comment-augmenter-le-nombre-d-enregistrements-affich-s-par-page-dans-une-liste-dynamics-crm.aspx
Depuis le temps que l’on me le demande, je l’ai enfin fait :-).
Vous trouverez à l’adresse ci-après un plan de cours type d’une nouvelle formation que j’ai créée pour tout savoir sur la gestion des rapports dans Microsoft Dynamics CRM 4.0 :
http://www.agilcom.info/1/skills/CRMSQLReportingServices.htm
En effet, Microsoft n’a pas de formation officielle dédiée sur le sujet. C’est pourquoi j’ai envoyé nombre d’entre vous suivre la formation traditionnelle qui permet d’apprendre à utiliser SQL Server Reporting Services. Mais chaque fois, votre retour est qu’il manque le lien entre SQL Server Reporting Services et CRM…
Cette nouvelle formation présente l’ensemble des technologies impliquées de près ou de loin dans le module de reporting de CRM. Elle explique bien sûr comment créer des rapports personnalisées avec SQL Server Reporting Services 2008 à partir de Visual Studio, mais pas seulement. Vous y trouverez des réponses notamment sur :
- la façon dont sont intégrés CRM et SSRS,
- les possibilités en matière de déploiement (par exemple pour publier un rapport dans une iFrame ou comment copier un rapport d’un déploiement CRM à un autre),
- le schéma de la base de données CRM,
- le fonctionnement en mode offline,
- le pré-filtrage,
- l’abonnement par messagerie,
- la sécurité,
- la récupération des rapports en cas de panne de CRM ou de SQL Server,
- l’utilisation d’Office 2010 (avec une intro à PowerPivot),
- et plein d’autres sujets encore !
Alors si vous êtes intéressés, contactez nous : http://www.agilcom.info/4/Infos/
Pour ajouter des colonnes dans les vues des files d’attente de Dynamics CRM 4.0, suivez la procédure suivante :
- Lancez Microsoft SQL Server Management Studio.
- Retrouvez la table MetadataSchema.Entity dans la base <VotreOrganisation>_MSCRM.
- Ouvrez la table pour afficher les données.
- Modifiez Entrez la valeur True dans la colonne IsCustomizable de l’enregistrement QueueItem.
(Editez la requête standard d’ouverture de la table et modifiez la pour retrouver plus rapidement l’enregistrement)
- Fermez Microsoft SQL Server Management Studio.
- Lancez CRM dans le navigateur.
- Naviguez sur Settings –> Customization –> Customize Entities.
- Double cliquez l’entité QueueItem dans la liste.
- La liste des vues est maintenant disponible pour la personnalisation :
Problématique
Si vous avez besoin d’exporter sous Excel une liste de comptes ou de contacts dans le but de faire des retouches à droite à gauche puis de réinjecter le tout dans CRM, vous ne pouvez pas vous en sortir avec CRM seul.
En effet, l’export sous Excel ne permet pas d’extraire les id des enregistrements (que ce soit des comptes, des contacts ou toute autre entité). Or ceux-ci sont nécessaires pour retrouver les enregistrements au moment de réimporter les modifications dans CRM.
Solution
Je ne vois que trois outils sur le net susceptibles de nous aider :
Quelques remarques
Ces outils sont simples d’utilisation. Quelques remarques toutefois :
- Microsoft Dynamics CRM 4.0 Bulk Update and Export Tool :
- Attention, pour cet outil, il faut installer le Framework 3.5.
- Vous pouvez faire des updates et des deletes en masse d’enregistrements mais la création de nouveaux enregistrements fonctionnent mal.
- La liaison entre entités, c’est-à-dire l’utilisation de champs lookup n’est pas très simple. En effet, par exemple, pour indiquer le contact principal d’un compte, vous devez transmettre un champ avec une valeur au format : “contact,60cde26b-92c1-dc11-9a60-0003ff562152”. Il n’est donc pas possible de transmettre le nom du contact directement. Vous devez fournir le Guid de l’enregistrement lié !
Conseil pour s’en sortir : Exportez les comptes et les contacts dans deux fichiers csv séparés. Editez ces fichiers dans Excel. Retrouvez le Guid associé à un contact en utilisant la fonction VLookup d’Excel.
- Tool to Update MSCRM 4.0 data inline and Export to CSV for Re-import
- Les champs Lookup ne sont pas rapatriés correctement (notamment s’ils sont mis à jour dans Excel)
- Les nouveaux enregistrements doivent être importés séparément dans CRM et ne peuvent être ajoutés en même temps que les enregistrements mis à jour.
- Un enregistrement n’est pas mis à jour s’il a été modifié entre temps dans CRM.
- Import Manager 2008
- Cet outil est indubitablement le plus complet des trois. Il permet notamment de programmer des imports sous forme de batch. Il permet notamment de mapper les colonnes des fichiers à importer avec les attributs des entités de CRM.
- Par contre, au delà de 10 enregistrements importés, il faut acheter une licence.
Problématique
Lorsqu’on affiche une liste d’éléments associés dans une iFrame au sein d’un formulaire Dynamics CRM (cf. article précédent explicitant le procédé pour y parvenir) , il reste un espace blanc de chaque côté de celle-ci :

Comment supprimer ces espaces de couleur blanche ?
Proposition de solution
Si vous observez l’élément HTML dans la page, à l’aide par exemple de l’Internet Explorer Toolbar (ou des outils de développement de IE8), vous constaterez que ces espaces sont dû :
- d’abord au padding de l’élément HTML correspondant qui n’est malheureusement pas à 0,
- mais aussi, sur la droite, à la zone prévue pour une éventuelle barre de défilement (ce qui explique d’ailleurs que l’espace blanc est plus important à droite qu’à gauche puisqu’il cumule le problème du padding et de la scrollbar).
Conclusion, pour s’en débarrasser il suffit de supprimer les deux :-)
Le code
Voici le code à rajouter dans l’évènement onLoad du formulaire :
ATTENTION : pensez à remplacer le nom de l’iFrame (IFRAME_Clubs) par le nom de votre iFrame à vous !
crmForm.all.IFRAME_Clubs.attachEvent('onreadystatechange',func);
function func(event) {
//Récupération de l'élément HTML (iframe) sur lequel porte l'évènement
var target = event.target || event.srcElement;
//Vérification du statut de chargement du contenu de l'iframe
if(target.readyState=='complete') {
//Récupération du body de l'iframe
iframeBody=target.contentWindow.document.body;
//Suppression du padding
iframeBody.childNodes[0].rows[0].cells[0].style.padding = 0;
//Suppression de l'emplacement de la scrollbar verticale
iframeBody.scroll = "no";
}
}
Pourquoi attacher dynamiquement une fonction en réponse à l’évènement onreadystatechange sur l’iFrame ?
Tout simplement parce que vous risquez d’accéder au contenu de l’iFrame avant même que celle-ci soit chargée ! L’évènement onreadystatechange se déclenche sur un élément justement lorsque le statut de celui-ci change. On l’utilise donc pour valider que le statut de l’iframe est à la valeur complete, indiquant la fin du chargement de son contenu!
Problématique
Dans CRM tout est rangé dans des tiroirs, et ça ne plait pas toujours. En effet, dans un formulaire, tous les éléments associés à l’enregistrement en cours sont accessibles par le volet de navigation situé sur le côté gauche.
Par exemple, imaginons qu’un contact possède des biens qu’on veut pouvoir enregistrer dans Dynamics CRM. Il suffit pour cela de créer une entité personnalisé, que l’on appellerait Bien et d’associer celle-ci à l’entité Contact par une relation de type N-1. Le résultat est que tous les biens d’un contact sont accessibles par le menu Biens dans le volet gauche du formulaire de l’entité Contact.
Il faut donc au moins un clic pour accéder à la liste des biens du contact. Une fois la liste des biens affichée, l’utilisateur n’a plus évidemment de visibilité sur les informations générales du Contact (son adresse, son téléphone etc…)
Comment faire pour que l’utilisateur puisse avoir en un coup d’œil, à la fois la liste des biens du contact, à la fois les informations générales de celui-ci ?
Alternative
Une alternative à la présentation par défaut proposée par Dynamics CRM consiste à utiliser les iFrame pour afficher la liste d’un élément associé directement sur le formulaire. Cela permet de revenir à une approche plus “portail” où tous les éléments sont visibles dans une seule et même page.
Par exemple, pour voir d’un seul coup d’œil, les informations d’un contact et la liste de ses biens, vous pouvez remplacer le nœud dans le volet de navigation à gauche par une iFrame positionnée sur n’importe quel onglet du formulaire :
Le code
Pour ramener une liste d’éléments dans une iframe sur un formulaire, voici la procédure à suivre :
- Utilisez les outils de développement de IE 8, ou si vous avez une version antérieure de IE, munissez vous d’une extension permettant de visualiser le modèle d’objets en mémoire d’une page html tel que l’Internet Explorer Developer Toolbar.
- Pour faire apparaître la barre de menu lorsque vous visualisez un enregistrement contact, appuyez par exemple la combinaison de touches CTRL-N.
- Une fois la barre de menu de IE visible, vous pouvez sélectionnez votre extension ou les outils de développement de IE 8 pour afficher le modèle d’objets en mémoire de la page en cours.
- Retrouvez dans la hiérarchie des nœuds celui de l’entité associée qui vous intéresse. Par exemple, le nœud Biens correspond à la SubArea d’id nav_new_contact_new_bien ou new_contact_new_bien est le nom de la relation entre l’entité contact et l’entité new_bien.
- Notez qu’il y a une procédure nommé loadArea sur l’évènement onclick de l’élément HTML.
C’est cette procédure justement qui affiche la liste dans le volet de droite lorsque l’utilisateur clique sur le nœud. Le code de cette procédure est situé dans le fichier Details.js que vous trouverez sous la structure de répertoire du site web CRM dans …\_static\_common\scripts :
Si vous éditez le source de la page HTML du formulaire, vous verrez qu’en effet ce fichier de script est chargé dans la page par une balise script :
En analysant la procédure loadArea, on constate que la page qui affiche la vue associée de l’élément enfant est une page nommée areas.aspx.

En analysant complètement cette procédure, on peut donc retrouver l’url de la page qui s’affiche dans le volet droit du formulaire lorsque l’utilisateur clique sur le nœud dans le volet de navigation de gauche. C’est cette url qu’il suffit donc de reproduire dans une iFrame dessinée sur le formulaire pour basculer le nœud du volet de navigation directement sur le formulaire. Elle est du type :
areas.aspx?oId=<</span>Id de l'objet>&oType='objet>&security=<</span>info de securité>&tabSet=<</span>Nom du noeud>;
- Créez maintenant une iFrame dans le formulaire de l’entité parent à l’emplacement souhaité. Elle doit avoir les caractéristiques suivantes :
- Ajoutez le script suivant dans le code de l’évènement onLoad du formulaire :
ATTENTION : n’oubliez pas de remplacer le nom IFRAME_Biens de l’iFrame dans cet exemple par le nom de votre iFrame à vous ! Remplacez également le nom de la SubArea (ici new_contact_new_bien) par celui de votre nœud à vous (que vous retrouvez en paramètre de l’appel à la fonction loadArea en réponse à l’évènement onclick sur l’élément HTML vu dans l’extension de IE)
var CRMFORMTYPE_CREATE =1;
var CRMFORMTYPE_UPDATE = 2;
var CRMFORMTYPE_READONLY = 3;
var CRMFORMTYPE_DISABLED = 4;
var CRMFORMTYPE_BULKEDIT = 6;
var CRMFORMTYPE_QUICKCREATE =5 ;
crmForm.all.IFRAME_Biens.src = GetFrameSource('new_contact_new_bien');
function GetFrameSource(tabSet)
{
var oId = crmForm.ObjectId;
var oType = crmForm.ObjectTypeCode;
var security = crmFormSubmit.crmFormSubmitSecurity.value;
var uri ="";
if (crmForm.ObjectId != null)
{
var oId = crmForm.ObjectId;
var oType = crmForm.ObjectTypeCode;
var security = crmFormSubmit.crmFormSubmitSecurity.value;
var url = "areas.aspx?oId=" + oId + "&oType=" + oType + "&security=" + security + "&tabSet=" + tabSet;
uri = url;
}
else
{
uri = "about:blank";
}
switch (crmForm.FormType)
{
case CRMFORMTYPE_UPDATE:
case CRMFORMTYPE_READONLY:
case CRMFORMTYPE_DISABLED:
return uri;
break;
case CRMFORMTYPE_BULKEDIT:
case CRMFORMTYPE_QUICKCREATE:
case CRMFORMTYPE_CREATE:
return "about:blank";
break;
default:
break;
}
}
Le switch à la fin de la procédure permet d’envisager tous les modes possible d’un formulaire Dynamics CRM. Par exemple, lorsque l’utilisateur créé un nouveau contact, la liste doit apparaître vide. C’est seulement une fois le contact sauvegardé qu’il est alors possible de lui associer des biens.
- Sauvegardez les changements, n’oubliez pas de cocher l’activation de l’évènement onLoad et publiez l’entité.
- Pour faire disparaître le nœud de l’élément associé dans le volet gauche de navigation du formulaire, il suffit de sélectionner Ne pas afficher dans la liste des option d’affichage dans l’écran de définition de la relation 1-N entre les deux entités.
Et voilà ! Votre liste est opérationnelle dans le formulaire !
Cas particulier d’un élément associé par une relation N-N native
Attention au cas des relations N-N native pour laquelle il y a une petite subtilité. Par exemple, un contact peut être membre de plusieurs clubs de sport (où club de sport serait défini en tant qu’entité personnalisée), ceux-ci ayant également plusieurs contacts membres. Une simple relation N-N native suffit donc à la mise en place d’une telle relation entre les entités contact et new_clubdesport. Sauf que, dans ce cas, l’affichage de la liste des clubs fait intervenir un paramètre supplémentaire appelé roleOrd.
En effet, vous savez qu’en base de données, toute relation N-N entre deux tables nécessitent la mise en place d’une table intermédiaire rapatriant la clé de chacune des tables impliquées dans la relation. Cette table existe bel et bien dans CRM lorsque vous tirez une relation N-N native entre deux entités, mais elle n’est pas visible et se comporte comme une table intrinsèque.
Cela veut dire que lorsqu’un utilisateur clique sur le nœud Clubs de sport dans le volet gauche d’un formulaire Contact, en théorie, c’est une liste des éléments de cette table intermédiaire qui devrait apparaître dans le volet droit. Or, Dynamics CRM fait bien les choses puisqu’il affiche directement la liste des clubs de sport dont le contact est membre.
Si on scrute le modèle objets de la page HTML en mémoire, on s’aperçoit que la fonction loadArea récupère un second paramètre :
Notez au passage que le nom de la SubArea (dans l’exemple areanew_new_clubdesport_contact) est toujours celui de la relation, mais préfixé par le mot area.
Le second paramètre est \x26roleOrd\x3d2. Que signifie-t-il ?
\x est le caractère d’échappement utilisé en javascript pour exprimer le code hexadecimal qui suit. 26 est le caractère “&” et 3d est le signe “=”. Cela donne donc la chaîne &roleOrd=2. roleOrd est donc en fait un Nième paramètre de l’url de la page areas.aspx qui constitue la source de l’iFrame de notre formulaire. En fait, si on se positionne sur l’entité Contact, par ce paramètre on indique qu’on veut voir le niveau 2 de la relation avec la table Club, c’est-à-dire la liste des clubs. Le niveau 1 représenterait la liste des éléments de la table intrinsèque…
- Jetez un œil dans le fichier Details.js. Vous constatez que le second paramètre passé à la fonction loadArea (appelé sParams) est concaténé à l’url à la suite des autres paramètres (oId, oType, security et tabSet) :
- Modifiez donc la fonction GetFrameSource dans le code de réponse à l’évènement onLoad du formulaire de l’entité parente pour inclure ce nouveau paramètre. Cela donne :
var CRMFORMTYPE_CREATE =1;
var CRMFORMTYPE_UPDATE = 2;
var CRMFORMTYPE_READONLY = 3;
var CRMFORMTYPE_DISABLED = 4;
var CRMFORMTYPE_BULKEDIT = 6;
var CRMFORMTYPE_QUICKCREATE =5 ;
crmForm.all.IFRAME_Biens.src = GetFrameSource('new_contact_new_bien');
//A ajouter : le second paramètre que vous pouvez récupérer dans le modèle objet de la page HTML
crmForm.all.IFRAME_Clubs.src = GetFrameSource('areanew_new_clubdesport_contact','\x26roleOrd\x3d2');
//A ajouter : le paramètre roleOrd dans la fonction
function GetFrameSource(tabSet, roleOrd)
{
var oId = crmForm.ObjectId;
var oType = crmForm.ObjectTypeCode;
var security = crmFormSubmit.crmFormSubmitSecurity.value;
var uri ="";
if (crmForm.ObjectId != null)
{
var oId = crmForm.ObjectId;
var oType = crmForm.ObjectTypeCode;
var security = crmFormSubmit.crmFormSubmitSecurity.value;
var url = "areas.aspx?oId=" + oId + "&oType=" + oType + "&security=" + security + "&tabSet=" + tabSet;
//A ajouter : traitement du paramètre optionnel roleOrd
var roleOrdParamMissing = (typeof(roleOrd) == "undefined") || (roleOrd == null);
if (!roleOrdParamMissing) {
//Si le paramètre est présent, concaténez le à la suite de l'url
url += roleOrd;
}
uri = url;
}
else
{
uri = "about:blank";
}
switch (crmForm.FormType)
{
case CRMFORMTYPE_UPDATE:
case CRMFORMTYPE_READONLY:
case CRMFORMTYPE_DISABLED:
return uri;
break;
case CRMFORMTYPE_BULKEDIT:
case CRMFORMTYPE_QUICKCREATE:
case CRMFORMTYPE_CREATE:
return "about:blank";
break;
default:
break;
}
}
et à l’exécution :

Requête Ajax
Voici la structure type d’une requête Ajax que l’on peut émettre depuis le code javascript d’un formulaire CRM pour interroger les services web de Dynamics CRM.
Par exemple voici la tuyauterie nécessaire pour invoquer la méthode RetrieveMultiple :
Méthode RetrieveMultiple avec un critère simple
Le corps de la balise RetrieveMultiple doit reprendre le schéma suivant :
- q1:ColumnSet définit les colonnes attendues en réponse de la requête SELECT (le type q1:AllColumns correspond à un SELECT * et q1:ColumnSet permet de spécifier des colonnes précises)
- q1:Criteria correspond à la clause WHERE de la requête SELECT. Il s’agit d’une collection de conditions définie dans l’élément q1:Conditions, elles-même associées par l’opérateur défini dans l’élément q1:FilterOperator. Chaque élément q1:Condition représente un critère de filtre défini par un attribut, un opérateur et les valeurs associées.
Exemple : Supposons que vous cherchez parmi vos contacts tous les directeurs informatiques basés sur la France, cela donnerait la requête suivante :
Cette première structure de requête permet de combiner uniquement des conditions par un même opérateur (And ou Or).
Exemples :
- WHERE condition a ET condition b,
- ou WHERE condition a OU condition b OU condition c,
- etc…
Méthode RetrieveMultiple avec multicritères
Si vous avez à traiter un groupement de conditions plus complexe associant plusieurs opérateurs du type WHERE (condition a ET (condition b OU condition c)), il faut exploiter un élément supplémentaire q1:filters qui permet d’imbriquer plusieurs filtres.
Le schéma est le suivant :
q1:Filters est une collection de filtres supplémentaires associée à l’ensemble des conditions de premier niveau du critère par l’opérateur q1:FilterOperator. q1:Filter définit une collection de conditions q1:Conditions, elles-même associées par l’opérateur défini dans le sous élément q1:FilterOperator. Exemple : Supposons que vous cherchez parmi vos contacts tous les directeurs informatiques basés sur la France ou la Belgique, cela donnerait la requête suivante :

Quelle est la problématique ?
Le Form Object Model de Dynamics CRM 4.0 ne permet pas de cacher dynamiquement un champ dans un formulaire. Du coup, il faut exploiter le DHTML.
Comment faire ?
Avant d’appliquer les propriétés et méthodes du DHTML il faut vous demander quel est le rendu HTML du champ (contrôle) que vous voulez cacher dans le formulaire CRM. Par exemple un attribut de type nvarchar, représenté par une zone de texte dans un formulaire CRM, a pour rendu un élément INPUT de type text dans la page HTML résultante (Notez que rien ne garantit que le choix du rendu d’un attribut de type nvarchar sera maintenu en INPUT dans la prochaine version de CRM…)

Une fois que vous connaissez le type d’élément HTML, vous pouvez donc appliquer les propriétés et méthodes de l’objet correspondant du DHTML. Pour cacher le champ Prénom du formulaire, vous pourriez donc écrire :
crmForm.all.firstname.style.display = 'none';
Mais ce code a pour effet de cacher l’élément INPUT uniquement, c’est-à-dire sans le libellé associé, donc vous obtenez :
Pour supprimer un champ intégralement du formulaire, vous devez donc aussi repérer la structure de table dans laquelle il est affiché. Par exemple, pour cacher le champ Prénom du formulaire, vous devez cacher les deux balises <td> correspondant au libellé Prénom et à la zone de texte associée. Les deux balises ont pour Identifiant respectif firstname_c et firstname_d. Cela donne le code suivant :
crmForm.all.firstname_c.style.display = 'none';
crmForm.all.firstname_d.style.display = 'none';
Pour réafficher le champ, on coderait :
crmForm.all.firstname_c.style.display = '';
crmForm.all.firstname_d.style.display = '';
Pour supprimer la ligne entière (contenant le champ Prénom et le champ Téléphone personnel), il ne faut pas hésiter à supprimer la balise <tr> englobant les balises <td>. Celle-ci n’ayant aucun identifiant, on pourrait procéder ainsi :
crmForm.all.firstname.parentElement.parentElement.style.display = 'none';
S’il s’agit d’un attribut de type ntext (zone de texte de plusieurs lignes) en revanche, le rendu n’est pas un élément INPUT mais un élément textarea.
Les propriétés de cet élément HTML n’étant pas les mêmes que pour un élément INPUT, le code pour le cacher est le suivant :
crmForm.all.description.style.visibility = 'hidden';
Liens utiles : Pour vous aider à trouver le rendu des champs et la structure de la page HTML généré par Dynamic CRM, utilisez l’Internet Explorer Developer Toolbar. Attention celle-ci n’est pas compatible avec IE8 pour lequel vous pouvez utiliser les outils de développement intégrés.
Un peu de théorie…
Les entités de Dynamics CRM 4.0 possèdent automatiquement deux attributs statecode et statuscode , de type picklist, permettant de gérer le cycle de vie d’un enregistrement de ce type :
-
l’attribut statecode (cf. figure (1)) donne le statut de l’enregistrement, c’est-à-dire l’état de l’enregistrement dans son cycle de vie.
Exemple : un enregistrement de type devis peut être dans les états brouillon, actif, conclu, perdu etc…
Les valeurs de l’attribut statecode ne sont pas personnalisables. Pour une entité personnalisée, elles sont automatiquement positionnées à : actif/inactif
-
l’attribut statuscode(cf. figure (2)) permet de préciser la raison pour laquelle l’enregistrement se trouve dans un statut donné.
Exemple : un enregistrement de type lead peut être à l’état exclu pour différentes raisons : parce que le client est injoignable, parce que ces coordonnées sont incorrectes etc…
Les valeurs de l’attribut statuscode sont évidemment personnalisables, et ce, en fonction des valeurs disponibles pour l’attribut statecode de l’entité concernée.
Là où cela devient intéressant c’est qu’un enregistrement peut se comporter différemment selon l’état dans lequel il se trouve. Plus précisément, pour certains états d’un enregistrement d’une entité système, Dynamics CRM est capable de figer l’enregistrement pour bloquer toute action de l’utilisateur.
Exemple : un devis à l’état actif signifie que celui-ci a été soumis au client et est donc en attente de la réponse de ce dernier. Du coup, Dynamics CRM bloque en lecture seule l’enregistrement de façon à empêcher l’utilisateur d’effectuer une quelconque modification sur un devis déjà présenté au client. Seul un changement d’état (révision du devis par exemple) lui permettra de repasser le devis en mode édition.
Quelle est la problématique ?
Le problème se pose lorsque vous créez votre propre entité personnalisée. En effet, pour ces entités, Dynamics CRM, ne pouvant deviner comment modéliser un cycle de vie complexe pour l’enregistrement, ne leur attribue que deux valeurs possibles : actif et inactif. Dans le premier statut, l’enregistrement est éditable et dans le second, il ne l’est plus. Du coup, si vous voulez imaginer un cycle de vie plus subtil, avec différents états successifs pour l’enregistrement, il n’y a pas beaucoup de marge de manœuvre…
Quelle solution alors ?
-
Une solution consiste à exploiter l’attribut statuscode pour nuancer les valeurs de l’attribut statecode. Mais attention, quand l’enregistrement est à l’état inactif il n’apparaît plus dans les vues standards (sauf celles qui affichent les éléments inactifs bien sûr) et notamment dans la vue associée de l’entité, c’est-à-dire dans le contexte d’un enregistrement parent. L’état inactif ne convient donc pas si l’utilisateur doit pouvoir voir une liste des enregistrements désactivés en même temps que ceux qui sont actifs.
Il reste la possibilité de jouer sur l’état actif pour ajouter des “raisons pour lesquelles l’enregistrement se situerait dans une sorte d’état actif intermédiaire”.
Cette première solution convient si votre enregistrement à l’état actif peut évoluer d’un état à l’autre via l’attribut statuscode tout en restant en permanence en mode édition.
Exemple : une demande de renseignement est active ou inactive (valeurs de l’attribut statecode). Lorsqu’elle est dans l’état actif, l’utilisateur peut jouer sur la raison du statut (valeurs de l’attribut statuscode) pour suivre son cycle de vie : ce pourrait être en cours de traitement, en attente d’une autre personne, en cours de validation, validée…etc
Cette solution n’est cependant pas pleinement satisfaisante si vous avez besoin de “figer” l’enregistrement en lecture seule dans certains états.
Par exemple, comment faire pour figer une demande de renseignement lorsqu’elle est dans la raison du statut “Traitée” pour garantir qu’aucune modification ne lui sera plus apportée maintenant qu’on a répondu à la demande ?
La simulation obtenue n’est cependant pas entièrement satisfaisante dans le mesure où idéalement, il faudrait également bloqué l’ajout d’association sur l’enregistrement. Par exemple, pour un enregistrement bloqué, il ne devrait pas être possible d’y associer de nouvelles activités.
Voici quelques idées pour mettre en œuvre cette solution :
var iLen = crmForm.all.length;
for (counter = 0; counter < iLen; counter++)
{
crmForm.all[counter].Disabled = true;
}

Le problème survient (sans raison apparente) lorsqu' on essaie de se connecter à l’application Dynamics CRM 4.0 via Internet Explorer. L’accès à CRM est bloqué avec le message suivant :
Le code d’erreur que l’on peut voir dans l’url et dans le gestionnaire d’évènement référence une erreur connue de CRM (cf. liste des codes d’erreur du SDK) indiquant un problème de génération de clé invalide (code error 8004A106).
J’ai trouvé une proposition de solution (sans explication du problème) sur Internet qui consiste à redémarrer le service Service de traitement asynchrone Microsoft CRM (http://peitor.blogspot.com/2008/12/microsoft-crm-4-crmexception-expired.html). Mais que faire si ce service est correctement démarré ?
En cherchant dans le Gestionnaire de déploiement de CRM, il s’avère que mon serveur CRM (ayant tous les rôles de serveur cumulés) était dans un état “désactivé”. En le réactivant, l’accès à CRM est rétabli !

Vous êtes plusieurs à me rapporter des erreurs qui vous bloquent dans le processus d’installation de CRM 4.0 sur Windows Server 2008 et SQL Server 2008. Et pour cause car il y a en effet des problèmes du fait que CRM 4.0 a été conçu pour être compatible notamment avec les anciennes versions des deux produits c’est-à-dire Windows Server 2003 et SQL Server 2005.
Il y a évidemment plein d’infos à droite à gauche sur Internet sur le sujet. En voici une petite compilation :
-
- Pour résoudre le message d’erreur « Le service msftesql est introuvable » dû à SQL Server 2008, je vous conseille cet article : http://support.microsoft.com/kb/952601/. La solution est en fait toute simple.
Il suffit de télécharger la dernière version des fichiers d’installation lorsque le programme d’installation vous le suggère (au tout début du processus d’install) :
Important : Notez que cette étape consiste à mettre à jour uniquement les fichiers d’installation de CRM et ne remplace donc pas l’installation des rollup de CRM qui doit être réalisée après l’installation du produit.
Le dernier rollup actuel pour CRM 4.0 est le N°4 téléchargeable ici :
http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=0ddf8e83-5d9c-4fe7-9ae6-f2713a024071 Autre remarque : Si vous avez un souci de connexion à Internet (par exemple sur une machine virtuelle) vous pouvez télécharger séparément les fichiers d’installation depuis l’url correspondante indiquée ici :
http://support.microsoft.com/kb/948917/
Bonne installation !
Le problème rencontré est le suivant :
Lorsqu’on exécute un site web (une page aspx quelconque) à partir de Visual Studio, le serveur de développement ASP.NET s’exécute mais Internet Explorer renvoie le message suivant :
Pour résoudre le problème, suivez la procédure suivante :
- Exécutez le Bloc-notes de Windows en tant qu’administrateur.
- Ouvrez le fichier C:\Windows\System32\drivers\etc\hosts
- Changez la ligne “::1 localhost” en “:::1 localhost” c’est-à-dire en rajoutant encore deux points (:) devant le chiffre 1.
- Sauvegardez le fichier en cliquant Fichier > Enregistrer sous puis en sélectionnant le type Tous les fichiers :
- Répondez Oui à la question qui vous est posé pour écraser le fichier existant avec les changements.
Si vous avez un problème plus spécifique concernant le fonctionnement du serveur de développement ASP.NET, vous trouverez ici quelques pistes de réflexion/solution : http://msdn.microsoft.com/fr-fr/library/w566a94d.aspx
Parallèlement à la consultation de rapports disponible dans l'interface de Dynamics CRM, il est possible d'envoyer automatiquement un rapport à un utilisateur en pièce attachée ou directement dans le contenu d'un message électronique.
J'ai déjà rencontré plusieurs fois ce besoin notamment pour des responsables faisant partie d'un pôle de direction d'entreprise, qui apprécient de trouver chaque semaine leurs rapports de synthèse dans leur boîte de messagerie, plutôt que de devoir faire la démarche par eux-même d'aller consulter les dits rapports dans CRM. Il y a comme un effet reminder appréciable.
Du point de vue technique, le procédé n'est pas particulièrement compliqué mais il est vrai qu'il est difficile de trouver une procédure claire et précise sur Internet sur le sujet. D'autant que la solution n'est techniquement pas faisable à partir de CRM seul et repose au contraire entièrement sur Report Server qui gère les rapports de ce dernier.
Le principe consiste à configurer un abonnement (subscription en anglais) sur Report Server pour l'utilisateur sur chaque rapport concerné.
Voici quelques éléments qui j'espère vous aideront dans la mise en oeuvre d'un abonnement avec SRS sur un rapport CRM :
Première étape : configuration de Report Server pour l' abonnement par email
- Sur le serveur installé avec SQL Reporting Services, lancez Start > All programs > Microsoft SQL Server 2005 > Configuration Tools > Reporting Services Configuration
- Sélectionnez Email Settings dans la barre de navigation à gauche.
- Indiquez l' adresse de l' expéditeur à utiliser pour les messages. Il faut que cet utilisateur ait les permissions évidemment d' envoyer des emails via le serveur SMTP spécifié dans le point suivant.
- Indiquez le nom du serveur SMTP (ce peut être une adresse IP, un nom UNC...etc. Par exemple, vous pouvez indiquer le nom du serveur Exchange si vous utilisez Exchange Server pour l'envoi de message)
- Appliquez les paramètres en cliquant le bouton Apply puis quitter le gestionnaire.
Seconde étape : configuration d'une source de données personnalisée pour le rapport concerné
- Lancez le gestionnaire de rapport de SRS dans Internet Explorer. Il doit s' agir d' une URL du type http://<NomDuServeurSRS>/Reports
- Cliquez Afficher les détails tout à droite dans la barre d' outils du gestionnaire, pour faire apparaître le détail des répertoires disponibles.
- Cliquez sur le répertoire du même nom que l' organisation contenant les rapports CRM, par exemple AdventureWorksCycle_MSCRM dans l' exemple ci-dessous :
- Cliquez ensuite sur le dossier 4.0 dans lequel doit se trouver le rapport sur lequel porte l' abonnement.
- Par défaut, les rapports de Dynamics CRM sont configurés sur une source de données qui s' appelle MSCRM_DataSource que vous trouverez tout en bas dans la liste des rapports.
Il se peut que vous rencontriez des problèmes en configurant un abonnement sur la base de cette source de données définie par défaut, y compris si celle-ci s' appuie sur le connecteur SRS installé pour CRM. Si vous tentez de configurer un abonnement sur le rapport, vous risquez de vous trouver face à ce message :
Pour que cela fonctionne sans encombre, une solution consiste à définir une source de données personnalisée dont vous maîtriserez parfaitement les paramètres de configuration.
- Sélectionnez Nouvelle source de données dans la barre de menu du gestionnaire pour créer une source de données personnalisée.
- Nommez la source par exemple Custom_DataSource.
- Donnez lui une description précise par exemple : Custom DataSource used for report subscriptions.
- Cochez la case Activer cette source de données.
- Sélectionnez Microsoft SQL Server dans la liste Type de connexion.
- Entrez la chaîne de connexion à la base de données CRM dans la zone de texte Chaîne de connexion, par exemple :
data source="<NomDuServeurSQLContenantLaBaseCRM>";initial catalog="<NomDeLOrganisation_MSCRM>"
Cela donne par exemple :
- Cochez Informations d'identification stockées en sécurité dans le serveur de rapports.
- Entrez un nom d'utilisateur et un mot de passe ayant accès à CRM.
- Cochez Utiliser comme informations d'identification Windows lors de la connexion à la source de données.
Cela donne par exemple :
- Validez en cliquant le bouton Appliquer.
- Revenez sur la liste des rapports Dynamics CRM 4 et sélectionnez le rapport sur lequel porte l' abonnement à réaliser.
- Sélectionnez l'onglet Propriétés.
- Sélectionnez Sources de données dans la zone de navigation à gauche.
Vous constatez que la source de données du rapport est par défaut MSCRM_DataSource qui se trouve dans le dossier 4.0. Remplacez cette source de données par celle personnalisée que vous venez de configurer.
- Cliquez Parcourir.
- Sélectionnez la source de données personnalisée Custom_DataSource en parcourant la hiérarchie de répertoires de l'organisation.
- Validez par OK.
- De retour dans l' écran de propriétés du rapport, cliquez Appliquer.
Troisième étape : configuration de l' abonnement au rapport Dynamics CRM
- Toujours sur le rapport concerné, basculez sur l' onglet Abonnements.
- Cliquez Nouvel abonnement dans la barre d' outils.
- Sélectionnez Messagerie comme option de remise du rapport.
- Entrez l' adresse email du ou des destinataires du rapport dans la zone A:
- Entrez éventuellement des destinataires en copie et copie cachée si besoin.
- Cochez Inclure un lien ou Inclure un rapport selon si l' utilisateur souhaite recevoir le rapport en pièce jointe ou directement dans le corps du message.
- Sélectionnez le format du rapport de votre choix.
- Planifiez l 'abonnement pour une réception hebdomadaire par exemple en cliquant Sélectionnez une planification.
- Configurez manuellement les paramètres de rapport dont vous auriez besoin.
Cela donne par exemple :
- Terminez en cliquant sur OK.
- Vous pouvez consulter votre abonnement dans la liste des abonnements et voir notamment la date de sa dernière exécution et l' état correspondant.
Quelques liens utiles :
Le cinquième atelier du coach VB.NET 2008 est en ligne à cette adresse : http://msdn.microsoft.com/fr-fr/vbasic/msdn.coachvb.atelier5.aspx
Dans la lignée de l'atelier 4 qui traitait de la manipulation de données de fichier, ce cinquième atelier pose les bases de l'accès aux données stockées cette fois en base de données.
Donc, si vous ne savez pas du tout comment vous y prendre pour accéder à des données en base à partir d'une application écrite en VB.NET, cet atelier est pour vous
. Il comprend des exemples d'accès à une base SQL Server Express 2005 et une base Microsoft Office Access 2007.
A vos claviers !
Les 10 derniers blogs postés
-
Intégration Yammer et SharePoint Online (Office 365), étape 1 … par
Le blog de Patrick [MVP SharePoint] le 06-12-2013, 17:37
-
[Dynamics CRM] Ajouter les dossiers de CRM au dossier Favoris d’Outlook par
Christine Dubois le 06-10-2013, 15:50
-
Visual Studio 2013 par
Etienne Margraff le 06-04-2013, 10:26
-
Configurer la collation SQL Server pour SharePoint par
Blog de Jérémy Jeanson le 06-03-2013, 19:48
-
Etendre le Team Web Access de TFS 2012 – Step 1: Création du plugin par
Philippe Didiergeorges Aka Philess le 06-03-2013, 07:30
-
Livre Blanc : Développer des applications NUI par
Fathi Bellahcene le 06-01-2013, 11:35
-
[Dynamics CRM 2011] Copier une vue d'entité par
Christine Dubois le 05-29-2013, 13:20
-
[Conf’SharePoint 2013] Mes présentations… par
Le blog de Patrick [MVP SharePoint] le 05-28-2013, 09:04
-
[wpdev] Storage bug in MediaLibrary.SavePicture par
Kévin Gosse le 05-26-2013, 19:08
-
VMMap en mode instrumentation sur système 64bit : attention à la plateforme cible du build .NET par
CoqBlog le 05-25-2013, 22:25