Implementing ECTs in SPD using Stored Procedures

If you plan to use Stored Procedures, you will need a separate stored procedure for each CRUD operation. In addition, you will need separate stored procedures for any associations you might need. It is important to note that each Read List, Read Item, and Association stored procedures need to return all the fields that will be required by any other stored procedure defined by that Content Type. In other words, the Read List, Read Item, and Association stored procedures need to return the same exact fields. If they don’t, you will get runtime errors.

Since most examples center on tables, you will often not see a detailed discussion of fields that are required for all the operations as tables always return to you all the fields of that table. So to avoid unintended runtime errors with your ECTs always make sure that your stored procedures return to you all the fields that you think you might need even if you expect not to need them in a particular ECT operation definition. SPD then allows you to define which of these fields should be included in the ECT definition.

The following is a list of field issues that you should be aware of:

  • Unique Identifiers: Each stored procedure needs to provide a unique identifier of type integer. SPD will allow you to have other types of unique identifiers, but you will run into runtime errors if you try to perform any association, create, update, or delete operations. You need these identifiers to avoid issues even if they are completely meaningless to your solution.
  • Limit filters (Read List operations): If it is possible that your data will return more than two thousand records, this will become big problem down the line. BCS by default has a 2000 item throttling limit. This limit can be changed, see BCS PowerShell: Introduction and Throttle Management. You can go without limit filters in development and not see any issue even if your database has hundreds of thousands of records as External lists will by default implement paging. Just understand that if you are using the object model (BCS Runtime or Client object models) to access your data, all records will be returned to you. This can be a major cause of performance degradation and you will not likely see it till you are on a production environment where there are greater latency issues (such as distributed servers, zones, and SSL implementations that you are likely not to have in development). One important thing to note is that a limit filter on its own will just limit the items returned; this means that without another filter type you can only access a subset of your data. For example if you want to limit the amount of books returned by a query to 100, you would add a limit filter and add another such as a Wildcard Filter (say for example a book’s partial title or publish date), this will mean you will get a maximum of 100 books which match the Wildcard filter returned. So in order to implement limit filtering on Read List operation, your Read List stored procedure needs to have an input parameter to use for performing an additional filter criteria.
  • Nullable field types: SPD will give you warnings if it finds fields that are nullable, but it can handle them just fine. Be careful with this as External lists will try to return empty strings to these fields if the fields are not required. This can be a real problem if the field is not of a CHAR, VARCHAR, or some other string type. This will give you runtime errors. If you are using these fields via the object model (BCS Runtime or Client object models), then you can handle this by returning nulls for these field types.

How to develop and deploy the ECTs/BDC Models to multiple environments

Up to this point I have discussed creating ECTs and BDC Models and Resources in SPD, VS, notepad, and Central Admin. So which should we be really using? I will first discuss each of these platforms:

SharePoint Designer
is free tool from Microsoft that can provide no-code solution to creating BDC Models and ECTs. It will provide for rapid development without writing any code or markup, but has two major drawbacks. First, the solution will not be searchable as stated in Issue 3. Second, the solution will be specific to a SharePoint site that you are required to identify before developing your solution and you will not be able to deploy your solution to a different site.

If neither of the drawbacks is an issue for you, then SPD is a wonderful tool for your BCS development. It will even allow you to create External Lists (among other things) based on your ECTs with a push of a button.

Visual Studio (2010)
Another tool from Microsoft that will allow you to create BDC Models, Resources, and ECTs with code or XML markup. Although it is not free, no SharePoint developer should develop without it. It has no limitations on your BCS solution and will allow you to package and deploy your BCS Solution to multiple sites. It’s only true drawback is that you will either need to write code or XML markup for your solution and can therefore not really be recognized as a rapid development platform.

Notepad (or your favorite text editor)
Since you can develop BCS Solutions using only XML markup, there is nothing stopping you from writing your XML in your favorite text editor. This however is no small feat as you will need to be very familiar with all the necessary BCS tags and all their necessary attributes. In addition, this approach is very error prone.

Central Admin
Although Central Admin is not a development platform; it will however allow you to do certain things that will make your development easier. Central Admin will allow you to import and export both .bdcm and .bdcr files. This means that if you do develop your solution in either Notepad or SPD (or even VS for that matter), Central Admin will allow you to import those files, strip out or add resources, and then allow you to export the new model or resources. This is incredibly useful if you want to take a solution built in SPD for example which is targeted to a specific site, strip out all site specific information, and then export out a true BDC Model that can then be implemented on any SharePoint site.

There are also third-party platforms that provide much of the capabilities of SPD without some of the limitations in creating and implementing BCS Solutions that are worth investigating.

So which of the above would you think is the best way to go?

Well, the answer turns out to be a combination of the platforms above, taking advantage of each of the above platform’s capabilities and using another platform to overcome the drawbacks of the first. Below is the process I used to rapidly develop a solution that is both searchable and deployable to multiple environments:

  1. Create all the required ECTs for a given BDC Model in SPD
    1. Include at least a Finder and a Specific Finder method for each ECT
    2. Include any other necessary operations for each ECT
    3. Define any associations for each ECT
    4. Identify a field to mark as a Title field for each ECT
  2. Select all the ECTs and export them out as a single BDC Model
  3. Save that model as a .bdcm file on your local system
  4. Import the .bdcm file into (the BCS Service Application on) CA
  5. Export the model out of CA as a different .bdcm file then was imported into it
    1. Make sure to uncheck any resource checkboxes prior to exporting as a BDC Model (this strips out any resources out of your BDC Model)
  6. Open VS and create a new (or open an existing) Blank SharePoint 2010 project
  7. Add a new BDC Model item
  8. Delete the generated Entity1.cs and the Entity1Service.cs files
  9. Open the .bdcm file (using an XML editor within VS)
    1. Right-Click the .bdcm file and choose Open With…
  10. Delete all content in the .bdcm file in VS
  11. Open the .bdcm file exported from CA with Notepad (or your favorite simple text editor)
  12. Copy all content and paste it into the .bdcm file in VS
  13. Make all the necessary changes to make the model searchable (see Issue 3)
  14. If deploying from VS, then open the newly created Feature.Template.xml file and add the following markup:
    <?xmlversion=”1.0″encoding=”utf-8″ ?>
    <Feature xmlns=””&gt;
    <Property Key=’SiteUrl’ Value=’http://YourDevSite‘/>

    1. Note that for each BDC Model, there is a SharePoint feature (you cannot have more than one model per feature)
    2. The feature will be scoped to the Farm level (as all BCS Solutions are defined at the Farm level in CA)
    3. You should only deploy from VS for development purposes, for Integration, QA, or production deployments, you should use PowerShell
  15. Right-Click on your project and choose to package your solution
  16. Go to your Bin folder in your project from your file system and copy the WSP file that is generated when you performed step 15
  17. Save the WSP onto the SP Application Server that you want your solution deployed to
  18. Deploy and Activate your WSP package to the target SP Application Server
  19. Go to the BCS Service Application in CA and select the BDC Model that was just deployed
  20. 20. Right-Click the model and choose to Set Permissions
  21. Add all the accounts that will need the appropriate permissions to your BDC model and click OK

And you are done…Only 21 steps, not a lot ;).