Microsoft Dynamics

Solução Microsoft Dynamics CRM

Aaron Elder

Em uma visão geral:

• Ilustrar uma arquitetura de solução
• Princípios fundamentais de solução de problemas
• Ferramentas para diagnosticar problemas de servidor
• Etapas para resolver erros CRM

Conteúdo

A pilha
Regras básicas
Solucionando problemas de servidor
Reproduzir em casa exemplo
Resumindo

Eu ’m volta para um segundo artigo no Microsoft DynamicsCRM (consulte o artigo do primeiro" Implantação do Microsoft Dynamics CRM 4.0"), com foco em algo que eu sou apaixonado — isto é, solução de problemas. Solução de problemas do Microsoft CRM não é muito diferente de solucionar problemas de qualquer outro aplicativo de Web n camadas construído sobre a pilha da Microsoft. Como tal, este artigo não é um guia de instruções ou uma coleção de "101 dicas e truques." Em vez disso, Falarei sobre os fundamentos de componentes do Dynamics CRM e as ferramentas para isolar, Noções básicas sobre e solução de problemas. Neste artigo, me concentrarei somente em solução de problemas os aspectos do lado do servidor de problemas do Microsoft Dynamics CRM.

A pilha

Com qualquer sistema complexo, seja do corpo humano ou um aplicativo Web n camadas que utiliza muitos igualmente subsistemas complexos e sistemas externos, é importante compreender "a pilha do sistema." A pilha é basicamente um plano gráfico de um sistema que permite que você compreender todos os componentes de sistema e como criar e camada uns dos outros. A pilha pode também ser chamada diagrama de arquitetura de solução, como ele ilustra os componentes da solução — nesse caso, Microsoft Dynamics CRM. Depois de compreender a solução, você também precisará compreender como a solução foi implantada. Para isso, você precisa de um diagrama de arquitetura do sistema, que ilustra onde cada componente da solução fica em relação às outras na sua implantação. Noções básicas sobre tudo isso é fundamental para poder isolar o problema.

Figura 1 mostra um Solution arquitetura diagrama do Microsoft Dynamics CRM 4.0, ilustrando todos os seus principais componentes e suas interdependências. Observe que cada componente por sua vez pode ter seu próprio diagrama igual ou maior complexidade. Sistemas de computador são tudo sobre abstração, o processo pelo qual um componente do sistema disponibiliza um conjunto de recursos que outro componente dependente pode depender, ocultando a complexidade interna do componente. Abstração é o motivo pelo qual que você precisa isolar um problema durante a solução de problemas.

Figura 1 diagrama de pacote UML ilustrando uma arquitetura de solução

Para expressar a arquitetura da solução, usei um diagrama de pacote UML. Setas indicam a direção de "dependência". Por exemplo, o roteador de email do CRM "depende" um servidor SMTP e Web Services a plataforma CRM. Um diagrama completo seria muito complexo, mas isso fornece um modelo básico.

Agora você pode considerar sobre como os componentes do Microsoft Dynamics CRM são implantados em sua empresa. Para fins deste artigo, usaremos uma arquitetura de implantação típico, como mostrado na Figura 2 . Noções básicas sobre como a arquitetura do sistema se relaciona com a arquitetura da solução é vital quando se trata de isolar problemas. Sem saber que componentes estão sendo executados, você poderia passar horas tentando encontrar e corrigir um problema que ainda não estiver acontecendo na máquina que você está tentando corrigir!

Figura 2 A arquitetura de implantação típica

Regras básicas

Antes de iniciar Solucionando um problema com o Dynamics CRM, você precisa entender alguns princípios fundamentais de solução de problemas. Primeiro, vamos examinar um fluxo de trabalho básico de solução de problemas e algumas diretrizes sobre como saber quando é seguro passar para a próxima etapa.

1. Um problema ou erro é identificado e reproduzido.

• Você identificou o problema e você tiver ler a mensagem de erro?
• A mensagem de erro é genérico? Em caso afirmativo, você entraram etapas para localizar o "erro real"? Dica: Se o erro diz "algo aconteceu, contate o administrador do sistema," Lembre-se que você provavelmente está que administrador do sistema e, portanto, precisará fazer mais examinar para localizar o erro real. Antes de você mover para a etapa 3, você deve estar se que você está lidando com o erro real.

2. O problema precisa ser compreendido.

• Você fez ler e compreender o que a mensagem de erro está dizendo?
• Você tem um conjunto consistente de etapas para reproduzir o problema confiável?

3. O problema precisa estar isolado.

• Quais sistemas em sua arquitetura de sistema pode você eliminar como uma causa ou influenciar o problema?
• Quais componentes de arquitetura de solução pode você regra de como a causa do ou influenciar o problema?

4. A correção precisa ser identificados e compreendido.

• É possível localizar artigos de suporte, postagens de blog ou postagens de grupos de notícias que sugerem correções que se aplicam ao seu problema exato?
• Antes de aplicar uma correção, você compreender por que ele irá corrigir o problema?

5. A correção precisa ser aplicada e verificada.

• A correção aplicada resolver o problema? Você precisará ser capaz de reproduzir o problema (etapa 2) para certificar-se. Porque você entende a correção, você tem re-tested outras áreas do sistema que podem ser afetados?

Solucionando problemas de servidor

Com uma compreensão do processo de solução de problemas, pode agora continuar com as ferramentas necessárias para diagnosticar problemas no Microsoft CRM.

DevErrors — quando o Microsoft Dynamics CRM envia dados para o servidor, informações são passadas para ASP.NET e processadas. Os erros são tratados por um manipulador de exceção global na camada de ASP.NET. Para usabilidade e às vezes, motivos de segurança, o erro real está oculta do chamador (que é você ou o usuário) e um "erro muito" é exibido em vez disso. Geralmente este erro diz algo como "você não tem privilégios suficientes"ou "O registro solicitado não foi encontrado." Infelizmente, esses erros muito provenientes de uma "lista em branco". Centenas de milhares de erros que podem ser lançados pelo CRM ou qualquer componente relacionado (SQL, SRS, NET, Windows e assim por diante), erro somente códigos que pode acontecer o pensamento de equipe CRM ter uma seqüência muito associada a eles. O restante obter tratadas pelo catchall temido "Ocorreu um erro, contate o administrador do sistema." Isso, obviamente, não é muito útil para você, o administrador do sistema.

Como um dos nossas regras básicas é exibida a mensagem de erro real, você precisa ser capaz de dizer ao CRM está residente ou pelo menos não informando a verdade toda. Serum verdade é habilitar DevErrors via o web.config. Isso é feito por modificar o [arquivo CRMWEB]\web.config assim:

<add key="DevErrors" value="On"/>

Certifique-se ter sua arquitetura de sistema em mente ao fazer isso. Se você tiver dois servidores configurados em um ambiente com balanceamento de carga, você desejará isolar o servidor onde o erro está ocorrendo ou, como alternativa, certifique ative DevErrors ambos os servidores. Depois de DevErrors estiver habilitada, você verá erros que aparência da Figura 3 .

Figura 3 um relatório de erro do Microsoft CRM

Figura 3 mostra vários itens à esquerda que fornecem diferentes conjuntos de informações:

O erro detalhado — A primeira tela (o padrão) mostra o erro real do ponto de vista do Microsoft Dynamics CRM. Isso inclui o nome Date, Time e Server onde ocorreu o erro, bem como a descrição de erro, Call Stack, número do erro (se disponível), o arquivo de fonte e número da linha onde ocorreu o erro (se disponível) e a URL que foi solicitada — todos útil ao tentar descobrir o que deu errado.

O ASP.NET erro — O próximo item é o erro real da perspectiva do ASP.NET. Isso fornece as mesmas informações como o erro CRM, mas adiciona as opções "Mostrar detalhado saída de compilador" e "Mostrar fonte complicação concluída".

Informações de diagnóstico — A terceira tela, mostrada na Figura 4 , fornece informações básicas sobre o servidor, onde ocorreu o erro e detalhes sobre o cliente e o usuário que fez a solicitação. Essas informações incluem sistema operacional do servidor, a versão em tempo de execução .NET, nome do servidor e o caminho para onde o CRM está instalado. Informações sobre as configurações no web.config e banco de dados CRM usado específico também estão incluídas. Para o cliente, a tela mostra a versão do navegador, resolução de tela, intensidade de bits e muito mais. Informações sobre o usuário que fizer a solicitação (pelo menos do CRM ponto do modo de exibição) inclui o usuário domínio e nome, nome de usuário do CRM, CRM User ID, ID de unidade de negócio e identificação de organização.

Figura 4 A tela de informações de diagnóstico

O que o usuário would com Seen — O item final, mostrado na Figura 5 , permite que você veja da perspectiva do usuário final, como se DevErrors foram desativadas.

Figura 5 Would com Seen A mensagem de erro do usuário

Observe que ajuda a DevErrors somente com erros que ocorrem durante o processamento de uma solicitação de aplicativo da Web e enviar somente aos pedidos que envolvem uma página inteira para o servidor. Solicitações de AJAX, como com uma publicação de personalizações, um fluxo de trabalho ou uma ação de grade, não oferecem suporte DevErrors. Para essas, você precisará usar rastreamento.

DICA: Se as informações na página DevErrors são cortadas e você não pode redimensionar a janela para ver mais detalhes, simplesmente clicar duas vezes em qualquer lugar na página e abrirá uma janela redimensionável.

rastreamento — se um erro CRM acontece em qualquer lugar diferente de uma solicitação Web direta, a melhor maneira para obter o erro real é usar o rastreamento de CRM. Rastreamento pode ser ativado e configurado seguindo as etapas no artigo "Como ativar o rastreamento no Microsoft Dynamics CRM" no support.microsoft.com/kb/907490. Ou você pode usar uma ferramenta como CrmDiagTool, disponível na caixa. NET/compartilhado/6oxfqi2ida.

DICA: No CRM 4.0, o "diretório de rastreamento" será ignorado.

Rastreamento pode ser assustador para iniciantes, para não obter frustrados. Em geral, rastreamento deve ser usado apenas ao solucionar um problema. Dependendo de como você configura o rastreamento, pode haver um impacto significativo no desempenho quando ele está sendo executado, e se você tiver o log detalhado, um sistema muito usado pode facilmente criar centenas de megabytes de logs por hora. O artigo mencionado acima fornece uma explicação detalhada de todas as formas para configurar o rastreamento e como ativar o rastreamento para cliente e servidor.

TIP: Ao enviando saída logs de rastreamento para obter ajuda, certifique-se de compactá-los primeiro. Arquivos de log são apenas texto e compactar normalmente por 90 por cento ou mais.

Estrutura do arquivo de log — quando rastreamento estiver ativado no servidor, os logs serão colocados na pasta de rastreamento, que está localizada em que você instalou o CRM. Cada serviço tem seu próprio arquivo de log e cada arquivo por padrão aumentará até 10 MB antes que um novo arquivo seja iniciado. Como os arquivos de log ativamente estão sendo gravados em por vários processos CRM, você não obterá as informações de rastreamento mais recentes absoluto até que o serviço correspondente (o IIS ou o serviço assíncrono) seja interrompido. Quando você abrir a pasta você verá arquivos, como

-CRMDEV-VPC-CrmAsyncService-bin-20090415-1.log

-CRMDEV-VPC-w3wp-CRMWeb-20090415-1.log

A convenção de nomenclatura é [MACHINE NAME] – [PROCESS da CRM] – [ano dia do mês –] [SEQUENCE] .log

O arquivo de log contém cargas de informações, com itens escritos em ordem cronológica. Observe que o log de rastreamento grava o evento mais recente na parte inferior do arquivo, enquanto dentro de uma pilha de chamadas itens são escritos em inversa ordem cronológica (mais recente primeiro item).

DICA: Ao procurar por erros no log de, procure ": erro" (dois-pontos seguido por um espaço e erro.

Log de eventos — O Log de eventos do Windows é outro local para procurar erros que ocorrem dentro do Microsoft Dynamics CRM, seus componentes dependentes ou outras áreas do sistema. Assim como o log de rastreamento, o log de eventos geralmente fornecerá mais detalhes sobre erros que ocorrem dentro do sistema.

Microsoft CRM não registra todos os erros no log de eventos. Por exemplo, um usuário desabilitado tentando fazer logon é registrado enquanto não tiver feita uma tentativa de atualizar um registro que não existe mais. Embora isso não é documentado, CRM registra erros no log de eventos de subsistemas seguintes:

-MSCRMPerfCounters

-MSCRMPlatform

-MSCRMKeyArchiveManager

-MSCRMKeyGenerator

-MSCRMEmail

-MSCRMDeletionService

-MSCRMReporting

-MSCRMWebService

-MSCRMAsyncService

-ASP.NET 2.0

Compartimento de memória do ASP.NET 2.0 atua como um "catch mais" para erros de camada de aplicativo. Além disso, o serviço do Microsoft Dynamics CRM Email Router tem seu próprio log de eventos (MSCRMEmailLog) que pode ser configurado independentemente para fazer uma grande variedade de informações, avisos e erros.

Como log de eventos não precisa ser ativado, é um bom local inicial para procurar por problemas.

uma pilha de chamadas de leitura — pilhas de chamada são fornecidos em todas as formas e tamanhos e todas as muitas são ignoradas por nondeveloper solucionadores de problemas. Não é incomum para engenheiros de sistema para simplesmente "ignorar as coisas de desenvolvedor" e somente a mensagem de erro ou o código de pesquisa. É recomendável que você não faça isso — mesmo que a pilha de chamadas se parece com código, ele é projetado para ser humano legível e saber o que aconteceu com para a direita até o erro ocorreu. Veja o exemplo a seguir:

[ReportServerException: The Report Server Windows service 'ReportServer' is not running. 
   The service must be running to use Report Server. (rsReportServerServiceUnavailable)]
   at Microsoft.Reporting.WebForms.ServerReport.SetDataSourceCredentials(DataSourceCredentials[]credentials)
   at Microsoft.Crm.Web.Reporting.SrsReportViewer.SetExecutionCredentials(ServerReport report)

[CrmReportingException: The Report Server Windows service 'ReportServer' is not running. 
The service must be running to use Report Server. (rsReportServerServiceUnavailable)]
   at Microsoft.Crm.Web.Reporting.SrsReportViewer.SetExecutionCredentials(ServerReport report)
   at Microsoft.Crm.Web.Reporting.SrsReportViewer.ConfigurePage()
   at Microsoft.Crm.Application.Controls.AppUIPage.OnPreRender(EventArgs e)
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

O que você vê aqui é uma lista de todas as coisas foi o sistema (as chamadas) listadas em ordem cronológica inversa (a pilha) até a última coisa que ele "tentou" fazer. Nesse caso, a primeira coisa que aconteceu com — a chamada na parte inferior da pilha — foi uma chamada para System.Web.UI.Page.ProcessRequestMain().

Ao ler as pilhas de chamada, é importante ler o nome de cada chamada. Para cada chamada listada, as palavras entre o último período e o parêntese são o nome do método. Palavras antes do nome do método são o espaço para nome e os itens dentro dos parênteses, os parâmetros. Nesse caso, o método ProcessRequestMain foi chamado primeiro; esse método está no namespace System.Web.UI.Page; e esse método espera dois parâmetros de valor booleano (True/False). Imediatamente, pela leitura o namespace, sabemos que esta chamada não é a qualquer código do Microsoft Dynamics CRM; isso na verdade está chamando código no .NET Framework base (designado pelo namespace raiz System) e especificamente para o ASP.NET (denotados pelo namespace Web). Como podemos ler "acima" na pilha, vemos que ProcessRequestMain então chamado PreRenderRecursiveInternal, em seguida, chamado OnPreRender. O método OnPreRender é o primeiro método, na verdade, uma parte do código do Microsoft Dynamics CRM base, como indicado pelo namespace Microsoft.Crm. Como podemos continuar na pilha de chamadas, vemos que CRM realmente faz uma chamada para o método SetDataSourceCredentials do SQL Reporting Services. Esse método, em seguida, lança uma exceção do tipo ReportServerException com o erro que o servidor de relatórios não está sendo executado. Como você pode ver, lendo a pilha de chamadas, você pode dizer que esse erro é não proveniente do CRM, mas em vez disso vem do SSRS (SQL Server Reporting Services) e é, em seguida, sendo "bubbled backup" por meio de CRM como um CrmReportingException. Com base em sua arquitetura de sistema, você precisará determinar onde SSRS está em execução para saber onde ir iniciar o serviço para resolver o problema.

Ler pilhas de chamadas dessa maneira pode ajudá-lo isolate local de onde um erro está realmente vindo. A chamada final na pilha pode ser algo como YourCompany.Crm.Extensions.UpdateRecord(); isso informa que o erro parece ser proveniente de qualquer código escrito por seus desenvolvedores ou talvez uma solução de ISV que você adquiriu.

Não é incomum para erros CRM realmente venham de SQL Server no caso de integridade referencial (RI) ou outras restrições de nível de SQL ou do .NET Framework propriamente dito.

Reproduzir em casa exemplo

Agora vamos dar uma chance de jogar em casa. Vamos supor que você criou um novo usuário no CRM e esse usuário está tentando usar o sistema pela primeira vez e está obtendo o erro, como mostrado na Figura 6 .

Figura 6 A CRM erro recebido por um usuário primeiro tempo

Que etapas você executaria para resolver esse problema? Para resolver esse problema, execute vamos nosso fluxo de trabalho solução de problemas básico.

1. Um problema ou erro é identificado e reproduzido.

Você deve perguntar ao usuário o que ele estava tentando fazer quando ele recebeu o erro e tente reproduzir as etapas para ver se você pode recriar o erro.

2. O problema precisa ser compreendido.

Vamos ler a mensagem erro de ponto de vista a solução de problemas: "o usuário conectado não tem as permissões de segurança apropriadas."

Para entender o problema, você precisa ser capaz de responder duas perguntas: "o usuário conectado" quem é? O que "permissão de segurança" que ele "tem"?

3. O problema precisa estar isolado.

Nesse caso, você pode responder as duas perguntas usando o rastreamento de CRM. Você sabe que o rastreamento é necessária porque essa página de erro está em uma caixa de diálogo e não fornece as informações que seriam DevErrors. CRM não registra erros de privilégio assim no log de eventos. Vamos ativar o rastreamento e reproduzir o problema usando o mesmo usuário. Log de rastreamento fornece o seguinte erro detalhado:

MSCRM Error Report:
Error: Exception has been thrown by the target of an invocation.
Error Number: 0x80040220
Error Message: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: 
  e76c5f50-40b3-dc11-8797-0003ffb8057d and PrivilegeId: 7863e80f-0ab2-4d67-a641-37d9f342c7e3
Error Details: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: 
  e76c5f50-40b3-dc11-8797-0003ffb8057d and PrivilegeId: 7863e80f-0ab2-4d67-a641-37d9f342c7e3
Source File: Not available
Line Number: Not available
Request URL: https://localhost:5555/AscentiumCrmDev/sfa/accts/edit.aspx?id={906C2F37-8D28-DE11-8D9F-0003FFB23445}
Stack Trace Info: [CrmSecurityException: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: 
  e76c5f50-40b3-dc11-8797-0003ffb8057d and PrivilegeId: 7863e80f-0ab2-4d67-a641-37d9f342c7e3] at
  Microsoft.Crm.BusinessEntities.SecurityLibrary.CheckPrivilege(Guid user, Guid privilege, ExecutionContext context)
…

Este erro e lendo os detalhes de pilha de chamada, você pode ver que o problema é causado por uma falha de privilégio de verificação do CRM. Você pode ver o GUID do usuário que fez a solicitação, bem como o GUID do privilégio que ele tentou usar.

Se você executar o Live Search no privilégio 7863e80f-0ab2-4 d 67-a641-37d9f342c7e3, a primeira ocorrência é o SDK do Microsoft CRM.

Seguir este link, você pode ver que o privilégio de usuário precisa é prvWriteAccount, que é o privilégio que concede direitos de atualização na entidade conta. O mesmo método funcionaria para qualquer uma das centenas de pronta de privilégios, como os GUIDs são conhecidos. Se você procurar a identificação de privilégio e ele não foi encontrado, que o privilégio pode estar em uma de suas entidades personalizadas, caso em que você precisará consultar o local do SQL Server para descobrir qual privilégio está sendo solicitado. O script a seguir produzirá as mesmas informações:

SELECT PrivilegeId, Name
FROM PrivilegeBase
WHERE PrivilegeId = '7863e80f-0ab2-4d67-a641-37d9f342c7e3'

Agora que você sabe que privilégio é necessário, basta verificar o usuário que está faltando o privilégio. Enquanto você às vezes pode assumir que o usuário final chamado é o, você sempre não é possível ter certeza, como quando ações são executadas por meio de código, plug-ins ou extensões personalizadas. Em tais casos, convém executar uma consulta para localizar o nome do usuário CRM pensou que estava tentando usar o privilégio. O script a seguir irá lidar com isso:

SELECT SystemUserId, DomainName
FROM SystemUserBase
WHERE SystemUserId = 'e76c5f50-40b3-dc11-8797-0003ffb8057d'

TIP: Se o usuário GUID é todos os zeros (00000000-0000-0000-0000-000000000000), o usuário provavelmente é a conta SYSTEM e isso significa que o usuário chamado provavelmente foi uma conta como serviço de rede. Contas do sistema normalmente não têm funções CRM; em vez disso, eles são concedidos privilégios elevados via PrivUserGroup no Active Directory.

4. A correção precisa ser identificados e compreendido.

Você agora pode ir em CRM e seleção para ver quais funções o usuário possui, como mostrado na Figura 7 .

Figura 7 funções de usuário no CRM

Você pode, em seguida, analisar e ver que a função de vendedor realmente falta a gravar em privilégio conta conforme mostrado na Figura 8 .

A Figura 8 mostra registros principais da função vendedor de que ele ausente o privilégio de gravação em conta.

5. A correção precisa ser aplicada e verificada.

Para corrigir o problema, basta você conceder o privilégio de gravação para essa função e salvá-lo. Tenha cuidado para Certifique-se que você saiba que isso afetará outros usuários. Depois de aplicar a correção, você pode pedir o usuário para tentar novamente verificar que o problema foi resolvido. Em seguida, você deve desabilitar o rastreamento e chame caso fechado.

Resumindo

Solução de problemas do Microsoft Dynamics CRM significa seguindo as regras básicas básico e uma metodologia que inclui identificando o problema real, restringir o escopo, isolar o problema e noções básicas sobre a correção. Você encontrará o DevErrors, log de eventos e ferramentas de rastreamento no Microsoft Dynamics CRM críticos em seus esforços de solução de problemas.

Aaron Ancião (Microsoft Dynamics CRM MVP) trabalha para a Ascentium, uma tecnologia consultoria e interativa agência de marketing. Visite o blog Ascentium em Ascentium.com/blog/CRM.