.NET

5 jun, 2013

Explorando Microsoft SQL Reporting Services – Parte 06

Publicidade

Olá pessoal, como prometido, hoje apresentaremos como consumir os relatórios, bem como outros exemplos com funcionalidades incríveis. Lembrando que todos os códigos aqui implementados estão disponíveis no meu blog http://caiodotnet.blogspot.com.

Bom divertimento!

Remote mode – funcionalidades adicionais

Nessa sessão falaremos de algumas funcionalidades adicionais interessantes sobre os relatórios remotos.

Leia todos os artigos dessa série

Serviço de Entrega

Como já mencionamos, o Reporting Services nos permite configurar um serviço de entrega de relatórios. Apresentaremos a seguir um exemplo simples dessa poderosa ferramenta.

Criaremos um serviço que gera o relatório em formato de arquivo em um compartilhamento da nossa estação de trabalho.

Antes de começarmos as configurações é necessário ter certeza que o serviço “SQL Server Agent” esteja ativo. É ele o responsável pelo monitoramento de Jobs, Schedules, Alertas e Eventos do SQL Server:

  Figura 4.1 –Serviços do Windows – SQL Server Agent
Figura 6.1 –Serviços do Windows – SQL Server Agent

Em seguida, acessamos o Report Manager, selecionamos um dos nossos relatórios e criaremos um novo Subscription, como exibido na figura abaixo:

Figura 6.2 –Selecionando um relatório e criando uma nova Subscription
Figura 6.2 –Selecionando um relatório e criando uma nova Subscription

Agora configuraremos nosso serviço de entrega, de modo a gerar um relatório em formato de arquivo PDF, criado em um compartilhamento da nossa estação de trabalho. Atente para o agendamento criado (botão Select Schedule) – ver figura abaixo.

Figura 6.3 –Configurações do subscription
Figura 6.3 –Configurações do subscription

Percebemos que nosso relatório possui alguns parâmetros, e que são especificados durante o processo de criação da subscription, como exibido na figura abaixo.

Figura 6.4 - Configuração dos parâmetros do relatório
Figura 6.4 – Configuração dos parâmetros do relatório

Cache

Como mencionamos anteriormente (Remote Mode – Arquitetura), uma vez gerado o formato intermediário do relatório, o RS, antes de renderizá-lo, o armazena temporariamente no banco de dados, ReportServerTempDB.

O RS disponibiliza três tipos de cache – de sessão , de execução e por snapshot.

Cache de sessão ou implícito é aquele gerado pelo RS, quando um mesmo usuário requer um relatório com o mesmo conjunto de parâmetros em um curto intervalo de tempo, esse cache é utilizado, por exemplo, quando um usuário requer, dentro de um mesmo relatório recursos de paginação ou renderização em diversos formatos. O RS gera uma cópia do relatório por cliente, como vemos na figura 4.5 abaixo:

Figura 6.5 –Cache de sessão
Figura 6.5 –Cache de sessão

Cache de execução, é similar ao cache de sessão, uma vez que ambos são armazenados no mesmo repositório. No entanto ele necessita ser configurado manualmente através do link “Execution” nas propriedades do relatório do Report Manager, como vemos na figura abaixo:

Figura 6.6 –Cache de relatório por execução.
Figura 6.6 –Cache de relatório por execução.

 Outra diferença crucial nesse relatório em relação ao cache de sessão é que ele pode ser compartilhado por “n” usuários como demonstrado na imagem abaixo:

Figura 6.7 –Cache de execução.
Figura 6.7 –Cache de execução.

É gerada uma cópia do relatório por conjunto de parâmetros selecionados. E não é possível ter esse tipo de cache se as credenciais de segurança para acesso ao repositório de dados do relatório forem solicitadas ao usuário.

Cache de snapshot, os dois primeiros são geridos pelo próprio RS, logo temos pouco controle sobre eles. Por exemplo, não sabemos quando o relatório será solicitado a primeira vez, nem quando o RS iniciará a contar seu tempo de validade. Em alguns casos, por exemplo, em relatórios que tenham um tempo de execução muito grande, seria interessante gerar esse relatório fora do horário de pico, salvar uma copia sua (no banco de dados ReportServer, tabela SnapshotData). Para criar esse tipo de cache utiliza-se o Report Manager, nas propriedades do relatório, opção Execution. No entanto esse tipo de cache não permite que o usuário modifique os parâmetros do relatório e necessário especificar valores padrão para os parâmetros.

Figura 6.8 –Cache de snapshot.
Figura 6.8 –Cache de snapshot.

Segurança para Reporting Services

Considerando que os relatórios são disponibilizados como uma aplicação web, muitas das boas práticas de segurança utilizadas em aplicações ASP .NET são aplicáveis aqui, por isso focaremos nossa análise nas funcionalidades de autenticação e autorização.

A segurança dos relatórios hospedados no reporting services é baseada em roles, ou seja, dado um conjunto de funcionalidades (rotulado role), tais como gerenciar relatórios, visualizar pastas, visualizar datasources, dentre outras, e sabendo-se que por padrão o Reporting Services utiliza o modelo de autenticação Windows (baseado no  Active Directory do sistema operacional). Para cada relatório ou conjunto de relatórios (armazenados em pastas), associamos uma ou mais roles e assim temos todas as funcionalidades possíveis para aqueles relatórios.  Às roles são vinculados os usuários ou grupos de usuários do Active Directory do Windows.

Todas essas configurações podem ser feitas através do Report Manager ou via SQL Server Management Studio, como demonstrados nas figuras abaixo:

Aqui apresentamos a edição/criação das roles padrão do RS e suas respectivas funcionalidades, via SSMS.

Figura 6.9 –edição de roles – SQL Server Management Studio
Figura 6.9 –edição de roles – SQL Server Management Studio

Para atribuição das permissões (as roles), a uma pasta ou relatório, basta selecionar o menu de opções com o botão direito, selecionar a opção Properties e finalmente Permissions. Vejamos que podemos associar um usuário ou grupo de domínio às roles (botão Add Grou por User…)

Figura 6.10 - adicionando usuários e grupos às roles – SQL Server Management Studio
Figura 6.10 – adicionando usuários e grupos às roles – SQL Server Management Studio

Basicamente é assim que gerimos a segurança dos relatórios no reporting services, onde é necessário utilizar uma conta de usuário de domínio com os devidos privilégios.

Mas percebam que os relatórios são disponibilizados através de uma aplicação web http://<servidor>/reportserver ou http://<servidor>/reports que tem seus modelos de autenticação como uma aplicação web qualquer – integrada, forms, anônima, etc, sendo que por padrão é utilizada a autenticação Windows e assim a identificação do usuário da aplicação é utilizado para autenticação junto ao RS e pode ser utilizado para o repositório de dados como ilustra a figura abaixo:

Figura 6.11 – modelo de segurança
Figura 6.11 – modelo de segurança

Esse modelo com usuários integrados ao AD fica muito restrito ao ambiente intranet, uma proposta mais genérica, seria uma na qual a aplicação web tem autenticação form, com um repositório customizado de usuários, e para o acesso aos relatórios do RS passamos as credenciais de um usuário do AD previamente configurado no RS a partir da aplicação web, e finalmente para acesso ao banco de dados usamos um usuário do SQL Server com acesso restrito às tabelas/views/procedures necessárias para concepção dos relatórios. Nesse modelo o segredo esta na passagem das credencias para o RS a partir da aplicação e isso veremos na sessão de integração de aplicação ASP .Net com RS.

Outro aspecto de segurança relevante é a criptografia dos dados, afinal os dados dos relatórios são trafegados sobre o protocolo HTTP para isso é possível utilizar recursos tais como:

  •        Protocolo SSL/HTTPS e certificados digitais.
  •        VPNs
  •        Wireless com chaves de criptografias
  •        Terminal Services
  •         IPSec, que é um protocolo de segurança padrão para TCP/IP 

Conversão de arquivos RDLC para RDL

Uma funcionalidade muito interessante que temos, é a capacidade de converter relatórios RLDC para RLC, e isso é mais simples que se pode imaginar, basta renomear a extensão do arquivo e incluir no projeto (adicionar um item existente) e atualizar o Dataset (opções de conexão e instrução), simples assim. O segredo dessa facilidade é que os relatórios no fundo utilizam a mesma estrutura que é a linguagem de definição de relatórios.

Integrando com uma aplicação ASP.NET

Até agora acessamos nosso relatórios a partir do ambiente do RS (via report manager), no entanto fica fácil perceber algumas de suas limitações tais como:

  • Identidade visual limitada
  • Validação dos parâmetros limitada
  • Impossibilidade de integração dos relatórios ao aplicativo

Para resolvermos esses problemas, podemos incluir nossos relatórios nas aplicações usando o controle ReportViewer. Para integração dos relatórios com o ReportViewer, é necessário:

  • Configurar adequadamente o controle, que classificamos da seguinte forma:

Configurações de Processamento, onde especificamos parâmetros de renderização e modo de processamento.

Parâmetros: ProcessingMode, AsyncRendering e SizeToReportContent.

Configurações Funcionais, onde especificamos quais funcionalidades do controle disponibilizaremos para os usuários, tais como exportação, zoom, impressão, navegação, prompt de parâmetros, dentre outros.

Parâmetros: ShowToolBar, ShowPageNavigationControls, ShowPrintButton, ShowExportControls, ShowParameterPrompts, ShowFindControls, etc.

Configurações de segurança, onde informamos as credencias do usuário de acesso aos relatórios. Nesse caso é necessário codificar uma classe que implemente a interface, Microsoft.Reporting.WebForms.IReportServerCredentials.

Parâmetros: ServerReport.ReportServerCredentials

Configurações de localização, onde especificamos a localização (servidor/pasta/relatório)  do relatório.

Parâmetros: ServerReport.ReportServerUrl, ServerReport.ReportPath

  •  Criar interface com usuário para obtenção dos parâmetros do relatório

Usando controles da ASP .NET

  • Codificar a validação dos parâmetros
  • Codificar os parâmetros do relatório para o controle ReportViewer

De toda codificação necessária, a mais importante é a criação da classe responsável pela passagem das credenciais do usuário para acesso ao relatório, como mostrado no código abaixo:

public class ReportCredentials : Microsoft.Reporting.WebForms.IReportServerCredentials
{

private string _userName;

private string _passWord;

private string _domainName;

public ReportCredentials(string UserName, string PassWord,  string DomainName)

{

      _userName = UserName;

      _passWord = PassWord;

     _domainName = DomainName;

                }

public WindowsIdentity ImpersonationUser

{  get { return null; }  }

public ICredentials NetworkCredentials

{   get { return new NetworkCredential(_userName, _passWord, _domainName); } }

public bool GetFormsCredentials(out Cookie authCookie, out string user, out string password,

                                                                                                                                      out string authority)

{

     authCookie = null;

     user = password = authority = null;

     return false;

}

}

Conclusão

É isso aí, pessoal! Abordamos diversos assuntos referentes a essa importante ferramenta que é o Reporting Services, nos permitindo enriquecer consideravelmente nossas aplicações. Existem outros aspectos que não foram abordados, como o Report Builder, por exemplo, mas acredito que o que foi falado nessa série seja suficiente para que possamos implementar soluções ricas e inteligentes provendo aos nossos clientes recursos que, há até pouco tempo, se não eram impensáveis,  certamente eram de difícil implementação.

Espero que tenham gostado dessa série.. comentem…perguntem..critiquem.. grande abraço e até a próxima.