Consuming SQL Azure Data : Introduction to Business Connectivity Services

1. What Is Business Connectivity Services?

Information workers (IWs) often require access to all different types of structured and unstructured LOB data that live in disparate systems such as SAP, Microsoft Dynamics, or PeopleSoft. This presents a number of key challenges for IT staff when serving IW needs. For example, to bring data from these systems together in a unified and seamless way is challenging; to maintain the cost of building, supporting, and training can be prohibitive; and productivity is lost as end users context-switch across different applications.

Bringing these systems together is one of IT’s greatest challenges. It’s important that IWs have access to this data, which can be both legacy and current, in a way that keeps them productive. Productivity, however, is but one pivot in the IT challenge; ensuring costs, both software and hardware, are kept in check is another consideration that must be held in front of IT planning.

To help alleviate the burden in this integration, SharePoint 2010 introduced BCS as a way to integrate external data from systems such as SAP and PeopleSoft with SharePoint. This integration manifests itself in ways that were not possible in past releases of SharePoint; you can now integrate with CRUD (create, read, update, and delete) operations to manage data that lives in an external system directly from within a SharePoint list. This new type of list is called an external list. It looks and feels like an ordinary list but operates much differently. For example, Figure 1 shows an external list—but the data is loaded only when SharePoint loads the page that contains the list. So if you’re loading data from an external system into SharePoint, when SharePoint loads the page, it also calls the external system to make a request, and then loads the resulting data from that system.

With BCS, you can integrate Microsoft ADO.NET connections (to systems such as SQL Server), web services (to SOAP-based ASMX services), and Windows Communication Foundation (WCF) services (to WCF services deployed to IIS, Windows Azure, or other locations). Further, BCS provides a way for you to surface external data in both SharePoint and Microsoft Office, map external data to Office, create read-only views of the data in Microsoft Access and SharePoint Workspace, integrate external data directly into Microsoft Outlook, reuse data connectors across the server and client, and bridge the world of structured/unstructured data with the IW through BCS solutions.

As an example, consider a sales professional who must look up customer information from a customer relationship management (CRM) system such as Microsoft Dynamics CRM, and then needs to get that information into SharePoint or Office documents. To do that, the salesperson must copy field-level data from the CRM system and paste it into SharePoint or Office. This copy-and-paste process results in lost time, and the manual process of moving data from one system to another can be error prone. If you instead create a direct connection from the Microsoft Dynamics CRM system by using BCS, when you load a document or open a list in SharePoint, the data from the external system (in this case Microsoft Dynamics CRM) is loaded into SharePoint or Office automatically. There is no copy and paste to worry about. And the IW can then engage with the document by using the customer information without the worry of errors, lost time with copy and paste, or other issues that might arise as a part of the manual process.

BCS is not just about integrating CRM data either: you can connect enterprise resource planning (ERP) data or supply chain management (SCM) data, or even take unstructured data and create a reporting mechanism through the process of modeling that unstructured data in Microsoft Visual Studio. Thus, BCS provides a flexible way to primarily manage structured data from external systems into SharePoint and Office, but it also enables you to integrate unstructured data (such as data from blogs, wikis, Twitter, and so on) as well.

To give you a better sense for how you can integrate with data and services by using BCS, Figure 3-2 provides you with a high-level architectural view of the different types of APIs and clients you can use (whether you’re using SharePoint or Office) and the different services and data that you can model using BCS. For example, in Figure 2 you will see that you can use REST feeds to retrieve web data if you want to; this gives you the ability to retrieve Twitter data and then model this for presentation within SharePoint. Likewise, you can integrate with WCF services, which makes it easy to connect with Windows Azure.

Although Microsoft SQL Azure is not an ERP system such as SAP, or a CRM system such as Microsoft Dynamics CRM, it does manage data that is external to SharePoint and Office and has a separate set of credentials (that is, a user name and password that connect a user to a separate database server in the cloud) that must be managed. SQL Azure is our external data system. And much like you would interact with an instance of SQL Server with an on-premises application, you’ll build and deploy a cloud-based SharePoint solution that leverages BCS to integrate with SQL Azure data.

Note:

More Info For more in-depth information on Business Connectivity Services, visit http://msdn.microsoft.com/en-us/library/ee556826.aspx.

2. External Content Types

When you use BCS to create a connection between SharePoint and an external system, you create what is called an external content type (ECT). An ECT is, in essence, an XML file that defines the relationship that exists between the external system and SharePoint and Office by representing properties such as the entities within the external system (for example, Customer entity), the operations that you want to manage against the external system (for example, Read, Write, and so on), and the type of authentication with the external system (for example, PassThrough). The ECT is the key artifact that has advanced the BCS to being what it is today: a flexible connection to structured and unstructured external systems.

You create an ECT by using SharePoint Designer 2010 or Visual Studio 2010. When you use SharePoint Designer 2010, you declaratively create an ECT and then directly save it into the BDC Metadata Store in SharePoint. When you create an ECT using Visual Studio 2010, you have a more flexible and structured approach as a developer using a code approach, but rather than saving the ECT, you deploy it as a Microsoft .NET Framework assembly into SharePoint; then it is automatically added as a feature to SharePoint and the ECT is also added to the BDC Metadata Store.

A number of properties exist within the ECT that are key to establishing the connection to the external system. Although there are many elements within the ECT, some of the core elements are described as follows:

• LobSystem An external data source, service, or software system.

• LobSystemInstance Specific implementation of the LobSystem.

• Entity Describes the structure of the business entity or object. It contains one or more Methods, fields (or TypeDescriptors), and a unique Identifier, and is made up of specific data types.

• Methods Describe the back-end APIs with MethodInstances being the specific implementation of a Method. Methods can also contain filters (defined through the FilterDescriptor).

• Parameters Defined through a TypeDescriptor and DefaultValue.

• AssociationGroup Defines relationships across back-end systems.

The XML code in Example 1 shows a simple ECT. You can see that there are a number of elements that make up this ECT, which have their own properties. For example, in this ECT, the LOBSystem is called SQLAzureForSharePoint, and it’s of type DotNetAssembly. Further, it has been built using a generic entity (for example, custom class) called Entity1. The ECT has many more properties, and if you’d like to learn more about these properties, visit http://msdn.microsoft.com/en-us/library/ee556391.aspx.

Example 1. Sample ECT XML

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Model  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns="http://schemas.microsoft.com/windows/2007/BusinessDataCatalog"
        Name="SQLAzureForSharePoint">
  <LobSystems>
    <LobSystem Name="SQLAzureForSharePoint" Type="DotNetAssembly">
      <LobSystemInstances>
        <LobSystemInstance Name="SQLAzureForSharePoint">
        </LobSystemInstance>
      </LobSystemInstances>
      <Entities>
        <Entity Name="Entity1" Namespace="C3_SQL_Azure_For_BDC.SQLAzureForSharePoint"
            EstimatedInstanceCount="1000" Version="1.0.0.0">
          <Properties>
            <Property Name="Class" Type="System.String">
               C3_SQL_Azure_For_BDC.SQLAzureForSharePoint.Entity1Service,
               SQLAzureForSharePoint</Property>
          </Properties>
          <Identifiers>
            <Identifier Name="Identifier1" TypeName="System.String" />
          </Identifiers>
          <Methods>
            <Method Name="ReadList">
              <Parameters>
                <Parameter Direction="Return" Name="returnParameter">
                  <TypeDescriptor TypeName="System.Collections.Generic.IEnumerable`1
                      [[C3_SQL_Azure_For_BDC.SQLAzureForSharePoint.Entity1,
                      SQLAzureForSharePoint]]"
                       IsCollection="true" Name="Entity1List">
                    <TypeDescriptors>
                      <TypeDescriptor
                           TypeName="C3_SQL_Azure_For_BDC.SQLAzureForSharePoint.
Entity1, SQLAzureForSharePoint" Name="Entity1">
                        <TypeDescriptors>
                          <TypeDescriptor TypeName="System.String"
IdentifierName="Identifier1" Name="Identifier1" />
                          <TypeDescriptor TypeName="System.String" Name="Message" />
                        </TypeDescriptors>
                      </TypeDescriptor>
                    </TypeDescriptors>
                  </TypeDescriptor>
                </Parameter>
              </Parameters>
              <MethodInstances>
                <MethodInstance Type="Finder" ReturnParameterName="returnParameter"
                    Default="true" Name="ReadList" DefaultDisplayName="Entity1 List"/>
              </MethodInstances>
            </Method>
            <Method Name="ReadItem">
              <Parameters>
                <Parameter Direction="In" Name="id">
                  <TypeDescriptor TypeName="System.String" IdentifierName="Identifier1"
                       Name="Identifier1" />
                </Parameter>
                <Parameter Direction="Return" Name="returnParameter">
                  <TypeDescriptor
                       TypeName="C3_SQL_Azure_For_BDC.SQLAzureForSharePoint.Entity1,
                       SQLAzureForSharePoint" Name="Entity1">
                    <TypeDescriptors>
                      <TypeDescriptor TypeName="System.String"
IdentifierName="Identifier1" Name="Identifier1" />
                      <TypeDescriptor TypeName="System.String" Name="Message" />
                    </TypeDescriptors>
                  </TypeDescriptor>
                </Parameter>
              </Parameters>
              <MethodInstances>
                <MethodInstance Type="SpecificFinder"
ReturnParameterName="returnParameter"
                   Default="true" Name="ReadItem" DefaultDisplayName="Read Entity1"/>
              </MethodInstances>
            </Method>
          </Methods>
        </Entity>
      </Entities>
    </LobSystem>
  </LobSystems>
</Model>

					  

Warning:

Important The lines in bold code in the preceding listing have been wrapped to meet page size restrictions, but in your code, the quoted strings in those tags must appear on a single line.

Now that you have been introduced to BCS and ECTs, the next sections walk you through four different practical examples that each use SQL Azure in some way. In the first, you’ll create a small database in SQL Azure. This exercise represents the process of creating a database that can be treated as an external system. In the second example, you’ll create an application ID that you can use to connect securely to the SQL Azure data source by using SharePoint 2010. In the third example, you’ll create an ECT by using SharePoint Designer—connecting SharePoint to your SQL Azure instance via the application ID and then setting the permissions for the ECT by using SharePoint Central Administration. The fourth and final walkthrough shows how you can use Visual Studio 2010 to create a Visual Web Part that connects to SQL Azure to illustrate a second way to consume SQL Azure data in SharePoint.