ALM – Industrialisation des développements CRM – Solution de développement CRM


Une fois que votre infrastructure de développement est en place, que l'équipe est au complet et que les premiers ateliers fonctionnels ont commencés, il ne reste plus qu'à initialiser la phase de développements !

Comment sont composés les développements CRM ?

Tout d'abord, il faut bien déterminer les différents niveaux de développements :

  1. Paramétrages : Il s'agit ici de la configuration spécifique apportée à l'organisation (ex : numérotation automatique, paramètres régionaux …)
  2. Personnalisations : Désigne toutes les opérations liées aux entités, vues, tableaux de bord, …
  3. Développements : Concerne tous les éléments éditable dans Visual Studio, à savoir : plugins, workflows, webresources, …

Les paramétrages et personnalisations doivent être réalisés dans l'interface CRM dans une solution spécifique.
Une fois les modifications appliquées et publiées, il est possible de les exporter de CRM (fichier compressé .zip) pour les livrer dans les autres environnements.

Les développements (c#, js …) sont déclarés dans la solution CRM mais doivent être réalisés dans Visual Studio.
Ces développements sont de plusieurs types (en très synthétique) :

  • Plugins / Workflows : Extensions des processus CRM par le biais d'assemblies (dll) qui sont développés en C#.
  • Webresources : Extensions de l'interface CRM par le biais de pages HTML et de fichiers JavaScript (js).
  • Rapports : Rapports SSRS (rdl) réalisés avec SSDT Business Intelligence for Visual Studio
  • Batchs : Processus permettant le chargement et la reprise de données (en c#, Powershell, ou SSIS)

Pour optimiser les développements, tous ces éléments doivent être gérés depuis une même solution technique, cela simplifiera la gestion du cycle de vie des différents composants.

Comment architecturer les développements CRM ?

L’objectif est de structurer les développements de manière à faciliter la maintenance et exploiter au maximum les couches réutilisables.
Que vous développiez un plugin, un workflow ou un batch, vous allez probablement réaliser des opérations qu’il est possible de centraliser.
Une bonne pratique consiste donc à rendre les couches suivantes centrales :

  • Modèle : Couche contenant la description du métadata CRM (Entités, OptionSets, …)
  • Services : Couche logique contenant les processus métiers

Ce qui donne le diagramme de dépendances suivants :

image

Par la suite, dans le but de réaliser des tests unitaires sur le code, on peut envisager d’ajouter une couche d’abstraction (interface) qui dériverait la couche de service vers une couche “bouchon” (mock) ;

image

En adoptant ce type d’architecture technique, il est possible de garantir un taux de couverture de code très élevés si l’on décentralise un maximum des traitements dans la couche de services.

Et ensuite ?

Ensuite, il faut structurer la solution de façon logique :

image

 

Late Bound ou Early Bound ?

Afin d’architecturer au mieux vos développements, il faut déterminer le mode de liaison pour la couche Model : Early Bound ou Late Bound.
Ce mode caractérise la manière donc on manipule les entités CRM au travers du code :

  • Early Bound : Les classes représentés les entités sont générées avec CrmSvcUtil et peuvent être utilisés dans le code comme des objets.
  • Late Bound : Les entités sont manipulables par le biais de la classe Entity et l’on accède aux champs via un dictionnaire en mentionnant explicitement le nom.

L’avantage du mode Early Bound est la capacité à manipuler les objets simplement et d’avoir l'IntelliSense dans VS, mais l’avantage du mode Late Bound est un gain important en terme de performance.

Par expérience nous préconisions le mode Late Bound et l’utilisation de l’outil CRM Model Generator pour s’approcher au maximum des avantages du Early Bound.

 

Les articles de la série “ALM - Industrialisation des développements CRM” :

  1. Définition de l'équipe projet
    Quels sont les différents rôles des membres d'une équipe de développements ?
  2. Team Foundation Server (TFS)
    Qu'est-ce que TFS ? Comment cet outil peut-il nous aider ?
  3. Organisation des développements
    Entre les spécifications et la solution finale, comment distribuer efficacement les taches et suivre l'avancement ?
  4. Architecture technique
    Comment définir une infrastructure de développement "type" appropriée et suffisamment flexible pour supporter les différentes activités des développeurs ?
  5. Solution de développement CRM
    Qu'impliquent ces développements et comment les structurer ?
  6. Activités de développement et outils
    Que font les développeurs ? Comment minimiser leur effort ?

Les équipes Microsoft Services se tiennent prêtes à vous accompagner tout au long de la mise en place de votre outil CRM. Pour en savoir plus, n'hésitez pas à nous contacter, via notre formulaire de contact ou à l'adresse : servicesfr@microsoft.com.

 

Comments (0)

Skip to main content