Implementación de Microsoft Dynamics CRM 4.0
Aaron Elder
En resumen:
- Componentes de software de un sistema de CRM
- El ciclo de vida de desarrollo
- Elementos de una solución CRM
- Un vistazo a multi-tenancy
Contenido
El ciclo de vida desarrollo de soluciones
Los elementos de una solución CRM
¿Qué sucede Multi-Tenancy?
Consideraciones acerca del diseño
Claves Takeaways
Si se utilizó para pensar de CRM como sólo una herramienta de administración ventas y marketing, considere volver a. Administración de relaciones cliente con Microsoft Dynamics es una plataforma para desarrollar aplicaciones que administración y realizar un seguimiento información y procesos relacionados con objetos del mundo real. Estos objetos pueden ser los clientes, pero también pueden ser prácticamente cualquier entidad (y actividades relacionadas) que tiene que administrar.
Como con cualquier solución personalizada a gran escala, hay algunos conceptos básicos relacionados con la implementación que necesitan ser entendida. En este artículo, voy a cubrir unos cuantos conceptos fundamentales relacionados con la implementación de Microsoft Dynamics CRM, incluyendo cómo pueden utilizarse estos conceptos para admitir una implementación del ciclo de vida completo del producto. También explicará administrar varias implementaciones como parte de una versión única solución y cómo multi-tenancy deben y no debe utilizarse como parte del ciclo de vida de solución completa.
Desea convertir borrar el principio de este artículo que cuando hace referencia a Microsoft Dynamics CRM "solución", me refiero la totalidad de todas las personalizaciones, extensiones, codificación personalizada, los cambios de esquema etc.. Una solución no es sólo una cosa; es todos los cambios entre sí.
En segundo plano, una solución de Microsoft Dynamics CRM es una aplicación de ASP.NET 2.0 y Web de Microsoft .NET Framework 3.5 controladas por datos estándar. El sistema de tres niveles incluye los componentes principales siguientes:
nivel de datos Base de datos de SQL Server 2005 o SQL Server 2008. Uso de SQL Server 2008 requiere una corrección urgente tal como se describe en el artículo de Knowledge Base" Compatibilidad para ejecutar Microsoft Dynamics CRM 4.0 junto con Microsoft SQL Server 2008."
Nivel intermedio Microsoft Internet Information Services (IIS) 6.0 o posterior Web cliente, SQL Server Reporting Services (SRS) 2005 o 2008 de SRS; 3.5 ASP.NET; servicios de Windows personalizada.
Nivel del cliente Cliente Microsoft Internet Explorer 6.0 o posterior; ASP.NET 2.0 o posterior; cliente de Microsoft Office Outlook 2003 o 2007 de Office (con opcional acceso sin conexión); otros, como los consumidores SDK y los clientes móviles de terceros.
Microsoft Dynamics CRM también se basa en una variedad de sistemas externos, incluidos Microsoft Exchange Server 2003 o posterior y Active Directory.
El ciclo de vida desarrollo de soluciones
Pasa el ciclo de mismo vida que tendría un proyecto de desarrollo de aplicaciones personalizadas, que podría ser algo como muestra el proceso en una solución de Microsoft Dynamics CRM La figura 1 .
Figura 1 el desarrollo de aplicaciones de ciclo
Todo este proceso podría ser compatible con varios entornos que juntos forman los sistemas de desarrollo, prueba y producción. En el mundo de cualquier aplicación de empresa multifaceted, esto, por supuesto, puede activar fuera que sorprendentemente complejas. Si, por ejemplo, se reflejar los entornos, puede acabar con algo que parece la figura 2 .
La Figura 2 creación de reflejos de los entornos de desarrollo, prueba y producción
Que es tres dominios, tres controladores de dominio, tres servidores de correo, tres servidores Web y tres servidores de bases de datos, y este modelo supone que SRS y CRM están en el mismo cuadro, y no tiene en cuenta aspectos such as equilibrio de carga. Ahora vamos a imagine agrega redundancia y unos servicios externos, como Microsoft Office SharePoint Services (MOSS), y podría acabar con un esquema como la en la figura 3 .
La figura 3 aumentar complejidad
Por razones de costo y la complejidad, pros y contras pueden ser conveniente para equilibrar la necesidad de aislamiento de entorno frente a la necesidad de reducir los costos y facilidad de uso hacia arriba. Las organizaciones, por tanto, han observado en una variedad de técnicas, como virtualización y el Microsoft Dynamics CRM multi-tenancy características integradas, para afrontar estos retos.
Al diseñar un conjunto de entornos para admitir el ciclo de vida del proyecto CRM, hay varias ideas del escuelas y, en función de los principios son importantes para usted, puede elegir ir a una forma u otro. En un extremo del espectro, los diseñadores de promover aislamiento total mediante la replicación exacta. Estos gente cree que la única manera de validar que algo funcionará fuera de producción es tener un entorno de pruebas que es idéntico del entorno de producción en 100 %. Todos los servidores, cada bit y cada valor debe ser idénticas y completamente aisladas de desarrollo y producción de personal de pruebas y IT Aceptar y cree algo funcionará en producción.
En cambio, otros usuarios pensar dicha ordenación de aislamiento no importa en absoluto. Si puede, podría desarrollar y probar directamente en el entorno de producción. Tienden a ver la redundancia como una pérdida de tiempo y dinero, y son ciertas entrega sería más fácil si sólo puede obtener en ella y hacer las cosas funcionen.
Con suerte, se encuentran en algún lugar de entre estos extremos y se estar abierta a la idea que cuando se trata de una solución de Microsoft Dynamics CRM-, es posible desarrollar un híbrido que equilibre la complejidad, costo, aislamiento y facilidad de uso.
Los elementos de una solución CRM
Componentes de las soluciones de Microsoft Dynamics CRM pueden dividirse en cuatro sectores de almacenamiento principales, y su solución puede incluir cuatro uno, dos, tres o todos.
las personalizaciones Se incluyen los cambios de formulario, cuadrícula, esquema y los metadatos; las funciones de seguridad; flujos de trabajo; configuración del sistema; y las plantillas. Personalizaciones de Microsoft Dynamics CRM se proporcionan como uno o más (normalmente, uno o dos) en zip archivos XML. Se importan en una implementación de CRM a través del cliente de Outlook o Web área "Settings | Customization" y, a continuación, se "publican" para hacerlos activos. Todo esto se puede automatizar mediante código que se escribe en el SDK de Microsoft Dynamics CRM.
las extensiones Éstos incluyen informes y código personalizado, como los complementos que deben implementarse por separado de las personalizaciones. Información de registro de complemento se almacena como un archivo XML y se puede implementar a través de cualquier una línea de comandos o aplicación de Windows Forms proporcionados por Microsoft. Esto también se puede automatizar mediante código escrito en el SDK de Microsoft Dynamics CRM.
código personalizado Nada desarrollado como parte de la solución, y puede consistir externo servicios Web, personalizado los componentes de aplicación Web y así sucesivamente. Las reglas y recomendaciones para implementar el código personalizado deben ser no diferentes para cualquier otra aplicación Web personalizada.
datos Cualquier información que debe importarse a un entorno para ese entorno para funcionar. Esto puede incluir datos de dominio (por ejemplo, una lista de códigos de producto) o los usuarios. Los datos que necesita la solución se pueden implementar en la instancia de Microsoft Dynamics CRM con código de secuencias de comandos o característica de importación masiva del CRM, o con algún tipo de proceso externo mediante BizTalk u otra herramienta ETL (extracción, transformación, carga). Algunos datos, como los usuarios, debe crearse manualmente o mediante el SDK de Microsoft Dynamics CRM llamadas.
Desea considerar las implementaciones de solución CRM sólo como si fueran las implementaciones de desarrollo de aplicaciones personalizadas. Esto significa que, durante el desarrollo y prueba, cada nueva generación de la solución se instala desde un sistema limpio básico y el proceso es como repetible y secuencias de comandos como sea posible.
¿Qué sucede Multi-Tenancy?
Ahora vamos a discutir aspecto debería tener el entorno que se va a implementarlos en. Es posible que haya lea acerca de la compatibilidad de Enterprise Edition de Microsoft Dynamics CRM 4.0 en de una característica denominada multi-tenancy, que permite dividir varias instancias de Microsoft Dynamics CRM dentro de una única implementación. Esto significa que se pueden ejecutar varias completamente distintas organizaciones con sus propios informes, flujo de trabajo, las personalizaciones y esquemas en el mismo conjunto de hardware mediante los mismos servidores físicos y las instancias de la misma base de datos y sitios Web de IIS.
A primera vista, esto es posible que parece ser la panacea que resuelve todos de nuestra capacidad de administración, aislamiento, y costos conundrums. Se puede visualizar esta solución como en la figura 4 .
Figura 4 un solución múltiples tenancy--sólo
Esto parece lógico porque cada organización obtiene su propia base de datos física en el servidor de SQL compartido o instancia (que incluye las personalizaciones, flujos de trabajo, los usuarios, funciones y configuración) y su propia carpeta de SQL Reporting Services.
Este funciona modelo perfectamente bien si las distintas organizaciones forman parte de equipo diferentes o soluciones de departamentos. Después de todo, esto es qué multi-tenancy se diseñó para. Aunque es verdad que cada organización (o arrendatario) obtiene su propia base de datos, todos comparten la misma unidad organizativa (OU) y grupos de Active Directory, y se todos comparten los mismos servicios de plataforma y aplicación cliente. Esto significa que el mismo servicio asincrónica y el sitio Web de IIS se compartirán entre las organizaciones. Los servidores front-end son puedos a "host" estas organizaciones diferentes a través de un proveedor de dirección URL que determina, basándose en la dirección URL, la organización a host.
Tomar estas direcciones URL como un ejemplo: crmserver/ContosoDevOrg/loader.aspx y crmserver/ContosoTestOrg/loader.aspx. El servidor CRM examina el directorio raíz para determinar el nombre de la organización para atender hacia arriba. Si no se encuentra ningún nombre de organización de raíz, como en el caso de crmserver/loader.aspx, el servidor predeterminado la primera organización creada en la implementación o la uno donde el usuario realiza la llamada tiene acceso.
Dado que el mismo sitio Web se utiliza para ambas organizaciones, si tiene código personalizado como parte de la solución, también se compartirán por ambas organizaciones; por ejemplo, crmserver/ContosoDevOrg/ISV/mycustomdialog.aspx y crmserver/ContosoTestOrg/ISV/mycustomdialog.aspx.
Ambos elija el mismo archivo físico en disco, como C:\inetpub\wwwroot\isv\mycustomdialog.aspx. Dado que es probable que la versión de una extensión personalizada podría sea diferente entre el desarrollo, prueba y producción, esto puede suponer un problema grave. Supongamos, por ejemplo, que generar 11 de la aplicación está actualmente siendo desarrollado, mientras 9 crear está en la prueba de aceptación de usuario (pruebas de aceptación de usuario) de prueba. Si intenta utilizar multi-tenancy para solucionar el problema de entorno, tendrá un tiempo de disco duro aislar estas dos versiones. En estos casos, algunos de los podrían ser querer para probar la solución que se muestra en la figura 5 .
La figura 5 Attempting para utilizar diferentes servidores IIS para separar el código de soluciones personalizadas
En ese modelo (si ya no está utilizando la dirección de equilibrio de la carga en la red), los usuarios pueden aciertos una dirección URL que tiene este aspecto:
Desarrollo 192.168.1.100/ContosoDevOrg/Loader.aspx
Prueba 192.168.1.105/ContosoTestOrg/Loader.aspx
Producción 192.168.1.110/Contoso/Loader.aspx
Este modelo permite que tiene tres servidores front-end, alojamiento tres diferentes organizaciones, con tres bases de código diferente en el disco independientes. Siempre que un usuario sin darse cuenta no ha alcanzado la organización incorrecta en el servidor incorrecto, todo debería funcionar sin perfectamente.
Desafortunadamente, dado que todos los servidores front-end se consideran una parte de la misma implementación, dificultades comenzar a surgir un poco más nivel inferior que se podría da cuenta a primera vista. Esto realmente será un desafío si la solución utiliza complementos asincrónicas o flujos de trabajo, porque aunque se pueden controlar qué servidores aciertos a los usuarios, no se puede controlar que servicio asincrónica procesa los eventos y las solicitudes para que las organizaciones.
Esto se debe a todos los servicios asincrónicos de una implementación funcionan de manera que una operación por turnos, y, como servicio asincrónica de su servidor de desarrollo puede procesar un flujo de trabajo, trabajo de sistema o respuesta de complemento de asincrónica a una solicitud desde el servidor de prueba, por tanto, tocando la derecha de requisito aislamiento fuera de la agua. Además, si el código personalizado que se ejecuta en este proceso asincrónico se basa en los archivos que deben implementarse en disco para el servidor (como un archivo de configuración o un archivo en la caché de ensamblados global o GAC), obtendrá los conflictos entre versiones.
Es importante tener en cuenta que, la mayoría de los casos, estos desafíos surgen sólo cuando está escribiendo código personalizado que debe implementarse en disco o si el código personalizado se basa en los recursos que estarían disponibles sólo en o desde un servidor determinado. Si su solución es simple y sólo utiliza las personalizaciones (esquemas, formularios, vistas y así sucesivamente), los flujos de trabajo y los informes, no tendrá problemas con el método en la figura 4 .
Por lo tanto ¿qué es multi-tenancy para y cuando lo es una buena solución para entornos de ciclo de vida del producto? Multi-tenancy se diseñó originalmente para solucionar un problema de hardware relacionado con el alojamiento de varios arrendatarios distintos en un entorno de producción, y lo hace muy bien. Anteriormente, en Microsoft Dynamics CRM 3.0, cada implementación o arrendatario, tenían que tener su propio servidor dedicado de SQL o instancia de SQL Server, así como un servidor front-end.
Esto era true por muchas razones, como el hecho de que utiliza la específicos de implementación configuración para almacenarlo en el registro y en el disco. Todas estas configuraciones han ahora movido a la base de datos, por lo que un servidor de aplicaciones único es capaz de controlar varias organizaciones. Multi-tenancy son útiles para las versiones alojadas de CRM incluidos en Microsoft Dynamics CRM.
Consideraciones acerca del diseño
Ahora que eres consciente de algunos problemas potenciales, vamos a explicar algunos puntos a tener en cuenta al diseñar la implementación. La respuesta, por supuesto, es que depende. Es ciertamente, posible ejecutar un completo entorno de CRM (incluidos el controlador de dominio, SQL server y el servidor Web) en un solo cuadro, como puede ver en la demostración del equipo virtual de Microsoft Dynamics CRM 4.0 (consulte la barra lateral "recursos CRM" para la dirección URL). Es muy común para utilizar una imagen de virtual único equipo en un entorno de desarrollo. Para las pruebas, sin embargo, es importante validar el entorno de producción clave desafíos y, por este motivo, recomienda tener el reflejo de entorno de prueba el entorno de producción en términos de estructura pero no capacidad. El entorno de aspecto el uno en la figura 6 .
Figura 6 la estructura del entorno de prueba debe reflejar la estructura de producción
En este enfoque, intentar reducir el hardware físico de la infraestructura con la virtualización y más intenta reducir los recursos de virtualización virtualización sólo escenarios clave que se deben probarse. Podrá permitir que los desarrolladores desarrollar en una imagen de servidor único (o imágenes) si tienen su propio equipo virtual en sus escritorios personales si asegúrese de que se preste atención y tener en cuenta el entorno en la que se implementará su solución. Los problemas que los desarrolladores deben prestar atención al son los mismos problemas que debe esté creando el entorno de prueba para validar, incluidos:
Realizar la configuración pueden configurar No, por ejemplo, supongamos que el servidor responde al host local o un puerto determinado.
Ser compatibles con de varios servidores No suponga cosas funcionará sin configurar los usuarios de proxy o de confianza para delegación.
mantener el equilibrio de carga en mente en la Tener gran cuidado con estado de sesión y el almacenamiento en caché. Tenga en cuenta que Microsoft Dynamics CRM está diseñado para ser totalmente sin estado y trabajar bien con un equilibrador de carga de operación por turnos.
piense en Multi-Tenancy Cuando varios arrendatarios están alojados en un solo equipo, comparten el mismo espacio de proceso. Esto significa que los elementos como las cachés necesitan se clave por el nombre de la organización para que los usuarios de una organización no sin darse cuenta utilizará datos de otra organización. Además, cuando tiene código de cliente que tenga vínculos o llamadas al servidor, deberá asegurarse de que las llamadas a conservar el nombre de organización en la dirección URL; de lo contrario, que haga puede clic en la organización predeterminada o una organización que no espera.
Recursos CRM
Guía de implementación de Microsoft Dynamics CRM 4.0
Microsoft Dynamics CRM 4.0 como una plataforma de desarrollo de aplicaciones Business
Blog del equipo de Microsoft Dynamics CRM
Microsoft Dynamics CRM 4.0 máquina virtual
Optimización y mantenimiento de Microsoft Dynamics CRM 4.0
Claves Takeaways
el aislamiento es importante Al diseñar la solución, tenga en cuenta qué método (como se muestra en las figuras 4, 5 o 6) se funcionan mejor para usted y tener en cuenta cuando y donde es posible que ejecutan el código personalizado. También es importante recordar cuando no es necesario que preocuparse sobre dichos problemas debido del tipo de extensiones de que la solución utiliza.
la virtualización Virtualización ayuda a reducir la complejidad en la creación de un entorno que refleja los escenarios clave de prueba de producción. A continuación se algunas instrucciones acerca de la instalación. Colocar CRM y SQL Server en servidores independientes. Esto ayuda a comprobar el confianza para delegación y otros temas relacionados. Servidores CRM deben ser con equilibrio de carga, lo que ayudará a identificar sesión, almacenamiento en caché y los problemas entre servidores. Por último, colocar el controlador de dominio y el correo electrónico en servidores independientes; Esto ayuda a identificar problemas de conectividad.
actualizar el entorno de cada generación Como norma general, es una buena idea crear copias de seguridad de los entornos virtuales o simplemente de bases de las Microsoft Dynamics CRM datos (datos y configuración) que, a continuación, se pueden restaurar para obtener el servidor en espera a un estado "vainilla". A continuación, se realiza una implementación completa limpia en un entorno nuevo cada hora, incluido datos de código, las personalizaciones, plug-ins y dominio personalizados.
pruebas de rendimiento y redundancia pueden se completado independientemente Excepto para las organizaciones muy grandes, normalmente, puede abordar conmutación por error y el rendimiento pruebas mediante las simulaciones aisladas y no a través de detalles de generación "reales". Esto significa que no es necesario intentar crear un entorno de prueba que permite la comprobación de estos escenarios. Como alternativa, puede confiar en las pruebas en producción o en diferentes entornos únicos.
En cierre, Microsoft Dynamics CRM es un sistema escalable, de clase empresarial que, cuando correctamente configurado y implementado, puede controlar los equipos pequeños, soluciones de toda la empresa y todas las opciones de entre. Intentando determinar qué entorno de ciclo de vida del producto es adecuada para la depende una gran variedad de factores.
En general, multi-tenancy no es una forma ideal de afrontan los desafíos de desarrollo del ciclo de vida producto de complejas soluciones y se mejor se utiliza de la al que se entiende completamente. Soluciones simples que requieren sólo la personalización básica o que hacen uso de extensiones personalizadas correctamente codificadas y aisladas que no dependen de recursos de disco o acceso de específica del servidor debe hacer bien tras el modelo de muestra en la figura 4 .
Si su solución exige más aislamiento, recursos de específica del servidor o acceso (sólo está permitido, quizás, un servicio externo a través de su VLAN de un determinado servidor a otro), y así forth, recomiendo continua con el modelo que se muestra en la figura 6 . Y desea recomienda evitar el enfoque que ilustra la figura 5 , ya que es un engañar híbrido en el mejor.
En última instancia, Microsoft Dynamics CRM puede implementarse en miles de configuraciones, y exactamente lo que es de derecha para usted dependerá lo que requiere su solución. Con un mejor conocimiento de multi-tenancy entornos de desarrollo de un solo servidor, entornos de prueba virtual, y qué probar escenarios son importantes para usted, debe poder diseñar una implementación de ciclo de vida del producto que es funcional y rentable.
Aaron Elder (Microsoft Dynamics CRM MVP) funciona Ascentium, una consultoría de tecnología y de interactivo agencia de marketing. Visite el blog Ascentium en ascentium.com/blog/CRM.