Implantação do Microsoft Dynamics CRM 4.0

Aaron Elder

 

Visão geral:

  • Componentes de software de um sistema CRM
  • O ciclo de vida de desenvolvimento
  • Elementos de uma solução do CRM
  • Uma olhada multi-tenancy

Conteúdo

A solução Development Lifecycle
Elementos de uma solução do CRM
E quanto Multi-Tenancy?
Considerações de design
Chaves Takeaways

Se você costuma pensar do CRM como apenas uma ferramenta de gerenciamento de vendas e marketing, pense novamente. Gerenciamento de relacionamento com o cliente Microsoft Dynamics é uma plataforma para desenvolvimento de aplicativos que gerenciar e controlar informações e processos relacionados a objetos do mundo real. Esses objetos podem ser clientes, mas também pode ser praticamente qualquer entidade (e atividades relacionadas) que você precisa gerenciar.

Como com qualquer solução personalizada em larga escala, há alguns conceitos básicos relacionados à implantação que precisam ser compreendidos. Neste artigo, vou abordar alguns conceitos fundamentais relacionados à implantação do Microsoft Dynamics CRM, incluindo como esses conceitos podem ser usados para oferecer suporte a uma implantação de ciclo de vida do produto completo. Além disso, discutirei Gerenciando várias implantações como parte de uma versão única solução, e como multi-tenancy deve e não deve ser usado como parte do ciclo de vida do solução inteira.

Eu quero deixar claro no início deste artigo que, quando me referir a um Microsoft Dynamics CRM "solução", significa o totality de todas as personalizações, as extensões, codificação personalizada, as mudanças de esquema e assim por diante. Uma solução não é apenas uma coisa; é todas as suas alterações em conjunto.

Nos bastidores, uma solução de Microsoft Dynamics CRM é um aplicativo ASP.NET 2.0 e o Microsoft .NET Framework 3.5 orientado a dados Web padrão. O sistema de três camadas inclui os seguintes componentes principais:

camada de dados O banco de dados SQL Server 2005 ou SQL Server 2008. Usar o SQL Server 2008 requer um hot fix conforme descrito no artigo na Base de Dados de Conhecimento da" Suporte para executar o Microsoft Dynamics CRM 4.0 junto com o Microsoft SQL Server 2008."

Camada intermediária Microsoft Internet Information Services (IIS) 6.0 ou posterior da Web front-end, SQL Server Reporting Services SRS () 2005 ou SRS 2008; ASP.NET 3.5; serviços do Windows personalizada.

Camada de cliente Internet Explorer 6.0 ou posterior cliente da Microsoft; ASP.NET 2.0 ou posterior cliente Microsoft Office Outlook 2003 ou 2007 do Office (com opcional acesso off-line); outras como consumidores do SDK e clientes móveis de terceiros.

Microsoft Dynamics CRM também depende de uma variedade de sistemas externos, incluindo o Microsoft Exchange Server 2003 ou posterior e do Active Directory.

A solução Development Lifecycle

Uma solução do Microsoft Dynamics CRM passa o ciclo de mesmo vida que um projeto de desenvolvimento de aplicativo personalizado, que poderia ser algo como o processo descrito na A Figura 1 .

fig01.gif

Figura 1 O desenvolvimento de aplicativos ciclo

Esse processo todo deve ter suporte vários ambientes que juntos constituem os sistemas de desenvolvimento, teste e produção. No mundo de qualquer aplicativo empresarial multifaceted, isso, claro, pode ativar check-out a ser surpreendentemente complexos. Se, por exemplo, você fosse espelhar o seu ambiente, você pode terminar com algo semelhante a Figura 2 .

fig02.gif

A Figura 2 espelhamento seus ambientes de desenvolvimento, teste e de produção

Isso é três domínios, o três controladores de domínio, o três servidores de email, o três servidores Web e três servidores de banco de dados — e Este modelo pressupõe que o SRS e CRM sejam na mesma caixa, e ele não leva em itens de conta, como balanceamento de carga. Agora vamos imaginar você adicionar redundância e alguns serviços externos, como o Microsoft Office SharePoint Services (MOSS), e você poderia terminar com um esquema como da Figura 3 .

fig03.gif

A Figura 3 aumentando complexidade

Por motivos de custo e complexidade, trade-offs básicos pode ser considerados para equilibrar a necessidade de isolamento de ambiente em relação à necessidade de manter os custos baixos e ao gerenciamento de backup. As organizações, portanto, tem parecia a uma variedade de técnicas, como a virtualização e o Microsoft Dynamics CRM recursos multi-tenancy internos, para abordar esses desafios.

Durante a criação de um conjunto de ambientes para suportar o ciclo de vida do projeto do CRM, houver vários escolas do pensamento e, dependendo de que princípios são importantes para você, você pode escolher ir a uma forma ou outro. Em uma extremidade do espectro, designers promover total isolamento usando duplicação exata. Essas pessoas acreditam que a única maneira de validar que algo funcionará fora da produção é ter um ambiente de teste que 100 % idêntico ao ambiente de produção. Todos os servidores, cada bit e todas as configurações devem ser idênticos e completamente isolados do desenvolvimento e produção para testadores e TI aceitar e acha algo funcionará em produção.

Em contrapartida, outras pessoas acha que esse tipo de isolamento, na verdade, não importa. Se eles pode, eles devem desenvolver e testar diretamente no ambiente de produção. Eles tendem a ver a redundância como perda de tempo e dinheiro, e são determinadas de entrega seria mais fácil se eles apenas podem obter no local e tornar as coisas de trabalho.

Felizmente, você se enquadram em algum lugar entre esses extremos e será aberto para a idéia de que, quando se trata de uma solução do Microsoft Dynamics CRM, é possível desenvolver um híbrido que equilibra complexidade, custo, isolamento e capacidade de gerenciamento.

Elementos de uma solução do CRM

Componentes de soluções do Microsoft Dynamics CRM podem ser divididas em quatro partições de memória principais, e sua solução pode incluir um, dois, três ou todos os quatro.

as personalizações Eles incluem alterações de formulário, grade, esquema e metadados; direitos; fluxos de trabalho; as configurações do sistema; e modelos. Personalizações do Microsoft Dynamics CRM são fornecidas como um ou mais (normalmente um ou dois) (zipada) arquivos XML. Eles são importados para uma implantação do CRM via o cliente Outlook ou da área "personalização de | configurações" e, em seguida, são "publicados" para torná-los ativo. Tudo isso pode ser automatizado usando código escrito com o SDK do Microsoft Dynamics CRM.

extensões Isso inclui relatórios e código personalizado, como plug-ins que devem ser implantados separadamente das personalizações. Informações de registro Plug-in são armazenadas como um arquivo XML e podem ser implantadas por meio de uma linha de comando ou aplicativo de formulário do Windows fornecido pela Microsoft. Isso também pode ser automatizado por meio de código escrito com o SDK do Microsoft Dynamics CRM.

código personalizado Nada desenvolvido como parte de sua solução, e ele pode consistem em externo serviços da Web, personalizadas componentes do aplicativo da Web e assim por diante. As regras e práticas recomendadas para implantar o código personalizado devem ser não diferentes para qualquer outro aplicativo da Web personalizado.

dados Qualquer informação que precisa ser importadas para um ambiente para esse ambiente para funcionar. Isso pode incluir dados de domínio (como, por exemplo, uma lista de códigos do produto) ou usuários. Os dados que precisa de sua solução podem ser implantados em sua instância do Microsoft Dynamics CRM usando código de script ou recurso de importação em massa do CRM, ou com alguma forma de processo externo usando BizTalk ou outra ferramenta ETL (extração, transformação, carga). Alguns dados, tais como usuários, precisam ser criado manualmente ou através de chamadas do SDK do Microsoft Dynamics CRM.

Gosto de pensar em implantações de solução do CRM apenas como se fossem implantações de desenvolvimento de aplicativo personalizado. Isso significa que, durante o desenvolvimento e teste, cada nova compilação da solução é instalada a partir um sistema limpo base e o processo é como passível de repetição e script possível.

E quanto Multi-Tenancy?

Agora vamos discutir o ambiente que você pretende implantá-los em deve aparência. Você pode ter ler sobre o suporte de Enterprise Edition do Microsoft Dynamics CRM 4.0 para um recurso chamado multi-tenancy, que lhe permite várias instâncias do Microsoft Dynamics CRM em uma única implantação de partição. Isso significa que várias organizações completamente diferentes com seus próprios relatórios, fluxo de trabalho, personalização e esquemas podem ser executar no mesmo conjunto de hardware usando os mesmos servidores físicos e o mesmo instâncias de banco de dados e sites da Web do IIS.

A princípio, isso pode parece ser a panacéia que resolva todos os nossa gerenciabilidade, isolamento, e custo conundrums. Uma solução pode ser visualizada como na Figura 4 .

fig04.gif

Figura 4 uma solução várias tenancy--somente

Isso parece lógico, porque cada organização obtém seu próprio banco de dados físico no SQL Server compartilhado ou instância (que inclui as personalizações, fluxos de trabalho, os usuários, funções e configurações) e sua própria pasta SQL Reporting Services.

Esse modelo funciona perfeitamente bem se as organizações diferentes fazem parte de outra equipe ou soluções de departamentos. Isso, afinal, é que multi-tenancy foi projetada para. Embora seja verdadeiro que cada organização (ou inquilino) obtém seu próprio banco de dados, todas elas compartilham a mesma unidade organizacional (OU) e grupos do Active Directory e eles serão todos os compartilhar o mesmo serviços de plataforma e o aplicativo front-end bem. Isso significa que o mesmo serviço assíncrono e o site do IIS serão compartilhadas entre as organizações. Os servidores front-end são capazes de "host" essas organizações diferentes através de um provedor de URL que determina, com base no URL, que organização para o host.

Veja essas URLs como exemplo: crmserver/ContosoDevOrg/loader.aspx e crmserver/ContosoTestOrg/loader.aspx. O servidor do CRM procura no diretório raiz para determinar o nome da organização para atender a. Se nenhum nome de organização raiz for encontrado, como no caso de crmserver/loader.aspx, o servidor padrão será a primeira organização criada na implantação ou aquele que o usuário chamado tem acesso.

Como o mesmo site é usado para ambas as organizações, se você tiver o código personalizado como parte de sua solução, ela também será compartilhada por ambas as organizações; por exemplo, crmserver/ContosoDevOrg/ISV/mycustomdialog.aspx e crmserver/ContosoTestOrg/ISV/mycustomdialog.aspx.

Ambos apontam para o mesmo arquivo físico no disco, como C:\inetpub\wwwroot\isv\mycustomdialog.aspx. Como é provável que a versão de uma extensão personalizada deve ser diferente entre dev, teste e produção, isso pode representar um problema sério. Vamos supor que, por exemplo, que criar 11 do seu aplicativo está atualmente sendo desenvolvido, enquanto criar 9 está em UAT (teste de aceitação de usuário) para teste. Se você tentar usar multi-tenancy para resolver o problema de ambiente, você terá uma dificuldade isolar esses dois compilações. Em tais situações, alguns de vocês podem ser tempted para tentar a solução mostrada na Figura 5 .

fig05.gif

A Figura 5 tentativa para usar diferentes servidores IIS para isolar o código de soluções personalizadas

Nesse modelo (se você não estiver usando o endereço de balanceamento de carga de rede), os usuários podem visitas uma URL que tem esta aparência:

Desenvolvimento 192.168.1.100/ContosoDevOrg/Loader.aspx

Teste 192.168.1.105/ContosoTestOrg/Loader.aspx

Produção 192.168.1.110/Contoso/Loader.aspx

Esse modelo permite que você tem três servidores front-end, hospedando três organizações diferentes, com três bases de código diferente no disco separados. Desde que um usuário não inadvertidamente atingiu a organização incorreta no servidor incorreto, tudo o que deve funcionar fora perfeitamente.

Infelizmente, desde que todos os servidores front-end são considerados uma parte da mesma implantação, dificuldades começar a surgir um pouco mais downstream que você talvez perceba à primeira vista. Se isso realmente torna um desafio se sua solução utiliza assíncrona plug-ins ou fluxos de trabalho, porque enquanto você pode controlar os servidores que os usuários atingida, não é possível controlar qual serviço assíncrono irá processar solicitações para que as organizações e eventos.

Isso ocorre porque todos os serviços assíncronos em uma implantação trabalha em uma forma de rodízio, e, assim, o serviço de assíncrona de seu servidor de desenvolvimento pode processar um fluxo de trabalho, trabalhos de sistema ou assíncrona resposta plug-in a uma solicitação do seu servidor de teste, falhe, portanto, a necessidade de isolamento direita check-out da água. Além disso, se seu código personalizado que é executado por esse processo assíncrono depende de arquivos que devem ser implantados no disco para o servidor (como um arquivo de configuração ou um arquivo no cache global de assemblies ou GAC), você receberá conflitos de versão.

É importante observar que, na sua maioria, esses desafios surgem somente quando você estiver escrever código personalizado que precisa ser implantada no disco ou se seu código personalizado depende de recursos que estariam disponíveis somente em ou de um servidor específico. Se sua solução é simples e usa apenas as personalizações (esquemas, formulários, modos de exibição e assim por diante), os fluxos de trabalho e relatórios, você não terá algum problema ao usar a abordagem na Figura 4 .

Portanto, o que é multi-tenancy para e quando ele é uma boa solução para ambientes de ciclo de vida do produto? Multi-tenancy foi criado originalmente para resolver um problema de hardware relacionado à hospedagem de vários inquilinos da distintos em um ambiente de produção, e ele faz isso muito bem. Anteriormente, no Microsoft Dynamics CRM 3.0, cada implantação ou inquilino, tinha que ter seu próprio SQL Server dedicado ou instância do SQL Server, bem como um servidor front-end.

Isso era verdade por vários motivos, incluindo o fato de que configurações de implantação específicas usadas sejam armazenados no Registro e no disco. Todas essas configurações agora tem movido para o banco de dados, portanto, um servidor único aplicativo é capaz de manipular várias organizações. Multi-tenancy é útil para versões hospedadas do CRM, incluindo o Microsoft Dynamics CRM online.

Considerações de design

Agora que você já atento com alguns problemas possíveis, discutiremos alguns pontos a serem lembrados conforme você cria sua implantação. A resposta, é claro, é que ele depende. É certamente possível executar um ambiente do CRM completo (incluindo o controlador de domínio, o SQL server e o servidor Web) em uma única caixa, como você pode ver a demonstração do Microsoft Dynamics CRM 4.0 Virtual Machine (consulte a barra lateral "Recursos de CRM" para a URL). É muito comum para usar uma imagem do virtual único computador para um ambiente de desenvolvimento. Para teste, no entanto, é importante validar o ambiente de produção principais desafios e, por esse motivo, recomenda tendo o espelho de ambiente de teste seu ambiente de produção em termos da estrutura, mas não capacidade. Seu ambiente pode parecer que na Figura 6 .

fig06.gif

A Figura 6 A estrutura do ambiente de teste deve espelhar a estrutura de produção

Nesta abordagem, você tentar minimizar hardware físico da infra-estrutura usando a virtualização e mais tenta minimizar recursos de virtualização virtualizar somente os cenários principais que precisam ser testados. Será possível permitir que seus desenvolvedores desenvolver em uma imagem de único servidor (ou imagens) se tiverem seu próprios máquina virtual em suas áreas de trabalho pessoais se você garantir que irão preste atenção e conhecer o ambiente para o qual sua solução será implantada. As questões de que os desenvolvedores devem ser prestando atenção a são os mesmos problemas que você deve ser criando seu ambiente de teste para validar, incluindo:

Verifique as configurações de configuráveis Não, por exemplo, suponha que o servidor responderá para host local ou uma porta específica.

Ser reconhecimento de vários servidores Não pense coisas funcionará sem configurar os usuários de proxy ou de confiança para delegação.

manter o balanceamento de carga em mental de Tenha muito cuidado com o estado da sessão e cache. Observe que o Microsoft Dynamics CRM foi projetado para ser totalmente sem monitoração de estado e trabalhar bem com um balanceador de carga de rodízio.

pense Multi-Tenancy Quando vários inquilinos da são hospedados em um único computador, eles compartilham o mesmo espaço de processo. Isso significa que elementos, como caches precisam ser chaveado pelo nome da organização para que os usuários de uma organização inadvertidamente não irão utilizar dados de outra organização. Além disso, quando você tem código de cliente que possui links ou chamadas de volta para o servidor, você precisará ser-se de que as chamadas de preservar o nome da organização na URL; caso contrário, você pode clicar a organização padrão ou uma organização que você não espera.

Recursos CRM

Guia de implementação do Microsoft Dynamics CRM 4.0

O Microsoft Dynamics CRM 4.0 como uma plataforma de desenvolvimento de aplicativos comerciais

Blog do Microsoft Dynamics CRM da equipe

Microsoft Dynamics CRM 4.0 Virtual Machine

Otimizando e fazendo a manutenção de Microsoft Dynamics CRM 4.0

Chaves Takeaways

isolamento É importante Durante a criação de sua solução, tenha em mente qual abordagem (conforme ilustrado na figuras 4, 5 ou 6) será funcionam melhor para você e ficar atento quando e onde seu código personalizado pode ser executado. Também vale a pena observar quando você não precisa se preocupar sobre esses problemas por causa do tipo de extensões de que sua solução utiliza.

a virtualização A virtualização ajuda a reduzir a complexidade na criação de um ambiente que simule cenários de teste principais de produção. Eis algumas orientações sobre a configuração. Coloque o CRM e o SQL Server em servidores separados. Isso ajuda a verificar confiança para delegação e outras questões relacionadas. Os servidores de CRM devem estar com balanceamento de carga, que ajudará a identificar sessão, cache e problemas de servidor cruzado. Finalmente, colocar o controlador de domínio e o email em servidores separados; isso ajuda a identificar problemas de conectividade.

atualizar o ambiente de cada compilação Como regra geral, é uma boa idéia para criar backups dos ambientes virtuais ou simplesmente dos bancos de Microsoft Dynamics CRM dados (data e configuração) que podem ser restaurados para obter o servidor de volta para um estado de baunilha". Você, em seguida, fazer uma implantação completa limpa em um ambiente nova cada hora, incluindo dados de código, as personalizações, plug-ins e domínio personalizados.

teste de redundância/desempenho pode ser concluído separadamente Exceto para empresas muito grandes, você geralmente pode atacar failover e testes por meio de simulações isoladas e não pela compilação "real" detalhes de desempenho. Isso significa que não é necessário tentar criar um ambiente de teste que permite o teste de nesses cenários. Como alternativa, você pode confiar nos testes-los em produção ou em ambientes one-off separados.

No fechamento, o Microsoft Dynamics CRM é um escalonável, sistema de classe empresarial que, quando corretamente configurado e implantado, pode manipular pequenas equipes, soluções de toda a empresa e cada opção entre. Tentativa de determinar qual ambiente de ciclo de vida do produto é adequado para você dependerão uma variedade de fatores.

Em termos gerais, o multi-tenancy não é uma forma ideal de corrigir os desafios de desenvolvimento de ciclo de vida do produto de soluções complexas e é melhor utilizados quando ele é compreendido totalmente. Soluções simples que exigem apenas personalização básica ou que fazer uso de adequadamente codificados e isoladas extensões personalizadas que não dependem de acesso específicas do servidor de recursos de disco ou faça bem seguir o modelo aparece ilustrado na Figura 4 .

Se sua solução exige mais isolamento, recursos específicos do servidor ou acesso (talvez um serviço externo só é permitido através de seu VLAN de um servidor específico para outro), e assim por diante, eu recomendo entrar com o modelo mostrado na Figura 6 . E eu recomendaria evitando a abordagem que ilustra a Figura 5 , como ataques de hackers um híbrido na melhor das hipóteses.

Finalmente, Microsoft Dynamics CRM podem ser implantado em milhares de configurações, e exatamente o que é adequado para você dependerão sua solução exija. Com uma melhor compreensão sobre multi-tenancy, ambientes de desenvolvimento de servidor único, ambientes de teste virtual e quais cenários de teste são importantes para você, será capaz de criar uma implantação de ciclo de vida do produto que é funcional e econômica.

Aaron Elder (Microsoft Dynamics CRM MVP) funciona para Ascentium, uma tecnologia de consultoria e interativa agência de marketing. Visite o blog Ascentium em ascentium.com/blog/CRM.