(please check the part 1 Explore the new idea of authoring Cognos reports – Part 1)
Table of Contents
4.3 Make data container reusable
4.3.1 Compare report authoring with software development
4.3.2 Define re-usability of data containers
4.3.3 Sample
4.3.4 Use layout component reference with query in same report
4.3.5 Use layout component reference with query in different reports
4.3.6 Use layout component reference with single data container
4.3.7 Use layout component reference with complicated data container
4.3.8 Make parameter generic for layout component reference
4.3.9 Make parameter pass through to grand children level for layout component reference
Compare report authoring with software development
One of the main focuses on software development is reusability, from functional design, object oriented design, component based, and to SOA. If we use OOD to compare with current report design, it can only belong to the initial functional design stage. We can use OOD as reference to compare with report design.
Encapsulation: report engine doesn’t provide a way to make query and layout together. There is layout component reference, which references only layout without related query.
Inheritance: while query can present a little concept, report itself doesn’t present such a concept at all.
Polymorphism: This is even more advanced concept, nowhere can reflect such an idea in report design.
Define re-usability of data containers
As there is no way that you can use data container as generic enough like software component, we can only maximize the possibility provided by Cognos engine. The main idea is to enhance Cognos layout component reference functionality. The following diagram provides a general solution to reuse data container, which data container can be considered as a crosstab with chart.
Sample
In order to explain this concept, a sample below is used, please download report specification (10.1.1) for review.
There are two pages with two different product lines. Assume that we don’t use loop to put two ages together, instead, we author two separated pages.
The first crosstab from page 1 can be simply used in page 2 as layout component reference.
The only difference between the first page and second page is page set query,
The following topic will explain how to get this concept implemented in detail.
Use layout component reference with query in same report
Traditional layout component reference is used to share the same header, footer and some simple layout. However, it is possible to reuse the whole data container with query. In above sample, the product line crosstab called Data Container (Crosstab) with query qCrosstab. The product line is passed by the master detail relationship to page level query
The page query is controlled by pageset 1 query to decide which product line to run
Now in second page, what need to do is to change page set query to page set query 2, and use component reference from page1, without using any new queries.
In other word, this is real reuse with encapsulation.
Use layout component reference with query in different report
If you want to use this solution in different report, it is going to work as well. The only main differences are:
Layout component reference is reference from different report. In this case you can consider the first report as layout library
All related queries are needed to copy from another report. It is suggested to make a special section of queries as reused query section
Use layout component reference with single data container
It is clear that you can use a single data container as layout component reference, such as crosstab, list, chart and repeater. You can pass one or more than one parameters via the master detail relationship.Use layout component reference with complicated data container
As a data container can contain multiple data containers inside. The reusable data container can be a complicated data container. Subsequently, the query behind layout can be very complicated as well. In this sample, chart is used in crosstab; therefore the reuse crosstab has not only the single crosstab, but also with chart. Of cause, the relationship between crosstab and chart is built based on master detail.Make parameter generic for layout component reference
In order to make component more robust and reusable, you need to make your query generic enough. Assume that you need report support product line, product type and product three level. One report use only product line level, another report uses product type level, and third one report use product level. The solution is to make three query items as below
Product line level
Product line : Product line
Product type: ALL
Product: ALL
Product type level
Product line : ALL
Product type: Product type
Product: ALL
Product level
Product line : ALL
Product type: ALL
Product: Product
The bottom query is to have three different optional filters as
if(?p_fo_productLine? ='ALL') then (1=1) else ([Sales (query)].[Products].[Product line] =?p_fo_productLine?)if(?p_fo_productType? ='ALL') then (1=1) else ([Sales (query)].[Products].[Product type] =?p_fo_productLine?)
if(?p_fo_product? ='ALL') then (1=1) else ([Sales (query)].[Products].[Product] =?p_fo_product?)
Make parameter pass through to grand children level for layout component reference
When data container needs to have master detail relationship to child data container, in this sample, crosstab has chart inside. The challenge is to pass product line from Crosstab to chart, while the product line is not in the crosstab and chart. You might argue that why we don’t make product line in both crosstab and chart. There are two reasons:
This is clear design and can be realized in any complicated situation
It provide much better performance as well, Please check old post How to improve master detail report performance
The solution is to add an optional query item in crosstab as parameter
The master detail relationship
No comments:
Post a Comment