November, 2011

Microsoft Business Connectivity Services (BCS) enables users to read and write data from external systems—through Web services, databases, and Microsoft .NET Framework assemblies—from within Microsoft SharePoint 2010 and Microsoft Office 2010 applications. Both SharePoint 2010 and Office 2010 applications have product features that can use external data directly, both online and offline. Developers can gain access to a rich set of features and rapidly build solutions by using familiar tools such as Microsoft Visual Studio 2010 and Microsoft SharePoint Designer 2010. This diagram shows the relationship between all of the components that make up BCS or that interact with the services BCS provides.

Managed metadata is a hierarchical collection of centrally managed terms that you can define and then use as attributes for items in Microsoft SharePoint Server 2010. Managed terms can act as sources of data for columns in libraries or lists. To manage the taxonomy column by using the server object model, there are APIs available under the Microsoft.SharePoint.Taxonomy namespace. However, handling managed metadata columns by using the client object model requires a different strategy. Managed Metadata Columns To work with managed metadata columns by using the SharePoint client object model, it helps to have an understanding of how managed metadata columns store values in lists. Consider the following details: Managed Metadata Columns are Derived from SPFieldLookup TaxonomyFieldValue has a WSS identifier that is the LookupId property of the term in the TaxonomyHiddenList list. The TaxonomyHiddenList list can be viewed by navigating to /Lists/TaxonomyHiddenList/AllItems.aspx . This list contains...

In this fifth article of our SharePoint Continuous Integration series, we will look at how to implement automated WSP deployment as part of a Team Foundation Server (TFS) build. We have dealt with most prerequisites in our earlier articles, but since we still have one outstanding prerequisite to cover, this article is split into two sections: Configuring PowerShell remoting Deploying WSPs as part of the build process Additionally, we are also introducing a SharePoint/TFS Continuous Integration Starter Pack – this is a Codeplex project which contains the TFS workflows and PowerShell deployment scripts referenced in this article. Configuring PowerShell Remoting Once you have automated the build of the assemblies and WSP packages using TFS Build, most likely you’ll want to deploy the WSPs to a SharePoint environment to test them. Unless SharePoint 2010 is installed on the TFS build server(s) (a configuration rarely recommended for several reasons, not least...

The request batching process helps to improve performance and reduce network traffic in two ways. First, fewer Web service calls occur between the client and the SharePoint server, which reduces the "chattiness" of the client-server interface. For example, you can perform two list queries in a single request. Second, as a set of operations occur on the server in a single request, the data being acted on doesn't need to be moved between the client and the server for the intermediate operations—only the list of operations and the final result set are passed between the client and the server. Request batching requires a different mindset when you create queries from client-side code. First, be aware that you do not have access to any results until you call ExecuteQueryAsync (or ExecuteQuery ) and receive the call back with the results. If you need to implement conditional logic in the client-side code that can't be expressed in the command list that you send to the server, you will...