Fórum exemplo funcionando de JSF chamando um iReport #4133

Pirahy,

qual exatamente tem sido o seu problema? É na hora de enviar o relatório para o cliente pelo servlet?

Eu consigo gerar o pdf, mas não lança na tela, ou no browse, neste caso uso usando "manager bean".

Com servlet não consegui chamar o jasperreport.

Olá Pirahy,

este caso é um pouco chato mesmo, no entanto, há uma solução para o problema, que consiste em redirecionar a saída do relatório utilizando o contexto do Faces.

Vou lhe expor um código fonte e, em seguida, explicá-lo linha a linha para você: no caso, trata-se de um trecho de um dos meus sistemas nos quais passei exatamente pela mesma dificuldade.

Eu precisava gerar um relatório (independente do formato, no código abaixo, foi em Excel) e estava usando o Faces.

No caso, o código se encontra dentro de um ManagedBean. Trata-se de uma action chamada geraRelatorio.

(Repare que este exemplo é independente do gerador de relatório utilizado. Ele simplesemnte expõe como redirecionar para o usuário a saída binária de um gerador de relatórios usando JSF, o que deverá resolver o seu problema.)

public String geraRelatorio() {
/*
   Obtendo o contexto do JSF.
   Ele será fundamental para o próximo passo:
*/
FacesContext contextoFaces = FacesContext.getCurrentInstance();

/*
    O primeiro passo consiste em obter a instância do HttpServletResponse, que conterá o stream de saída para
    o qual você irá redirecionar a saída do iReport
*/
            HttpServletResponse resposta = (HttpServletResponse)  contextoFaces.getExternalContext().getResponse();

/*
       Com o HttpServletResponse obtido, eu defino algumas propriedades referentes ao cabeçalho HTTP
*/
            String mimeType = "application/octet-stream";
            resposta.setContentType(mimeType); // O tipo de dados que quero expor ao navegador

            resposta.setHeader("Content-Disposition", "attachment; filename=\"lista.xls\""); // O nome do arquivo que quero enviar
            resposta.setHeader("Content-Encoding", "ISO-8859-1"); // a codificação que escolhi
/*
   A codificação ISO-8859-1 foi escolhida porque é o padrão latino brasileiro (suporte a caracteres como ç, ã, etc.)
*/
            Saida saida = new Saida(); // o meu gerador de relatórios
            try {
/*
        A minha classe para geração de relatórios recebe os seguintes parametros:
         o tipo do relatório: referente à minha aplicação
         o conteúdo a ser impresso: uma lista de componentes, não interessa o conteúdo no seu caso
         o tipo de impressão: no meu caso, um arquivo no formato Excel
         o Stream de saída.

         O Stream de saída corresponde ao stream de saída do HttpServletResponse.
*/

                saida.gerarSaida(getTipoRelatorio(), conteudoImpressao, getConteudo(), TipoImpressao.Excel, resposta.getOutputStream());

// Sempre execute o método flush após a execução do seu relatório
                resposta.getOutputStream().flush();
// O método responseComplete finaliza o envio para o usuário
                FacesContext.getCurrentInstance().responseComplete();
            } catch (ErroHenrique ex) {
                ex.printStackTrace();
            } catch (IOException ex) {
                ex.printStackTrace();
            }
}


Aguardo seu retorno

Agora é o seguinte: ao abrir a saida ele não encontra o arquivo que gerei, talvez eu tenha que rever o caminho onde gravo o arquivo de saida e inclusive o arquivo de origem (.jasper) Como posso informar os caminhos dinamicamente, por exemplo, tenho o .jasper dentro da pasta "web/relatorios" e a saida estou colocando "/saida.pdf" mas ao abrir o pdf ele não abre. Por obsequio, tem como abrir direto o adobe sem que o usuario precise confirmar?

Olá Pirahy,

não há como definir aonde o arquivo será salvo na máquina do cliente, pois o navegador só receberá um stream de dados.  Uma outra razão diz respeito à segurança. Se fosse possível definir aonde o arquivo seria salvo no computador do usuário, códigos mal intencionados poderiam, por exemplo, substituir arquivos já presentes no computador do cliente, como por exemplo DLLs, arquivos de registro, etc.

No caso, o stream é precedido do cabeçalho HTTP que, como no exemplo anterior, só lhe permite mudar o nome do arquivo a ser enviado.

Com relação a abrir o arquivo diretamente com o Acrobat Reader, novamente aqui o que se pode fazer consiste em alterar o cabeçalho HTTP referente à propiredade mime type, no caso do arquivo PDF, o valor desta propriedade seria application/pdf

(uma lista completa de mime types pode ser encontrada no endereço http://www.webmaster-toolkit.com/mime-types.shtml)

Ao receber o stream do servidor, o cliente primeiro verificará qual o mime type do tipo de conteúdo enviado pelo browser. Então, a partir do mime type, cabe ao navegador/sistema operacional selecionar qual o programa relativo aquele tipo de arquivo.

No entanto, nada impede que no computador do usuário não tenha por exemplo o Acrobat instalado. Neste caso, o comportamento default do browser consiste em oferecer apenas a opção salvar como relativo ao arquivo enviado.

A principio funcionou, ´so um detalhe, ao chamar o adobe reader ele pergunta antes para salvar ou abrir, teria como abrir dentro do browse a visualização do pdf?

Neste caso, vai depender da configuração do browser do cliente, ou seja, não há muito como se garantir isto. 

Pirahy,
a resposta do consultor solucionou o seu problema? Podemos fechar o chamado?
No aguardo.

sim, pode fechar