Relatórios Web Lazarus no Linux

Hoje temos o prazer de anunciar o lançamento dos componentes cliente-servidor para o Lazarus. Com a ajuda deles, você pode criar e configurar um servidor para construção remota e exportação de relatórios de acordo com suas necessidades, e tanto seu programa quanto um navegador da Web podem atuar como cliente.

Until recently, the task of generating reports through the Web from an application written in Lazarus was, let’s say, very creative. Today we are pleased to announce the release of client-server components for Lazarus in beta testing. They can be used to create and customise a server for remote report generation and exporting, while your program and Web browser can act as a client.

Os componentes cliente-servidor no VCL FastReport foram implementados há muito tempo, mas antes disso não haviam sido adaptados para o Lazarus e operavam apenas no Rad Studio Delphi e C ++ Builder.

O artigo será útil não apenas para aqueles que nunca os usaram antes, mas também para aqueles que desejam migrar seu servidor FR para o Linux, pois descreve honestamente todas as vantagens e desvantagens. Também descobrimos o problema no próprio Lázaro e encontramos uma maneira de resolvê-lo.

E agora vamos passar para o lado técnico do problema.

Componentes cliente-servidor para relatórios no Lazarus

Os componentes cliente-servidor no Lazarus estão disponíveis em dois sistemas operacionais: Windows e Linux (somente GTK2). Eles são implementados no pacote "fr6CS_lazarus.lpk", cujas dependências especificam o pacote de exportação e, portanto, o pacote de exportação localizado na pasta "Source/ExportPack" deve ser instalado antes da instalação.

Após instalar o pacote de componentes cliente/servidor, você terá uma nova aba chamada "FastReport 6.0 Cliente/Server", onde encontrará 4 componentes:

1. TfrxReportServer é um componente de servidor, um servidor de relatório e um servidor HTTP dois em um. Seu campo mais importante é ConfigFileName, onde o caminho para o arquivo xml com as configurações deve ser especificado.

Você pode especificar muitas configurações neste arquivo, estas são apenas as mais importantes delas:

• As próprias configurações do servidor, como porta e tempo de espera;
• Configurações para o motor FR, como desabilitar a execução de scripts;
• Grandes configurações de exportação;
• Configurações de cache, como duração do arquivo de cache, localização de armazenamento de cache ou você pode desativá-lo completamente;
• Configurações do sistema de registro;
• Configurações de conexão de banco de dados.

Você pode ler mais sobre todas as configurações aqui. 

2. TfrxServerConnection é um componente cliente que contém informações para conexão remota ao TfrxReportServer, tais como: host, porta, número de tentativas de erro, tempo limite e assim por diante.

3. TfrxReportClient, um componente cliente, análogo ao TfrxReport, executa uma solicitação de relatório no servidor e a exibe no cliente. Ele usa esse componente TfrxServerConnection para obter informações sobre o servidor. Ele pode receber um relatório criado do servidor e exibi-lo ou exportá-lo internamente (na máquina do cliente).

4. TfrxHTTPClient é um componente cliente projetado para receber arquivos arbitrários por meio do protocolo HTTP. Por exemplo, ele pode solicitar relatórios já exportados do servidor.

Também fornecemos 3 aplicativos de demonstração:

1 server - imediatamente junto com relatórios e bancos de dados;
2 clients - simples e "avançado".

Como um cliente "Avançado", você pode realizar testes multithread de suporte de carga pressionando o botão Iniciar:

Gostaríamos também de lembrar que o cliente pode ser um navegador normal e a geração do site para o cliente web também pode ser configurada a seu gosto, enquanto o servidor de demonstração já está configurado para o cliente web.

"Bottle neck" GTK2

Lazarus é um IDE de código aberto para várias plataformas. Mas esse "barril de mel", infelizmente, também tem uma "colher cheia de alcatrão". Começaremos com o mais desagradável, ou seja, o servidor Linux.

GTK2 tem uma propriedade extremamente desagradável: single threading.

Isso significa que mesmo que 2 programas desenhem figuras em seu BitMap em um ciclo infinito, GTK2 reduzirá tudo a 1 fluxo. Portanto, no total, esses 2 programas desenharão menos números do que um programa teria desenhado, porque parte do tempo será gasto na sincronização.

Mas, neste caso, a sincronização é organizada sem nosso envolvimento.

Agora considere, por exemplo, a situação em que as figuras são desenhadas por 1 programa em vários fluxos (cada fluxo tem seu próprio BitMap local). Neste caso você terá que criar um sistema de travamento em seu código, pois nos lembramos das threads únicas desta biblioteca. Mas essas não devem ser seções críticas comuns, mas seções críticas globais no nível GTK2. E quando um dos fios entra nessa função crítica, até a forma básica é suspensa até sair dela.

O multithreading com imagens só pode ser organizado encontrando um componente de desenho semelhante que seja independente de GTK2 (por exemplo, neste exemplo com imagens), no nosso caso, outro componente não é adequado.

Portanto, algumas operações de servidor são reduzidos a 1 stream.

E por causa dessa característica, em particular, é melhor não usar diálogos, pois enquanto 1 cliente responder a um diálogo, a construção de relatórios para outros clientes ficará em pausa.
Pode surgir a pergunta: "Por que você ainda precisa de um servidor de thread único?" e você estará parcialmente certo, pois é semelhante ao problema do "gargalo" em estradas onde a capacidade total da estrada é igual à capacidade da estrada no lugar mais estreito.

Mas você estará apenas parcialmente certo. Apenas 3 grandes operações são reduzidas a um fluxo: upload de relatórios, construção e exportação. O recebimento e a transferência são realizados em paralelo e, graças ao sistema de cache dos relatórios construídos, em alguns casos não será necessário construí-los novamente.

And this, in combination with a powerful server, will make this problem much less visible. It is also a problem only for Linux (GTK2), because this problem does not exist in Windows, and with the release of GTK3 (which already supports multithreading) in Lazarus it will disappear altogether.

E isso, em combinação com um servidor poderoso, tornará o problema muito menos visível. Também é um problema apenas para Linux (GTK2), porque este problema não existe no Windows, e com o lançamento do GTK3 (que já suporta multithreading) no Lazarus ele desaparecerá por completo.

O resto dos problemas são muitas vezes menores e até minúsculos em comparação com este.

O que fica para trás

Uma pequena parte da funcionalidade foi cortada durante a portabilidade, nomeadamente o CGI e o sistema de autorização. A rapidez com que os implementamos depende de solicitações reais de nossos clientes.

Exportar para HTML para o Lazarus ainda está longe da perfeição, o cliente web pode e deve ser usado, pois é conveniente, mas os relatórios não serão exibidos perfeitamente.

No entanto, você pode configurar o sistema para que o cliente web receba relatórios exportados não em HTML, mas em PDF, por exemplo. Afinal, a maioria dos navegadores modernos pode exibir arquivos PDF perfeitamente. Implementamos muito bem esse formato de exportação, que você pode ver por si mesmo.

Correção de um erro na queue de mensagens do Lazarus 2.0.10

Também para aqueles que desejam utilizar nossos novos componentes no Linux, uma coisa importante a ser mencionada: encontramos um erro no bloqueio da fila de mensagens e não foi possível contorná-lo. Conseguimos entrar em contato com os programadores do Lazarus, eles já corrigiram esse problema e na próxima versão do Lazarus tudo funcionará de forma estável. Por enquanto, na versão 2.0.10 e posterior, esse bug terá que ser corrigido localmente. Não vai demorar muito tempo ou esforço, tudo o que você precisa fazer é adicionar 3 linhas a um dos arquivos do Lazarus e reconstruí-lo:

1. Abra a pasta onde o Lazarus está localizado (on Ubuntu, for example  "/usr/share/lazarus/2.0.10")
2. Abra o arquivo ~/lcl/interfaces/gtk2/gtk2msgqueue.pp in it.
3. Encontre a procedure:  procedure TGtkMessageQueue.Lock;
4. Nesta procedure, encontre a linha: g_main_context_acquire(FMainContext);

Este código ignora o fato de que a função g_main_context_acquire pode falhar.

Portanto, substitua-o por:

repeat
until g_main_context_acquire(FMainContext);

Ou seja, nós chamamos g_main_context_acquire em um ciclo até retornar True (concluído com êxito).

Nós o convidamos a experimentar nossos novos componentes para o Lazarus, mas gostaríamos de lembrar que esta é uma versão beta e irá melhorar de acordo com suas necessidades. Em caso de erros, não deixe de nos escrever para o suporte.