Question

Je commence un nouveau projet de gestion de contenu Web SharePoint 2010 où est entraîné par un système externe (sur la base SQL Server) une partie du contenu du site. Pensez bios des employés ... Le système externe est le système d'enregistrement pour ces données, nous devons l'exposer (lecture seule) dans les pages de publication sur le site -. Pour chaque enregistrement, nous voulons créer une page d'édition

Je l'ai fait des recherches, mais ne sont pas venus à travers des exemples d'utilisation BCS et dans les sites d'édition ECTs. Compte tenu de cette approche et l'espoir d'obtenir des commentaires à ce sujet de la communauté:

  • Créer un type de contenu externe pour représenter les données dans le système externe
  • Utilisez un récepteur d'événements d'élément pour créer une page pour publier de nouveaux records
  • Le récepteur d'événements d'élément peut également mettre à jour un magasin à long terme pour l'étiquetage ailleurs
  • La mise en page d'édition serait basée sur le type de contenu externe

Je crains que l'un ou plusieurs des choses ci-dessus pourrait ne pas être même possible avec des types de contenu externes - ou ont des limitations graves.

apprécieraient des réflexions sur ce rapport d'approche accéder directement à SQL à partir de pièces web sur une page d'édition basée sur un paramètre de chaîne de requête.

Merci

Était-ce utile?

La solution

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.

Licencié sous: CC-BY-SA avec attribution
Non affilié à sharepoint.stackexchange
scroll top