The tutorial in the previous chapter demonstrates how easy it is to build reports using BIRT, so you may be puzzled when you next see a chapter recommending that you plan your report development. This chapter receives its prominent position because as you need to address more complex reporting requirements, you will find it is much more efficient to work from a plan.
You should always plan a report on paper before you begin to create the report with BIRT Report Designer. Planning helps clarify the report requirements and saves time in the long run, because you do not waste time creating and fine-tuning a report that does not meet your users’ needs.
Before you start creating a report, you should have the following documents prepared:
A specification that describes the requirements for the report project
A prototype, or mock-up, of the report
Ideally, your documents should be reviewed and approved by your report users to determine if the proposed layout meets requirements they may not be able to predict without seeing a mock-up on paper.
In organizations with large IT departments, report developers typically receive requests for new reports that are accompanied by a specification and perhaps a mock-up of the report. Sometimes, report developers discuss report requirements with the person who requested the report, and they develop the specification and mock-up together. Either way, both documents are essential planning tools before a report developer even starts BIRT Report Designer.
If you are responsible for writing the specification, you need to identify the information that the report should provide and determine how best to present the information. This chapter provides guidelines for defining the specification and designing a mock-up of the report. If you receive a specification from somewhere else, use the guidelines to ensure that the specification covers all the information that you need.
This step is the most important one in the planning process. To get started, answer the following questions:
What is the purpose of the report?
A purpose statement helps you determine the information that you need. It also gives the report a starting point.
The following example is a sample purpose statement:
The purpose of this report is to show monthly sales by region, then by sales representatives, and to flag the representatives whose sales figures fall below a certain amount.
Make the purpose statement as specific as possible. A vague requirement, such as a monthly sales report, does not help define the precise data requirements.
Who is going to read the report?
A report can be viewed by different types of users. For example, sales representatives, sales managers, and the vice president of sales can all use a sales report. Each type of user is interested in different types of information and different levels of detail. Knowing the users of your report helps you plan the report data accordingly. Reviewing the list of data to be included can ensure that the data needed by each of the users is, in fact, included in the design. Having a representative from each of the groups of users available to review your proposed layout assists in ensuring that you are meeting each set of requirements.
What information should appear in the report, and where is it coming from?
Much of the information in a typical report is taken directly from data fields in a database, application, or text file. First, you need to know the source or sources of data for the report. Second, you need to understand how the data is structured. If, for example, the data source is a database, you need to know what tables are in it, the relationships among tables, the columns in each table, the data types, and so on. If necessary, ask your database administrator for this information.
Does any of the data need to be calculated?
Some report data comes directly from data fields, such as sales representative names or addresses. Some information must be calculated, such as the percentage by which sales figures exceed or fall below a certain amount.
How will the data be calculated?
Some data can be calculated by performing a mathematical operation on data field values, such as multiplying Item.Quantity by Item.Price to get extended prices. Some data may need to be calculated by using a JavaScript function or a user-defined function.
Do you want to enable the report user to specify what data to display?
You can create a report that always displays a specific set of data from the data source. You can also create a report that lets users specify what information they want to see. For example, rather than displaying sales data for all regions, you can prompt the user to specify a region for which the sales data appears in the report.
When designing a report, you need to consider and test the environment in which the report will be viewed, because the environment affects how a report appears and prints.
You should always design for the final delivery environment. This approach includes choosing the right fonts and colors, selecting the appropriate page size, fine-tuning the size of report fields and the amount of space between them, and so on.
Consider the following questions:
Which is more important, viewing online or printing the report?
Recognize that there are differences between online and printed reports; decide which is more important, and design for that output. For example, printed reports can vary in appearance depending upon the printer producing the output. If, for example, a report will primarily be viewed online, you can add interactive viewing features, such as hyperlinks or a dynamic table of contents.
Will the report be viewed in HTML or as a PDF file?
The appearance of the report differs depending on the file format. Pagination, for example, is a key difference between HTML and PDF files. A report in PDF format appears on multiple pages of a fixed size. An HTML report, on the other hand, can appear on multiple pages or in one scrollable page, depending on what you specify.
If distributing an HTML report, what browsers are you supporting?
Different browsers can display results differently, because they interpret HTML or CSS tags differently. If there are particular browsers that you must support, test the report in those browsers.
BIRT Report Designer supports creating reports that contain international data for use in multiple locales. A locale defines a set of conventions for providing, displaying, and sorting data. Numbers, dates, and currencies appear differently in different locales. The following examples show dates in long date format when the locale is English (United States) and when the locale is German (Germany):
Wednesday, July 7, 2004 Mittwoch, 7. Juli 2004
BIRT reports automatically display date, number, and currency data according to the locale to which the report user’s machine is configured. You do not have to do anything special to display these types of data in multiple locales.
When designing a report for international users, consider the following questions:
Will the report be viewed in one locale? If yes, which locale?
If your report will be used in a specific locale, design and test the report in that locale.
Will the report be viewed by users in multiple countries?
If your report will be viewed by users in multiple countries, you should consider internationalizing the report so that it appears correctly in multiple locales. For example, rather than specifying text directly in a report design, you can create text strings in an external source and provide translations of those strings. Using this technique, called localization, the report displays text in the language that is specified by the locale of the user’s machine.
Testing report output in multiple locales is an important early stage in the report design process. Develop a small sample and send that to recipients who can test the output in that locale and, in particular, can test printed output for possible glitches in fonts and layout. Even decisions such as how names are to be displayed can be challenging if the report is to be viewed by users with differing language competencies.
After you identify the report’s purpose and content, you should have a good idea how to organize and present the information. Consider these questions:
What is the overall layout for the report data? Can all the data appear in a single section, or does the data need to be presented in multiple sections?
A simple listing of customer names and phone numbers, for example, can be presented in a two-column table. A financial statement, on the other hand, can be a multi-sectioned report that includes a form letter, a summary of accounts and balances, and transaction details for each account.
Do you need to organize information into groups? If yes, how?
For example, a monthly sales report can display sales figures by region, by sales representative, or by both. To display both, you can group the information by region first, then list the sales representatives for each region.
How do you want to sort information?
A report can present information in the order in which it is stored in the data source, in ascending order, or in descending order. The sort order affects the readability and usability of a report.
Do you need to summarize the data? If yes, how?
Reports that present numerical data, such as expense reports, financial statements, and earnings reports, always contain summary sections for totals, averages, or percentages. Decide if this summary information should appear in a table, a chart, or a combination of these display options.
Do you want to highlight information based on certain conditions?
It is common to use formatting to emphasize certain information. For example, if a report displays a long list of customers in alphabetical order, you can display the names of the top ten customers in blue.
Do you need to display information in page headers and footers?
Printed reports typically display information in the page header to help users navigate multi-page reports. For example, you can display the region name in the header, so users know that sales representatives on page n are part of region x. In the page footer, you can show the page number and the report’s generation date. On the other hand, online reports that present data in one continuous page do not require page headers and footers.
Are there corporate standards that you need to follow?
If your company produces reports for external use, such as financial statements for clients, it is likely that a report that you create needs to use corporate styles. Corporate styles typically dictate the logos, security statements, fonts, and colors that you can use.
Are there online style sheets that you can use?
Most organizations maintain a corporate web site and frequently use CSS to format the look and feel of web pages. You can reuse CSS styles in your reports, which enables you to create reports with the corporate look without having to recreate the styles.
Are there report templates you can use?
Unless your organization is just starting up, chances are report templates are available. If there are no formal templates, look at existing reports to see if you can reuse and adapt their layouts. If you are in start-up mode, examine the sample reports, and consider establishing standards for organizational reporting in common areas, such as budget variance, expenses, and vacation reporting.
After you make the decisions that are described in the previous sections, you are ready to create a mock-up of the report. Use any tool with which you are comfortable, such as a word processor, graphics program, or pen and paper.
A mock-up should show approximately what the finished report will look like, including the report title, page header and footer information, and all the fields in the body of the report. Using a mock-up to get feedback and approval from your primary users can save you time. With this approval, you do not waste time creating a polished report that contains the wrong information or layout.
A mock-up is especially useful when you are first learning BIRT Report Designer. With a blueprint in hand, you can focus on learning and using the tool, rather than trying to design and learn at the same time.
Rarely do you create just one report. Often, you create reports for different departments in your company or to meet your clients’ varying reporting needs. You can approach report creation one report at a time, or you can plan and design a suite of reports. Consider these questions to evaluate which approach is more suitable:
How many reports are you creating?
Do the reports require common elements and styles, such as connections to the same data source, page headers and footers that display the same information, report titles in a particular font and color, or tables with a certain format?
Do you work in a group with other report developers? If yes:
How similar are the report projects?
Do you need to collaborate on the designs?
If you create more than a couple of reports, and they contain many common elements, or if you work with other report developers on similar reports, you can streamline the report creation process by creating a collaborative and shared report development environment. With BIRT Report Designer, you can:
With careful planning, you can create rich sets of libraries and templates that provide you and other report developers with a head start when you create a new report.
A report design typically uses external resources, such as image files, report libraries, Java files, and message files used for localization. If you work on a suite of reports that use multiple external files, you need a way to organize the files so that you can easily package and deploy them to an application server or migrate your reports to different machines.
BIRT Report Designer provides a resource folder as a way to organize all these external files for ease of deployment later. The default location of this resource folder is specified in the Preferences page, which you access by choosing Windows→Preferences from the main menu, then choosing the Report Design Resource item. On this page, you can specify a different path for the resource folder option.
When you publish a library or create a message file in BIRT Report Designer, these files are automatically saved in the resource folder. To manage files that are created with other applications, such as image files, copy the files into the resource folder before you create the report. Then, when you insert the images in the report, select the image in the resource folder.
Planning the report design is one phase of the planning process. You also need a plan for deploying or distributing the report. Consider these questions:
How will the report be distributed to users?
Will the report be deployed from an application?
Will the report be sent through e-mail?
If the report will be deployed from an application, address these questions:
How will the report integrate with the application?
Will users need a secure login to access the report?
Will users view a generated report, or will users generate the report to view it with real-time data?
Depending on your deployment strategy, there are a host of other questions to answer and programming tasks to perform. Deployment and integration are topics that are beyond the scope of this book and are covered in Integrating and Extending BIRT (Addison-Wesley, 2006).