IGI Custom Reports - Best Practice Guide

A short and sweet "quick tip" update only, I'm afraid. Anyone looking to settle down to a long read will be sorely disappointed as my time is precious and this topic doesn't deserve lengthy discussion.

Creating custom reports in IBM Security Identity Governance and Intelligence (IGI) is a multi-step process:

• Create a SQL query to extract data
• Create a "Report" to structure the data according to your needs
• Assign the "Report" to a user community

What happens if you need to update your report to include an additional data element, however? Unfortunately, IGI (as of v5.2.2) does not afford you with the luxury of updating your SQL query to grab the additional data element without deleting the report. What a pain.

My solution? Don't bother.

Well... I say don't bother. What I mean is that there is no need to update the SQL query in-situ.

A better approach might be to create a new SQL query with the additional data element, create a new report as required and associate the new report to the same user community as the old report. The old report can remain in the system although disassociating it from the user community would seem to be a reasonable final step to take.

When I create a custom report, I like to follow these steps:

• Create a SQL query to extract data and add a version number to the name, i.e. "Stephen's Query v1.0"
• Create a "Report" to structure the data according to my needs and add a version number to the name, i.e. "Stephen's Report v1.0"
• Assign the "Report" to a user community, i.e. IGI Users Called Stephen

When I need to update the report, I follow these steps:

• Create a SQL query to extract data and add a version number to the name, i.e. "Stephen's Query v1.1"
• Create a "Report" to structure the data according to my needs and add a version number to the name, i.e. "Stephen's Report v1.1"
• Assign the "Report" to a user community, i.e. IGI Users Called Stephen
• De-assign the "Old Report" from the user community

Of course, an added benefit is that it is much easier to "roll-back" to the previous version of the report if necessary and I didn't have to delete anything.

NOTE: I would frequently prefix all my custom reports with some identifier which helps me differentiate custom reports from the pre-packaged reports. For example, when providing services to ACME Inc, I may prefix all my reports with ACME and I would NEVER customise a pre-packaged report, but rather create a new custom-version of the report instead.