Dynamics CRM 4.0: Foco na escalabilidade e produtividade
Com os recursos disponíveis na versão 4.0 do Dynamics CRM tornou-se possível a criação de soluções mais sofisticadas com menos esforço ou complexidade. Cito abaixo diversos exemplos :
-A possibilidade de disparar workflows para diversos eventos e a adoção do WWF (Windows Workflow Fundation) permitiram inserir na aplicação processos de negócio mais complexos;
-A sofisticação da estrutura de relacionamento e a possibilidade de criar relatórios via wizard permitiram o desing e criação de entidades que correspondessem as necessidades de armazenamento dos dados e de extração de dados para análise;
Fora outras melhorias que dependendo do projeto, significam ou um diferencial entre os produtos concorrentes ou servem como apoio na customização da aplicação para o cliente, como multi currency, multi language, exportação de configurações, importação de dados para qualquer entidade, etc. É claro que existem muitas coisas no produto que poderiam ser melhores (e a lista não é pequena) mas a evolução comparada a versão 3.0 é expressiva e tiveram foco na escalabilidade e estabilidade quando em operação, além na produtividade durante o desenho e desenvolvimento. Mas o que poderia ser melhor no Dynamics CRM fica para outro tópico.
Projetos de Implementação de CRM: Sinônimo de expectativa
Em geral os projetos de implementação de uma estratégia de CRM são acompanhados por muita expectativa por parte do cliente, pois significa uma mudança no paradigma de como se relacionar com o publico alvo.Lidar com esse cenário é um desafio enorme para qualquer gerente de projeto ou arquiteto de software. E não existe nada mais frustrante do que a aplicação não responder de forma adequada.
O problema é depois de tudo pronto descobrir aonde mexer. Muitos esquecem de que por der uma aplicação web, o Dynamics CRM possui diversos componentes que são impactados de forma distinta por uma customização ou desenvolvimento mal planejado. Na maioria dos casos a customização não está tecnicamente mal construída, mas na sua idealização não foram levados em consideração fatores como perfil de utilização (o que primariamente os usuários realizarão no CRM e como o farão?), restrições tecnológicas ou de segurança no ambiente do cliente e integrações entre outros sistemas .
Por isso é importante tomar alguns cuidados no momento de desenhar a solução para o cliente. E quando eu falo desenhar a solução, quero dizer desde decidir se um processo de negócio será implementado via workflow ou plugin desde prever o impacto de processos de migração de dados em massa ou de uma lógica extremamente complexa aplicada via jscript no onload de um formulário que será utilizado simultaneamente por 200 usuários.
Nesta série de posts, irei descrever uma série de recomendações, que vão desde o desenho da solução até ajustes em componentes como o SQL Server e .NET Framework. O objetivo é diminuir o risco de um grave problema de desempenho no Dynamics CRM. É claro que cada projeto tem suas características e sempre haverá algum cenário em que não será possível observar alguns dos itens que apresento, mas é importante conhecê-los e se antecipar comunicando os riscos ao cliente, que deve decidir se o desempenho é o preço a se pagar pela informatização de um processo de negócio. A decisão é sempre dele, nunca do responsável pelo projeto.
Cuidados no Desenho da Solução
1-Não esqueça de que por ser uma aplicação web, o Dynamics CRM possui diversos componentes (Sql Server, Web Server, Web Services, Estações de Trabalho e Customizações). Cada um dele deve ser dimensionado de acordo com as especificações de hardware software recomendadas na documentação do produto. Recomendada não é a configuração mínima. Ela não garante desempenho.
2-Ainda sobre hardware e software, se o seu projeto prevê o uso extenso de workflows, talvez seja melhor prever a versão Enterprise e deixar uma máquina específica para o Serviço Assíncrono (que é responsável pelos workflows, serviço de importação e de detecção de duplicatas). Se houver um grande número de usuários, talvez seja necessário deixar um ou mais servidores específicos para a apresentação da interface. Ou ainda, se está planejada a adoção em massa do Outlook Client para Laptops, é bom prever o impacto na intranet. E assim sucessivamente. A Microsoft possui uma documentação detalhada a respeito do que você pode fazer para melhorar o tempo de resposta da aplicação.
3-Se no seu projeto existir o cenário de migrações em massa, procure evitar a adoção de workflows que disparam automaticamente nas entidades que estão sendo migradas.O desempenho da aplicação é degradado de maneira intensa, e pode ser que os worflows fiquem travados, o que obrigará que você tenha que deletá-los (o que é extremamente trabalhoso).
Uma alternativa seria criar um serviço que fosse executado em um horário diferente da migração para realizar a atividade dos workflows (ou até mesmo executá-los).
4-Jscripts devem ser utilizados com cuidado por 03 questões: eles são de difícil manutenção, é muito fácil de um código ser alterado inadvertidamente e deixar de funcionar e por último, eles são descarregados localmente na estação de trabalho para execução. Java Scripts extensos e complexos juntamente com estações de trabalho antigas são sinônimos de problemas de desempenho.
5-Se uma lógica de negócio for extremamente complexa de ser aplicada via workflow ou Java script, talvez seja melhor criar um plugin .NET para executá-la. O desempenho e confiabilidade são superiores.
6-Muitos clientes possuem áreas de TI que não estão acostumadas a suportar aplicações web. É importante alertá-los desde cedo que a execução de atividades de manutenção de acordo com a documentação do produto(como backup do banco de dados, atualizações, etc.) garantem o desempenho do mesmo.
7-Muitos clientes possuem usuários que não estão acostumados com a navegabilidade e funcionalidade de aplicações web. É bom alertá-los desde cedo de que adicionar recursos ou interferir no funcionamento da aplicação tem um custo de desempenho.
8-Caso a utilização do Outlook Client para Laptops seja predominante, o cuidado deve ser redobrado. O funcionamento de customizações pode ser totalmente diferente ,o que requer que o código seja reescrito, causando problemas de desempenho. É preciso lembrar que a estação de trabalho é o servidor!
9-Se os relatórios exigem agregação, sumarização e outras operações matemáticas com quantidade de registros na ordem de milhões, é recomendado replicar os dados para um repositório a parte (datawarehouse) e manipular os dados no próprio SQL criando views e store procedures que serão consumidas pelos relatórios, caso contrário o Report Server consumirá todos os recursos disponíveis do servidor onde estiver instalado. Ele não foi concebido para fazer operações aritiméticas em grande escala , mas sim para exibir relatórios.
10-Nunca deixe que um desenvolvedor escreva sozinho a query no banco de dados para o funcionamento dos desenvolvimentos. Ela deverá ser otimizada por um DBA e deverá sempre obedecer ao que consta na documentação do produto
11-Sempre desenvolva tudo em conformidade com o SDK (Software Development KIT) do Dynamics CRM. Isto por que se você ainda tiver um grave problema de desempenho após ter observado tudo o que foi disposto acima, ainda poderá contar com o suporte da Microsoft para resolvê-lo.
Essas são as recomendações quanto ao desenho da solução que deverá ser apresentada ao cliente. Na próxima semana escreverei sobre algumas dicas na manutenção e otimização do componente banco de dados do Dynamics CRM.
Abraços! 