To “Get it done” and to “Get it done well” are two entirely different things. Both have merit and are appropriate under specific conditions. A mission critical output under a strict deadline must be prioritized to “get it done” to meet the objective. Often this approach has delayed consequences that the urgency of the objective justify. When time allows, real advantages can be gained from a well-considered and documented method of development.
In this overview, we’ll consider some general principles, but also some specific to Cognos Report Studio, a terrifically powerful and feature-rich application, but one with plenty of pitfalls for its abundance. We’ll discuss some ways to set your efforts up for success throughout the process and on through report maintenance.
Understand the Data What generates the data upon which you’re reporting? Is the data consistent? Where are the key dimensions that the business is reliant upon? Which business entities or departments interact with the data? How often does it change?
These are just a sampling of the questions that can be considered at the onset of a design effort. Having a solid understanding of the data, its sources and the processes that generate the data will not only provide a grasp of the business challenges, but also enable you to best solve the reporting needs.
Organize the Information Invest time in leveraging your newly acquired understanding of the data by arranging the data for your report output such that you can easily add or modify data at a later time.
Specifically, identify the level or granularity at which the primary transactions take place. Having this as reference will enable you to make quality decisions about data placement and can often uncover errant assumptions. Separate the dimensions and their attributes in a manner that makes supplementing the data with an additional attribute at a future time a simple matter of identifying to which dimension it belongs.
Finally, push any and all business rules possible to the lowest level that is easily maintained. If you have access to the underlying model, make alterations or additions as this allows for maximum reuse. If the requirements you’ve implemented change, then the changes need only be made in a single place. If you don’t have access to the model, carefully arrange query data to accommodate single locations for business rule definitions. Inevitably one of the first troubleshooting steps is to run the query supporting the report page. If your data is poorly organized or your business rules are somehow contained in multiple places, you’re immediately disadvantaged.
Implement with Intention One of the strengths of Cognos Report Studio is its ability to conditionally render report output. Pages, objects, and blocks along with various other data elements can be rendered by variable conditions, via conditional styles or by render variables. While this endows the developer with tremendous control, it’s wise to use it in a way that can be traced and that enables straightforward troubleshooting.
As with business rules in the data, it’s recommended that structuring any conditional elements based on data be consistently and centrally located, preferably in the variables if at all possible. This enables a single location as reference when alterations are required.
A more detailed post on Cognos Report Studio variables will be best served at a future time but for now, consider two very helpful boolean variables to aid your troubleshooting and development efforts. Try assigning the following booleans to report objects to serve your troubleshooting and development needs:
Do Not Render Creating a boolean variable which will always resolve to a false condition (ex. 0=1) will provide you as a developer with a tool to selectively hide and show objects during development. Additionally, creating documentation blocks with this variable will allow unobtrusive inclusion in the design view of the report of additional context and documentation.
Render if Dev Similarly, enabling visibility of deterministic but hidden data elements, such as identifiers or switches, is useful to a developer but unsightly for the end user – even when testing. Switching them on and off can be cumbersome or worse… forgotten and left littering the report.
This technique relies on the published consumer version of the report being a view connected to an actual report being developed. Using the ReportName() function in a variable, allows a specific character string to be used in the actual report name, ex. ‘DEV’ that is omitted from the name of the view consumed by the end-user. The variable can then be defined as ReportName() CONTAINS ‘DEV’. This will resolve to TRUE when running the report directly, but FALSE when running the view by the consumer.
There are, of course, times when use of variables is simply impractical or impossible. In these cases the consistent naming and use of conditional styles is merited. A naming scheme for styles that focuses on traceability is helpful. Depending upon your application, this may mean style condition names are oriented to the query upon which they depend or to an indication of their purpose. In any case, taking the time to carefully consider the implications of maintenance, whether it is to be performed by the original developer or by others, yields time, effort and frustration saved in the longer run.
