Inhaltsconnector erstellen

Ein Inhalts-Connector ist ein Softwareprogramm, mit dem die Daten in einem des Unternehmens gespeichert und eine Datenquelle befüllt wird. Google stellt Folgendes zur Verfügung: Optionen für die Entwicklung von Inhalts-Connectors:

  • Das Content Connector SDK Dies ist eine gute Option, wenn Sie in Java. Das Content Connector SDK ist ein Wrapper der REST API, mit der Sie schnell Connectors erstellen können. Um Inhalte zu erstellen mit dem SDK verwenden, finden Sie Erstellen Sie mit dem Content Connector SDK einen Inhaltsconnector.

  • Eine Low-Level-REST API oder API-Bibliotheken. Verwenden Sie diese Optionen, wenn Sie in Java programmieren können oder wenn Ihre Codebasis eine REST API oder eine Bibliothek. Informationen zum Erstellen eines Inhaltsconnectors mit der REST API finden Sie unter bis Erstellen Sie mit der REST API einen Inhaltsconnector.

Mit einem typischen Inhaltsconnector werden die folgenden Aufgaben ausgeführt:

  1. Konfigurationsparameter lesen und verarbeiten
  2. diskrete Teile indexierbarer Daten abzurufen, sogenannte Elemente vom Drittanbieter Inhalts-Repository.
  3. ACLs, Metadaten und Inhaltsdaten zu indexierbaren Elementen kombinieren
  4. Elemente werden in der Cloud Search-Datenquelle indexiert.
  5. (Optional) Wartet auf Änderungsbenachrichtigungen von Inhalten Dritter zu erstellen. Änderungsbenachrichtigungen werden in Indexierungsanfragen umgewandelt, damit die Cloud Search-Datenquelle und das Repository des Drittanbieters synchronisiert. Die Connector führt diese Aufgabe nur aus, wenn das Repository die Änderungserkennung unterstützt.

Mit dem Content Connector SDK Inhaltsconnectors erstellen

In den folgenden Abschnitten wird erläutert, wie Sie mithilfe der Funktion Content Connector SDK

Abhängigkeiten einrichten

Sie müssen bestimmte Abhängigkeiten in Ihre Build-Datei aufnehmen, um das SDK verwenden zu können. Klicken Sie auf auf einem Tab, um die Abhängigkeiten für Ihre Build-Umgebung anzuzeigen:

Maven

<dependency>
<groupId>com.google.enterprise.cloudsearch</groupId>
<artifactId>google-cloudsearch-indexing-connector-sdk</artifactId>
<version>v1-0.0.3</version>
</dependency>

Gradle

compile group: 'com.google.enterprise.cloudsearch',
        name: 'google-cloudsearch-indexing-connector-sdk',
        version: 'v1-0.0.3'

Connector-Konfiguration erstellen

Jeder Connector verfügt über eine Konfigurationsdatei mit den Parametern, die vom Connector, z. B. die ID für Ihr Repository. Parameter sind definiert als Schlüssel/Wert-Paare, z. B. api.sourceId=1234567890abcdef

Das Google Cloud Search SDK enthält verschiedene von Google bereitgestellte Parameter, die von allen Connectors verwendet werden. Du musst Folgendes deklarieren Von Google bereitgestellte Parameter in Ihrer Konfigurationsdatei:

  • Für einen Inhaltsconnector müssen Sie Folgendes deklarieren: api.sourceId und api.serviceAccountPrivateKeyFile, da diese Parameter den Standort identifizieren. Ihres Repositorys und des privaten Schlüssels, die für den Zugriff auf das Repository erforderlich sind.
  • Für einen Identitätsconnector müssen Sie api.identitySourceId so deklarieren: gibt den Speicherort der externen Identitätsquelle an. Wenn Sie Nutzer synchronisieren, müssen Sie auch api.customerId als eindeutige ID für mit dem Google Workspace-Konto Ihres Unternehmens.

Sofern Sie die Standardwerte anderer von Google bereitgestellter müssen Sie diese nicht in Ihrer Konfigurationsdatei angeben. Weitere Informationen zu den von Google bereitgestellten Konfigurationsparametern zum Generieren bestimmter IDs und Schlüssel erhalten Sie unter Von Google bereitgestellte Konfigurationsparameter

Sie können auch eigene Repository-spezifische Parameter zur Verwendung in Ihrem Konfigurationsdatei.

Konfigurationsdatei an den Connector übergeben

Legen Sie das Systemattribut config fest, um die Konfigurationsdatei an Ihr Connector. Sie können das Attribut beim Start mit dem Argument -D festlegen. an den Connector. Mit dem folgenden Befehl wird z. B. der Connector gestartet. durch die Konfigurationsdatei MyConfig.properties:

java -classpath myconnector.jar;... -Dconfig=MyConfig.properties MyConnector

Wenn dieses Argument fehlt, versucht das SDK, auf eine Standardkonfiguration zuzugreifen Datei mit dem Namen connector-config.properties.

Durchlaufstrategie festlegen

Die Hauptfunktion eines Inhaltsconnectors besteht darin, ein Repository zu durchsuchen ihre Daten zu indexieren. Sie müssen eine Durchlaufstrategie implementieren, die auf der Größe und das Layout der Daten in Ihrem Repository. Sie können Ihre eigene Strategie entwickeln oder aus den folgenden im SDK implementierten Strategien:

Durchlauf mit vollständiger Indexierung (Full Traversal)

Bei einer Strategie mit vollständigem Durchlauf wird das gesamte Repository gescannt und blind indexiert für jedes Element. Diese Strategie wird häufig verwendet, wenn Sie ein kleines Repository haben einen vollständigen Durchlauf bei jeder Indexierung leisten können.

Diese Durchlaufstrategie eignet sich für kleine Repositories, statische, nicht hierarchische Daten. Sie können auch diese Durchlaufstrategie verwenden, wenn die Änderungserkennung schwierig ist oder vom Repository nicht unterstützt wird.

Durchlauf mit Teilindexierung (List Traversal)

Bei dieser Strategie wird das gesamte Repository gescannt, einschließlich aller untergeordneten und bestimmt den Status der einzelnen Elemente. Der Connector dauert einen Moment, übergeben und indexiert nur Elemente, die neu sind oder seit der letzten Indexierung. Diese Strategie wird häufig verwendet, um an einem vorhandenen Index aktualisiert werden (anstatt nach jedem wenn Sie den Index aktualisieren).

Diese Durchlaufstrategie eignet sich für das Erkennen von Änderungen werden vom Repository nicht unterstützt, es gibt nicht hierarchische Daten sehr großen Datasets arbeiten.

Graph Traversal

Bei dieser Strategie wird der gesamte übergeordnete Knoten gescannt. Status der einzelnen Elemente. Dann macht der Connector einen zweiten Durchlauf und indexiert nur Elemente im Stammknoten sind neu oder wurden seit der letzten Indexierung aktualisiert. Schließlich übergibt der Connector alle untergeordneten IDs und indexiert dann Elemente in den untergeordneten Knoten. die neu sind oder aktualisiert wurden. Der Connector fährt rekursiv durch bis alle Elemente adressiert sind. Ein solcher Durchlauf ist in der Regel wird für hierarchische Repositories verwendet, bei denen die Auflistung aller IDs praktisch sein.

Diese Strategie ist geeignet, wenn Sie hierarchische Daten haben, z. B. eine Reihe von Verzeichnissen oder Webseiten.

Jede dieser Durchlaufstrategien wird mit einem Vorlagen-Connector implementiert. -Klasse im SDK. Sie können zwar Ihre eigene Durchlaufstrategie implementieren, Vorlagen die Entwicklung Ihres Connectors erheblich beschleunigen. Bis Erstellen Sie einen Connector mithilfe einer Vorlage. Durchlaufstrategie:

Mit einer Vorlagenklasse einen „Full Traversal“-Connector erstellen

Dieser Abschnitt bezieht sich auf Code-Snippets aus dem FullTraversalSample-Beispiel.

Einstiegspunkt des Connectors implementieren

Der Einstiegspunkt für einen Connector ist der main()-Methode. Die Hauptaufgabe dieser Methode besteht darin, eine Instanz des Application und rufen ihre start() um den Connector auszuführen.

Vor dem Anruf application.start(), verwenden Sie die IndexingApplication.Builder -Klasse zum Instanziieren der FullTraversalConnector Vorlage. Die FullTraversalConnector akzeptiert eine Repository Objekt, dessen Methoden Sie implementieren. Das folgende Code-Snippet zeigt, um die Methode main() zu implementieren:

FullTraversalSample.java
/**
 * This sample connector uses the Cloud Search SDK template class for a full
 * traversal connector.
 *
 * @param args program command line arguments
 * @throws InterruptedException thrown if an abort is issued during initialization
 */
public static void main(String[] args) throws InterruptedException {
  Repository repository = new SampleRepository();
  IndexingConnector connector = new FullTraversalConnector(repository);
  IndexingApplication application = new IndexingApplication.Builder(connector, args).build();
  application.start();
}

Im Hintergrund ruft das SDK die initConfig() nach den Aufrufen der Methode main() des Connectors Application.build Die initConfig()-Methode führt folgende Aufgaben aus:

  1. Ruft die Methode Configuation.isInitialized() um sicherzustellen, dass der Configuration noch nicht initialisiert wurde.
  2. Initialisiert ein Configuration-Objekt mit dem von Google bereitgestellten Schlüssel/Wert-Paar Paare. Jedes Schlüssel/Wert-Paar wird in einem ConfigValue innerhalb des Configuration-Objekts.

Repository-Oberfläche implementieren

Die einzige Aufgabe des Repository-Objekts besteht darin, der Indexierung von Repository-Elementen. Bei Verwendung eine Vorlage haben, müssen Sie nur bestimmte Methoden innerhalb der Repository um einen Inhalts-Connector zu erstellen. Welche Methoden Sie überschreiben, hängt vom und die Durchlaufstrategie, die Sie verwenden. Für die FullTraversalConnector , überschreiben Sie die folgenden Methoden:

  • Die init() . Um ein Daten-Repository einzurichten und zu initialisieren, überschreiben Sie init()-Methode.

  • Die getAllDocs() . Um alle Elemente im Daten-Repository zu durchsuchen und zu indexieren, überschreiben Sie getAllDocs()-Methode. Diese Methode wird für jeden geplanten Durchlauf einmal aufgerufen. (gemäß Ihrer Konfiguration).

  • (optional) Das Feld getChanges() . Wenn Ihr Repository die Änderungserkennung unterstützt, überschreiben Sie den getChanges()-Methode. Diese Methode wird für jeden geplanten inkrementellen (wie in Ihrer Konfiguration definiert), um geänderte Elemente abzurufen und indexiert werden.

  • (optional) Das Feld close() . Wenn Sie eine Repository-Bereinigung ausführen müssen, überschreiben Sie den close(). . Diese Methode wird einmal beim Herunterfahren des Connectors aufgerufen.

Jede der Methoden des Das Repository-Objekt gibt einen Typ von ApiOperation -Objekt enthält. Ein ApiOperation-Objekt führt eine Aktion in Form eines einzelnen oder vielleicht mehrere, IndexingService.indexItem() für die tatsächliche Indexierung Ihres Repositorys.

Benutzerdefinierte Konfigurationsparameter abrufen

Im Rahmen der Konfiguration des Connectors müssen Sie alle benutzerdefinierten Parameter aus dem Configuration -Objekt enthält. Diese Aufgabe wird normalerweise in einem Repository Kurs init()-Methode.

Die Configuration-Klasse bietet mehrere Methoden zum Abrufen verschiedener Datentypen aus einer Konfiguration. Bei jeder Methode wird ein ConfigValue-Objekt zurückgegeben. Anschließend führen Sie Verwenden Sie das Objekt ConfigValue get() um den tatsächlichen Wert abzurufen. Das folgende Snippet aus FullTraversalSample, zeigt, wie Sie ein einzelner benutzerdefinierter Ganzzahlwert aus einem Configuration-Objekt:

FullTraversalSample.java
@Override
public void init(RepositoryContext context) {
  log.info("Initializing repository");
  numberOfDocuments = Configuration.getInteger("sample.documentCount", 10).get();
}

Um einen Parameter mit mehreren Werten abzurufen und zu parsen, verwenden Sie einen der Typparser der Klasse Configuration zum Parsen der Daten in separate Blöcke. Im folgenden Snippet aus dem Connector für die Anleitung wird die Methode getMultiValue , um eine Liste der GitHub-Repository-Namen abzurufen:

GithubRepository.java
ConfigValue<List<String>> repos = Configuration.getMultiValue(
    "github.repos",
    Collections.emptyList(),
    Configuration.STRING_PARSER);

Full-Traversal durchführen

Überschreiben getAllDocs() um einen vollständigen Durchlauf (Full Traversal) durchzuführen und das Repository zu indexieren. Das getAllDocs() akzeptiert einen Prüfpunkt. Der Prüfpunkt wird verwendet, um die Indexierung an einem wird der Vorgang unterbrochen. Für jedes Element in Ihrem führen Sie in der Methode getAllDocs() die folgenden Schritte aus:

  1. Legen Sie die Berechtigungen fest.
  2. Legen Sie die Metadaten für das Element fest, das Sie indexieren.
  3. Metadaten und Element in einer indexierbaren Datei kombinieren RepositoryDoc
  4. Verpacken Sie jedes indexierbare Element in einen Iterator, der von getAllDocs() zurückgegeben wird. . Beachten Sie, dass getAllDocs() tatsächlich eine CheckpointCloseableIterable eine Iteration von ApiOperation -Objekte, wobei jedes Objekt eine API-Anfrage darstellt, die für eine RepositoryDoc verwenden, z. B. bei der Indexierung.

Wenn die Gruppe von Elementen zu groß ist, um in einem einzigen Aufruf zu verarbeiten, fügen Sie einen Checkpoint und setzen Sie hasMore(true) um anzuzeigen, dass mehr Elemente für die Indexierung verfügbar sind.

Berechtigungen für ein Element festlegen

Ihr Repository verwendet eine Zugriffssteuerungsliste (Access Control List, ACL), um die Nutzer oder Gruppen, die Zugriff auf ein Element haben. Eine ACL ist eine Liste von IDs für Gruppen oder Nutzer. wer auf das Element zugreifen kann.

Sie müssen die von Ihrem Repository verwendete ACL duplizieren, um sicherzustellen, dass nur diese Nutzer die Zugriff auf ein Element haben, können dieses Element in den Suchergebnissen sehen. Die Beim Indexieren eines Elements muss eine ACL für ein Element enthalten sein, damit Google Cloud Search über die Informationen verfügt, die erforderlich sind, um die richtige Zugriffsebene bereitzustellen. das Element.

Das Content Connector SDK bietet eine Vielzahl von ACL-Klassen und -Methoden, die ACLs der meisten Repositories modellieren. Sie müssen die ACL für jedes Element in Ihr Repository und erstellen Sie eine entsprechende ACL für Google Cloud Search, ein Element zu indexieren. Wenn in der ACL Ihres Repositorys Konzepte wie die ACL verwendet werden Vererbung und die Modellierung einer ACL schwierig sein. Weitere Informationen zu Google Cloud Search-ACLs, siehe ACLs für Google Cloud Search

Hinweis:Die Cloud Search API unterstützt ACLs für einzelne Domains. Nicht domainübergreifende ACLs. Verwenden Sie die Methode Acl.Builder , um den Zugriff auf jedes Element mithilfe einer ACL festzulegen. Das folgende Code-Snippet, Durchlaufs aus dem Full Traversal-Beispiel alle Nutzer oder „Hauptkonten“ (getCustomerPrincipal()) alle Elemente als „Leser“ (.setReaders()) wenn Sie eine Suche durchführen.

FullTraversalSample.java
// Make the document publicly readable within the domain
Acl acl = new Acl.Builder()
    .setReaders(Collections.singletonList(Acl.getCustomerPrincipal()))
    .build();

Sie müssen die ACLs verstehen, um ACLs für das Repository richtig zu modellieren. Für wie z. B. Dateien in einem Dateisystem, verwendet ein Vererbungsmodell, bei dem untergeordnete Ordner Berechtigungen erben aus übergeordneten Ordnern. Für die Modellierung der ACL-Vererbung sind zusätzliche Informationen erforderlich behandelt in ACLs für Google Cloud Search

Metadaten für ein Element festlegen

Metadaten werden in einem Item-Objekt gespeichert. Zum Erstellen eines Item benötigen Sie einen mindestens aus einer eindeutigen String-ID, einem Elementtyp, einer ACL, einer URL und einer Version für das Element besteht. Das folgende Code-Snippet zeigt, wie ein Item mithilfe der IndexingItemBuilder Hilfsklasse.

FullTraversalSample.java
// Url is required. Use google.com as a placeholder for this sample.
String viewUrl = "https://www.google.com";

// Version is required, set to current timestamp.
byte[] version = Longs.toByteArray(System.currentTimeMillis());

// Using the SDK item builder class to create the document with appropriate attributes
// (this can be expanded to include metadata fields etc.)
Item item = IndexingItemBuilder.fromConfiguration(Integer.toString(id))
    .setItemType(IndexingItemBuilder.ItemType.CONTENT_ITEM)
    .setAcl(acl)
    .setSourceRepositoryUrl(IndexingItemBuilder.FieldOrValue.withValue(viewUrl))
    .setVersion(version)
    .build();

Indexierbares Element erstellen

Nachdem Sie die Metadaten für das Element festgelegt haben, können Sie die indexierten mithilfe der Methode RepositoryDoc.Builder . Das folgende Beispiel zeigt, wie ein einzelnes indexierbares Element erstellt wird.

FullTraversalSample.java
// For this sample, content is just plain text
String content = String.format("Hello world from sample doc %d", id);
ByteArrayContent byteContent = ByteArrayContent.fromString("text/plain", content);

// Create the fully formed document
RepositoryDoc doc = new RepositoryDoc.Builder()
    .setItem(item)
    .setContent(byteContent, IndexingService.ContentFormat.TEXT)
    .build();

Ein RepositoryDoc ist ein Typ von ApiOperation, der die tatsächlichen IndexingService.indexItem()-Anfrage

Sie können auch die setRequestMode()-Methode des RepositoryDoc.Builder , um die Indexierungsanforderung als ASYNCHRONOUS oder SYNCHRONOUS zu identifizieren:

ASYNCHRONOUS
Der asynchrone Modus führt zu einer längeren Latenz zwischen Indexierung und Bereitstellung ermöglicht hohe Durchsatzkontingente für Indexierungsanfragen. Der asynchrone Modus ist empfohlen für die erste Indexierung (Backfill) des gesamten Repositorys.
SYNCHRONOUS
Im synchronen Modus ist die Latenz zwischen Indexierung und Bereitstellung kürzer und ermöglicht ein begrenztes Durchsatzkontingent. Der synchrone Modus ist empfohlen für die Indexierung von Updates und Änderungen am Repository. Wenn nicht angegeben ist, wird standardmäßig SYNCHRONOUS verwendet.

Jedes indexierbare Element in einen Iterator verpacken

Die getAllDocs() gibt ein Iterator zurück, insbesondere ein CheckpointCloseableIterable von RepositoryDoc Objekte. Sie können die CheckpointClosableIterableImpl.Builder -Klasse, um einen Iterator zu erstellen und zurückzugeben. Das folgende Code-Snippet zeigt, um einen Iterator zu erstellen und zurückzugeben.

FullTraversalSample.java
CheckpointCloseableIterable<ApiOperation> iterator =
  new CheckpointCloseableIterableImpl.Builder<>(allDocs).build();

Das SDK führt jeden Indexierungsaufruf aus, der im Iterator enthalten ist.

Nächste Schritte

Als Nächstes könnten Sie Folgendes tun:

List Traversal-Connector mithilfe einer Vorlagenklasse erstellen

Die Cloud Search-Indexierungswarteschlange enthält IDs und optionale Hash-Werte -Werte für jedes Element im Repository. Ein List Traversal-Connector sendet der Indexierungswarteschlange von Google Cloud Search hinzu und ruft sie einzeln ab für die Indexierung benötigt. Google Cloud Search verwaltet Warteschlangen und den Inhalt der Warteschlangen zu vergleichen, um den Elementstatus zu ermitteln, z. B. ob ein Element aus dem Repository gelöscht wurden. Weitere Informationen zu Cloud Search Indexierungswarteschlange, siehe Cloud Search-Indexierungswarteschlange

Dieser Abschnitt bezieht sich auf Code-Snippets aus dem ListTraversalSample Beispiel.

Einstiegspunkt des Connectors implementieren

Der Einstiegspunkt für einen Connector ist der main()-Methode. Die Hauptaufgabe dieser Methode besteht darin, eine Instanz des Application und rufen ihre start() um den Connector auszuführen.

Vor dem Anruf application.start(), verwenden Sie die IndexingApplication.Builder -Klasse zum Instanziieren der ListingConnector Vorlage. Für ListingConnector akzeptiert ein Repository Objekt, dessen Methoden Sie implementieren. Das folgende Snippet zeigt, Instanziieren Sie ListingConnector und die zugehörige Repository:

ListTraversalSample.java
/**
 * This sample connector uses the Cloud Search SDK template class for a
 * list traversal connector.
 *
 * @param args program command line arguments
 * @throws InterruptedException thrown if an abort is issued during initialization
 */
public static void main(String[] args) throws InterruptedException {
  Repository repository = new SampleRepository();
  IndexingConnector connector = new ListingConnector(repository);
  IndexingApplication application = new IndexingApplication.Builder(connector, args).build();
  application.start();
}

Im Hintergrund ruft das SDK die initConfig() nach den Aufrufen der Methode main() des Connectors Application.build Die Methode initConfig():

  1. Ruft die Methode Configuation.isInitialized() um sicherzustellen, dass der Configuration noch nicht initialisiert wurde.
  2. Initialisiert ein Configuration-Objekt mit dem von Google bereitgestellten Schlüssel/Wert-Paar Paare. Jedes Schlüssel/Wert-Paar wird in einem ConfigValue innerhalb des Configuration-Objekts.

Repository-Oberfläche implementieren

Die einzige Aufgabe des Repository-Objekts besteht darin, der Indexierung von Repository-Elementen. Wenn Sie eine Vorlage verwenden, müssen Sie Methoden in der Repository-Oberfläche erstellen, um Inhaltsconnectors zu erstellen. Welche Methoden Sie überschreiben, hängt von der verwendeten Vorlage und der Durchlaufstrategie ab. Für die ListingConnector, die folgenden Methoden überschreiben:

  • Die init() . Um ein Daten-Repository einzurichten und zu initialisieren, überschreiben Sie init()-Methode.

  • Die getIds() . Um IDs und Hashwerte für alle Datensätze im Repository abzurufen, überschreiben Sie die Methode getIds().

  • Die getDoc() . Wenn Sie dem Index neue Elemente hinzufügen, Elemente aktualisieren, ändern oder löschen möchten, überschreiben Sie das Feld getDoc()-Methode.

  • (optional) Das Feld getChanges() . Wenn Ihr Repository die Änderungserkennung unterstützt, überschreiben Sie den getChanges()-Methode. Diese Methode wird für jeden geplanten inkrementellen (wie in Ihrer Konfiguration definiert), um geänderte Elemente abzurufen und indexiert werden.

  • (optional) Das Feld close() . Wenn Sie eine Repository-Bereinigung ausführen müssen, überschreiben Sie den close(). . Diese Methode wird einmal beim Herunterfahren des Connectors aufgerufen.

Für jede der Methoden des Repository-Objekts wird ein ApiOperation -Objekt enthält. Ein ApiOperation-Objekt führt eine Aktion in Form eines einzelnen oder vielleicht mehrere, IndexingService.indexItem() für die tatsächliche Indexierung Ihres Repositorys.

Benutzerdefinierte Konfigurationsparameter abrufen

Im Rahmen der Konfiguration des Connectors müssen Sie alle benutzerdefinierten Parameter aus dem Configuration -Objekt enthält. Diese Aufgabe wird normalerweise in einem Repository Kurs init()-Methode.

Die Configuration-Klasse bietet mehrere Methoden zum Abrufen verschiedener Datentypen aus einer Konfiguration. Bei jeder Methode wird ein ConfigValue-Objekt zurückgegeben. Anschließend führen Sie Verwenden Sie das Objekt ConfigValue get() um den tatsächlichen Wert abzurufen. Das folgende Snippet aus FullTraversalSample, zeigt, wie Sie ein einzelner benutzerdefinierter Ganzzahlwert aus einem Configuration-Objekt:

FullTraversalSample.java
@Override
public void init(RepositoryContext context) {
  log.info("Initializing repository");
  numberOfDocuments = Configuration.getInteger("sample.documentCount", 10).get();
}

Um einen Parameter mit mehreren Werten abzurufen und zu parsen, verwenden Sie einen der Typparser der Klasse Configuration zum Parsen der Daten in separate Blöcke. Im folgenden Snippet aus dem Connector für die Anleitung wird die Methode getMultiValue , um eine Liste der GitHub-Repository-Namen abzurufen:

GithubRepository.java
ConfigValue<List<String>> repos = Configuration.getMultiValue(
    "github.repos",
    Collections.emptyList(),
    Configuration.STRING_PARSER);

List Traversal durchführen

Überschreiben getIds() Methode zum Abrufen von IDs und Hash-Werten für alle Datensätze im Repository. An die Methode getIds() kann ein Prüfpunkt übergeben werden. Der Prüfpunkt wird verwendet, um wenn der Vorgang unterbrochen werden sollte.

Als Nächstes überschreiben Sie getDoc() zur Verarbeitung der einzelnen Elemente in der Cloud Search-Indexierungswarteschlange.

Element-IDs und Hashwerte per Push übertragen

Überschreiben getIds() um die Artikel-IDs und die zugehörigen Inhalts-Hashwerte aus der zu erstellen. ID- und Hashwert-Paare werden dann in den Push-Vorgang verpackt. an die Cloud Search-Indexierungswarteschlange. Stamm- oder übergeordnete IDs sind in der Regel wird zuerst verschoben, gefolgt von untergeordneten IDs, bis die gesamte Hierarchie der Elemente verarbeitet werden.

An die Methode getIds() kann ein Prüfpunkt übergeben werden, der das letzte zu erfassende Element darstellt indexiert. Der Prüfpunkt kann verwendet werden, um die Indexierung bei einem bestimmten Element fortzusetzen, wird der Prozess unterbrochen. Führen Sie für jedes Element in Ihrem Repository die folgenden Schritte aus: Schritte in der getIds()-Methode:

  • Rufen Sie jede Artikel-ID und den zugehörigen Hashwert aus dem Repository ab.
  • Verpacken Sie jedes ID-Hashwert-Paar in eine PushItems.
  • Kombinieren Sie alle PushItems in einem Iterator, der vom getIds() . Beachten Sie, dass getIds() tatsächlich eine CheckpointCloseableIterable eine Iteration von ApiOperation -Objekte, wobei jedes Objekt eine API-Anfrage darstellt, die für eine RepositoryDoc zum Beispiel die Elemente in die Warteschlange verschieben.

Im folgenden Code-Snippet sehen Sie, wie Sie die einzelnen Artikel-IDs und Hashwerte abrufen und fügen Sie sie in eine PushItems PushItems ist eine ApiOperation-Anfrage, mit der ein Element an Cloud Search übertragen wird. Warteschlange für die Indexierung.

ListTraversalSample.java
PushItems.Builder allIds = new PushItems.Builder();
for (Map.Entry<Integer, Long> entry : this.documents.entrySet()) {
  String documentId = Integer.toString(entry.getKey());
  String hash = this.calculateMetadataHash(entry.getKey());
  PushItem item = new PushItem().setMetadataHash(hash);
  log.info("Pushing " + documentId);
  allIds.addPushItem(documentId, item);
}

Im folgenden Code-Snippet sehen Sie, wie das Tag PushItems.Builder , um die IDs und Hashwerte in einem einzigen Push zu bündeln. ApiOperation.

ListTraversalSample.java
ApiOperation pushOperation = allIds.build();
CheckpointCloseableIterable<ApiOperation> iterator =
  new CheckpointCloseableIterableImpl.Builder<>(
      Collections.singletonList(pushOperation))
  .build();
return iterator;

Elemente werden zur weiteren Verarbeitung in die Cloud Search-Indexierungswarteschlange verschoben.

Jedes Element abrufen und verarbeiten

Überschreiben getDoc(), um jedes Element in der Cloud Search-Indexierungswarteschlange zu verarbeiten. Ein Element kann neu, geändert oder unverändert sein oder nicht mehr in der Quelle vorhanden sein zu erstellen. Rufen Sie jedes neue oder geänderte Element ab und indexieren Sie es. Elemente entfernen aus dem Index, die nicht mehr im Quell-Repository vorhanden sind.

Die Methode getDoc() akzeptiert ein Element aus Google Cloud Search Warteschlange für die Indexierung. Führen Sie für jedes Element in der Warteschlange die folgenden Schritte im getDoc()-Methode:

  1. Prüfen Sie, ob die ID des Elements in der Cloud Search-Indexierungswarteschlange vorhanden ist im Repository gespeichert. Ist dies nicht der Fall, löschen Sie das Element aus dem Index.

  2. Fragen Sie im Index den Status des Elements ab. Wenn ein Element unverändert ist (ACCEPTED), tun Sie dies nicht. irgendetwas tun.

  3. Indexieren Sie geänderte oder neue Elemente:

    1. Legen Sie die Berechtigungen fest.
    2. Legen Sie die Metadaten für das Element fest, das Sie indexieren.
    3. Metadaten und Element in einer indexierbaren Datei kombinieren RepositoryDoc
    4. Geben Sie RepositoryDoc zurück.

Hinweis: Die Vorlage ListingConnector unterstützt nicht die Rückgabe von null für die Methode getDoc(). Die Rückgabe von null führt zu einem NullPointerException..

Umgang mit gelöschten Elementen

Das folgende Code-Snippet zeigt, wie Sie feststellen, ob ein Element im und falls nicht, löschen Sie es.

ListTraversalSample.java
String resourceName = item.getName();
int documentId = Integer.parseInt(resourceName);

if (!documents.containsKey(documentId)) {
  // Document no longer exists -- delete it
  log.info(() -> String.format("Deleting document %s", item.getName()));
  return ApiOperations.deleteItem(resourceName);
}

Beachten Sie, dass documents eine Datenstruktur ist, die das Repository darstellt. Wenn documentID wurde in documents nicht gefunden, Rückgabe APIOperations.deleteItem(resourceName) um das Element aus dem Index zu löschen.

Umgang mit unveränderten Elementen

Im folgenden Code-Snippet sehen Sie, wie der Status von Elementen in Cloud Search abgefragt wird: Indexierungswarteschlange und Verarbeitung eines unveränderten Elements.

ListTraversalSample.java
String currentHash = this.calculateMetadataHash(documentId);
if (this.canSkipIndexing(item, currentHash)) {
  // Document neither modified nor deleted, ack the push
  log.info(() -> String.format("Document %s not modified", item.getName()));
  PushItem pushItem = new PushItem().setType("NOT_MODIFIED");
  return new PushItems.Builder().addPushItem(resourceName, pushItem).build();
}

Wenn Sie feststellen möchten, ob der Artikel unverändert ist, prüfen Sie auch seinen Status. sowie andere Metadaten, die auf eine Änderung hinweisen können. In diesem Beispiel sind die Metadaten wird verwendet, um festzustellen, ob das Element geändert wurde.

ListTraversalSample.java
/**
 * Checks to see if an item is already up to date
 *
 * @param previousItem Polled item
 * @param currentHash  Metadata hash of the current github object
 * @return PushItem operation
 */
private boolean canSkipIndexing(Item previousItem, String currentHash) {
  if (previousItem.getStatus() == null || previousItem.getMetadata() == null) {
    return false;
  }
  String status = previousItem.getStatus().getCode();
  String previousHash = previousItem.getMetadata().getHash();
  return "ACCEPTED".equals(status)
      && previousHash != null
      && previousHash.equals(currentHash);
}

Berechtigungen für ein Element festlegen

Ihr Repository verwendet eine Zugriffssteuerungsliste (Access Control List, ACL), um die Nutzer oder Gruppen, die Zugriff auf ein Element haben. Eine ACL ist eine Liste von IDs für Gruppen oder Nutzer. wer auf das Element zugreifen kann.

Sie müssen die von Ihrem Repository verwendete ACL duplizieren, um sicherzustellen, dass nur diese Nutzer die Zugriff auf ein Element haben, können dieses Element in den Suchergebnissen sehen. Die Beim Indexieren eines Elements muss eine ACL für ein Element enthalten sein, damit Google Cloud Search über die Informationen verfügt, die erforderlich sind, um die richtige Zugriffsebene bereitzustellen. das Element.

Das Content Connector SDK bietet eine Vielzahl von ACL-Klassen und -Methoden, die ACLs der meisten Repositories modellieren. Sie müssen die ACL für jedes Element in Ihr Repository und erstellen Sie eine entsprechende ACL für Google Cloud Search, ein Element zu indexieren. Wenn in der ACL Ihres Repositorys Konzepte wie die ACL verwendet werden Vererbung und die Modellierung einer ACL schwierig sein. Weitere Informationen zu Google Cloud Search-ACLs, siehe ACLs für Google Cloud Search

Hinweis:Die Cloud Search API unterstützt ACLs für einzelne Domains. Nicht domainübergreifende ACLs. Verwenden Sie die Methode Acl.Builder , um den Zugriff auf jedes Element mithilfe einer ACL festzulegen. Das folgende Code-Snippet, Durchlaufs aus dem Full Traversal-Beispiel alle Nutzer oder „Hauptkonten“ (getCustomerPrincipal()) alle Elemente als „Leser“ (.setReaders()) wenn Sie eine Suche durchführen.

FullTraversalSample.java
// Make the document publicly readable within the domain
Acl acl = new Acl.Builder()
    .setReaders(Collections.singletonList(Acl.getCustomerPrincipal()))
    .build();

Sie müssen die ACLs verstehen, um ACLs für das Repository richtig zu modellieren. Für wie z. B. Dateien in einem Dateisystem, verwendet ein Vererbungsmodell, bei dem untergeordnete Ordner Berechtigungen erben aus übergeordneten Ordnern. Für die Modellierung der ACL-Vererbung sind zusätzliche Informationen erforderlich behandelt in ACLs für Google Cloud Search

Metadaten für ein Element festlegen

Metadaten werden in einem Item-Objekt gespeichert. Zum Erstellen eines Item benötigen Sie einen mindestens aus einer eindeutigen String-ID, einem Elementtyp, einer ACL, einer URL und einer Version für das Element besteht. Das folgende Code-Snippet zeigt, wie ein Item mithilfe der IndexingItemBuilder Hilfsklasse.

ListTraversalSample.java
// Url is required. Use google.com as a placeholder for this sample.
String viewUrl = "https://www.google.com";

// Version is required, set to current timestamp.
byte[] version = Longs.toByteArray(System.currentTimeMillis());

// Set metadata hash so queue can detect changes
String metadataHash = this.calculateMetadataHash(documentId);

// Using the SDK item builder class to create the document with
// appropriate attributes. This can be expanded to include metadata
// fields etc.
Item item = IndexingItemBuilder.fromConfiguration(Integer.toString(documentId))
    .setItemType(IndexingItemBuilder.ItemType.CONTENT_ITEM)
    .setAcl(acl)
    .setSourceRepositoryUrl(IndexingItemBuilder.FieldOrValue.withValue(viewUrl))
    .setVersion(version)
    .setHash(metadataHash)
    .build();

Indexierbares Element erstellen

Nachdem Sie die Metadaten für das Element festgelegt haben, können Sie die indexierten mithilfe der Methode RepositoryDoc.Builder Das folgende Beispiel zeigt, wie ein einzelnes indexierbares Element erstellt wird.

ListTraversalSample.java
// For this sample, content is just plain text
String content = String.format("Hello world from sample doc %d", documentId);
ByteArrayContent byteContent = ByteArrayContent.fromString("text/plain", content);

// Create the fully formed document
RepositoryDoc doc = new RepositoryDoc.Builder()
    .setItem(item)
    .setContent(byteContent, IndexingService.ContentFormat.TEXT)
    .build();

RepositoryDoc ist eine Art von ApiOperation für die eigentliche IndexingService.indexItem()

Sie können auch die setRequestMode()-Methode des RepositoryDoc.Builder , um die Indexierungsanforderung als ASYNCHRONOUS oder SYNCHRONOUS zu identifizieren:

ASYNCHRONOUS
Der asynchrone Modus führt zu einer längeren Latenz zwischen Indexierung und Bereitstellung ermöglicht hohe Durchsatzkontingente für Indexierungsanfragen. Der asynchrone Modus ist empfohlen für die erste Indexierung (Backfill) des gesamten Repositorys.
SYNCHRONOUS
Im synchronen Modus ist die Latenz zwischen Indexierung und Bereitstellung kürzer und ermöglicht ein begrenztes Durchsatzkontingent. Der synchrone Modus ist empfohlen für die Indexierung von Updates und Änderungen am Repository. Wenn nicht angegeben ist, wird standardmäßig SYNCHRONOUS verwendet.

Nächste Schritte

Als Nächstes könnten Sie Folgendes tun:

Graph Traversal-Connector mithilfe einer Vorlagenklasse erstellen

Die Cloud Search-Indexierungswarteschlange enthält IDs und optionale Hashwerte für jedes Element im Repository. Ein Graph Traversal-Connector überträgt Element-IDs der Google Cloud Search-Indexierungswarteschlange Indexierung. Google Cloud Search verwaltet Warteschlangen und vergleicht Warteschlangeninhalte mit Artikelstatus ermitteln, z. B. ob ein Artikel aus dem zu erstellen. Weitere Informationen zur Indexierungswarteschlange von Cloud Search finden Sie unter bis Indexierungswarteschlange in Google Cloud Search

Während des Indexierens wird der Inhalt des Artikels aus dem Daten-Repository und allen IDs untergeordneter Elemente werden in die Warteschlange verschoben. Der Connector fährt rekursiv fort. Es werden IDs von übergeordneten und untergeordneten Elementen verarbeitet, bis alle Elemente verarbeitet wurden.

Dieser Abschnitt bezieht sich auf Code-Snippets aus dem GraphTraversalSample Beispiel.

Einstiegspunkt des Connectors implementieren

Der Einstiegspunkt für einen Connector ist der main()-Methode. Die Hauptaufgabe dieser Methode besteht darin, eine Instanz des Application und rufen ihre start() um den Connector auszuführen.

Vor dem Anruf application.start(), verwenden Sie die IndexingApplication.Builder Klasse, um die Vorlage ListingConnector zu instanziieren. Die ListingConnector akzeptiert eine Repository Objekt, dessen Methoden Sie implementieren.

Das folgende Snippet zeigt, Instanziieren Sie ListingConnector und die zugehörige Repository:

GraphTraversalSample.java
/**
 * This sample connector uses the Cloud Search SDK template class for a graph
 * traversal connector.
 *
 * @param args program command line arguments
 * @throws InterruptedException thrown if an abort is issued during initialization
 */
public static void main(String[] args) throws InterruptedException {
  Repository repository = new SampleRepository();
  IndexingConnector connector = new ListingConnector(repository);
  IndexingApplication application = new IndexingApplication.Builder(connector, args).build();
  application.start();
}

Im Hintergrund ruft das SDK die initConfig() nach den Aufrufen der Methode main() des Connectors Application.build Die Methode initConfig():

  1. Ruft die Methode Configuation.isInitialized() um sicherzustellen, dass der Configuration noch nicht initialisiert wurde.
  2. Initialisiert ein Configuration-Objekt mit dem von Google bereitgestellten Schlüssel/Wert-Paar Paare. Jedes Schlüssel/Wert-Paar wird in einem ConfigValue innerhalb des Configuration-Objekts.

Repository-Oberfläche implementieren

Der einzige Zweck der Das Repository-Objekt besteht darin, das Repository zu durchsuchen und zu indexieren. Elemente. Wenn Sie eine Vorlage verwenden, müssen Sie nur bestimmte Methoden innerhalb des Repository-Schnittstelle, um einen Inhaltsconnector zu erstellen. Die überschriebenen Methoden hängen von der verwendeten Vorlage und Durchlaufstrategie ab. Für die ListingConnector, überschreiben Sie die folgenden Methoden:

  • Die init() . Um ein Daten-Repository einzurichten und zu initialisieren, überschreiben Sie init()-Methode.

  • Die getIds() . Um IDs und Hashwerte für alle Datensätze im Repository abzurufen, überschreiben Sie die Methode getIds().

  • Die getDoc() . Wenn Sie dem Index neue Elemente hinzufügen, Elemente aktualisieren, ändern oder löschen möchten, überschreiben Sie das Feld getDoc()-Methode.

  • (optional) Das Feld getChanges() . Wenn Ihr Repository die Änderungserkennung unterstützt, überschreiben Sie den getChanges()-Methode. Diese Methode wird für jeden geplanten inkrementellen (wie in Ihrer Konfiguration definiert), um geänderte Elemente abzurufen und indexiert werden.

  • (optional) Das Feld close() . Wenn Sie eine Repository-Bereinigung ausführen müssen, überschreiben Sie den close(). . Diese Methode wird einmal beim Herunterfahren des Connectors aufgerufen.

Jede der Methoden des Das Repository-Objekt gibt einen Typ von ApiOperation-Objekt zurück. Ein ApiOperation -Objekt eine Aktion in Form eines einzelnen oder vielen Mehrfachobjekts ausführt, IndexingService.indexItem() für die tatsächliche Indexierung Ihres Repositorys.

Benutzerdefinierte Konfigurationsparameter abrufen

Im Rahmen der Konfiguration des Connectors müssen Sie alle benutzerdefinierten Parameter aus dem Configuration -Objekt enthält. Diese Aufgabe wird normalerweise in einem Repository Kurs init()-Methode.

Die Configuration-Klasse bietet mehrere Methoden zum Abrufen verschiedener Datentypen aus einer Konfiguration. Bei jeder Methode wird ein ConfigValue-Objekt zurückgegeben. Anschließend führen Sie Verwenden Sie das Objekt ConfigValue get() um den tatsächlichen Wert abzurufen. Das folgende Snippet aus FullTraversalSample, zeigt, wie Sie ein einzelner benutzerdefinierter Ganzzahlwert aus einem Configuration-Objekt:

FullTraversalSample.java
@Override
public void init(RepositoryContext context) {
  log.info("Initializing repository");
  numberOfDocuments = Configuration.getInteger("sample.documentCount", 10).get();
}

Um einen Parameter mit mehreren Werten abzurufen und zu parsen, verwenden Sie einen der Typparser der Klasse Configuration zum Parsen der Daten in separate Blöcke. Im folgenden Snippet aus dem Connector für die Anleitung wird die Methode getMultiValue , um eine Liste der GitHub-Repository-Namen abzurufen:

GithubRepository.java
ConfigValue<List<String>> repos = Configuration.getMultiValue(
    "github.repos",
    Collections.emptyList(),
    Configuration.STRING_PARSER);

Graph Traversal durchführen

Überschreiben getIds() Methode zum Abrufen von IDs und Hash-Werten für alle Datensätze im Repository. An die Methode getIds() kann ein Prüfpunkt übergeben werden. Der Prüfpunkt wird verwendet, um wenn der Vorgang unterbrochen werden sollte.

Als Nächstes überschreiben Sie getDoc() zur Verarbeitung der einzelnen Elemente in der Cloud Search-Indexierungswarteschlange.

Element-IDs und Hashwerte per Push übertragen

Überschreiben getIds() um die Artikel-IDs und die zugehörigen Inhalts-Hashwerte aus der zu erstellen. ID- und Hashwert-Paare werden dann in den Push-Vorgang verpackt. an die Cloud Search-Indexierungswarteschlange. Stamm- oder übergeordnete IDs sind in der Regel wird zuerst verschoben, gefolgt von untergeordneten IDs, bis die gesamte Hierarchie der Elemente verarbeitet werden.

An die Methode getIds() kann ein Prüfpunkt übergeben werden, der das letzte zu erfassende Element darstellt indexiert. Der Prüfpunkt kann verwendet werden, um die Indexierung bei einem bestimmten Element fortzusetzen, wird der Prozess unterbrochen. Führen Sie für jedes Element in Ihrem Repository die folgenden Schritte aus: Schritte in der getIds()-Methode:

  • Rufen Sie jede Artikel-ID und den zugehörigen Hashwert aus dem Repository ab.
  • Verpacken Sie jedes ID-Hashwert-Paar in eine PushItems.
  • Kombinieren Sie alle PushItems in einem Iterator, der vom getIds()-Methode. Beachten Sie, dass getIds() tatsächlich eine CheckpointCloseableIterable eine Iteration von ApiOperation -Objekte, wobei jedes Objekt eine API-Anfrage darstellt, die für eine RepositoryDoc zum Beispiel die Elemente in die Warteschlange verschieben.

Im folgenden Code-Snippet sehen Sie, wie Sie die einzelnen Artikel-IDs und Hashwerte abrufen und fügen Sie sie in eine PushItems Ein PushItems ist ein ApiOperation-Anfrage, um ein Element in die Cloud Search-Indexierungswarteschlange zu verschieben.

GraphTraversalSample.java
PushItems.Builder allIds = new PushItems.Builder();
PushItem item = new PushItem();
allIds.addPushItem("root", item);

Im folgenden Code-Snippet sehen Sie, wie das Tag PushItems.Builder , um die IDs und Hashwerte in einem einzigen Push zu bündeln. ApiOperation

GraphTraversalSample.java
ApiOperation pushOperation = allIds.build();
CheckpointCloseableIterable<ApiOperation> iterator =
  new CheckpointCloseableIterableImpl.Builder<>(
      Collections.singletonList(pushOperation))
  .build();

Elemente werden zur weiteren Verarbeitung in die Cloud Search-Indexierungswarteschlange verschoben.

Jedes Element abrufen und verarbeiten

Überschreiben getDoc(), um jedes Element in der Cloud Search-Indexierungswarteschlange zu verarbeiten. Ein Element kann neu, geändert oder unverändert sein oder nicht mehr in der Quelle vorhanden sein zu erstellen. Rufen Sie jedes neue oder geänderte Element ab und indexieren Sie es. Elemente entfernen aus dem Index, die nicht mehr im Quell-Repository vorhanden sind.

Die Methode getDoc() akzeptiert ein Element aus der Cloud Search-Indexierung Wiedergabeliste. Führen Sie für jedes Element in der Warteschlange die folgenden Schritte im getDoc()-Methode:

  1. Prüfen Sie, ob die ID des Elements aus der Cloud Search-Indexierungswarteschlange im zu erstellen. Ist dies nicht der Fall, löschen Sie das Element aus dem Index. Ist das Element vorhanden, fahren Sie mit dem nächsten Schritt fort.

  2. Indexieren Sie geänderte oder neue Elemente:

    1. Legen Sie die Berechtigungen fest.
    2. Legen Sie die Metadaten für das Element fest, das Sie indexieren.
    3. Metadaten und Element in einer indexierbaren Datei kombinieren RepositoryDoc
    4. Fügen Sie die untergeordneten IDs zur weiteren Verarbeitung in die Cloud Search-Indexierungswarteschlange ein.
    5. Geben Sie RepositoryDoc zurück.

Umgang mit gelöschten Elementen

Im folgenden Code-Snippet wird gezeigt, wie Sie feststellen, ob ein Element im Index vorhanden ist. und es nicht löschen.

GraphTraversalSample.java
String resourceName = item.getName();
if (documentExists(resourceName)) {
  return buildDocumentAndChildren(resourceName);
}
// Document doesn't exist, delete it
log.info(() -> String.format("Deleting document %s", resourceName));
return ApiOperations.deleteItem(resourceName);

Berechtigungen für ein Element festlegen

Ihr Repository verwendet eine Zugriffssteuerungsliste (Access Control List, ACL), um die Nutzer oder Gruppen, die Zugriff auf ein Element haben. Eine ACL ist eine Liste von IDs für Gruppen oder Nutzer. wer auf das Element zugreifen kann.

Sie müssen die von Ihrem Repository verwendete ACL duplizieren, um sicherzustellen, dass nur diese Nutzer die Zugriff auf ein Element haben, können dieses Element in den Suchergebnissen sehen. Die Beim Indexieren eines Elements muss eine ACL für ein Element enthalten sein, damit Google Cloud Search über die Informationen verfügt, die erforderlich sind, um die richtige Zugriffsebene bereitzustellen. das Element.

Das Content Connector SDK bietet eine Vielzahl von ACL-Klassen und -Methoden, die ACLs der meisten Repositories modellieren. Sie müssen die ACL für jedes Element in Ihr Repository und erstellen Sie eine entsprechende ACL für Google Cloud Search, ein Element zu indexieren. Wenn in der ACL Ihres Repositorys Konzepte wie die ACL verwendet werden Vererbung und die Modellierung einer ACL schwierig sein. Weitere Informationen zu Google Cloud Search-ACLs, siehe ACLs für Google Cloud Search

Hinweis:Die Cloud Search API unterstützt ACLs für einzelne Domains. Nicht domainübergreifende ACLs. Verwenden Sie die Methode Acl.Builder , um den Zugriff auf jedes Element mithilfe einer ACL festzulegen. Das folgende Code-Snippet, Durchlaufs aus dem Full Traversal-Beispiel alle Nutzer oder „Hauptkonten“ (getCustomerPrincipal()) alle Elemente als „Leser“ (.setReaders()) wenn Sie eine Suche durchführen.

FullTraversalSample.java
// Make the document publicly readable within the domain
Acl acl = new Acl.Builder()
    .setReaders(Collections.singletonList(Acl.getCustomerPrincipal()))
    .build();

Sie müssen die ACLs verstehen, um ACLs für das Repository richtig zu modellieren. Für wie z. B. Dateien in einem Dateisystem, verwendet ein Vererbungsmodell, bei dem untergeordnete Ordner Berechtigungen erben aus übergeordneten Ordnern. Für die Modellierung der ACL-Vererbung sind zusätzliche Informationen erforderlich behandelt in ACLs für Google Cloud Search

Metadaten für ein Element festlegen

Metadaten werden in einem Item-Objekt gespeichert. Zum Erstellen eines Item benötigen Sie einen mindestens aus einer eindeutigen String-ID, einem Elementtyp, einer ACL, einer URL und einer Version für das Element besteht. Das folgende Code-Snippet zeigt, wie ein Item mithilfe der IndexingItemBuilder Hilfsklasse.

GraphTraversalSample.java
// Url is required. Use google.com as a placeholder for this sample.
String viewUrl = "https://www.google.com";

// Version is required, set to current timestamp.
byte[] version = Longs.toByteArray(System.currentTimeMillis());

// Using the SDK item builder class to create the document with
// appropriate attributes. This can be expanded to include metadata
// fields etc.
Item item = IndexingItemBuilder.fromConfiguration(documentId)
    .setItemType(IndexingItemBuilder.ItemType.CONTENT_ITEM)
    .setAcl(acl)
    .setSourceRepositoryUrl(IndexingItemBuilder.FieldOrValue.withValue(viewUrl))
    .setVersion(version)
    .build();

Indexierbares Element erstellen

Nachdem Sie die Metadaten für das Element festgelegt haben, können Sie die indexierten mithilfe der Methode RepositoryDoc.Builder Das folgende Beispiel zeigt, wie ein einzelnes indexierbares Element erstellt wird.

GraphTraversalSample.java
// For this sample, content is just plain text
String content = String.format("Hello world from sample doc %s", documentId);
ByteArrayContent byteContent = ByteArrayContent.fromString("text/plain", content);

RepositoryDoc.Builder docBuilder = new RepositoryDoc.Builder()
    .setItem(item)
    .setContent(byteContent, IndexingService.ContentFormat.TEXT);

Ein RepositoryDoc ist ein Typ von ApiOperation, der die tatsächlichen IndexingService.indexItem()-Anfrage

Sie können auch die setRequestMode()-Methode des RepositoryDoc.Builder , um die Indexierungsanforderung als ASYNCHRONOUS oder SYNCHRONOUS zu identifizieren:

ASYNCHRONOUS
Der asynchrone Modus führt zu einer längeren Latenz zwischen Indexierung und Bereitstellung ermöglicht hohe Durchsatzkontingente für Indexierungsanfragen. Der asynchrone Modus ist empfohlen für die erste Indexierung (Backfill) des gesamten Repositorys.
SYNCHRONOUS
Im synchronen Modus ist die Latenz zwischen Indexierung und Bereitstellung kürzer und ermöglicht ein begrenztes Durchsatzkontingent. Der synchrone Modus ist empfohlen für die Indexierung von Updates und Änderungen am Repository. Wenn nicht angegeben ist, wird standardmäßig SYNCHRONOUS verwendet.

Untergeordnete IDs in die Cloud Search-Indexierungswarteschlange aufnehmen

Im folgenden Code-Snippet sehen Sie, wie die untergeordneten IDs Übergeordnetes Element wird gerade verarbeitet, in die Warteschlange zur Verarbeitung. Diese IDs verarbeitet werden, nachdem das übergeordnete Element indexiert wurde.

GraphTraversalSample.java
// Queue the child nodes to visit after indexing this document
Set<String> childIds = getChildItemNames(documentId);
for (String id : childIds) {
  log.info(() -> String.format("Pushing child node %s", id));
  PushItem pushItem = new PushItem();
  docBuilder.addChildId(id, pushItem);
}

RepositoryDoc doc = docBuilder.build();

Nächste Schritte

Als Nächstes könnten Sie Folgendes tun:

Mit der REST API Inhaltsconnectors erstellen

In den folgenden Abschnitten wird erläutert, wie Sie mithilfe der Funktion REST API

Durchlaufstrategie festlegen

Die Hauptfunktion eines Inhaltsconnectors besteht darin, ein Repository zu durchsuchen ihre Daten zu indexieren. Sie müssen eine Durchlaufstrategie implementieren, die auf der Größe und das Layout der Daten in Ihrem Repository. Die folgenden drei gängigen Durchläufe Strategien:

Durchlauf mit vollständiger Indexierung (Full Traversal)

Bei einer Strategie mit vollständigem Durchlauf wird das gesamte Repository gescannt und blind indexiert für jedes Element. Diese Strategie wird häufig verwendet, wenn Sie ein kleines Repository haben einen vollständigen Durchlauf bei jeder Indexierung leisten können.

Diese Durchlaufstrategie eignet sich für kleine Repositories, statische, nicht hierarchische Daten. Sie können auch diese Durchlaufstrategie verwenden, wenn die Änderungserkennung schwierig ist oder vom Repository nicht unterstützt wird.

Durchlauf mit Teilindexierung (List Traversal)

Bei dieser Strategie wird das gesamte Repository gescannt, einschließlich aller untergeordneten und bestimmt den Status der einzelnen Elemente. Der Connector dauert einen Moment, übergeben und indexiert nur Elemente, die neu sind oder seit der letzten Indexierung. Diese Strategie wird häufig verwendet, um an einem vorhandenen Index aktualisiert werden (anstatt nach jedem wenn Sie den Index aktualisieren).

Diese Durchlaufstrategie eignet sich für das Erkennen von Änderungen werden vom Repository nicht unterstützt, es gibt nicht hierarchische Daten sehr großen Datasets arbeiten.

Graph Traversal

Bei dieser Strategie wird der gesamte übergeordnete Knoten gescannt. Status der einzelnen Elemente. Dann macht der Connector einen zweiten Durchlauf und indexiert nur Elemente im Stammknoten sind neu oder wurden seit der letzten Indexierung aktualisiert. Schließlich übergibt der Connector alle untergeordneten IDs und indexiert dann Elemente in den untergeordneten Knoten. die neu sind oder aktualisiert wurden. Der Connector fährt rekursiv durch bis alle Elemente adressiert sind. Ein solcher Durchlauf ist in der Regel wird für hierarchische Repositories verwendet, bei denen die Auflistung aller IDs praktisch sein.

Diese Strategie ist geeignet, wenn Sie hierarchische Daten haben, wie Reihenverzeichnisse oder Webseiten.

Durchlaufstrategie und Indexelemente implementieren

Jedes indexierbare Element für Cloud Search wird in Cloud Search als Element bezeichnet. die Cloud Search API. Ein Element kann eine Datei, ein Ordner, eine Zeile in einer CSV-Datei oder Datenbankeintrag.

Sobald Ihr Schema registriert ist, können Sie den Index so befüllen:

  1. (optional) Mit items.upload um Dateien für die Indexierung hochzuladen, die größer als 100 KiB sind. Bei kleineren Dateien sollten Sie den Inhalt folgendermaßen einbetten: inlineContent mit items.index

  2. (optional) Mit media.upload um Mediendateien zur Indexierung hochzuladen.

  3. Verwenden Sie items.index, um das Element zu indexieren. Wenn Ihr Schema beispielsweise die Objektdefinition aus dem Film Film verwendet, Schema, eine Indexierungsanfrage für eine einzelne würde wie folgt aussehen:

    {
  "name": "datasource/<data_source_id>/items/titanic",
  "acl": {
    "readers": [
      {
        "gsuitePrincipal": {
          "gsuiteDomain": true
        }
      }
    ]
  },
  "metadata": {
    "title": "Titanic",
    "viewUrl": "http://www.imdb.com/title/tt2234155/?ref_=nv_sr_1",
    "objectType": "movie"
  },
  "structuredData": {
    "object": {
      "properties": [
        {
          "name": "movieTitle",
          "textValues": {
            "values": [
              "Titanic"
            ]
          }
        },
        {
          "name": "releaseDate",
          "dateValues": {
            "values": [
              {
                "year": 1997,
                "month": 12,
                "day": 19
              }
            ]
          }
        },
        {
          "name": "actorName",
          "textValues": {
            "values": [
              "Leonardo DiCaprio",
              "Kate Winslet",
              "Billy Zane"
            ]
          }
        },
        {
          "name": "genre",
          "enumValues": {
            "values": [
              "Drama",
              "Action"
            ]
          }
        },
        {
          "name": "userRating",
          "integerValues": {
            "values": [
              8
            ]
          }
        },
        {
          "name": "mpaaRating",
          "textValues": {
            "values": [
              "PG-13"
            ]
          }
        },
        {
          "name": "duration",
          "textValues": {
            "values": [
              "3 h 14 min"
            ]
          }
        }
      ]
    }
  },
  "content": {
    "inlineContent": "A seventeen-year-old aristocrat falls in love with a kind but poor artist aboard the luxurious, ill-fated R.M.S. Titanic.",
    "contentFormat": "TEXT"
  },
  "version": "01",
  "itemType": "CONTENT_ITEM"
}

  4. (Optional) Verwenden von items.get Aufrufe, um ein Element zu überprüfen wurde indexiert.

Für einen vollständigen Durchlauf müssen Sie in regelmäßigen Abständen den gesamten zu erstellen. Für einen List Traversal oder Graph Traversal, müssen Sie Code für den Umgang mit Repository-Änderungen.

Repository-Änderungen verarbeiten

Sie können jedes Element regelmäßig aus einem Repository erfassen und indexieren, um eine vollständige Indexierung. Sie können zwar damit sicherstellen, dass Ihr Index aktuell ist, die Indexierung bei größeren oder hierarchischen Repositories kostspielig sein kann.

Anstatt ein ganzes Repository regelmäßig mit Indexaufrufen zu indexieren, Sie können auch die Google Cloud-Indexierungswarteschlange verwenden. um Änderungen nachzuverfolgen und nur Elemente zu indexieren, geändert. Sie können die items.push -Anfragen, um Elemente für eine spätere Abfrage und Aktualisierung in die Warteschlange zu stellen. Weitere Informationen Informationen zur Warteschlange für die Google Cloud-Indexierung finden Sie unter Google Cloud-Indexierungswarteschlange

Weitere Informationen zur Google Cloud Search API finden Sie unter Cloud Search API