Olá,  pessoal! Hoje começaremos a ver a grande revolução no mundo dos relatórios, que são os “remote mode”. Começaremos por apresentar a arquitetura desse modelo de relatórios, bem como suas principais características e o processo de criação. Lembrando que todos os códigos aqui implementados estão disponíveis, só entrar em contato. Bom divertimento!

Os relatórios do modelo “Remote Mode” são baseados em ambiente web, sendo disponibilizados como uma aplicação asp.net qualquer, hospedados (e dependentes), no Intenet Information Server. São considerados remotos, porque são acessados pelos clientes via protocolo HTTP, e todo seu processamento é feito em um ambiente dedicado.

Nesse modelo de relatórios, o processamento dos relatórios é dividido entre diversos provedores de serviços, como exibido na figura 3.1 abaixo. Ao cliente (Windows e Web application, bem como qualquer outro que interprete SOAP), cabe apenas exibir os relatórios devidamente formatados através do nosso já conhecido controle ReportViewer.

Quando falamos da arquitetura do reporting services, temos os seguintes componentes principais:

• RS Engine, cuja principal função é gerar os relatórios;
• RS Configuration Database, ou catálogo, que funciona como um repositório centralizado dos metadados necessários para o serviço de relatórios;
• Report Manager, aplicação web para gerenciamento do catalogo de relatórios, datasources, segurança, schedules e cache.

Analisando detalhadamente a arquitetura do reporting services, apresentaremos seus componentes através do processamento de um relatório, como apresentado no infográfico da figura 3.2.

Inicialmente, temos a solicitação dos usuários (1) via HTTP ou SOAP, essa solicitação é interceptada pelo IIS (componentes HTTP Handler ou RS Web Service), que em seguida a envia para o elemento (2) Report Processor que analisa a requisição, e através de (3) consultas ao catálogo do RS  (banco de dados ReportServer e ReportServerTempDB),  tem-se as definições e metadados do relatório. Nesse instante o Report Processor valida as informações de acesso ao relatório. Se as permissões forem concedidas temos o processamento dos relatórios divididos em três estágios: consulta, execução e renderização, respectivamente passos 5, 6 e 7 da figura 3.2.

Com o relatório publicado (arquivo RDL), é gerado um assembly .NET que é armazenado no catalogo do RS, e sendo sua primeira execução, o RS carrega e executa esse assembly, que através do componente Data Extensions (4) é feita a pesquisa (5) para carga do datasource do relatório, e combinando o conteúdo do dataset gerado com as informações de layout, é gerado um relatório em um formato intermediário (6), o que significa ganhos de performance, uma vez que esse formato pode ser reaproveitado no caso de exportação do relatório em outros formatos que não o da renderização – processo esse que é executado para atender a requisição inicial do usuário (7). Esse formato intermediário também pode ser armazenado no repositório temporário do RS no caso de configurações de cache. 

Os relatórios “remote mode” caracterizam-se especialmente por:

• Modelo de segurança de aplicações web .NET;
• Interatividade com links, Document Map;
• Exporta para vários formatos [csv, excell, pdv, html];
• Filtros, ordenação, agrupamento e funções de agregação;
• Formatação rica e inteligente, com imagens, fontes e cores;
• Liberdade para interatividade com o usuário final;
• Suporta código customizado e assemblies externos;
• Disponibiliza os relatórios, sob demanda ou por entrega.

Seus elementos fundamentais correlacionam-se conforme a figura abaixo:

 

A partir dessa sessão começaremos a implementar alguns relatórios exemplo e para tal utilizaremos o mesmo banco de dados utilizado nos relatórios “local mode” – vide figura 2.3.

Antes de iniciar a criação dos relatórios é necessário nos certificarmos que todos os serviços estejam operacionais para tal convém verificar as ferramentas: Reporting Services Configuration Manager, onde podemos chegar as configurações do serviço, do diretório virtual, web services, dos bancos de dados do RS, serviços de email, integração com SharePoint, etc, além do aplicativo web Report Manager, acessível por padrão no endereço http://<servidor>/Reports, onde <servidor> corresponde ao nome ou endereço IP, da estação no qual o reporting services se encontra, se for na sua estação de trabalho localhost, também funciona.

 

Ao contrário dos relatórios “Local Mode”, aqui temos um projeto específico para os relatórios e outro(s) para o(s) cliente(s).  Nesse primeiro momento, nos concentraremos na criação, deploy e consumo dos relatórios. Utilizamos o SQL Server Business Intelligence Development Studio, e criamos um novo projeto com o template Report Server Project.

Basicamente uma aplicação de relatórios é composta dos seguintes elementos:

• DataSource, que corresponde à conexão com a fonte de dados do relatório. É através do datasource que podemos acessar os diversos repositórios de dados seja ele um banco de dados SQL, documentos XML, elementos de BI do SQL via Analisys Services, Oracle ou quaisquer outras fontes compatíveis com ODBC e OLE DB. Podemos ter vários objetos datasources em nosso projeto, um para cada relatório, ou um único compartilhado por todos os relatórios.
• Reports são efetivamente os elementos que iremos trabalhar. Ao contrário dos relatórios “Local Mode”, durante sua implementação é necessário criar os conjuntos de dados (DataSets) que serão utilizados, que aqui faz parte da solução (por isso, para cada arquivo .rdl dos relatórios temos um correspondente .data). Dessa forma, a interface de desenvolvimento de relatórios nessa modalidade oferece alguns recursos de criação dos dataset, uma tab para formatação do Layout do relatório e finalmente uma opção de Preview para visualizarmos o relatório ainda no ambiente de desenvolvimento. A figura 3.6 abaixo apresenta nosso ambiente de desenvolvimento destacando seus principais elementos.

O processo de criação, para qualquer relatório segue basicamente os seguintes passos:

Aqui criaremos os objetos de conexão ao repositório de dados. Em nossos exemplos usaremos um único datasource compartilhado.

Aqui, configuraremos o destino dos relatórios e dos datasources. Especificando dentro do diretório virtual do report Server, a pasta na qual nossos relatórios serão hospedados – propriedade  TargetReportFolder.

 

Nesse modelo de relatórios, o conjunto de registros são criados dentro da própria estrutura dos relatórios, não sendo necessário criar objetos DataSets (estruturas de dados utilizados nos “local modes”). Através da Tab Data (vide,”Elementos de uma Aplicação de Relatórios, figura 3.6) criamos nosso conjunto de registros especificando suas propriedades, com destaque para o tipo do comando (texto ou stored procedure), o data source utilizado, a instrução SQL ou nome da procedure.

Não menos funcional, são as especificações de parâmetros e ocasionalmente filtros. A figura abaixo ilustra  a criação dos datasets de um relatório:

Os recursos de formatação do layout dos relatórios “Remote Mode”, são exatamente iguais aos que dispomos no “Local Mode”. Os elementos da ToolBox estão todos à nossa disposição, bem como as opções de formatação, formatação condicional, os tipos de relatórios tabular, chart e relacional, estão todos aqui.

Uma grande funcionalidade aqui presente são os wizards disponíveis, não só para formatação, como para todo processo de criação do relatório. O wizard é chamado quando da criação de um novo relatório. As imagens a seguir demonstram algumas das principais funcionalidades do Report Wizard.

Os relatórios possuem um mecanismo de parametrização, onde é possível passar informações a partir do cliente para o relatório em tempo de execução. A figura 2.12 ilustra a janela Report Parameters para criação dos parâmetros de um relatório, onde, para acessar, basta clicar com o botão direito fora das sessões do relatório.

Os parâmetros nessa modalidade de relatórios têm uma funcionalidade a mais, que nos relatórios “local mode”, que é a capacidade de especificar os valores possíveis para os parâmetros multivalorados e seus respectivos “Default Values” a partir de DataSets como mostrado na figura abaixo.

É isso, pessoal! No próximo artigo veremos como consumir os relatórios em nossos aplicativos, além de apresentarmos outros exemplos de relatórios com funcionalidades incríveis.

Até lá!