Web reports in Lazarus on Linux

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.

The client-server components in VCL FastReport were implemented long ago, but before that they had not been adapted for Lazarus and operated only in Rad Studio Delphi and C++Builder.

The article will be useful not only for those who have never used them before, but also for those who want to migrate their FR server to Linux, as it honestly describes all the advantages and disadvantages. We also discovered a problem in Lazarus itself and found the way to solve it.

And now let’s move on to the technical side of the issue.

Client-server components for reporting in Lazarus

The client-server components in Lazarus are available under two operating systems: Windows and Linux (GTK2 only). They are implemented in the "fr6CS_lazarus.lpk" package, the dependencies of which specify the export package, and therefore the export package located in the "Source/ExportPack" folder must be installed before installation.

After installing the client/server components package, you will have a new tab called "FastReport 6.0 Client/Server", where you will find 4 components:

1. TfrxReportServer is a server component, a report server and a two-in-one HTTP server. Its most important field is ConfigFileName, where the path to the xml file with settings must be specified.

You can specify many settings in this file, these are just the most important of them:

• Server settings itself, such as port and waiting time;
• Settings for the FR engine, such as disabling the execution of scripts;
• Huge export settings;
• Cache settings, such as cache file lifetime, location of cache storage or you can disable it altogether;
• Logging system settings;
• Database connection settings.

You can read more about all the settings here. 

2. TfrxServerConnection is a client component that contains information for remote connection to TfrxReportServer, such as: host, port, number of error attempts, timeout and so on.

3. TfrxReportClient, a client component, analogous to TfrxReport, performs a report request on the server and displays it on the client. It uses this TfrxServerConnection component to obtain information about the server. It can receive a built report from the server and display or export it in-house (on the client's machine).

4. TfrxHTTPClient is a client component designed to receive arbitrary files via the HTTP protocol. For example, it can request reports already exported from the server.

We also provide 3 demonstration applications:

1 server - immediately together with reports and databases;
2 clients - simple and "advanced".

As an "Advanced" client, you can perform load-bearing multithreaded testing by pressing the Start button:

We would also like to remind you that the client can be a normal browser and the generation of the website for the web client can also be configured to his or her taste, while the demo server is already configured for the web client.

"Bottle neck" GTK2

Lazarus is a cross-platform open source IDE. But this "barrel of honey", unfortunately, also has a "spoonful of tar" in it. We will start with the most unpleasant, namely the Linux server.

GTK2 has one extremely unpleasant property: single threading.

This means that even if 2 programmes will draw figures on their BitMap in an endless cycle, GTK2 will narrow everything down to 1 stream. Therefore, in total, these 2 programs will draw fewer figures than one program would have drawn, because part of the time will be spent on synchronisation.

But in this case synchronisation is organised without our involvement.

Now take, for example, the situation when the figures are drawn by 1 programme in several streams (each stream has its own local BitMap). In this case you will have to create a locking system in your code, because we remember about the single threads of this library. But these should not be ordinary critical sections, but global critical sections at GTK2 level. And when one of the threads enters this critical function, even the basic form hangs until it comes out of it.

Multithreading with pictures can only be organised by finding a similar drawing component that is independent of GTK2 (for example, for this example with pictures), in our case another component is not suitable.

Therefore, some server operations are narrowed to 1 stream.

And because of this feature, in particular, it is better not to use dialogues, because as long as 1 customer answers a dialogue, the building of reports for other customers will be on pause.

The question may arise: "Why do you even need a single-threaded server?" and you will be partially right, as it is similar to the "bottle neck" problem on roads where the total road capacity equals the road capacity in the narrowest place.

But you will be right only partly. Only 3 large operations are narrowed down to one flow: uploading reports, building and exporting. Receipt and transfer are carried out in parallel, and thanks to the caching system of built reports in some cases you will not need to build them again.

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.

The rest of the problems are many times smaller and even tiny compared to this one.

What is left behind

A small part of the functionality was cut out during porting, namely the CGI and authorization system. How soon we implement them depends on real requests for them from our customers.

Exporting to HTML for Lazarus is still far from perfect, the web client can and should be used, because it is convenient, but the reports will not display perfectly.

However, you can set up the system so that the web client receives reports exported not in HTML but in PDF, for example. After all, most modern browsers can display PDF files perfectly. We have implemented this export format very well, which you can see for yourself.

Correction of an error in the Lazarus message queue 2.0.10

Also for those who want to use our new components in Linux, one important thing is worth mentioning: we encountered an error in blocking the message queue and could not bypass it. We were able to contact the programmers in Lazarus, they have already fixed this problem and in the next version of Lazarus everything will work steadily. For now, in version 2.0.10 and later this bug will have to be fixed locally. It will not take much effort or time, all you have to do is add 3 lines to one of the Lazarus files and rebuild it:

1. Open the folder where Lazarus is located (on Ubuntu, for example  "/usr/share/lazarus/2.0.10")
2. Open the file ~/lcl/interfaces/gtk2/gtk2msgqueue.pp in it.
3. Find the procedure: procedure TGtkMessageQueue.Lock;
4. In this procedure, find the line: g_main_context_acquire(FMainContext);

This code disregards the fact that the g_main_context_acquire function may fail.

So replace it with:

repeat
until g_main_context_acquire(FMainContext);

That is to say, we call g_main_context_acquire in a cycle until it returns True (completed successfully).

We invite you to try out our new components for Lazarus, but we would like to remind you that this is a beta version and it will improve according to your needs. In case of any errors, be sure to write to us in support.