eSS Example of Reusable Reporting Concepts

Here is an example of an eSpreadSheet design that uses the Reusable Reporting concepts previously mentioned. The data layer uses our generic schema to swap data sets within this spreadsheet design without having to modify the layout. Column headings are externalized in a text file and swapped in with the associated data set. The example can be downloaded by clicking here.

To use this example, run as is to see the design against the Products data set and ProductLabels.txt. Next, set the Status Data set to the Book default by right-clicking on the Status Data item in the Data Explorer. Select Set Default then select Book.


Next, let's switch our column headers to come from our StatusLabels.txt external file. Right-click on Label Data Source under Data Sources, select Edit, and change the Source File to StatusLabels.txt as such:


Run the design to test the results. Voila! The eSS design now shows order status information instead of product information. All without modifying the spreadsheet layout. It's a beautiful thing.

eRD Pro Example of Reusable Reporting Concepts

Here is an eRD Pro example that uses all the previously discussed Reusable Reporting concepts. The data layer uses our generic schema. The presentation layer is built off the generic schema field names. Internationalization is accomplished through properties files with name/value pairs associated with the generic schema. It can be downloaded by clicking here.

This report can be run and viewed in English, Japanese and French. Set the viewing locale in eRD Pro Designer's Tools | Options | General tab then Default locale dropdown.


When running this example in the designer, choose the desired locale in the report input parameter dropdown. Since this report is running at generation time, it doesn't have the viewing locale to make this decision for us, so we handle it through the dropdown.


Now you can see how the Reusable Reporting concepts can be used with eRD Pro reports. Later on, I'll discuss how other components in the report layout can be published to a library and made available to all your reusable designs.

BIRT Example of Reusable Reporting Concepts

Here is a BIRT example showing the reusable reporting concepts in action. This example uses our generic schema in the data layer, presentation layer and internationalized locale property files. It can be downloaded here. This example uses BIRT's Classic Models database for the data source. It has two data sets that conform to our generic schema: Countries Data Set and ProductLines Data Set. The report only uses one at a time. The report also uses four internationalized properties files: Countries_en_US.properties, Countries_fr.properties, ProductLines_en_US.properties and ProductLines_fr.properties. They will be used in conjunction with the appropriate data set and locale setting with the BIRT Designer.

First, make sure your BIRT Designer locale setting is set to English (United States) in Window | Preferences | Report Design | Preview.


Run this report as is to see our report against the Countries Data Set with the column headers displayed in English from our Countries_en_US.properties file.

Change the locale setting to French and rerun the report. The column headers will be displayed from the values in the Countries_fr.properties file.

Now, let's take a look at swapping out the data set without having to change the presentation layer. We can do this inside the BIRT Designer by right-clicking on the Table tab in the report design layout and choosing Edit Data Binding. Choose ProductLines Data Set in the Data Set drop down. Answer "No" to the question about wanting to clear all existing data field information. We answer "No" here to keep all our field names that are set to our generic schema, thus not having to make any changes to the presentation layer. Click "OK" to save settings.

Next, let's set the associated locale properties files. Since we swapped in the ProductLines Data Set for our underlying data, we now need to have the associated column headers display on this report. Click on any part of the report design other than the table to choose the report. Look in the Property Editor under Properties and select Resources. Change the Resource File to ProductLines.
Enlarge

Run this report to see the product line data with appropriate column headers. Change the locale setting to back to English and rerun.

You can now see the powerful capabilities of using our generic schema and internationalization. This two column summary report design can be reused easily by swapping in different data sets and locale property files. Later on, I'll discuss how putting components of the report design in a library will further extend the power of these reusable reporting concepts.

Internationalization

Now that our data and presentation layers are synced up through our generic schema, let's look at how internationalization fits into the picture. Labels can be assigned values in locale-specific properties files as name/value pairs. Our labels will coincide with our generic schema by being named Cat1Label, Date1Label and Val1Label. Just add "Label" to the end of the generic field names in our schema that's described in Step 1. For example, in a Sales_en_US.properties file referenced in a BIRT design we have:

Cat1Label=Customer
Date1Label=Transaction Date
Val1Label=Product Quantity

while in a Sales_fr.properties file we would have:

Cat1Label=Client
Date1Label=Date de Transaction
Val1Label=Quantité de Produit

The labels are referenced in your report designs as externalized text from these properties resource files. They are used for column headers, chart axis labels and titles in your report designs. The name/value pair combination associate the appropriate value to the label reference.

Here is a screenshot of setting the x-axis label in a BIRT chart to some external text associated with Date1Label:



The properties files can be referenced through the BIRT report design Resource File setting:

Enlarge

Notice how the Resource File setting identifies the properties file as Sales. Depending on what locale is being used, BIRT will serve up the name/value pair from the appropriate locale-specific properties file. In our example, this would be either Sales_en_US.properties or Sales_fr.properties.

Information Objects as a Bridge

Actuate Information Objects act as a perfect bridge between the data layer and the presentation layer. They map the physical database fields to the logical fields of the generic schema described in Step 1. This is a very good alternative to the use of an alias in the SQL statement described in Step 1. Information Objects act as a separator between the data layer and presentation layer. When something changes in the data layer, only the Information Object needs to be modified, not all the report designs that use it as a data source. The following is an example Information Object that maps the physical database fields to our generic schema:



Information Objects that use the generic schema can be swapped into report designs for reuse of the presentation layer.

Step 2: The Presentation Layer

The second step in using the Framework of Reusable Components is to create charts, spreadsheets and report designs based on the field naming convention of the generic schema introduced in Step 1. The following is an example BIRT chart containing references to our generic schema database field names of Cat1, Date1 and Val1:



Once your report designs contain generic schema database field names, any data source created in Step 1 can be swapped into the report design. The presentation layer is now reused without having to make any modifications.

Step 1: The Data Layer

The first step in using the Framework of Reusable Components is to get control of the data layer. All data presented to the report designs and reusable components of the Framework need to be in the form of a generic schema. The generic schema is a set of arbitrary names for different types of data. Here is the generic schema used by the Framework:

Text fields: Cat1, Cat2, Cat3,...
Date fields: Date1, Date2, Date3,...
Number fields: Val1, Val2, Val3,...

The data source used to collect the data will return it in terms of the generic schema, namely Cat1, Date1, Val1. Here is an example SQL statement that aliases the database field names in terms of the generic schema:

select CUSTOMERS.COUNTRY as "Cat1", CUSTOMERS.CITY as "Cat2", ORDERS.ORDERDATE as "Date1", ORDERDETAILS.QUANTITYORDERED as "Val1", ORDERDETAILS.PRICE as "Val2"
from
CUSTOMERS, ORDERS, ORDERDETAILS
where
CUSTOMERS.CUSTOMERNUMBER = ORDERS.CUSTOMERNUMBER
and
ORDERS.ORDERNUMBER = ORDERDETAILS.ORDERNUMBER

Since all the reusable components in the Framework are built off this generic schema, any data source that conforms to this generic schema can be used. This means our presentation layer will be able to be reused many times over by swapping in any data source that conforms to this generic schema.

Best Idea Contest (Win Prizes)

We are pleased to announce the first in a series of contests we will be running on this blog. We would like you to submit your ideas for what would be the best reusable component for your organization. The winner(s) will receive a copy of the latest version of BIRT: A Field Guide to Reporting by Diana Peh, Alethea Hannemann and Nola Hague. This is an excellent guide for learning and developing useful reports in BIRT.

Please submit your ideas in the comments of this post. And don’t be surprised if we develop a few of these ideas to show you how easy it is.

Introduction

A Framework of Reusable Components can mean a lot of things to a lot of different people. In Dan O'Connell's and my minds, reusable components need to built so generically that anyone will be able to use them without modification. I admit, that's a lofty goal, but even having something to start out with where a few tweaks here and there get you exactly what you need, will greatly improve productivity.

The idea of reusing the whole presentation layer, not just a component from a library at design time, is an idea DanO and I have been noodling on for a while. How cool would it be to have complete report designs, spreadsheets and dashboard controls be reused without modification, just by swapping out the underlying data source? What if there was a repository of presentation assets that was built on this concept and made available for anyone to download and use? Would you use it to swap your data into the visualizations, without modifying the presentation layer, to accelerate the building of your reporting application? I know I would in a heartbeat. This is why DanO and I are taking this idea out of concept stage and building this Framework of Reusable Components into a repository that can be used by all. As you learn this concept and start using this Framework in your own reporting applications, we're hoping you will create your own cool components and submit them back to us for inclusion into the repository so everyone can benefit from them. We would love to have this be a collaborative effort.

In upcoming blog entries, we will describe this concept in more depth, how to access the Framework of Reusable Components repository, how to make it part of your reporting application, how to create your own components, and how to submit them for inclusion into the repository.

I predict this will be a fun project to be involved in and that a lot of people will get a lot of value from it. As an engineer, I'm excited to develop some presentation assets, share them with others, and realize the potential of how this Framework can save tons of report development time.