Introducing Microsoft SharePoint 2010 Business Connectivity Services
- 6/15/2012
Connecting to Business Applications
The Business Connectivity Services (BCS) data connectivity layer, known as the Business Data Connectivity (BDC), uses connectors to access the external systems. The built-in connectors allow you to connect to databases, cloud-based services, Windows Communication Foundation (WCF) endpoints, and web services, as well as provide you with the ability to create new connectors, such as .NET assembly and custom connectors. These two connectors are created using Visual Studio. The .NET assembly connector is typically developed internally in an organization and allows a developer complete control over the operations with the external system with the code the developer writes. Custom connectors are typically developed by third-party companies so that the purchasers of the third-party solution can integrate the solution with a SharePoint installation.
Once SharePoint knows how to connect to an external system, then depending on the operations SharePoint is allowed, it can retrieve, modify, and create external data. An improvement in SharePoint 2010 is the introduction of batch and bulk operations for retrieving external data. When multiple documents are retrieved, it is also possible to retrieve the documents in chunks, which reduces the number of round-trips to retrieve the data.
The connection and data operation details are stored in the BDC metadata store, also known as the BCS database. In this database, SharePoint stores and secures external content type (ECT) and related objects defined in the BDC model, so this database is also known as the ECT repository. This database does not contain external data; it contains only information about the external system. The metadata store is accessed by the Administration and Runtime interfaces, as shown in Figure 2-4, which are discussed in more detail in the following sections.
)
Figure 2-4 External data can be accessed either from an Office client application or using SharePoint.
BDC Administration
The Business Data Connectivity (BDC) interface creates, reads, updates, and deletes objects within the metadata store. All of the SharePoint 2010 built-in features use this interface. For example, when you use the SharePoint 2010 Central Administration website, the BCS administration webpages use the BDC interface to import the model, as does the external data picker in any of the business data Web Parts.
On a server hosting the BDC service application, the BDC layer stores in memory (caches) all the BDC model information, so most of the time a call to the administration interface will result in manipulating objects from the cache instead of making round trips to the SQL Server to access the ECT repository. If the BDC sees a change to one of the BDC model objects, it clears and then loads the cache.
BDC Runtime
This layer is used to create, update, display, and edit the external content. External content is not saved in the ECT repository but is retrieved by the BDC server runtime using bulk load routines when the content is needed.
For example, if a user clicks a link for an external list, the BDC runtime is used to populate the default view of the external list. However, before the BDC runtime can populate the default view, it must first call the BDC Administration interface to find the location and format of the data from the BDC model, so that it can call the appropriate connector, which is the component that obtains the external data. This process causes network traffic between the web server and the servers that host the BDC service application. Examples of the built-in features that use the BDC runtime are external lists, business data Web Parts, the Retrieve data link, and the refresh icon in the external data column of a list or library.
The Office applications include a symmetrical BDC runtime to the BDC runtime that runs on the server. The BDC runtime, whether it is on the client or SharePoint 2010, uses the same connectors, so the client does not need to connect back to SharePoint to access the external data.
The BDC runtime provides an intuitive, “stereotypical,” consistent object model, independent of the external system. Developers need to understand only the BDC Object Model to extract data from the external systems, whether they are developing code for the client or the server.
The BDC runtime consists of an infrastructure component to provide runtime connection management and shared security services to the external systems. Access to the external systems is the responsibility of the BDC connectors.
External Content Types
External content types (ECTs) are a new concept in SharePoint 2010 and are the building blocks of BCS, similar to the entity object in SharePoint Server 2007. ECTs refer to external data objects and define the fields, methods, and behavior of the data in SharePoint and Office client applications. Both read and write capabilities are included, along with batch and bulk operation support. ECTs are defined in the BDC model. The data objects defined by the ECTs can be displayed on SharePoint 2010 sites using Web Parts, external columns in lists, and libraries. Also, as the data objects are similar to content types, you can use them to create a specialized list, such as an external list, or in Office 2010 applications where ECTs are the framework for creating Office Business Applications (OBAs).
BCS Security
To create, modify, or delete the BDC model, or to access the data from the external systems, you will need to plan and consider security requirements. The security requirements of the external systems will usually be outside your control. Many of the external systems will have been installed in your organization before the installation of SharePoint, probably many years before SharePoint was even considered by your organization. You will need to work closely with the external system owners, and with your organization’s security experts if you are in a highly regulated industry, as you develop SharePoint composite solutions.
Security requirements can be divided into two types: authentication and authorization. Authentication involves some type of system that provides a mechanism such that users can prove their identity. An authentication mechanism commonly used by large organizations is Windows authentication, where users are provided with a user name and a password. This approach could be augmented with advanced techniques, such as smart cards or fingerprint recognition. Windows authentication involves the installation of Active Directory (AD) within your organization and servers (domain controllers) whose role is to take requests from other servers in your organization to check that a user’s credentials are valid. Once the requesting servers have received positive notification from a domain controller concerning the user’s credentials, then the requesting server can authorize the user to perform actions based on the permissions granted to the user (authorization).
Authentication
A BCS solution involves a number of systems and each system has its own authentication method. A solution typically involves an end-user device, such as a laptop, desktop computer, mobile phone, or tablet, and on that device an application will run, such as a mobile phone application, an Office application, or a browser. A BCS SharePoint solution involves a SharePoint farm as well as the external system. Each one of these systems—end-user device, SharePoint, and the external system—will be able to use a number of authentication methods, such as Windows authentication, SAML token, or Windows Live ID.
In an ideal world, once a user has signed on to their device, there should be no need to have the user authenticate again. Such an environment, in which a user need only authenticate once no matter how many systems the user’s application has to request information from, is known as single sign-on. Although over the years the authentication process has become increasingly transparent to the end user, it still doesn’t happen by magic. In most BCS solutions, you will have work to do. If not you, then someone in your organization will need to understand the authentication methods.
For example, in an organization that hosts its own AD and SharePoint farm, the credentials that a user logs on to their computer with are used to authenticate with the web server—this is called Windows authentication. SharePoint, using the authorization settings for the user (for example, the site permission settings), allows the user to complete certain operations. In this scenario, the two systems involved—the user’s computer and the SharePoint web server—share the same authentication method, and there is just one hop from the user’s computer to the SharePoint server.
With a BCS solution, in the same scenario three systems are involved, as shown in Figure 2-5: the user’s computer, the SharePoint web server, and the external system.
)
Figure 2-5 Displaying data from an external system requires two-hop authentication.
Even if the external system shares the same authentication method as the end-user device and SharePoint, when you try to pass a user’s Windows authentication identification on to the external system, doing so will always incur a double hop: one hop from the client’s computer to the SharePoint server, and a second hop from the SharePoint server to the external system. Unless SharePoint 2010 and the external system are installed on the same server, the user’s credentials will not be successfully passed on to the external system. This is known as the double-hop issue.
The workaround to the double-hop issue, where you want to use Windows authentication both for the SharePoint site and the external system, is to use Kerberos or an SSS service application.
The SSS service application is available with SharePoint Server 2010 and can be used with BCS to authenticate users with external systems. It supports access to external data by allowing you to map the credentials of SharePoint users or groups to external system credentials. The SSS application has its own database where the user credentials are encrypted.
Authorization
There are at least three levels of authorization with a SharePoint-based BCS solution:
SharePoint permissions Sites are organized into site collections, and a site collection is a security boundary—that is, the top-level site of a site collection starts with its own unique security settings. When you create sites, by default they inherit the permissions of their parent site, which then percolates down to all lists, libraries, list items, and files within that site. When you create a page to display external data or when you create an external list, SharePoint permissions are used to control who can see that page or list. You can break the inheritance on your site so that pages and lists can have their own unique permission settings.
BCS service application permissions Since any BDC model could be extensively used through your SharePoint installation and could be a critical component to the day-to-day working of your organization, there is a mechanism to guard against accidental or malicious modifications to the model. The BDC service application also allows you to specify who can use the definitions to access the external data that the BDC model describes.
External system authorization Most external systems have their own authorization settings determining who can see the data as well as who can view, create, manipulate, or delete the data.
When you create a SharePoint page to display or modify external data, the user experience will be a combination of these three levels of authorization. The user must have SharePoint permissions to the library where the page is stored. The user must have BCS model permissions for SharePoint to read the external system connection details and ECT information. Then the external system must allow the data to be retrieved for that user.
Also, once a BDC model is created, then the visibility of the external data is not limited to a single site. You can set permissions on the BDC model so that only a subset of users can see it, and those users may be site owners or list owners on other sites. However, without a full understanding of how you set up the authorization permissions, the users may decide to create solutions to use the data on their sites or within their lists with unexpected results. Other users on these sites may not have permissions to see the external data because of authorization settings at the BCS service application level or within the external system. These users on other sites may be presented with an error message, and then they might phone the help desk for support. Therefore, it is important to understand the security implications of your solution, not just on the site where you plan to create external lists and business dashboards, but also throughout all the web applications associated with the BCS service application where your model is stored.
Taking External Data Offline
When connecting an external list to Outlook 2010 and SharePoint Workspace 2010, you may notice that you can take the external data offline. However, to take the external data offline, additional logic is required. This logic is provided by a Visual Studio Tools for Office (VSTO) ClickOnce deployment package, which is provided only in the Enterprise edition of SharePoint Server 2010. In SharePoint Foundation or the Standard version of SharePoint Server 2010, you cannot take external list data offline in Outlook 2010 or SharePoint Workspace 2010 unless you write your own code.