12

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?

Improve this question
0

10 Answers 10

Reset to default
8
+100

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

Improve this answer
3
  • Could you add some more specific details to this?
    – dunxd
    Dec 19, 2011 at 10:16
  • Done. As a warning, it can be a bit tricky to work with but you should be able to find plenty of resources on the web to get started. BDC Metaman is an app that will become quite useful if you decide to explore the option
    – Paul Lucas
    Dec 19, 2011 at 11:31
  • Sidenote: (having used both 2007 and 2010) BDC has improved a lot in SP2010 and makes connecting to external data sources so much more straightforward (including read/write).
    – Russell
    Dec 21, 2011 at 3:51
3

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.

Improve this answer
12
  • 3
    The root web application is a site collection which can have lists, libraries and subsites just like a managed path site collection. Site collections are the logical boundaries within the SharePoint infrastructure and getting data from other site collections can be a challenge. There are tools to help roll up information from various site collections, like the Lightning COnductor web part from Lightning Tools.
    – Eric Alexander
    Dec 9, 2011 at 15:46
  • 1
    Hard to say, we have almost 400 site collections in one of our web applications. The architecture of it isn't the greatest so we're bringing some sites under existing site collections, but it works for us. I always try to push organization wide information up to the top of the web application as much as possible where it can be viewed and maintained by everyone.
    – Eric Alexander
    Dec 9, 2011 at 16:20
  • 1
    The root web application is still a site collection so the same boundaries apply to sites under managed paths.
    – Eric Alexander
    Dec 13, 2011 at 14:27
  • 1
    In the broad sense yes, the web application is a container for site collections, but the root web application site is still a singular site collection, mysp.domain.com is a site collection just like mysp.domain.com/sites/asite.
    – Eric Alexander
    Dec 14, 2011 at 14:42
  • 2
    Hierarchy is nothing when it comes to site collections. Just because it's at the root of a web application doesn't mean it can allow access to other site collections in the web application. The 'apparent' hierarchy of site collections from root to managed paths is purely cosmetic, nothing else.
    – James Love
    Dec 16, 2011 at 8:09
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.

Improve this answer
2

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.

Improve this answer
2
  • That would work for displaying the lists in different places, but not for making use of list data in other lists.
    – dunxd
    Dec 20, 2011 at 10:48
  • I know that you were looking for OOB, but I have used this web part in the past. link . It is free, and allows you to hit lists that from different sites.
    – Kevin Rodgers
    Dec 20, 2011 at 14:18
2

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

Improve this answer
2
  • > make items from that list available in other lists no matter where they are in Sharepoint
    – dunxd
    Dec 20, 2011 at 10:40
  • Without managed code or a third party tool, that simple sentence in a broad context isn't possible.
    – Josey
    Dec 22, 2011 at 14:27
2

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).

Improve this answer
1
  • That is a very interesting suggestion indeed. Is it possible to store the location details in Active Directory separately from users, and then associate users with a given location? Is it then also possible to associate the location data with list items in Sharepoint (i.e. not users at all?)
    – dunxd
    Dec 21, 2011 at 11:19
1

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

Improve this answer
1

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.

Improve this answer
0

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.

Improve this answer
2
  • Could you expand on what you mean by "dedicated portal", and how the different lists can be joined using look-up columns? What you describe sounds very much like what @PirateEric suggested, and I have tried that without much success.
    – dunxd
    Dec 14, 2011 at 21:49
  • I mean a dedicated site collection.For sharing data across site collections, you can code webparts\usercontrols using SharePoint object model
    – Amit Kumawat
    Dec 16, 2011 at 15:43
0

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.

Improve this answer
1
  • Both suggestions include copying the data from one place to another - how do you reflect changes to the "master" list?
    – dunxd
    Dec 20, 2011 at 10:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.