[FLEX] Melhores práticas para gerar relatórios

JasperReport com um servlet “cuspindo” application/pdf

FlexReport tem várias limitações
xViewer o projeto está instinto e tem diversos bugs

Se quiser abrir esse relatório na aplicação pode “cuspir” esse application/pdf para um iframe (tem um componente que criaram) no flex ou então abrir em uma nova janela mesmo…

Servlet é o mesmo que usado no Java para relatórios…

Hm entendi,

e no meu caso, estou usando o BlazeDS, consigo acessar esse servlet por ele? Vi algo sobre HTTPService nos pacotes do flex, mas fiquei meio perdido.

Que tal JasperServer. É uma mão na roda.

No seu sistema Java vai ter no seu web.xml configurado o servlet que vai ficar acessivel pelo www.endereco.com.br/nomeapp/servlet

Você acessa o servlet pelo navigateToURL, vai abrir em uma nova janela o relatório:

navigateToURL( new UrlRequest(“enderecodaservlet”), “_blank”);

Se quiser enviar algum parametro pode colocar um URLVariable no data do urlrequest.

Hmm saquei! Putz uma mao na roda, vou fazer isso o quanto antes.

Muito obrigado pela ajuda!!

Sim não tem segredo já queria ter escrito sobre isso em algum blog ou artigo mas até hoje não tomei vergonha na cara… preciso logo tirar tempo para escrever algumas coisas…

O jeito mais fácil é usar CrystalReports e gerar o PDF e converter o PDF em SWF ao usuário. O FlashPlayer não é tão rápido para ainda ocuparmos o bichinho fazendo cálculos, escrevendo PDF, etc.

Não vi ainda nenhum exemplo com CrystalReports caso queira demonstrar algum ficaremos gratos.

Porém não é o flashplayer quem fará os cálculos ou escreverá o PDF realmente ele não é capaz de fazer algo que ocupa grande processamente nesse momento que entra o Java e todo seu potencial pois os cálculos serão feitos com o Java (na verdade no jasperreport, na maioria dos casos).O Flex só tem o trabalho de chamar a servlet e exibir o relatório… ops nem exibir não preciso ser pelo flash player pois quando é aberta no _blank não ta rodando no flash player…

Enfim, concordo com sua opinião:

GRANDE PROCESSAMENTO = BACK-END

Entao pessoal,

gerar um pdf para o swf torna independente o browser de um plugin visualizador ( adobre reader, foxit), mas nao consome mais recursos? sendo assim uma uma escolha mutuamente exclusiva?

RafaelViana:

Não vi ainda nenhum exemplo com CrystalReports caso queira demonstrar algum ficaremos gratos.

Porém não é o flashplayer quem fará os cálculos ou escreverá o PDF realmente ele não é capaz de fazer algo que ocupa grande processamente nesse momento que entra o Java e todo seu potencial pois os cálculos serão feitos com o Java (na verdade no jasperreport, na maioria dos casos).O Flex só tem o trabalho de chamar a servlet e exibir o relatório… ops nem exibir não preciso ser pelo flash player pois quando é aberta no _blank não ta rodando no flash player…

Enfim, concordo com sua opinião:

GRANDE PROCESSAMENTO = BACK-END

Esse é um problema. Não é interessante, também, abrir com página web, por uma coisa simples - vai aparecer o endereço do relatório no navegador. Menos um ponto pra segurança.

Sim concordo. Menos um ponto para segurança.E menos um ponto também para usabilidade do usuário pois também não acho útil abrir em uma nova aba ter que fechar e voltar a usar o sistema.

Por exemplo no que você fala em gerar o SWF, teria que ser gerado em runtime já que os relatórios são dinâmicos, certo? Isso seria do lado servidor provavelmente pelo grande processamento.Não tens problemas com perfomance? Tem como colocar um exemplo de como você faz isso?

Outra maneira não sei se ja comentei nesse tópico é usar o iframe que é um componente que criaram.mas também apresenta desvantagem pois o wmode precisa estar como transparente (já ouvi falando contra isso).

Vou me meter na conversa.

Acho que você diz dizer PDF em vez de SWF. Se sim, correto.

Aí depende de fatores como banda (transporte entre o cliente e o servidor) e do processamento do servidor. Se aplica igualmente a algo feito com JSF, acredito eu.

Não tenho, mas pode ser feito da seguinte maneira: um objeto pode guardar as informações do que deve ser gerado no relatório (quando digo informações, digo tudo: desde dados numéricos, caracteres até que tipo de gráfico vai ter, tabelas e essas coisas mais ‘avançadas’). Transita esse objeto entre o Flex e o Java, realiza a geração do relatório no lado do servidor e manda de volta para o Flex.

RafaelViana:

Sim concordo. Menos um ponto para segurança.E menos um ponto também para usabilidade do usuário pois também não acho útil abrir em uma nova aba ter que fechar e voltar a usar o sistema.

Por exemplo no que você fala em gerar o SWF, teria que ser gerado em runtime já que os relatórios são dinâmicos, certo? Isso seria do lado servidor provavelmente pelo grande processamento.Não tens problemas com perfomance? Tem como colocar um exemplo de como você faz isso?

Outra maneira não sei se ja comentei nesse tópico é usar o iframe que é um componente que criaram.mas também apresenta desvantagem pois o wmode precisa estar como transparente (já ouvi falando contra isso).

Olá Rafael,

Não há ponto negativo para a usabilidade em caso de Air. É possível abrir PDF dentro dele em um container comum como TitleWindow, etc. No caso do Flex é melhor converter pra SWF mesmo.

Quanto ao peso do SWF depende. Antes de gerar um novo SWF eu verifico a versão gerada do anterior, e cada um desses tem uma espécie de time control. Logo, se alguém tirou um relatório 1 min atrás não tem porqu~e eu tirar outro. Eu pego o SWF que já estava lá e mando pro cidadão.

Não tenho problema com performance não. Uso um EXE mesmo que peguei de um projeto chamado Alfresco (também uso ele). Eu passo o PDF que quero converter e esse EXE me retorna o SWF dele. Bonitinho.

Não gosto do IFrame pois é uma gambiarra desgraçada que arrebenta com a memória (isso se falando em relatórios realmente grandes).

E outra coisa, eu nunca deixo o controle de geração de relatórios ao usuário. O usuário apenas solicita, e o sistema envia o último já criado. De acordo com o time control de cada um.

@Andre

Quis dizer SWF mesmo.Porque do mesmo modo que um PDF é gerado em runtime esse PDF precisaria ser convertido para SWF em runtime.

@AUser

Interessante.Esse seu processo, realmente tive uma experiência com o AIR mês passado com o componente html e htmlloader você consegue chamar esse URLRequest.E esse componente pode ficar em qualquer container.A desvantagem que percebi é que o usuário é obrigado a ter o Adobe Reader instalado já que com outro leitor de PDF como Foxit não abre.Adobe está tentando valorizar o Reader que na minha opinião perdeu a preferencia do mercado para o Foxit Reader.

Legal esse esquema de gerar SWF em runtime já que havia visto uma vez um post senão me engano do Igor Costa que usava o SWFTools porém tinha que ter o SWF gerado na mão.Por isso perguntei da geração desse SWF.Vou realizar alguns testes com SWF daqui algumas semanas quando tirar um tempo…

Só não sei esse modelo do SWF de pegar de certo tempo porque os dados estão em constante mudança e no meu caso tenho vários filtros então podem estar tirando o mesmo relatório ao mesmo tempo porém com filtros diferentes consequentemente o relatório é o mesmo porém os dados são diferentes (crio a sql dinamicamente que irá enviar para o jasper). (não sei como você faz esse controle, então é apenas uma visão superficial)

Falando em filtros e relatórios mais complexos (odeio lidar com relatórios principalmente aqueles com mais filtros) quero dar uma olhada na geração dinâmica desses relatórios tem um vídeo de um exemplo do Beck Novaes de uma ferramenta que ele implementou para a Petrobras. (mas deve dar uma trabalheira só vou conseguir mexer com isso quando tiver bastante tempo)

Portanto voltando ao título do tópico não existe UMA prática para gerar relatório deve se analisar o ambiente e as necessidades para encontrar a melhor alternativa.

RafaelViana:

@Andre

Quis dizer SWF mesmo.Porque do mesmo modo que um PDF é gerado em runtime esse PDF precisaria ser convertido para SWF em runtime.

@AUser

Interessante.Esse seu processo, realmente tive uma experiência com o AIR mês passado com o componente html e htmlloader você consegue chamar esse URLRequest.E esse componente pode ficar em qualquer container.A desvantagem que percebi é que o usuário é obrigado a ter o Adobe Reader instalado já que com outro leitor de PDF como Foxit não abre.Adobe está tentando valorizar o Reader que na minha opinião perdeu a preferencia do mercado para o Foxit Reader.

Legal esse esquema de gerar SWF em runtime já que havia visto uma vez um post senão me engano do Igor Costa que usava o SWFTools porém tinha que ter o SWF gerado na mão.Por isso perguntei da geração desse SWF.Vou realizar alguns testes com SWF daqui algumas semanas quando tirar um tempo…

Só não sei esse modelo do SWF de pegar de certo tempo porque os dados estão em constante mudança e no meu caso tenho vários filtros então podem estar tirando o mesmo relatório ao mesmo tempo porém com filtros diferentes consequentemente o relatório é o mesmo porém os dados são diferentes (crio a sql dinamicamente que irá enviar para o jasper). (não sei como você faz esse controle, então é apenas uma visão superficial)

Falando em filtros e relatórios mais complexos (odeio lidar com relatórios principalmente aqueles com mais filtros) quero dar uma olhada na geração dinâmica desses relatórios tem um vídeo de um exemplo do Beck Novaes de uma ferramenta que ele implementou para a Petrobras. (mas deve dar uma trabalheira só vou conseguir mexer com isso quando tiver bastante tempo)

Portanto voltando ao título do tópico não existe UMA prática para gerar relatório deve se analisar o ambiente e as necessidades para encontrar a melhor alternativa.

Rafael,

Definimos esse processo por ser uma aplicação bancária. Existem certos relatórios que demorariam 30 min pra ser gerados, e não é certo eu ocupar processamento do datacenter com o relatório na hora que o usuário quiser. E digamos que tenha 5 mil usuários na aplicação, se 1000 desses começam a tirar relatórios todos em um momento, simplesmente ocorre quase um DDoS no datacenter, rs.

Eu não gosto do Jasper justamente por isso de SQL, etc. Eu gosto muito do Crystal, é o mais fácil de mexer e o melhor (embora seja pago, e bem pago).

Só ocorreram simulações até agora na aplicação, por isso não dá pra dizer algo tão mais preciso, pois ela só vai entrar em produção acho que lá pro meio de 2010 (e está sendo feita desde 2008 )… Mas tá ficando boa.

[]'s!