Report Layout Component References (LCR) allow us to build reports using a standard library of components. They are a massive help in reducing report build times and maintenance.
LCRs allow us to reuse an object within the same report, but more importantly within other reports.
An introduction to LCRs
Those who are familiar with LCRs might want to skip this section.
To simply explain the power of LCRs consider the case that all our reports should have a standard header on each page.
This standard header is a simple table. It shows my company name, the report name (using a report expression so it just picks up the saved report name) and the data and time.
If I wanted this standard header in all my reports, I could copy and paste it from one report to another. Problem solved.
However, in an enterprise solution we must consider the life cycle cost of a report – what are the maintenance costs of this header? For example, my company has decided to change its name to Widget Superstore.
If I have copied the header across reports then I must edit each report and update the header. I must then retest each report as I can’t guarantee that I have the correct spelling in each report. LCRs replace this burden.
Typically, I will keep all of my reusable components such as header and footers in a master component report.
The above screenshot shows I have a report called Master Components. Within this report I have a standard header named StandardHeader. I can now reuse this in any other report.
For example, I have created a new report. I will add an LCR from the Advanced objects.
On the Component reference dialogue box, I will browse to my Master Components report and choose the StandardHeader.
This will insert the standard header into my report.
Notice that whilst my header looks the same as the previously shown header the properties pane clearly shows it isn’t a table – it is an LCR.
If we update the header in the Master report then all reports will automatically get the new header. The cost to change multiple reports is the same cost as changing one report. Being an LCR I can guarantee that every single report will have the same company name. I only need to test one report after the name change.
Being an LCR the report author using the LCR can only change the contents that the master creator deems suitable. For example no one using the LCR could change my header colour from grey to blue, or remove the standard Date Time and so on. This guarantees consistency across all of our reports.
LCRs have another trick – Overrides. Overrides lets you change selected parts of an LCR.
For example, by default my standard header has the ReportName from a report expression. I might want to give report authors the ability to override what goes in this box.
To do so I need to name the components I want my authors to be able to override.
The screenshot shows that in the master report I have named the text item that shows the ReportName.
Let us return to the report that contains the LCR. By clicking the Override property of the LCR I can override the named parts.
Here I am overriding the ReportName.
After doing so the LCR now looks like:
The ReportName has been removed. I now have a drop zone into which I could place my own bespoke text.
This short introduction should demonstrate the power of LCRs. LCRs can be anything that you can put on a page – tables, blocks, lists, prompts and so on.
LCRs do have some restrictions.
- You can’t set the properties of anything in an LCR.
Which is why I am writing this blog post to talk about prompts.
- Only display objects can be LCRs.
- If you create an LCR that contains something that uses a query, then you need to make sure the query is in any reports that use the LCR.
Making More Reusable Prompts and LCRs
I have shown how LCRs can be used for a simple header. But LCRs can be anything. Consider in a report suite that we will have many reports that use the same prompts. We can create prompts in our master report and reuse them in any other report.
The above example shows a sample Currency Scale prompt. It consists of a table with some text and a prompt. The table has been named PromptCurrencyScale.
Being a simple example, the prompt contains three entries.
And the default has been set to Millions.
Using an LCR our report authors can now add the standard scale prompt to their reports. This massively reduces development time.
We know that when this report runs it will default to millions.
Often with prompts we find that we want to change the default value. Consider the case that for the majority of reports we want them shown scaled to millions. Our Currency Scale prompts is perfect for these reports. But how about for the reports that we still want to have scaling but would prefer the default scaling of Pounds? These reports can’t use the standard scaling prompt. Do we create multiple versions of of the prompt and let authors choose the one with the appropriate default? In this case I would have to create three versions of the prompt and maintain three versions of the prompt in my master report. This is one solution, but doesn’t really work when we have a data driven prompt with potentially hundreds of values where report authors might want to pick any for a default.
There is a better way, and it involves being a bit more creative with our master prompt.
The better way is a master prompt that looks like this.
The changes are:
- A new table has been inserted.
This is coloured yellow.
The table contains some text and a new text prompt.
- The text prompt sets the same parameter ‘Scale’ as the existing drop down prompt.
- The text prompt is set to default to Millions.
- The text prompt is named ‘DefaultScale’ so that it can be overridden.
- The box type of the yellow table is set to box type none so that report consumers cannot see it.
Report authors should use the ‘Show Hidden Objects’ from the visual aids menu to see these hidden items. (For more details see my previous blog posts on comments in reports).
- The default value has been removed from the drop down prompt.
The summarise then we now have two prompts that set the same Scale parameter. The first of which is the text prompt that defaults to millions.
Let’s look at this from the report authors context. If this updated prompt is added as an LCR the report looks like.
And again, if this is run it defaults to millions.
But the report author now can change to their preferred default. To do this they will use the Override capability.
The text prompt is overridden.
This leaves a drop zone into which we can add our own text prompt. The new prompt sets the parameter Scale and the default is Thousands.
Now when the report runs the standard scale prompt defaults to thousands.
Whilst this solution looks a little crazy and is a bit more work for the Master author it has many advantages.
- The master author only has one prompt to maintain.
- Report Authors can override the default to any value they desire.
Another use case for this technique is when we have optional prompts. We may have a prompt that is optional. For the standard version of the optional prompt we don’t want any values selected. But we want to give report authors the ability to set a default on the optional prompt.
In this scenario my master prompt looks like this:
In this case the visible check box prompt has no default set (the same as the previous technique). But this time there is no text prompt providing a default. Instead there is some place holder text that is named. This text also tells report authors to override the text and drop a text prompt in with their default.
LCRs and the Interactive Viewer
A late amendment on this blog post. In CA 12.1 and prior objects that have the interactive viewer, such as lists, if referred to across reports via an LCR, will not enable the interactive viewer.
For example, I create a list in Report 1. I refer to that list in Report 2 using and LCR to the list in Report 1. The interactive viewer will not be available in report 2.
#IBMChampion