The last couple of days have been crazy here at SPC. The excitement for Office and SharePoint 2010 has continued to swell. I’ve had the opportunity to meet with lots of customers here and actually got a chance to see Huey Lewis and the News on Tuesday night. That was a little bit of a blast from the past!
Yesterday, I gave a session on the Business Connectivity Services (BCS)—the session was entitled Creating Office Business Applications with Business Connectivity Services. It was a 300-level code heavy session that showed developers how they could take the BCS from the server offline to the client and begin to code against it using the BCS.
If you think about the idea of an OBA being the ability to integrate SharePoint and/or Office to LOB systems, the BCS represents another way to connect your data. However, there are some great advantages to the BCS.
1. It is read/write (where its predecessor the BDC was read-only).
2. It provides the ability to work with data from both the server and the client.
3. You can work with the data on the client offline without the need to have connectivity with the server.
4. There is a rich OM that enables you to program against that data on the server and on the client.
Below is a diagram that shows you how the BCS fits into the OBA architecture.
If we take the BCS part of this diagram and drill into it, you can see that there’s quite a bit going on. For example, the below diagram shows that you’ve got something called an External Content Type (ECT) on the server—this is the successor to the BDC’s application definition file but provides CRUD operations. You’ll also see that you can create an External List (a SharePoint list that provides read/write capabilities into your external data source) and then take it offline (which uses ClickOnce deployment to the client). The offline story is a cache of the data you take offline with the ability to code against that cache coming from the Office installation (i.e. the BCS runtime). And lastly, there is a mechanism that polls and queues the changes you make on the client and then updates those changes to the server. This is very cool stuff because you can create the ECT using SharePoint Designer 2010 or VS 2010 and then map it to a service end-point, hence you can consume WCF, ASP.NET, Azure, and of course ADO.NET service or classic endpoints.
I’ve posted my deck from the session here: http://cid-40a717fc7fcd7e40.skydrive.live.com/browse.aspx/BCS%5E_SPC. I’m also going to clean up the code and post it here later in the week.
After I presented, I took a number of questions and the audience asked me to post one thing and that was a small tip to include a “?wsdl” when creating the ECT. For example, when you create your service, you will have a service endpoint that you’ll need to configure in SharePoint Designer. You configure it by clicking External Content Types and then External Content Type to create a new ECT-see below.
However, once you’ve created a new ECT you can add a new connection, you need to specify the WCF as your service configuration (applies to all types of services, e.g. ASP.NET and WCF). If you enter the Service Metadata URL as in the below figure you’ll get an error; you need to add a “?wsdl” after the service URL and that will configure properly. For example, for the Service Metadata URL you might enter something like http://fabrikamhockey:1190/Service.asmx?wsdl, and for the Service Endpoint URL, you’d enter http://fabrikamhockey:1190/Service.asmx.
I’ll talk more about the BCS in upcoming posts. There’s a wealth of information and very cool things within the BCS, and it takes OBAs to the next level. I’m pumped about the BCS, and I know that when you all get availability to the bits you’re going to love this new feature of SharePoint and Office.