Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I'm starting a new SharePoint 2010 web content management project where a portion of the site's content is driven by an external system (SQL Server based). Think employee bios... The external system is the system of record for this data, we need to expose it (read only) in publishing pages on the site - for each record, we want to create a publishing page.

I've done some research but haven't come across examples of using BCS and ECTs in publishing sites. Considering this approach and hoping to get some feedback on it from the community:

  • Create External Content Type to represent the data in the external system
  • Use an item event receiver to create a publishing page for new records
  • The item event receiver might also update a term store for tagging use elsewhere
  • The publishing page layout would be based on the external content type

I'm concerned that one ore more of the above things might not even be possible with External Content Types - or have serious limitations.

Would appreciate any thoughts on this approach vs. directly accessing SQL from web parts on a publishing page based on a query string parameter.

Thank you

share|improve this question
    
George, it is not possible to use event receivers (or workflows) with ECTs –  Matt Taylor Apr 26 '11 at 8:35
add comment

1 Answer

up vote 2 down vote accepted

The use of BCS for external content types and lists is more suitable for surfacing external data in a familiar format that business users can consume - a SharePoint List. I don't see much of an advantage using it the way you are suggesting.

Have you considered using BCS to augment user profiles to pull in the bio information as a mapped property? This would provide the information as part of the native User Profile, and you could easily access it with the SharePoint object model from a custom web part to render a custom profile page.

3 approaches I might consider taking would be:

a) - Use BCS to import the SQL data as a mapped property into User Profiles - Create a custom search page to render the User Profile/Bio using XSL with a query parameter

a) - Use BCS to import the SQL data as a mapped property into User Profiles - Use a query-parameter driven page with custom web parts that read and present the User Bio

c) - Wrap the custom user profile data in a RESTful Web Service - Use a query-parameter driven DFWP with the XmlDataSource and XSL to render the content

I lean towards a) because it is leveraging native features of the SharePoint platform the way they were designed to be used. Augmenting User Profiles with BCS allows them to surface through People Search, and search pages can be customized without have to resort to custom code with web part configuration and XSL.

share|improve this answer
    
I think Chris is definitely heading in the right direction here although I'm not clear if this is a public site with anonymous users. If so I would set up a proof of concept to test anonymous user access to user profile information (never needed to do it so don't know if it is possible or requires extra configuration). Otherwise, just use a simple ECT exposing all the bio information but the important point that Chris makes is leveraging search to minimise/exclude custom development. –  Matt Taylor Apr 26 '11 at 8:42
    
Thanks for your responses. This will be an anonymously accessible public website. I used user profile data as an example, but the external data source will contain other data that we want to create publishing pages based on. So the pattern we end up using should apply to the different types of data. The web service idea appears to be the most promising, I think the key difference here is that you end up with a single query-driven page vs. multiple pages. Need to look at what implications this has for search. thank you –  George Durzi Apr 26 '11 at 11:12
    
Here's the approach I ended up going with. I created two content types, one to sit behind a "backing list", and another based on Page. They're essentially the same content type, but one is a publishing content type. I created a list based on my backing content type and attached an item event receiver to it. In the events, I did CRUD operations on Publishing pages based on the publishing version of the content type. –  George Durzi May 23 '11 at 11:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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