A NEW TODAY IS DAWNING!

TB0004 - Using a Browser to View Reports

Number: TB0004

Availability: As of BuildPro 8.00, all users.


Introduction

Internet Browsers (i.e. Netscape Navigator or Microsoft Internet Explorer) were built to view information. They have excellent features such as the ability to scroll up and down through large documents, print specific portions, changes fonts sizes etc. Why not use the browser to view on-screen reports from BuildPro?


Your First Web Report

Browsers rely on a file format called HTML. While we are not going to include a tutorial on HTML here, we'll show you how to convert a report output file to HTML format.

When running a report in BuildPro the end result is always a plain text file (ASCII). Normally if a report's destination is "T" for Terminal, BuildPro will display it in the internal viewer. Lets say that the report output file is as follows (a simple address listing):

Industrial Tools Inc.
123 Big Street
Los Angeles, CA 90007

The only thing needed to convert the file to HTML format is to add two lines:

<HTML><BODY><PRE>
Industrial Tools Inc.
123 Big Street
Los Angeles, CA 90007
</PRE></BODY></HTML>

Follow this link to view the above file in your browser. Use the browser function to view the "source" to make sure the content is the same as above. Then come back.

That is just the beginning. One of the strong features of HTML is the ability to embedd colors and graphics. See more on formatting below.

For each report you will need to add a few lines to the beginning and end of each report. The above example is quite simple, but as you will experiment and learn, you will probably want to add many lines at the beginning and end of each report. So instead of embedding this in your report text you will want to post process the output file after the report is finnished. Besides you don't want to add report formatting codes to your report layout. See post processing below.

To view the report in a browser, you have to tell BuildPro to start the browser and display the report output file. Do this using the SYSTEM *UI command. See Using the New SYSTEM command for more information.


Example

Here is a simple example on how to create and display a report in a browser from within BuildPro. The example is simplified to make it easy to follow. A real implementation would incorporate a more sophisiticated approach.

In the function or process which calls the report add a couple extra commands:

REPORT customers
VISIT post_process V-output
SYSTEM *UI V-output_file

To determine the unique name of the report output file, add the following line as the first line of the report's start-of-report function:

V-output_file = *FILENAME

The output filename of a report is normally *TEMP. The above command will allow you to save that name in a variable so you can access it later. Also set the report output destination to "F" for file and elect not to delete the output file after the report is done.

In the post_process function, process the file to add the HTML lines at the beginning and end. While this can be done within BuildPro, it would be more efficient using a UNIX script, C or Visual Basic program. One method is to simply concatonate the a header file, the report file and a footer file.


Formatting

Let's look at a typical report normally printed on a landscape printer. Using the above approach on a report from an exising BuildPro application the result might look like this. Again use the browser feature to view the page source. Then come back.

Lets expand the HTML header to include the following:

<html>
<head>
<title>Revenue Report</title>
</head>
<body>
<pre style="font-size: 80%">
<small>

Now have a look. This is what we did:

  1. The <HTML> and <BODY> commands are required in HTML. <PRE> is used to tell the browser the text that follows is preformatted so the browser will not provide line breaks.
     
  2. The <TITLE> command sets the title at the top of the window. When the window is minimized, the report title is visible on the task bar.
     
  3. By adding a style to the <PRE> tag we can decrease the font size to include more text in the initial view. The user can also change the size by altering the settings in the browser.

Reports generated by BuildPro normally include page breaks consisting of a header and footer. Without modifiying the report or post-formatting the output file, these will remain. Means of removing them will depend on your reports. If you are not able to change the report or programtically bypass headers and footers you should be able to remove them afterwards. Searching for formfeed characters is one way of finding a page break (allowing you to remove lines prior or after the formfeed).

Adding colors and graphics will allow you to create a look-and-feel according to your customers requirements. Here is one further example based on the original BuildPro report. Adding tables, frames or small java scripts will allow you to create incredible looking reports.

For a good resource guide to formatting pages using HTML see http://www.jalfrezi.com.


Post Processing

If the application is on a Linux server you can use the following example script to post process the report output file. In this case the first argument is the report file and the second argument is the requested output destination.

#
# Syntax: rpt_process input_file output_file
#
header=$HOME/wwwreports/header.htm
footer=$HOME/wwwreports/footer.htm
#
# Concatenate files:
cat $header $1 $footer > $2
#
# Transfer to required destination:
mv $2 $USER_WWW_REPORTS
#
# Done.

This script would allow users to define their own report headers and footers. The script automatically transfers the file to the users home directory (designated by $USER_WWW_REPORTS).


Displaying the Report

The simple example above relies on running BuildPro stand-alone on a single PC. It is recommended that as part of the post processing, the output file is moved to a different file space move conveniently accessible to the PC. Here are a couple options:

  • Web Server. The best option for a server-based application is to transfer the file to a predetermined space on an Intranet web server. Most server platforms (UNIX and NT) come with http services and does not mean you need a dedicated web server. One method is to transfer the file to a hidden directory on the web server so that different users cannot view reports generated by other users. This can also be solved by dedicated and password protected directories for each user controlled by a user setting.
     
  • E-Mail. The report can be send via e-mail to the end-user. In this case make sure you do not link to images or other files not available to the end-user.
     
  • FTP. Using a SYSTEM *UI command, have the client PC retrieve the file from the application server.
     
  • Shared Directory on Server. Allow the client PC to access a shared file space on the application server. After post processing move the file to the user's predefined shared file space.
     
  • Shared Directory on Remote Server. Transfer the output file to a shared file space accessible from the PC. For example the if the application server is UNIX based and the file server is running Windows NT, the UNIX server can ftp the file to a directory on the NT file server. The target directory may be different for different users.

 

Further expanding the use of the Browser
 

  • Printing. Using the browser as the on-screen viewer of reports also enables the user to print a hard copy fo the report. For list style reports (parts list, customer report etc) might always choose to view the report on-screen and then print all or portions of the report. This will allow you to eliminate the need for different printer and on-screen layouts.
     
  • Links. Add hyperlinks in the report to direct users to manual pages explaining details of the report data. Add a link to the support desk.
     
  • Temporarily store reports. Using the Web Server or shared file space alternatives above, the report output can be saved for access later in the day. A user which accesses a report frequently during the day (and for which the input data does not change) can run the report in the morning an access that same report throughout the day. A server process can continuously montior existing reports and delete them after certain expiry time / date.
     
  • Advanced HTML. Using style sheets and simple Java scripts the report could collapse or expand based on the user interest in details.

 

Summary of Benefits
 

  • Intranet-enable your application.
  • Same wide reports for on screen as for printer. No need for two different report layouts = decreased application code.
  • Easy to embedd graphics, fonts and colors in existing reports.
  • Print all or only portions of a report.
  • Save for access later.