We’re excited to announce that Penelope Coventry, Brett Lonsdale, and Phill Duffy’s Microsoft SharePoint 2010: Business Connectivity Services (ISBN: 9780735660182; 420 pages) is now available for purchase!
You can find the book’s chapter-level table of contents and Introduction to using Business Connectivity Services in this previous post.
Led by SharePoint experts Penelope Coventry, Brett Lonsdale, and Phill Duffy, you’ll learn how to access external data from several sources and make informed decisions based on what you retrieve. Unlock your enterprise data and increase your productivity, using code and no-code solutions! You’ll discover how to connect to enterprise data with Microsoft SharePoint Designer or Visual Studio; access line-of-business data, data from Microsoft SQL Server®, or data from web services; create, read, update, and delete data records using Business Connectivity Services; build external data lists through your web browser; view your data lists in SharePoint, Microsoft Word, or Microsoft Outlook; search your external data lists and work with them offline; design business solutions using SharePoint Designer list composites; and enhance user profiles or social experiences with Business Connectivity Services.
In today’s post, please enjoy reading an excerpt from Chapter 3, “Creating and Maintaining Business Data Connectivity Service Applications.”
In this chapter, you will:
· Understand the service application architecture and its effects on the deployment of Business Connectivity Services
· Understand Business Connectivity Services security options
· Create and configure a Business Data Connectivity service application
· Configure the Secure Store Service
· Use Windows PowerShell to administer a Business Data Connectivity service application
· Modify the throttling settings of Business Connectivity Services
· Administer Business Connectivity Services in a tenant environment
In SharePoint 2010, Business Connectivity Services (BCS) is managed using the Business Data Connectivity (BDC) service application, which can be shared between one or more web applications or between farms. As explained in Chapter 2, “Introducing Business Connectivity Services,” the BDC service connects the presentation layer with the external system. It uses different types of connectors depending on the interfaces supported by the external systems, together with information defined in an XML file, known as the BDC model, to read and write data to and from the external system.
The BDC shared service is built upon the Microsoft SharePoint 2010 shared service architecture, and it is available in SharePoint Foundation 2010, both the Standard and Enterprise editions of SharePoint Server 2010, and SharePoint Online. Different sets of administrators can manage the shared service architecture independently using the SharePoint 2010 Central Administration website or Windows PowerShell.
In this chapter, you will learn how SharePoint uses service applications and its effect on the deployment of BCS. You will then learn how to create and manage BDC service applications, how to configure the security options, and how to administer BCS in a tenant environment.
What Are Service Applications?
SharePoint 2010 contains a number of shared service applications, each of which function independently of each other, allowing you to install SharePoint in a service-orientated approach. These services include the following:
· Access Services
· Application Discovery and Load Balancer Service Application
· Application Registry Service
· Business Data Connectivity Service
· Excel Services
· Managed Metadata Service (MMS)
· PerformancePoint Service (PPS)
· Search Service Application (SSA)
· Secure Store Service (SSS)
· Security Token Service (STS)
· State Service
· Subscription Settings Service Application
· Usage and Health Data Collection Service
· User Profile Service (UPS)
· Visio Graphics Service
· Web Analytics Service (WAS)
· Word Automation Services
Note In SharePoint 2010, InfoPath Form Services (IFS) is not implemented as a service application. It is a farmwide component, and you cannot share it across farms or partition it, nor can you create multiple InfoPath Form Services in one farm.
Microsoft Office SharePoint Server 2007 provided some of these services, but you could not install them independently of each other. In that version, the services were grouped into Shared Service Providers (SSPs), and you were severely limited when you tried to scale or deploy complex solutions.
Not all service applications are available in all versions of SharePoint 2010. BCS and the Usage and Health Data Collection Service are the only service applications available in SharePoint Foundation 2010. Other service applications are provided by other Microsoft products, including Microsoft Office Web Apps (OWA), which enable users to access and do light editing and sharing of documents created with Microsoft Word, Excel, PowerPoint, and OneNote.
Note You will need the Application Registry Service only if you upgraded from Microsoft SharePoint Server 2007 Enterprise Edition and used Business Data Catalog.
BCS and the Service Application Architecture
You can associate service applications with one or more web applications. For example, a BDC service application can contain multiple BDC models, each defining connection and security details of several external systems. If you associate the BDC service application with the two web applications http://portal.adventure-works.com and http://marketing.adventure-works.com, as shown in Figure 3-1, all site collections within both web applications can access those definitions and present the data from those external systems, as long as the authentication and authorization requirements are met.
You can associate other service applications, such as the MMS service application, with the two web applications, making available terms from the term store and content types defined in the MMS service application.
Figure 3-1 You can share one or more service applications between web applications.
Using Multiple Service Applications
You can have multiple occurrences of a service application. For example, you can create multiple BDC service applications: one that contains the definitions for external systems associated with the human resources department (for example, definitions for your organization’s SAP or PeopleSoft system) and another that contains definitions to external systems that you want to present only on pages in your organization’s portal web application. Similarly, you can have multiple MMS service applications: one global MMS service application for terms and content types applicable to all departments and divisions within your organization that you want to control centrally and another for each division within an organization (human resources, marketing, finance, etc.). You can configure each divisional MMS service application with its own term stores and content types, with the management of the term stores and content types delegated to the appropriate people within each division.
Also, some service applications allow multiple instances to be associated with one web application; the MMS service application is an example. All the MMS service applications could be associated with a web application—for example, http://portal.adventure-works.com. A divisional web application, such as http://hr.adventure-works.com, is associated with two MMS service applications: one containing organizationwide terms and content types and one containing HR-related terms and content types, as shown in Figure 3-2. When two MMS service applications are associated with a web application, one has to be defined as the default.
Figure 3-2 Service application instances can be shared between web applications.
Each BDC service application can have its own BCS administrators, who could be the business owners of the external systems and therefore familiar with the data held in the external system, the business processes that it supports, and security considerations. Each business team can control access to the business data without exposing the connection details of external system. As a result, each BCS service application can be administered in isolation and contain its own definition of external systems, external content types, and security settings.
Web applications can be associated with one or more BDC service applications. However, only the BDC service application that is specified as the default will be used. The second BDC service could be consumed through custom code.
Sharing Service Applications Across Farms
You can share service applications across SharePoint farms. The BDC service application is one of the service applications you can share across server farms, so you can manage it centrally and it can be consumed by web applications created on other farms. Table 3-1 lists the other service applications that can and cannot be shared across farms.
Table 3-1 Service applications that can and cannot be shared across farms
Can be shared
Cannot be shared
· Search Services
· Access Web Services
· Document Conversion
· Excel Services
· Project Services
· State Service
· Visio Graphics Services
· OWA Services
Note To make a BDC service application available to be consumed by other SharePoint farms, you need to publish the BDC service application. You can find information about how to publish a BDC service application later in this chapter.
For example, in a large international organization, one farm could be hosting the BDC service application that contains all BDC models for all enterprise line-of-business (LoB) applications, plus a MMS service application that contains organizationwide terms and content types. Each country could host its own SharePoint farm, and web applications in those farms would use the central BDC and MMS service applications and service applications that have been created locally, as shown in Figure 3-3. Very large organizations could create a SharePoint farm with the sole purpose of hosting service applications that other farms consume—that is, the farm would host no web applications.
Figure 3-3 Service application instances can be shared between SharePoint farms.
If you are considering such a configuration for your organization, you must ensure that the connectivity between the sites does not adversely impact the user experience. You will need to consider the retrieval of both the BDC model from the central BCS service application and the data from the external system. Once the BDC model is retrieved from the central BDC service application, it will be cached locally. The information in the BDC model will then be used by the local farms to retrieve data from the external systems—this too will be cached. There could be a long delay the first time a user requests a page that uses a Web Part that displays data from an external system. Subsequent requests will use the cached data and will be faster, but if the external data is rarely accessed, then users will always experience a delay.
Partitioning Service Applications
You can partition some service applications, and each partition can be used by one or more site collections when those site collections are hosted in a web application configured for multiple tenants. Each tenant, sometimes referred to as a customer, is identified by a computer-generated number known as a subscription ID. Subscription IDs can be created only when the Subscription Settings service is started.
Note Multitenancy is the term commonly used to describe the isolation of websites in a hosting environment. It is the configuration used in Microsoft Office 365 SharePoint Online P and E plans.
Each tenant can have multiple site collections as well as a tenant administration site collection. Site collections belonging to the same tenant are known as member sites. The subscription ID is used to identify all the member sites belonging to the same tenant.
The BDC service application is one of the service applications that can be partitioned, where each partition can contain its own external system definitions. Each partition is associated with a subscription ID, which identifies those site collections that can use the partition’s external system definitions. Figure 3-4 shows four tenants, each associated with its own subscription ID.
Figure 3-4 Service application partitions can be mapped to tenant site collections.
The BDC models uploaded into the first partition of the BDC service application can only be used by the member site /sites/hr.
In Figure 3-4, note that the SSS application is depicted as unpartitioned. SSS can be used in a tenant environment. You create the SSS service application in the same way as in a nontenant environment, and you manage it using the Tenant Administration page. However, in a hosting environment such as Office 365, where each tenant may belong to a separate organization, it is not prudent to use SSS where credentials from one organization are saved in the same encrypted database as credentials from other organizations—therefore, companies who provide hosting solutions may not allow the use of SSS.
See Also You can find information about how to administer a tenant environment later in this chapter.
In Figure 3-4, each site collection is created below a managed path, sites, under the root-level site collection http://portal.adventure-works.com. To view the pages in the HR site collection, for example, users would use the URL http://portal.adventure-works.com/sites/hr. This is not the only way to deploy a multitenant web application.
SharePoint allows multiple root-level site collections, known as host header site collections. Each host header site collection can have its own top-level domain name that is independent of the web application where the site collections are stored. In SharePoint 2010, you can use host header site collections with managed paths and both HTTP and HTTPS protocols. Also, it is possible to configure site collections in multitenant web applications so that a mixture of host header site collections and web protocols coexist. The site collection structure could remain as shown in Figure 3-4, and then you could configure it so users refer to the HR site collection as https://hr.adventure-works.com, while the finance site’s URL is http://portal.adventure-works.com/sites/finance.
See Also You can find a poster summarizing the hosting environments and illustrating common hosting architectures on the Microsoft download site at www.microsoft.com/download/en/details.aspx?displaylang=en&id=3326.
BCS and the Service Application Infrastructure
You can host service applications across one or more servers. SharePoint provides its own round-robin load-balancing mechanism to evenly distribute user requests across the servers running the service application code. In the case of the BDC service, the service application code then connects to the external systems to obtain the external data.
The service application infrastructure consists of the following:
· Service instances
· Service applications
· Service application proxies
· Service application groups
· Web applications
On each server, the process that runs service application code is known the service instance or service. A SharePoint service instance is similar to a Windows service: each maps to an executable that performs specific functions, does not require user intervention, and runs for a long time.
Windows services include the Background Intelligent Transfer Service (BITS), DNS Client, Print Spooler, and Task Scheduler. A server administrator can start and stop Windows services using the Services Microsoft Management Console (MMC; services.msc) snap-in, which you can start from Administrator Tools on the Start menu or through the Services tab in Windows Task Manager. SharePoint service instances are not Windows services, however, and to manage them, you use the SharePoint 2010 Central Administration website or Windows PowerShell.
Before creating a service application, you must start the appropriate service on at least one SharePoint server in the farm. That is, to create a BDC service application, you must start a BDC service on at least one SharePoint server.
Note Not only service application executables run in service instances. Other functionally also needs to run as service instances, such as the Microsoft SharePoint Foundation Subscription Settings Service, which provides the functionality to create and manage the subscription IDs that allow you to deploy a multitenancy environment.
By starting the BDC service on a number of servers, you are distributing BDC service applications across those servers, providing redundancy and the ability to scale your solution to support more users. For example, you could start the BDC service on two SharePoint servers, and if one of these SharePoint servers was lost, this issue would be detected by the built-in load balancer in each SharePoint web server. All subsequent requests from the web servers for external data would be directed to the SharePoint servers that are running the BDC service.
Note You can find the number of servers you need to run BCS service instances only by completing performance and capacity monitoring activities in your environment.
You can run only one BDC service per server, with such servers fulfilling the application tier role. If you create two BDC service applications, they both run in the same BDC service and have their own WCF endpoint. As detailed in Chapter 2, a SharePoint server can fulfill both web and application tier roles. In large deployments, some SharePoint servers will be running only service application services. For example, the two application servers in Figure 3-5 are hosting a subset of service application services, including the BDC service, and the remaining services are hosted on the web servers.
Figure 3-5 Service applications distributed over two application servers.
See Also You can find more information to help you plan your service architecture at technet.microsoft.com/en-us/library/cc560988.aspx for SharePoint Server 2010 and technet.microsoft.com/en-us/library/ff627854.aspx for SharePoint Foundation 2010.
Service Application Proxy
Most service applications require a service application proxy, also known as a service connection. A service application proxy connects the service application to a service application consumer, the web application.
Service Application Groups
Service applications are grouped together into service application groups. When you install SharePoint, there is one service application group: default. A service application can belong to more than one group. When you create a web application, you can select the default service application group or create a service application group, named custom, that is a specific collection of service applications for the web application you are creating, as shown in Figure 3-6.
Figure 3-6 The interaction between BDC services, service application groups, BDC service applications, BDC service application proxies, and web applications.
All service applications are automatically added to the default group. If you are a member of the Farm Administrators group, you can add and remove service applications from service application groups at any time by using the link to the service application groups on the Service Application Associations page. To navigate to this page in the SharePoint 2010 Central Administration website, click Configure Service Application Associations under Service Applications on the Application Management page.
When you click a service application group name, a modal window showing the Configure Service Application Association page appears, as shown in Figure 3-7. All service applications are displayed on this page. Select the ones that you want in your service application group.
Figure 3-7 Associate service applications with service application groups on the Configure Service Application Associations page.
You can add more than one BDC service application to a service application group, but only the BDC service application configured as the default will be used. You are unable to create any new ECTs or use any existing ECTs stored in the metadata store of the BDC service application other than the default.
If you set a different BDC service application as the default, then any external lists you created from ECTs saved in the previous BDC service application will not display any data, and an error message similar to “Entity (External Content Type) cannot be found with Namespace = ‘http://AdventureWorksSalesInvoicing’, Name = ‘AdventureWorks_Customers’.” will display, together with a correlation ID, as shown in Figure 3-8. Select only one BDC service application in a service application proxy group.
Figure 3-8 An error message is displayed when an ECT for an external list cannot be found.
See Also See the section “Troubleshooting Connection Problems” later in this chapter for information about correlation IDs and how they can help during troubleshooting.