As we all know in Office 365 developers are bound to the Sandbox which is limited to his own Site Collection. The information living in other Site Collection is hard to get from code. Even with ECMA script the possibilities are very limited too. With an on premise SharePoint 2010 farm the first thing that comes to mind when talking about cross site aggregation is Search. Luckily the possibilities to use Search over Site Collections is present in Office 365.
Note: You’ll need an Office 365 Enterprise License to be able to use Search the way I described.
Sandboxed definitions
Because sandbox development in Office 365 is very limited, the best way to use the sandbox is to deploy custom templates or definition in your Site Collection. For this solution I’ve created a List Definition for a specific type of information: A news article. Why would I create a definition for this and not just add some columns to a generic list with the UI? Well that becomes clear in a sec.
Just for this example I did a simple definition by using the default SPI for a List Definition in Visual Studio.
ArticleList is the Definition and Articles is a default Instance. Visual Studio starts with ID 10000 for Definitions or Templates. The ID of the Definition is important in this solution. This Solution needs to be deployed to all Site Collections from which we will aggregate articles.
Site Collection 1 Site Collection 2
Search
To aggregate all the articles we use the Office 365 Search with the All Sites scope. By Default the Search with the All Sites scope will take you to a search center with a results page which is located on the “root” Site Collection of the Office 365 server your environment is on. When using scope This Site you will land on the default /_layouts/OSSSearchResults.aspx page.
However we are free to use the OOB Search Web Parts on any page in Office 365. The one we need to use is the Core Results Web Part. There are a few settings we need to change:
Besides the use of the All Sites scope it’s important to set a fixed query for all articles. By Default a SharePoint Search Result contains an element <contentclass/>. This is the property we will use to aggregate all results with this query: contentclass:STS_ListItem_10000. The 10000 is the ID of the List Definition for our ArticleList.
Results
As we can see in the screenshot our articles are stored on different Site Collections (/sites/Aggregatie & /sites/RC). If you’re into XSLT you can change the Web Parts XSLT to reformat the results the way you want.
Reusability
By saving all the settings for the Web Part and doing an export / import, the Web Part becomes a very reusable component which can be uploaded to all Site Collections it’s needed. U can also change the view of the results by modifying the XSLT for the results.
Doing aggregation with (mostly) default SharePoint components in Office 365 is very powerful. No Sandbox Code or Client Object Model Code is needed. It’s more flexible and easy to use. Aggregation by Content Type is also a good way to get the information you need. However Content Type is not a property which is passed into the Search Results. It is possible to create a managed property for Content Type and pass it into the Core Results so that can be used.