Business Connectivity Services hybrid

In this chapter, you will learn what Microsoft SharePoint Business Connectivity Services offers in a hybrid context, its usage scenarios, authentication flow, and configuration in a sample on-premises application. We cover what are the requirements for a BCS hybrid solution with step-by-step procedures on the configuration process. This chapter requires the use of Microsoft Visual Studio, and adequate screenshots with explanation have been provided here—enough to get you right through the process of configuring BCS hybrid.

Overview of Business Connectivity Services hybrid

A Business Connectivity Services (BCS) hybrid solution makes it possible for organizations to securely publish internally hosted business application data, commonly referred to as line-of-business (LoB) data to SharePoint Online. Your mobile workers, traveling workforce, and external partner organizations can securely consume and interact with the data that resides on your internal corporate network without the need for you to migrate or replicate data across network boundaries.

Using BCS, your internal users can publish on-premises data to a list or application external in SharePoint Online. With BCS hybrid, users can create, read, update, and delete items in an external list across both SharePoint Online and SharePoint on-premises. Your LoB data can exist in its current location without moving it out to a perimeter or external network. A requirement is that the on-premises SharePoint must have an existing BCS configuration set up.

BCS hybrid uses the on-premises BCS services to connect to the LoB data and then, through a reverse proxy, securely publish it through a Client-Side Object Model (CSOM) endpoint out to the BCS services in SharePoint Online. BCS hybrid currently only connects through an Open Data Protocol (OData) source. OData is an open web protocol for querying and manipulating data with Create, Read, Update, and Delete (CRUD) operations.

Simply put, BCS hybrid connects to the SharePoint on-premises farm and in turn, connects to the on-premises OData service URL that connects and exposes the LOB data with which users can interact.

An OData client accesses data provided by an OData service by using standard HTTP. The OData protocol largely follows the conventions defined by REST, which define how you use HTTP verbs such as GET, POST, PUT, DELETE.

BCS hybrid with Microsoft Azure SQL

Some organizations that already have their data on Azure SQL, have the option of exposing this data directly to SharePoint Online. Microsoft has made it easy to set up the external content types between SharePoint Online and Azure SQL databases. This is done through SharePoint Designer’s SQL Data source type without the need for using Visual Studio and working with OData. After all the permissions are set up correctly and the configurations made, you can add databases from Azure SQL as external lists on SharePoint Online.

BCS hybrid flow

To understand BCS hybrid, you need to go through the flow to see what it entails, such as authentication, presentation of data, and components involved in presenting that data, as illustrated in Figure 3-1. Understanding this will make BCS hybrid more meaningful and help in troubleshooting and administration.

1. A user that requires content from the LoB application, signs in to SharePoint Online as a federated or synchronized user and opens an online app or external list on SharePoint Online.

2. The online app or external list sends a request to BCS online for the data. BCS determines the data source and credentials required by looking up its imported data models and connection settings. BCS online differs a little from BCS on-premises by the requirement to specify the OData connection settings in a separate setting within BCS online.

3. BCS retrieves the identification certificate with a purpose of client preauthentication against the reverse proxy from the online Secure Store Service. This certificate is configured when setting up the online Secure Store Service. This certificate is used for authentication from SharePoint Online back to the on-premises reverse proxy and SharePoint on-premises farm.

   Additionally, BCS retrieves an OAuth token containing the user's credentials from the Azure Access Control Service (ACS) and is used for authenticating to the SharePoint on-premises farm.

4. BCS online sends a HTTPS request to the published endpoint for the data source. This HTTPS request contains the following:

   • The client authentication certificate from the online Secure Store Service for preauthentication purposes with the reverse proxy

   • The user’s OAuth security token

   • A request for the data.

5. The reverse proxy authenticates the request by using the client certificate and forwards the HTTPS request to the CSOM pipeline of the SharePoint on-premises farm.

6. SharePoint on-premises retrieves the user's identity from the OAuth security token in the HTTPS request and attempts to match it to an identity in the on-premises User Profile Service. If a match exists, the user’s on-premises on-premises credentials are returned to the HTTPS request. The matching process is performed on the user’s security identifier (SID) first and then a soft match is performed on the user’s User Principal Name (UPN), Simple Mail Transfer Protocol (SMTP), and Session Initiation Protocol (SIP) settings, if necessary.

   NOTE

   When a user signs in to SharePoint Online, the user is authenticated by ACS. ACS issues an OAuth security token, which represents the user to all SharePoint Online processes and objects that the user tries to access. This security token is embedded in the request for external data and passed, along with the client authentication certificate, to the reverse proxy.

7. The user’s on-premises credentials are used to authenticate to the SharePoint on-premises site that is configured for inbound hybrid requests and published by the reverse proxy; for example, https://intranet.contoso.com. The request is then passed to the SharePoint on-premises BCS service.

   NOTE

   User’s domain credentials is another security token that represents the user in the on-premises Active Directory domain. In a SharePoint BCS hybrid scenario, it is used to authenticate the user to SharePoint on-premises and to access all other on-premises resources as that user. This depends, of course, on the BCS Secure Store in play on the internal site. If you are using Secure Store group credentials or a fixed account, the content is not accessed as the user, but as the group or the fixed account.

8. The SharePoint on-premises BCS retrieves the credentials in the form of a security token that are used to the Secure Store service application, which in turn provides credentials for access to the OData source.

9. The SharePoint on-premises BCS service passes the request for data along with the data access credentials to the OData endpoint, which then performs the desired operations on the external data. The request is authenticated by OData endpoint which, in our example, is Internet Information Services (IIS), and the results are returned to the SharePoint Online user.

Prerequisite Steps for Configuring SharePoint BCS hybrid

The following are the prerequisites that are required to be set up prior to configuring your SharePoint BCS hybrid environment.

For all the scenarios in this chapter, the following assumptions have been made.

1. The company’s on-premises domain has been added to the O365 tenant.

2. Azure Active Directory Connect (Azure AD Connect) has been configured with or without password synchronization.

3. If password synchronization has not been enabled, then Active Directory Federation Services (AD FS) has been deployed to support user sign-in to Office 365.

   More info

   You can find details for the preceding steps in the free eBook, Planning and Preparing for Microsoft SharePoint Hybrid. To download the e-book, go to https://blogs.msdn.microsoft.com/microsoft_press/2016/04/26/free-ebook-planning-and-preparing-for-microsoft-sharepoint-hybrid.

4. An S2S trust has been set up between SharePoint Server on-premises and Microsoft Office 365, using Azure ACS as the trust broker. You can configure this trust either manually as detailed in Chapter 1, or it might already be in place if you have used the SharePoint Online Hybrid picker to deploy Microsoft OneDrive or Hybrid Sites features.

5. A SharePoint site collection has been chosen and is published via a reverse proxy. This is identical to what hybrid search requires. The choice of reverse proxies might differ from one organization to another, but Microsoft’s Web Application Proxy server has been chosen in this book along with the configuration steps in Windows PowerShell. Refer to the following subsections in the section “Configuring inbound hybrid search” in Chapter 2:

• Publishing the SharePoint On-Premises Web Application by using client certificate preauthentication

• Configuring Web Application Proxy

The main thing is to note here is that preauthentication occurs with the client certificate to ensure that the published endpoint is secure.

SharePoint farm configuration

You will need to check a few things on your SharePoint on-premises farm before you begin configuring for BCS hybrid. The following points will help with the your checks:

• A Managed Metadata Service Application configured and the service instance running

• A configured user profile service application that has been synchronized and the user profile store contains the same users that are synchronized to Azure Active Directory. The corresponding users that have been synchronized to Office 365 must have a valid Office 365 subscription license assigned to them.

This is used by the STS service that uses the metadata from the User Profile Service Application to construct security tokens for gaining access to hybrid resources.

• A BCS solution using OData to connect to the LoB.

For example, for a SQL database, an OData service endpoint hosted as a web service would look like https://odata.contoso.com/AdventureWorks.svc.

OData source

You need to confirm that the OData service endpoint has been configured and is available; for example, https://odata.contoso.com/AdventureWorks.svc.

Validate the prerequisites

The following steps help to validate that the prerequisites are in place and you are ready to proceed further with configuration:

1. Verify that your public Internet domain name can be resolved in DNS; for example, intranet.contoso.com.

2. Verify that you can connect to the primary web application by using both the internal and external URLs; for example, https://intranet.contoso.com

3. To verify that your reverse proxy endpoint is successfully configured and ready for client preauthentication, validate by navigating to your externally published URL such as https://intranet.contoso.com from an external web browser with Fiddler2 loaded to inspect the web traffic. Figure 3-2 shows that Fiddler2 displays the Client Certificate Requested message box, which confirms that a certificate challenge was received. No further steps are necessary in this validation step.

   

   Figure 3-2: Fiddler being challenged to produce the client certificate for preauthentication with the reverse proxy.

Configuring SharePoint BCS hybrid

After the prerequisites have been completed, you must perform the following steps to configure SharePoint BCS hybrid. We will go through all the steps in sequence. It is advised to record your configuration information (such as names of services) as you progress with the configuration steps, especially if you deviate from the names suggested here.

SharePoint Online Secure Store Service configuration

You need to set up a secure store target application in SharePoint Online. This target application is used to store the certificate for client preauthentication.

1. Sign in to the SharePoint Admin Center with administrator rights.

2. Click Secure Store, and then click New.

3. In the Target Application ID box, type SecureChannelTargetApplication.

   The ID can be anything you want, but note that it should not contain any spaces. You will need to use this same ID at a later stage in the configuration.

4. In the Display Name box, type Secure Channel Target App.

5. In the Contact E-mail box, provide an address and leave the target application type as Group Restricted.

6. In the Credential Fields section, replace any text in the field name of the first row with Certificate.

7. In the upper Field Type box, select Certificate.

8. If you have a .pfx certificate as your preauthentication certificate, you would need to replace any text in the field name of the second row with Certificate Password.

9. In the lower Field Type box, select Certificate Password, as illustrated in Figure 3-3.

   NOTE

   You can delete the second row if you have only a .cer certificate to work with as your secure channel certificate.

   

   Figure 3-3: Configuring the certificate and password for a .pfx preauthentication certificate in the Secure Store Service Online.

10. In the box in the Target Application Administrators section, type the list of users who need to manage the Target Application settings, as demonstrated in Figure 3-4.

    

    Figure 3-4: Configuring target application administrators and using Everyone Except External Users as members.

11. In the Members section, add the users and groups that are mapped to the credentials defined for this target application; for example, Everyone Except External Users is available as a default group in SharePoint Online.

12. Click ok.

    After you create it, you will see the Target Application ID called SecureChannelTargetApplication in the SharePoint Online Secure Store Service.

13. Select the Target Application ID check box, and then click, on the ribbon, in the Credentials group, click Set, as depicted in Figure 3-5.

    

    Figure 3-5: Set Credentials on the SecureChannelTargetApplication in the Secure Store Service Online.

14. After you upload your certificate and the password, click Ok to complete the Secure Store Service target application ID configuration.

    Figure 3-6 presents the credentials in this screen, which are the certificate and certificate password that would be used for the client preauthentication process.

    

    Figure 3-6: Uploading the SSL certificate (contoso.com.pfx) with its password in Secure Store Service Online.

On-premises service account and security group creation

You would need to create a new service account and a security group in Active Directory on-premises by performing the following steps:

1. Create a new on-premises service account. This will access the OData service endpoint; for example, CONTOSO\ODataAccount.

2. Create a new on-premises global security group; for example, CONTOSO\ODataGroup.

3. Identify all users that will use the BCS hybrid solution. Ensure that they are federated accounts. Add them to the CONTOSO\ODataGroup.

4. Add the CONTOSO\ODataGroup as a Member of the SharePoint site to grant all the designated users access to the BCS hybrid solution.

On-premises Secure Store Target application configuration

Through the on-premises secure store service, users in the CONTOSO\ODataGroup access the OData service endpoint through only one account, the CONTOSO\ODataAccount

Here’s how to create a target application:

1. On the Central Administration home page, in the Application Management section, click Manage Service Applications.

2. Click the Secure Store service application.

3. In the Manage Target Applications group, click New.

4. In the Target Application ID box, type a text string; for example, ODataApp.

5. In the Display Name box, type a name for the target application; for example, ODataApp.

6. In the Contact Email box, type a contact email address.

7. In the Target Application Type list box, select Group.

   This indicates the mapping of many user credentials or a security group to one credential. In this case, the Target Application Page URL is not needed and automatically selects None.

8. Click Next.

9. On the Create New Secure Store Target Application page, for both Field Name and Field Type, accept the default values of Windows User Name and Windows Password, and then click Next.

10. In the Target Application Administrators box, add the Farm Administrators account and an account that has farm administrator rights.

11. In the Members box, add the domain security group you are using to control access to the BCS hybrid scenario solution; for example, ODataGroup.

12. Click OK.

Here’s how to set credentials for a target application:

1. In the target application list, point at the target application that you just created (ODataApp), click the arrow that appears, and then, on the menu, click Set Credentials.

2. If the target application is of type Group, type the credentials for the external data source.

   Depending on the information that is required by the external data source, the fields for setting credentials will vary.

3. If the target application is of type Individual, type the user name of the individual who will be mapped to this set of credentials on the external data source, and type the credentials for the external data source.

   Depending on the information that is required by the external data source, the fields for setting credentials will vary.

4. In the Windows User Name box, type the account name for the account that will have access to the OData service endpoint in domain\username format; for example, CONTOSO\ODataAccount.

5. Type and confirm the password for that account, and then click OK.

On-premises Secure Store Service Application master key configuration

If you do not have a Master key configured in the Secure Store Service Application in your on-premises farm, you will need to perform the following steps:

1. Go to your on-premises Secure Store Service.

2. Ensure that there are no keys already configured. Confirm with a colleague or SharePoint farm administrator if you are unsure.

3. If no one has yet set up a key for the farm, click Generate New Key.

4. Type a passphrase, and then click OK

Ensure that you have recorded this passphrase in a safe place.

SharePoint Online site and App Catalog preparation

You can present the data either through a SharePoint Online external list or through an add-in (app) for SharePoint. If you choose to use an add-in for SharePoint, you must also have a SharePoint Online App Catalog configured. In this book, we will present data through a SharePoint Online external list and not an add-in (app) for SharePoint.

SharePoint Online BDC Metadata Store permissions configuration

The BDC Metadata Store holds external content types, external systems, and BDC model definitions for the BCS Service Application. You will be required to configure permissions on the Metadata Store for users to be able to access the external content types.

To set permissions on the BDC Metadata Store in SharePoint Online, perform the following steps:

1. Open the SharePoint Online Admin Center by using an administrative account.

2. In the navigation pane on the left, click “bcs,” and then click Manage BDC Models And External Content Types.

3. Click Set Metadata Store Permissions, and then add All Authenticated Users with at least Execute permissions.

   This will make it possible for all users who authenticate to your SharePoint Online tenancy to use the external content types stored in the Metadata Store.

4. Select the “Propagate permissions to all BCS Models, External Systems and External Content Types in the BDC Metadata Store” check box. Doing so will overwrite any existing permissions check boxes.

5. Click OK.

SharePoint Online BCS connection settings for apps configuration

Unlike BCS in SharePoint on-premises, BCS in SharePoint Online requires that you configure additional connection settings, which contains additional information to establish the connection to the external system and the OData source.

Before you begin this procedure, ensure that you have the following:

• The URL or published service endpoint of the on-premises OData service that you configured (https://odata.contoso.com/AdventureWorks.svc/).

• The ID of the on-premises Secure Store target application that you configured; for example, ODataApp.

• The Internet-facing URL that Office 365 uses to connect to the service address and that was published by the reverse proxy. This is the address that you used to browse to the external service in the last procedure, with the addition of /_vti_bin/client.svc; for example, https://intranet.contoso.com/_vti_bin/client.svc

  Important

  Ensure that you do not forget to add the path to the client side object model to the URL /_vti_bin/client.svc. So your URL would look similar to https://intranet.contoso.com/_vti_bin/client.svc.

• The ID of the Secure Store target application for the client preauthentication certificate in Office 365; for example, SecureChannelTargetApplication.

To configure the connection settings object for the BCS hybrid scenario, perform the following steps:

1. Open the SharePoint Online Admin Center by using a Global Administrator account, and then, in the navigation pane, click “bcs.”

2. Click Manage Connections To On-Premises Services, and then click Add

3. On the Connection Settings Properties page, give the connection settings object a name; for example, ODataOnPremises.

   Important

   Keep track of this name; you will require it when you create the external content type in the next procedure.

4. In the Service Address box, type the URL of the OData service endpoint that you created; for example, https://odata.contoso.com/AdventureWorks.svc.

5. For this scenario, select the Use Credentials Stored In Sharepoint On-Premises as the authentication option, and then type the name of target application ID that holds the group to account mapping. In this scenario, it is ODataApp that you created.

6. In the Authentication Mode list box, select Impersonate Window’s Identity.

7. In the Internet-Facing URL box, type the external URL with the /_vti_bin/client.svc extension; for example, https://intranet.contoso.com/_vti_bin/client.svc

   Important

   Ensure that you do not forget to add the path to the client side object model to the URL /_vti_bin/client.svc. So your URL would look similar to https://intranet.contoso.com/_vti_bin/client.svc.

8. In the Secure Store Target Application ID box, type the ID of the target application that holds the Secure Channel certificate; for example, SecureChannelTargetApplication. Before clicking create, reconfirm your settings. It should be similar to what you see in Figure 3-7.

   

   Figure 3-7: The BCS Online Connection Settings Properties page to manage connections to on-premises services.

9. Click Create.

SharePoint 2013 compatibility setting for SharePoint Online

If you configured Use Credentials Stored In SharePoint On-Premises in step 9 of the previous procedure, and if you are working with SharePoint Server 2013 on-premises, there is an additional change you need to make to the web.config file in your on-premises web application. Because SharePoint Online essentially contains version 16 bits and if you are running SharePoint Server 2013 on-premises with version 15 bits, there is a mismatch in versions that could cause an issue when uploading your BDC model file in Office 365.

<dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">

         <assemblyIdentity name="Microsoft.Office.SecureStoreService" publicKeyToken="71e9bce111e9429c"
culture="neutral" />

         <bindingRedirect oldVersion="16.0.0.0" newVersion="15.0.0.0" />

</dependentAssembly>

Without this in place you will get the following error when you import your BDC model: The Type Name For The Secure Store Provider Is Not Valid.

Create and configure the external content type

An external content type (ECT) holds important configuration information that BCS needs to understand and to get data from the LoB data source. ECTs map external data fields to business entities; for example, Customer, Order, and Product. An ECT defines how the LoB data is structured and typically includes the service URL of the data source, or in a hybrid BCS scenario, it points to the BCS connection configured in the previous procedure; for example, ODataOnPremises in the Connection Settings For Apps.

An ECT also includes specific portions of the external data that you want to interact with, and the permitted operations such as create, read, update and delete.

In the BCS hybrid scenario, only OData sources are supported and the preferred way to make an external content type for an OData source is to use Visual Studio. With Visual Studio, you are able to easily create the external content type by directly connecting to the OData source, reading it, and building it. After it is created, you would need to extract the BDC model file (.bdcm) and make some changes to get it ready for upload to SharePoint Online BCS. These modifications are described in the section “Make the BDC model file Office 365 tenant ready” later in this chapter.

Before you begin, ensure you have the following:

• Visual Studio 2012/2013 installed

• Microsoft Office Tools for Visual Studio

• The OData service endpoint URL, such as https://odata.contoso.com/AdventureWorks.svc

You need to create an ECT from the OData service endpoint by using Visual Studio.

The following steps show how to use Visual Studio 2012 to create an ECT based on an OData source.

To create a new SharePoint Add-in:

1. In Visual Studio, create a new App For SharePoint project, which is located under the Visual C#, Office/SharePoint template node, as depicted in Figure 3-8.

   

   Figure 3-8: Creating a new Visual Studio project in C# - App for SharePoint.

2. Name your project, and then choose OK. In our example, we named it ContosoSalesApp.

3. To specify the SharePoint settings, type a name for your app, and the URL of the on-premises SharePoint dev farm you will be debugging against. In our example here, we have https://devintranet.contoso.com configured with a Developer Site web template (DEV#0), as illustrated in Figure 3-9.

   

   Figure 3-9: Settings for the new app for SharePoint project in Visual Studio.

4. Click Finish.

   After the project is created, you use the new auto generation tooling for OData sources and add a BDC model for the OData source to your app.

   To add a new BDC model:

5. In Solution Explorer, right-click the App (ContosoSalesApp), and then, on the shortcut menu that opens, click Add.

6. On the submenu that appears, select Content Types For External Data Source, as depicted in Figure 3-10.

   

   Figure 3-10: Adding content types for an external data source for the ContosoSalesApp in Visual Studio.

   This starts a wizard that will help you discover the selected data source and create the BDC model.

7. The first page of the wizard is used to collect the URL of the data service. On the Specify OData Source page, type the URL of the OData service to which you want to connect. In our example, it is https://odata.contoso.com/AdventureWorks.svc.

   If you don’t have an on-premises OData service created yet, you can work with freely available read-only OData service endpoints on the Internet such as: http://services.odata.org/AdventureWorksV3/AdventureWorks.svc or http://services.odata.org/Northwind/Northwind.svc.

8. Choose a name for your OData source, and then choose Next.

9. A list of data entities that are being exposed by the OData Service appears. Select one or more of the entities (see Figure 3-11), and then choose Finish.

   

   Figure 3-11: Data entities enumerated and selecting CompanySales to build the new external content type.

10. Verify if the .ect file has been created by expanding the newly created folder named External Content Types in Solution Explorer. As depicted in Figure 3-12, you will see your newly created data source (ContosoSales) and if you further expand the ContosoSales folder, you will see the newly created .ect file.

    

    Figure 3-12: ECTs created based on selection of CompanySales data entity.

    You can view the .ect file in a graphical list of the entities by double-clicking the .ect file in Visual Studio, as shown in Figure 3-13.

    

    Figure 3-13: Viewing the .ect file in graphical list in Visual Studio.

Alternatively, to view the contents in XML format, in an XML editor, right-click the .ect file in Visual Studio, select Open With, and then select XML (Text) Editor.

How to prepare the .ect file

To use multiple ECTs in the BCS service application, you need to ensure that unique names are configured in the .ect files.

1. After you have opened the .ect file in an XML editor such as Visual Studio, you will need to replace the Name attribute in the Model element, as illustrated in Figure 3-14 and Figure 3-15. In our example, we used the AdventureWorks.svc OData source endpoint, so the name in your ECT will have something similar to AdventureWorksModel. You will need to replace this with a unique name such as >ContosoCompanySales.

   

   Figure 3-14: The AdventureWorksModel automatically generated in the ECT needs to be changed to unique name.

   You can change this to anything you like that describes this particular ECT.

   

   Figure 3-15: Model name changed to ContosoCompanySales to make it unique.

2. For consistency, you can change the Namespace attribute of the Entity element, which is about 28 lines down in the .ect file (see Figure 3-16). Replace AdventureWorksModel with >ContosoCompanySales.

   

   Figure 3-16: Update Entity NameSpace to ContosoCompanySales.

3. Modify the Elements.xml file (Figure 3-17) with the same name for consistency. Replace AdventureWorksModel with >ContosoCompanySales and save all the files in that project.

   

   Figure 3-17: Update the Elements.xml file for consistency.

Manually extract an external content type to a BDCM file

The external content type that you configured must be manually extracted and saved as a file with a .bcdm extension. You do this in Windows Explorer by locating the project files where the .app package is created. Follow the procedure in “How to: Convert an App-Scoped External Content Type to Tenant-Scoped” in the MSDN Library.

You’ll need the .bdcm file for the next few procedures, such as importing it into BCS on-premises and BCS online.

Import the BDCM file into the SharePoint on-premises BDC Metadata Store

After you have the .bdcm file, you need to import it into your SharePoint on-premises BDC metadata store by performing the following steps:

1. Upload the .bdcm file into your on-premises BCS service application through the Central Administration site. Just use the default options while importing via Central Administration.

   Alternatively, you can use the following Windows PowerShell script to import the BDC Model directly into your on-premises SharePoint BCS. Update the script with your SharePoint Central Administration URL and the path to your .bdcm file.

   $BDCMetadataObject = Get-SPBusinessDataCatalogMetadataObject -BdcObjectType Catalog -ServiceContext
   "http://SPCentralAdmin:44000"
   
   Import-SPBusinessDataCatalogModel -Identity $BDCMetadataObject -Path "D:\Temp\BDCmodel.bdcm"

2. After the file is imported into the on-premises BCS, you would need to grant permissions to the on-premises users to be able to use the BCS. For convenience, you could use the CONTOSO\ODataGroup security group and give them execute permissions, as shown in Figure 3-18.

   

   Figure 3-18: Set permissions on the ContosoCompanySales BDC Model in the on-premises BCS.

Make the BDC model file Office 365 tenant–ready

When you open the BDC Model (.bdcm) file in an XML reader, you would have noticed that the file has your OData service endpoint URL present in two places in the file. Because the SharePoint Online BCS uses its own connection details that you already configured in previous steps, you would have to remove these references in the .bdcm file and add a reference to the Connection name that was configured; for example, ODataOnPremises. BCS hybrid connections from Office 365 to the on-premises data source will not work if these steps are missed or improperly configured.

1. Make a copy of the .bdcm file that you'll be importing into Office 365.

2. In the .bdcm file, delete the ODataServiceMetadataUrl and ODataServiceMetadataAuthenticationMode properties from the LobSystem property list.

3. Again, in the .bdcm file, delete the ODataServiceUrl and ODataServiceAuthenticationMode properties from the LobSystemInstance property list.

4. Add this property to the list of properties for both the LobSystem and LobSystemInstance:

   <Property Name="ODataConnectionSettingsId" Type="System.String">ODataOnPremises</Property>

5. Save the .bdcm file and you are now ready to import it into the SharePoint Online BDC Metadata Store. Your .bdcm file should look similar to that shown in Figure 3-19.

   

   Figure 3-19: The .bdcm file updated and ready to upload to Office 365.

Import the BDCM file into the SharePoint Online BDC Metadata Store

When you import the BDC Model file into SharePoint Online, you must be logged in to the SharePoint Online administrator site as a federated or synchronized account (an account imported to Office 365 and synchronized with the on-premises Active Directory). This federated account must be a Global Administrator in Office 365. When importing the BDC Model to configure a hybrid BCS, certain calls are made to on-premises SharePoint farm that will require you use a federated user account. This account must also have a populated user profile in your on-premises SharePoint farm.

To import a .bdcm file into the SharePoint Online BDC Metadata Store, perform the following procedure:

1. Sign in to your SharePoint Online tenancy by using an account as described in the preceding paragraph, and then, in the SharePoint Online Admin Center, click “bcs.”

2. In the Business Connectivity Services section, click Manage BDC Models And External Content Types.

3. On the Edit tab, click Import.

4. Click Browse, and then browse to the .bdcm file that you exported.

5. Leave the default selections for File Type and Advanced Settings, and then click Import. During the import, BCS validates the XML in the model, queries the connection settings object, and connects to the on-premises OData source.

When you import a BDCM model into the BDC metadata service, you are creating an ECT. This ECT is available across your SharePoint Online in your Office 365 tenant.

Create an external list in your SharePoint Online site

The next step is to create an external list in your desired SharePoint Online site.

1. Open the SharePoint Online site where you want to create an external list. Ensure that the site has appropriate permissions configured to allow your ODataGroup users access to work with the LoB data within it.

2. In SharePoint Online, click Site Contents, and then click add an app.

3. Click External List, and then provide a name for the list; for example, Contoso Sales.

4. Click the Select External Content Type link next to the External Content Type box.

5. Select the external content type that you created, click OK, and then click Create.

6. Open the external list and confirm that your external data is displayed.

7. After the list is created, validate the scenario.

Validation steps for BCS hybrid

To validate the external list, ensure that you and the selected users are able to access it, as illustrated in Figure 3-20.

If your OData Source allows you to write back, you should be able to test creating, updating, and deleting content as another nonprivileged user who is part of the CONTOSO\ODataGroup.

To summarize, every user who will be reading, creating, and updating the external data must have three properties:

• He must have user or greater permissions to the SharePoint Online site and the external list or app for SharePoint.

• He must be a federated or synchronized account.

• He must be a member of the on-premises global security group that you are using to control access to the OData service endpoint; for example, he must be a member of ODataGroup.