Navigation and service panel


Content

This text is fallbacked from the German Version. If you need use Google Translate


Sitecore 7 ContentSearch: Indexierung

By Martin Haas on 6. September 2013, No comments

Mit dem Update auf Sitecore 7 hat sich einiges im Bereich der Suche verändert. In diesem Blog-Beitrag werden die Möglichkeiten der Index-Konfiguration vorgestellt.

Wie bisher kann in der Konfiguration angegeben werden, was wie indexiert werden soll. Allerdings hat man neu viel mehr Möglichkeiten, welche vorher nur mit dem AdvancedDatabaseCrawler möglich waren.

Index erstellen

Die Konfigurationen für Core, Master und Web sind bereits vorhanden und können grundsätzlich auch so belassen werden. Um einen neuen Index für die Inhaltssuche zu erstellen, kopiert man am besten die vorhandene Konfiguration für Web, da damit das Grundgerüst des Index bereits steht und die Referenz auf die Web-DB vorhanden ist.

Index-Type

Wie bisher, hat der Index eine ID. Man kann neu als Index-Typen einen SwitchOnRebuildLuceneIndex verwenden, welcher 2 Verzeichnisse für den Index führt. Wird der Index neu gebaut, wird ein Verzeichnis neu befüllt und das andere ist immer noch für die Suche zugänglich. Dadurch kann verhindert werden, dass die Suche während eines Rebuilds keine Resultate liefert. Zu beachten ist aber, dass die beiden Indexe nicht redundant sind. Es ist vielmehr so, dass ein Index immer einen Schritt zurück ist. Deshalb muss man beim erstmaligem Erstellen des Index auch darauf achten, dass der Build zweimal gestartet wird, damit beide Verzeichnisse ein erstes mal befüllt werden.
Leider funktioniert der Wechsel des Index in der aktuellen Sitecore-Version (7, Update 1) nicht korrekt. Eine Support-DLL kann aber über das Sitecore Support Portal mit Angabe der Ticket-Nummer #392958 angefordert werden.
Tipp: Es empfiehlt sich, diesen Typen auch für den Master-Index zu verwenden, da dieser Index für die Item-Buckets-Suche verwendet wird und es für den Autoren nicht gerade ideal ist, wenn dort kurzfristig keine Resultate erscheinen.

<index id="website_index" type="Sitecore.ContentSearch.LuceneProvider.SwitchOnRebuildLuceneIndex, Sitecore.ContentSearch.LuceneProvider">
...
</index>

Crawling-Strategien

Einem Index können mehrere Crawling-Strategien zugewiesen werden. Allerdings sollte man darauf achten, dass diese einander nicht in die Quere kommen. Die Strategien sind im Sitecore.ContentSearch.Lucene.DefaultIndexConfiguration.config konfiguriert. Nachfolgend ein kurzer Überblick:

IntervalAsynchronousStrategy: Der Index wird in einem bestimmten Interval (konfigurierbar) aktualisiert. Ausserdem kann angegeben werden, für welche Datenbank dies gilt und ob ein Full-Rebuild gemacht werden soll, wenn die Anzahl der geänderten Items den konfigurierten Wert Config.FullRebuildItemCountThreshold überschreitet.

ManualStrategy: Deaktiviert ein automatisches Update. Der Rebuild kann nur manuell angestossen werden.

OnPublishEndAsynchronousStrategy: Der Index wird nach dem publish:end-Event neu gebuilded. Wiederum kann die Datenbank angegeben werden und ob ein Full-Rebuild gemacht werden soll, wenn die Anzahl der geänderten Items den konfigurierten Wert Config.FullRebuildItemCountThreshold überschreitet. Diese Strategie sollte nicht zusammen mit der IntervalAsynchronousStrategy oder der SynchronousStrategy verwendet werden, ist jedoch ideal für das Delivery-System.

RebuildAfterFullPublishStrategy: Der Index wird nach einem Full-Publish komplett neu gebuilded. Auch diese Strategie sollte nicht zusammen mit der IntervalAsynchronousStrategy oder der SynchronousStrategy verwendet werden. Allerdings ist die Strategie eine ideale Kombination zur OnPublishEndAsynchronousStrategy. Bei der Deklaration im Config-File muss aber darauf geachtet werden, dass die RebuildAfterFullPublishStrategy vor der OnPublishEndAsynchronousStrategy definiert wird. Dies weil  itecore die Publikationsstrategie anhand der Reihenfolge in der Konfiguration durchgeht und dadurch nach einem Full-Publish die RebuildAfterFullPublishStrategy aufruft, aber nicht die OnPublishEndAsynchronousStrategy, obwohl der Event publish:end mehrmals ausgelöst wurde.

RemoteRebuildStrategy: Der Index auf der Delivery-Umgebung wird dann komplett neu erstellt, wenn auf der Autorenumgebung ein Full-Rebuild ausgelöst wird.

SynchronousStrategy: Daten im Index werden sofort aktualisiert. Diese Strategie ist CPU-intensiv und sollte daher nicht auf Delivery-Umgebungen angewandt werden. Sie ist jedoch ideal für Autorenumgebungen, da die Resultate bei der Item-Buckets-Suche immer aktuell sind.

Item-Locations

Um einen neuen Pfad zum Index hinzuzufügen, kann man in der Konfiguration eine neue Location hinzufügen:


  
    web
    /sitecore/content/Website/Folder/
  

Konfiguration des Index

Grundsätzlich wird die Sitecore.ContentSearch.Lucene.DefaultIndexConfiguration.config verwendet. Wenn man allerdings nur einen Abschnitt ändern möchte, muss man die Konfiguration komplett neu erstellen.
Hier empfiehlt es sich, den Knoten der DefaultIndexConfiguration zu kopieren und nach den locations einzufügen. Ich möchte hier nur auf einige wenige Konfigurationsmöglichkeiten eingehen. Die restlichen ergeben sich aus den Kommentaren in der DefaultIndexConfiguration:

IndexAllFields: Definiert, ob alle Felder indexiert werden sollen oder nicht. Wenn dieses Setting auf true gesetzt ist, können im Knoten <exclude hint="list:ExcludeField"> bestimmte Felder ausgeschlossen werden. Ansonsten müssen die zu indexierenden Feldern im Knoten <include hint="list:IncludeField"> definiert werden.

ComputedIndexFields: Der Knoten <fields hint="raw:AddComputedIndexField"> kann dafür verwendet werden, Computed Fields zum Index hinzuzufügen. Computed Fields enhalten Werte, welche nicht direkt aus dem Item ausgelesen werden. Sie können aber mittels einer eigenen .NET-Klasse abgefüllt werden und sind das Werkzeug, um den Index zu individualisieren. So ist es zum Beispiel möglich, den Inhalt von referenzierten Items (z.B. News) in das Page-Item (z.B. News-Overview) zu schreiben.

Computed Field anlegen
Hier ein Beispiel, wie ein Computed-Field definiert werden kann:

Klasse,Assembly name

Die Klasse implementiert das Interface IComputedIndexField und in der Methode ComputeFieldValue kann der Wert des Feldes bestimmt werden. Hier ein kleines Code-Beispiel:

public object ComputeFieldValue(IIndexable indexable)
{
    var item = (SitecoreIndexableItem)indexable;

    if (item != null && item.Item != null)
    {
        Item sitecoreItem = item.Item;

        if (!string.IsNullOrEmpty(sitecoreItem["Abstract"]))
        {
            return sitecoreItem["Abstract"];
        }

        if (!string.IsNullOrEmpty(sitecoreItem["Lead Text"]))
        {
            return sitecoreItem["Lead Text"];
        }
    }

    return string.Empty;
}

Wie man sieht, kann man normale Item-Operationen vornehmen und dadurch den entsprechenden Wert aus dem Feld "Abstract" zurückgeben. Natürlich ist es auch möglich, referenzierte Items aus Feldern zu lesen und deren Inhalt in das ComputedField zu speichern. Dabei muss aber beachtet werden, dass die Context-Sprache beim Indexieren nicht die Sprache des zu indexierenden Items ist. Das bedeutet, dass man das referenzierte Item zuerst in der Sprache des SitecoreIndexableItem laden muss, bevor man den Wert abspeichern kann.

No comments

Add your comment

Your email address will not be published. Required fields are marked *

*