The term service application has been overused. This makes it difficult for people to understand where the components live and how they function. To really get a handle on what’s happening behind the scenes, it’s important to know these terms:

You can deploy services in a number of ways, including the Configuration Wizard, Central Administration, or Windows PowerShell. The Configuration Wizard will configure many of the services with their default values. You shouldn’t use this for production environments, as there are many services that should be manually configured to ensure success.

In Central Administration, you can configure several services by populating fields associated with them. While you have a little more control than with the Farm Configuration Wizard, most SharePoint professionals will opt to use Windows PowerShell.

Windows PowerShell gives you the most control over the deployment of your service applications into your environment. The provisioning of some of the service applications can be very tricky, but you can still provision them all through Windows PowerShell.

When you configure your SharePoint farms, you get two services created automatically. These are key components for how the services work. These services include:

Service applications must expose a web endpoint because all of their communications take place over HTTPS. It’s also important to know that service applications communicate over TCP ports 32843 (HTTP) and 32844 (HTTPS).

Service applications are consumed by web applications, and each web application can have a specific set of proxy groups assigned to it. In Figure 4-1, you can see that the default proxy group and the secondary proxy group are getting consumed by different web applications and are sharing four service applications.

Figure 4-1. Service application mapping to proxy groups for four web applications.

Having the ability to pick and choose which proxy groups are assigned to which web application allows you to easily create a service architecture that is as complicated as you require.

The WCF is a communications framework for sending asynchronous messages between endpoints hosted by Microsoft Internet Information Services (IIS) or hosted within an application such as SharePoint. So when SharePoint services communicate between servers, they use the WCF framework. The complexity of the messages sent over WCF depends on the service using the framework; for example, a message might be as simple as a piece of XML data or as complex as a stream of binary data.

You can assign a specific service application to an individual web application. The web application uses the service application proxy as a way to connect to the service application because the consuming web application does not talk directly to the service application. You also have the ability to assign a single proxy to multiple proxy groups; however, you are not able to create custom-named proxy groups through Central Administration. To create your new friendly named proxy group, you will have to use the following Windows PowerShell cmdlet, where “Group Name” is the name of the proxy group that you wish to create.

PS C:> New-SPServiceApplicationProxyGroup "Group Name"

After the new proxy group has been created, users can add service applications to the group through the Central Administration graphical user interface (GUI) or through Windows PowerShell using the Add-SPServiceApplicationProxyGroupMember cmdlet. In Figure 4-2, you can see that a custom Application Proxy Group called Staff has been created for the Staff web application.

Figure 4-2. Users have the ability to create custom application proxy groups to keep their service application associations tidy.

By clicking the name (Staff) of the application proxy group, you are able to assign the application proxies (shown in Figure 4-3).

Figure 4-3. How to assign a service application to an application proxy group.

Users have the ability to implement out-of-the-box service applications either through the Central Administration GUI (Development Environment) or through the use of Windows PowerShell; meanwhile, the creation of custom service applications is done through a deployment package. The implementation of service applications can be in dedicated application pools and can be run by different service accounts. When deploying, you can adjust settings or can customize settings after the service application has been implemented. Users have the ability to modify service application proxies through either the administration user interface or through Windows PowerShell.

A database for a service application is not a requirement; however, for service applications, such as the Search service or the User Profile service, the service application could require more than one database, or for service applications, such as the Microsoft Visio Graphics service or Microsoft Excel, the service might not require any databases. Also, service applications do not need to be implemented as a WCF service. If you deploy your service applications using the Farm Configuration Wizard (into your development environment farm), the database names are automatically created with the service application name, as well as with a GUID. However, when you deploy your service applications into your production environment using Windows PowerShell, you can create user-friendly database names that follow the database naming convention of your organization.

There are not a lot of steps in the process of how OWA functions within SharePoint 2013 (see Figure 4-6).

Figure 4-6. The steps required to display a document in a web browser using an OWA server through SharePoint.

As you can see in Figure 4-6, there are four steps required to get a document to view within a web browser using the SharePoint 2013 OWA server:

Figure 4-9 shows the steps required for workflow to function within SharePoint 2013.

Figure 4-9. The way various workflow components talk to each other.

As seen in Figure 4-9, there are several steps that are required for the successful start of a workflow:

The Access Services web service application is based on the same service application namesake from SharePoint 2010. Access Services allows users to host Microsoft Access databases in SharePoint 2013 after being built using the Access 2013 desktop client and published into SharePoint. The Access Services for SharePoint 2013 can view and edit the Access 2010 web databases and even republish them into SharePoint 2013. The new service does not just allow you to create a website based on an Access database, but it will create the database schema and logic within a Microsoft SQL Server 2012 instance to store the Access database tables and information. Once the Access database has been provisioned, users will be able to view, edit, and interact with the Access 2013 database through their web browser. Unlike many of the SharePoint Server 2013 application services, Access Services 2013 doesn’t expose an API that you can use to develop Access apps in Microsoft Visual Studio. Access 2013 client is the tool that you use to develop Access 2013 apps, as shown in Figure 4-10.

Figure 4-10. An example of how Access Services works in SharePoint 2013.

Because the Access Services creates SQL databases and tables to store the Access databases, there are some SQL prerequisites that must be met. You can read more about Access Services and its prerequisites on Microsoft TechNet at http://social.technet.microsoft.com/wiki/contents/articles/12514.sharepoint-2013-access-services.aspx.

With the introduction of the Windows Store came the need for the creation of the Application (App) Management service. The App Management service is responsible for storing and providing the SharePoint app licenses and user permissions, which are stored in its own database. If you purchase an app from the Windows Store, the App Management service will store all of the information about downloaded app licenses. Each time a user tries to use a SharePoint app, the App Management service will query its SQL database to validate that the user has permissions to use the app and that the license is valid (see Figure 4-11).

Figure 4-11. The App Management service verifies that a user has permission to run the app.

The Machine Translation service allows SharePoint to translate content from one language into another through Microsoft Translator. Translator is a cloud-based translation service, so the server that is running the translation service must have the ability to access the Internet. If your organization limits which users can access the Internet, the service account that is running the service will also need permission to access the Internet. The Machine Translation service can run synchronously or asynchronously, or it can stream the translation of documents, pages, or sites. If you are using variations, it is possible to translate pages automatically based on target labels, and Managed Metadata service terms are also included in the variation translation, as shown in Figure 4-12.

The Machine Translation service is supported as a cross-farm (federated) service, is supported over wide area network (WAN) connections, and has its own database.

Figure 4-12. The Translator service is used with SharePoint to translate between languages.

Task aggregation across multiple platforms within an organization has been a huge thorn in the sides of many people. This new Work Management Service (WMS) gives SharePoint 2013 the ability to take all of the tasks assigned to a person from SharePoint, Exchange, Project, and custom providers and render them in a single location, as shown in Figure 4-13. The WMS is dependent upon the Search service application and the User Profile service application to be provisioned. The service account that is running your WMS application will need full control permissions on the User Profile service application.

Figure 4-13. WMS is used to consolidate all of a person’s tasks from various locations.

The Access Services 2010 web service application allows the backward compatibility of existing Access web databases from SharePoint 2010. Access Services 2010 allows users to view, edit, and interact with their Access 2010 databases through their browser. SharePoint does not store the Access Services Access databases in SQL, since this service functions the same as it did in SharePoint 2010.

The BDC service allows users to interact with data that does not live within SharePoint. There are out-of-the-box connectors that allow communication to external databases, such as a SQL database that contains sales data. BDC can publish the external data just like a standard SharePoint list and gives the users the ability to perform standard create, read, update, or delete (CRUD) operations on external line-of-business (LOB) systems (see Figure 4-14).

BDC is supported as a cross-farm (federated) service, is supported over WAN connections, and has its own database.

Figure 4-14. All the moving parts that are utilized by BDC within SharePoint and BCS within Office.

The purpose of Excel Services has not changed from SharePoint 2010. It still exists to publish Excel work sheets, workbooks, and data within a web browser. However, there have been several enhancements made to Excel Services from a developer perspective, such as updates to the REST API to request data through the Open Data Protocol (ODATA), and to the ECMAScript. There is also a new Excel Interactive View, which uses Excel services to generate Excel tables and chart views on demand, as diagrammed in Figure 4-15.

Figure 4-15. The parts found within the Excel Services application and proxy.

The Managed Metadata Service (MMS) application makes it possible to use managed metadata and share content types across site collections and web applications. Managed metadata is a hierarchical collection of centrally managed terms that users can define and then use as attributes for items. When you create the MMS application, a centralized term store is created to manage the keywords and terms, which gives the administrator the ability to point other web applications to the centrally managed MMS.

Another feature that is handled by the MMS is the ability to share content types. After creating the MMS and selecting a specific site collection as the content type hub location, users can share content types, such as columns, workflow associations, and policies, from their site collection’s content type gallery. It is possible to create multiple MMS and share multiple term stores and content types from multiple site collections, but the question of whether you should deploy more than one MMS would depend on your corporate information architecture. The architecture for MMS is the same as it was for SharePoint 2010.

MMS is supported as a cross-farm (federated) service, is supported over WAN connections, and has its own database.

The PerformancePoint Service (PPS) application allows users to create business intelligence (BI) dashboards, custom reports, filters, tabular data sources, and scorecards (see Figure 4-16). This is the tool that creates all the pretty pictures to show management a quick overview of an organization’s health. Using PPS with PowerPivot for SQL Server 2012 rounds off the BI integration stack by extending the capabilities of a user to dive deep into data. PerformancePoint alone will give you the dashboards to alert you of potential issues or trends, and PowerPivot will allow you to analyze (in detail) the source of the issue or trend.

Figure 4-16. The PPS application exposes data to the user.

Search is one of the major cornerstones that has made SharePoint a success. For SharePoint 2013, it can be said that the enhancements to the Search service application are not just the best upgrade of the service applications, but probably the best feature of SharePoint 2013. The integration of FAST into SharePoint 2013 Search, as well as shifting the responsibilities from the SharePoint 2010 Web Analytics Service, have made this service application one of the most important features of SharePoint. However, your SharePoint 2013 Search is not just FAST repurposed. Microsoft took the best of SharePoint 2010 Enterprise Search and combined it with the best of FAST to come up with Search for SharePoint 2013. Search is probably one of the most important services within SharePoint 2013, and it is critical to keep this service functioning at peak performance, not only for user satisfaction, but also to help SharePoint administrators keep track of what is happening on the web analytics side of SharePoint. The ability to give the site owners the flexibility to look at the analytics and adjust the search scopes accordingly should help reduce the strain on the administrative staff and make the site owners happier. The Search service application crawls content, maps the information to managed properties, updates analytics, updates the search index, handles user search queries, and displays the query results.

Search is supported as a cross-farm (federated) service and is supported over WAN connections. Search crawls over your corporate WAN to consume the content of your remote farms will eat up your network bandwidth, so plan and crawl accordingly.

How does it work?

The Search service application comprises several components and databases, as shown in Figure 4-17. Just like the other services, before implementing Search, you should take high availability and fault tolerance into account. You should also consider the volume of your content, the estimated page views, and the number of search queries that are going to happen when you architect out your Search service.

SharePoint Search has two system service instances: the SharePoint Search Host Controller and the SharePoint Server Search 15. The SharePoint Search Host Controller is responsible for performing the host deployment and management for the SharePoint Search components on a single host. In a single-server installation, the host controller will start up five Noderunner.exe processes, one for each of the following search components:

• Content processing

• Analytics processing

• Index

• Query processing

• Search administration

This leaves the final component, the crawl component, to be handled by the SharePoint Server Search 15 instance.

Figure 4-17. All these moving parts are required to get the new SharePoint 2013 Search working.

1. The crawl component is responsible for crawling content—not just SharePoint content, but also network folders, webpages, Exchange, and even custom LOB applications (piped items in Figure 4-17). The crawl component is responsible for collecting the content and metadata of the crawled items. To crawl content, the crawl component (crawler) connects to the content source by using the appropriate indexing connector with the appropriate crawl account. After the content has been crawled, the crawl component passes the crawled information to the content processing component for parsing. The crawling and indexing components are now discrete components in SharePoint 2013, where they were not in SharePoint 2010.

2. The content processing component is responsible for processing the crawled items and sending that information to the index component. You still have the ability to use custom iFilters, which are supported through a generic iFilter handler. In SharePoint 2013, you will not have to supply a .pdf iFilter because since it is native to the content processing component. The content processing component also transforms the crawled items into objects that can be included in the search index by parsing the document and document property mappings. This component is also responsible for linguistics processing such as language detection. The content processing component also updates the Link database with information about links and URLs. This content processing component is also responsible for generating the phonetic name variations for People Search. The content processing component sends the information to the index component and updates the analytics processing component by directly modifying the Link database.

3. The analytics processing component analyzes the crawled items and how users interact with the search results, then updates the search analytics information stored in the Link database. The analytics processing component is also responsible for maintaining the usage analytics information. For example, when a user loads a page, the page load event information is stored in the usage files on the web server and then pushed to the event store, where the data will remain until the analytics processing component updates the information in the Analytics Reporting database.

4. The index component receives the processed items’ information from the content processing component and writes the information to an index file. The index files are stored on a disk in an index replica. The index component is also responsible for handling the incoming search queries, retrieving information from the query processing component, and sending the query result set back to the query processing component. You can divide the search index into separate slices, called index partitions, where each index partition holds one or more index replicas. The search index is the aggregation of all index partitions. Indexes can be scaled out both horizontally (partitions) or vertically (replicas). Replicas are created for fault tolerance and to help increase the query throughput.

5. The query processing component analyzes and processes the incoming search queries and results. When the query processing component receives a query, it analyzes the query for relevance to help optimize the search precision. The processed query is sent to the index component, which in turn processes that result set before returning the search results to the web server.

6. The search administration component is responsible for running and monitoring the system processes for the search components. The search administration component is also responsible for provisioning and topology changes. Search topology is no longer modifiable through the Central Administration GUI, only through Windows PowerShell.

In SharePoint 2013, there are now four databases for Search out of the box, as compared to three for SharePoint 2010. This should not be too much of a surprise because Search did consume the SharePoint 2010 Web Analytics service. The four databases are as follows:

1. The Crawl database still stores the details about crawled items. It also stores historical information, such as the last crawl time, the last crawl ID, and the type of update during the last crawl.

2. The Link database stores information (links) gathered by the content processing component. It also stores information about the number of times that people have clicked a search result from the search result page.

3. The Analytics Reporting database stores the results of usage analytics and contains the extracted information from the link database. The Analytics Reporting database will also store search reports, such as item reports, like the number of views per document over time, or site level reports, like the number of unique visitors over time. Data is aggregated to monthly views every 14 days. A portion of the data is passed to the search index component, such as different view counts.

4. The Search Administration database stores search configuration data and the analytics settings. The Admin database no longer stores the access control list (ACL). There can be only one Search Administration database per Search service application.

You can read more about the Search databases in Chapter 5.

The Secure Store Service from SharePoint 2010 replaced the Single Sign On (SSO) feature in MOSS. SSS is a claims-aware service that stores user names and passwords in an encrypted database. The SSS can store more than just identities and passwords; it can store custom fields as well. The SSS is generally used to store identities and passwords to access external back-end systems within an organization. Within SharePoint, SSS is used to hold the unattended service accounts for other services such as Excel, Visio, PerformancePoint, and PowerPivot services. BCS also uses SSS to store the credentials that it requires to access external LOB data systems.

Before you try to use SSS for the first time, you will need to provide an encryption (passphrase) key, which the SSS will use to encrypt and decrypt credentials stored in its database. It is a good idea to keep a copy of the passphrase in a secure location, such as an encrypted password safe, but you can force a re-encryption of the database based on a new passphrase should you lose your original SSS passphrase. If you are going to force a re-encryption of your SSS database, back it up first. The architecture for SSS is the same as it was for SharePoint 2010.

SSS is supported as a cross-farm (federated) service and is supported over WAN connections, but not recommended across WANs due to the latency created for the applications consuming it. SSS also has its own database.

The User Profile service application (UPA) stores information about users in a central location, and it can even be set up to synchronize external LOB data to enhance the users’ profile data. UPA is required to provision My Sites and enable social features such as Profiles pages, Social Tagging, and Newsfeeds. UPA is also required if you are planning on distributing user profiles across multiple farms. UPA is one service that added functionality by taking features of past deployments and integrating them into the improved SharePoint 2013 UPA. Like in the SharePoint 2007 days, there is once again the ability to run in Active Directory Import (ADI) mode.

Running in ADI mode has its limitations. Since you are not running the User Profile Synchronization (UPS) service, you will not be able to synchronize your user profiles with external data. The UPS for SharePoint 2013 (see Figure 4-18) is the same as it was for SharePoint 2010.

UPA is supported as a cross-farm (federated) service but is not supported over WAN connections. UPA has its own database.

Figure 4-18. All these moving parts are required to make UPS and ADI work.

The Visio Graphics service (VGS) allows users to view and refresh Visio diagrams in a web browser. It is the service used to create the Visio diagrams so that you can monitor workflow progress, if enabled, and is a great tool for keeping everyone on the same page regarding how things work. VGS supports the new Visio file format .vsdx, which will allow users to save files directly into SharePoint and not publish them as Visio Web Drawings (.vdw) files. The new service will also natively render Visio macro-enabled drawing (.vsdm) files. One of the other new features within Visio 2013 is the ability to use BCS to refresh external content, tied in with the ability to use SSS for handling authentication. See Figure 4-19 for more information on the architecture of VGS.

Figure 4-19. VGS renders Visio drawings in this way.

The Word Automation service (WAS) performs bulk Word document conversions. The document conversions are automated, unattended server-side conversions. That means that you cannot convert the documents without having custom code written. The conversions can only happen with documents that are a supported “Save As” file type from within the Word client application. In SharePoint 2010, the conversion of Word documents was dependent on the timer service, which could be adjusted to convert documents every minute. In SharePoint 2013, you have the option to create a file conversion request that happens immediately (see Figure 4-20 for more information). Notice that there is a similar architectural layout as the new Machine Translation service. This is not surprising because the Machine Translation service was built using the WAS code. As with the Machine Translation service, the Word Automation service has its own database to store the document queue information.

Figure 4-20. WAS is used to convert Word documents into other formats.

The Application Discovery and Load Balancer service is also known as the Topology service, and as its name says, one of the functions of this service is to provide load balancing. However, it is not a network load balancer for your websites (spWebs); rather, it is a load balancer for your service applications. This is a round-robin service and is used by the service applications for load balancing and fault tolerance, which allows you to have the same service enabled on different servers for high availability.

The application discovery side of this service occurs when the service application proxy requests an endpoint for a service application from the load balancer. The load balancer maintains a list of the available endpoints for each service application in cache on the consumer and returns the next available endpoint when queried. There is also a timer job that updates the cache that runs every 15 minutes by default. You can manually start a refresh of the endpoints by running the following Windows PowerShell cmdlet:

PS C:> Start-SPTimerJob job-spconnectedserviceapplication-addressesrefresh

There is more information about service application endpoints in the Service application endpoint using the WCF framework section, earlier in this chapter.

The Secure Token service (STS) is another service that is automatically created when you provision your SharePoint farm. The STS is a WCF service (.svc) endpoint that is designed to respond to requests for security tokens and provide identity management.

User authentication in SharePoint 2013

User authentication is the validation of a user’s identity against a trusted authentication provider. SharePoint 2013 uses STS to handle the claims-based authentication for user authentication. If the user is authenticated through a claims-based authentication, a claims-based security token is generated by SharePoint STS and converted into an SPUser identity (see Figure 4-21).

Figure 4-21. A user uses STS and claims to become authenticated and access information in SharePoint.

As previously mentioned, to create a trust between farms, an exchange of certificates needs to take place. From the consumer farm, export the Root and STS certificates. The exporting of the required certificates can only be done using Windows PowerShell:

PS C:> $rootCert = (Get-SPCertificateAuthority).RootCertificate
PS C:> $rootCert.Export("Cert") | Set-Content C:consumerFarmRoot.cer -Encoding byte
PS C:> $stsCert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate
PS C:> $stsCert.Export("Cert") | Set-Content C:consumerFarmSTS.cer -Encoding byte

The next step will be to export only the Root certificate from the service farm:

PS C:> $rootCert = (Get-SPCertificateAuthority).RootCertificate
PS C:> $rootCert.Export("Cert") | Set-Content C:servicesFarmRoot.cer -Encoding byte

After the export has completed, copy the consumer Root and STS certificates to the service farm, and copy the Root certificate from the service farm to the consumer farm. From the service farm, establish the trust by importing the Root and STS certificates:

PS C:> $trustCert = Get-PfxCertificate C:consumerFarmRoot.cer
PS C:> New-SPTrustedRootAuthority consumerFarm -Certificate $trustCert
PS C:> $stsCert = Get-PfxCertificate C:consumerFarmSTS.cer
PS C:> New-SPTrustedServiceTokenIssuer consumerFarm -Certificate $stsCert

From the consumer farm, import the Root certificate only:

PS C:> $trustCert = Get-PfxCertificate C:servicesFarmRoot.cer
PS C:> New-SPTrustedRootAuthority servicesFarmRoot -Certificate $trustCert

By taking a look within Central Administration | Security | Manage Trust on the consumer (Figure 4-24) and service farms (Figure 4-25), you can verify that you have installed the certificates correctly.

Figure 4-24. A list of the consumer farm trust relationships.

Figure 4-25. A list of the provider farm trust relationships.

Because the topology service maintains a list of all of the endpoints for the SharePoint farm, the consuming farm must have access to the publishing farm’s topology service. This can be achieved by taking the Farm ID from the consumer farm and giving it permissions on the Topology service application on the service farm. The following Windows PowerShell cmdlet will export the consumer farm’s ID:

PS C:> $farmID = (Get-SPFarm).Id
PS C:> New-Item C:consumerFarmID.txt -type file -force -value "$farmID"

After the file has been created, copy the file to the service farm and run the following Windows PowerShell cmdlet to give the consumer farm access to the service farm’s topology service:

PS C:> # Run the following commands on the services farm to set up the trust relationship with
the consumer farm:
PS C:> $farmID = Get-Content c:consumerFarmID.txt
PS C:> $security = Get-SPTopologyServiceApplication | Get-SPServiceApplicationSecurity
PS C:> $claimProvider = (Get-SPClaimProvider System).ClaimProvider
PS C:> $principal = New-SPClaimsPrincipal -ClaimType "http://schemas.microsoft.com/
sharepoint/2009/08/claims/farmid" -ClaimProvider $claimProvider -ClaimValue $farmID
PS C:> Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights "Full Control"
PS C:> Get-SPTopologyServiceApplication |
PS C:> Set-SPServiceApplicationSecurity -ObjectSecurity $security

The creation of the permission set can be verified by going into Central Administration of the service farm and looking at the permissions for the Application Discover and Load Balancing service application, as shown in Figure 4-26.

Figure 4-26. The permissions window for the Topology service.

The first step toward being able to publish your service applications is provisioning your service applications. If you have not provisioned the service applications that you wish to publish, you will need to do that first. After you have provisioned the BDC service application and proxy on your services farm, publish the service application by going into Central Administration | Application Management | Manage Service Applications | Business Data Connectivity Service Application | Publish (in the Ribbon).

Clicking Publish will open the Publish Service Application modal dialog box. Change the connection type to HTTPS, and a bit farther down the page, copy the Published URL into Notepad. You will need the URL when it is time to connect to the service (see Figure 4-27). Click OK when you are ready to continue.

Figure 4-27. The Publish Service Application modal dialog box.

From within your consuming farm, select Central Administration | Application Management | Manage Service Applications. If you have already provisioned the BDC service, you should remove it before progressing.

From the Connect drop-down menu, select the BDC service. Don’t be fooled by SharePoint exposing all the service applications within the drop-down menu. SharePoint will let you create connections for the App Management and Work Management service applications as well, but that is not supported.

Once the Connect To A Remote Service Application modal dialog box has opened, paste in the URL that you copied when you published the BDC service, as shown in Figure 4-28. If you click OK and run into an error, verify that you have opened port 32844 (HTTPS) if you followed directions, or 32843 (HTTP) if you did not.

Figure 4-28. Enter the URL from the service farm.

After successfully connecting the two farms, your list of service applications should have the connected Topology service and the connected BDC service, as shown in Figure 4-29.

Figure 4-29. A list of the remote Topology services and remote service applications.

Currently, there still is no way to manage the service applications in the service farm from the consumer farm. So, just as when you set the permission for the consumer farm to use the Topology service, it is now time to add the consuming farm’s ID to the BDC service. The farm ID is already on the C: drive, so all you need to do paste the ID into the permissions window for the BDC service, check the name, add it to the group, and give Full Control, as illustrated in Figure 4-30.

Figure 4-30. The modal dialog box is for adding the consuming server’s permissions.

The configuration of the BDC service farm is complete, and the consuming farm will treat the service as if it were being run locally.

Service application federation is a valuable tool when it comes to scalability and flexibility in a growing SharePoint 2013 environment. If you need to deploy a service farm, you should now have all the tools to succeed.