Now you’ll take some time to explore the user interface (UI) to understand the different components you use to configure the BDC model. You won’t make any changes to the default “Hello World” model you have at the moment, to make things easier to understand. The first item to look at is the visual representation of the ECT on the design surface, as shown in Figure 12-6.

Figure 12-6. The Entity1 ECT is shown on the design surface.

The design surface with the ECT that you can see in Visual Studio is the BdcModel1.bdcm file. To view any BDC models in your solution, simply double-click the *.bdcm file to open it in this designer view.

Taking a look at the Entity1 ECT, notice that it has an identifier defined called Identifier1 and it has two methods: ReadList and ReadItem. As you know by now, the identifier is the type descriptor that uniquely identifies a row of data in your external data and must be returned by each method. The names of the two methods give you a clue as to their method type: ReadList is the Finder method, and ReadItem is the SpecificFinder method. To confirm the method types, use the BDC Method Details tool pane at the bottom of the design surface (you may need to click its tab to display it). If you do not see the tool pane, go to the Visual Studio Menu toolbar at the top of the application and navigate to Views, click Other Windows, and then click BDC Method Details. The tool pane that displays looks similar to the one shown in Figure 12-7. Make sure the ECT is selected on the design surface.

Figure 12-7. View method details for the Entity1 ECT in the BDC Method Details tool pane.

In this view, you can see the two methods, ReadList and ReadItem, and for each method you can see the parameters, instances, and filter descriptors. For now, you are only interested in instances; you will look at the rest later. Click the ReadList line under Instances (not the one at the top; rather, the one six lines down from there). When you click this method instance, you can see its properties in the Properties tool pane, as shown in Figure 12-8. If the tool pane doesn’t appear, press F4 to display it or find it under the Views menu.

Figure 12-8. View the method instance type in the Properties tool pane.

If you click the identifier on the ECT, you will see that its properties also display in the Properties tool pane. You can see both the identifier name and its data type, System.String. This is where you will configure various properties of the model later on.

So far, you have seen what the ECT looks like on the design surface and the information it offers. You have also viewed some of the properties of the model. The last thing to look at before writing your own ECT is the BDC Explorer tool pane. The BDC Explorer provides an overall view of the structure of the ECT and a means of working with the type descriptors of the model. When you work with a table as a data source, there is usually a simple mapping of one column to one type descriptor; however, as you will learn, you can add your own independent type descriptors to add more data to the ECT. You can access the BDC Explorer through its tab to the right of the Solution Explorer. If you do not see the BDC Explorer tab there, you can locate it through the Views menu. Figure 12-9 shows the BDC Explorer displaying the “Hello World” model.

Figure 12-9. The BDC Explorer shows the “Hello World” model.

You can click the various nodes in the BDC Explorer to easily access the properties of the BDC model.

You should now have a good sense of the BDC connector environment before diving into the code. There is a tight correlation between the code and the model, so it is important to understand where properties are configured.

Go ahead and delete the Entity1 ECT—it’s had its time in the spotlight. Now it’s time to create one with code. You should now have a blank design surface. Before you can move ahead, you’ll need to complete some housekeeping tasks. In the Solution Explorer, you’ll find two *.cs files to delete (see Figure 12-10). These are the C# code files that were used by the ECT that you just deleted.

Figure 12-10. Delete these redundant C# files.

After you delete the two .cs files, you should rename the model to something more appropriate than BdcModel1. Change to the BDC Explorer view and click the first node, BdcModel1. In the Properties pane, update the name to BdcConnectorProductModel, and also update the rest of the nodes to match Figure 12-11. These changes will help you identify the model and ECTs when using them inside of SharePoint.

Figure 12-11. The BDC Explorer shows the current model structure.

Now it’s time to create an ECT. Right-click the design surface, click Add, and then click Entity. You can also drag an Entity toolbox item from the Toolbox.

Because this ECT will be used for product exchange rates, name it ProductExchangeRates. You can set the display name separately to make it easier for end users to read, but for the sake of the code, the name shouldn’t contain any spaces. To set the display name, click the ECT and change the Default Display Name in the Properties tool pane. If you look at the Solution Explorer, you should see that a file called ProductExchangeRatesService.cs has been automatically generated, as shown in Figure 12-12.

Figure 12-12. The ProductExchangeRatesService.cs file has been automatically generated.

This service class is the class used as the data access layer to the external system. As methods and some changes are added to the BDC model, this file also gets updated. Visual Studio is writing the signature for the method for you to just enter the code logic to return the required data. If you look into the file now, you will see that it is just an empty C# class.

When you deleted the files from the Entity1 ECT earlier, you may recall that there were two files: a service class, like you have now, and another file. The second file is a class that defines the data you are getting from your external system. Essentially, you are building a strongly typed class that defines an ECT. To put this into simple terms, you need to think about the data you want to display in SharePoint. For this scenario, you want to return products with different exchange rates, so you will create a C# class that defines what a “product” in this context looks like.

In Solution Explorer, right-click the BdcModel1 folder, click Add, and click New Item. From the Code node, click Class, name it Product.cs, and click Add. Now you have an empty C# class to which you can add the necessary code to define what a product is. Because some of the data is coming from SQL Server, navigate to the SQL table using SQL Server Management Studio and have a look at the column types of the columns you are interested in. Figure 12-13 shows the view in SQL Server Management Studio.

Figure 12-13. View the column setup for the Product table.

The columns you are interested are ProductID, which is the primary key and has a type of Integer (int), Name (nvarchar(50)), and ListPrice (money). To add these properties to your C# code, you need to understand what their .NET equivalents are. A useful table available on MSDN presents the conversions: http://msdn.microsoft.com/en-us/library/ms131092.aspx. Some of the .NET types have Nullable<Type>, which is used when the standard .NET type expects to have a type. Usually it causes an error if, for example, a property of type Int (a number) is set to a null value (that is, no value). Using Nullable allows it to have no value. This is useful when you may not have all the values completed in your table—for example, say you have a database that contains people data, and one of the fields is Age, an optional field. If users have opted not to provide their age, then the value is null; it doesn’t exist. If you don’t use Nullable in this example, and SharePoint tries to set the Age property to null, it will throw an exception, whereas if you do use Nullable, SharePoint will allow the Age property to contain no value.

Converting the columns gives you the properties in Table 12-1, which you will add to the C# class.

The following code for the C# file shows that Product.cs was added:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ProductExchangeModel.BdcModel1
{
    public class Product
    {
        public int ProductId { get; set; }
        public string Name { get; set; }
        public decimal Price { get; set; }
        public decimal PriceInPoundSterling { get; set; }
        public decimal PriceInYen { get; set; }
    }
}

When you write the names of these properties, they do not need to match the names of the columns in the SQL table. You should remember that the data used to populate this object that you are calling a “product” could come from anywhere and could include as many or as few properties as needed. An external system could be just code or a hybrid such as this one, with a SQL table and code. Although these property names don’t have to match the source’s name, they do need to match the type descriptors in the BCS model. Naming the type descriptors is often where issues arise when building BCS models, and it is simply a case of a type descriptor not matching a property name perfectly (spelling, casing, and so on).

Now that you have defined what a Product ECT will look like in code, you can configure the BCS model to match by adding an identifier, a Finder method, and a SpecificFinder method. The identifier (the type descriptor that uniquely identifies a row) is the ProductId. You can add this identifier to the ECT by right-clicking it, clicking Add, and then clicking Identifier. By default, the identifier is called Identifier1 and its type is System.String, as shown in Figure 12-14.

Figure 12-14. The identifier properties can be viewed in the Properties tool pane.

This doesn’t match up with the identifier you want defined in the code: ProductId, with the type name System.Int32. Update the Properties pane to reflect your Product class, as shown in Figure 12-15. Don’t forget to check that the name matches the actual property’s name and ensure that the type is identical as well. Also set the Display Name to make it easier to understand what the column represents when it is used in SharePoint.

Figure 12-15. Updated properties for the identifier.

Next, you’ll add your first method to the model. Right-click the ECT again, and this time click Add, and then click Method. Call the new method GetAllProducts, as this will be the Finder method that gets all of the products.

You can edit the properties of the method to add a default display name, so your end users know what’s going to happen when they call this method. Entering Get All Products will suffice.

If you take a look at the BDC Method Details pane for the new method, you will see it is empty, as shown in Figure 12-16.

Figure 12-16. The newly created method before configuration.

Now you’ll add some more properties to the method to describe its behavior. First, you’ll look at the parameters. When creating a basic Finder method, the only parameter required is a Return parameter. The majority of the time, a method has either an In and a Return parameter or just a Return parameter. An In parameter defines in the model that a value is going to be passed into your query. For example, if you have a filter, then you will be passed in the value to filter by. The SpecificFinder, as you will see later, gets passed in the identifier of the item to get from your external system. The Return parameter defines what data SharePoint can expect to be returned from your code, such as a Finder method returning a collection of items from your external system or a SpecificFinder returning just a single item from your external system.

Click the <Add a Parameter> text, and then click Create Parameter to create an In parameter (helpfully called “parameter” by default). You will want to change its name and also change the type to Return. Open the Properties tool pane and amend it to match Figure 12-17.

Figure 12-17. The parameter has been configured.

With a Return parameter defined, you now need to define what is being returned. The easiest way to do this is using a combination of the BDC Explorer and the Properties tool pane. If you take a look at the BDC Explorer pane now, you will see the parameter that you have just added (see Figure 12-18).

Figure 12-18. The BDC Explorer displays ReturnParameter.

A type descriptor has been created for you, but you will need to do some work to make it fit with your requirements. As mentioned previously, type descriptors define the structure of the data that is going to be returned by your code, and this is where you define what that structure looks like. A Finder method typically returns a collection of objects (a Product), which have properties (Name, Cost, and so on). You will need to configure your type descriptors to reflect this detail, and its structure will look something like the following:

I am going to be returning a list of Products

This is a Product

This is a property of a Product

The default type descriptor created for you is defined to say that when the method is called, a single item—a string—will be returned, as shown in Figure 12-19.

Figure 12-19. The default Return parameter type descriptor with a string type.

Rename the parameter to ProductsList, as you want to return a list of products. Click the Type Name, and then click the little arrow on the right to open a dialog box where you can select the type of data being returned. In this dialog box, you will set the outer level of data you are returning to be a collection of products. Not just any products, though—a collection of our C# code definition of products. As shown in Figure 12-20, select the Is Enumerable check box to return enumerable data (a collection that can be iterated over) and select the Product class.

Figure 12-20. Select the custom Product class as an enumerable type descriptor.

Once the outer type descriptor has been created, you’ll add a type descriptor to the ProductsList type descriptor to define what each of the items is inside of the collection. Right-click ProductsList in the BDC Explorer and click Add Type Descriptor to add a sub–type descriptor. This time call it Product, and set its Type to just Product, without selecting the Is Enumerable check box.

You’ll now add the properties of a Product to the product definition. At the moment, the model doesn’t contain a definition of a Product, so you need to define it. Right-click Product and choose Add Type Descriptor. Do this four more times, making sure you’re adding the type descriptor to Product each time (see Figure 12-21).

Figure 12-21. The Product with five type descriptors defined.

You added five type descriptors to define each property in your C# class, as shown in Table 12-2. For each type descriptor, you should edit the properties so the name exactly matches the name in the C# class, and also set the Type to match.

Once you have set the values, the BDC Explorer should look like Figure 12-22.

Figure 12-22. Configure the type descriptor names to match the property names in the C# class.

The final step is to let SharePoint know that this method is returning the identifier. To do so, select the ProductId type descriptor, and in the Properties pane, set Identifier to ProductId, as shown in Figure 12-23.

Figure 12-23. Setting the identifier for the ProductId type descriptor.

As mentioned previously in this book, you should always consider working with the smallest subset of data you can when working with BCS. There is no point pulling superfluous data across your network and taking up both resources and bandwidth. You have seen how to add filters using SharePoint Designer; in this section, you will look at how to add filters when building a BDC model in Visual Studio.

In this scenario, you will add a Limit filter and a Wildcard filter. The Limit filter will limit the number of items returned from the external system that match the Product Name specified by the Wildcard filter. To configure the method with a Limit filter, you need to add a filter descriptor and In parameter for the Limit and Wildcard filters.

Open the BDC Method Details tool pane for the GetAllProducts method and click the <Add a Filter Descriptor> text. Click Create Filter Descriptor to add a new filter descriptor called FilterDescriptor. You will want to configure the properties shown in Table 12-3.

With the Limit filter descriptor added, you will add the Wildcard filter in the same way, this time using the property values listed in Table 12-4.

Now you’ll add the two In parameters. The value for the Limit filter will have a default value assigned to it, but you will be able to configure it inside SharePoint. The Wildcard filter will get its value set by the end user, or you could configure it with a static value inside SharePoint.

Back in the Parameters section of the BDC Method Details pane, add a new parameter called LimitParameter and set its direction to In. Add a new parameter for the Wildcard filter, called WildcardParameter, and again set its direction to In.

It is now time to configure the type descriptors that let SharePoint know the data that is going to be passed into this method. Navigate to the BDC Explorer and locate LimitParameter under the Get AllProducts method node. Table 12-5 lists the properties to configure for the type descriptor.

The Limit filter will take a number of items to return, so set its Type to Int32. The Associated Filter tells SharePoint where it should use the value that is passed in to this parameter. Next, configure the Wildcard parameter as shown in Table 12-6.

The final step is to add the method instance. Here you are defining in the model the type of the method, whether it is the default method, the parameter that is being returned, and its display name. In the BDC Method Details pane, click <Add a Method Instance>, and then click Create Finder Instance. Set the properties for the method instance to values listed in Table 12-7, leaving the rest the same.

You are specifying the Return parameter to the first parameter you created; this is the one that returns the collection of Products and defines what a single property consists of.

The Finder method has now been configured with regard to the model. Next, you will add the SpecificFinder method, which allows the end user to select a single record. If you want to be able to use your ECT with an external list, make sure you have these two methods at a minimum.

There are quite a few steps involved in creating the SpecificFinder method. Some of the tasks are easier, because you have already done some of the legwork. Add a new method to the ProductExchangeRates ECT, and call this new method GetSingleProduct. Your ECT should now look like Figure 12-24.

Figure 12-24. Add a new GetSingleProduct method to the ECT.

For a SpecificFinder method to function, it needs to receive the identifier that uniquely defines a record, so the first thing you will need to do is add an In parameter. As before, select the method and open the BDC Method Details pane. Make sure you find the correct GetSingleProduct method, as this pane now shows both the Finder method and the newly created method. You can minimize the method you’re not interested in by clicking the hyphen (-) next to the method name of the Finder method. Add a new parameter with the property configuration shown in Table 12-8.

By making these simple changes, you can add the Return parameter to the new parameter. This time, however, the parameter will define a single object that your method will return, which is a Product (see Table 12-9).

The parameters are added for both accepting data into and returning data from the method. Next, you will define the type descriptors to use. Go to the BDC Explorer and expand all of the method, parameter, and type descriptor nodes, as shown in Figure 12-25.

Figure 12-25. Showing the parameters for the methods so far.

The first node to tackle is InParameterTypeDescriptor. This type descriptor must match the identifier defined in our code, both the name and the type. As this value is also the identifier, you must set it, too (see Table 12-10).

This is all that is required. It is worth noting that a SpecificFinder does not use a filter descriptor to get the single item; it just uses an In parameter.

Now you will configure the ReturnParameter. Last time, you needed to add the outer type descriptor that defined the collection, and under that, you defined the Product. With the SpecificFinder returning only a single item, you don’t need to add the outer level. A neat feature in Visual Studio is that you don’t need to create the Product structure again, since you can just copy it from the Finder method’s type descriptor. Right-click Product under the ProductsList type descriptor and click Copy, as shown in Figure 12-26.

Figure 12-26. Copying the type descriptors.

With the type descriptors now on the clipboard, you can right-click the ReturnParameter of the SpecificFinder method and paste the type descriptors (see Figure 12-27). You will get a warning that you will replace the existing one. Click Yes.

Figure 12-27. The type descriptors have been copied.

This is all you need to do for the type descriptors. You have defined the In parameter type as the identifier, and you have also defined the single object that is being returned by the method. You can now move on to add the method instance using the BDC Method Details pane. In the Instances section, add a new method instance and update its properties, as shown in Table 12-11.

That’s it—the BDC model is now configured to support both a Finder and a SpecificFinder method. Before you can use the model in SharePoint, you need to write the code to retrieve the data.

While you have been configuring the BDC model, Visual Studio has been maintaining the file called ProductExchangeRatesService.cs in the Solution Explorer with the method signatures required by the BDC model. The automatic signature generation makes writing the code a good deal easier, as it is easy to see the parameters being passed into the method as well as the return type. The code generated for the model should look like the following:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ProductExchangeModel.BdcModel1
{
    public partial class ProductExchangeRatesService
    {
        public static IEnumerable<Product> GetAllProducts(int LimitParameter, string
WildcardParameter)
        {
            throw new System.NotImplementedException();
        }        public static Product GetSingleProduct(int InParameter)
        {
            throw new System.NotImplementedException();
        }
    }
}

We have two methods in the code that match the methods that were created in the model. The first method, GetAllProducts, is the Finder method. It has two parameters, one for the Limit filter and another for the Wildcard filter value. You can also see that the method is returning a collection of Products, just as we specified. The SpecificFinder method has a parameter for the ID, and this time it will return just a single Product.

It is worth reiterating at this point that the model and the code are completely independent from any external system. All you have done is configured a model that defines the concept of a ProductExchangeRate ECT. If you want to make this ECT get its data from any single external system, or even pull data from numerous systems, this is all possible in the code. If the .NET Framework can get the data, then you can use it here. For now, though, you will continue with the scenario of getting some of the data from SQL and enhancing it with some exchange-rate calculated data.

For the sake of brevity, you will use a generic method to get your data to help demonstrate how this data could come from anywhere. The code also uses a method called GetExchangeRate, which could perform any functionality you want to on your data before presenting it to SharePoint.

The following code is an example you can use for the Finder method:

        /// <summary>
        /// Finder Method
        /// </summary>
        /// <param name="LimitParameter">Limit Filter</param>
        /// <param name="WildcardParameter">Wildcard</param>
        /// <returns>Collection of Products matching filters</returns>
        public static IEnumerable<Product> GetAllProducts(int LimitParameter, string
WildcardParameter)
        {
            // Get the items from the External System(s)
            IEnumerable<DataAccessLayer.ExternalSytemProduct> externalSystemProducts =
                DataAccessLayer.GetProductsFromExternalSystem(LimitParameter,WildcardParameter);

            // Get Exchange rate for pound sterling
            decimal poundSterlingExchangeRate =
CurrencyHelper.GetExchangeRate(Currency.PoundSterling);

            // Get the Exchange rate for Yen
            decimal yenExchangeRate = CurrencyHelper.GetExchangeRate(Currency.Yen);

            // Return collection of Products created from External Data and own values
            return externalSystemProducts.Select(
                externalSystemProduct => new Product
                                             {
                                                 ProductId = externalSystemProduct.ProductID,
                                                 Name = externalSystemProduct.Name,
                                                 Price = externalSystemProduct.ListPrice,
                                                 PriceInPoundSterling =
externalSystemProduct.ListPrice * poundSterlingExchangeRate,
                                                 PriceInYen = externalSystemProduct.ListPrice *
yenExchangeRate
                                             }
                );
        }

The code is passing the filters to a custom method that will call the external system and retrieve the matching data. The code also has methods that call another method to get the exchange rates you are interested in. The final step is to iterate through each item returned from the external system and to create a Product object that we have defined in your own Product.cs class and is also the object that the BDC model has been configured to expect.

For the SpecificFinder method, the code is fairly simple. You are passing in the identifier to get one item that you then convert to a Product and set its properties.

        /// <summary>
        /// Specific Finder Method
        /// </summary>
        /// <param name="InParameter">Identifier</param>
        /// <returns>Single record with matching Identifier</returns>
        public static Product GetSingleProduct(int InParameter)
        {
            // Get the items from the External System(s)
            DataAccessLayer.ExternalSytemProduct externalSystemProduct =
                DataAccessLayer.GetSingleProductFromExternalSystem(InParameter);

            // Get Exchange rate for pound sterling
            decimal poundSterlingExchangeRate =
CurrencyHelper.GetExchangeRate(Currency.PoundSterling);

            // Get the Exchange rate for Yen
            decimal yenExchangeRate = CurrencyHelper.GetExchangeRate(Currency.Yen);

            // Return collection of Products created from External Data and own values
            return new Product
            {
                ProductId = externalSystemProduct.ProductID,
                Name = externalSystemProduct.Name,
                Price = externalSystemProduct.ListPrice,
                PriceInPoundSterling = externalSystemProduct.ListPrice *
poundSterlingExchangeRate,
                PriceInYen = externalSystemProduct.ListPrice * yenExchangeRate
            };
        }

This is the final piece of the puzzle, provided that you have written the code. In the accompanying source code to this book, you will find an example that has the blanks filled in.

To use this ECT, simply press F5 in Visual Studio to deploy the model. Once the model has been deployed, you can use the ECT on a Business Data Web Part, just as you would use any other ECTs you have deployed. In Figure 12-28, you can see all five columns from the Product object, including the two different exchange rates. The Wildcard filter is applied to show the products with Sport in their name.

Figure 12-28. Viewing the BCS connector ECT on a business data list.

It is possible to import a BDC model that was previously created in SharePoint Designer to allow you to manage its deployment through a .wsp package. This section outlines this simple process.

First, to export a BDC model from SharePoint Designer, from the navigation tab locate the ECT you want to use. If several ECTs make up a model, you can select multiple items. Then right-click and choose Export BDC Model, as shown in Figure 12-29.

Figure 12-29. You can export ECTs from SharePoint Designer.

Provide a name for the file you’re exporting, and leave the remaining settings at their defaults. Click OK. In the next dialog box, choose a location to save the .bdcm file, so you can find it later.

The next step is to import the model into Visual Studio. With Visual Studio open, create a new empty SharePoint project from the list of projects available. Choose to deploy it as a Sandboxed Solution and click Finish. Once the project has been created, right-click the project name, click Add, and then click Existing Item. Navigate to the .bdcm file you exported earlier. If the model does not contain a .NET assembly, Visual Studio will ask if you want to create one, as shown in Figure 12-30.

Figure 12-30. Choose if you want to add a .NET assembly to the imported model.

You will not be able to use the UI to manipulate the model the same way you could if you created the model from scratch, but you will be able to deploy the packaged .wsp file.

For developers, the ability to write code against the SharePoint Object Model provides a great way to create solutions without needing to understand the nuances of specific external systems. The code a developer could write for a Microsoft SQL Server external system will be the same for Oracle or even a web service.

Using the SharePoint Object Model, developers can create solutions that the out-of-the-box Web Parts don’t offer. Writing a BCS solution for a dashboard can really help support a business by providing data from multiple external systems through BCS. Working with the BCS programmatically also opens up the possibility of making decisions based on business data, which we will look at shortly.

Let’s take a look at some code that connects to an ECT, iterates through product category items, and returns products from an associated product category:

    private void GetProductAndProductCategortyData()
        {
            using (new SPServiceContextScope(SPServiceContext.GetContext(SPContext.Current.
Site)))
            {
                // Get the BDC service and metadata catalog.
                var service = SPFarm.Local.Services.GetValue<BdcService>(String.Empty);
                IMetadataCatalog catalog = service.GetDatabaseBackedMetadataCatalog(SPService
Context.Current);
                // Get the entity by using the specified name and namespace.
                IEntity entity = catalog.GetEntity("AdventureWorksModel", "ProductCategory");
                ILobSystemInstance lobSysteminstance = entity.GetLobSystem().
GetLobSystemInstances()[0].Value;

                IFilterCollection defaultFilter = entity.GetDefaultFinderFilters();

                IEntityInstanceEnumerator entityInstanceEnumerator = entity.FindFiltered(default
Filter,lobSysteminstance);

                KeyValuePair<string, IAssociation> keyValuePair =
entity.GetSourceAssociations()[0];

                IAssociation association = keyValuePair.Value;

                // Iterate through each Product Category
                while (entityInstanceEnumerator.MoveNext())
                {
                    IEntityInstance currentProductCategory = entityInstanceEnumerator.Current;
                    if (currentProductCategory != null)
                    {
                        // Get Name of the Product Category
                        var productCategoryName = currentProductCategory.GetFormatted("Name");

                        // Get Enumerator for the Association
                        IEntityInstanceEnumerator associationEnumerator =
currentProductCategory.GetAssociatedInstances(association);

                        // Get Data Table contain Association data
                        var dataTable =
entity.Catalog.Helper.CreateDataTable(associationEnumerator);
                    }
                }
            }

As mentioned previously, Visual Studio packages the BCS model and, if you’re using a .NET connectivity assembly, the necessary DLLs when you build the project. There is also an option in the Build menu to simply package the solution. When the project is packaged, it creates the .wsp package in the solution directory in the BIN subfolder of the Build Configuration folder. For example, if you’re in debug mode for the ProductExchangeModel created earlier in this chapter, the .wsp will be created in a location similar to the following:

C:SourceProductExchangeModelProductExchangeModelinDebugProductExchangeModel.wsp

The .wsp package is the same as any other solution package you are familiar with in SharePoint. To move this BDC model to another environment, such as from a development server to a staging environment, you can deploy the .wsp package using Windows PowerShell or using STSAdm code.