Créer un connecteur de contenu

Un connecteur de contenu est un programme qui permet de balayer les données d'un dépôt d'entreprise et remplir une source de données. Google propose les fonctionnalités suivantes : options de développement de connecteurs de contenu:

Un connecteur de contenu standard exécute les tâches suivantes:

  1. Lit et traite les paramètres de configuration.
  2. Elle extrait des fragments distincts de données indexables, appelées éléments, de l'application tierce un référentiel de contenu.
  3. Combiner les listes de contrôle d'accès, les métadonnées et les données de contenu dans des éléments indexables.
  4. Indexe des éléments dans la source de données Cloud Search.
  5. (Facultatif) Écoute les notifications de modification du contenu tiers un dépôt de clés. Les notifications de modification sont converties en demandes d'indexation la source de données Cloud Search synchronisée avec le dépôt tiers. La le connecteur n'effectue cette tâche que si le dépôt prend en charge la détection des modifications.

Créer un connecteur de contenu à l'aide du SDK Content Connector

Les sections suivantes expliquent comment créer un connecteur de contenu à l'aide de la SDK Content Connector.

Configurer des dépendances

Vous devez inclure certaines dépendances dans votre fichier de compilation pour utiliser le SDK. Cliquez sur dans un onglet ci-dessous pour afficher les dépendances de votre environnement de compilation:

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'

Créer une configuration de connecteur

Chaque connecteur dispose d'un fichier de configuration contenant les paramètres utilisés par par exemple l'ID de votre dépôt. Les paramètres sont définis comme suit : des paires clé-valeur : api.sourceId=1234567890abcdef

Le SDK Google Cloud Search contient plusieurs configurations fournies par Google paramètres utilisés par tous les connecteurs. Vous devez déclarer les éléments suivants : Paramètres fournis par Google dans votre fichier de configuration:

  • Pour un connecteur de contenu, vous devez déclarer api.sourceId et api.serviceAccountPrivateKeyFile, car ces paramètres identifient l'emplacement de votre dépôt et la clé privée nécessaire pour y accéder.
  • Pour un connecteur d'identité, vous devez déclarer api.identitySourceId comme ceci identifie l'emplacement de votre source d'identité externe. Si vous utilisez les utilisateurs synchronisés, vous devez également déclarer api.customerId comme identifiant unique pour le compte Google Workspace de votre entreprise.

À moins que vous ne souhaitiez remplacer les valeurs par défaut des autres vous n'avez pas besoin de les déclarer dans votre fichier de configuration. Pour en savoir plus sur les paramètres de configuration fournis par Google, tels que comment générer certains ID et clés, reportez-vous Paramètres de configuration fournis par Google.

Vous pouvez également définir des paramètres spécifiques au dépôt à utiliser dans votre fichier de configuration.

Transmettre le fichier de configuration au connecteur

Définissez la propriété système config pour transmettre le fichier de configuration à votre le connecteur d'alimentation. Vous pouvez définir la propriété à l'aide de l'argument -D au démarrage le connecteur. Par exemple, la commande suivante permet de démarrer le connecteur avec le fichier de configuration MyConfig.properties:

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

Si cet argument est manquant, le SDK tente d'accéder à une configuration par défaut nommé connector-config.properties.

Déterminer votre stratégie de balayage

La fonction principale d'un connecteur de contenu est de balayer un référentiel pour indexer ses données. Vous devez implémenter une stratégie de balayage adaptée à la taille et la mise en page des données dans votre référentiel. Vous pouvez élaborer votre propre stratégie ou choisir à l'aide des stratégies suivantes implémentées dans le SDK:

Stratégie de balayage complet

Une stratégie de balayage complet consiste à analyser l'intégralité du dépôt et à l'indexer aveuglément. chaque élément. Cette stratégie est couramment utilisée lorsque vous avez un petit dépôt et un balayage complet à chaque indexation.

Cette stratégie de balayage convient aux petits dépôts des données statiques et non hiérarchisées. Vous pouvez également utiliser cette stratégie de balayage lorsque la détection des modifications est difficile ou n'est pas prise en charge par le dépôt.

Stratégie de balayage de liste

La stratégie de balayage de liste analyse l'ensemble du dépôt, y compris les fichiers enfants qui détermine l'état de chaque élément. Ensuite, le connecteur prend une seconde transmet et n'indexe que les éléments nouveaux ou mis à jour depuis la dernière ou l'indexation. Cette stratégie est généralement utilisée pour effectuer les mises à jour d'un index existant (au lieu d'avoir à effectuer un balayage complet lors de la mise à jour de l'index).

Cette stratégie de balayage est adaptée lorsque la détection des modifications est difficile ou non pris en charge par le référentiel, vous avez des données non hiérarchisées, travailler avec de très grands jeux de données.

Traversée de graphe

Une stratégie de balayage de graphe analyse l'intégralité du nœud parent l'état de chaque élément. Il effectue ensuite une seconde passe et n'indexe éléments du nœud racine sont nouveaux ou ont été mis à jour depuis la dernière indexation. Enfin, le connecteur transmet les ID enfants, puis indexe les éléments de ces nœuds qui sont nouveaux ou ont été mis à jour. Le connecteur se poursuit alors de manière récursive via tous les nœuds enfants jusqu'à ce que tous les éléments aient été traités. Ce type de balayage utilisé pour les référentiels hiérarchiques où la liste de tous les ID n'est pas pratiques.

Cette stratégie convient si vous avez des données hiérarchisées qui doivent être explorés, comme une série de répertoires ou de pages Web.

Chacune de ces stratégies de balayage est mise en œuvre par un modèle de connecteur dans le SDK. Vous pouvez implémenter votre propre stratégie de balayage, accélèrent considérablement le développement du connecteur. À créez un connecteur à l'aide d'un modèle, passez à la section correspondant à votre stratégie de balayage:

Créer un connecteur de balayage complet à partir d'un modèle de classe

Cette section fait référence aux extraits de code Exemple FullTraversalSample.

Implémenter le point d'entrée du connecteur

Le point d'entrée d'un connecteur est main(). La tâche principale de cette méthode est de créer une instance de Application et à appeler sa classe start() pour exécuter le connecteur.

Avant d'appeler application.start() utilisez la IndexingApplication.Builder pour instancier FullTraversalConnector modèle. La FullTraversalConnector accepte un Repository dont vous allez implémenter les méthodes. L'extrait de code suivant montre comment pour implémenter la méthode main():

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();
}

En arrière-plan, le SDK appelle initConfig() après les appels de méthode main() du connecteur Application.build La initConfig() méthode effectue les tâches suivantes:

  1. Appelle la méthode Configuation.isInitialized() pour vous assurer que Configuration n'a pas été initialisé.
  2. Elle initialise un objet Configuration avec la clé-valeur fournie par Google. paires. Chaque paire clé-valeur est stockée ConfigValue dans l'objet Configuration.

Implémenter l'interface Repository

L'objet Repository sert uniquement à effectuer le balayage ou l'indexation des éléments du dépôt. Lorsque vous utilisez un modèle, il vous suffit de remplacer certaines méthodes dans Repository pour créer un connecteur de contenu. Les méthodes que vous remplacez dépendent le modèle et la stratégie de balayage. Pour le FullTraversalConnector , remplacez les méthodes suivantes:

  • La init() . Pour configurer et initialiser un référentiel de données, remplacez init().

  • La getAllDocs() . Pour balayer et indexer tous les éléments du référentiel de données, remplacez la getAllDocs(). Cette méthode est appelée une fois pour chaque balayage planifié. (tel que défini par votre configuration).

  • (Facultatif) La propriété getChanges() . Si votre dépôt prend en charge la détection des modifications, remplacez getChanges(). Cette méthode est appelée une fois pour chaque incrémentation planifiée (tel que défini par votre configuration) pour récupérer les éléments modifiés les indexer.

  • (Facultatif) La propriété close() . Si vous devez nettoyer le dépôt, remplacez close() . Cette méthode est appelée une fois lors de l'arrêt du connecteur.

Chacune des méthodes du L'objet Repository renvoie un type de ApiOperation . Un objet ApiOperation effectue une action sous la forme d'un seul élément, ou peut-être plusieurs, IndexingService.indexItem() pour effectuer l'indexation effective de votre dépôt.

Obtenir les paramètres de configuration personnalisés

Dans le cadre de la configuration de votre connecteur, vous devez obtenir des paramètres personnalisés Configuration . Cette tâche est généralement effectuée dans un Repository du cours init().

La classe Configuration comporte plusieurs méthodes pour obtenir différents types de données. à partir d'une configuration. Chaque méthode renvoie un objet ConfigValue. Ensuite, utilisez l'objet ConfigValue get() pour récupérer la valeur réelle. L'extrait de code suivant, FullTraversalSample montre comment récupérer Valeur entière personnalisée unique à partir d'un objet Configuration:

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

Pour récupérer et analyser un paramètre contenant plusieurs valeurs, utilisez l'une des méthodes les analyseurs de type de la classe Configuration pour analyser les données en fragments distincts. L'extrait de code suivant, issu du connecteur du tutoriel, utilise la classe getMultiValue pour obtenir la liste des noms de dépôts GitHub:

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

Effectuer un balayage complet

Remplacement getAllDocs() pour effectuer un balayage complet et indexer votre dépôt. getAllDocs() accepte un point de contrôle. Le point de contrôle permet de reprendre l'indexation un élément spécifique si le processus est interrompu. Pour chaque élément de votre , procédez comme suit dans la méthode getAllDocs():

  1. Définissez les autorisations.
  2. Définissez les métadonnées de l'élément que vous indexez.
  3. Combiner les métadonnées et l'élément en un seul élément indexable RepositoryDoc
  4. Empaqueter chaque élément indexable dans un itérateur renvoyé par getAllDocs() . Notez que getAllDocs() renvoie en fait une CheckpointCloseableIterable qui est une itération de ApiOperation chaque objet représentant une requête API effectuée sur un RepositoryDoc, comme l'indexation.

Si l'ensemble d'éléments est trop volumineux pour être traité en un seul appel, ajoutez un et définir hasMore(true) pour indiquer que davantage d'éléments sont disponibles pour l'indexation.

Définir les autorisations pour un élément

Votre dépôt utilise une liste de contrôle d'accès (LCA) pour identifier les utilisateurs ou les groupes ayant accès à un élément. Une LCA est une liste d'ID pour des groupes ou des utilisateurs qui peut accéder à l'élément.

Vous devez dupliquer la LCA utilisée par votre dépôt pour vous assurer que seuls ces utilisateurs ayant accès à un élément peut le voir dans les résultats de recherche. La La LCA d'un élément doit être incluse lors de son indexation, afin que Google Cloud Search dispose des informations nécessaires pour fournir le niveau d'accès approprié à l'article.

Le SDK Content Connector fournit de nombreuses classes et méthodes de LCA de modéliser les LCA de la plupart des dépôts. Vous devez analyser la LCA de chaque élément dans dans votre dépôt et créez une LCA correspondante pour Google Cloud Search lorsque vous pour indexer un élément. Si la LCA de votre dépôt utilise des concepts tels que les LCA l'héritage et la modélisation d'une LCA peut être délicate. Pour en savoir plus sur Google pour les LCA de Cloud Search, reportez-vous LCA de Google Cloud Search :

Remarque:L'API Cloud Search Indexing accepte les LCA à domaine unique. Il ne fait pas sont compatibles avec les LCA interdomaines. Utilisez le Acl.Builder pour définir l'accès à chaque élément à l'aide d'une LCA. L'extrait de code suivant, pris de l'exemple de balayage complet, permet tous les utilisateurs ou "comptes principaux" (getCustomerPrincipal()) être des "lecteurs" de tous les éléments (.setReaders()) lorsque vous effectuez une recherche.

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

Vous devez maîtriser les LCA afin de les modéliser correctement pour le dépôt. Pour Par exemple, vous pouvez indexer des fichiers dans un système de fichiers qui utilise un modèle d'héritage selon lequel les dossiers enfants héritent des autorisations à partir des dossiers parents. La modélisation de l'héritage des LCA nécessite des informations supplémentaires abordés dans LCA de Google Cloud Search

Définir les métadonnées d'un élément

Les métadonnées sont stockées dans un objet Item. Pour créer un Item, vous avez besoin d'un au minimum un identifiant de chaîne unique, un type d'élément, une LCA, une URL et une version uniques pour l'élément. L'extrait de code suivant montre comment créer un Item à l'aide de la méthode IndexingItemBuilder classe d'assistance.

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();

Créer l'élément indexable

Après avoir défini les métadonnées de l'élément, vous pouvez créer l'élément indexable à l'aide de la méthode RepositoryDoc.Builder . L'exemple suivant montre comment créer un seul élément indexable.

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();

Un RepositoryDoc est un type de ApiOperation qui effectue les actions IndexingService.indexItem().

Vous pouvez également utiliser Méthode setRequestMode() du RepositoryDoc.Builder pour identifier la requête d'indexation en tant que ASYNCHRONOUS ou SYNCHRONOUS:

ASYNCHRONOUS
Le mode asynchrone augmente la latence entre l'indexation et la diffusion permet un débit élevé pour les requêtes d'indexation. Le mode asynchrone est recommandé pour l'indexation initiale (le remplissage) de l'ensemble du dépôt.
SYNCHRONOUS
Le mode synchrone réduit la latence entre l'indexation et la diffusion permet un quota de débit limité. Le mode synchrone recommandé pour l'indexation des mises à jour et des modifications du dépôt. Si non spécifié, le mode de requête est défini par défaut sur SYNCHRONOUS.

Empaqueter chaque élément indexable dans un itérateur

getAllDocs() renvoie un Iterator, plus précisément CheckpointCloseableIterable de RepositoryDoc d'objets. Vous pouvez utiliser CheckpointClosableIterableImpl.Builder pour construire et renvoyer un itérateur. L'extrait de code suivant montre comment pour construire et renvoyer un itérateur.

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

Le SDK exécute chaque appel d'indexation inclus dans l'itérateur.

Étapes suivantes

Voici quelques étapes que vous pouvez également suivre :

Créer un connecteur de balayage de liste à partir d'un modèle de classe

La file d'attente d'indexation Cloud Search permet de conserver les ID et le hachage facultatif pour chaque élément du dépôt. Un connecteur de balayage de liste transfère dans la file d'attente d'indexation Google Cloud Search, puis les récupère un à un le temps d'indexation. Google Cloud Search gère les files d'attente et comparer le contenu d'une file d'attente pour déterminer l'état d'un article, par exemple si un article a ont été supprimés du dépôt. Pour en savoir plus sur l'API file d'attente d'indexation, reportez-vous à File d'attente d'indexation Cloud Search

Cette section fait référence aux extraits de code ListTraversalSample à titre d'exemple.

Implémenter le point d'entrée du connecteur

Le point d'entrée d'un connecteur est main(). La tâche principale de cette méthode est de créer une instance de Application et à appeler sa classe start() pour exécuter le connecteur.

Avant d'appeler application.start() utilisez la IndexingApplication.Builder pour instancier ListingConnector modèle. Le ListingConnector accepte une Repository dont vous allez implémenter les méthodes. L'extrait de code suivant montre comment instanciez ListingConnector et son Repository associé:

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();
}

En arrière-plan, le SDK appelle initConfig() après les appels de méthode main() du connecteur Application.build La méthode initConfig():

  1. Appelle la méthode Configuation.isInitialized() pour vous assurer que Configuration n'a pas été initialisé.
  2. Elle initialise un objet Configuration avec la clé-valeur fournie par Google. paires. Chaque paire clé-valeur est stockée ConfigValue dans l'objet Configuration.

Implémenter l'interface Repository

L'objet Repository sert uniquement à effectuer le balayage ou l'indexation des éléments du dépôt. Lorsque vous utilisez un modèle, il vous suffit de remplacer certaines méthodes de l'interface Repository pour créer un connecteur de contenu. Les méthodes à remplacer dépendent du modèle et de la stratégie de balayage que vous utilisez. Pour le ListingConnector remplacer les méthodes suivantes:

  • La init() . Pour configurer et initialiser un référentiel de données, remplacez init().

  • getIds() . Pour récupérer les ID et les valeurs de hachage de tous les enregistrements du dépôt, remplacez la méthode getIds().

  • getDoc() . Pour ajouter, mettre à jour, modifier ou supprimer des éléments dans l'index, remplacez getDoc().

  • (Facultatif) La propriété getChanges() . Si votre dépôt prend en charge la détection des modifications, remplacez getChanges(). Cette méthode est appelée une fois pour chaque incrémentation planifiée (tel que défini par votre configuration) pour récupérer les éléments modifiés les indexer.

  • (Facultatif) La propriété close() . Si vous devez nettoyer le dépôt, remplacez close() . Cette méthode est appelée une fois lors de l'arrêt du connecteur.

Chacune des méthodes de l'objet Repository renvoie un type de ApiOperation . Un objet ApiOperation effectue une action sous la forme d'un seul élément, ou peut-être plusieurs, IndexingService.indexItem() pour effectuer l'indexation effective de votre dépôt.

Obtenir les paramètres de configuration personnalisés

Dans le cadre de la configuration de votre connecteur, vous devez obtenir des paramètres personnalisés Configuration . Cette tâche est généralement effectuée dans un Repository du cours init().

La classe Configuration comporte plusieurs méthodes pour obtenir différents types de données. à partir d'une configuration. Chaque méthode renvoie un objet ConfigValue. Ensuite, utilisez l'objet ConfigValue get() pour récupérer la valeur réelle. L'extrait de code suivant, FullTraversalSample montre comment récupérer Valeur entière personnalisée unique à partir d'un objet Configuration:

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

Pour récupérer et analyser un paramètre contenant plusieurs valeurs, utilisez l'une des méthodes les analyseurs de type de la classe Configuration pour analyser les données en fragments distincts. L'extrait de code suivant, issu du connecteur du tutoriel, utilise la classe getMultiValue pour obtenir la liste des noms de dépôts GitHub:

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

Effectuer un balayage de liste

Remplacement getIds() pour récupérer les ID et les valeurs de hachage de tous les enregistrements du dépôt. La méthode getIds() accepte un point de contrôle. Le point de contrôle est utilisé pour reprendre pour un élément spécifique au cas où le processus serait interrompu.

Ensuite, remplacez les getDoc() pour gérer chaque élément de la file d'attente d'indexation Cloud Search.

Transmettre les ID et les valeurs de hachage des éléments

Remplacement getIds() pour récupérer les ID des articles et les valeurs de hachage de contenu associées un dépôt de clés. Les paires ID/valeur de hachage sont ensuite empaquetées dans une opération push. à la file d'attente d'indexation Cloud Search. Les ID racine ou parent sont généralement puis envoyé en premier, suivi des ID des éléments enfants, jusqu'à ce que toute la hiérarchie des éléments traités.

La méthode getIds() accepte un point de contrôle représentant le dernier élément à être peut être indexée. Le point de contrôle peut être utilisé pour reprendre l'indexation à un élément spécifique le processus être interrompu. Pour chaque élément de votre dépôt, effectuez ces étapes dans la méthode getIds():

  • Récupérez l'ID de chaque élément et la valeur de hachage associée à partir du dépôt.
  • Empaquetez chaque paire ID/valeur de hachage dans un PushItems.
  • Combinez chaque PushItems dans un itérateur renvoyé par la getIds() . Notez que getIds() renvoie en fait une CheckpointCloseableIterable qui est une itération de ApiOperation chaque objet représentant une requête API effectuée sur un RepositoryDoc , par exemple pour placer les éléments dans la file d'attente.

L'extrait de code suivant montre comment récupérer l'ID et la valeur de hachage de chaque élément. et insérez-les PushItems Un PushItems est une requête ApiOperation visant à transmettre un élément à Cloud Search. File d'attente d'indexation.

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);
}

L'extrait de code suivant montre comment utiliser la classe PushItems.Builder pour empaqueter les ID et les valeurs de hachage en une seule opération ApiOperation

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

Les éléments sont placés dans la file d'attente d'indexation Cloud Search en vue d'un traitement plus poussé.

Récupérer et traiter chaque élément

Remplacement getDoc() pour traiter chaque élément de la file d'attente d'indexation Cloud Search. Un élément peut être nouveau, modifié ou inchangé, ou n'exister plus dans la source. un dépôt de clés. Récupérez et indexez chaque élément nouveau ou modifié. Supprimer des éléments de l'index qui n'existent plus dans le dépôt source.

La méthode getDoc() accepte un élément de Google Cloud Search File d'attente d'indexation. Pour chaque élément de la file d'attente, effectuez les étapes suivantes dans Méthode getDoc():

  1. Vérifier si l'élément figure dans la file d'attente d'indexation Cloud Search dans le dépôt. Si ce n'est pas le cas, supprimez l'élément de l'index.

  2. Interrogez l'index pour connaître l'état de l'élément. Si un élément n'a pas été modifié (ACCEPTED), ne le faites pas faire quoi que ce soit.

  3. Éléments modifiés ou nouveaux éléments:

    1. Définissez les autorisations.
    2. Définissez les métadonnées de l'élément que vous indexez.
    3. Combiner les métadonnées et l'élément en un seul élément indexable RepositoryDoc
    4. Renvoyez RepositoryDoc.

Remarque:Le modèle ListingConnector ne permet pas de renvoyer null sur la méthode getDoc(). Le renvoi d'une null entraîne une NullPointerException..

Gérer les éléments supprimés

L'extrait de code suivant montre comment déterminer si un élément existe dans le et, si ce n'est pas le cas, le supprimer.

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);
}

Notez que documents est une structure de données représentant le dépôt. Si documentID introuvable dans documents, retour APIOperations.deleteItem(resourceName) pour supprimer l'élément de l'index.

Traiter les éléments non modifiés

L'extrait de code suivant montre comment interroger l'état de l'élément dans Cloud Search. dans la file d'attente d'indexation et gérer un élément inchangé.

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();
}

Pour déterminer si l'élément n'a pas été modifié, vérifiez également son état. que d'autres métadonnées susceptibles d'indiquer un changement. Dans cet exemple, les métadonnées le hachage est utilisé pour déterminer si l'élément a été modifié.

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);
}

Définir les autorisations pour un élément

Votre dépôt utilise une liste de contrôle d'accès (LCA) pour identifier les utilisateurs ou les groupes ayant accès à un élément. Une LCA est une liste d'ID pour des groupes ou des utilisateurs qui peut accéder à l'élément.

Vous devez dupliquer la LCA utilisée par votre dépôt pour vous assurer que seuls ces utilisateurs ayant accès à un élément peut le voir dans les résultats de recherche. La La LCA d'un élément doit être incluse lors de son indexation, afin que Google Cloud Search dispose des informations nécessaires pour fournir le niveau d'accès approprié à l'article.

Le SDK Content Connector fournit de nombreuses classes et méthodes de LCA de modéliser les LCA de la plupart des dépôts. Vous devez analyser la LCA de chaque élément dans dans votre dépôt et créez une LCA correspondante pour Google Cloud Search lorsque vous pour indexer un élément. Si la LCA de votre dépôt utilise des concepts tels que les LCA l'héritage et la modélisation d'une LCA peut être délicate. Pour en savoir plus sur Google pour les LCA de Cloud Search, reportez-vous LCA de Google Cloud Search :

Remarque:L'API Cloud Search Indexing accepte les LCA à domaine unique. Il ne fait pas sont compatibles avec les LCA interdomaines. Utilisez le Acl.Builder pour définir l'accès à chaque élément à l'aide d'une LCA. L'extrait de code suivant, pris de l'exemple de balayage complet, permet tous les utilisateurs ou "comptes principaux" (getCustomerPrincipal()) être des "lecteurs" de tous les éléments (.setReaders()) lorsque vous effectuez une recherche.

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

Vous devez maîtriser les LCA afin de les modéliser correctement pour le dépôt. Pour Par exemple, vous pouvez indexer des fichiers dans un système de fichiers qui utilise un modèle d'héritage selon lequel les dossiers enfants héritent des autorisations à partir des dossiers parents. La modélisation de l'héritage des LCA nécessite des informations supplémentaires abordés dans LCA de Google Cloud Search

Définir les métadonnées d'un élément

Les métadonnées sont stockées dans un objet Item. Pour créer un Item, vous avez besoin d'un au minimum un identifiant de chaîne unique, un type d'élément, une LCA, une URL et une version uniques pour l'élément. L'extrait de code suivant montre comment créer un Item à l'aide de la méthode IndexingItemBuilder classe d'assistance.

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();

Créer un élément indexable

Après avoir défini les métadonnées de l'élément, vous pouvez créer l'élément indexable à l'aide de la méthode RepositoryDoc.Builder L'exemple suivant montre comment créer un seul élément indexable.

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();

Un RepositoryDoc est un type ApiOperation qui effectue IndexingService.indexItem() requête.

Vous pouvez également utiliser Méthode setRequestMode() du RepositoryDoc.Builder pour identifier la requête d'indexation en tant que ASYNCHRONOUS ou SYNCHRONOUS:

ASYNCHRONOUS
Le mode asynchrone augmente la latence entre l'indexation et la diffusion permet un débit élevé pour les requêtes d'indexation. Le mode asynchrone est recommandé pour l'indexation initiale (le remplissage) de l'ensemble du dépôt.
SYNCHRONOUS
Le mode synchrone réduit la latence entre l'indexation et la diffusion permet un quota de débit limité. Le mode synchrone recommandé pour l'indexation des mises à jour et des modifications du dépôt. Si non spécifié, le mode de requête est défini par défaut sur SYNCHRONOUS.

Étapes suivantes

Voici quelques étapes que vous pouvez également suivre :

Créer un connecteur de balayage de graphe à partir d'un modèle de classe

La file d'attente d'indexation Cloud Search permet de conserver les ID et les valeurs de hachage facultatives pour chaque élément du dépôt. Le connecteur de balayage de graphe transmet les ID d'élément dans la file d'attente d'indexation de Google Cloud Search et les récupère un par un ou l'indexation. Google Cloud Search gère les files d'attente et compare leur contenu déterminer l'état d'un élément (par exemple, s'il a été supprimé du un dépôt de clés. Pour en savoir plus sur la file d'attente d'indexation Cloud Search, consultez à File d'attente d'indexation de Google Cloud Search

Pendant l'indexation, le contenu des éléments est extrait du référentiel de données et Les ID des éléments enfants sont placés dans la file d'attente. Le connecteur s'exécute de manière récursive. traiter les ID des parents et enfants jusqu'à ce que tous les éléments soient traités.

Cette section fait référence aux extraits de code GraphTraversalSample à titre d'exemple.

Implémenter le point d'entrée du connecteur

Le point d'entrée d'un connecteur est main(). La tâche principale de cette méthode est de créer une instance de Application et à appeler sa classe start() pour exécuter le connecteur.

Avant d'appeler application.start() utilisez la IndexingApplication.Builder pour instancier le modèle ListingConnector. La ListingConnector accepte un Repository dont vous allez implémenter les méthodes.

L'extrait de code suivant montre comment instanciez ListingConnector et son Repository associé:

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();
}

En arrière-plan, le SDK appelle initConfig() après les appels de méthode main() du connecteur Application.build La méthode initConfig():

  1. Appelle la méthode Configuation.isInitialized() pour vous assurer que Configuration n'a pas été initialisé.
  2. Elle initialise un objet Configuration avec la clé-valeur fournie par Google. paires. Chaque paire clé-valeur est stockée ConfigValue dans l'objet Configuration.

Implémenter l'interface Repository

L'unique objectif du L'objet Repository permet d'effectuer le balayage et l'indexation du dépôt éléments. Lorsque vous utilisez un modèle, il vous suffit de remplacer certaines méthodes dans les Repository pour créer un connecteur de contenu. Les méthodes que vous remplacez dépendent du modèle et de la stratégie de balayage. Pour le ListingConnector vous remplacez les méthodes suivantes:

  • La init() . Pour configurer et initialiser un référentiel de données, remplacez init().

  • getIds() . Pour récupérer les ID et les valeurs de hachage de tous les enregistrements du dépôt, remplacez la méthode getIds().

  • getDoc() . Pour ajouter, mettre à jour, modifier ou supprimer des éléments dans l'index, remplacez getDoc().

  • (Facultatif) La propriété getChanges() . Si votre dépôt prend en charge la détection des modifications, remplacez getChanges(). Cette méthode est appelée une fois pour chaque incrémentation planifiée (tel que défini par votre configuration) pour récupérer les éléments modifiés les indexer.

  • (Facultatif) La propriété close() . Si vous devez nettoyer le dépôt, remplacez close() . Cette méthode est appelée une fois lors de l'arrêt du connecteur.

Chacune des méthodes du L'objet Repository renvoie un objet ApiOperation. ApiOperation effectue une action sous la forme d'un ou de plusieurs IndexingService.indexItem() pour effectuer l'indexation effective de votre dépôt.

Obtenir les paramètres de configuration personnalisés

Dans le cadre de la configuration de votre connecteur, vous devez obtenir des paramètres personnalisés Configuration . Cette tâche est généralement effectuée dans un Repository du cours init().

La classe Configuration comporte plusieurs méthodes pour obtenir différents types de données. à partir d'une configuration. Chaque méthode renvoie un objet ConfigValue. Ensuite, utilisez l'objet ConfigValue get() pour récupérer la valeur réelle. L'extrait de code suivant, FullTraversalSample montre comment récupérer Valeur entière personnalisée unique à partir d'un objet Configuration:

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

Pour récupérer et analyser un paramètre contenant plusieurs valeurs, utilisez l'une des méthodes les analyseurs de type de la classe Configuration pour analyser les données en fragments distincts. L'extrait de code suivant, issu du connecteur du tutoriel, utilise la classe getMultiValue pour obtenir la liste des noms de dépôts GitHub:

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

Effectuer un balayage de graphe

Remplacement getIds() pour récupérer les ID et les valeurs de hachage de tous les enregistrements du dépôt. La méthode getIds() accepte un point de contrôle. Le point de contrôle est utilisé pour reprendre pour un élément spécifique au cas où le processus serait interrompu.

Ensuite, remplacez les getDoc() pour traiter chaque élément de la file d'attente d'indexation Cloud Search.

Transmettre les ID et les valeurs de hachage des éléments

Remplacement getIds() pour récupérer les ID des articles et les valeurs de hachage de contenu associées un dépôt de clés. Les paires ID/valeur de hachage sont ensuite empaquetées dans une opération push. à la file d'attente d'indexation Cloud Search. Les ID racine ou parent sont généralement puis envoyé en premier, suivi des ID des éléments enfants, jusqu'à ce que toute la hiérarchie des éléments traités.

La méthode getIds() accepte un point de contrôle représentant le dernier élément à être peut être indexée. Le point de contrôle peut être utilisé pour reprendre l'indexation à un élément spécifique le processus être interrompu. Pour chaque élément de votre dépôt, effectuez ces étapes dans la méthode getIds():

  • Récupérez l'ID de chaque élément et la valeur de hachage associée à partir du dépôt.
  • Empaquetez chaque paire ID/valeur de hachage dans un PushItems.
  • Combinez chaque PushItems dans un itérateur renvoyé par la getIds(). Notez que getIds() renvoie en fait une CheckpointCloseableIterable qui est une itération de ApiOperation chaque objet représentant une requête API effectuée sur un RepositoryDoc , par exemple pour placer les éléments dans la file d'attente.

L'extrait de code suivant montre comment récupérer l'ID et la valeur de hachage de chaque élément. et insérez-les PushItems Un PushItems est un Requête ApiOperation pour placer un élément dans la file d'attente d'indexation Cloud Search.

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

L'extrait de code suivant montre comment utiliser le PushItems.Builder pour empaqueter les ID et les valeurs de hachage en une seule opération ApiOperation

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

Les éléments sont placés dans la file d'attente d'indexation Cloud Search en vue d'un traitement plus poussé.

Récupérer et traiter chaque élément

Remplacement getDoc() pour traiter chaque élément de la file d'attente d'indexation Cloud Search. Un élément peut être nouveau, modifié ou inchangé, ou n'exister plus dans la source. un dépôt de clés. Récupérez et indexez chaque élément nouveau ou modifié. Supprimer des éléments de l'index qui n'existent plus dans le dépôt source.

La méthode getDoc() accepte un élément issu de Cloud Search Indexing File d'attente. Pour chaque élément de la file d'attente, effectuez les étapes suivantes dans Méthode getDoc():

  1. Vérifiez si l'élément figure dans la file d'attente d'indexation Cloud Search un dépôt de clés. Si ce n'est pas le cas, supprimez l'élément de l'index. Si l'élément existe, passez à l'étape suivante.

  2. Éléments modifiés ou nouveaux éléments:

    1. Définissez les autorisations.
    2. Définissez les métadonnées de l'élément que vous indexez.
    3. Combiner les métadonnées et l'élément en un seul élément indexable RepositoryDoc
    4. Placez les ID des éléments enfants dans la file d'attente d'indexation Cloud Search pour un traitement ultérieur.
    5. Renvoyez RepositoryDoc.

Gérer les éléments supprimés

L'extrait de code suivant montre comment déterminer si un élément figure dans l'index. et non les supprimer.

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);

Définir les autorisations pour un élément

Votre dépôt utilise une liste de contrôle d'accès (LCA) pour identifier les utilisateurs ou les groupes ayant accès à un élément. Une LCA est une liste d'ID pour des groupes ou des utilisateurs qui peut accéder à l'élément.

Vous devez dupliquer la LCA utilisée par votre dépôt pour vous assurer que seuls ces utilisateurs ayant accès à un élément peut le voir dans les résultats de recherche. La La LCA d'un élément doit être incluse lors de son indexation, afin que Google Cloud Search dispose des informations nécessaires pour fournir le niveau d'accès approprié à l'article.

Le SDK Content Connector fournit de nombreuses classes et méthodes de LCA de modéliser les LCA de la plupart des dépôts. Vous devez analyser la LCA de chaque élément dans dans votre dépôt et créez une LCA correspondante pour Google Cloud Search lorsque vous pour indexer un élément. Si la LCA de votre dépôt utilise des concepts tels que les LCA l'héritage et la modélisation d'une LCA peut être délicate. Pour en savoir plus sur Google pour les LCA de Cloud Search, reportez-vous LCA de Google Cloud Search :

Remarque:L'API Cloud Search Indexing accepte les LCA à domaine unique. Il ne fait pas sont compatibles avec les LCA interdomaines. Utilisez le Acl.Builder pour définir l'accès à chaque élément à l'aide d'une LCA. L'extrait de code suivant, pris de l'exemple de balayage complet, permet tous les utilisateurs ou "comptes principaux" (getCustomerPrincipal()) être des "lecteurs" de tous les éléments (.setReaders()) lorsque vous effectuez une recherche.

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

Vous devez maîtriser les LCA afin de les modéliser correctement pour le dépôt. Pour Par exemple, vous pouvez indexer des fichiers dans un système de fichiers qui utilise un modèle d'héritage selon lequel les dossiers enfants héritent des autorisations à partir des dossiers parents. La modélisation de l'héritage des LCA nécessite des informations supplémentaires abordés dans LCA de Google Cloud Search

Définir les métadonnées d'un élément

Les métadonnées sont stockées dans un objet Item. Pour créer un Item, vous avez besoin d'un au minimum un identifiant de chaîne unique, un type d'élément, une LCA, une URL et une version uniques pour l'élément. L'extrait de code suivant montre comment créer un Item à l'aide de la méthode IndexingItemBuilder classe d'assistance.

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();

Créer l'élément indexable

Après avoir défini les métadonnées de l'élément, vous pouvez créer l'élément indexable à l'aide de la méthode RepositoryDoc.Builder L'exemple suivant montre comment créer un seul élément indexable.

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);

Un RepositoryDoc est un type de ApiOperation qui effectue les actions IndexingService.indexItem().

Vous pouvez également utiliser Méthode setRequestMode() du RepositoryDoc.Builder pour identifier la requête d'indexation en tant que ASYNCHRONOUS ou SYNCHRONOUS:

ASYNCHRONOUS
Le mode asynchrone augmente la latence entre l'indexation et la diffusion permet un débit élevé pour les requêtes d'indexation. Le mode asynchrone est recommandé pour l'indexation initiale (le remplissage) de l'ensemble du dépôt.
SYNCHRONOUS
Le mode synchrone réduit la latence entre l'indexation et la diffusion permet un quota de débit limité. Le mode synchrone recommandé pour l'indexation des mises à jour et des modifications du dépôt. Si non spécifié, le mode de requête est défini par défaut sur SYNCHRONOUS.

Placer les ID des éléments enfants dans la file d'attente d'indexation Cloud Search

L'extrait de code suivant montre comment inclure les ID enfants pour le qui traite actuellement l'élément parent, dans la file d'attente pour traitement. Ces identifiants sont traités après l'indexation de l'élément parent.

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();

Étapes suivantes

Voici quelques étapes que vous pouvez également suivre :

Créer un connecteur de contenu à l'aide de l'API REST

Les sections suivantes expliquent comment créer un connecteur de contenu à l'aide de la API REST.

Déterminer votre stratégie de balayage

La fonction principale d'un connecteur de contenu est de balayer un référentiel pour indexer ses données. Vous devez implémenter une stratégie de balayage adaptée à la taille et la mise en page des données dans votre référentiel. Voici trois types de balayage stratégies:

Stratégie de balayage complet

Une stratégie de balayage complet consiste à analyser l'intégralité du dépôt et à l'indexer aveuglément. chaque élément. Cette stratégie est couramment utilisée lorsque vous avez un petit dépôt et un balayage complet à chaque indexation.

Cette stratégie de balayage convient aux petits dépôts des données statiques et non hiérarchisées. Vous pouvez également utiliser cette stratégie de balayage lorsque la détection des modifications est difficile ou n'est pas prise en charge par le dépôt.

Stratégie de balayage de liste

La stratégie de balayage de liste analyse l'ensemble du dépôt, y compris les fichiers enfants qui détermine l'état de chaque élément. Ensuite, le connecteur prend une seconde transmet et n'indexe que les éléments nouveaux ou mis à jour depuis la dernière ou l'indexation. Cette stratégie est généralement utilisée pour effectuer les mises à jour d'un index existant (au lieu d'avoir à effectuer un balayage complet lors de la mise à jour de l'index).

Cette stratégie de balayage est adaptée lorsque la détection des modifications est difficile ou non pris en charge par le référentiel, vous avez des données non hiérarchisées, travailler avec de très grands jeux de données.

Traversée de graphe

Une stratégie de balayage de graphe analyse l'intégralité du nœud parent l'état de chaque élément. Il effectue ensuite une seconde passe et n'indexe éléments du nœud racine sont nouveaux ou ont été mis à jour depuis la dernière indexation. Enfin, le connecteur transmet les ID enfants, puis indexe les éléments de ces nœuds qui sont nouveaux ou ont été mis à jour. Le connecteur se poursuit alors de manière récursive via tous les nœuds enfants jusqu'à ce que tous les éléments aient été traités. Ce type de balayage utilisé pour les référentiels hiérarchiques où la liste de tous les ID n'est pas pratiques.

Cette stratégie convient si vous avez des données hiérarchisées qui doivent être comme une série de répertoires ou de pages Web.

Implémenter votre stratégie de balayage et vos éléments d'index

Chaque élément indexable pour Cloud Search est appelé élément dans l'API Cloud Search. Un élément peut être un fichier, un dossier, une ligne d'un fichier CSV ou un enregistrement de base de données.

Une fois le schéma enregistré, vous pouvez renseigner l'index en:

  1. (Facultatif) Avec items.upload pour importer des fichiers de plus de 100 Kio à indexer. Pour les fichiers plus petits, intégrez le contenu inlineContent avec items.index

  2. (Facultatif) Avec media.upload pour importer des fichiers multimédias à indexer.

  3. Utilisation de items.index pour indexer l'élément Par exemple, si votre schéma utilise la définition d'objet dans le fichier movie schema, une requête d'indexation d'un seul l'élément doit se présenter comme suit:

    {
  "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. (Facultatif) Utiliser items.get des appels pour valider un élément a été indexée.

Pour effectuer un balayage complet, vous devez régulièrement réindexer l'intégralité un dépôt de clés. Pour effectuer un balayage de liste ou de graphe, vous devez implémenter pour gérer les modifications du dépôt.

Gérer les modifications du dépôt

Vous pouvez collecter et indexer régulièrement chaque élément d'un dépôt pour effectuer une pour une indexation complète. Même s'il est efficace de garantir que votre index est à jour, une liste complète l'indexation peut s'avérer coûteuse lorsqu'il s'agit de référentiels plus importants ou hiérarchisés.

Au lieu d'utiliser de temps en temps des appels d'index pour indexer un dépôt entier, peuvent également utiliser la file d'attente d'indexation Google Cloud pour suivre les modifications et indexer uniquement les éléments modifié. Vous pouvez utiliser items.push Requêtes d'ajout d'éléments dans la file d'attente en vue d'une interrogation et d'une mise à jour ultérieures. Pour plus de la file d'attente d'indexation Google Cloud, reportez-vous File d'attente d'indexation Google Cloud

Pour en savoir plus sur l'API Google Cloud Search, consultez API Cloud Search :