Background
Hello, my name is Doc O'Connor and I am a Database and Virtualization Solution Architect with Quest. One of our Foglight customers had a question when they could not find a newly created report anywhere in the Foglight 5 directories. When told that the Foglight 5 reports were stored as a binary object in the Foglight database, they asked how they could get the reports out to a filesystem. There are different ways to do this if you are creating a report ad hoc, but what if you want all the reports sent to a filesystem where others can get to them without bringing up Foglight?
On with the blog:
Have you ever created a report in Foglight and then tried to look for it within the Foglight file system? And when you got there, did you look in every possible directory, even bin where you knew it would never be, without ever finding it? Well, you are not alone. So the question is, where did my report go?
So, first of all, how do I create a report in Foglight 5? By opening the panel on the right side of your console you can see the option to create a report.
This will bring you to a page where you give the report a name and select what key input you might wish to use for the report, in this case we selected agents.
You now have the ability to drag and drop data and views into the window, thus building your report.
Secondly, where are reports stored in Foglight 5? Reports are stored as binaries in the Foglight database. So, if we want to have the report automatically placed outside of the db in a file system, we need to create an event driven rule that will make this happen whenever a report is generated.
At this point you should go look at Pontus Rydin’s blog about event driven rules located here:
There are some differences to be aware of. As in Pontus’ blog you will go to “Administration -> Rules and Notifications -> Create Rule”. The differences will be on the Rule Definition page and the Conditions page of the new rule. The event driven rule in this case (on the Rule Definition tab) needs to be off of a ReportGeneratedEvent, not AlarmSystemEvent as Pontus wrote. You can select this from the dropdown menu next to “Event Name”
For this example, we will leave the “No Scoping Query” checked, this means that we will be doing this for every report generated. The other difference is found on the condition tab of the rule. Below is the condition code that you would use, followed by an explanation of each line and its purpose.
def realReportName = @event.report.reportName
def name = @event.report.reportId
println "TEST Report Generation :"+name+” – “+realReportName+”
def fos = new FileOutputStream("C:/temp/report_"+real ReportName+"__"+name+".pdf")
fos.write(server.ReportingService.getReportData(name))
fos.close()
return false
And now let’s look at the purpose of each line:
def realReportName = @event.report.reportName
This line takes the name of the report into the realReportName variable.
def name = @event.report.reportId
This line takes the id assigned the report when generated and assigns it to the name variable.
println "TEST Report Generation :"+name+” – “+realReportName+”
This is more of a system check and is not necessary, but here is why we did it. Whenever a report is generated in Foglight the event is written to the log which shows up as TEST Report Generation. By including this line you will be able to look in the Foglight logs and see what variables were passed.
def fos = new FileOutputStream("C:/temp/report_"+real ReportName+"__"+name+".pdf")
Within the parenthesis is the destination of your report, in this case a Windows file system as denoted by the C:/temp destination. Now a question you may ask is:
“Why are there forward slashes instead of back slashes if this is a Windows destination?”
What an excellent and intelligent question! Foglight uses forward slashes regardless of the OS, so any Groovy code within a rule condition will always follow that format.
fos.write(server.ReportingService.getReportData(name))
This actually writes the report to the file defined.
fos.close()
This closes the output stream with an end-of-file.
return false
This is needed to successfully end the operation. You now have the code necessary to do this for all reports. If the need is more selective, you can use the Scoping Query to define which reports you want the rule to fire for, but that is a whole 'nuther blog!