This project has moved and is read-only. For the latest updates, please go here.

Web services as replacement for CrossList rollup

Mar 17, 2012 at 2:31 AM

I am used to creating rollups with Data View Web Parts (CrossList mode). It works fine, but it's a little bit heavy to manage (need to deal with code full of < and > in SharePoint Designer).

I was thinking about replacing this technique with Web services. The idea would be:

1. Go to each subsite to collect list information

2. Retrieve list items for each list

3. Create a single view that aggregates all the items

The idea would be to apply this technique when the number of lists is not too big - let's say between 5 and 20. I'd be interested to know if somebody has tried this before, and what would be the caveats.



Mar 17, 2012 at 5:26 AM

The one immediate tradeoff that sticks out in my head would be XSLT Caching that you get from a DVWP.  In my opinion, you are definitely going to have a performance tradeoff, just depends if it's drastic enough for your end-users to notice.




Mar 19, 2012 at 3:49 PM


While it might make some sense in some cases to use the Web Services to roll up content, I think in general you'd be asking the client side to do far too mauch work. Under the covers, the Crosslist mode seems to be far more intelligent about gathering content across lists. Lists aren't actually "in" a site; they are in the database tables. Crosslist mode is efficient at pulling the content because of this.

IMO, you'd be writing a lot of script, too, which may well obviate the benefit over the "heavy to manage" DVWP apprach. You're only seeing the encoding iin the selectcommand, right? By setting your filters with the dialogs before switching to Crosslist mode, you don't ever really need to touch that encoded CAML if you don't want to.


Mar 19, 2012 at 6:16 PM

Thanks for the replies!

Matt, I followed your link, but I am not sure where to look. In the case of crosslist query, I am more concerned with the query itself than caching xslt (which is just a few dozen lines of code).

Marc, thanks for the explanations, your point about database tables makes sense. And right, it's a lot of script, but the idea is that managing a script (for example changing a field name) is easier to do for a site owner (not to mention teams who are not allowed to use SPD). Especially if you use some library that does the Web service wrapping for you ;-)

Mar 19, 2012 at 6:19 PM

Well, there's always more than one way to skin a cat, as they say. I'd still recommend caution.


Mar 20, 2012 at 7:30 PM

That's what I get for answering with one eye open... :)

I can't seem to find any great links that explain the benefits you get from XSL Caching.  I know there has to be some, but can't seem to find any *great* documentation on it.  I've definitely heard about it from various other devs, but my searches on MSDN aren't giving me anything solid to stand on.

Jun 18, 2012 at 4:59 PM

I know it's been a while but this just came up and I decided to track this down.  From the post above, this is what I was referring to:

Using the Web Services, you'll miss out on the caching optimization that has been built into SharePoint.  I decided to add another link with a bit more info as well.  Definitely something to consider when discussing the tradeoffs of front-end dev.