Konfigurieren der SharePoint Server 2010-Suche für externe Inhaltstypen (Teil 2 von 2)

Zusammenfassung:  Mit Microsoft Business Connectivity Services (BCS) können Benutzer auf einfache Art externe Daten als Ergebnisse für die Microsoft SharePoint Server 2010-Suche-Funktionen in SharePoint einschließen. Erfahren Sie mehr zur Konfiguration externer Inhaltstypen für die Indizierung in der SharePoint Server-Suche und zu Optionen für die Konfiguration von Ergebnissen der SharePoint Server-Suche.

Letzte Änderung: Montag, 9. März 2015

Gilt für: Business Connectivity Services | Office 2010 | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Inhalt dieses Artikels
Einführung
Erläuterung zur XML-Datei im BDC-Modell
Ändern des externen Inhaltstyps zur Unterstützung von inkrementellen Durchforstungen
Was ist aus dem IDEnumerator geworden?
Verwenden desselben externen Inhaltstyps für externe Listen
Weitere Ressourcen
Informationen zum Autor

Bereitgestellt von:  Bob McClellan

Inhalt

• Einführung

• Erläuterung zur XML-Datei im BDC-Modell

• Ändern des externen Inhaltstyps zur Unterstützung von inkrementellen Durchforstungen

• Was ist aus dem IDEnumerator geworden?

• Verwenden desselben externen Inhaltstyps für externe Listen

• Weitere Ressourcen

• Informationen zum Autor

Dieser Artikel ist der zweite Artikel einer zweiteiligen Serie zum Konfigurieren der SharePoint Server-Suche für externe Inhaltstypen.

• Konfigurieren des SharePoint Server 2010-Suchdiensts für externe Inhaltstypen (Teil 1 von 2)

• Konfigurieren der SharePoint Server 2010-Suche für externe Inhaltstypen (Teil 2 von 2) (dieser Artikel)

Einführung

Mit Microsoft Business Connectivity Services (BCS) können Sie SharePoint-Lösungen mit externen Datenquellen verbinden und externe Inhaltstypen definieren, die auf diesen externen Daten basieren. SharePoint 2010-Suchdienste können die externen Daten indizieren, indem externe Inhaltstypen zum Anzeigen adäquater Suchergebnisse verwendet werden. Business-Konnektivitätsdienste (Business Connectivity Services), zuvor Geschäftsdatenkatalog (Business Data Catalog, BDC) genannt, stellen weitere Verbesserungen einschließlich Unterstützung für Microsoft SharePoint Designer 2010 bereit.

Im vorherigen Artikel dieser Serie, Konfigurieren des SharePoint Server 2010-Suchdiensts für externe Inhaltstypen (Teil 1 von 2), habe ich die Verwendung von SharePoint Designer 2010 zum Definieren von externen Inhaltstypen und das Einrichten einer Durchforstung mit der Microsoft SharePoint Server 2010-Suche erläutert, die diese externen Daten einschließt. Mit diesem Ansatz können die Durchforstungszeiten für umfangreiche Datenmengen mithilfe von inkrementellen Durchforstungen verringert werden. Dies wird mithilfe von SharePoint Designer, der SharePoint-Zentraladministration und XML-Codebeispielen beschrieben.

Stellen Sie zunächst sicher, dass Sie Folgendes besitzen:

• Zugriff auf die SharePoint 2010-Zentraladministration. Dies schließt den Suchdienst und den Business Data Connectivity-Dienst ein.

• Zugriff auf SharePoint Designer.

• Eine SharePoint 2010-Webanwendung mit einer Websitesammlung. Weitere Informationen finden Sie unter Erstellen einer Websitesammlung (SharePoint Server 2010. Beachten Sie, dass Sie Sharepoint - 80 verwenden können.

• Zugriff auf Microsoft SQL Server. Beachten Sie, dass Sie dieselbe Instanz von SQL Server verwenden können wie der Computer, auf dem SharePoint Server 2010 ausgeführt wird.

• Eine Beispieldatenbank für Microsoft SQL Server (In diesem Beispiel wird AdventureWorks verwendet. Informationen zum Installieren dieser Beispieldatenbank finden Sie unter AdventureWorks 2008 R2.)

Erläuterung zur XML-Datei im BDC-Modell

Im letzten Abschnitt haben Sie Änderungen an der XML-Version des BDC-Modells vorgenommen. In diesem Abschnitt werden die meisten Elemente dieser XML-Datei erläutert. Sie können diesen Abschnitt überspringen und zum nächsten Abschnitt über inkrementelle Durchforstungen wechseln, falls diese Details nicht Ihr Interesse wecken. Dieses Informationen sind zum Vervollständigen der Beispiele nicht erforderlich. Es kann hilfreich sein, wenn Sie sich eine tatsächliche XML-Datei des Modells ansehen, während Sie dies lesen.

Das Element der obersten Ebene ist das Model-Element. Es besitzt ein Name-Attribut, das beim Importieren als Name des Modells angezeigt wird. LobSystems ist ein untergeordnetes Element von Model. Es kann mindestens ein untergeordnetes LobSystem-Element enthalten. Das LobSystem-Element besitzt ein Name-Attribut, mit dem die externe Datenquelle auf einfache Art bestimmt werden kann. Zudem besitzt es ein Type-Attribut zur Angabe des Typs von Datenquelle. Für diese Beispiele ist Type auf Database festgelegt.

Die tatsächlichen Verbindungsinformationen für diese Datenquelle ist in Property-Elementen im LobSystemInstance-Element definiert, das ein untergeordnetes Element von LobSystemInstances ist. LobSystemInstances ist ein untergeordnetes Element von LobSystem. Property-Elemente werden im BDC-Modell häufig verwendet. Zahlreiche dieser Elemente lassen ein Properties-Element mit mindestens einem Property-Element zu. Ein Property-Element besitzt ein Name-Attribut, das die Eigenschaft identifiziert, und ein Type-Attribut zur Identifikation des .NET-Werttyps für diese Eigenschaft. Der Wert wird dann im Hauptteil dieses Property-Elements angezeigt. In Tabelle 1 sind einige Eigenschaftennamen für LobSystemInstance zusammengestellt.

Tabelle 1. Eigenschaften für 'LobSystemInstance'

Name	Typ	Beispielwert
AuthenticationMode	System.String	PassThrough
DatabaseAccessProvider	System.String	SqlServer
RdbConnection Data Source	System.String	localhost
RdbConnection Initial Catalog	System.String	AdventureWorks
RdbConnection Integrated Security	System.String	SSPI
RdbConnection Pooling	System.String	True
ShowInSearchUI	System.String	<beliebiger Wert>

Wie Ihnen vielleicht aufgefallen ist, sind alle Eigenschaften, die mit RdbConnection beginnen, reguläre Werte für Verbindungszeichenfolgen für eine SQL-Datenbank. Jeder in einer Verbindungszeichenfolge angezeigte Wert kann in dieser Liste mit Eigenschaften definiert werden, indem ihm RdbConnection vorangestellt wird. Die letzte aufgeführte Eigenschaft, ShowInSearchUI, besitzt keinen Wert. Sie ist zwar als Zeichenfolge definiert, es muss jedoch nur die Eigenschaft vorhanden sein, damit das Modell erkennt, dass das LobSystemInstance-Element in der Benutzeroberfläche angezeigt werden muss.

Ein weiteres untergeordnetes Element von LobSystem ist Entities. Das Element kann zwar mindestens ein untergeordnetes Entity-Element enthalten, in der Regel werden Modelle jedoch mit einer Entität angezeigt. Das Entity-Element entspricht einem einzelnen externen Inhaltstyp. Für ein Entity-Element sind mehrere Attribute möglich. Eingeschlossen sind das Name- und das DefaultDisplayName-Attribut. In Tabelle 2 sind die Eigenschaften für ein Entity-Element aufgeführt.

Tabelle 2. Eigenschaften für 'Entity'

Name	Typ	Beispielwert
Title	System.String	Name
DefaultAction	System.String	View Profile

Mit der Title-Eigenschaft wird das Feld definiert, das als Titel in den Suchergebnissen verwendet wird. Die DefaultAction-Eigenschaft verweist auf ein Action-Element nach Namen. Diese Aktion wird als Verknüpfung in den Suchergebnissen verwendet. In diesen Beispielen ist diese Aktion immer so festgelegt, dass eine URL für eine Profilseite geöffnet wird.

Zu den untergeordneten Elementen für ein Entity-Element zählen AccessControlList, Identifiers, AssociationGroups, Actions und Methods.

Das AccessControlList-Element kann mindestens ein AccessControlEntry-Element mit einem Principal-Attribut enthalten, das den Benutzernamen angibt, dem Zugriff erteilt werden soll. Die untergeordneten Elemente sind Right-Elemente, die Zugriffsrechte für den Prinzipal definieren. Jedes Right-Element besitzt ein BdcRight-Attribut, das Edit, Execute, SetPermissions oder SelectableInClients lauten kann.

Das Identifiers-Element enthält ein Identifier-Element mit einem Name-Attribut für den Feldnamen, der als Bezeichner für die Entität verwendet wird, und ein TypeName-Attribut mit dem .NET-Datentyp des Bezeichners.

Das AssociationGroups-Element wird zum Definieren von Zuordnungen zwischen externen Inhaltstypen verwendet. Das Actions-Element enthält ein Action-Element, in der Regel dient es dem Öffnen einer Profilseite. Diese können auf einfache Art von SharePoint Designer definiert werden. Daher werden sie hier nicht näher erläutert.

Das Methods-Element beinhaltet mindestens ein Method-Element. Jedes Method-Element besitzt ein Name-Attribut zur eindeutigen Identifizierung der Methode für diese Entität. Es besitzt auch ein AccessControlList-Element, das mit dem Element im Entity-Element identisch ist. In Tabelle 3 sind die Eigenschaften für ein Method-Element aufgeführt.

Tabelle 3. Eigenschaften für 'Model'

Name	Typ	Beispielwert
RdbCommandType	System.String	System.Data.CommandType ...
RdbCommandText	System.String	SELECT [ProductID], [ProductModelID] FROM [Production].[Product]
BackEndObjectType	System.String	SqlServerTable
BackEndObject	System.String	Product
Schema	System.String	Production

Das RdbCommandText-Element ist sehr wichtig, da Sie mit diesem Element die für die Daten verwendete SQL-Abfrage anpassen können. Falls Sie z. B. in einer bestimmten Datenbank keine Sicht erstellen können, könnten Sie den Text so konfigurieren, dass Verknüpfungen innerhalb des Befehlstexts erstellt werden, solange die Rückgabeparameter übereinstimmen. Das BackEndObjectType-Element kann SqlServerView sein, falls sich RdbCommandText auf eine Sicht anstatt auf eine Tabelle bezieht.

FilterDescriptors ist ein untergeordnetes Element von Method. Es kann mindestens ein untergeordnetes FilterDescriptor-Element enthalten. SharePoint Designer unterstützt das Erstellen von Filtern in seiner Benutzeroberfläche. Diese sind jedoch nicht immer nützlich für Suchmethoden, in denen Sie die SQL-Abfrage steuern. Der Filter SynchronizationCookie wird im nächsten Abschnitt gezeigt.

Parameters ist ein untergeordnetes Element von Method. Es kann mindestens ein untergeordnetes Parameter-Element enthalten. Das Parameter-Element besitzt ein Name-Attribut zur eindeutigen Identifizierung des Parameters und ein Type-Attribut, das In, InOut oder Return lauten kann. Es kann nur ein einzelner Parameter für jedes Method-Element angegeben sein, das vom Typ Return ist. Die Anzahl und Typen von Parametern werden durch den Vorgang bestimmt, der von der Methode implementiert wird. Zahlreiche dieser Vorgänge können mithilfe von SharePoint Designer definiert werden. Daher ist es am einfachsten, den Vorgang dort zu erstellen und dann bei Bedarf zu bearbeiten. Zwei Vorgänge, die von SharePoint Designer nicht definiert werden können, ChangedIdEnumerator und DeletedIdEnumerator, werden im nächsten Abschnitt definiert.

Der Parameter wird tatsächlich durch das untergeordnete TypeDescriptor-Element definiert. Dieses Element besitzt Attribute für Name, TypeName und IdentifierName. Einige Elemente besitzen einfache Typen und werden durch ein einzelnes TypeDescriptor-Element definiert. Andere sind sehr komplex mit geschachtelten TypeDescriptors- und TypeDescriptor-Elementen und zusätzlichen Eigenschaften. In Tabelle 4 sind einige Eigenschaften für ein TypeDescriptor-Element aufgeführt.

Tabelle 4. Eigenschaften für 'TypeDescriptor'

Name	Typ	Beispielwert
Size	System.Int32	25
RequiredInForms	System.Boolean	true
Decimal Digits	System.Int32	4

In den meisten Fällen sollte es möglich sein, die von SharePoint Designer definierten Parameter zu kopieren und zu bearbeiten.

Das letzte wichtige untergeordnete Element des Method-Elements ist MethodInstances. Es enthält ein MethodInstance-Element zur Definition der Art des Vorgangs. Das Type-Attribut kann Finder, SpecificFinder, AssociationNavigator, IdEnumerator und anders lauten. Das ReturnParameterName-Attribut muss auf den Namen des Attributs verweisen, das den Rückgabewert des Vorgangs definiert. Das Default-Attribute lautet in der Regel true, da nur eine Methode für jeden Vorgang definiert wird. Falls mehrere Finder-Elemente beispielsweise standardmäßig angegeben sind, würde hier angegeben, welches Element zu verwenden ist. Das Name-Attribut identifiziert das MethodInstance-Element, und das DefaultDisplayName-Element wird verwendet, wenn der Vorgangsname angezeigt wird. Das MethodInstance-Element besitzt einige wichtige Eigenschaften, die in Tabelle 5 dargestellt sind.

Tabelle 5. Eigenschaften für 'MethodInstance'

Name	Typ	Beispielwert
RootFinder	System.String	<beliebiger Wert>
AttachmentAccessor	System.String	<beliebiger Wert>
LastModifiedTimeStampField	System.String	ModifiedDate

Mit RootFinder wird die Finder-Methode angegeben, die vom Suchcrawler zum Enumerieren aller Zeilen auf oberster Ebene verwendet wird, die durchforstet werden sollen. Es sollte nur eine Finder-Methode für RootFinder angegeben sein. Die AttachmentAccessor-Eigenschaft wurde im vorherigen Abschnitt erläutert, und die LastModifiedTimeStampField-Eigenschaft wird im nächsten Abschnitt behandelt.

Weitere Informationen zum BDC-Modell finden Sie unter Weitere Ressourcen.

Ändern des externen Inhaltstyps zur Unterstützung von inkrementellen Durchforstungen

Das konstante Ausführen vollständiger Durchforstungen für die in diesen Beispielen verwendeten Datensatzmengen ist recht einfach. Es funktioniert jedoch nicht mehr so einfach, wenn Sie eine Million Datensätze indizieren möchten. Nachdem der externe Inhaltstyp und die SharePoint Server-Suche für diesen Umfang eingerichtet wurden, bietet sich nun das Ausführen von inkrementellen Durchforstungen an, um Änderungen zu finden und dann nur diese Datensätze im Suchindex zu aktualisieren. SharePoint Server-Suche unterstützt zwei Methoden für inkrementelle Durchforstungen in externen Inhaltstypen. Beide Methoden haben sowohl Vor- als auch Nachteile, zunächst soll jedoch einmal ihre Funktionsweise erläutert werden.

Inkrementelle Durchforstung auf Zeitstempelbasis

Bei dieser Methode wird ein Feld definiert, das den Zeitstempel für die letzte Änderung jedes Datensatzes enthält. Falls dieser Zeitstempel neuer ist als die letzte Durchforstung, werden die Indizes für diesen Datensatz aktualisiert. Für dieses Beispiel wird der externe Inhaltstyp auf der Grundlage einer Sicht geändert, zunächst muss jedoch das Datum der letzten Änderung der Sicht in der AdventureWorks-Datenbank hinzugefügt werden.

So konfigurieren Sie die Product-Sicht und die Description-Sicht zum Hinzufügen des Änderungsdatums

1. Starten Sie SQL Server Management Studio.

2. Wählen Sie im Dialogfeld Verbindung mit Server herstellen die Option Datenbankmodul für Servertyp aus.

3. Geben Sie localhost in das Feld Servername ein.

4. Klicken Sie auf Verbinden.

5. Erweitern Sie das Element Datenbanken in der Gruppe Objekt-Explorer.

6. Klicken Sie mit der rechten Maustaste auf das Element AdventureWorks, und klicken Sie dann auf Neue Abfragen.

7. Führen Sie die ALTER VIEW-Anweisung wie im folgenden Beispiel gezeigt aus.

   ALTER VIEW [Production].[vProductAndDescription] 
   WITH SCHEMABINDING 
   AS 
   SELECT 
   p.[ProductID] 
   ,p.[Name] 
   ,pm.[Name] AS [ProductModel] 
   ,pmx.[CultureID] 
   ,pd.[Description] 
   ,CASE WHEN p.ModifiedDate > pm.ModifiedDate THEN p.ModifiedDate ELSE pm.ModifiedDate END AS ModifiedDate
   FROM [Production].[Product] p 
   INNER JOIN [Production].[ProductModel] pm 
   ON p.[ProductModelID] = pm.[ProductModelID] 
   INNER JOIN [Production].[ProductModelProductDescriptionCulture] pmx 
   ON pm.[ProductModelID] = pmx.[ProductModelID] 
   INNER JOIN [Production].[ProductDescription] pd 
   ON pmx.[ProductDescriptionID] = pd.[ProductDescriptionID];
   

Dadurch wird der Sicht ein neues Feld hinzugefügt. In diesem Beispiel gibt ModifiedDate das neueste Änderungsdatum von Product oder ProductModel an. Wenn Sie auch ProductDescription in diesen Ausdruck einschließen möchten, müssen Sie einen weiteren Fall hinzufügen, um zu bestimmen, welche der Datumsangaben die neueste ist.

So fügen Sie ModifiedDate den Vorgängen für externe Inhaltstypen hinzu

1. Klicken Sie in SharePoint Designer im Navigationsbereich auf Externe Inhaltstypen.

2. Klicken Sie in der Liste auf Products, um diesen externen Inhaltstyp zu konfigurieren.

3. Doppelklicken Sie in der Gruppe Externe Inhaltstypvorgänge auf Elementlesevorgang.

4. Klicken Sie zweimal auf Weiter.

5. Wählen Sie auf der Seite Rückgabeparameter im Bereich Datenquellenelemente das Feld ModifiedDate aus.

6. Klicken Sie auf Fertig stellen.

7. Doppelklicken Sie in der Gruppe Externe Inhaltstypvorgänge auf Listenlesevorgang.

8. Klicken Sie zweimal auf Weiter.

9. Wählen Sie auf der Seite Rückgabeparameter im Bereich Datenquellenelemente das Feld ModifiedDate aus.

10. Wählen Sie im Bereich Eigenschaften das Feld neben Zeitstempelfeld aus.

    Abbildung 18. Festlegen des Zeitstempelfelds

    

11. Klicken Sie auf Fertig stellen.

12. Speichern Sie den externen Inhaltstyp.

Durch Auswahl des Felds für das Feld Timestamp haben Sie festgelegt, dass dieses Feld vom Suchdienst verwendet wird, um zu bestimmen, ob der Datensatz seit der letzten Durchforstung geändert worden ist. Intern besitzt der XML-Code nun eine LastModifiedTimeStampField-Eigenschaft, die das ModifiedDate-Feld angibt. Falls Sie das Modell für Products exportiert und nach der Eigenschaft gesucht haben, finden Sie sie in den MethodInstances-Eigenschaften für die Read List-Methode.

Nun können Sie die üblichen Schritte zum Erstellen der AWProductSearch-Inhaltsquelle und zum Ausführen einer vollständigen Durchforstung ausführen. Wie zuvor auch möchten Sie vielleicht AWModelSearch löschen, um die Anzeige von Ergebnissen aus beiden Quellen zu vermeiden. Nach Abschluss der vollständigen Durchforstung starten Sie eine inkrementelle Durchforstung. Nach Abschluss der inkrementellen Durchforstung können Sie überprüfen, ob der Vorgang erfolgreich war.

So untersuchen Sie die Ergebnisse der inkrementellen Durchforstung

1. Klicken Sie in der Suchdienstkonfiguration in SharePoint Designer im Navigationsbereich unter Durchforstung auf Durchforstungsprotokoll.

2. Klicken Sie ganz oben auf Durchforstungsverlauf.

Es wird angezeigt, dass die vollständige Durchforstung ca. 296 Erfolge aufweist und die inkrementelle Durchforstung nur 2 Erfolge. Da kein Datensatz geändert wurde, mussten die Datensätze bei der inkrementellen Durchforstung nicht neu indiziert werden.

Falls Sie die geänderten Daten testen möchten, nehmen Sie an mindestens einem Datensatz eine Änderung vor, was die Aktualisierung des ModifiedDate-Felds auf das aktuelle Datum und die aktuelle Uhrzeit einschließt. Führen Sie dann eine weitere inkrementelle Durchforstung aus. Die Erfolge sind mehr als 2 (3, falls Sie einen Datensatz geändert haben), nicht jedoch mehr als 296. Die Abfrage im folgenden Beispiel veranschaulicht diese Art von Änderung.

UPDATE Production.Product
SET Name='Classical Vest, M',ModifiedDate=GETDATE()
WHERE ProductID=865

Inkrementelle Durchforstung auf Änderungsprotokollbasis

Bei dieser Methode speichert SharePoint Server-Suche ein Token oder Cookie, mit dem Änderungen nach der letzten Durchforstung nachverfolgt werden sollen. In diesem Fall handelt es sich bei dem Cookie um einen einzelnen Zeitstempel vom letzten Start einer Durchforstung. Falls nach diesem Zeitpunkt Änderungen aufgetreten sind, werden nur die Änderungen im Index aktualisiert. Für diesen Prozess müssen zwei neue Vorgänge für den externen Inhaltstyp definiert werden: Einer für geänderte Datensätze und einer für gelöschte Datensätze. Diese müssen manuell erstellt werden, da in SharePoint Designer keine Funktion hierzu zur Verfügung steht. (Falls Sie sich den externen Inhaltstyp in SharePoint Designer ansehen, wird er in der Liste Externe Inhaltstypvorgänge angezeigt. Sie können ihn jedoch nicht konfigurieren.) Wie zuvor auch müssen Sie das BDC-Modell exportieren, damit Sie den XML-Code direkt konfigurieren können.

So exportieren Sie das BDC-Modell in eine XML-Datei

1. Klicken Sie in SharePoint Designer im Navigationsbereich auf Externe Inhaltstypen.

2. Klicken Sie in der Liste neben Produkte auf AWProducts, um diesen externen Inhaltstyp auszuwählen.

3. Klicken Sie auf dem Menüband auf BDC-Modell exportieren.

4. Geben Sie im Dialogfeld BDC-Modell exportieren den Begriff Produkte in das Feld Name des BDC-Modells ein.

5. Klicken Sie auf OK.

6. Ändern Sie Dateityp in Alle Dateien.

7. Wählen Sie einen Zielordner für die Datei aus.

8. Ändern Sie das Feld Dateiname in Products.xml.

9. Klicken Sie auf Speichern.

Zur Implementierung dieser beiden Vorgänge benötigen Sie zwei SQL-Abfragen. Eine gibt die Datensätze zurück, die nach einem bestimmten Zeitstempel geändert wurden, und die andere gibt die Datensätze zurück, die nach einem bestimmten Zeitstempel gelöscht wurden. Für die Product-Tabelle verwende ich das Feld DiscontinuedDate, um anzugeben, dass ein Datensatz effektiv gelöscht wurde und nicht mehr in den Suchergebnissen angezeigt werden soll. Falls das DiscontinuedDate-Feld den Wert Null besitzt, ist es weiterhin aktiv. Der DiscontinuedDate-Wert aus der Product-Tabelle muss der Sicht genauso hinzugefügt werden, wie ModifiedDate zuvor hinzugefügt wurde, obwohl Sie sich den ProductModel-Datensatz nicht ansehen müssen. Daher handelt es sich um ein einfaches hinzugefügtes Feld (p.DiscontinuedDate).

Es folgen die neuen Methoden, die Sie dem BDC-Modell für den externen Inhaltstyp Products innerhalb des Methods-Elements hinzufügen müssen. Beide verwenden einen SynchronizationCookie-Filtertyp zum Nachverfolgen des Datums und der Uhrzeit der letzten Änderung. Die SQL-Abfrage muss die entsprechende Gruppe der geänderten oder gelöschten Datensatz-IDs zurückgeben und zudem das Datum und die Uhrzeit der letzten Ausführung aktualisieren. Der wichtigste SQL-Code ist im XML-Code für diese beiden Vorgänge im folgenden Beispiel hervorgehoben.

<Method IsStatic="false" Name="GetChangedProductIds">
  <Properties>
    <Property Name="RdbCommandType" Type="System.Data.CommandType, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">Text</Property>
    <Property Name="RdbCommandText" Type="System.String">
if @LastRunDate != CAST('1900-1-1' as datetime)BEGINSELECT [ProductID] FROM [Production].[vProductAndDescription] WHERE [ModifiedDate] &gt; @LastRunDateENDSET @LastRunDate=CURRENT_TIMESTAMP
    </Property>
    <Property Name="BackEndObjectType" Type="System.String">SqlServerView</Property>
    <Property Name="BackEndObject" Type="System.String">vProductAndDescription</Property>
    <Property Name="Schema" Type="System.String">Production</Property>
  </Properties>
  <AccessControlList>
    <AccessControlEntry Principal="contoso\administrator">
      <Right BdcRight="Edit" />
      <Right BdcRight="Execute" />
      <Right BdcRight="SetPermissions" />
      <Right BdcRight="SelectableInClients" />
    </AccessControlEntry>
  </AccessControlList>
  <FilterDescriptors>
    <FilterDescriptor Name="LastRunDate" Type="InputOutput">
      <Properties>
        <Property Name="SynchronizationCookie" Type="System.String">ChangedItemCookie</Property>
      </Properties>
    </FilterDescriptor>
    <FilterDescriptor Name="FilterDescriptor" Type="Timestamp" />
  </FilterDescriptors>
  <Parameters>
    <Parameter Name="@LastRunDate" Direction="InOut">
      <TypeDescriptor Name="LastRunDateTypeDescriptor" TypeName="System.DateTime" AssociatedFilter="LastRunDate">
        <Interpretation>
          <NormalizeDateTime LobDateTimeMode="Local" />
        </Interpretation>
      </TypeDescriptor>
    </Parameter>
    <Parameter Direction="Return" Name="ChangedProductIds">
      <TypeDescriptor TypeName="System.Data.IDataReader, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IsCollection="true" Name="ChangedProductIds">
        <TypeDescriptors>
          <TypeDescriptor TypeName="System.Data.IDataRecord, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="ChangedProductIdElement">
            <TypeDescriptors>
              <TypeDescriptor TypeName="System.Int32" ReadOnly="true" IdentifierName="ProductID" Name="ProductID">
                <Properties>
                  <Property Name="RequiredInForms" Type="System.Boolean">true</Property>
                </Properties>
              </TypeDescriptor>
            </TypeDescriptors>
          </TypeDescriptor>
        </TypeDescriptors>
      </TypeDescriptor>
    </Parameter>
  </Parameters>
  <MethodInstances>
    <MethodInstance Name="GetChangedPrimaryKeysInstance" Type="ChangedIdEnumerator" ReturnParameterName="ChangedProductIds"  />
  </MethodInstances>
</Method>
<Method IsStatic="false" Name="GetDeletedProductIds">
  <Properties>
    <Property Name="RdbCommandType" Type="System.Data.CommandType, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">Text</Property>
    <Property Name="RdbCommandText" Type="System.String">
SELECT [ProductID] FROM [Production].[vProductAndDescription]
WHERE [ModifiedDate] is null
    </Property>
    <Property Name="BackEndObjectType" Type="System.String">SqlServerView</Property>
    <Property Name="BackEndObject" Type="System.String">vProductAndDescription</Property>
    <Property Name="Schema" Type="System.String">Production</Property>
  </Properties>
  <AccessControlList>
    <AccessControlEntry Principal="contoso\administrator">
      <Right BdcRight="Edit" />
      <Right BdcRight="Execute" />
      <Right BdcRight="SetPermissions" />
      <Right BdcRight="SelectableInClients" />
    </AccessControlEntry>
  </AccessControlList>
  <FilterDescriptors>
    <FilterDescriptor Name="LastRunDate" Type="InputOutput">
      <Properties>
        <Property Name="SynchronizationCookie" Type="System.String">DeletedItemCookie</Property>
      </Properties>
    </FilterDescriptor>
    <FilterDescriptor Name="FilterDescriptor" Type="Timestamp" />
  </FilterDescriptors>
  <Parameters>
    <Parameter Name="@LastRunDate" Direction="InOut">
      <TypeDescriptor Name="LastRunDateTypeDescriptor" TypeName="System.DateTime" AssociatedFilter="LastRunDate">
        <Interpretation>
          <NormalizeDateTime LobDateTimeMode="Local" />
        </Interpretation>
      </TypeDescriptor>
    </Parameter>
    <Parameter Direction="Return" Name="DeletedProductIds">
      <TypeDescriptor TypeName="System.Data.IDataReader, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IsCollection="true" Name="DeletedProductIds">
        <TypeDescriptors>
          <TypeDescriptor TypeName="System.Data.IDataRecord, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="DeletedProductIdElement">
            <TypeDescriptors>
              <TypeDescriptor TypeName="System.Int32" ReadOnly="true" IdentifierName="ProductID" Name="ProductID">
                <Properties>
                  <Property Name="RequiredInForms" Type="System.Boolean">true</Property>
                </Properties>
              </TypeDescriptor>
            </TypeDescriptors>
          </TypeDescriptor>
        </TypeDescriptors>
      </TypeDescriptor>
    </Parameter>
  </Parameters>
  <MethodInstances>
    <MethodInstance Name="GetDeletedPrimaryKeysInstance" Type="DeletedIdEnumerator" ReturnParameterName="DeletedProductIds"  />
  </MethodInstances>
</Method>

Diese Methoden sind zwar sehr lang, sie sind jedoch eigentlich recht einfach und ähnlich. Der Filter ist zur Übergabe des Datums der letzten Ausführung definiert, obwohl es sich tatsächlich um einen Zeitstempel handelt, der sowohl das Datum als auch die Uhrzeit enthält. Der Rückgabeparameter ist als eine Gruppe von Datensätzen definiert, die ein ProductID-Element enthält. Die MethodInstance-Elemente definieren diese Methoden als die Vorgänge für geänderte Datensätze und gelöschte Datensätze.

Auch der SQL-Code ist ähnlich. Beide überprüfen die Gültigkeit des LastRunDate-Zeitstempels. Ist er gültig, werden alle Änderungen seit dem letzten Datum und der letzten Uhrzeit zurückgegeben. Anschließend wird der Zeitstempel auf das aktuelle Datum und die aktuelle Uhrzeit aktualisiert, sodass der Cookie mit dem neuen Wert gespeichert wird. Von der Methode für geänderte Datensätze wird ModificationDate mit dem letzten Zeitstempel verglichen, und die Methode für gelöschte Datensätze wird mit DiscontinuedDate verglichen.

Es sollte noch eine weitere Änderung vorgenommen werden, damit diese Methode ordnungsgemäß implementiert wird. Der SQL-Code für den Vorgang Read List sollte so aktualisiert werden, dass sichergestellt ist, dass gelöschte Datensätze nicht in eine vollständige Durchforstung eingeschlossen werden, wie im folgenden Beispiel gezeigt.

<Property Name="RdbCommandText" Type="System.String">
SELECT [ProductID],[Name],[ProductModel],[CultureID],[Description]
FROM [Production].[vProductAndDescription]
WHERE [DiscontinuedDate] IS NULL
</Property>

Nehmen Sie diese Änderungen am Products-Modell vor, und entfernen Sie auch die LastModifiedTimeStampField-Eigenschaft, um zu überprüfen, ob die neuen Methoden funktionieren. Importieren Sie das geänderte Modell mithilfe der BDC-Dienstkonfiguration in der SharePoint-Zentraladministration.

So importieren Sie eine XML-Datei zur Aktualisierung eines BDC-Modells

1. Klicken Sie in der BDC-Dienstkonfiguration in der SharePoint-Zentraladministration auf die Registerkarte Bearbeiten.

2. Wählen Sie im Abschnitt Ansicht des Menübands aus der Dropdownliste Externe Inhaltstypen aus.

3. Klicken Sie auf das Dropdownmenü für ProductDetail, klicken Sie auf Löschen, und klicken Sie dann auf OK.

4. Klicken Sie auf OK.

5. Wählen Sie im Abschnitt BDC-Modelle des Menübands die Option Importieren aus.

6. Geben Sie in das Feld BDC-Modelldatei den Namen der XML-Datei ein, oder klicken Sie auf Durchsuchen, um die Datei zu suchen.

7. Klicken Sie auf Importieren. Es können eine oder zwei Warnungen angezeigt werden, es sollten aber keine Fehler vorhanden sein.

8. Klicken Sie auf OK.

Nun können Sie das Ganze testen, indem Sie die Inhaltsquelle für die SharePoint Server-Suche neu erstellen und dann Änderungen an den Datensätzen vornehmen, die inkrementelle Durchforstung und die Suche starten und die Ergebnisse anzeigen.

Falls in der Datenbank Datensätze gelöscht werden müssen, anstatt diese nur als gelöscht zu kennzeichnen, müssen Sie einen anderen Ansatz zum Nachverfolgen dieser Löschungen verwenden. Am Einfachsten erstellen Sie eine neue Tabelle für gelöschte IDs. Fügen Sie der ursprünglichen Tabelle dann einen Trigger hinzu, mit dem die Datensätze der neuen Tabelle hinzugefügt werden, wenn diese gelöscht werden. In der Tabelle der gelöschten Datensätze könnten IDs und ein Zeitstempel gespeichert werden. Falls die inkrementellen Durchforstungen nach einem Zeitplan ausgeführt werden, können Sie auch einen SQL-Auftrag zum Löschen alter Datensätze aus der Tabelle planen.

Vergleichen des Ansatzes auf Zeitstempelbasis mit dem Ansatz auf Änderungsprotokollbasis

Der Ansatz auf Zeitstempelbasis kann viel einfacher implementiert werden. Der Ansatz auf Änderungsprotokollbasis ist jedoch viel effizienter. Der Ansatz auf Zeitstempelbasis erfordert, dass die Zeitstempel für jeden Datensatz gespeichert und dann bei jeder Ausführung einer inkrementellen Durchforstung verglichen werden. Der Ansatz auf Änderungsprotokollbasis erfordert, dass vom Suchdienst nur ein einzelner Zeitstempel gespeichert wird. Wenn der Suchdienst darüber hinaus die Änderungen anfordert, werden nur die geänderten Datensätze verarbeitet. Falls zahlreiche Datensätze vorhanden sind, wird mit dem Ansatz auf Änderungsprotokollbasis Zeit und Speicherplatz gespart. Falls nur sehr wenige Datensätze vorhanden sind, sind die inkrementellen Durchforstungen nicht wirklich erforderlich. Falls Sie nicht sicher sind, welchen Ansatz Sie verwenden sollen, können Sie zunächst den Ansatz auf Zeitstempelbasis testen. Falls sich dann herausstellt, dass er zu langsam ist oder zu viel Festplattenspeicher verwendet, können Sie zum Ansatz auf Änderungsprotokollbasis wechseln. Falls Sie die Datenbank jedoch nicht steuern können, müssen Sie möglicherweise den Ansatz verwenden, der in das vorhandene Schema passt.

Was ist aus dem IDEnumerator geworden?

Falls Sie die SharePoint Server-Suche mit externen Daten seit der Einführung des Geschäftsdatenkatalogs in SharePoint 2007 verwendet haben, haben Sie den IDEnumerator an Stelle des Vorgangs Read List verwendet. Die IDEnumerator-Methode kann in Suchvorgängen weiterhin verwendet werden. Sie wird jedoch in SharePoint Designer nicht direkt unterstützt. Ein Verwendungsbereich von IDEnumerator sah die Unterstützung sehr umfangreicher externen Listen vor, die andernfalls von den Websiteeinstellungen eingeschränkt worden wären. Die Crawler der SharePoint Server-Suche werden durch die Einschränkungseinstellungen nicht beeinträchtigt. Daher müssen Sie die segmenting-Techniken nicht verwenden. Falls Sie bereits einen externen Inhaltstyp mit IDEnumerator definiert haben, können Sie diesen für die SharePoint Server-Suche verwenden. Für neue externe Inhaltstypdefinitionen geht es schneller, wenn Sie den Vorgang Read List in SharePoint Designer verwenden.

Verwenden desselben externen Inhaltstyps für externe Listen

Die Verwendung von externen Inhaltstypen für externe Listen sprengt eigentlich den Rahmen dieses Artikels. Möglicherweise möchten Sie aber denselben externen Inhaltstyp für beides verwenden. Beachten Sie jedoch, dass zahlreiche Anpassungen in der SharePoint Server-Suche auch Auswirkungen auf die Darstellung der externen Liste haben können. Auch können Grenzwerte für Einschränkungen vorhanden sein, die die Effizienz der Durchforstungen in der SharePoint Server-Suche beeinträchtigen. Im Allgemeinen ist es sehr wahrscheinlich besser, verschiedene externe Inhaltstypen zu diesen Zwecken zu verwenden, es sei denn, es handelt sich um sehr einfache Daten und weniger als Tausend Datensätze.

Weitere Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Konfigurieren des SharePoint Server 2010-Suchdiensts für externe Inhaltstypen (Teil 1 von 2)

• Verwalten der Suche in Unternehmen

• Verwalten des Business Data Connectivity-Diensts

• Schemareferenz für Business Connectivity Services

• Von BDC unterstützte stereotype Vorgänge

• The Notion of Associations and the External Item Picker

• Tooling Associations in SharePoint Designer 2010

• Konfigurieren von Secure Store Service (SharePoint Server 2010)

• BCS-Ressourcencenter | SharePoint 2010

Informationen zum Autor

Bob McClellan entwickelt bereits seit fast 30 Jahren Anwendungen, meistens für Datenbanksysteme. Zuletzt hat er an Power Tools for Open XML mitgearbeitet, einer Serie von Windows PowerShell-Befehlen zum Ändern von Open XML-Dokumenten. Bob McClellan besitzt umfangreiche Programmiererfahrung in einer Vielzahl von Computersprachen, Datenbanksystemen und Entwicklungsumgebungen.