Sharing data between multiple site collections

Question

We currently have no central records for the addresses of our offices around the world in SharePoint. Different teams maintain their own address lists, and a search for an address may return various different results as each team may not have up to date records.

This seems pretty dumb, and SharePoint Office Server 2007 seems like it should be able to centralize this sort of information, and make it available across the whole SharePoint estate.

It is easy enough to set up a list somewhere. However, the next step would be to make items from that list available in other lists no matter where they are in SharePoint. For example, our network team might want to associate a bit of network equipment with the office where that equipment sits. They have a list of network equipment, I have a list of offices - can their list have a column from which the offices can be selected (and then linked to)? Kind of like linking database tables.

Are there any out of the box features of SharePoint Office Server 2007 Enterprise which will help me achieve this?

Answer 1

Have you taken a look at the business data catalog (BDC) on moss 2007?

The BDC (renamed Business Connectivity Services in SP2010) is an out of box feature enabling external business data (in your case a list of offices) to be surfaced within SharePoint site collections without writing any code.

It may not be the perfect fit for your requirements, since if you actually want to store the list of offices within SharePoint itself, you may need to write something to get the data moulded into a shape that the BDC likes, but it's probably worth playing around with to get a better idea of its functionality ( +/- quirks etc ;-)

http://msdn.microsoft.com/en-us/library/ms563661(v=office.12).aspx

Answer 2

It would make sense to logically store the data in a root web application where everyone might have access to update the information. With some metadata and various views, you can slice and dice the information very easily for teams to digest.

To consume the information in other places, you can use page viewer web parts or use data view web parts to pull in the data.

Another possibility would be to have a core master list of basic information at a root level. Then create secondary lists specifically for individual teams that need to extend that information. Those secondary lists could use lookup columns to reference data to create relationships. With Data view web parts, you'd be able to insert joined subviews so you'd be able to see the basic data for a user, then see inventory assigned to the user for example.

Answer 3

Lookup columns do not work across site collection boundaries. This is by design and makes good sense considering that site collections can be placed in different content databases.

I can see two possible strategies to tackle your problem:

1. Replicate data across site collections
2. Keep data in one place and 'reference' data across site collections

I am sure there are many solutions for both strategies. So please do not regard the following examples as a complete list of possibilities.

Replicate data

You create a SharePoint list with the offices of your company, let's say in the root site collection of your SharePoint farm. You add a guid field to the offices list so that you have a unique and independent identifier for each entry in the list. You create an ItemAdded, ItemUpdated and ItemDeleted event receiver on that list to replicate these changes to 'consumer' lists in other site collections. In the 'consumer' site collections you can use standard SharePoint lookup columns within these site collections to reference data from the offices list.

An available solution for data replication might be this component (sync root list to a table in database and hook up 'consumer' lists to that table): http://www.layer2.de/en/products/Pages/SharePoint-Business-Data-List-Connector.aspx

Reference data

You can create a custom lookup field that can be used across site collections. In the lists in the 'consumer' site collection you use this field type to reference information from the offices list in the root site collection directly. You will definetly have to solve the issue how to update the referenced data, because your custom field will have to store a copy of the selected value (e.g. address) when the list item is created in the 'consumer' site collection.

An existing 3rd party solution for this could be the Cross-site lookup from SharePointBoost.

Update:

An OOTB approach to replicate the data could be to use the above mentioned Business Data List Connector component from Layer2 and hook that up to the RSS feed (feed.aspx) of the root list. The Layer2 component can consume XML files and the feed.aspx can be customized with an XSLT for the purpose.

Answer 4

If you are using kerberos you may be able to get away with using an RSS Reader web part. Since the part only allows one source per part it might take a few on a page to display all of your lists, but you could remove the chrome so that they all looked like they were one. It isn't elegant, but it could work.

Also if you are not using kerberos, I've used a couple of free rss reader solutions that can do it without running into the authentication problems of the out of the box version with NTLM.

Answer 5

The question is, are you working across sites, or site collections?

Across sites is easy, use a single list on the root with a cross site enabled data view web part on the sites you want to display it on. (there is a trick to this I can share if this is your situation).

Going across site collections will require custom code using visual studio. To do this, follow this link: http://blogs.msdn.com/b/ramg/archive/2009/04/22/implementing-a-simple-cross-site-collection-list-view-webpart.aspx

Answer 6

Taking one step back, you could add a property to Active Directory which includes location information. User profiles can bring this information into SharePoint and others in the organisation can use the AD locations to associate with other records. This allows a central storage of locations in a central service (Active Directory).

Answer 7

I don't think there is an OOB solution to this common problem in SharePoint 2007. There are many third party packages available for purchase which may help.

SharePoint 2010, however, has a new feature called Metadata Management which could be used to solve for your cross site collection requirement.

http://blogs.msdn.com/b/ecm/archive/2010/06/22/introducing-enterprise-metadata-management.aspx

Greg

Answer 8

Maybe you could make use of an infopath form and form web part with an office field that the user can type in to search, if you don't need them to be able to browse all the data. I do this for one of my business scenarios where I have an entering student SP page that shows the student all the requirements they need to fill out and their status on each. Each requirement lives in the appropriate department site list, library, form library and I'm just querying it via my data connections. Mine doesn't require they type in who they are, it fetches data based on the user logged in dynamically but you could do the same with an input field.

Answer 9

A good solution is to create a dedicated portal for this requirement. The different kind of lists can be joined using look-up columns(In SharePoint 2010, its even better as referential integrity is supported).

You should not keep related lists dispersed in separate site collection as it will be difficult for maintenance.If this is something you cannot avoid, the information can be shared across lists in different site collection by coding custom webpart\controls as per your requirement.

Answer 10

Got the following solutions by googling.

1. Use Content deployment in central administration-> operations. The following link has details about content deployment, please take reference: http://technet.microsoft.com/en-us/library/cc263428.aspx

2. Use SPList and SPListItem class in Object Model to copy the shared data from source site collection to the destination site
   collection.