The SpecificFinder method then uses the CustomerID returned from above IdEnumerator method as a parameter (where CustomerID=@CustomerID) to retrieve the fields for this particular customer. This is how the BDC search is able to search the entire Customers entity. So to make a field searchable, we just include it in the query and return as type string.  Here’s the SQL Query:

Select CustomerID,CompanyName,ContactName,ContactTitle,Address,City,Region,PostalCode,Country,Phone,Fax
from Customers
where customerID=@CustomerID

Import Application Definition

Now we have our required metadata well-defined in the ADF, we are ready to export the XML metadata to an ADF file and then import it to MOSS.  Once we have it imported, we can confirm that our Customers entity implements the two methods in SSP Administration page by viewing application and then entity. The Crawlable property under Entity Information means our Customers entity is available to be crawled, as shown in Figure 8.

Figure 8: View Entity Information in SSP

So far we have started from creating the ADF to importing it to enable searching. Since we can enable searching on any entity that has an IdEnumerator and SpecificFinder defined, we don’t have to start from scratch to set this up specifically for search.  We can just go straight to configuring the Enterprise Search.

Configuring the Enterprise Search

Configuring the Enterprise Search consists of the following steps:

1. Create a content source
2. Perform a full crawl
3. Create a search scope (optional)
4. Add scope rule (optional)

We start by creating a content source for our BDC application and performing a full crawl, then optionally create a search scope and scope rule.  These steps are very straight forward so I will focus on the main points. If you’re interested in each and every detail, check out the Customizing Search Series by Steve Mann.

Step 1: Create a content source (Figure 9)

In order to create a content source, go to SSP Administration page –> Search Settings under Search section, and click on “Content Sources and Crawl Schedules”. Click on “New Content Source” and give a name for this content source; specify “Business Data” as the type of the content to be crawled. Additionally, if we wish to index the content at regular intervals we could create a Crawl schedule that defines our full crawl schedules. Here is how my screen looks:

Figure 9: Create a content source

Step 2: Perform a full crawl (Figure 10)

In the above step, since I’ve checked the Start full crawl of this content source, it will initiate a full crawl of the new content source, and we should now see the content source crawling as shown below:

Figure 10: Perform a full crawl

We can also check the crawl log to make sure that the BDC data has been indexed correctly. At this point, we should be able to search our customers table. If we search for “great lakes”, we get search results as shown in Figure 1 above.

As we can see, both documents and BDC Search Results are listed together. This demonstrates some of the real power behind Enterprise Search. That is, we’re seeing SharePoint content side by side with external BDC content. This is great especially when we intend to search everything including both documents and BDC sources.

Another real power of Enterprise Search is its extensibility. We can create customized search experiences by creating a custom search tab in the Search Center where our users can search for customers in the database, and we can create a custom UI for the search results. This is what we’re going to do to separate the BDC Search results from other content. We can achieve this by performing the following two additional steps: 1) creating a search scope for BDC and 2) adding a scope rule.

Step 3: Create a search scope (Figure 11)

In order to create a search scope, go to the SSP Administration page, under Search section, click on Search settings. In the “Scopes” area, click on “View Scopes”.  Click on “New Scope”, give it a name.

Figure 11: Create a search scope

Step 4: Add scope rule

Click on “Add Rules” where it says “Empty – Add Rules” on the newly added scope (Figure 12).

Figure 12: Add scope rule

Specify a Content Source as shown below (Figure 13):

Figure 13: Add scope rule – specifying a content source

Our BDC Search scope has been created and is now available in the search drop-down as shown in Figure 14. If we now search for “great lakes”, we get search results back from the existing database as shown in Figure 4 above.

Figure 14: BDC Search scope is available for use

As you have seen, the last two steps, even though optional, do give us additional value.  That is, to segregate the BDC search results from the rest of SharePoint search results so that we can focus on just business data. Thus better search relevance is accomplished through the extensibility!

BDC Search Access Permission

It is a good time for us to know how to configure BDC Search access permission so that it will work out-of-the-gate. Often times we forget about it or ignore it, and only when the crawling fails or when the search returns no results, do we go in and dig the logs, even though it is not a bad troubleshooting methodology.

In these examples, we’ve been using “PassThrough” authentication in the ADF. That means additional settings have to be configured so that the “Default Content Access Account” (the account used to crawl) has access to the database. Also the “Default Content Access Account” must have appropriate rights to the BDC application and entity.

We’ll achieve that in the following steps:

1. Create a new Active Directory account for BDC search. We’ll call ours MOSS.Search.
2. Change the default content access account to that account in search settings (Figure 15).
3. Change search crawler account to that account under Operations –> Services –> Office SharePoint Server Search.
4. Grant this account db_datareader access to the database in SQL Server.
5. Grant this account Execute, Selectable in clients in Manage permissions for the ADF (Figure 16).

Figure 15:  Specify the Default Content Access Account

Figure 16:  Grant Execute, Selectable permissions

Note: there might be a delay of a few minutes after the permission is changed on BDC application. You may delete and re-import the BDC application definition at when needed — no need to re-crawl as long as the BDC name is not changed.

Enabling Incremental Crawling

Next, we’re going to show you how create an enhancement to our ADF to support incremental crawling through the use of the __BdcLastModifiedTimestamp entity property.

To optimize search performance, it’s important to have incremental crawl. As you may know, Incremental Crawl is a process of crawling only new or changed content from the previous full or incremental crawl. This means that we have to let BDC know what has changed since its last crawl.

To ensure that incremental crawls can be performed in the database when indexing, we’ll need to enhance the IdEnumerator method that has a return field that represents the last update time for that particular row. The Type attribute of the __BdcLastModifiedTimestamp property must be System.String and its value must be set to the value of the Name attribute of the TypeDescriptor for the field returned by the IDEnumerator method that contains the last modified date and time of the entity instance. This is illustrated below.

In our Customers table, we start by adding a column called LastUpdated of data type DateTime to indicate the last modified time of a single row. SharePoint indexing service will use that as a time stamp and incremental crawling is enabled. SQL-knowledgeable people should not confuse this with a timestamp data type. The example we are walking through is specific to SQL Server, but the concept will apply to other databases or Web Service methods.

Here are the specific steps to enable incremental crawling:

1. Update the database table to add a LastUpdated column of datetime data type (Figure 16).
2. Ensure the value of LastUpdated column is set to the current date and time when the row changes. (This can be accomplished with an Update trigger.)
3. Update ADF to have the __BdcLastModifiedTimestamp property of the entity set to LastUpdated (Figure 17).
4. Update ADF to have IdEnumerator mothod return LastUpdated field (Figure 18).
5. Update ADF to have a TypeDescriptor with its TypeName attribute set to System.DateTime (Figure 19).

The following figures are the screens for performing the above tasks:

Figure 16: Create a LastUpdated column of datetime type in SQL Server

Figure 17: Add the __BdcLastModifiedTimestamp property

Figure 18: Have IdEnumerator method return LastUpdated field

Figure 19: Add a TypeDescriptor with its TypeName attribute set to System.DateTime

To compare the performance, I then performed an incremental crawl.  This is shown in Figure 20 below.

Figure 20: Comparison between the incremental crawling and the full crawling.

In our sample, it took significantly less time in the incremental crawling than the full crawl (35 seconds vs. 54 seconds).  Depending on the size of the database and the number of changes that need to be processed with each crawl, the difference in crawl times will vary. The key of enabling incremental crawl here is performance so that the back-end systems are not unnecessarily burdened by the crawling.

Actions

Lastly, let’s show you how we can make our BDC search results “actionable” by creating a custom action on the Customers entity. There are two ways to create a custom action. It can be defined either in the ADF or added after the ADF is imported by going to SSP administration page (View Application –> View Entity).

By default through the SpecificFinder method, we get a default view Profile action that links to a simple page with your search results. This is where the customization comes in, and you could create custom Web Parts to provide more user-friendly and richer user experience. We’ll dedicate Part 8 of this series to Custom Actions so you have the best for last. For this article, let’s quickly create a custom action to map the customer using Live Search Maps (maps.Live.com).

Here are the specific steps to enable custom action with Live Search Maps:

1. Add Action and set parameters (Figure 21)
2. Check action (Figure 22)

Go to SSP administration page (View Application –> View Entity), add action and configure URL parameters.

Figure 21:  Create a custom action in SSP

The parameter “Address” will be substituted at index “0″, which is specified as a querystring URL to maps.live.com. If you have already deployed your ADF before creating a custom action, you will need to redeploy it if you use this approach to adding a custom action.

Check the custom action to ensure it’s configured and ready for use (Figure 22).

Figure 22: Live Map Action appears under Actions

Now let’s test-drive our search and custom action in the following two steps:

1. Search any customer in the Search Center (Figure 23)
2. Perform the custom action based on the search result (Figure 24)

Figure 23: Search result of a customer entity

Clicking on “The Big Cheese“ will take us to the default profile page, where we can see and act upon the custom action Live Map (maps.live.com) as shown below. Clicking on Live Map will issue a search on maps.live.com using the address of “The Big Cheese”. Here’s the live map (Figure 26). Neat!

Figure 24: BDC Search Results with Live Map action available

Figure 25:  Live Map of the searched customer

Conclusion

In this article we have covered the concepts behind BDC search and how to enable it. We’ve then walked you through how to make our Customer data searchable, and how to make a custom action on search results. In doing so, we’ve demonstrated the power behind BDC and MOSS Enterprise Search. Even though we have only used a database in our example, this is also all possible with Web Services, provided the SpecificFinder and IdEnumerator methods are still in place. Hope you have enjoyed reading it as much as I have enjoyed writing it. Look forward to your comments and suggestions.  Aloha!