Entendendo o BIRT Viewer
- Visualizando o relatório em múltiplos formatos
No capítulo anterior, quando realizamos o "Preview" do relatório, o vimos em sua forma básica, em formato HTML. Mas o cliente espera poder imprimir esta consulta com alta qualidade e precisão, motivo pelo qual o projetista escolheu defini-la com o padrão "Consultar/Imprimir Objetos" (estereótipo "plcRelatorio").
Felizmente, o Eclipse BIRT pode renderizar um mesmo relatório em diversos formatos de saída, sendo um deles PDF, apropriado para este fim. Vamos conhecê-los através ainda do ambiente de
desenvolvimento e depois aprender a disponibilizar estes relatórios em tempo de execução. 1. De posse ainda do Banco de Dados "BancoLocal", definido em Apache Derby, ativo no projeto
"rhtutorial", edite o relatório "FuncionarioAuditoria.rptdesign", desenvolvido no capítulo anterior, e acione a aba "Preview".
2. Informe argumentos apropriados se a janela de parâmetros do relatório se abrir (será pedido uma primeira vez – nas subsequentes, os dados informados ficarão em caching).
3. Agora acione a opção "Run -> View Report -> As DOC" (salte a primeira opção por enquanto - voltaremos a ela mais tarde). Clique em Open (ou Abre) no diálogo que se segue.
Figura F20.1. Relatório em HTML ao fundo, com opção para ver em DOC em destaque.
4. O relatório deve ser exibido em formato "Open Document" acessível pelas principais suítes de edição de texto do mercado.
20
A6
Utilizando o jCompany
BIRT Viewer
Figura F20.2. Relatório em formato DOC para edições de texto complementares.
Importante: Note que alguns problemas de formatação ocorrem no título para o formato DOC.
Isto porque o relatório não foi ajustado para este formato - muito embora o BIRT tente fazer o melhor, os diversos formatos usam tecnologias bem distintas e, portanto, requerem ajustes. Para gerações em PPT, especificamente, o resultado com alguns problemas costuma ser aceitável, pois usuários normalmente realizam edição posterior do resultado (em PowerPoint, por exemplo). Os ganhos já compensam - pense no que já adianta ao usuário trazer dados de quaisquer de seus relatórios imediatamente para suas apresentações!
5. Clique agora em "As PPT" e clique novamente em Open (ou Abrir). Uma nova versão em PPT é renderizada.
Figura F20.3. Relatório em formato PPT para apresentações.
6. Clique agora em "As PDF" e clique novamente em Open (ou Abrir). Uma nova versão em PDF é renderizada.
Figura F20.4. Relatório em formato PDF, para visualização e impressão de alta qualidade.
7. Clique agora em "As XLS" e clique novamente em Open (ou Abrir). Uma nova versão para uso em planilhas é renderizada.
Figura F20.5. Relatório em formato XLS, para planilhas.
- Utilizando o BIRT Viewer em tempo de desenvolvimento
1. Clique agora na primeira opção, que deixamos por último propositalmente. O diálogo de parâmetros do relatório se abrirá. Informe os argumentos e confira que o relatório é exibido em HTML, porém agora com diversos recursos à disposição do usuário.
Estes recursos são providos por uma aplicação chamada Viewer, muito parecida com a que nós utilizaremos preferencialmente em tempo de execução para prover facilidades diversas aos usuários.
Figura F20.6. BIRT Viewer em tempo de desenvolvimento. #1. O título do relatório aparece no topo.
#2. A barra de opções para o usuário traz diversas operações que trazem alta flexibilidade. A primeira é o "Table of Contents", que exibe uma estrutura hierárquica de assuntos para o relatório, definida pelo Desenvolvedor. Não desenvolvemos no relatório corrente, mas iremos utilizar para o próximo, que contém uma estrutura mais interessante com grupos em vários níveis.
#3. A segunda chama o diálogo de parâmetros para mudança de valores.
#4. A terceira, "Export Data", traz opções de exportação dos dados do relatório somente, sem incluir seu formato. É a opção acionada na figura.
#5. A quarta opção abre um diálogo para permitir ao usuário exportar o relatório para todos os formatos que vimos, com opções que conheceremos a seguir.
#6. A quinta opção gera um arquivo PDF para impressão na máquina do usuário (Cliente). #7. A sexta e última opção envia o relatório para impressão no servidor, via Postscript. #8. A apresentação do BIRT Viewer é paginada, facilitando a consulta mesmo de grandes
relatórios.
#9. Uma barra de navegação está disponível, inclusive para saltos diretos para alguma página específica.
#10. O relatório em si é apresentando no formato HTML.
#11. No diálogo de exportação de dados, note que os valores de colunas aparecem com nomes significativos para o usuário graças às nossas boas práticas em defini-los, no diálogo "Output
Column"*. Clique nas setas duplas (">>") para enviar todos os campos para exportação.
* Perceba que ainda restou "decorar" um "ELEMENT_203", propositalmente, como exemplo do resultado exibido sem informarmos
nomes mais significativos. Para alterá-lo, vá ao Outline e clique direito no único objeto "Table" abaixo de Body, dando o nome "Funcionários". A lista do exportador exibe uma relação de Tables existente no relatório.
#12. Se deixarmos o formato default UTF-8, pode ser que tenhamos problemas com acento para edição. Por este motivo, pode ser que o usuário tenha que informar o formato alternativo "ISO-8859-1" (Latin 1), como mostra a figura. Apesar de desajeitado na primeira vez, o BIRT Viewer mantém esta informação em caching para as subsequentes.
#13. Veja as diversas operações de separadores existentes. Pode-se variar conforme o interesse. Clique em "Ok" e em seguida em Open (ou Abrir) para consultar os dados exportados. 2. Clique agora em "Export Report". Veja que as opções que utilizamos anteriormente estão aqui
disponíveis para que o usuário em tempo de execução possa acioná-las!
Figura F20.7. Exportação de relatórios para vários formatos, para usuários finais.
3. Clique nas demais opções para entender o recurso de impressão. Se estiver com o Application Server local (como é o caso em desenvolvimento), não haverá diferença entre os dois tipos de impressão, mas para impressões corporativas, muitas vezes em formulários especiais, a última opção é bastante apropriada.
- Liberando relatórios para Web
Após conhecermos uma pequena amostra das enormes possibilidades oferecidas pelo BIRT na área conhecida como "Reporting", estaremos mais sensíveis à problemática de liberação para este tipo de transação. Existem pelo menos três problemas clássicos que precisamos considerar quando concebemos uma arquitetura para disponibilizar relatórios para usuários finais:
o Arquitetura de embalagem de bibliotecas de Runtime
Para prover alta flexibilidade para usuários (como a que obtivemos usando o Eclipse BIRT Viewer), a quantidade de bibliotecas JAR que teríamos que embalar em nossa aplicação triplicaria o
tamanho dos arquivos "executáveis" EAR ou WAR. O aumento de tamanho implicaria em
rotinas de construção (build) mais lentas, bem como liberação (deploy) e ainda distribuição (para download, por exemplo). Além disso, haveria maior consumo de memória neste caso com relação a outras alternativas que veremos.
Portanto, embalar as bibliotecas de runtime do BIRT dentro de nossos projetos não seria
uma opção ideal.
Uma outra alternativa seria disponibilizar estas bibliotecas em diretórios de "escopo global" dos Application Servers (como o diretório "common/lib" do Tomcat). É como fazemos, por exemplo, com bibliotecas JAR que contêm classes Drivers de JDBC, utilizada pelos pools de conexão JDBC mantidos pelos Application Server. Porém, ao contrário dos Drivers JDBC*, não haveria como convivermos com duas versões de BIRT simultaneamente.
* No caso dos Drivers JDBC, pode-se variar o nome da classe em alguns casos para utilizar duas grandes versões de um mesmo Driver,
simultaneamente. Mas, na prática, também ocorrem limitações em versões menores - o que ameniza é o fato de que este é um recurso mais simples e estável quando comparado, por exemplo, a bibliotecas de runtime de um motor de relatórios extenso como o BIRT.
Como uma mesma instância de Application Server pode conviver com dezenas de aplicações
jCompany* - e como a evolução do Eclipse BIRT em si ainda é intensa e o mercado altamente rico
e competitivo, a probabilidade de que venhamos a precisar de uma convivência entre diferentes versões é alta.
Felizmente, o Eclipse BIRT provê as funções que vimos no Viewer como uma aplicação
independente, que pode ser compartilhada para executar relatórios presentes em diversas outras aplicações. Pode-se, inclusive, ter mais de uma versão desta aplicação em
produção para permitir o reúso por diferentes versões de projetos.
O jCompany FS Framework traz uma versão aprimorada deste aplicativo chamada jCompany
BIRT Viewer, inclusive com traduções dos rótulos e mensagens para português†, que é
homologada para disponibilizar relatórios em duas modalidades diferentes, como veremos mais adiante.
o Flexibilidade para liberação de relatórios AD-HOC
No mundo real, relatórios estão entre os requisitos que mais se alteram. Na medida em que usuários exploram novas aplicações, demandas por extrações de dados diferentes das
originalmente requisitadas, ou mais sofisticadas, passam a entupir listas de demandas (backlogs) das áreas de desenvolvimento.
O Eclipse BIRT já contribui para diminuir em boa parte este gargalo, quando permite aos usuários exportarem dados para Excel ou outros aplicativos de manipulação - mas ainda restarão casos mais complexos, onde a demanda por manutenção será inevitável - ou não?
É possível minimizarmos este desperdício liberando, de forma embalada nas aplicações,
somente um mínimo essencial (talvez exigido legalmente) de relatórios. A partir da
implantação da aplicação, em um esquema mais ágil, desenvolver e liberar novos relatórios "sob demanda", na medida em que sejam efetivamente requisitados, é uma postura que tende a produzir uma funcionalidade "enxuta", evitando o trabalho em relatórios que nunca serão realmente utilizados.
Note que, para se obter esta vantagem, é importante que os relatórios possam ser
embalados de forma independente das aplicações! Se precisarmos reconstruir e liberar toda a
aplicação novamente, um sério problema de controle de versão terá que ser enfrentado. Note que estamos falando de liberar um ou dois novos relatórios por dia, algo plenamente possível com a produtividade que o Eclipse BIRT oferece.
Também para este caso, a arquitetura proposta pelo jCompany para liberação de relatórios é adequada, como veremos mais adiante.
o Distribuição de processamento de relatórios para evitar gargalos de performance
Um outro problema sério no mundo real são os níveis de consumo de recursos de memória e
processador que determinados relatórios costumam exigir - aliás, muito comumente‡!
É preciso entender que a memória e o processador da máquina utilizada para hospedar o Application Server são recursos compartilhados por várias "Threads" (usuários ativos) e que, portanto, não há mágica aqui: um único relatório que irá processar 2.000 páginas e
renderizar um PDF ao final, por exemplo, pode ser suficiente para consumir 90% de recursos de um servidor durante uma hora, digamos§. Durante este período, este único
relatório tornará um sofrimento o trabalho de outros 200 usuários que, fora isso, estariam utilizando suas transações OLTP com ótima performance.
* Estamos nos referindo ao jCompany porque, com a arquitetura que o framework provê, há uma considerável otimização default de
memória. Conhecemos casos reais com quase 20 aplicações corporativas em produção, em uma única instância de Tomcat, com 2GB RAM e acessos de nível mediano a este grupo (500 usuários ao todo). É possível, no entanto, em uma arquitetura artesanal, mesmo com baixo acesso, consumir-se recursos de memória e processador que não permitam esta extrapolação.
† O arquivo com traduções foi cedido como contribuição para a comunidade Eclipse BIRT, mas ainda não havia sido incorporada no
momento desta escrita.
‡ Já testemunhamos três ou quatro casos reais de problemas críticos de quedas de Application Server em produção, originados por
relatórios que, eventualmente, realizavam consultas sem os filtros devidos (às 16:00 horas da tarde!) fazendo uma varredura (Full Scan) que ocupava mais de 1GB de RAM da memória - suficiente para derrubar todos os demais usuários.
Portanto, haverá que se tomar uma decisão a este respeito, evitando que determinados relatórios sejam disparados em determinados horários "de pico", ou utilizando-se uma solução de servidor de relatórios como o eCompany Reports*.
Uma solução provisória para quem não pode contar com uma solução dedicada para esta área é liberar relatórios pesados em uma instância diferente de Application Server, deste modo deixando relatórios concorrerem com outros relatórios somente†.
Cientes da problemática, vamos compreender agora as quatro opções de embalagem de relatórios BIRT disponíveis na arquitetura proposta pelo jCompany:
1. Relatórios embalados com a aplicação, mas servidos via jCompany BIRT Viewer
Esta é uma opção recomendada para relatórios estáveis, que tendem a não ser alterados - e também que não sejam em demasiado pesados, já que irão executar no mesmo servidor da aplicação. É possível realizar programações para impedir disparos em horários de picos, se for necessário.
Iremos utilizar esta opção ainda neste capítulo para nosso primeiro relatório.
2. Relatórios disponibilizados fora da aplicação, possivelmente embalados dentro do
jCompany BIRT Viewer
Esta é a opção recomendada para relatórios desenvolvidos "sob demanda" (AD-HOC), ou cuja natureza e complexidade sugiram a possível demanda por ajustes constantes. Outro motivo é a possível separação destes relatórios para outro servidor (fora do cluster principal que executa a aplicação) para evitar os problemas de concorrência.
Também iremos explorar esta solução neste capítulo.
3. Relatórios embalados com a aplicação e servidos diretamente (sem passarem pelo
jCompany BIRT Viewer)
Esta opção cairia nos problemas de embalagem que discutimos anteriormente. Apesar de possível, não a discutiremos neste livro.
4. Relatórios utilizados via eCompany Reports
Esta é nossa sugestão ideal para ambientes robustos, com centenas ou milhares de relatórios e usuários. Porém, também foge ao nosso escopo neste livro.
- Disponibilizando o jCompany BIRT Viewer para ambiente de teste
Para quaisquer das duas modalidades que iremos utilizar de liberação de relatórios, precisaremos do aplicativo jCompany BIRT Viewer funcionando como uma aplicação no Tomcat. Vamos disponibilizá-lo, seguindo os passos:
1. Copie o projeto "jcompany_birtviewer", que se encontra abaixo de
"[jcompany]\meus_projetos", para o diretório "webapps" do Tomcat, em "[jcompany]\servers\tomcat".
2. Troque seu nome para "plcVis" (apenas para não usar referências muito grandes em URLs, em tempo de produção). O resultado deve ser como o da Figura F20.8.
* O eCompany Reports é um produto comercializado em modalidade Open Source gerenciada pela Powerlogic, integrante da suíte
Powerlogic jALM, que oferece um "Portal de Relatórios" com capacidade para coletar parâmetros de usuários e executar relatórios de forma escalonada (à noite ou periodicamente, em determinadas "janelas de tempo"). Deste modo, permite que se faça uma gestão deste problema, com flexibilidade, em tempo de execução.
† Em empresas que utilizam Application Servers comerciais tais como Websphere, Oracle ou Weblogic, não há necessidade de
licenciamento para esta outra máquina - como irão basicamente utilizar JDBC em pools de conexão contra um SGBD-R, os serviços de relatório não exigem APIs Java EE que justifiquem um novo licenciamento somente para este fim.
Figura F20.8. jCompany BIRT Viewer disponível no Tomcat. #1. Diretório do Tomcat abaixo da instalação do jCompany.
#2. Projeto "jcompany_birtviewer" copiado e renomeado para "plcVis".
#3. Bibliotecas reutilizadas pelo BIRT Viewer. Repare que a o Viewer tem mais de 60MB no total, mas liberado desta forma é reutilizado por várias aplicações.
3. Agora crie um novo arquivo de contexto para o "plcVis". Procure no diretório
"/tomcat/conf/Catalina/localhost" pelo arquivo de contexto "rhtutorial.xml" e crie outro copiando-o para o nome "plcVis.xml".
4. Troque as referências de nome "rhtutorial" para "plcVis", conforme o Código F20.1.
<?xml version='1.0' encoding='UTF-8'?> <Context displayName="plcVis" docBase="plcVis" path="plcVis"
privileged="true" swallowOutput="off">
<Resource name="jdbc/rhtutorial" type="javax.sql.DataSource" driverClassName="org.apache.derby.jdbc.ClientDriver"
url="jdbc:derby://localhost:1527/bancolocal;create=true" username="APP" password="APP" maxActive="50" maxWait="-1" maxIdle="10" removeAbandoned="true" logAbandoned="true" /> </Context>
Código F20.1. Arquivos de contexto para aplicativo "plcVis".
Importante: Perceba que mantivemos a declaração do pool de conexões (Resource
“javax.sql.DataSource”) dentro do contexto do visualizador de relatório "plcVis" porque este aplicativo roda relatórios de forma isolada, externamente à aplicação, como citamos. Sendo assim, precisamos de um pool no contexto deste utilitário. O endereço JNDI que declaramos como "java:comp/env/jdbc/rhtutorial" no relatório deve ter o sufixo coincidente com recurso declarado aqui para que o jCompany BIRT Viewer utilize o pool e rode o relatório corretamente, de forma otimizada*.
* Desta forma, ficamos com dois pools de conexão para um mesmo SGBD, um para a aplicação e outro para relatórios. Em produção,
seria necessário alterar parâmetros "maxActive", "maxIdle" etc. para ajustar o tamanho de recursos que serão usados no pool, para cada caso.
Outra opção seria definir um pool de conexões "rhtutorial" global, reutilizado por ambas as aplicações. Este tipo de recurso pode ser definido, no caso do Tomcat, no arquivo "conf/context.xml".
5. Pare o Tomcat se ele estiver rodando e reinicie-o novamente para testarmos a instalação. Chame
http://localhost:8080/plcVis para o teste*. A página exibida na Figura F20.9 deve aparecer para
indicar que a instalação do jCompany BIRT Viewer está correta.
Figura F20.9. Página principal do BIRT Viewer indicando o correto funcionamento.
Obs.: Esta página não será exibida para usuário durante a execução de relatórios, serve apenas
para conferência da instalação e de versões.
6. Acessar o diretório "\servers\tomcat\webapps\plcvis\plc", copiar a pasta rel para a raiz da aplicação dentro do tomcat, ficando assim: "\servers\tomcat\webapps\plcvis\rel". Esta configuração é necessária por motivos de segurança que serão explicados mais adiante nesta documentação.
7. Clique em "View Example" para agora testar a execução de um relatório. Este novo teste garante que tudo está em ordem também nas bibliotecas de Runtime.
Importante: Uma janela requerendo autenticação deverá ser exibida, o que indica que estamos na
versão customizada do jCompany! Note que ela não traz a pele que criamos e isto nem será necessário - esta janela não será exibida quando chamamos os relatórios da aplicação, porque trabalharemos com uma configuração de “single signon” do Tomcat (qualquer outro Application Server de mercado também irá oferecer esta opção).
8. Após a autenticação, confira com a figura abaixo.
Figura F20.10. Relatório de teste executado corretamente.
#1. Perceba que, tal como o jCompany, o Eclipse BIRT também utiliza URLs RESTful. Isso significa que qualquer execução de relatório pode ser disparada com hiperlinks, inclusive com passagem de parâmetros, com as vantagens de uso de "Favoritos", "História do Usuário", "Envio por e-mail" etc.
#2. O jCompany BIRT Viewer traz agora os rótulos traduzidos.
Importante: Para personalizar a aparência, deve-se editar diretamente o projeto
"jcompany_birtviewer". Mas para este caso ainda não há framework - portanto, mantenha suas modificações em separado do projeto para reaplicá-las no recebimento de uma nova versão.
#3. Mensagem de confirmação do BIRT quanto à correta instalação.
#4. O parâmetro passado na URL é aqui exibido, indicando que foi recebido e renderizado apropriadamente.
9. Agora edite a URL, retirando a parte que passa o argumento "&sample=my+parameter". Confira com a Figura F20.11.
Figura F20.11. Relatório exibindo diálogo de argumentos traduzido. #1. Uma das opções de execução do visualizador é "frameset".
#2. O parâmetro de URL "__report" (assim mesmo, com dois sublinhados) permite que se passe a localização de um arquivo de relatório com sufixo ".rptdesign"*.
#3. No caso, o arquivo "test.rptdesign" está na raiz do projeto "plcVis", por isto pode ser chamado somente a partir do nome, sem qualificação de diretórios.
#4. Quando omitimos o parâmetro "sample" da URL, podemos inserir um novo parâmentro atráves do botão "Executar Relatório" encontrado na parte superior esquerda da tela.
- Liberando relatórios embutidos na aplicação
Com o jCompany BIRT Viewer disponível, vamos realizar uma liberação de nosso relatório para testá-lo em 3 camadas no ambiente do Application Server, seguindo a primeira modalidade de liberação que citamos anteriormente - com o relatório embalado com a aplicação.
1. Primeiramente, precisamos criar um item de menu que permita chamar o relatório. Edite o arquivo "geralMenu.xhtml" e inclua a chamada indicada na Figura F20.12.
Figura F20.12. Chamada de relatório via menu.
#1. A opção deve ser colocada no atributo "app.m.inicial", somente visível para usuários com papel "Administrador"†.
#2. Crie a chamada com "menu.funcionario.auditoria.titulo" e informe "Auditoria" como rótulo no arquivo "ApplicationResources.properties".
#3. Note que esta chamada é diferente das demais que fizemos até agora, pois irá chamar uma transação de outra aplicação (porém no mesmo Application Server), o BIRT Viewer. Para isso, o endereço de chamada relativo deve estar como indicado, com três blocos de retorno “../”. Isso porque temos que retornar para “webapp” de “webapp/rhtutorial/f/n”.
#4. Nesta passagem de parâmetro, o arquivo de relatório é passado em esquema inverso: como endereço "de retorno" (Callback) para que o BIRT Viewer localize o arquivo que está dentro do "rhtutorial". Neste caso, um único retorno é suficiente.
Note que com esta técnica nós "terceirizamos" execuções de relatório para o BIRT Viewer, enquanto preservamos os arquivos de relatórios em si, encapsulados na aplicação.
* Este arquivo é o único necessário em tempo de execução. Um outro arquivo com sufixo ".rptconfig" existirá em tempo de
desenvolvimento, mas não precisa ser disponibilizado para execução.
2. Realize uma "Liberação Rápida com Reinício" e teste a execução do relatório, clicando no item de menu.
- Segurança para relatórios embalados na aplicação
Note que, apesar de o bloco com a chamada de menu aparecer somente para usuários com papel "Administrador", nada impede que outros informem a URL diretamente, burlando a especificação da segurança.
Há duas formas de se tratar desta questão quando liberamos um relatório dentro da própria aplicação: o Definindo segurança via "web.xml"
Neste caso, deve-se criar uma nova "Security Constraint" permitindo "GET" somente para role "Administrador" para a URL "/rel/funcionarioAuditoria.rptdesign".
Nós já discutimos esta forma em tutoriais passados, portanto não iremos repeti-lo aqui. Fica para o leitor o desafio de configurar a segurança neste padrão.
o Utilizando segurança segundo convenção de pastas
Especificamente para o caso de relatório visualizados com jCompany BIRT Viewer, há uma alternativa adicional para definição de segurança.
Nesta convenção, somente relatórios liberados abaixo do pacote "[aplicação]/rel" ficam acessíveis por qualquer usuário*. Relatórios liberados em qualquer outro diretório (exceto em
subdiretórios de "/rel") estarão protegidos para acesso – somente podendo ser acessados por usuários que possuírem uma role especial, que pode ser formada pela sigla da aplicação (nome do WAR) e nome do arquivo ou nome do primeiro diretório.
Vejamos alguns exemplos:
o Relatórios públicos abaixo de “[aplicação]/rel”: “rhtutorial/rel/funcionarioAuditoria.rptdesign” ou
“rhtutorial/rel/funcionario/funcionarioAuditoria.rptdesign”.
o Relatório somente para quem possui a role “RHTUTORIAL_PLANOPROJETO”: “rhtutorial/projeto/planoProjeto.rptdesign” ou
“rhtutorial/planoProjeto/plano.rptdesign”.
Note que, no primeiro caso, a role coincide com o nome do arquivo. Já no segundo, com o nome do primeiro diretório abaixo do escopo da aplicação. Deste modo, pode-se registrar segurança especial para um arquivo ou definir para grupos de arquivos.
Importante: Note que estamos pensando do ponto de vista do projeto em seu formato de execução (WAR ou EAR). Para que um diretório “/rel” seja apresentado logo abaixo de
“rhtutorial” no WAR file, por exemplo, nós tivemos que incluí-lo abaixo de “src/main/webapp”, em tempo de desenvolvimento, segundo o padrão Maven.
1. Mude o relatório do atual diretório “/rel” para outro, digamos,
“/administrador/funcionarioAuditoria.rptdesign”, e crie uma nova role
“RHTUTORIAL_ADMINISTRADOR” no arquivo “[tomcat]/conf/tomcat-users.xml”, atribuindo-a somente para usuários do grupo “Administrador”†.
2. Reinicie o Tomcat para que pegue a nova política de controle de acesso. Agora tente se autenticar com um usuário que não seja um Administrador. O menu para acesso à auditoria não irá aparecer, mas tente informar a URL de acesso ao relatório diretamente. Uma mensagem de restrição ao acesso deverá aparecer.
* Note que, para utilizarmos a segurança com o primeiro padrão, precisamos necessariamente incluir o relatório abaixo do diretório
"/rel", na raiz do projeto. Se incluirmos em outra pasta, a segurança por convenção de diretórios atuará primeiro.
† Em nosso caso mais simples, para atender à especificação, teríamos que nos lembrar de incluir todos os usuários da role
“Administrador”, também na role “RHTUTORIAL_ADMINISTRADOR”. Mas note que, em um sistema de controle de acesso mais sofisticado como provido pelo jCompany Security, teríamos o conceito de “grupos”, além do de “roles” (papéis) e “usuários” – o que nos permitiria criar um “grupo” Administrador contendo as duas roles, evitando esquecimentos básicos por parte de responsável pelo cadastro da segurança.
- Liberando relatórios de forma independente da aplicação
Vamos agora avaliar a segunda arquitetura de embalagem de relatórios que iremos discutir neste livro, possibilitando que estes sejam liberados e executados de forma independente, mais rapidamente e com menor risco*.
1. Vá diretamente para o diretório "webapps" do Tomcat e abra o diretório “/administrador” ou "/rel" (se não tiver feito a alteração do tópico anterior) na aplicação "rhtutorial".
2. Faça uma cópia do arquivo de relatório (somente o arquivo "funcionarioAuditoria.rptdesign" é suficiente) deste diretório para o diretório "rel", abaixo da aplicação "plcVis". Confira com aFigura F20.13.
Figura F20.13. Cópia do relatório para a aplicação "plcVis". 3. Agora chame este relatório utilizando a URL
http://localhost:8080/plcVis/frameset?__report=rel/funcionarioAuditoria.rptdesign.
Repare que a página de autenticação é exibida e, a partir daí, a execução ocorre normalmente - já
que o relatório não depende de nenhum recurso interno a aplicação†. Esta é uma
excepcional vantagem, pois nos permitirá estabelecer uma estratégia de BI (Business Inteligence) com o Eclipse BIRT - que pode gerenciar relatórios, cubos, gráficos, etc., de forma separada da aplicação.
4. Mova agora o relatório para um novo diretório “/administrador”, a ser criado abaixo da raiz de “plcVis”. Tente, em seguida, chamá-lo com
http://localhost:8080/plcVis/frameset?__report=administrador/funcionarioAuditoria.rptdesign.
Uma mensagem de restrição ao acesso será exibida, mesmo que estejamos com o usuário que possua a role “RHTUTORIAL_ADMINISTRADOR”. Isso porque não estamos mais com o relatório embalado dentro da aplicação. No caso de liberações isoladas no BIRT Viewer, deve-se dispensar o prefixo da aplicação utilizando-se apenas “ADMINISTRADOR”, neste caso (nome de um arquivo ou do primeiro diretório que contenha arquivos de relatórios, mas sem o prefixo com nome da aplicação!).
* Quando relatórios AD-HOC (desenvolvimento e liberados em taxa diária) são liberados juntamente com uma aplicação (WAR ou EAR),
a preocupação com o controle de versão se torna imensa (será que todos os artefatos são exatamente os mesmos atualmente liberados?). Além disso, o tempo de liberação é maior e, por melhor que seja o recursos de "Hot-Deploy" dos Application Servers, haverá sempre uma ligeira "congelada" e até eventual perda de alguma transação por parte de usuários, no momento da liberação. Quando liberados de forma isolada, este risco é consideravelmente mitigado.
† Tanto o jCompany quando o BIRT Viewer possuem recursos para se utilizar classes mapeadas com Hibernate/JPA como Data Source.
Este caminho, no entanto, traz poucas vantagens que não compensam a grande perda de produtividade e o acoplamento que esta estratégia cria, do relatório com a aplicação. Como o modelo relacional é extremamente eficiente para a produção de relatórios - e não haverá codificação em 99% dos casos -, o uso de OO aqui é desnecessário.
5. Altere a role “RHTUTORIAL_ADMINISTRADOR” em “tomcat-users.xml” para somente “ADMINISTRADOR” e reinicie o Tomcat. Agora tente novamente o acesso com um usuário administrador. Ele deverá ser liberado.
- Criando menus dinâmicos para relatórios independentes
Mesmo quando for desejado utilizar a arquitetura de relatórios independentes, os hiperlinks de disparo através de menus da aplicação ainda devem ser providos na aplicação, do contrário os usuários terminarão por não encontrar e usar muitos dos relatórios disponíveis.
Deve-se ter este cuidado especialmente na ausência de uma aplicação de portal de relatórios
como o eCompany Reports, que ao menos oferece uma Interface com o Usuário alternativa (tipo
pastas de arquivos) para que estes acessem seus relatórios de forma independente.
A princípio, este é um problema simples: basta alterar a URL de chamada de menu no arquivo "geralMenu.xhtml", que criamos para a versão embutida, para:
../../../plcVis/frameset?__report=administrador/funcionarioAuditoria.rptdesign Note que nesta nova URL, o “__report”, aponta para um recurso interno ao “plcVis”.
Porém, esta não seria uma alternativa viável pois exigiria liberação da aplicação a cada novo relatório “independente”: se pretendemos usar relatórios independentes é exatamente para evitar estas
liberações de nossa aplicação principal!
Como produzir, então, menus dinâmicos que nos permitam criar hiperlinks para relatórios (e outros recursos, inclusive), sem a necessidade de liberação da aplicação?
Já fizemos uma programação de menus dinâmicos em Facelets neste livro, mas o jCompany FS
Framework provê uma solução completa e imediatamente produtiva para este fim, trazendo:
o Uma classe pré-mapeada que permite o armazenamento em banco de dados de itens de menu dinâmicos e os respectivos hiperlinks de chamada;
o Uma Colaboração completa que pode ser reutilizada para que usuários com papel "Administrador" somente possam criar estes itens;
o E um componente Tiles de menu que renderiza o menu dinâmico para usuários em geral, oferecendo ainda "conforto visual" associado à segurança de convenção por nome de diretório - ou seja, somente exibindo chamadas de relatórios dinâmicas para usuários com os papéis que permitem o acesso.
Vamos definir o nosso primeiro menu dinâmico reutilizando este framework:
1. Inclua a classe pré-mapeada "PlcDynamicMenuEntity" no arquivo "persistence.xml".
Figura F20.14. Classe que persiste itens dinâmicos de menu.
2. Inclua uma tag para o menu genérico "geralMenuDinamico.xhtml" no arquivo
Figura F20.15. Reúso de bloco de menu com opções para menu dinâmico.
3. Inclua o classe "PlcDynamicMenuEntity" como "classesLookup" no arquivo
"package-info.java" de configuração do rhtutorial encontrado no projeto principal.
Figura F20.16. Definição da classe de itens dinâmicos como "classesLookup".
4. Faça uma "Liberação Rápida para Tomcat com Reinício" e, após autenticar, utilize o menu Área Técnica para atualizar o esquema do Banco de Dados.
Figura F20.17. Esquema de criação de nova tabela para persistência de menu dinâmico.
Note que a tabela criada permite, basicamente, a persistência de rótulos e hiperlinks. O framework irá inspecionar a estrutura de hiperlinks para aplicar a segurança por convenção de diretórios. 5. Se você está autenticado com usuário com papel "Administrador", o menu "Dinâmico" aparecerá
contendo a opção "Manutenção do Menu". Chame-a para definirmos os itens de menu dinâmicos. 6. Preencha um item dinâmico para chamada do relatório externo, conforme a Figura F20.18.
Figura F20.18. Itens de menu para chamadas de relatórios e outros, criados dinamicamente. #1. Menu dinâmico.
#2. Item de menu que permite a criação de demais itens dinamicamente - somente é exibido para usuários com role “Administrador”.
#3. Os itens criados também são exibidos neste mesmo menu, utilizando os mesmos critérios de segurança “baseado em diretórios” para relatórios.
#4. Note que a URL quando informada em menus dinâmicos deve retroceder um nível a mais, pois esta transação fica definida no framework em URL no padrão “/f/t/plc”, ou seja, um nível abaixo das transações da aplicação. Assim, serão necessários quatro “../”.
7. Clique para testar o item de menu “Auditoria”. O relatório deve ser acionado.
Importante: Note que, com a liberdade para se criar itens com hiperlink para o mundo externo da
aplicação e uma arquitetura RESTful plena oferecida com o jCompany, é possível se disponibilizar "atalhos corporativos" para quaisquer consultas, seleções e edições de documentos da corporação, não somente relatórios!
- Produzindo páginas específicas de argumento
Como apresentamos, o BIRT Viewer oferece um diálogo que coleta argumentos de usuários - desta forma permitindo o funcionamento inteiramente isolado de outras implementações.
Este é um diálogo muito poderoso que, além de ser exibido em português, com rótulos e ajuda em balões para cada parâmetro de entrada, ainda traz:
o Facilidades avançadas de formatação tais como "Radio Button", "Combo Box", "List Box", inclusive com opção de recuperação de listas de valores dinamicamente (equivalente ao "comboDinamico" do jCompany) ou de informá-la de forma estática ("comboEstatico"). o Encadeamento de listas (Ex.: Selecionou o estado "São Paulo" então traga listas de Municípios
deste estado para seleção na próxima lista).
o Programações diversas em Javascript e/ou em Java utilizando eventos do BIRT.
Por todas estas vantagens e simplicidade é altamente recomendável que se utilize o diálogo
padrão do BIRT para coleta de parâmetros de relatórios sempre que possível! Em algumas
situações, porém, pode se fazer necessário programar a coleta de argumentos de forma independente do relatório, passando para este os valores já informados pelo usuário.
O jCompany IDE irá apoiar este tipo de demanda com um assistente Cheat-Sheets para o padrão "Caso
de Uso Consultar/Imprimir Objetos (Relatório)". Vamos explicá-lo somente para efeito de didática -
não aplique esta solução em sua aplicação, se não quiser.
1. Via menu "Help -> Cheat-Sheets..." selecione "Caso de Uso Consultar/Imprimir Objetos
(Relatório)".
Figura F20.19. Criação de Colaboração para Relatórios.
#1. Selecione a Entidade Raiz da agregação que conterá os argumentos necessários para recuperação do relatório.
#2. URL Lógica (este Caso de Uso produzirá uma Colaboração que irá basicamente abrir uma página com argumentos do relatório).
#3. Informe "funcionario" para gerar os XHTMLs de argumento do relatório de auditoria abaixo do pacote "WEB-INF/fcls/funcionario".
#4. Selecione o arquivo do relatório em si.
3. No segundo diálogo do Assistente, informe somente Título "Auditoria de Man. de Funcionários" e siga para o terceiro passo.
4. No terceiro passo, selecione como argumentos a "dataUltAlteracao" e o "usuarioUltAlteracao", retirando o "id". Como o jCompany IDE não gera ainda intervalo de datas, iremos gerar somente um argumento de data e ajustar manualmente para um intervalo, editando o XHTML*.
* Havia um Product Backlog para esta implementação, no momento da escrita deste livro. Se encontrar uma opção de operador
Figura F20.20. Definição de argumentos para o relatório.
5. Encerre o Assistente de Criação e clique no próximo passo. Edite o XHTML para incluir o "intervalo de datas" e ajustar o nome das propriedades aos nomes dos argumentos do relatório, conforme
definidos no “Report Parameters”. Lembre-se de alterar os rótulos para ficarem coerentes.
Figura F20.21. Página XHTML de argumentos modificada para intervalo de datas.
#1. Altere o nome da propriedade para “dataUltAlteracao_ArgINI” (o mesmo do BIRT). #2. Explicite os tamanhos dos campos (já que, sem que exista uma propriedade com nome
correspondente na Entidade, eles não poderão ser herdados).
#3. Copie a célula de “data de início” para uma para a “data de fim” e altere sufixos para rótulos, id e ajuda.
#4. Altere o nome da data de fim para “dataUltAlteracao_ArgFIM” (também o mesmo do BIRT).
6. Edite o arquivo "geralMenu.xhtml" e altere a posição da chamada do último bloco para o inicial, com opções do "Administrador"*.
Figura F20.22. Chamada de menu reposicionada.
7. Siga para o próximo passo para editar artefatos da camada Controle. Edite o arquivo MB do caso de uso (ex:FuncionarioauditoriaMB.java) para realizar pequenos ajustes.
Figura F20.23. Classe de Controle alterada para informar o prefixo do relatório.
#1. Inclua um prefixo “rel” ou “administrador”, conforme o diretório onde se encontre o relatório, no “plcVis”.
#2. Altere o nome do argumento para o definido no relatório: "dataUltAlteracaoIniArg". #3. Crie um novo argumento para a data fim com nome “dataUltAlteracaoFimArg” e operador
MENOR_OU_IGUAL_QUE.
8. Exclua o pacote "com.empresa.rhtutorial.persistence.jpa.funcionarioauditoria" que está no projeto rhtutorial_model
9. Faça uma "Liberação Rápida para Tomcat com Reinicialização" e acione o novo item de menu. Informe os argumentos e clique em "Gerar Relatório". Veja que o relatório já será executado imediatamente sem o diálogo de parâmetros do BIRT, pois o jCompany já os compõe na URL, apropriadamente.
- Considerações para uso em Produção
Existem alguns cuidados a serem tomados quando disponibilizamos esta arquitetura para um ambiente de produção, especialmente com cluster*:
o Para liberar relatórios de forma independente - ou seja, dentro das pastas do BIRT Viewer,
este aplicativo precisará, naturalmente, ser liberado de forma expandida (como temos
usado) e não como um único arquivo "plcVis.war", como é recomendado em produção.
Este requisito pode ser problemático em certas marcas de Application Server comerciais. Para cada caso, deve-se adaptar a solução para alguma pasta de escopo global ou investigar de forma mais específica.
o Em ambientes em Cluster será preciso também um esquema de liberação capaz de replicar
um arquivo de relatório para todos os nós, simultaneamente. Pode ser que este esquema
conhecido como Farming esteja disponível para arquivos "WAR" e "EAR", mas não necessariamente para um arquivo individual de recurso, como o
"funcionarioAuditoria.rptdesign".
Mas existem alternativas para se solucionar esta liberação, desde a replicação manual (para poucos nós) até a automação desta replicação em nível da JVM ou mesmo do Sistema Operacional.
* Sempre pressupomos um ambiente de produção configurado com Cluster, ou seja, com dois ou mais servidores paralelos contendo
instâncias idênticas do Application Server e das aplicações, funcionando com solução de balanceamento de carga, login unificado e tolerância à falhas.
Sumário
Neste capítulo, conhecemos as diversas opções que o aplicativo de visualização de relatórios do Eclipse BIRT provê para usuários finais, desde a renderização em vários formatos (HTML, PDF, PPT, XLS etc.), até a exportação de dados e impressão no cliente ou servidor.
Conhecemos também as facilidades disponíveis no jCompany para liberação de relatórios em diversas arquiteturas distintas, em tempo de execução, seja de forma embutida na aplicação, seja de forma independente e flexível, mais condizente com uma estratégia de Business Intelligence.
No próximo capítulo iremos implementar um novo Caso de Uso através do Eclipse BIRT, que nos permitirá conhecer recursos tais como agrupamentos, quebras e gráficos.
