Boa tarde pessoal!
Hoje vou compartilhar com vocês um problema que enfrentei com o CRM2011.
Todo o ambiente de produção deste CRM já havia sido entregue ao cliente, tudo estava funcionando...quase tudo!
Quando um novo relatório era criado e importado para o CRM, ao executa-lo, este relatório não exibia nenhum dado. Durante a criação de um novo relatório era possível ver no preview que tudo estava correto, método de autenticação, banco de dados DataSource...tudo.
Este problema persistiu no cliente por um longo tempo, consultores e desenvolvedores tentaram varias possíveis soluções e nada...
Algumas semanas depois estive neste cliente e comecei a analisar o problema. Primeiro criei um relatório simples no ambiente de homologação, importei ele para o CRM e tudo ok. Neste caso o ambiente de homologação e todos os componentes estão instalados em um único servidor.
No ambiente de produção temos um servidor para cada componente. Repeti a criação de um report, durante o preview ele funcionou normalmente, mas ao importa-lo para o CRM ele novamente não trouxe os dados que deveria trazer.
Comecei a verificar os logs gerados no event viewer e também os logs gerados pelo SQL Server.
Obs: O cliente já havia reportado estas entradas nos logs do SQL Server...
Ao abrir o log do SQL Server, a cada tentativa de geração do relatorio, um novo registro como este logo abaixo era criado:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: 192.168.0.174]
Lembrando que este registro somente era gravado quando o relatório era executado pelo CRM via browser.
Minha duvida, que ainda permanece, é a seguinte... Por que o CRM utiliza autenticação anônima para exibir estes relatórios?
Minha primeira tentativa para tentar corrigir o problema, ainda no ambiente de homologação, foi importar esta conta para a instância do CRM e deixa-la como "SYSADMIN". Esta ação, apesar de não ser a mais correta, resolveu o problema e os relatórios customizados passaram a funcionar.
No ambiente de produção restringi mais a permissão para esta conta e com isso os relatorios também passaram a funcionar!
Portanto, a solução para este problema foi importar esta conta para o SQL Server com as devidas permissões no banco de dados do CRM e Reporting Services.
Resolvido o problema, passei a procurar o porque dele, por qual razão o CRM estava utilizando autenticação anônima para os relatórios customizados, e durante esta pesquisa encontrei o seguinte link:
http://blog.sonomapartners.com/2007/04/kerberos_and_de.html
Depois de ler o post ajustei as configurações no servidor do cliente e tudo funcionou perfeitamente.
Apesar de ser de 2007 este post é muito valido, sugiro a vocês a leitura dele!
Até a próxima pessoal!
Mostrando postagens com marcador Report. Mostrar todas as postagens
Mostrando postagens com marcador Report. Mostrar todas as postagens
terça-feira, 15 de abril de 2014
segunda-feira, 7 de abril de 2014
A dica do dia - Reports AX2012!
Olá pessoal!
Hoje venho compartilhar com vocês uma dica útil!
No AX2012 por inúmeras razões faz-se necessário a manutenção no servidor, ou serviço, de relatório. Esta manutenção em grande parte exige a reinicialização do serviço do Reporting Services, e nesta ação o cache do SSRS é limpo. Após esta limpeza, reinicialização do serviço do SSRS, os relatórios levam um longo tempo para serem exibidos novamente. Por exemplo, devido a uma reinicialização do servidor de relatórios, na manha seguinte, os usuários notam uma grande lentidão ao tentar acessar os reports do AX.
Este efeito pode ser minimizado utilizando uma classe do AX chamada SRSReportServerWarmup. Esta classe é padrão do CU7 do AX2012 R2. Ao executar esta classe ela prepara o Report Server para utilização.
Para que você, e seus usuários, de fato se beneficiem deste recurso, é aconselhado que você programe esta classe para ser executada via batch job logo após a reinicialização do serviço do Reporting Services.
Analise a necessidade de executar esta classe e agende este batch conforme melhor for para o seu cenário!
O primeiro passo para utilizar esta classe e efetuar o deploy do Report "SRSReportServerWarmup", para tanto siga a dica da imagem abaixo:
Caso o deploy seja executado sem erros a seguinte mensagem será exibida:
Com o deploy do report efetuado vamos agora criar um grupo de lote para executa-lo. Abra o AX e vá em > Administração do Sistema > Configuração > Grupo de lotes. Crie um novo grupo de lote seguindo o exemplo das imagens abaixo:
Agora precisamos configurar o trabalho em lote que executará a classe do "SRSReportServerWarmup". Acesse a AOT do AX, expanda as Classes e procure pela classe "SRSReportServerWarmup", ao encontra-la clique com o botão direito sobre ela e clique em Abrir.
Marque a caixa de "Processamento em lotes" e preencha o campo "Grupo de lotes"com o grupo criado no passo anterior. Depois clique no botão "Recorrência".
Configure a recorrência de execução deste lote. Neste caso é preciso analisar a janela de manutençao exigida pelo Reporting Services e configurar esta recorrência de acordo com ela. No meu servidor eu configurei de forma a executar este job todos os dias logo pela manha, as 07:00am.
Depois de tudo configurado clique em OK até fechar todas as janelas e a seguinte mensagem será exibida:
Agora que tudo está configurado, todos as manhas um report básico será executado deixando mais rápido o acesso aos relatórios por parte dos usuários após uma manutenção ou problema no Reporting Services.
Ainda é possível estender a funcionalidade desta classe, fazendo com que ela execute também outros relatórios, aqueles muito utilizados por determinados usuários, deixando o trabalho destes usuários mais rápido! Para tanto consulte este link.
Fonte: Technet
Hoje venho compartilhar com vocês uma dica útil!
No AX2012 por inúmeras razões faz-se necessário a manutenção no servidor, ou serviço, de relatório. Esta manutenção em grande parte exige a reinicialização do serviço do Reporting Services, e nesta ação o cache do SSRS é limpo. Após esta limpeza, reinicialização do serviço do SSRS, os relatórios levam um longo tempo para serem exibidos novamente. Por exemplo, devido a uma reinicialização do servidor de relatórios, na manha seguinte, os usuários notam uma grande lentidão ao tentar acessar os reports do AX.
Este efeito pode ser minimizado utilizando uma classe do AX chamada SRSReportServerWarmup. Esta classe é padrão do CU7 do AX2012 R2. Ao executar esta classe ela prepara o Report Server para utilização.
Para que você, e seus usuários, de fato se beneficiem deste recurso, é aconselhado que você programe esta classe para ser executada via batch job logo após a reinicialização do serviço do Reporting Services.
Analise a necessidade de executar esta classe e agende este batch conforme melhor for para o seu cenário!
O primeiro passo para utilizar esta classe e efetuar o deploy do Report "SRSReportServerWarmup", para tanto siga a dica da imagem abaixo:
Com o deploy do report efetuado vamos agora criar um grupo de lote para executa-lo. Abra o AX e vá em > Administração do Sistema > Configuração > Grupo de lotes. Crie um novo grupo de lote seguindo o exemplo das imagens abaixo:
Agora precisamos configurar o trabalho em lote que executará a classe do "SRSReportServerWarmup". Acesse a AOT do AX, expanda as Classes e procure pela classe "SRSReportServerWarmup", ao encontra-la clique com o botão direito sobre ela e clique em Abrir.
Marque a caixa de "Processamento em lotes" e preencha o campo "Grupo de lotes"com o grupo criado no passo anterior. Depois clique no botão "Recorrência".
Configure a recorrência de execução deste lote. Neste caso é preciso analisar a janela de manutençao exigida pelo Reporting Services e configurar esta recorrência de acordo com ela. No meu servidor eu configurei de forma a executar este job todos os dias logo pela manha, as 07:00am.
Depois de tudo configurado clique em OK até fechar todas as janelas e a seguinte mensagem será exibida:
Agora que tudo está configurado, todos as manhas um report básico será executado deixando mais rápido o acesso aos relatórios por parte dos usuários após uma manutenção ou problema no Reporting Services.
Ainda é possível estender a funcionalidade desta classe, fazendo com que ela execute também outros relatórios, aqueles muito utilizados por determinados usuários, deixando o trabalho destes usuários mais rápido! Para tanto consulte este link.
Fonte: Technet
quinta-feira, 13 de março de 2014
Problemas Danfe AX2012 e Codigo de Barras.
Olá pessoal!
Mais um problema solucionado hoje!!! Então vamos compartilhar a experiência!
Um consultor nos relatou um problema em um ambiente de homologação de um cliente. O problema era durante a impressão de danfes no AX2012 deste ambiente. Ao visualizar a impressão de uma danfe o codigo de barras nao era exibido corretamente, ao invez dele eram exibidos apenas simbolos, caracteres especiais.
Na imagem abaixo, mesmo desfocada e com campos apagados podemos ver os caracteres especiais ao invés do código de barra.
Hoje consegui entender exatamente qual o problema...
Esta tela é na verdade um relatorio do AX2012, o nome do report na AOT é EFDocDANFE_BR.
Eu realmente nao sabia disso...só descobri hoje!!!!!
Sabendo disso imaginei que o tamanho do campo estava pequeno para exibir corretamente o código de barras e por isso apareciam apenas caracteres especiais. Parecido com o Excel!!!
Queria abrir as propriedades do relatório para verificar esta configuração e pra isso precisei instalar o Visual Studio Tools, durante esta instalação eu precisei reiniciar o serviço do SSRS.
Após instalar o Visual Studio Tools eu abri novamente o AX e tentei imprimir a danfe novamente. Para minha surpresa a danfe foi impressa corretamente exibindo o codigo de barras perfeitamente...!!!
Resumindo, a solução para o problema foi apenas reiniciar o serviço do Reporting Services no servidor de relatórios, só isso!!!
Até a próxima pessoal!
Mais um problema solucionado hoje!!! Então vamos compartilhar a experiência!
Um consultor nos relatou um problema em um ambiente de homologação de um cliente. O problema era durante a impressão de danfes no AX2012 deste ambiente. Ao visualizar a impressão de uma danfe o codigo de barras nao era exibido corretamente, ao invez dele eram exibidos apenas simbolos, caracteres especiais.
Na imagem abaixo, mesmo desfocada e com campos apagados podemos ver os caracteres especiais ao invés do código de barra.
Hoje consegui entender exatamente qual o problema...
Esta tela é na verdade um relatorio do AX2012, o nome do report na AOT é EFDocDANFE_BR.
Eu realmente nao sabia disso...só descobri hoje!!!!!
Sabendo disso imaginei que o tamanho do campo estava pequeno para exibir corretamente o código de barras e por isso apareciam apenas caracteres especiais. Parecido com o Excel!!!
Queria abrir as propriedades do relatório para verificar esta configuração e pra isso precisei instalar o Visual Studio Tools, durante esta instalação eu precisei reiniciar o serviço do SSRS.
Após instalar o Visual Studio Tools eu abri novamente o AX e tentei imprimir a danfe novamente. Para minha surpresa a danfe foi impressa corretamente exibindo o codigo de barras perfeitamente...!!!
Resumindo, a solução para o problema foi apenas reiniciar o serviço do Reporting Services no servidor de relatórios, só isso!!!
Até a próxima pessoal!
sexta-feira, 24 de janeiro de 2014
Relatorios AX2012 R2 - Erro de ID SRSServers Table
Olá pessoal!
Hoje vou compartilhar com vocês um problema pelo qual passei na implementação de um ambiente de produção do Microsoft Dynamics AX2012 R2 com o CU7.
Neste ambiente tenho os seguintes servidores:
06 Servidores de AOS
01 Servidor Web
02 Servidores SQL em Cluster
Dos 06 AOS's apenas 04 eram destinados a conexões de usuários, os outros 02 seriam apenas Batch Servers.
Todo o ambiente foi instalado corretamente. Os demais componentes do AX foram instalados sem erro. Neste cenário utilizei o recurso de NLB e tudo funcionou perfeitamente.
Efetuei diversos testes derrubando AOS's para verificar o balanceamento de carga de todos os componentes e tudo ok!!!
Ao efetuar testes com os relatorios do AX me deparei com um erro inesperado.
Na configuração dos relatórios eu tinha exatamente o seguinte:
Até aqui tudo normal, esta foi a configuração registrada durante o setup do componente de relatório do AX.
Notem que somente o AOS estava registrado nesta configuração... e este era exatamente o meu problema. Ao tentar executar algum relatorio de algum outro AOS o seguinte erro era exibido:
The default Report Server Configuration ID could not be found in the SRSServers table.
Este erro ocorre porque quando temos mais de 01 AOS na estrutura é necessário, obrigatório, adicionar este(s) AOS no form de configuração do Report Server.
Após adicionar os demais AOS's à configuração do Report Server no AX os relatorios passaram a funcionar sem nenhum problema em todos os AOS's.
E assim meu problema foi solucionado!
Fonte: TechNet
Hoje vou compartilhar com vocês um problema pelo qual passei na implementação de um ambiente de produção do Microsoft Dynamics AX2012 R2 com o CU7.
Neste ambiente tenho os seguintes servidores:
06 Servidores de AOS
01 Servidor Web
02 Servidores SQL em Cluster
Dos 06 AOS's apenas 04 eram destinados a conexões de usuários, os outros 02 seriam apenas Batch Servers.
Todo o ambiente foi instalado corretamente. Os demais componentes do AX foram instalados sem erro. Neste cenário utilizei o recurso de NLB e tudo funcionou perfeitamente.
Efetuei diversos testes derrubando AOS's para verificar o balanceamento de carga de todos os componentes e tudo ok!!!
Ao efetuar testes com os relatorios do AX me deparei com um erro inesperado.
Na configuração dos relatórios eu tinha exatamente o seguinte:
Notem que somente o AOS estava registrado nesta configuração... e este era exatamente o meu problema. Ao tentar executar algum relatorio de algum outro AOS o seguinte erro era exibido:
The default Report Server Configuration ID could not be found in the SRSServers table.
Este erro ocorre porque quando temos mais de 01 AOS na estrutura é necessário, obrigatório, adicionar este(s) AOS no form de configuração do Report Server.
Após adicionar os demais AOS's à configuração do Report Server no AX os relatorios passaram a funcionar sem nenhum problema em todos os AOS's.
E assim meu problema foi solucionado!
Fonte: TechNet
Assinar:
Postagens (Atom)