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:
- Konfigurationsparameter lesen und verarbeiten
- diskrete Teile indexierbarer Daten abzurufen, sogenannte Elemente vom Drittanbieter Inhalts-Repository.
- ACLs, Metadaten und Inhaltsdaten zu indexierbaren Elementen kombinieren
- Elemente werden in der Cloud Search-Datenquelle indexiert.
- (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
undapi.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 auchapi.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 einer List Traversal-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:
- Mithilfe einer Vorlagenklasse einen „Full Traversal“-Connector erstellen
- List Traversal-Connector mithilfe einer Vorlagenklasse erstellen
- Graph Traversal-Connector mithilfe einer Vorlagenklasse erstellen
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:
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:
- Ruft die Methode
Configuation.isInitialized()
um sicherzustellen, dass derConfiguration
noch nicht initialisiert wurde. - Initialisiert ein
Configuration
-Objekt mit dem von Google bereitgestellten Schlüssel/Wert-Paar Paare. Jedes Schlüssel/Wert-Paar wird in einemConfigValue
innerhalb desConfiguration
-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 Sieinit()
-Methode.Die
getAllDocs()
. Um alle Elemente im Daten-Repository zu durchsuchen und zu indexieren, überschreiben SiegetAllDocs()
-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 dengetChanges()
-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 denclose()
. . 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:
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:
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:
- Legen Sie die Berechtigungen fest.
- Legen Sie die Metadaten für das Element fest, das Sie indexieren.
- Metadaten und Element in einer indexierbaren Datei kombinieren
RepositoryDoc
- Verpacken Sie jedes indexierbare Element in einen Iterator, der von
getAllDocs()
zurückgegeben wird. . Beachten Sie, dassgetAllDocs()
tatsächlich eineCheckpointCloseableIterable
eine Iteration vonApiOperation
-Objekte, wobei jedes Objekt eine API-Anfrage darstellt, die für eineRepositoryDoc
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.
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.
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.
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 zum Erstellen und Zurückgeben eines Iterators. Das folgende Code-Snippet zeigt,
um einen Iterator zu erstellen und zurückzugeben.
Das SDK führt jeden Indexierungsaufruf aus, der im Iterator enthalten ist.
Nächste Schritte
Als Nächstes könnten Sie Folgendes tun:
- Optional: Wenn Ihr Indexierungsdurchsatz zu niedrig zu sein scheint, lesen Sie den Hilfeartikel Indexierungsrate für
FullTraversalConnector
erhöhen. - (Optional)
close()
implementieren um Ressourcen vor dem Herunterfahren freizugeben. - Optional: Identitätsconnector erstellen mithilfe des Content Connector SDK.
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
:
Im Hintergrund ruft das SDK die
initConfig()
nach den Aufrufen der Methode main()
des Connectors
Application.build
Die Methode initConfig()
:
- Ruft die Methode
Configuation.isInitialized()
um sicherzustellen, dass derConfiguration
noch nicht initialisiert wurde. - Initialisiert ein
Configuration
-Objekt mit dem von Google bereitgestellten Schlüssel/Wert-Paar Paare. Jedes Schlüssel/Wert-Paar wird in einemConfigValue
innerhalb desConfiguration
-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 Sieinit()
-Methode.Die
getIds()
. Um IDs und Hashwerte für alle Datensätze im Repository abzurufen, überschreiben Sie die MethodegetIds()
.Die
getDoc()
. Wenn Sie dem Index neue Elemente hinzufügen, Elemente aktualisieren, ändern oder löschen möchten, überschreiben Sie das FeldgetDoc()
-Methode.(optional) Das Feld
getChanges()
. Wenn Ihr Repository die Änderungserkennung unterstützt, überschreiben Sie dengetChanges()
-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 denclose()
. . 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:
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:
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 vomgetIds()
. Beachten Sie, dassgetIds()
tatsächlich eineCheckpointCloseableIterable
eine Iteration vonApiOperation
-Objekte, wobei jedes Objekt eine API-Anfrage darstellt, die für eineRepositoryDoc
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.
Im folgenden Code-Snippet sehen Sie, wie das Tag
PushItems.Builder
, um die IDs und Hashwerte in einem einzigen Push zu bündeln.
ApiOperation
.
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:
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.
Fragen Sie im Index den Status des Elements ab. Wenn ein Element unverändert ist (
ACCEPTED
), tun Sie dies nicht. irgendetwas tun.Indexieren Sie geänderte oder neue Elemente:
- Legen Sie die Berechtigungen fest.
- Legen Sie die Metadaten für das Element fest, das Sie indexieren.
- Metadaten und Element in einer indexierbaren Datei kombinieren
RepositoryDoc
- 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.
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.
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.
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.
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.
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.
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:
- (Optional)
close()
implementieren um Ressourcen vor dem Herunterfahren freizugeben. - Optional: Identitätsconnector erstellen mithilfe des Content Connector SDK.
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
:
Im Hintergrund ruft das SDK die
initConfig()
nach den Aufrufen der Methode main()
des Connectors
Application.build
Die Methode initConfig()
:
- Ruft die Methode
Configuation.isInitialized()
um sicherzustellen, dass derConfiguration
noch nicht initialisiert wurde. - Initialisiert ein
Configuration
-Objekt mit dem von Google bereitgestellten Schlüssel/Wert-Paar Paare. Jedes Schlüssel/Wert-Paar wird in einemConfigValue
innerhalb desConfiguration
-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 Sieinit()
-Methode.Die
getIds()
. Um IDs und Hashwerte für alle Datensätze im Repository abzurufen, überschreiben Sie die MethodegetIds()
.Die
getDoc()
. Wenn Sie dem Index neue Elemente hinzufügen, Elemente aktualisieren, ändern oder löschen möchten, überschreiben Sie das FeldgetDoc()
-Methode.(optional) Das Feld
getChanges()
. Wenn Ihr Repository die Änderungserkennung unterstützt, überschreiben Sie dengetChanges()
-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 denclose()
. . 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:
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:
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 vomgetIds()
-Methode. Beachten Sie, dassgetIds()
tatsächlich eineCheckpointCloseableIterable
eine Iteration vonApiOperation
-Objekte, wobei jedes Objekt eine API-Anfrage darstellt, die für eineRepositoryDoc
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.
Im folgenden Code-Snippet sehen Sie, wie das Tag
PushItems.Builder
, um die IDs und Hashwerte in einem einzigen Push zu bündeln.
ApiOperation
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:
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.
Indexieren Sie geänderte oder neue Elemente:
- Legen Sie die Berechtigungen fest.
- Legen Sie die Metadaten für das Element fest, das Sie indexieren.
- Metadaten und Element in einer indexierbaren Datei kombinieren
RepositoryDoc
- Fügen Sie die untergeordneten IDs zur weiteren Verarbeitung in die Cloud Search-Indexierungswarteschlange ein.
- 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.
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.
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.
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.
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.
Nächste Schritte
Als Nächstes könnten Sie Folgendes tun:
- (Optional)
close()
implementieren um Ressourcen vor dem Herunterfahren freizugeben. - Optional: Identitätsconnector erstellen mit dem Identity Connector SDK.
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 einer List Traversal-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:
(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 mititems.index
(optional) Mit
media.upload
um Mediendateien zur Indexierung hochzuladen.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" }
(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