Une nouvelle fonctionnalité pour gérer les clés métiers dans Microsoft Dynamics CRM 2/2

Dans l'article précédent, Une nouvelle fonctionnalité pour gérer les clésmétiers dans Microsoft Dynamics CRM 1/2, nous avons présenté une des nouvelles fonctionnalités de Microsoft Dynamics CRM, les clés additionnelles. Nous avons notamment montré les aspects fonctionnels de cette nouveauté qui nous permet de gérer des clés métiers dans le CRM telles qu'un code client, un numéro de compte… et qui permet également de garantir leur unicité sans saisir une ligne de code. La notion de clé additionnelle peut servir également côté technique et c’est dans cette seconde partie que j'aimerais vous montrer, à travers des exemples, à quel point l'écriture du code de mise à jour des enregistrements est devenue très simple grâce à cette nouveauté technico-fonctionnelle.

Cette nouveauté nous permet de cibler un enregistrement CRM à l'aide d'une ou de plusieurs clés additionnelles- qui sont des clés fonctionnelles- à la place d'un identifiant unique GUID. Nous ne sommes donc plus obligés de faire des RetrieveMultiple ou des requêtes Linq pour retrouver l'identifiant unique GUID par rapport à un numéro de compte ou d'autres données fonctionnelles afin de mettre à jour des enregistrements.

Afin d'illustrer cela, je vous propose les exemples de code suivants :

Pour commencer, je crée un nouveau compte avec comme numéro de compte la valeur 12345

Avant de continuer, je vérifie que mon nouveau compte JAVISTA a bien été créé dans le CRM :

Ensuite, je vais mettre à jour le compte JAVISTA en utilisant la clé additionnelle "numéro de compte" ; pour cela, je vais créer une instance de la classe Entity à l'aide du nouveau constructeur suivant :

public Entity (string logicalName, string keyName, object keyValue) {…}

Ce constructeur prend en guise de paramètres, le nom de l'entité à mettre à jour, le ou les champs composants la clé additionnelle de l'entité, et le ou les valeurs correspondant à la clé additionnelle.

Comme vous le remarquez ci-dessus, j'ai fait un update à partir d'un objet qui n'a pas d'identifiant unique GUID, au lieu donc de chercher et d’utiliser l'identifiant unique qui est normalement essentiel pour faire une mise à jour. J'ai pu travailler directement avec l'identifiant fonctionnel de l'entité Compte, le "accountnumber".

Vérifions dans le CRM si notre compte JAVISTA est à jour :

Maintenant, je vais essayer de créer un autre compte avec la même clé que précédemment, 12345, pour voir si le CRM va bloquer ou pas la création d'un deuxième compte avec le même identifiant fonctionnel Numéro de compte :

Effectivement, comme vous le remarquez, le CRM renvoie une exception avec un message d'erreur qui m'indique qu'il n'est pas possible de créer deux enregistrements CRM avec le même identifiant.

Grâce à cette nouveauté nous allons vraiment éviter de faire des requêtes intermédiaires pour mettre à jour des enregistrements, ce qui rend donc l'écriture du code plus simple et plus rapide.