Déploiement de Microsoft Dynamics CRM 4.0

Aaron Elder

À une vue d'ensemble :

• Composants logiciels d'un système CRM
• Le cycle de vie de développement
• Éléments d'une solution CRM
• Un coup de œil à multi-tenancy

Contenu

Le support de développement de solution
Éléments d'une solution CRM
Qu'en est-il Multi-Tenancy ?
Considérations de conception
Clé takeaways

Si vous avez utilisé pour réfléchir de CRM simplement un outil de gestion des ventes et marketing, pensez à nouveau.Microsoft Dynamics Customer Relationship Management est une plate-forme pour le développement d'applications qui gérer et suivre les informations et des processus liés à des objets réels.Ces objets peuvent être des clients, mais ils peuvent également être n'importe quel entité (et activités associées) que vous deviez gérer.

Comme avec toute solution personnalisée à grande échelle, il existe certains principes de base liés à un déploiement qui doivent être compris.Dans cet article, je vais pour couvrir les quelques concepts fondamentaux liés à Microsoft Dynamics CRM déploiement, notamment comment ces concepts peuvent servir à prendre en charge un déploiement de cycle de vie du produit complet.J'aborderai également Gestion des déploiements multiples d'une version de solution unique, et comment multi-tenancy doit et ne doit pas être utilisée dans le cadre du cycle de vie solution complète.

Je souhaite effectuer clair à la ligne sortante de cet article que lorsque je faites référence à un Microsoft Dynamics CRM "solution", je VEUX dire la totality de toutes les personnalisations, extensions, codage personnalisé, les changements de schéma et ainsi de suite.Une solution n'est pas une chose ; il toutes vos modifications est rassemblées.

En coulisses, une solution Microsoft Dynamics CRM est une application ASP.NET 2.0 et Microsoft .NET Framework 3.5 piloté par des données Web standard.Le système à trois niveaux inclut les composants principaux suivants :

niveau de données Base de données SQL Server 2005 ou SQL Server 2008.À l'aide de SQL Server 2008 requiert un correctif logiciel comme décrit dans l'article de base de connaissances »Prise en charge en cours d'exécution Microsoft Dynamics CRM 4.0 avec Microsoft SQL Server 2008."

Niveau intermédiaireMicrosoft Internet Information Services (IIS) 6.0 ou version ultérieure Web front end ; SQL Server Reporting Services (SRS) 2005 ou service de réplication de sites 2008 ; 3.5 ASP.NET ; Windows Services personnalisés.

Niveau clientInternet Explorer 6.0 ou version ultérieure client Microsoft ASP.NET 2.0 ou version ultérieure client Microsoft Office Outlook 2003 ou Office 2007 (avec facultatif accès hors connexion); d'autres tels que les consommateurs du Kit de développement logiciel (SDK) et les clients mobiles tiers.

Microsoft Dynamics CRM dépend également une variété de systèmes externes, y compris Microsoft Exchange Server 2003 ou version ultérieure et Active Directory.

Le support de développement de solution

Une solution Microsoft Dynamics CRM parcourt le cycle de même vie qui serait d'un projet de développement d'application personnalisée, qui pourrait ressembler comme le processus décrit dansLa figure 1 .

Figure 1, le développement d'applications cycle

Ce processus entier s'être pris en charge par plusieurs environnements qui forment ensemble les systèmes de développement, test et production.Dans le monde de toute application d'entreprise multifaceted, bien sûr, pouvez activer les à étonnamment complexe.Si, par exemple, vous deviez mettre en miroir les environnements, vous pouvez vous retrouver par quelque chose qui ressemble à la figure 2 .

La figure 2 mise en miroir les environnements-type, test et la production

C'est de trois domaines trois contrôleurs de domaine, les trois serveurs de messagerie, trois serveurs Web et trois base de données de serveurs, et ce modèle suppose que service de réplication de sites et CRM sont de la même zone, et il ne tient pas compte des éléments such as équilibrage de charge.Maintenant Imaginons vous ajouter redondance et quelques services externes tels que Microsoft Office SharePoint Services (MOSS), et vous pouvez vous retrouver avec un modèle semblable à celui de la figure 3 .

La figure 3 complexité augmentation

Pour des raisons de coût et la complexité, des compromis peuvent être considérés comme pour équilibrer la nécessité d'isolation d'environnement contre les nécessaire de conserver les coûts vers le bas et la simplicité de gestion des.Les organisations ont ainsi examiné à une variété de techniques, telles que la virtualisation et Microsoft Dynamics CRM fonctionnalités multi-tenancy intégrées pour résoudre ces défis.

Lorsque vous créez un ensemble d'environnements pour prendre en charge de cycle de vie de votre projet CRM, il y a plusieurs établissements of pensée et, selon les principes importants pour vous, peut choisie atteindre une façon ou l'autre.À un bout de la chaîne, concepteurs promouvoir isolation totale en utilisant la réplication exacte.Ces gens pensez que la seule manière valider que quelque chose fonctionne en dehors de la production est pour un environnement de test est identique à l'environnement de production à 100 %.Chaque serveur, chaque bit et tous les paramètres doivent être identiques et complètement isolé de développement et la production pour les testeurs et IT d'accepter et pensez que quelque chose fonctionneront dans la production.

En revanche, d'autres considérer ce genre d'isolation peu très du tout.Si elles pourrait, il serait développer et tester directement dans l'environnement de production.Ils ont tendance à voir la redondance comme un gaspillage de temps et de l'argent, et ils sont certains livraison serait être plus facile si elles peuvent uniquement obtenir dans cet emplacement et rendre les choses fonctionne.

Nous espérons que vous tombent quelque part entre ces extrêmes et va être ouverte à l'idée que lorsqu'il s'agit à une solution Microsoft Dynamics CRM, il est possible de développer un hybride des soldes de complexité, coût, d'isolation et la simplicité de gestion.

Éléments d'une solution CRM

Composants de solutions Microsoft Dynamics CRM peuvent être divisées en quatre compartiments principales, et votre solution peut-être inclure un, deux, trois ou toutes les quatre.

les personnalisations Elles comprennent modifications de formulaire, de grille, de schéma et de métadonnées ; rôles de sécurité ; les flux de travail ; paramètres système et modèles.Personnalisation de Microsoft Dynamics CRM est fournis par un ou plusieurs (généralement une ou deux) compressés XML fichiers.Ils sont importées dans un déploiement CRM via le client Outlook ou Web « Settings | Customization » zone et puis sont « publiés » pour les rendre actif.Tout ceci peut être automatisée l'aide de code est écrit pour le Kit de développement SDK de Microsoft Dynamics CRM.

les extensions Ceux-ci incluent les rapports et code personnalisé comme plug-ins qui doit être déployé séparément les personnalisations.Informations plug-in d'enregistrement sont stockées en tant que fichier XML et peuvent être déployées via soit une ligne de commande ou application Windows Forms fourni par Microsoft.Cela peut également être automatisé via le code écrit pour le Kit de développement SDK de Microsoft Dynamics CRM.

code personnalisé Quoi que ce soit développé dans le cadre de votre solution, et elle peut se composer d'externe services Web, personnalisé composants d'application Web et ainsi de suite.Les règles et les méthodes recommandées pour déployer le code personnalisé doivent être non différentes pour tout autre application Web personnalisée.

données Toute information qui doit être importé dans un environnement pour cet environnement de la fonction.Ce peut-être inclure des données de domaine (comme une liste des codes produits) ou les utilisateurs.Les données que votre solution doit peuvent être déployées dans votre instance de Microsoft Dynamics CRM code script ou fonctionnalité Importation en bloc de CRM ou avec une forme de processus externes à l'aide de BizTalk ou un autre outil ETL (extraction, transformation, charge).Certaines données, telles que les utilisateurs, doivent être créé manuellement ou via des appels de Microsoft Dynamics CRM SDK.

J'aime à penser de déploiements de solution CRM uniquement comme s'il s'agissait déploiements de développement d'application personnalisée.Cela signifie que lors du développement et test, chaque nouvelle version de la solution est installée à partir un système de base en mode minimal et le processus est aussi reproductibles et scripts que possible.

Qu'en est-il Multi-Tenancy ?

Maintenant nous allons aborder quoi doit ressembler l'environnement, vous allez déployer dans.Vous pouvez ont Découvrez la prise en charge Enterprise Edition de Microsoft Dynamics CRM 4.0 pour une fonctionnalité appelée multi-tenancy, qui permet de partition plusieurs instances de Microsoft Dynamics CRM dans un déploiement unique.Cela signifie qu'aux plusieurs complètement distinctes organisations disposant de leurs propres rapports, flux de travail, les personnalisations et schémas peuvent être s'exécuter sur le même jeu de matériel en utilisant les mêmes serveurs physiques et les instances de la base de données même et sites Web IIS.

Au premier coup de œil, cela peut apparaissent à la panacée qui résout tous nos facilité de gestion, d'isolation, et coût conundrums.Une telle solution peut visualiser comme dans la figure 4 .

Figure 4 une solution multithread tenancy--uniquement

Cela semble logique, car chaque organisation obtient son propre base de données physique sur le serveur SQL partagé ou instance (qui comprend personnalisations, flux de travail, les utilisateurs, rôles et paramètres) et son propre dossier SQL Reporting Services.

Ce fonctionne modèle parfaitement bien si ces organisations distinctes font partie d'autre équipe ou des solutions départements.Après tout, est le multi-tenancy a été conçu pour.S'il est vrai que chaque organisation (ou locataire) Obtient sa propre base de données, elles partagent les même unité d'organisation (UO) et les groupes Active Directory et qu'ils sont tous partagent les mêmes services de plate-forme et application frontale ainsi.Cela signifie que le site Web IIS et de même service asynchrone seront partagées entre organisations.Les serveurs frontaux peuvent à « ordinateur hôte » ces différentes organisations via un fournisseur URL qui détermine, en fonction de l'URL, le entreprise à ordinateur hôte.

Prendre ces URL comme exemple : crmserver/ContosoDevOrg/loader.aspx et crmserver/ContosoTestOrg/loader.aspx.Le serveur CRM recherche dans le répertoire racine pour déterminer le nom de l'organisation pour répondre à des.Si aucun nom d'organisation racine n'est trouvé, comme dans le cas de crmserver/loader.aspx, le serveur par défaut la première organisation créée dans le déploiement ou de l'endroit où l'utilisateur appelant a accès.

Étant donné que le même site Web est utilisé pour les organisations, si vous avez un code personnalisé dans le cadre de votre solution, il trop sera partagé par deux organisations ; par exemple, les crmserver/ContosoDevOrg/ISV/mycustomdialog.aspx et les crmserver/ContosoTestOrg/ISV/mycustomdialog.aspx.

Les deux pointer vers le même fichier physique sur disque, tels que C:\inetpub\wwwroot\isv\mycustomdialog.aspx.Car il est probable que la version d'une extension personnalisée est différente entre développement, test et production, cela peut poser un problème grave.Supposons, par exemple, que 11 de création de votre application est actuellement en cours développé, pendant 9 créer UAT (acceptation tests utilisateur) pour le test.Si vous essayez d'utiliser multi-tenancy pour résoudre votre problème d'environnement, vous aurez une heure dur isolant ces deux versions.Dans ce cas, certains d'entre vous peuvent être tenté essayez la solution illustrée figure 5 .

La figure 5 tentative pour utiliser les différents serveurs IIS à segregate votre code de solutions personnalisées

Dans ce modèle (si vous utilisez n'est plus l'adresse d'équilibrage de la charge réseau), les utilisateurs peuvent accès une URL qui ressemble à ceci :

Développement192.168.1.100/ContosoDevOrg/loader.aspx

Test192.168.1.105/ContosoTestOrg/loader.aspx

Production192.168.1.110/Contoso/loader.aspx

Ce modèle vous permet d'avoir trois séparer les serveurs frontaux, hébergeant trois différentes organisations avec trois bases de code différent sur le disque.Tant qu'un utilisateur n'est pas par inadvertance a atteint l'organisation incorrecte sur le serveur incorrecte, tout devrait fonctionner parfaitement les.

Malheureusement, dans la mesure où tous les serveurs frontaux sont considérés comme une faisant partie de la même déploiement, difficultés commencent à se produire un peu plus downstream que vous pouvez réaliser au premier coup de œil.Cela fait devient un défi si votre solution utilise asynchrone plug-ins ou flux de travail, parce que pendant que vous pouvez contrôler quels serveurs vos utilisateurs accès, vous ne pouvez pas contrôler les service asynchrone va traiter les événements et demandes concernant les organisations.

Cela est dû au fait que tous les services asynchrones dans un déploiement fonctionnent de manière à tour, et, en tant que tel, service asynchrone de votre serveur de développement peut traiter un flux de travail, travail système ou asynchrone réponse plug-in à une demande de votre serveur test, donc faire l'isolation demande prêts à l'eau.En outre, si votre code personnalisé qui s'exécute par ce processus asynchrone repose sur les fichiers qui doivent être déployés sur disque pour le serveur (tel qu'un fichier de configuration ou un fichier dans le Global Assembly Cache, ou le cache d'assembly global), vous obtiendrez les conflits de version.

Il est important de noter que, pour l'essentiel, ces problèmes surviennent uniquement lorsque vous écrivez un code personnalisé qui doit être déployé sur le disque ou si votre code personnalisé repose sur les ressources qui serait disponibles uniquement sur ou à partir d'un serveur particulier.Si votre solution est simple et utilise uniquement les personnalisations (schémas, formulaires, affichages, etc.), les flux de travail et les états, vous n'avez pas les problèmes avec l'approche dans la figure 4 .

Ainsi, quelle est multi-tenancy pour et il est quand une bonne solution pour les environnements cycle de vie du produit ?Multi-tenancy a été créé pour résoudre un problème matériel lié à l'hébergement de plusieurs domaines distincts dans un environnement de production, et cela très bien.Auparavant, dans Microsoft Dynamics CRM 3.0, chaque déploiement ou locataire, devaient avoir son propre serveur SQL dédié ou instance de SQL Server, ainsi qu'un serveur frontal.

Cela a pour de nombreuses raisons, notamment le fait que les paramètres de déploiement-spécifiques utilisés pour être enregistrées dans le Registre et sur le disque.Tous ces configurations ont maintenant déplacés vers la base de données, un serveur d'applications unique est en mesure de gérer plusieurs organisations.Multi-tenancy est utile pour les versions hébergées de CRM, y compris Microsoft Dynamics CRM Online.

Considérations de conception

Maintenant que vous êtes conscient de certains problèmes potentiels, nous allons explique quelques points à garder à l'esprit lorsque vous créez votre déploiement.La réponse, bien sûr, est qu'elle dépend.Il est certainement possible d'exécuter un environnement CRM complet (y compris le contrôleur de domaine, le SQL server et le serveur Web) sur une seule zone, comme vous pouvez le voir à la démonstration de Microsoft Dynamics CRM 4.0 Virtual Machine (voir l'encadré « Ressources CRM » pour l'URL).Il est très fréquent à utiliser une image virtuelle seul ordinateur pour un environnement de développement.Pour test, cependant, il est important pour valider l'environnement de production clé défis, et, pour cette raison, je recommande que votre miroir d'environnement de test votre environnement de production en termes de structure mais pas la capacité.Votre environnement peut ressembler à celle de la figure 6 .

La figure 6 de la structure d'environnement de test doit refléter la structure de production

Dans cette approche, vous essayez réduire matériel physique de l'infrastructure à l'aide de la virtualisation et plus tente de réduire les ressources de la virtualisation en virtualiser uniquement les scénarios clés qui doivent être testés.Vous pourrez permettant à vos développeurs à développer sur une image serveur unique (ou images) si elles ont leur propre ordinateur virtuel sur leurs ordinateurs personnels si vous vérifiez qu'ils sont attention et être conscient de l'environnement qui sera déployée leur solution.Les problèmes que les développeurs doivent payer l'attention sur sont les mêmes problèmes que vous devez générer votre environnement de test pour valider, y compris :

Vérifiez les paramètres configurableNe le faites pas, par exemple, supposons que le serveur répond aux hôte local ou un port particulier.

Être Aware de plusieurs serveursNe pensez pas fonctionnent sans configuration utilisateurs proxy ou approbation pour la délégation de sorte que les choses.

conserver l'équilibrage d'idées de charge Soyez très prudent avec état de session et la mise en cache.Notez que Microsoft Dynamics CRM est conçu pour être complètement sans état et travailler avec un équilibreur de charge à tour.

pensez à Multi-Tenancy Lorsque plusieurs domaines sont hébergés sur un seul ordinateur, elles partagent le même espace de processus.Cela signifie que éléments comme les caches doivent gérés par le nom d'organisation afin que les utilisateurs d'une organisation pas par inadvertance utilisera données d'une autre organisation.En outre, lorsque vous avez code côté client qui a des liens ou des appels vers le serveur, vous devez pour vous assurer que les appels de conserver le nom de l'URL de l'organisation ; dans le cas contraire, vous pouvez appuierez sur l'organisation par défaut ou une organisation que vous ne prévoyez pas.

Ressources CRM

Guide de mise en Œuvre de Microsoft Dynamics CRM 4.0

Microsoft Dynamics CRM 4.0 comme une plate-forme de développement Applications professionnels

Blog de l'équipe Microsoft Dynamics CRM

Microsoft Dynamics CRM 4.0 ordinateur virtuel

Optimisation et maintenance de Microsoft Dynamics CRM 4.0

Clé takeaways

Isolation est important Lorsque vous créez votre solution, tenez compte quelle approche (comme illustré dans chiffres 4, 5 ou 6) est la plus adaptée à votre place et savoir quand et où votre code personnalisé peut s'exécuter.Il est également important de noter lorsque vous ne souhaitez pas soucier de tels problèmes en raison du type de votre solution utilise les extensions.

la virtualisation La virtualisation permet de réduire la complexité de la création d'un environnement qui reflète les scénarios de test clé de production.Voici quelques conseils concernant l'installation.Placez CRM et SQL Server sur des serveurs distincts.Cela permet de vérifier Approbation pour délégation et autres problèmes connexes.Serveurs CRM doivent est à équilibrer la charge, qui s'identifier session, la mise en cache et problèmes inter-serveur.Enfin, placez le contrôleur de domaine et le courrier électronique sur des serveurs distincts ; cela permet d'identifier les problèmes de connectivité.

Actualiser l'environnement pour chaque version En règle générale, il est judicieux pour créer des sauvegardes des environnements virtuels ou simplement des bases de Microsoft Dynamics CRM données (données et de configuration) qui peuvent ensuite être restaurés pour obtenir le serveur sauvegarder sur un état « vanille.Vous procédez ensuite un déploiement complet en mode minimal dans un environnement de nouvelle chaque fois, y compris les personnalisé des données de code, les personnalisations plug-ins et domaine.

Test de redondance/performances peut être effectué séparément Sauf pour les très grandes organisations, vous pouvez généralement résoudre basculement et les performances test via isolées des simulations et non via coulisses génération « réelle ».Cela signifie qu'il n'est pas nécessaire tenter de créer d'un environnement de test permettant de test de ces scénarios.En guise d'alternative, vous pouvez compter sur les tests en production ou dans des environnements isolés distincts.

Dans la clôture, Microsoft Dynamics CRM est un système Entreprise évolutives, qui, lorsque correctement configuré et déployé, peut traiter petites équipes, les solutions à l'échelle de l'entreprise et chaque option entre.Essayez de déterminer quel environnement cycle de vie du produit est de droite pour vous dépend de différents facteurs.

En général, multi-tenancy n'est pas un moyen idéal pour résoudre les défis produit cycle de vie du développement de solutions complexes et est mieux utilisé lorsqu'il est entièrement compris.Solutions simples qui ne nécessitent que personnalisation simple ou qui effectuer utiliser correctement codées isolées personnalisées extensions et qui ne dépendent de ressources de disque ou spécifiques au serveur accès doit faire bien après le modèle mentionné dans la figure 4 .

Si votre solution exige plus isolation, ressources spécifiques au serveur ou accès (par exemple un service externe est autorisé uniquement via votre réseau local virtuel d'un serveur spécifique à un autre), et c'est le cas forth, je recommande passer avec le modèle illustré figure 6 .Et je souhaitez recommande d'éviter l'approche qui figure 5 illustre, comme c'est un piratage hybride au mieux.

Au final, Microsoft Dynamics CRM peut être déployée en milliers de configurations, et exactement ce qui convient pour vous varient selon votre solution nécessite.Avec un mieux comprendre multi-tenancy, environnements de développement de serveur unique, environnements de test virtuel, et quels scénarios de tests sont importants pour vous, vous devriez pouvoir créer un déploiement de cycle de vie de produit qui est fonctionnelle et rentable.

Aaron Elder (MVP Microsoft Dynamics CRM) fonctionne pour Ascentium, une technologie de conseil et d'interactive agence marketing.Consulter le blog Ascentium àAscentium.com/blog/CRM.