Architecture applicative Dynamics CRM 2011

  • Article

Introduction

Microsoft Dynamics CRM (Customer Relationship Management) est une solution permettant de gestion de la relation client en entreprise. Alliant le marketing, la vente (Sales Force Automation) ainsi que le service, cette solution permet la gestion complète de la relation client ainsi que l’automatisation de certain processus.

La solution Dynamics CRM 2011 est disponible Online et en OnPremise. Cet article est spécifique à Dynamics CRM OnPremise.

 

Cet article fait partie d’une série d’articles sur l’architecture, la haute disponibilité et la scalabilité d’une infrastructure Dynamics CRM. Dans ce premier article, nous verrons en première partie les composants de l'architecture applicative du CRM.

 

 

Rappel de l'architecture applicative de Dynamics CRM 2011

L’architecture applicative d’une plateforme MS Dynamics CRM 2011 est décrite dans le schéma suivant :

 

 

 

Les composants applicatifs de la plateforme CRM sont décrits plus en détail sur
MSDN à l’adresse: https://msdn.microsoft.com/en-us/library/hh547453.aspx

 

Les composants CRM : rappel des rôles et utilisation

Serveur frontal

Ce rôle héberge l’application Web Dynamics CRM, les services Web de découverte, d’organisation et le serveur d’aide.

- Service Web de découverte : Ce service  recherche l’organisation à laquelle un utilisateur appartient dans un déploiement à plusieurs organisations.

- Service Web d’organisation a pour rôle de prendre en charge l’exécution des applications utilisant les méthodes décrites dans le Microsoft Dynamics CRM Software Development Kit.

- Serveur d’applications Web : Exécute le Serveur d’applications Web qui sert à connecter les utilisateurs aux données Microsoft Dynamics CRM. Le rôle Serveur  d’applications Web requiert le rôle Service Web d’organisation.

- Serveur d’aide : Met l’Aide de Microsoft Dynamics CRM à disposition des utilisateurs.

L’ensemble de ces services sont installés dans un site Web IIS dédié.

Serveur Asynchrone

Ce rôle héberge le service asynchrone. Il traite les événements asynchrones tels que l’envoi de message en nombre, l’importation des données…

Ce service est responsable de l’exécution des Workflows et Plugins asynchrones.

Serveur SandBox

Ce rôle héberge le service SandBox ou «Bac à Sable».

Il constitue un environnement restreint permettant l’exécution des plug-ins. Cet environnement (Bac à Sable) réduit les risques et empêche les problèmes, qui se produisent lors de l’exécution, d’affecter le reste de l’environnement CRM.

L’utilisation des solutions Bac à Sable est fortement recommandée lorsque la charge des solutions doit être répartie sur plusieurs serveurs du CRM.

La solution Bac à Sable peut également être utilisée à des fins de tests pour exécuter du code sur une solution CRM n’ayant pas été testée précédemment.

A noter que les traitements s’exécutant en Bac à Sable n’ont pas la possibilité de :

- Se connecter aux ressources qui ne se trouvent pas sur le serveur local via un protocole autre que HTTP/HTTPS.

- Accéder à une base de données

- Appeler du code non géré par CRM

- Ecrire sur le disque

- Accéder à des ressources qui se trouvent dans une autre organisation que celle qui exécute la solution.

Serveur d’administration et de déploiement

Ce rôle héberge le service Web de déploiement ainsi que les outils de déploiement.

- Le service Web de déploiement gère le déploiement en suivant les méthodes décrites dans le Microsoft Dynamics CRM 2011 Deployment Software Development Kit (SDK).

- Les outils de déploiement sont constitués du gestionnaire de déploiement et des applets de commande Windows PowerShell.

  • Les applets de commande Windows PowerShell peuvent être utilisées par les administrateurs du CRM pour automatiser les tâches du Gestionnaire de déploiement.
  • Le gestionnaire de déploiement constitue un composant logiciel enfichable -Microsoft Management Console (MMC)- qui permet aux administrateurs de système de gérer les organisations, les serveurs et les licences lors des déploiements CRM.

Serveur de base de données

SQL Server est installé sur ce serveur. Ce serveur héberge la base de configuration CRM et les bases de données d’organisation CRM.

Serveur Reporting

Ce server héberge SQL Server Reporting Services (SSRS) ainsi que les extensions Reporting de Dynamics CRM.

Le SQL Server Reporting Services (SSRS) fournit une gamme complète d'outils et de services qui permet de créer, déployer et gérer des rapports ainsi que des fonctions de programmation. Ces fonctionnalités permettent de créer des rapports personnalisés.

Les extensions de création de rapports de Dynamics CRM assurent l’intégration entre Dynamics CRM et Reporting Services. Elles permettent de créer, utiliser et planifier des rapports dans Dynamics CRM. Les extensions de création de rapports de Dynamics CRM sont requises pour créer ou importer une organisation dans un déploiement Dynamics CRM.

Les extensions de création de rapports de Dynamics CRM sont installées sur les serveurs Reporting Services, elles acceptent les informations d’authentification provenant de Dynamics CRM Server 2011 et les transmettent au serveur SQL Server Reporting Services (SSRS) ce qui évite de mettre en place une délégation Kerberos entre les serveurs CRM et les serveurs Reporting.

L’installation des extensions de création de rapports de Dynamics CRM contient deux extensions de traitement des données : l’extension de traitement des données Fetch et l’extension de traitement des données SQL.

  • L'Extension pour le traitement des données Fetch est requise pour créer, exécuter et planifier des rapports Fetch dans Microsoft Dynamics CRM 2011.
  • L'Extension pour le traitement des données SQL est requise pour planifier des rapports SQL dans Microsoft Dynamics CRM 2011.

Ces extensions sont installées par défaut au cours de l’installation des extensions de création de rapports de Dynamics CRM.

Serveur Email Router

Ce rôle héberge le service Email Router. Ce service est responsable de l’envoi et la réception d’emails dans CRM.

L’installation de Dynamics CRM E-mail Router est composée de deux éléments principaux : l’E-mail Router et l’Assistant Déploiement de règles.

- Le composant E-mail Router installe le service E-mail Router et le Gestionnaire de configuration d’E-mail Router. Le gestionnaire de configuration d’E-mail Router permet de configurer l’E-mail Router.

- Le composant Assistant Déploiement de règles déploie les règles qui permettent d’assurer le suivi des emails reçus.

 

Haute disponibilité des composants CRM

La haute disponibilité d’une plateforme Dynamics CRM est assurée par la redondance des serveurs. En cas de panne d’un serveur le deuxième serveur prend le relais. Cette action se produit de manière transparente pour les utilisateurs.

Serveur frontal

 Les serveurs frontaux CRM se basent sur le serveur Web IIS. Ces serveurs peuvent être configurés en équilibrage de charge matériel (Hardware Load-Balancing) ou logiciel (Network Load-Balancing).

A noter que le HLB opère au niveau 4 de la couche réseau tandis que le NLB opère au niveau 3. Ainsi, le NLB ne considère qu’un serveur CRM n’est plus disponible que si le serveur n’est plus joignable via le réseau.

L’équilibrage de charge matériel est en général préconisé pour améliorer les performances de l’application CRM.

Certains boitiers d’équilibrage de charge (ex. BigIp de F5) intègrent des modules de cryptage/décryptage SSL, ce qui permet de décharger les serveurs CRM de cette tâche.

Il est fortement recommandé de mettre en place le Management Pack de SCOM (System Center Operations Manager) avec l’équilibrage de charge réseau (NLB). En cas d’indisponibilité d’un serveur CRM, le Management Pack de SCOM va le retirer de la configuration NLB via un script afin de ne plus recevoir de requêtes. 

Serveur Asynchrone 

La haute disponibilité du service asynchrone est assurée par la redondance des serveurs asynchrones. Il est possible de mettre en place plusieurs serveurs asynchrones sans équilibrage de charge. Toutefois, il n’est pas recommandé de mettre plus que 3 serveurs asynchrones sur la même ferme CRM.

Le service asynchrone fonctionne en mode Pull. Ceci se traduit par le fait que le service initie la requête et récupère les tâches à faire depuis le serveur SQL.

Serveur SandBox

Dans le cas du rôle SandBox, la haute disponibilité du service est également assurée par la redondance des serveurs SandBox.

L’équilibrage de charge est assuré par la plateforme CRM. Dynamics CRM utilise un algorithme basé sur Round-Robin afin de répartir la charge sur plusieurs serveurs SandBox.

Serveur d’administration et de déploiement

Dans le cas du serveur d’administration et de déploiement, l’équilibrage de charge est nécessaire pour les services Web de déploiement.

Il est recommandé de mettre en place deux serveurs avec un équilibrage de charge matériel ou logiciel (HLB/NLB) pour assurer la haute disponibilité du service.

Serveur Reporting

Les serveurs Reporting CRM sont configurés en équilibrage de charge matériel ou logiciel (HLB/NLB).

L’équilibrage de charge matériel est en général préconisé pour améliorer les performances du service Reporting.

Certains boitiers d’équilibrage de charge (ex. BigIp de F5) intègrent des modules de cryptage/décryptage SSL, ce qui permet de décharger les serveurs SSRS de cette tâche.Il est fortement recommandé de mettre en place le Management Pack de SCOM (System Center Operations Manager) avec l’équilibrage de charge réseau (NLB). En cas d’indisponibilité d’un serveur Reporting, le Management Pack de SCOM va le retirer de la configuration NLB via un script afin de ne plus recevoir de requêtes.

Serveur Email Router

Pour assurer la haute disponibilité du service, il est nécessaire de configurer les serveurs Email Router en cluster Windows actif /passif. La mise en cluster du service Email Router est documentée sur Technet https://technet.microsoft.com/fr-fr/library/hh699708.aspx.

Il n’est pas possible de faire du scale-out pour ce rôle. Pour améliorer les performances de ce service, il faut évoluer la configuration matérielle de ce serveur (augmentation de RAM, CPU).

Serveur de base de données (SQL Server)

Selon la version de SQL Server utilisée, vous avez plusieurs options pour assurer la haute disponibilité du serveur SQL :

- Un Failover cluster Windows Actif/Passif sur SQL Server 2008/2012

- Mirroring synchrone avec témoin (SQL 2008 R2)

- SQL Server 2012 AlwaysOn Availability Groups

Note: AlwaysOn Availability Groups est la nouvelle solution de haute disponibilité et de récupération après sinistre de SQL Server 2012.

Conclusion

Dans cet article, nous avons traité l’ensemble des éléments constituant l’architecture applicative d’un CRM, ainsi qu’une description de la haute disponibilité des serveurs CRM.

Dans cette série, nous détaillerons dans notre prochain article les avantages d’utilisation de SQL Server AlwaysOn Availability Groups pour assurer la haute disponibilité et améliorer la scalabilité d’une ferme CRM.

 

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 .