IBM Support

BiLog: March Madness and QBR Edit Business Rules

Technical Blog Post


BiLog: March Madness and QBR Edit Business Rules


March Madness
– two marvelous words with multiple meanings.  It may have you rooting for your favorite team in the NCAA Basketball Tournament or waiting impatiently for your iPad 3 to arrive.   It may have you joined in mass with others celebrating St Patrick’s Day, or  anxiously waiting for Spring to finally arrive.
Whatever your March Madness may involve, let's take a step back and review another March event - Pulse 2012. 

During the Reporting presentation at Pulse, we delved into the details of BIRT and Cognos reporting functionality, along with highlighting report functionality comparisons and best practices.   For BIRT, two of the newer Version 7.5 features were reviewed in detail, including QBR Edit and Email URL.  

For QBR (Query Based or Ad Hoc Reporting) Edit, in addition to detailing the functionality, key business rules were explored including:
1.    If there are future report schedules, the QBR report can not be edited.  In these cases, you would have to first delete the report schedules, edit the QBR report and then re-enter the report schedules.

2.    If the ROS has been updated since the QBR was originally created, the QBR cannot be edited.  This business rule highlights the tight dependencies QBR reports have on report object structures (ROS), as shown in the scenarios below.
image In this example, today’s date is March 19th, and a QBR report was created previously on February 2nd. 

In scenario 1, the last time the ROS was updated was January 1st – before the QBR was created – so the QBR can be edited. 

However, in scenario 2, the ROS was updated on March 1st – after the QBR was created.  Because the original ROS that the QBR was created on is no longer available  – the QBR cannot be edited. 
3.     The third business rule involves security access, and determines if the user who created the report can edit it – if other other security groups have access to it.  In this circumstance, you may or may not want users to edit QBR reports --  so a property file is enabled for you determine how to apply it in your environment.  The property setting is

  • If the property setting is yes, your users can edit the QBR regardless of what security groups have access
  • If the property setting is no, you cannot edit QBR when any security group* has access

When setting this property, remember to take into consideration if your users have granted 'Public' Security access, which enables the EVERYONE security group to execute QBR reports. 

4.  The last business rules was that any QBR report created in the 7.1x Versions, cannot be edited, when upgraded to Version 7.5
This occurs because the new 7.5 database objects enabling QBR Edit were not available when the 7.1x QBR reports were created.  These new database objects include REPORTADHOC and REPORTADHOCFIELD.

To identify the non-editable 7.1x reports, during your upgrade from 7.1x to 7.5, they will be assigned a value of 0 (No) in the REPORT.EDITENABLED field.  Any QBR report created in 7.5x will have a value of 1 (Yes) in this field.
 You can find more information on Version 7.5 QBR Reports in the V75 QBR guide accessible here, or at the Maximo Report Wiki Pages.  
....and looking forward to our MARCH MADNESS to evolve into an AMAZING APRIL!

[{"Business Unit":{"code":"BU055","label":"Cognitive Applications"},"Product":{"code":"SSLKT6","label":"IBM Maximo Asset Management"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB02","label":"AI Applications"}}]