The two different coding options both have advantages and uses when working with ECTs.

Server-side operations are concerned with processing the external data on the SharePoint server, as the name suggests. If a page requires any more information—for example, when a user chooses a category to see the products in it—then the page needs to perform a postback, where information is sent back to the server, and the server performs the new operation before sending the new content back to the browser to display on the page. Typically, server-side code is written in either C# or Visual Basic, and the SharePoint server itself executes the code and performs the required functionality. With the SharePoint server doing the main work, it is possible for developers to have more control of the ECT and its behavior. In Chapter 12, you will learn how to leverage server-side code to great effect.

Client-side code offloads most of the work to the client—that is, to the user’s computer—so that the load can be lessened on the server. The SharePoint server is still used to retrieve the data, but its role is changed to being the data provider rather than being in charge of displaying the data. In SharePoint 2010, you can use an extra Client Object Model, which allows you to create solutions that don’t need to be located on the server. You have different sorts of clients to consider when thinking about client-side versus server-side code with SharePoint—the client could be a browser, an Office application, or another standalone .NET application.

Client-side code is often used when presenting the data to an end user in a Web Part, application page, or desktop application, whereas server-side code can be used in workflows—for example, where a decision is made based on values in an external system. Essentially, server-side code does most of its processing on the SharePoint server, and client-side code performs its duties in a client, whatever that client may be.

Now that you know the differences between client-side and server-side code, you can start investigating working with external data on the client side. Next, you will look at how you can use the Client Object Model to create a web-based solution.

As mentioned previously, SharePoint 2010 offers developers a new programming object model to use when working with SharePoint: the Client Object Model. You can now create solutions that use only SharePoint to provide data, rather than being limited to server-side solutions. While it was possible to write client-side solutions in SharePoint 2007 by calling the exposed web services, it did not offer as much flexibility or functionality as in SharePoint 2010. It’s worth remembering that even though you are using the Client Object Model, some actions are still performed by the server.

Three flavors of the Client Object Model are available:

The following list describes a few scenarios for each of the Client Object Models:

The three platforms have been designed so their usage is very similar. They closely resemble the Server Object Model, providing a consistent, familiar means of developing against the different models.

The Client Object Model makes use of a SharePoint web service called Client.svc, which takes a request from the client, gets the requested information or performs the desired action on the server, and then returns the result. Figure 11-1 shows the information flow between the client and the server.

As shown in Figure 11-1, an XML request is built by the Client Object Model and passed to the Client.svc web service, which then performs the action using the SharePoint Server Object Model and returns a JavaScript Object Notation (JSON) object back to the client.

Figure 11-1. This diagram shows the flow of data when the Client Object Model interacts with SharePoint.

You have a few limitations when working with external data and the Client Object Model. This section explores some of these limitations and how you can use the Client Object Model to work with external data.

The Client Object Model cannot perform any actions directly on an ECT, so any actions on external data must be performed via an external list (see Chapter 5). When you use an external list, be aware of the following .NET types, which you are not able to use and are omitted from the list:

You can, however, use these fields with the BDC Object Model.

When using one of the Client Object Models, developers are able to write code against an external list as if it was a standard SharePoint list. There is no way to page or get chunks of data from the external list. It is not possible to run bulk operations, such as reading 25 instances simultaneously. Also, it is not possible to stream binary large objects (BLOBs), and complex associations cannot be used.

The following example demonstrates how you can use the Client Object Model to provide an alternate way of displaying products from the product list. Figure 11-2 shows the standard list, and Figure 11-3 shows how it looks with a little bit of Client Object Model coding in a Web Part.

Figure 11-2. This image shows an external list’s default view of a product’s ECT.

The Client Object Model is useful when retrieving data from SharePoint, but if you want to create an alternate way of interacting with the data, a framework such as jQuery makes this task a lot easier. In the next section, you will learn some of the functionality that can enhance the user’s experience of working with external data in the browser.

Figure 11-3. You can present the same product data in various ways.

This section’s example demonstrates how you can use jQuery to create a rich UI for working with external data from within SharePoint. jQuery is a JavaScript library that simplifies HTML coding tasks and provides a great partner to the Client Object Model.

Figure 11-4 shows an interactive page of business data, in which end users are allowed to drag and drop products from the list to a shopping cart, where the total cost for the order is displayed. You can easily implement drag-and-drop operations and other such features using jQuery.

You can also use jQuery widgets to help display your business data in a rich UI. For example, you could use the Accordion widget, which is part of the jQuery UI plug-in, to split products into their product categories to allow users to easily find products by expanding the relevant accordion menu (see Figure 11-5).

Figure 11-4. This simple jQuery-based shopping cart example shows how external data can drive client-side applications.

Figure 11-5. An accordion widget is being used to split products into categories, making it easier for end users to find the information they want.

When working with external lists, you are not restricted to just reading the information. As long as you created the methods on the ECT, it is also possible to update, add, and delete. Figure 11-6 shows an example of how an end user could use a custom UI to update the list price of some items.

Figure 11-6. As demonstrated in this example, you can create your own UIs to update external systems.

Editing a value and clicking the save icon reflects the changes back in the external system. For example, the first item, Mountain-100 Silver, 38, has a price of $3,399.99. Entering 2500 in the List Price box and clicking the save icon updates the LoB system with the new value of $2,500. Figure 11-7 shows the updated value in SQL Server.

Figure 11-7. The cost has been updated here from the custom updating UI.

There are many other ways you can use the Client Object Model in the browser to make business data accessible. The following are just a few examples of different ways to present your LoB data:

When creating a solution using the Client Object Model, whether it is using the JavaScript, Silverlight, or .NET Client Object Model, you are using the Client Object Model method to connect to your external system and you are working via SharePoint. The BCS Client Runtime allows for solutions that work directly with the external system, bypassing SharePoint, as shown in Figure 11-8.

Figure 11-8. The BCS Client Runtime allows a client application to directly connect to external systems.

You can use a couple of additional features in the BCS Client Runtime: BCS Cache and BCS Sync.

Using Microsoft Visual Studio 2010, you can create add-ins for most of the Microsoft Office client applications, as shown in Figure 11-9.

Visual Studio provides these out-of-the-box project templates:

In all these Office client applications, you can combine the power of these applications with data from an external system by using the BDC Client Runtime Object Model.

There are many different scenarios in which you can use the client runtime. For example, you can pull through data for a report in a Word document, analyze information in an Excel workbook, or graph the latest business data in a PowerPoint presentation.

Figure 11-9. Visual Studio provides project templates for Microsoft Office applications.

Creating a Visual Studio Tools for Office (VSTO) ClickOnce package is now much easier in Visual Studio 2010 than in previous versions with the VSTO Project types, which have all of the necessary files to add custom ribbon elements and begin to build the solution. In the example in this section, you will read and write data from an Excel document. The example solution makes use of the ribbon in Excel, but it could use a tool pane if that was required.

The example solution also makes use of the BCS Cache. As you learned in Chapter 7, it is possible to cache data from an external system for processing offline on a user’s computer and then have it synced back to the external system once the user is back online. SharePoint 2010 makes use of Microsoft SharePoint Workspace 2010 to synchronize the data. When you display an external list in the browser, on the Lists ribbon tab, in the Connect & Export group, click Sync to SharePoint Workspace, as shown in Figure 11-10. This command makes the list and the external data available to SharePoint Workspace, as well as to add-ins using the BDC Client Runtime.

Figure 11-10. You can take data offline using SharePoint Workspace.

When you click Sync to SharePoint Workspace, the dialog box shown in Figure 11-11 appears, warning you of the implications of synchronizing data on your computer.

Figure 11-11. A warning dialog box explains the issues with syncing to SharePoint Workspace.

When you click OK, the dialog box shown in Figure 11-12 opens, asking whether you want to install a package. The package contains the BDC model, and once you install it, the BCS Client Runtime directly connects with the external system.

With the deployment completed, you should see the list appear in SharePoint Workspace, as shown in Figure 11-13.

Figure 11-12. The VSTO that has been created gets installed on the local machine.

Figure 11-13. Once installed, the external list displays in SharePoint Workspace.

As mentioned previously, this example uses an Excel add-in to populate an Excel worksheet. In the following screenshot, you can see the new elements added to the ribbon. On the Data ribbon tab, there is a command in the BCS group to select the ECT, as shown in Figure 11-14. Once you select the ECT, click Get BCS Data to execute the ECT Finder method (operation).

Figure 11-14. You can find BCS-related commands in Excel on the Data ribbon tab.

The only ECTs available are those that you have made available. When writing against the BCS Object Model, it is possible to choose these methods of working with the ECT data:

To recap, the ECT Finder method is the method that returns all data from the external system. If a filter is being used, then you can add extra UI functionality to allow the user to enter one or more values, and those values would limit the amount of data returned. In this example, however, no filters have been defined, so all data is returned.

After you click Get BCS Data, the Finder method executes and populates the Excel worksheet with all of the information stored in the cache, as shown in Figure 11-15. Bringing the data into Excel enables you to easily analyze it.

Figure 11-15. This Excel spreadsheet is populated with data from the external system.

If you want to edit the data as a whole, Excel provides you with helpful features, such as data sheet view and the ability to update items in bulk. With this solution, you can use Excel to manipulate the data, and then using a combination of your own business logic and the BDC Object Model, you can easily update the information to your external system by clicking the Update BCS Data command on the Data ribbon tab, in the BCS group (see Figure 11-16). You can then write the information back to your external system.

Figure 11-16. Modifications made in Excel can be updated in the external system.

BCS enables information workers to surface ECTs, such as Customer, Employee, or Order, within Microsoft Outlook 2010 as a native Outlook item type, such as a Contact, Task, Post, or Appointment. You don’t need to write any code to do this—it can all be done declaratively. To do so, configure the ECT to map columns to the Office item columns, so that Outlook can parse the data when an external list is connected to it. In Microsoft SharePoint Designer 2010, on the Summary View of the ECT, in the External Content Type Information area, select an Office item type, as shown in Figure 11-17.

Figure 11-17. In SharePoint Designer, you can define the Office item type.

The fields of the SpecificFinder are the fields used by the consuming Office application. When you first create the method, you receive a number of warnings to set up some minimum mappings for the Office item mapping to work. For example, when the Office item type is Contact, you must map a column to either the LastName or FullName Office property, as shown in Figure 11-18.

Figure 11-18. For a Contact Office item type, map a return parameter to the LastName Office property.

Once you have configured all the columns and the ECT has been deployed, you can then use the ECT in Outlook via an external list by clicking Connect to Outlook on the List ribbon tab, as shown in Figure 11-19.

Figure 11-19. Click Connect to Outlook to use the ECT in Outlook via an external list.

A VSTO package is created, and it installs the required files into Outlook, making the contacts available. If the full CRUD methods have been created, you can read to and write from Outlook to the external system. As the tooltip shown in Figure 11-19 states, this data will be available through caching even when the user is offline. In Figure 11-20, the contacts are shown as if you had created a normal contacts list in Outlook.

Figure 11-20. Contact details stored in an external system are displayed in Outlook.

This method of pulling data from an external system into Outlook is known as a simple Outlook solution, where just the flat data is pulled through. But what happens if you want to be able to see all of a customer’s orders alongside their contact information, to save your users from changing systems to view this information? This is possible by progressing to an intermediate declarative Outlook solution. A couple more steps are required for the intermediate version, and some tools are available to help you out. Alternatively, you can write the necessary files to get the results you want. The following are two tools you will use in this example:

In this walk-through, you will see the different components required to create an intermediate declarative Outlook solution. First up is the BCS Artifact Generator. You can create the files generated manually, but for most situations, using the BCS Artifact Generator will meet your requirements or at least get you most of the way to a complete solution. As mentioned previously, this tool requires a BDC model that is used by the solution to work with your external system. In this scenario, you are pulling customer contact details and the customer order history. To create a master-detail scenario of customers and orders, create a BDC model using either SharePoint Designer or Visual Studio, with the two ECTs with an association method on the Orders ECT, which will get the orders for a particular customer.

Figure 11-21 shows that the ECT for the orders has the association defined.

Figure 11-21. You can define an association between customers and orders in SharePoint Designer.

The second ECT is the one used in the previous example, where the Customer ECT has its Office item type set to Contact. With the two ECTs configured, you need to export them so that they are both contained in one BDC model, and the BCS Artifact Generator tool can work with associations. From the External Content Types gallery in SharePoint Designer, select both ECTs by holding down the Shift or Ctrl key. Right-click and then select Export BDC Model, as shown in Figure 11-22.

Figure 11-22. Export the two ECTs in a BDC model using SharePoint Designer.

Both ECTs are saved in one BDC model file. This file is required for the next step, when you use the BCS Artifact Generator.

Run the BCS Artifact Generator tool. You are presented with a simple form, where you enter the location of the exported BDC model file and provide a name for the solution. The application will validate the model and display any error or warning messages in the Status text box, as shown in Figure 11-23, where a warning is shown. These errors are due to the fact that both the Order and the Customer ECTs used in this example have no filters defined. You’ll address this issue later.

Figure 11-23. Artifact Generator validates the BDC model and displays error and warning messages.

Click Next to show all the ECTs defined in the BDC model and some information about them. To see the associated orders for a customer, you customize the imported BDC model and “declaratively” tell Outlook to generate a task pane to contain the information.

The customization process starts a wizard that takes you through up to three pages. Click Customize to the right of the Customers ECT to start the wizard and display the Item Details page, where you can configure the Display Name and Icon settings. Click Next.

When an association is defined in the BDC model, the BCS Artifact Generator displays the Taskpane page so it can create a form automatically for you to show the data from the associated ECT, which in this example is Orders, as shown in Figure 11-24. However, you can also create your own form using InfoPath to display the information to suit your business requirements and choose the region in which the information is displayed. In that case, select Display Related Item Details in InfoPath Form, and then specify the location of the InfoPath form.

Figure 11-24. You can use Artifact Generator to create a custom task pane.

Once you have selected Add a Custom Taskpane, accept the default, and then click Next to display the Action page. You can add actions and ribbons to Outlook to enhance the way in which the ECT can be used; for this example, however, you are interested only in showing the related data. When the wizard is completed, you are returned to the overview page, where you confirm that the settings are updated, as shown in Figure 11-25. Notice that Customers is an Outlook Contact type, the custom region will be autogenerated, and there will be a task pane.

Figure 11-25. The artifact for the Customer ECT is configured to autogenerate a region and to create a task pane.

Click Generate Artifacts to create the files, as shown in Figure 11-26. These artifacts include subscription files, an OIR file, the BDC model file, and a relationship file.

Figure 11-26. Without the Artifact Generator tool, you would need to write these files manually. You can edit them if you need further customization.

To package the files generated by the BCS Artifact Generator, use the BCS Solution Packaging tool. The Packaging tool takes the artifacts and generates a ClickOnce package to allow you to deploy the intermediate declarative Outlook solution.

The BCS Solution Packaging tool, as shown in Figure 11-27, allows you to name the solution, provide a version number, select a solution type such as Outlook Intermediate Declarative Solution, point the source folder path to where the artifact files are located, and then choose a path where you want the packaged files to be created.

Figure 11-27. Use the BCS Solution Packaging tool to package the artifact files created by the BCS Artifact Generator tool.

You are able to sign the file; doing so removes the security warning when the package is used. It also indicates to end users that this solution comes from a trusted source.

In the Packaging section, click the Package button to create the necessary files to deploy the solution. You can then either take a look at the generated files or deploy them to your current environment to test them out immediately. Once you have created a package, the Deploy button in the Deployment section of the tool becomes active. Clicking Deploy installs and opens Outlook, where you can see the Customer Orders solution alongside the standard Outlook items, as shown in Figure 11-28.

Figure 11-28. You can see here that the Customer Orders solution has been deployed to Outlook.

Currently, you have the same level of functionality as you had earlier when you clicked the Connect to Outlook button on the Lists ribbon tab for an external list. However, if you double-click a contact, in the detail view you can see a pane that shows the contact’s orders (as shown in Figure 11-29).

Figure 11-29. The custom pane is now providing more information on the contact form.

It is very useful to be able to supplement Outlook with business data using a declarative solution that doesn’t require you to write any code, yet can make good use of your business data. If you want more control, you can write an add-in and further tailor your end-user experience, or you can add custom business logic and still have your end users using the familiar Outlook interface.

To make this solution available to your SharePoint users, simply put the files and folder in the same format in which they were created by the tool into a document library, as shown in Figure 11-30.

Figure 11-30. These files are required to install the VSTO you want to make available in SharePoint.

The easiest way to add the files is to use the multiple upload functionality of a document library, as shown in Figure 11-31. This allows the files to be dragged from Windows Explorer onto the dialog box.

Figure 11-31. Use the document library multiple upload function to add the package.

After you’ve uploaded the files in a document library, provide a link to the VSTO file in an email or on a page. A user can then click the link to install the package. Usually, though, developers add a command button on the ribbon that points to a link to the package, providing users with a similar experience to the Connect to Outlook command. Once the user clicks the link, the Microsoft Office Customization Installer dialog box opens and asks the user to confirm the installation, as shown in Figure 11-32.

Figure 11-32. Clicking the VSTO prompts the user to install the package.

In addition to creating intermediate declarative Outlook solutions, you can also create advanced solutions, which allow you to use code for greater control and enable further customization of the user experience using BCS with Outlook. The types of solutions you can create include code-based actions that allow for greater meshing between the data and Outlook. For example, you can create an Outlook task to follow up with a customer or add information to the Outlook Calendar. Another possibility is to create data parts, which give you the opportunity to create a user control element in which to interact with the data in ways above and beyond what you are able to do declaratively.