Omnis Studio Reporting for the Internet

This document looks at developing Omnis applications which produce reports to be viewed via the web. There are several different approaches to doing this, and issues to consider.

Delivering Reports via the Web

In order to present a report to an Internet user, it's necessary to deliver it in a format which may be viewed using standard software on a variety of operating systems. The most common way to publish information of any sort on the web is to use pages coded in HTML. Omnis has the facility to produce HTML output from it's standard report classes, allowing existing reports to be published fairly quickly in a web format.

There are several other variations on producing HTML output from within Omnis. However, HTML is not always the ideal way to deliver content which is traditionally associated with printed copy. Because of the different ways in which various web browser programs interpret and display HTML code - which can be further affected by the user's configuration of the package's options - it is not easy to accurately predict the appearance of a page.

Another common medium for delivering documents via the web is Portable Document Format. PDF files can be viewed using free software such as Adobe Acrobat Reader, which also works as a browser plug-in. PDF documents will look and print the same wherever they are opened, which makes them good for delivering print format reports.

The Omnis HTML Report Device

The quickest way to implement web enabled reporting is to take advantage of the standard HTML reporting integrated into Omnis Studio. Instead of choosing to send report output to a printer or the screen, you direct it to the HTML report device, as follows:


Calculate $cdevice as kDevHtml
Do $cdevice.$setparam(kDevHtmlFileName,%%ReportFile)

The second line sets the report's filename. When the Print report command is executed, the HTML generated by the report device is stored in the specified file. If you are implementing a web interface for your application using HTML remote tasks, the remote task's Quit method command would specify the URL of the newly created file and the user's browser would be redirected to view it. If you are using the WebClient, you can call the remote form's $showurl method to achieve the same thing.

This approach allows you to produce web output from existing Omnis report classes without too much effort, but suffers from several drawbacks:-

Appearance
You may be surprised to see that a report which normally looks great when sent to screen or printed out has wobbly looking columns, no lines or boxes, unpredictable text styles and various other anomalies. The Omnis HTML report device handles report layout by specifying the width of table cells in pixels. However, HTML tables are notoriously difficult to accurately control using this method, and sometimes the contents of an individual cell can inflate it's dimensions, affecting neighbouring rows and columns. Handling fonts is a similarly inexact science in web page design, and graphical elements such as lines and boxes are simply ignored by the HTML device.


Pagination
There isn't any - the report is produced as one web page, with a header at the top and totals at the bottom.


Printability
To print a web page, the user must select the browser's print option. Settings for margins, orientation and in some cases scale, are held by the browser, and apply for all web pages printed, so it's impossible to specify these values from within Omnis. Printed output can vary from user to user.


File Creation
The HTML device creates a file as described above. But it's not always desirable to store the report as a file on the web server in this fashion. Sometimes it's preferable to generate the HTML and then return it directly to the user without any disk activity on the server. The program should perform more quickly and demand less storage resources.


File Size
As described above, the report is constructed of layers of nested HTML tables - one for each line of output. This means that a row of, say, 70 characters on the report can represent up to 10 times that number of characters in the HTML file. A report displaying thousands of records can easily expand to megabytes, which would take a long time to download using a normal modem.


There are various approaches to tackling these problems, including the following.

Acrobat Portable Documents

One approach which gets around the problems of display quality and pagination is to create an Acrobat PDF file on the server, and redirect the user's browser to this (using the redirection techniques mentioned above). If the user has the Adobe Acrobat Viewer plug-in for their browser, the file will be displayed, and they can choose to send it to a local printer. The printed output should be similar to that which would be produced by printing the file from the server. If the user doesn't have this browser plug-in (which is freely available), they will be prompted to save the file to disk, from where they can open it in a non-browser version of Acrobat, or any other PDF viewer.

Creation of the PDF file on the server can be done in several ways. Firstly, the full version of Adobe Acrobat includes a PDF 'printer' driver. If you send the report to this 'printer', it will create a PDF file instead. The drawback to this approach is that the standard Adobe driver prompts the user for a filename. As the 'user' in this case is our web server, which may very well be unattended, this presents the developer with a problem. One way around this is to use a proprietary Omnis external called PrintPDF, available from Kelly Burgess, which allows the programmer to specify the filename to the driver.

There are other ways to produce PDF files, including the Aladdin Ghostscript system, which is a freely available piece of software. This includes various utilities for writing and reading PDF files, including PS2PDF.BAT, which converts postscript files to PDF format. In order to produce postscript files, simply install any postscript printer driver, and select print to file. This suffers from the same drawback as the PDF printer driver though, in that the postscript driver will prompt the user (the web server) for a filename. A postscript driver which allowed runtime specification of the filename by a calling program would solve this, and allow PDF files to be created automatically without Adobe Acrobat.

Pagination using Omnis HTML

Going back to HTML, it is possible to get around the problem of pagination by extracting a few records at a time from the report list and producing separate reports from them. For example, if the master report list has 1000 lines, we could produce one report for the first 100 lines, and include links on the page to allow the user to move forwards and backwards through the report. The main problem faced using this approach is the performance of subtotals and totals, which would only reflect the records in the sub-list.

HTML reports without the Report Device

One approach which I believe would be quite elegant would be to produce reports without using the report device, or report classes at all. Although time consuming to set up to start with, this would allow the developer to implement reports which:

The reports would be produced as a response to a remote task, and could include links to page forwards and backwards through the results.