Before looking into what’s new in BCS for SharePoint 2013, let’s do a quick level-set on the external content type (ECT), a key component in Business Connectivity Services. The ECT is metadata that describes the connection information, methods (create, read, update, delete) that can be performed against the connection, data definitions for data elements, and any parameters that might pass between the client and external LOB data source. Security permissions can be set on the ECT to allow access by specific users or groups, and a wide array of authentication methods are supported, including Windows, claims-based, username and password, and certificate. ECTs serve as the basis for external lists. Unlike other lists in SharePoint that have their data stored in the SharePoint content database, external lists retrieve their data from the LOB data source every time the list is accessed by a user or programmatically. Therefore, external lists bring real-time data to SharePoint stakeholders. ECTs can also be made available to SharePoint search for indexing, and the LOB system data is included in a user’s search result, trimmed by permissions.
A significant benefit of BCS is that it can provide a central location where IT manages a consistent approach for accessing LOB systems. By investing in building ECTs on a common infrastructure that surfaces LOB information in a usable and reusable form, business users, power users, and developers alike can become consumers of data served up by the ECTs in a variety of contexts. These range from configuring a dashboard of business data Web parts on a page, to configuring document templates for Word to include business data columns, to developers building custom enterprise solutions. Also, the developer’s’ programming pattern is consistent when building against ECTs because no matter what the LOB system is, they code exactly the same way against the ECT to retrieve or update the data. Because IT also builds the ECTs, it can ensure the efficiency of the ECT by defining the filters and throttling limits on the accesses to the back-end systems.
External content types were broadly welcomed in SharePoint 2010, and Microsoft built on the ECT foundation in SharePoint 2013 by providing new capabilities. Figure 13-1 shows the various BCS components and highlights the primary Microsoft BCS investments in this release.
In the connector framework, alongside the already-popular SQL, WCF, and .NET connectors, the new highly requested OData connector joins the ranks. With the proliferation of OData producers, services that expose their data using the OData protocol, this new class of data services is now available for your BCS solutions.
With the new app model for SharePoint, where apps have a particular scope upon install into SharePoint, BCS now has app-scoped ECTs, too. In other words, an ECT can be created for and deployed within the scope of the app upon install. Typically, where an ECT has a farm-level, on-premises, or tenant-wide scope in Office 365, your app for SharePoint can have ECTs in your solution that run isolated within the app boundaries.
Another much-desired capability for BCS external lists was to have REST support for accessing them. This feature, too, was a significant investment by Microsoft to make the BCS data available via REST, but it has done so while also making meaningful contributions in the CSOM for accessing BCS data.
Microsoft also made significant investments in this release to support alerts and event receivers on external lists; both highly requested features by users and developers. Users can now create alerts in external lists in the same way they do on other SharePoint lists. Event receivers have been available on SharePoint artifacts for some time, but now BCS is a first-class citizen in the event infrastructure. For SharePoint to be notified that data has changed on an external list, configuration both on SharePoint and the external data source is required. The data source needs a way to become aware of underlying data changes; for example, SQL triggers or a service that periodically polls the data source to detect changes. It also needs a way for SharePoint to subscribe to it to receive notification of changes. SharePoint now has the infrastructure to support this interaction and provides a way to register this “notification channel” through an extension to the BDC model schema to include the new EventSubscriber and EventUnsubscriber stereotypes. At a high level, the communication flow for SharePoint to subscribe to be notified when there is a data change on the external system works like this: when the Subscribe method is called on the ECT associated with an external system, the Subscribe method passes the event type and delivery address to the external system. The external system records this information in a database and then returns a subscription ID to SharePoint. When the Subscribe method completes, notification of a data change can be sent from the external system to the delivery address REST endpoint on SharePoint. Receipt of the notification, in turn, fires an event on the external list and calls into your remote event receiver. Please refer to MSDN for full documentation on this subject.
Of the numerous Microsoft investments for BCS in 2013, let’s first take a look at setting up an ECT that connects to an OData service. You will use Office 365 SharePoint Online in this Try It Out since it supports Business Connectivity Services.
If you navigate to the Employee.bdcm provided in the code sample download for this chapter and open it in Notepad or any XML editor, you can view the XML document structure. Following are a few of the high-level elements with which you should be familiar: