I am not a Reporting Services guru and nor do I play one on TV. I am however forced to be all things Microsoft Data where I work. So I frequently find myself stretching way beyond my abilities. I just had to get a report running that feeds from a web service and has a recursive hiearchy with customized aggregation on multiple fields with drill down to a different set of details. Yeah, through the internet I can see the SSRS monsters rolling their eyes at the ease of this task. But for us mere mortals it was work. Since I spent so much time learning how to do it, I thought I’d share.
XML as a Source
First, because we have a very paranoid (and appropriately so) group of PeopleSoft administrators, I couldn’t get direct access to the Oracle database. Instead, they provided me with a web service. Easy enough to consume, but it comes back as XML. Good news is Reporting Services can consume XML through a URL. Bad news is that it has a sort of proprietary XQuery language that is extremely obtuse (or I find it so, but then I’ve had trouble with SQL Server’s XQuery as well).
Setting up the Data Source is extremely simple. When you select XML from the Type dialogue, it’s going to ask you for a Connection String. Supply the URL. Done.
The work comes when you need to set up the DataSet. When you set the Data Source the Query Type will change to Text. No options. And you’ll be looking at a big blank box of nothing. My initial XML data set was this stacked hiearchy that had nested departments, accurately portraying the structure of the data. To query this XML you can do one of two things, set up the XML path as described in this excellent Microsoft white paper or allow SSRS to parse the XML for you. I tried working through the path, but I kept excluding parts of the structure. Basically I needed a method to recursively union the data within XML and, frankly, that was too hard. So I tried the automatic route. What’s the query look like for the automatic route?
*
That was tough. But, the same problem occurred. According to the white paper referenced above, letting SSRS figure out how to parse the XML means it will walk through and identify the first repeating group within the XML and that will be the structure it uses for the rest of the data. So, in my example, I have Departments and Personnel. The Personnel are inside the Department and Departments are inside Departments which have other Personnel… etc. It looks something like this:
<?xml version="1.0"?> <ROOT_SEGMENT> <REPORT_TITLE>Monster Hunters Status</REPORT_TITLE> <SUMMARY> <DEPTID>997</DEPTID> <PARENT_DEPTID></PARENT_DEPTID> <DETAIL> <EMPLID>000001</EMPLID> <NAME>Shackleford, Julie</NAME> <TERMINATED>N</TERMINATED> <RETIRED>N</RETIRED> </DETAIL> <DETAIL> <EMPLID>000002</EMPLID> <NAME>Jones, Trip</NAME> <TERMINATED>Y</TERMINATED> <RETIRED>N</RETIRED> </DETAIL> <SUMMARY> <DEPTID>998</DEPTID> <PARENT_DEPTID>997</PARENT_DEPTID> <DETAIL> <EMPLID>000003</EMPLID> <NAME>Pitt, Owen</NAME> <TERMINATED>N</TERMINATED> <RETIRED>N</RETIRED> </DETAIL> <DETAIL> <EMPLID>000003</EMPLID> <NAME>Newcastle, Holly</NAME> <TERMINATED>N</TERMINATED> <RETIRED>N</RETIRED> </DETAIL> <SUMMARY> <DEPTID>342</DEPTID> <PARENT_DEPTID>998</PARENT_DEPTID> <DETAIL> <EMPLID>000022</EMPLID> <NAME>Harbinger, Earl</NAME> <TERMINATED>Y</TERMINATED> <RETIRED>Y</RETIRED> </DETAIL> </SUMMARY> </SUMMARY> </SUMMARY> </ROOT_SEGMENT>
Problem is, the first repeating group didn’t include the nesting. That was a deviation, so it didn’t read in the same way. What I had to do, in order to use the automated parsing, was flatten the structure, moving the SUMMARY areas outside of each other. With the new structure, the query returned all the data. Now the trick was to get the department hiearchy into the report
Recursive Hiearchies
Thankfully, after a bit of searching, I found this in the documentation on SSRS. It shows exactly what I needed, the, incredibly simple, method for creating a recursive hiearchy. The only trick was to have the Parent field stored with the child records. You can see that in the XML above, but the original didn’t have it. Once that modification was in place, it was simple. Follow the directions. In my case, DEPTID became the grouping field. To support other functions I also changed the name of the group so it could be referenced in functions.
Once it was created, simply going into the Advanced tab in the Row Groups property window and setting PARENT_DEPTID as the recursive parent was all that was needed.
Way too easy. But, how to get the drill down and the aggregates?
Drill Down & Aggregates
With that in place, the query will return hiearchical data, grouping on the DEPTID and keeping the parent child relationships in order. To establish drill down, it’s just a matter of going into the Row Group properties for the Department group again. In the Visibility tab, you set the visibility to Hide and check “Display can be toggled by this report item:”
Once that’s done, the recursive groups are only displayed as the little plus signs expand and contract the groups. It works great. You can even get fancy and add an indent function as shown in this bit of the documentation. But, how to do get the totals to display recursively? Not tricky at all. In fact, pretty easy. Since the data coming out has a set of flags that I have to check for positive or negative values, I have to use a expression to check them anyway. Something like this:
=Sum(CInt(IIf(Fields!HIRE_FLG.Value.Equals(
</font></span><span style="color: #a31515; font-size: x-small;"><span style="color: #a31515; font-size: x-small;">"Y"</span></span><span style="font-size: x-small;">),1,0))</span><span style="font-size: x-small;">)
Luckily, built right into the function is a method to make it work recursively, so that you get totals of the children displayed with the parent. All that’s necessary is to supply the group, which I named earlier, Department, and tell it to total this stuff in a recursive manner, like this: [sourcode language="TSQL"]=Sum(CInt(IIf(Fields!Terminated.Value.Equals(
“Y”),1,0)),“Department”,Recursive)[/sourcecode]
Put one of these with the appropirate field and you have a nice neat report.
Conclusion
To finish up, none of this is rocket science. It’s just a question of knowing where to go and how to put it all together. Being a newb when it comes to Reporting Services, I spent a lot of time struggling. Now, you won’t have to.
