In the center of the search architecture is the Search Service Application (SSA). The SSA is one of the many shared services available in SharePoint Server. This means that you may create and share instances of the SSA across farms just like any other service application. From the Central Administration website, you may access the SSA by selecting Manage Service Applications. From the list of service applications, you may select the SSA, set its properties, designate administrators, and enter the administration pages. Figure 15-3 shows the SSA in the list of service applications.

Figure 15-3. Managing the SSA

Within the SSA are three databases: the Search Service database, the Managed Properties database, and the Crawl database. The Search Service database maintains configuration data for the SSA. The Managed Properties database contains the definitions for Managed Properties that are defined and mapped to crawled properties. The Crawl database contains configuration information related to content sources to be crawled. The SSA also maintains the index file that is built during the crawl and provides support for Federated Search connectors. Each of these components supports search administration, which is accessed by clicking the Manage button for the SSA.

The indexing process is responsible for building the index file. The index file contains properties from content sources, along with access control information that ensures search results display only content for which the user has rights. The process of building the index file involves crawling the designated content sources.

A content source is a repository that you want to search. Content sources can be SharePoint sites, websites, external file systems, Exchange Server public folders, Business Connectivity Services (BCS) External Systems, or other custom repositories. The Index Engine gains access to these repositories through .NET Assembly Connectors and access to the contents of individual items through IFilters.

Chapter 13, presented the fundamentals of .NET Assembly Connectors, which are used by BCS to connect with External Systems. The indexing process uses these same components to connect with content sources. In previous versions of SharePoint, Protocol Handlers were the primary means of connecting with content sources, but they were difficult to create in managed code. In SharePoint 2010, Protocol Handlers are still supported, but .NET Assembly Connectors should be created whenever a custom repository is used as a content source.

Just as in previous versions of SharePoint, IFilters are used to allow the indexing process to access the contents of an item. For example, IFilters allow the indexing process to access the body of Microsoft Office documents so that a full-text search can be performed. While SharePoint 2010 ships with IFilters for Office documents, you may need to install additional IFilters for other types, such as Portable Document Format (PDF) documents. Generally, IFilters are available from the appropriate manufacturer, such as Adobe, and require a simple installation on the server where the indexing process runs.

Once the index file is created, it may be used to support query execution. Query execution begins when a user navigates to the Search Center and enters a query. The query in the Search Center may take the form of a simple keyword or an advanced search with multiple values against multiple Managed Properties.

When the user issues a search, the query is sent to the search engine. Within the search engine, the query processor accepts the query and also retrieves any required information from the Managed Properties database. Information from the Managed Properties database is required any time a query is issued against a specific Managed Property, such as Title. The combination of the user query and Managed Property information is then sent to the query server, which executes the query and returns the results. The results are returned as Extensible Markup Language (XML) to the Search Center where they are formatted using Extensible Stylesheet Language for Transformations (XSLT).

Along with performing a query on its own index, SharePoint can send the query out to other federated search locations. Federated search locations are connections to other search services that independently run the query and return the results separately to the Search Center for display. Communication with federated locations is based on the Open Search protocol, so any search service that supports Open Search can be used as a federated location.

The primary way in which users interact with the search engine is through a set of search Web Parts that ship with SharePoint. These search Web Parts may be used independently, but they are most often used as part of an Enterprise Search site created through a site template. The Enterprise Search template contains Web Parts for issuing queries and returning results. Table 15-1 lists the Web Parts and their purposes.

Each of the Web Parts listed in Table 15-1 is configurable in various ways that are useful when creating search solutions. Furthermore, you can inherit from many of the Web Parts to create your own custom versions. You’ll learn more about customizing these Web Parts later in the chapter.

SharePoint Server 2010 contains two object models to support search. One object model is an administration application programming interface (API) that can be used to perform administrative operations on the SSA. The other is a search object model that can be used to create custom search solutions that execute keyword query and full-text query searches. Object models are covered in the section entitled Working with Keyword Query Syntax later in the chapter.

In SharePoint 2010, not all the internal ranking model capabilities are available to your custom ranking models, but there is enough power to have a significant impact on the search results. Custom ranking models are created as XML files that specify the query-independent and query-dependent factors to use when ranking search results. Example 15-1 shows a sample custom ranking model that gives extra weight to the title of an item and Microsoft Word documents. Such a model might be used if an organization’s most important documents are typically in Word format, and the title of the document contains key information.

<?xml version='1.0'?>
<rankingModel
    name='NewRankingModel'
    id='11111111-65CD-4a1b-9A63-F7ECB4B6BB5E'
    description = 'Sample ranking model'
    xmlns='http://schemas.microsoft.com/office/2009/rankingModel'>
    <queryDependentFeatures>
        <queryDependentFeature
          name='Body' pid='1' weight='10.0000000000'
          lengthNormalization='2.8898552470'/>
        <queryDependentFeature
          name='Title' pid='2' weight='100.0000000000'
          lengthNormalization='0.9574077587'/>
        <queryDependentFeature
          name='Author' pid='3' weight='0.1000000000'
          lengthNormalization='1.0131509886'/>
        <queryDependentFeature
          name='AnchorText' pid='10' weight='0.1000000000'
          lengthNormalization='2.6713762088' />
        <queryDependentFeature
          name='DisplayName' pid='56' weight='0.1000000000'
          lengthNormalization='0.9713508040'/>
        <queryDependentFeature
          name='ExtractedTitle' pid='302' weight='0.1000000000'
          lengthNormalization='1.0095022768'/>
        <queryDependentFeature
          name='QueryLogClickedText' pid='100' weight='0.1000000000'
          lengthNormalization='1.6000001537'/>
    </queryDependentFeatures>
    <queryIndependentFeatures>
        <queryIndependentFeature
          name='DistanceFromAuthority' pid='96' default='5' weight='0.1000000000'>
            <transformInvRational k='0.1359244473'/>
        </queryIndependentFeature>
        <queryIndependentFeature
          name='URLdepth' pid='303' default='3' weight='0.1000000000'>
            <transformLinear max='1000'/>
        </queryIndependentFeature>
        <queryIndependentFeature
          name='DocumentPopularity' pid='306' default='0' weight='0.1000000000'>
            <transformRational k='1.2170868558'/>
        </queryIndependentFeature>
        <queryIndependentFeature
          name='DocumentUnpopularity' pid='307' default='0' weight='0.1000000000'>
            <transformRational k='0.7333557072'/>
        </queryIndependentFeature>
        <categoryFeature name='FileType' pid='98' default='0'>
            <category name='Html' value='0' weight='0.1000000000'/>
            <category name='Doc' value='1' weight='100.0000000000'/>
            <category name='Ppt' value='2' weight='0.1000000000'/>
            <category name='Xls' value='3' weight='0.1000000000'/>
            <category name='Xml' value='4' weight='0.1000000000'/>
            <category name='Txt' value='5' weight='0.0000000000'/>
            <category name='ListItems' value='6' weight='0.1000000000'/>
            <category name='Message' value='7' weight='0.1000000000'/>
        </categoryFeature>
        <languageFeature name='Language' pid='5' default='1' weight='10.0000000000'/>
    </queryIndependentFeatures>
</rankingModel>

Custom ranking models begin with the rankingModel element. The only required attribute for this element is the id attribute, which is a globally unique identifier (GUID) that identifies the model. The other attributes are optional and are used largely for readability. In addition, the namespace must be called http://schemas.microsoft.com/office/2009/rankingModel. The child elements of the rankingModel are a set of queryDependentFeatures and queryIndependentFeatures, which specify the factors that will be used for dynamic and static ranking, respectively.

The queryDependentFeature element has name, pid, weight, and lengthNormalization attributes. The queryIndependentFeature element has name, pid, default, and weight attributes. The name attribute is optional and is used primarily for readability. The pid is the property identifier for the Managed Property that is being referenced. The weight is a relative attribute that determines the effect that the factor will have on the ranking. The lengthNormalization attribute is a number used to account for differences in the lengths of various properties. The default attribute is the value to be used when an actual value cannot be determined.

The categoryFeature and languageFeature elements are children of the queryIndependentFeature. The categoryFeature element allows you to specify a set of possible values for a Managed Property and give different weights to each one. The languageFeature element gives extra weight to an item if it is in the default language. Finally, the transformRational, transformInvRational, and transformLinear elements associate additional functions with the model that transform the weighting values.

Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchMetadataManagedProperty

Once you have created a custom ranking model, you can use it with SharePoint Server. The process of using the custom ranking model involves several steps. First, you must enable any associated Managed Properties for use with the model. Second, you must install the ranking model. Third, you must reference the new model in either a custom solution or existing Web Part. Creating custom solutions is covered later in the chapter. For now, this section will focus on using the custom ranking model with existing search Web Parts.

When you create a custom ranking model, you will quite often be creating new Managed Properties for use in the weighting strategy. Previously, you saw how to get the identifier for a Managed Property so that it could be referenced in the ranking model. However, Managed Properties are not enabled for use as query-independent parameters by default. You must allow it explicitly. So if your model uses a Managed Property as a query-independent feature, you must set the EnabledForQueryIndependentRank property to True. You can set the property using the following Windows PowerShell code, substituting the name of the specific Managed Property for PropertyName in this example.

$p = Get-SPEnterpriseSearchServiceApplication |
     Get-SPEnterpriseSearchMetadataManagedProperty -Identity {PropertyName}

$p.EnabledForQueryIndependentRank = $true

$p.Update

The next step is to install the custom ranking model. Installing the custom ranking model is accomplished using the Windows PowerShell cmdlet New-SPEnterpriseSearchRankingModel. This cmdlet takes as a parameter the complete ranking model as a string. Therefore, you have to crunch your ranking model into a single piece of text by removing all the line breaks and white space so it can be passed as a parameter. Once this is done, the following Windows PowerShell script will install the new ranking model.

Get-SPEnterpriseSearchServiceApplication |
  New-SPEnterpriseSearchRankingModel -RankingModelXML {Crunched Ranking Model}

The final step in the process is to reference the custom ranking model in the Search Core Results Web Part. The Search Core Results Web Part displays the primary result set from a search and uses the default ranking model out of the box. However, it has a DefaultRankingModelID property that may be changed to reference the Id of any custom ranking model, such as the required id attribute shown earlier in Example 15-1.

To change the DefaultRankingModelID property, you must navigate to a search results page and place that page in edit mode. Once in edit mode, the Search Core Results Web Part may be exported as an XML file. After exporting the Web Part, you can open it in an editor and search for the DefaultRankingModelID property, which will be empty. When the property is empty, the default ranking model is used. Simply change this value by hand and save it. You may then return to the search page and import the new file as an instance of the Search Core Results Web Part. Deleting the original Web Part from the page completes the process. Now when you search, the new ranking model will be used. The following code shows how the property appears in XML after editing.

<property name="DefaultRankingModelID" type="string">
  0D4CB5B6-2FA3-4D7F-AF79-EF0DE64F242C
</property>

By default, the Search Center has an All Sites tab and a People tab, which correspond to search scopes. What’s interesting—but also potentially confusing—about the Search Center template is that it actually has two sets of tabs. One set is used to render initial tabs before a search is executed, and the other is used to render tabs that appear in the search results. However, both sets of tabs are given the same name to make it appear as though only a single set of tabs exists. The Tabs In Search Pages list contains the first set of tabs, and the Tabs In Search Results list contains the second set of tabs. When you create search-based applications, you will quite often deploy them as new tabs within the Search Center based on custom search scopes. This means that adding a new tab is a multistep process involving the creating of a search scope, page layouts, and tabs.

Creating a search scope is accomplished through the Search Service Application. Within the SSA, you will find a Scopes link, where you may define a new search scope based on Web address, property, or content source. Once defined in the SSA, you can make the scope available to a site collection. This process starts in the Site Collection by browsing to Site Settings, Site Collection Administration, and Search Settings, and then enabling custom scopes, which requires you to enter the Uniform Resource Locator (URL) of the new Search Center. After that, you can go to Site Settings, Site Collection Administration, and Search Scopes, and then decide whether to use the new scope in the Scopes drop-down list.

Once the scope is defined and available, you may go to the Search Center to define search and search results pages. The best way to add the required pages is simply to select View All Site Content from the Site Actions menu in the Search Center. From the All Site Content page, click the Pages library link. Within the Pages library, click the Documents tab and finally the New Document button on the Ribbon, which will present the Create page.

On the Create page, you will see the four different page layouts available for the Search Center. For a typical search-based application, you will create a Search Box page and a Search Results page. The exact names of the pages don’t matter as long as you keep track of them. Typically, however, these pages are named ScopeSearch.aspx and ScopeResults.aspx, with “Scope” replaced in the page name with the actual name of the scope.

Once the pages are created, you can create the associated tabs. Again, the best way to do this is on the All Site Content page. In the Tabs In Search list, create a new tab using the same name as the scope and associate the search page. In the Tabs In Search Results list, create a new tab using the same name as the scope and associate the results page. At this point, you should be able to see the new tab in the Search Center. Creating the tabs and pages is not enough, however, to duplicate the functionality of the other tabs in the Search Center. To have the new scope fully implemented, changes must be made to several Web Parts.

First, a change must be made to the Search box Web Part on both the search and results page. This can be done by simply putting the appropriate page in edit mode and selecting to edit the Search Box Web Part. Under the Miscellaneous category, locate the Target Search Results Page URL and change it to be the name of the results page created earlier. In addition, a change must be made to the Search Core Results Web Part on the results page. In this Web Part, under the Location Properties category, you must enter the name of the scope in the Scope property. After these changes are complete, publish both the search and results pages. The new scope is now available to the Search Center.

The Search Core Results Web Part is central to all search-based applications. You have already seen that altering the DefaultRankingModelID or the Scope property can have a significant impact on the displayed search results. You can also customize which columns to display in the search results and the format of the display. Finally, you can create a custom Web Part that inherits directly from the Search Core Results Web Part to gain access to the query pipeline.

<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Columns>
    <Column Name="WorkId"/>
    <Column Name="Rank"/>
    <Column Name="Title"/>
    <Column Name="Author"/>
    <Column Name="Size"/>
    <Column Name="Path"/>
    <Column Name="Description"/>
    <Column Name="Write"/>
    <Column Name="SiteName"/>
    <Column Name="CollapsingStatus"/>
    <Column Name="HitHighlightedSummary"/>
    <Column Name="HitHighlightedProperties"/>
    <Column Name="ContentClass"/>
    <Column Name="IsDocument"/>
    <Column Name="PictureThumbnailURL"/>
    <Column Name="ServerRedirectedURL"/>
  </Columns>
</root>

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:output method="xml" version="1.0" encoding="utf-8" indent="yes"/>
  <xsl:template match="/">
    <xmp>
      <xsl:copy-of select="*"/>
    </xmp>
  </xsl:template>
</xsl:stylesheet>

using System;
using System.ComponentModel;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
using Microsoft.Office.Server.Search.Query;
using Microsoft.Office.Server.Search.WebControls;
using System.Xml.XPath;

namespace CustomSearchParts.AssignedToMeResults {

  public class AssignedToMeResults : CoreResultsWebPart {
    protected override XPathNavigator GetXPathNavigator(string viewPath) {

      // get reference to Query Manager
      QueryManager queryManager =
        SharedQueryManager.GetInstance(this.Page).QueryManager;

      // Modify User Query
      queryManager.UserQuery +=
       " AssignedTo:" + SPContext.Current.Web.CurrentUser.LoginName +
       " AssignedTo:" + SPContext.Current.Web.CurrentUser.Name;

      return base.GetXPathNavigator(viewPath);
    }
  }
}

using System;
using System.ComponentModel;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
using Microsoft.Office.Server.Search.Query;
using Microsoft.Office.Server.Search.WebControls;
using System.Xml.XPath;

namespace CustomSearchParts.RankingModelIdResults {
  public class RankingModelIdResults : CoreResultsWebPart {

    //Use default ranking model to start
    private string rankingModelId = "8f6fd0bc-06f9-43cf-bbab-08c377e083f4";

    [ Personalizable(PersonalizationScope.Shared),
      WebBrowsable(true),
      WebDescription("The ID of the Ranking Model to use"),
      WebDisplayName("Ranking Model ID"),
      Category("Configuration") ]
    public string RankingModelID {
      get { return rankingModelId; }
      set { rankingModelId = value; }
    }

    protected override XPathNavigator GetXPathNavigator(string viewPath) {
      try {
        QueryManager queryManager =
          SharedQueryManager.GetInstance(this.Page).QueryManager;
        foreach (LocationList locList in queryManager) {
          foreach (Location loc in locList)
            try { loc.RankingModelID = RankingModelID; }
            catch { }
        }
      }
      catch { }

      return base.GetXPathNavigator(viewPath);
    }
  }
}

Whenever any External Content Type (ECT) is created in BCS, there is an XML model that gets created behind the scenes. This model defines the external system, entities, relationships, methods, and user access rights for the ECT. The same is true when a .NET Assembly Connector is created. The primary difference is that the external system is defined as an association between a .NET assembly and the ECT.

When you use SPD to create ECTs, the model is generated for you so that you never have to deal with XML directly. When you use Visual Studio 2010 to create a .NET Assembly Connector, you also have design tools that hide the XML, but you often have to edit the XML model manually to get the exact capabilities you need. In Visual Studio, the XML model is contained in a file with a .bdcm extension. When this file is opened, it appears in three windows. First, a design surface is available for creating entities. Second, a detail section is available for method definitions. Third, the BDC Explorer is available for browsing the model. Figure 15-5 shows the three windows of information for the model described in Chapter 13. This model used a .NET Assembly Connector to connect with product information.

Figure 15-5. Viewing a .NET Assembly Connector

You may view the XML for the model directly by right-clicking the .bdcm file in the Solution Explorer and selecting Open With from the context menu. When the Open With dialog appears, select to open the file with the XML Editor. If you study the XML model alongside the BDC Explorer, you will begin to see that the BDC Explorer contains a node for each key element in the model. This concept is important because you typically will be adding information to model elements when you prepare a .NET Assembly Connector to support search.

To search-enable an existing model, you must make two changes. The first change is to designate which method to call during the indexing process. The second change allows the model to appear as a content source in search. Both changes are simple edits to the XML.

Chapter 13 discussed BCS operations in detail. In particular, Finder methods were defined as methods that return many records from an external system. Essentially, a Finder method defines a view of an external system. When search crawls an external system, it needs to know which of the available Finder methods represents the entire population of records to index. This finder method is known as the RootFinder method.

In your .NET Assembly Connector, you designate the RootFinder by first selecting the method instance in the Method Details pane. When you select it, the Properties window in Visual Studio 2010 will show details for the method. From this window, you can open the Custom Properties collection. In the Property Editor window, you can enter the RootFinder designation with a Type of System.String and a Value of x. Figure 15-6 shows the modifications being made to the sample from Chapter 13.

Figure 15-6. Setting the RootFinder method

After setting RootFinder, you can open the model XML in Visual Studio and see how the new information was added to the model. The following code shows the resulting XML.

<MethodInstances>
  <MethodInstance Type="Finder"
     ReturnParameterName="returnParameter"
     Default="true" Name="ReadList"
     DefaultDisplayName="Entity1 List">
    <Properties>
        <Property Name="RootFinder" Type="System.String">x</Property>
    </Properties>
  </MethodInstance>
</MethodInstances>

Once RootFinder is defined, you must make a change to allow the .NET Assembly Connector to appear as a content source in search. This is accomplished by applying the ShowInSearchUI property to the model. This property is applied by selecting the LobSystemInstance for your project under the LobSystemInstances folder in the model explorer. You may then create the property, again setting its value to x, using the same technique as for RootFinder. Figure 15-7 shows the modifications.

Figure 15-7. Applying the ShowInSearchUI property

After applying the ShowInSearchUI property to the model, it is a good idea to examine the XML and verify the change. The following code shows the modified model for the sample in Chapter 14.

<LobSystemInstances>
  <LobSystemInstance Name="BdcModel1" >
    <Properties>
      <Property Name="ShowInSearchUI" Type="System.String">x</Property>
    </Properties>
  </LobSystemInstance>
</LobSystemInstances>

Once you have completed the two modifications, the model is search-enabled. You may deploy the feature and immediately select it as a search content source. It is worth noting that when you create models using SPD, the RootFinder and ShowInSearchUI properties are added automatically.

While search-enabling a BCS model is fairly simple, this process provides no security checking against search queries. This means that when a search is run against the external system, all matching results will be returned regardless of whether the current user is supposed to see them. In most production applications, you will want to implement an access control list (ACL) that specifies rights for the records returned when searching with a .NET Assembly Connector. This is accomplished by adding a special method to the model called a BinarySecurityDescriptorAccessor method.

The process to implement security begins by adding a new method to the model. In Visual Studio, you can right-click the entity in the design surface and select Add New Method from the context menu. You can then give it a name such as ReadSecurityDescriptor. Once created, the method will appear in the Method Details pane.

Now in the Method Details pane, you must create a new method instance beneath the new method. Once the new method instance is created, you can change its Type in the Properties window to BinarySecurityDescriptorAccessor.

The new method instance will require input and output parameters. Typically, the input parameters are the identifier for an item and the user name of the current user. The output parameter must be a byte array that holds the security descriptor. The following code shows the XML for the new method.

<Method Name="ReadSecurityDescriptor">
  <Parameters>
    <Parameter Name="id" Direction="In">
      <TypeDescriptor Name="ID" TypeName="System.String" IdentifierName="ID" />
    </Parameter>
    <Parameter Name="acl" Direction="Return">
      <TypeDescriptor Name="SecurityDescriptor"
        TypeName="System.Byte[]" IsCollection="true" >
        <TypeDescriptors>
          <TypeDescriptor Name="SecurityDescriptorByte" TypeName="System.Byte"/>
        </TypeDescriptors>
      </TypeDescriptor>
    </Parameter>
  </Parameters>
  <MethodInstances>
    <MethodInstance Name="ReadSecurityDescriptorInstance"
      Type="BinarySecurityDescriptorAccessor" ReturnParameterName="acl"/>
  </MethodInstances>
</Method>

When you create the new method definition, Visual Studio will automatically generate a method stub in code that accepts the input parameters and returns a byte array. Your job is to write code for this method that creates an ACL for the item.

When the BinarySecurityDescriptorAccessor method is called during the indexing process, username will be the account performing the search crawl. This is fine because this account will simply be designated as the owner account for the ACL. In the method, you may add other permissions for users based on whatever criteria you need. For example, the code in Example 15-8 grants access to all users.

public static byte[] ReadSecurityDescriptor(string id, string username) {
  try {
    //Grant everyone access
    NTAccount workerAcc = new NTAccount(
    username.Split('')[0], username.Split('')[1]);
    SecurityIdentifier workerSid =
        (SecurityIdentifier)workerAcc.Translate(typeof(SecurityIdentifier));
    SecurityIdentifier everyone =
         new SecurityIdentifier(WellKnownSidType.WorldSid, null);
    CommonSecurityDescriptor csd = new CommonSecurityDescriptor(
         false, false, ControlFlags.None, workerSid, null, null, null);
    csd.SetDiscretionaryAclProtection(true, false);
    csd.DiscretionaryAcl.AddAccess(
    AccessControlType.Allow, everyone, unchecked((int)0xffffffffL),
    InheritanceFlags.None, PropagationFlags.None);
    byte[] secDes = new byte[csd.BinaryLength];
    csd.GetBinaryForm(secDes, 0);
    return secDes;
  }
  catch (Exception x) {
    PortalLog.LogString("Product Model (ReadSecurityDescriptor): {0}", x.Message);
    return null;
  }
}

After creating the BinarySecurityDescriptorAccessor method, a property must be added to the Product entity to hold the ACL. In the sample, this property is named SecurityDescriptor. The model must then be updated to relate the BinarySecurityDescriptorAccessor method to the SecurityDescriptor property. The following code shows how to relate the entity and the method instance.

<MethodInstances>

  <MethodInstance Name="ReadSecurityDescriptorInstance"
                  Type="BinarySecurityDescriptorAccessor"
                  ReturnParameterName="acl">
    <Properties>
      <Property Name="WindowsSecurityDescriptorField" Type="System.String">
        SecurityDescriptor
      </Property>
    </Properties>
  </MethodInstance>

<MethodInstances>

When your .NET Assembly Connector is complete, you should be able to select it as a content source and initiate a full crawl. When you crawl the solution for the first time, it’s a good idea to attach Visual Studio to the crawl process (mssdmn.exe) and watch how the crawl progresses. Set breakpoints in the Finder, SpecificFinder, and BinarySecurityDescriptorAccessor methods. Also, be sure that you have granted access in the BCS service to the account that will perform the crawling.

When the crawl is initiated, you should see the Finder method called first. You’ll then see the SpecificFinder called for each individual item returned from the Finder method. Along the way, the security descriptor should be built for each item. After the crawl completes, check the crawl log for errors. Now you can run a search against the crawled data. SharePoint should use the security descriptors that you constructed to limit access to items as appropriate.