A year and a half ago, I introduced an upgraded version of xmlRSDocs, explaining that, basically, I couldn’t live without better dependency support for report-embedded-sql to handle the hundreds of handed-down RDLs in my new job’s environment.
At that time, my main concern was to find out “what reports are dependent on what tables, views, and other semantic entities?”.
This is a question that you db folks are accustomed to getting by right-clicking in Management Studio, but of course that only gives you information about code contained in the same database, and certainly not code contained in reports.
Before I continue, I see that my post mentioned the new samples I provided, which actually answer that question for reports, using xmlRSDocs data:
In this delivery, I’ve included a bare-bones-but-usable RDL and some fancy parsing to support it, so that the “export” provides a list of all the entities and procedures on which the RDLs you’ve documented depend. Of course, you can still use any RDL you choose, and do much more exciting things if you need them, you can still create any schema you like for your xmlRSDocs database, etc, but this is a pretty good base.
… but I see that my post wasn’t specific about how you could find those new samples. So let me just note explicitly: they’re under the “Additional Samples” folder in the downloads zip file. Look for the xmlRSDocsEntityReport.rdl report and the special function it invokes, udf_xmlRSDocs_GetCommandTextEntityList.sql, which does the “fancy parsing” I was talking about.
This is not a drill, er, demo
Running xmlRSDocs’s ReportServer-reporting DTSX regularly is absolutely a real requirement for me. I rely on the information from xmlRSDocs to answer many IT and user questions about our reports, combined with a thorough understanding of the report execution logs. (We cache and parse the logs to update other enterprise applications for a variety of purposes — but that’s another blog topic.) I don’t know what I’d do without it.
But wait, there’s more
Recently I realized that xmlRSDocs couldn’t help me with another dependency question: what URLs are linked to from within reports? This is important to know if, as now, you are changing versions of a vendor-supplied app to which you know you’ve linked within many reports, and you’re deeply suspicious about the way the new version of the app will support the links you’ve used.
We try to make it easy to find such dependencies using parameters to hold the link strings, and by naming those parameters in a consistent way. If this convention is followed, xmlRSDocs’s default xslt will let you find all such parameter values quite easily. However… not everybody follows the convention… and other hyperlinks in reports won’t be added to your xmlRSDocs table unless you’ve marked the placeholder, textbox, or image with the hyperlink as requiring “verbose” treatment.
Remember: the default xslt is just a default. It does what I want it to do, which may not be what you need… but by default I don’t want to list every attribute of every textbox in every report, so the default xslt doesn’t do that.
In this case (duh!) we couldn’t go back into the reports and mark the relevant items with hyperlinks as “verbose” after-the-fact. We were trying to find where they were, we didn’t know.
So, I just upgraded the 2008 RDL-schema-version of the XSLT to report on any clickable actions (hyperlink, bookmark, or drilldown, which seemed just as valuable) in a specially verbose mode, even though the textbox or whatever itself didn’t require other verbosity or mention in the output. It just seemed like a reasonable thing to do.
Yes, I didn’t do the 2005 RDL-schema-version of the XSLT. Yet. It’s a trivial change, you can do it based on my 2008-schema-version. Neither have I done a 2012 RDL-schema-version. Yet. When I need to, I will — or you can!
Come and get it
Today, I’ve updated the full XMLRSDocs zip file. I’ve also provided the upgraded XSLT as a separately-downloadable file. See our downloads page, for full information.
Happy documenting!