Hey guys!
Nesse post eu gostaria de demonstrar a vocês como como logar a visualização dos relatórios e identificar qual usuário está acessando, isto é, como gravar em uma tabela do banco de dados, qual usuário está acessando determinado relatório e quando isso foi feito.
A ideia desse post partiu de uma dúvida em um grupo do Telegram e achei que poderia ajudar mais pessoas publicando esse artigo. Inclusive, quando precisei criar algo desse tipo, não achei muita documentação clara e objetiva na internet.
Como logar a visualização dos relatórios
Como o intuito desse post não é ensinar como criar relatórios no SSRS (vou criar um post sobre isso), vou avançar para o objetivo desse artigo. Em resumo, o que você deve fazer para atingir esse objetivo é utilizar uma variável padrão do SSRS para identificar o usuário que está executando o relatório (=User!UserID) e passar essa variável para o conjunto de dados que está consultando os dados no banco, de modo que ele inclua no processo de consulta, a operação de gravação desse log.
Achou difícil? Vou detalhar 🙂
Partindo do pressuposto que você tem um relatório funcional do Reporting Services, como o demonstrado abaixo, vamos começar a preparar nossa rotina para que a gente consiga logar a execução do relatório:
Não posso deixar de comentar aqui, como eu apoio, recomendo e SEMPRE utilizo Stored Procedures para a execução dos meus relatórios. Isso me dá uma liberdade e flexibilidade muito grande para consultar e processar os dados, passando parâmetros e fazendo com o que eu possa editar a consulta apenas alterando objetos no banco, sem precisar alterar o meu relatório.
O código-fonte atual da minha Stored Procedure é assim:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
CREATE PROCEDURE dbo.stpConsulta_Relatorio ( @Ds_Objeto AS VARCHAR(100) ) AS BEGIN SELECT * FROM sys.objects WHERE [name] = @Ds_Objeto END GO |
Agora vamos iniciar as alterações para começar a logar as alterações, inclusive, com o nome do usuário que está consultando o relatório.
Primeiramente, vamos criar a tabela que vai armazenar as informações dos logs de execução dos relatórios:
|
1 2 3 4 5 6 |
CREATE TABLE dbo.Logs_Relatorios ( Id_Log INT IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED, Dt_Log DATETIME DEFAULT GETDATE(), Ds_Relatorio VARCHAR(100), Ds_Usuario VARCHAR(100) ) WITH(DATA_COMPRESSION=PAGE) |
Vamos alterar a nossa Stored Procedure que consulta os dados para que ela faça a inclusão do registro de log. Para isso, vou adicionar o parâmetro @Ds_Usuario na SP para que ela receba o nome do usuário e insira no log do banco.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
ALTER PROCEDURE dbo.stpConsulta_Relatorio ( @Ds_Objeto AS VARCHAR(100), @Ds_Usuario AS VARCHAR(100) ) AS BEGIN -- Loga as operações INSERT INTO dbo.Logs_Relatorios ( Dt_Log, Ds_Relatorio, Ds_Usuario ) VALUES ( GETDATE(), 'Consulta_Relatorio', @Ds_Usuario) -- Executa o relatório SELECT * FROM sys.objects WHERE [name] = @Ds_Objeto END GO |
O próximo passo, é alterar o nosso conjunto de dados no Report Builder (Construtor de Relatórios) para incluir o parâmetro de usuário:
Uma vez com a tela de configurações do conjunto de dados aberta, clique na opção de Parâmetros e adicione a variável @Ds_Usuario na chamada da Stored Procedure:
Ao clicar no botão de Expressão, selecione o campo interno UserID (=User!UserID):
Após realizar essas alterações, salve o Report e acesse-o no portal do SSRS:
Aos consultar os dados gerados na tabela de histórico (dbo.Logs_Relatorios), podemos visualizar os registros gerados, com a data de quando o relatório foi consultado e quem consultou:
[Vídeo] – Como logar a visualização dos relatórios
Se você é do tipo de pessoa que tem mais facilidade em aprender com elementos visuais ricos de imagem e áudio (vulgo Vídeo), preparei uma rápido vídeo-aula de como fazer isso:
E a view ExecutionLog?
Se você conhece as views e tabelas de catálogo do Reporting Services, deve estar se perguntando: “Por quê não utilizar a view ExecutionLog, que já tem todas essas informações armazenadas automaticamente, para todos os relatórios?”
Bom, antes de mais nada, vou apresentar a view ExecutionLog para quem não conhece. Essa view, que traz os dados da tabela ExecutionLogStorage, registra todas as execuções de todos os relatórios do Reporting Services, incluindo os parâmetros utilizados, usuário que executou o relatório, tempo de resposta, tempo de render, etc..
|
1 2 |
SELECT * FROM ReportServer.dbo.ExecutionLog |
Result:
“Então, por quê utilizar o controle manual de auditoria, se o próprio Report Server já faz isso pra mim, trazendo mais um monte de informação e estatísticas interessantes, para todos os relatórios e automaticamente?”
R: Embora eu concorde com tudo isso, existem determinadas situações que te forçam a buscar alternativas para implementar seus controles e alguns dos motivos que me levariam a utilizar essa solução, são:
- Equipe de BI deseja centralizar todas as informações de Log, de todas as instâncias do RS, em um database específico
- Equipe de BI não possui acesso de leitura no database ReportServer
- Por padrão, o Report Server possui um limite de 60 dias para armazenar os dados da tabela ExecutionLogStorage.
Uma alternativa interessante, seria a equipe de BI criar um job que colete esses dados temporários e armazene em uma tabela definitiva, mas quando os analistas de BI não possuem acesso para criar jobs, o controle manual dos logs acaba sendo uma opção viável
- Restrições diversas de espaço em disco e permissões na instância
Além disso, o exemplo demonstrado acima pode servir para outros fins, que não a de auditoria, como por exemplo, filtrar os dados de acordo com o usuário, retornar consultas diferentes ou até mesmo, restringir acesso dentro da própria Stored Procedure.
Bom pessoal, é isso aí!
Espero que vocês tenham gostado desse artigo e até o próximo!
Abraço!
Portuguese 
English
Show Dirceu!! Muito bem explicado!