Crea un conector de contenido

Un conector de contenido es un programa de software usado para desviar los datos en un repositorio de una empresa y propagar una fuente de datos. Google brinda las siguientes opciones para desarrollar conectores de contenido:

  • El SDK de Content Connector Esta es una buena opción si estás programando en Java. El SDK de Content Connector es un wrapper alrededor de la API de REST que te permite crear conectores rápidamente. Para crear un conector de contenido mediante el uso del SDK, consulta Crea un conector de contenido con el SDK de Content Connector.

  • Una API de REST de bajo nivel o bibliotecas de la API. Usa estas opciones si no programas en Java, o si tu base de código se adapta mejor a una API de REST o a una biblioteca. Para crear un conector de contenido con la API de REST, consulta Crea un conector de contenido con la API de REST.

Un conector de contenido típico realiza las siguientes tareas:

  1. Lee y procesa parámetros de configuración.
  2. Extrae fragmentos discretos de datos indexables, llamados "elementos", del repositorio de contenido de terceros.
  3. Combina LCA, metadatos y datos de contenido en elementos indexables.
  4. Indexa elementos a la fuente de datos de Cloud Search.
  5. (opcional) Presta atención a las notificaciones de cambios del repositorio de contenido de terceros. Las notificaciones de cambios se convierten en solicitudes de indexación para mantener la fuente de datos de Cloud Search en sincronización con el repositorio de terceros. El conector solo realiza esta tarea si el repositorio es compatible con la detección de cambios.

Crea un conector de contenido con el SDK de Content Connector

En las siguientes secciones, se explica cómo crear un conector de contenido con el SDK de Content Connector.

Configura dependencias

Debes incluir determinadas dependencias en el archivo de compilación para usar el SDK. Haz clic en la pestaña a continuación para ver las dependencias del entorno de compilación:

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'

Crea tu configuración del conector

Cada conector tiene un archivo de configuración que contiene los parámetros que usa el conector, como el ID de tu repositorio. Los parámetros se definen de la siguiente manera: par clave-valor, como api.sourceId=1234567890abcdef

El SDK de Google Cloud Search contiene varios parámetros de configuración proporcionados por Google que son usados por todos los conectores. Debes declarar los siguientes parámetros proporcionados por Google en tu archivo de configuración:

  • Para un conector de contenido, debes declarar api.sourceId y api.serviceAccountPrivateKeyFile, ya que estos parámetros identifican la ubicación de tu repositorio y la clave privada necesaria para acceder al repositorio.
  • Para un conector de identidad, debes declarar api.identitySourceId como esta identifica la ubicación de tu fuente de identidad externa. Si eres sincronizando usuarios, también debes declarar api.customerId como el ID único para la cuenta de Google Workspace de tu empresa.

A menos que desees anular los valores predeterminados de otros parámetros proporcionados por Google, no necesitas declararlos en el archivo de configuración. Para obtener información adicional sobre los parámetros de configuración proporcionados por Google, como sobre cómo generar determinados IDs y claves, consulta Parámetros de configuración proporcionados por Google.

También puedes definir tus propios parámetros específicos del repositorio para usar en tu archivo de configuración.

Pasa el archivo de configuración al conector

Establece la propiedad del sistema config para pasar el archivo de configuración a tu o del conector. Puedes configurar la propiedad con el argumento -D cuando comiences el conector. Por ejemplo, el siguiente comando inicia el conector por el archivo de configuración MyConfig.properties:

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

Si falta este argumento, el SDK intenta acceder a una configuración predeterminada. llamado connector-config.properties.

Determina tu estrategia de recorrido

La función primaria de un conector de contenido es recorrer un repositorio y luego indexar sus datos. Debes implementar una estrategia de recorrido en función del tamaño y diseño de los datos en tu repositorio. Puedes diseñar tu propia estrategia o elige entre las siguientes estrategias implementadas en el SDK:

Estrategia de recorrido completo

Una estrategia de recorrido completo analiza todo el repositorio e indexa a ciegas cada elemento. Esta estrategia se usa comúnmente cuando tienes un repositorio pequeño y puedes permitirte la sobrecarga de realizar un recorrido completo cada vez que indexas.

Esta estrategia de recorrido es adecuada para repositorios pequeños con datos mayormente estáticos y no jerárquicos. También puedes usar esta estrategia de recorrido cuando la detección de cambios es difícil o no es compatible con el repositorio.

Estrategia de recorrido de lista

Una estrategia de recorrido de lista analiza todo el repositorio, incluidos los nodos secundarios, y determina el estado de cada elemento. Luego, el conector realiza una segunda pasada y solo indexa elementos que son nuevos o que se actualizaron desde la última indexación. Esta estrategia se usa comúnmente para realizar actualizaciones graduales en un índice existente (en lugar de tener que hacer un recorrido completo cada vez que actualizas el índice).

Esta estrategia de recorrido es adecuada cuando la detección de cambios es difícil o no es compatible con el repositorio, cuando tienes datos no jerárquicos y cuando estás trabajando con conjuntos de datos muy grandes.

Recorrido de grafos

Una estrategia de recorrido de grafos analiza todo el nodo principal y determina el estado de cada elemento. Luego, el conector realiza una segunda pasada y solo indexa elementos en el nodo raíz que son nuevos o que se actualizaron desde la última indexación. Por último, el conector pasa cualquier ID secundario e indexa elementos en los nodos secundarios que son nuevos o que se actualizaron. El conector continúa recursivamente a través de todos los nodos secundarios hasta que se hayan abordado todos los elementos. Este recorrido se usa normalmente para los repositorios jerárquicos donde no es práctico hacer una lista de todos los ID.

Esta estrategia es adecuada si tienes datos jerárquicos que deben ser rastreados, como una serie de directorios o páginas web.

Cada una de estas estrategias de recorrido se implementa a través de un conector de plantillas en el SDK. Si bien puedes implementar tu propia estrategia de recorrido, estas aceleran considerablemente el desarrollo de tu conector. Para crear un conector mediante el uso de una plantilla, consulta la sección correspondiente a tu estrategia de recorrido:

Crea un conector de recorrido completo mediante el uso de una clase de plantilla

Esta sección de los documentos hace referencia a los fragmentos de código del ejemplo FullTraversalSample.

Implementa el punto de entrada del conector

El punto de entrada a un conector es el main(). La tarea principal de este método es crear una instancia de la Application e invocar su start() para ejecutar el conector.

Antes de llamar application.start(), usa el IndexingApplication.Builder para crear una instancia de la FullTraversalConnector plantilla. El FullTraversalConnector acepta un Repository objeto cuyos métodos implementarás. En el siguiente fragmento de código, se muestra cómo para implementar el método 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 segundo plano, el SDK llama a initConfig() después de llamar al método main() de tu conector Application.build El Método initConfig() realiza las siguientes tareas:

  1. Llama al Configuation.isInitialized() método para asegurarte de que el Configuration no se inicializó.
  2. Inicializa un objeto Configuration con el par clave-valor proporcionado por Google. pares. Cada par clave-valor se almacena en un ConfigValue dentro del objeto Configuration.

Implementa la interfaz Repository

El único propósito del objeto Repository es realizar el recorrido y de los elementos del repositorio. Al usar una plantilla, solo debes anular ciertos métodos dentro de Repository para crear un conector de contenido. Los métodos que anulas dependen de la plantilla y de la estrategia de recorrido que usas. Para el FullTraversalConnector anula los siguientes métodos:

  • El init() . Para configurar e inicializar cualquier repositorio de datos, anula el parámetro init().

  • El getAllDocs() . Para recorrer e indexar todos los elementos en el repositorio de datos, anula el parámetro getAllDocs(). Se llama a este método una vez por cada recorrido programado (según lo define tu configuración).

  • (Opcional) El getChanges() . Si tu repositorio es compatible con la detección de cambios, anula el getChanges(). Se llama a este método una vez por cada recorrido gradual programado (según lo define tu configuración) para recuperar elementos modificados y luego indexarlos.

  • (Opcional) El close() . Si necesitas realizar una limpieza del repositorio, anula close(). . Se llama a este método una vez durante el cierre del conector.

Cada uno de los métodos del El objeto Repository muestra algún tipo de ApiOperation . Un objeto ApiOperation realiza una acción en forma de un solo objeto, o quizás varios, IndexingService.indexItem() para realizar la indexación real de tu repositorio.

Obtén parámetros de configuración personalizados

Como parte del control de la configuración del conector, deberás obtener cualquier parámetros personalizados del Configuration . Por lo general, esta tarea se realiza Repository de la clase init().

La clase Configuration tiene varios métodos para obtener diferentes tipos de datos. de una configuración. Cada método muestra un objeto ConfigValue. Luego, deberás usa la ConfigValue get() para recuperar el valor real. El siguiente fragmento, de FullTraversalSample, se muestra cómo recuperar un un solo valor de número entero personalizado de un objeto Configuration:

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

Para obtener y analizar un parámetro que contenga varios valores, usa uno de los Analizadores de tipo de la clase Configuration para analizar los datos en fragmentos separados. En el siguiente fragmento del conector del instructivo, se usa el elemento getMultiValue para obtener una lista de nombres de repositorios de GitHub:

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

Realiza un recorrido completo

Anular getAllDocs() para realizar un recorrido completo y, luego, indexar tu repositorio. El getAllDocs() acepta un punto de control. El punto de control se usa para reanudar la indexación en un elemento específico en caso de que se interrumpa el proceso. Para cada elemento de tu repositorio, realiza estos pasos en el método getAllDocs():

  1. Establece permisos.
  2. Establece los metadatos para el elemento que indexas.
  3. Combina los metadatos y el elemento en un solo elemento indexable RepositoryDoc
  4. Empaqueta cada elemento indexable en un iterador que muestra getAllDocs(). . Ten en cuenta que getAllDocs() en realidad muestra un CheckpointCloseableIterable que es una iteración de ApiOperation objetos, cada uno de los cuales representa una solicitud a la API realizada en un RepositoryDoc, como la indexación.

Si el conjunto de elementos es demasiado grande para procesarlo en una sola llamada, incluye un punto de control y establece hasMore(true) para indicar que hay más elementos disponibles para indexar.

Establece los permisos para un elemento

Tu repositorio usa una Lista de control de acceso (LCA) para identificar los usuarios o grupos que tienen acceso a un elemento. Una LCA es una lista de ID para grupos o usuarios que pueden acceder al elemento.

Debes duplicar la LCA que usa tu repositorio para garantizar que solo esos usuarios con acceso a un elemento puede verlo en un resultado de la búsqueda. El Se debe incluir la LCA de un elemento cuando se indexa para que Google Cloud Search tenga la información que necesita para proporcionar el nivel de acceso correcto el elemento.

El SDK de Content Connector proporciona un amplio conjunto de métodos y clases de LCA para modelar las LCA de la mayoría de los repositorios. Debes analizar la LCA para cada elemento en tu repositorio y crear una LCA correspondiente para Google Cloud Search cuando indexes un elemento. Si tu LCA del repositorio emplea conceptos como la herencia de la LCA, modelar esa LCA puede ser complicado. Para obtener más información sobre las LCA de Google Cloud Search, consulta LCA de Google Cloud Search.

Nota: La API de indexación de Cloud Search es compatible con las LCA de un solo dominio. No es compatible con las LCA de dominio cruzado. Usa el Acl.Builder para establecer el acceso a cada elemento con una LCA. El siguiente fragmento de código, tomado de la muestra de recorrido completa, permite todos los usuarios o “principales” (getCustomerPrincipal()) ser “lectores” de todos los artículos (.setReaders()) al realizar una búsqueda.

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

Debes comprender las LCA con el objetivo de modelarlas de forma adecuada para el repositorio. Por ejemplo, podrías estar indexando archivos dentro de un sistema de archivos que usa algún tipo de modelo de herencia por el cual las carpetas secundarias heredan permisos de las carpetas principales. El modelado de la herencia de LCA requiere información adicional incluida en las LCA de Google Cloud Search

Establece los metadatos de un elemento

Los metadatos se almacenan en un objeto Item. Para crear un Item, necesitas un mínimo de un ID de string único, un tipo de elemento, una LCA, una URL y una versión para el elemento. En el siguiente fragmento de código, se muestra cómo compilar un Item con la clase IndexingItemBuilder clase auxiliar.

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

Crea el elemento indexable

Una vez que hayas configurado los metadatos para el elemento, puedes crear la versión indexable real con el RepositoryDoc.Builder . En el siguiente ejemplo, se muestra cómo crear un elemento indexable único.

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 es un tipo de ApiOperation que realiza la acción IndexingService.indexItem().

También puedes usar setRequestMode() de la RepositoryDoc.Builder para identificar la solicitud de indexación como ASYNCHRONOUS o SYNCHRONOUS:

ASYNCHRONOUS
El modo asíncrono da como resultado una latencia de indexación a entrega más prolongada y admite una gran cuota de capacidad de procesamiento para solicitudes de indexación. El modo asíncrono es Se recomienda para la indexación inicial (reabastecimiento) de todo el repositorio.
SYNCHRONOUS
El modo síncrono reduce la latencia de indexación a entrega y se adapta a una cuota de capacidad de procesamiento limitada. Se recomienda el modo síncrono para la indexación de actualizaciones y cambios en el repositorio. Si Si no se especifica, el modo de solicitud predeterminado es SYNCHRONOUS.

Empaqueta cada elemento indexable en un iterador

La getAllDocs() muestra un Iterator, específicamente un CheckpointCloseableIterable: de RepositoryDoc objetos. Puedes usar la CheckpointClosableIterableImpl.Builder para construir y mostrar un iterador. El siguiente fragmento de código muestra cómo construir y mostrar un iterador.

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

El SDK ejecuta cada llamada de indexación incluida dentro del iterador.

Próximos pasos

Aquí hay algunos pasos que puedes seguir:

Crea un conector de recorrido de lista mediante el uso de una clase de plantilla

La cola de indexación de Cloud Search se usa para almacenar ID y valores hash opcionales para cada elemento en el repositorio. Un conector de recorrido de lista envía los ID de elementos a la cola de indexación de Google Cloud Search y los recupera uno por uno para la indexación. Google Cloud Search mantiene colas y compara contenidos de cola para determinar el estado del elemento, por ejemplo, si un elemento se ha borrado del repositorio. Para obtener más información sobre el de Indexación de datos, consulta La cola de indexación de Cloud Search.

Esta sección de los documentos hace referencia a los fragmentos de código del ejemplo ListTraversalSample.

Implementa el punto de entrada del conector

El punto de entrada a un conector es el main(). La tarea principal de este método es crear una instancia de la Application e invocar su start() para ejecutar el conector.

Antes de llamar application.start(), usa el IndexingApplication.Builder para crear una instancia de la ListingConnector plantilla. ListingConnector acepta un Repository objeto cuyos métodos implementarás. En el siguiente fragmento, se muestra cómo Crea una instancia de ListingConnector y su Repository asociado:

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 segundo plano, el SDK llama a initConfig() después de llamar al método main() de tu conector Application.build El método initConfig():

  1. Llama al Configuation.isInitialized() método para asegurarte de que el Configuration no se inicializó.
  2. Inicializa un objeto Configuration con el par clave-valor proporcionado por Google. pares. Cada par clave-valor se almacena en un ConfigValue dentro del objeto Configuration.

Implementa la interfaz Repository

El único propósito del objeto Repository es realizar el recorrido y de los elementos del repositorio. Cuando se usa una plantilla, solo necesitas anular algunos métodos dentro de la interfaz Repository para crear un conector de contenido Los métodos que anules dependerán de la plantilla y de la estrategia de recorrido que uses. Para el ListingConnector, anula los siguientes métodos:

  • El init() . Para configurar e inicializar cualquier repositorio de datos, anula el parámetro init().

  • La getIds() . Para recuperar los ID y los valores hash de todos los registros del repositorio, haz lo siguiente: anula el método getIds().

  • La getDoc() . Para agregar nuevos, actualizar, modificar o borrar elementos del índice, anula el parámetro getDoc().

  • (Opcional) El getChanges() . Si tu repositorio es compatible con la detección de cambios, anula el getChanges(). Se llama a este método una vez por cada recorrido gradual programado (según lo define tu configuración) para recuperar elementos modificados y luego indexarlos.

  • (Opcional) El close() . Si necesitas realizar una limpieza del repositorio, anula close(). . Se llama a este método una vez durante el cierre del conector.

Cada uno de los métodos del objeto Repository muestra algún tipo de ApiOperation . Un objeto ApiOperation realiza una acción en forma de un solo objeto, o quizás varios, IndexingService.indexItem() para realizar la indexación real de tu repositorio.

Obtén parámetros de configuración personalizados

Como parte del control de la configuración del conector, deberás obtener cualquier parámetros personalizados del Configuration . Por lo general, esta tarea se realiza Repository de la clase init().

La clase Configuration tiene varios métodos para obtener diferentes tipos de datos. de una configuración. Cada método muestra un objeto ConfigValue. Luego, deberás usa la ConfigValue get() para recuperar el valor real. El siguiente fragmento, de FullTraversalSample, se muestra cómo recuperar un un solo valor de número entero personalizado de un objeto Configuration:

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

Para obtener y analizar un parámetro que contenga varios valores, usa uno de los Analizadores de tipo de la clase Configuration para analizar los datos en fragmentos separados. En el siguiente fragmento del conector del instructivo, se usa el elemento getMultiValue para obtener una lista de nombres de repositorios de GitHub:

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

Realiza el recorrido de lista

Anular getIds() para recuperar los IDs y los valores hash de todos los registros del repositorio. El método getIds() acepta un punto de control. El punto de control se usa para reanudar la indexación en un elemento específico en caso de que se interrumpa el proceso.

Luego, anula el getDoc() para controlar cada elemento de la cola de indexación de Cloud Search.

Envía ID de elementos y valores hash

Anular getIds() para recuperar los IDs de artículo y los valores hash de su contenido asociado de las en un repositorio de confianza. Los ID y pares de valor hash luego se empaquetan en una solicitud de operación push a la cola de indexación de Cloud Search. Por lo general, los ID principales o de raíz se envían primero, seguidos por los ID secundarios hasta que se haya procesado toda la jerarquía de elementos.

El método getIds() acepta un punto de control que representa el último elemento que se va a de forma manual. El punto de control se puede usar para reanudar la indexación en un elemento específico en caso de que se interrumpa el proceso. Para cada elemento de tu repositorio, realiza estas Pasos en el método getIds():

  • Obtén cada ID de elemento y el valor hash asociado del repositorio.
  • Empaqueta cada ID y par de valor hash en un PushItems.
  • Combina cada PushItems en un iterador que muestra el getIds() . Ten en cuenta que getIds() en realidad muestra un CheckpointCloseableIterable que es una iteración de ApiOperation objetos, cada uno de los cuales representa una solicitud a la API realizada en un RepositoryDoc como el envío de elementos a la cola.

El siguiente fragmento de código muestra cómo obtener cada ID de artículo y valor hash y insertarlos en un PushItems Un PushItems es una solicitud ApiOperation para enviar un elemento a Cloud Search. de la cola de indexación.

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

En el siguiente fragmento de código, se muestra cómo usar la PushItems.Builder para empaquetar los IDs y los valores hash en un solo envío ApiOperation

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

Los elementos se envían a la cola de indexación de Cloud Search para su posterior procesamiento.

Recupera y controla cada elemento

Anular getDoc() para controlar cada elemento de la cola de indexación de Cloud Search Un elemento puede ser nuevo, modificado o sin cambios, o puede no existir más en el repositorio de código fuente. Recupera e indexa cada elemento que sea nuevo o modificado. Quita los elementos del índice que ya no existen en el repositorio de código fuente.

El método getDoc() acepta un elemento de Google Cloud Search. de la cola de indexación. Para cada elemento en la cola, sigue estos pasos en la Método getDoc():

  1. Comprueba si el ID del elemento, dentro de la cola de indexación de Cloud Search, existe en el repositorio. Si no existe, borra el elemento del índice.

  2. Consulta el índice para el estado del elemento y, si un elemento no ha sido modificado (ACCEPTED), no hagas nada.

  3. Índice modificado o elementos nuevos:

    1. Configura los permisos.
    2. Establece los metadatos para el elemento que indexas.
    3. Combina los metadatos y el elemento en un solo elemento indexable RepositoryDoc
    4. Muestra el RepositoryDoc.

Nota: La plantilla ListingConnector no admite que se muestre null en el método getDoc() Cuando se muestra null, se genera una NullPointerException.

Controla los elementos borrados

El siguiente fragmento de código muestra cómo determinar si un elemento existe en el repositorio y, si no, cómo borrarlo.

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

Ten en cuenta que documents es una estructura de datos que representa el repositorio. Si documentID no se encuentra en documents, devolver APIOperations.deleteItem(resourceName) para borrar el elemento del índice.

Controla elementos no modificados

El siguiente fragmento de código muestra cómo consultar el estado del elemento en la cola de indexación de Cloud Search y controlar un elemento no modificado.

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

Para determinar si un elemento no está modificado, verifica el estado del elemento, así como otros metadatos que pueden indicar un cambio. En el ejemplo, el hash de los metadatos se usa para determinar si el elemento se ha modificado.

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

Configura los permisos para un elemento

Tu repositorio usa una Lista de control de acceso (LCA) para identificar los usuarios o grupos que tienen acceso a un elemento. Una LCA es una lista de ID para grupos o usuarios que pueden acceder al elemento.

Debes duplicar la LCA que usa tu repositorio para garantizar que solo esos usuarios con acceso a un elemento puede verlo en un resultado de la búsqueda. El Se debe incluir la LCA de un elemento cuando se indexa para que Google Cloud Search tenga la información que necesita para proporcionar el nivel de acceso correcto el elemento.

El SDK de Content Connector proporciona un amplio conjunto de métodos y clases de LCA para modelar las LCA de la mayoría de los repositorios. Debes analizar la LCA para cada elemento en tu repositorio y crear una LCA correspondiente para Google Cloud Search cuando indexes un elemento. Si tu LCA del repositorio emplea conceptos como la herencia de la LCA, modelar esa LCA puede ser complicado. Para obtener más información sobre las LCA de Google Cloud Search, consulta LCA de Google Cloud Search.

Nota: La API de indexación de Cloud Search es compatible con las LCA de un solo dominio. No es compatible con las LCA de dominio cruzado. Usa el Acl.Builder para configurar el acceso a cada elemento con una LCA. El siguiente fragmento de código, tomado de la muestra de recorrido completa, permite todos los usuarios o “principales” (getCustomerPrincipal()) ser “lectores” de todos los artículos (.setReaders()) al realizar una búsqueda.

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

Debes comprender las LCA con el objetivo de modelarlas de forma adecuada para el repositorio. Por ejemplo, podrías estar indexando archivos dentro de un sistema de archivos que usa algún tipo de modelo de herencia por el cual las carpetas secundarias heredan permisos de las carpetas principales. El modelado de la herencia de LCA requiere información adicional incluida en las LCA de Google Cloud Search

Establece los metadatos de un elemento

Los metadatos se almacenan en un objeto Item. Para crear un Item, necesitas un mínimo de un ID de string único, un tipo de elemento, una LCA, una URL y una versión para el elemento. En el siguiente fragmento de código, se muestra cómo compilar un Item con la clase IndexingItemBuilder clase auxiliar.

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

Crea un elemento indexable

Una vez que hayas configurado los metadatos para el elemento, puedes crear la versión indexable real con el RepositoryDoc.Builder En el siguiente ejemplo, se muestra cómo crear un elemento indexable único.

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 objeto RepositoryDoc es un tipo de ApiOperation que realiza la acción IndexingService.indexItem() para cada solicitud.

También puedes usar setRequestMode() de la RepositoryDoc.Builder para identificar la solicitud de indexación como ASYNCHRONOUS o SYNCHRONOUS:

ASYNCHRONOUS
El modo asíncrono da como resultado una latencia de indexación a entrega más prolongada y admite una gran cuota de capacidad de procesamiento para solicitudes de indexación. El modo asíncrono es Se recomienda para la indexación inicial (reabastecimiento) de todo el repositorio.
SYNCHRONOUS
El modo síncrono reduce la latencia de indexación a entrega y se adapta a una cuota de capacidad de procesamiento limitada. Se recomienda el modo síncrono para la indexación de actualizaciones y cambios en el repositorio. Si Si no se especifica, el modo de solicitud predeterminado es SYNCHRONOUS.

Próximos pasos

Aquí hay algunos pasos que puedes seguir:

Crea un conector de recorrido de grafo mediante el uso de una clase de plantilla

La cola de indexación de Cloud Search se usa para almacenar ID y valores hash opcionales para cada elemento en el repositorio. Un conector de recorrido de grafo envía los IDs de elemento a la cola de indexación de Google Cloud Search y los recupera, uno a la vez, para la indexación de datos. Google Cloud Search mantiene colas y compara contenidos de cola para determinar el estado del elemento, por ejemplo, si un elemento se ha borrado del repositorio. Para obtener más información sobre la cola de indexación de Cloud Search, consulta a La cola de indexación de Google Cloud Search.

Durante el índice, el contenido del elemento se recupera del repositorio de datos y cualquier ID del elemento secundario se envía a la cola. El conector continúa procesando recursivamente los ID principales y secundarios hasta que se controlan todos los elementos.

Esta sección de los documentos hace referencia a los fragmentos de código del ejemplo GraphTraversalSample.

Implementa el punto de entrada del conector

El punto de entrada a un conector es el main(). La tarea principal de este método es crear una instancia de la Application e invocar su start() para ejecutar el conector.

Antes de llamar application.start(), usa el IndexingApplication.Builder para crear una instancia de la plantilla ListingConnector. El ListingConnector acepta un Repository objeto cuyos métodos implementarás.

En el siguiente fragmento, se muestra cómo Crea una instancia de ListingConnector y su Repository asociado:

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 segundo plano, el SDK llama a initConfig() después de llamar al método main() de tu conector Application.build El método initConfig():

  1. Llama al Configuation.isInitialized() método para asegurarte de que el Configuration no se inicializó.
  2. Inicializa un objeto Configuration con el par clave-valor proporcionado por Google. pares. Cada par clave-valor se almacena en un ConfigValue dentro del objeto Configuration.

Implementa la interfaz Repository

El único propósito de la El objeto Repository realiza el recorrido y la indexación del repositorio. elementos. Cuando usas una plantilla, solo debes anular ciertos métodos dentro del Repository para crear un conector de contenido. Los métodos que anulas dependen de la plantilla y de la estrategia de recorrido que usas. Para el ListingConnector, anula los siguientes métodos:

  • El init() . Para configurar e inicializar cualquier repositorio de datos, anula el parámetro init().

  • La getIds() . Para recuperar los ID y los valores hash de todos los registros del repositorio, haz lo siguiente: anula el método getIds().

  • La getDoc() . Para agregar nuevos, actualizar, modificar o borrar elementos del índice, anula el parámetro getDoc().

  • (Opcional) El getChanges() . Si tu repositorio es compatible con la detección de cambios, anula el getChanges(). Se llama a este método una vez por cada recorrido gradual programado (según lo define tu configuración) para recuperar elementos modificados y luego indexarlos.

  • (Opcional) El close() . Si necesitas realizar una limpieza del repositorio, anula close(). . Se llama a este método una vez durante el cierre del conector.

Cada uno de los métodos del El objeto Repository muestra algún tipo de objeto ApiOperation. Un ApiOperation que un objeto realiza una acción en forma de una IndexingService.indexItem() para realizar la indexación real de tu repositorio.

Obtén parámetros de configuración personalizados

Como parte del control de la configuración del conector, deberás obtener cualquier parámetros personalizados del Configuration . Por lo general, esta tarea se realiza Repository de la clase init().

La clase Configuration tiene varios métodos para obtener diferentes tipos de datos. de una configuración. Cada método muestra un objeto ConfigValue. Luego, deberás usa la ConfigValue get() para recuperar el valor real. El siguiente fragmento, de FullTraversalSample, se muestra cómo recuperar un un solo valor de número entero personalizado de un objeto Configuration:

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

Para obtener y analizar un parámetro que contenga varios valores, usa uno de los Analizadores de tipo de la clase Configuration para analizar los datos en fragmentos separados. En el siguiente fragmento del conector del instructivo, se usa el elemento getMultiValue para obtener una lista de nombres de repositorios de GitHub:

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

Realiza el recorrido de grafo

Anular getIds() para recuperar los IDs y los valores hash de todos los registros del repositorio. El método getIds() acepta un punto de control. El punto de control se usa para reanudar la indexación en un elemento específico en caso de que se interrumpa el proceso.

Luego, anula el getDoc() para controlar cada elemento de la cola de indexación de Cloud Search.

Envía ID de elementos y valores hash

Anular getIds() para recuperar los IDs de artículo y los valores hash de su contenido asociado de las en un repositorio de confianza. Los ID y pares de valor hash luego se empaquetan en una solicitud de operación push a la cola de indexación de Cloud Search. Por lo general, los ID principales o de raíz se envían primero, seguidos por los ID secundarios hasta que se haya procesado toda la jerarquía de elementos.

El método getIds() acepta un punto de control que representa el último elemento que se va a de forma manual. El punto de control se puede usar para reanudar la indexación en un elemento específico en caso de que se interrumpa el proceso. Para cada elemento de tu repositorio, realiza estas Pasos en el método getIds():

  • Obtén cada ID de elemento y el valor hash asociado del repositorio.
  • Empaqueta cada ID y par de valor hash en un PushItems.
  • Combina cada PushItems en un iterador que muestra el getIds(). Ten en cuenta que getIds() en realidad muestra un CheckpointCloseableIterable que es una iteración de ApiOperation objetos, cada uno de los cuales representa una solicitud a la API realizada en un RepositoryDoc como el envío de elementos a la cola.

El siguiente fragmento de código muestra cómo obtener cada ID de artículo y valor hash y insertarlos en un PushItems Un PushItems es un Solicitud ApiOperation para enviar un elemento a la cola de indexación de Cloud Search.

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

En el siguiente fragmento de código, se muestra cómo usar la PushItems.Builder para empaquetar los IDs y los valores hash en un solo envío ApiOperation

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

Los elementos se envían a la cola de indexación de Cloud Search para su posterior procesamiento.

Recupera y controla cada elemento

Anular getDoc() para controlar cada elemento de la cola de indexación de Cloud Search Un elemento puede ser nuevo, modificado o sin cambios, o puede no existir más en el repositorio de código fuente. Recupera e indexa cada elemento que sea nuevo o modificado. Quita los elementos del índice que ya no existen en el repositorio de código fuente.

El método getDoc() acepta un elemento de la indexación de Cloud Search. Fila. Para cada elemento en la cola, sigue estos pasos en la Método getDoc():

  1. Comprueba si el ID del elemento, dentro de la cola de indexación de Cloud Search, existe en el repositorio. Si no, borra el elemento del índice. Si el elemento existe, sigue con el próximo paso.

  2. Índice modificado o elementos nuevos:

    1. Configura los permisos.
    2. Establece los metadatos para el elemento que indexas.
    3. Combina los metadatos y el elemento en un solo elemento indexable RepositoryDoc
    4. Coloca los ID secundarios en la cola de indexación de Cloud Search para su posterior procesamiento.
    5. Muestra el RepositoryDoc.

Controla los elementos borrados

El siguiente fragmento de código muestra cómo determinar si un elemento existe en el índice y, si no, cómo borrarlo.

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

Configura los permisos para un elemento

Tu repositorio usa una Lista de control de acceso (LCA) para identificar los usuarios o grupos que tienen acceso a un elemento. Una LCA es una lista de ID para grupos o usuarios que pueden acceder al elemento.

Debes duplicar la LCA que usa tu repositorio para garantizar que solo esos usuarios con acceso a un elemento puede verlo en un resultado de la búsqueda. El Se debe incluir la LCA de un elemento cuando se indexa para que Google Cloud Search tenga la información que necesita para proporcionar el nivel de acceso correcto el elemento.

El SDK de Content Connector proporciona un amplio conjunto de métodos y clases de LCA para modelar las LCA de la mayoría de los repositorios. Debes analizar la LCA para cada elemento en tu repositorio y crear una LCA correspondiente para Google Cloud Search cuando indexes un elemento. Si tu LCA del repositorio emplea conceptos como la herencia de la LCA, modelar esa LCA puede ser complicado. Para obtener más información sobre las LCA de Google Cloud Search, consulta LCA de Google Cloud Search.

Nota: La API de indexación de Cloud Search es compatible con las LCA de un solo dominio. No es compatible con las LCA de dominio cruzado. Usa el Acl.Builder para establecer el acceso a cada elemento con una LCA. El siguiente fragmento de código, tomado de la muestra de recorrido completa, permite todos los usuarios o “principales” (getCustomerPrincipal()) ser “lectores” de todos los artículos (.setReaders()) al realizar una búsqueda.

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

Debes comprender las LCA con el objetivo de modelarlas de forma adecuada para el repositorio. Por ejemplo, podrías estar indexando archivos dentro de un sistema de archivos que usa algún tipo de modelo de herencia por el cual las carpetas secundarias heredan permisos de las carpetas principales. El modelado de la herencia de LCA requiere información adicional incluida en las LCA de Google Cloud Search

Establece los metadatos de un elemento

Los metadatos se almacenan en un objeto Item. Para crear un Item, necesitas un mínimo de un ID de string único, un tipo de elemento, una LCA, una URL y una versión para el elemento. En el siguiente fragmento de código, se muestra cómo compilar un Item con la clase IndexingItemBuilder clase auxiliar.

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

Crea el elemento indexable

Una vez que hayas configurado los metadatos para el elemento, puedes crear la versión indexable real con el RepositoryDoc.Builder En el siguiente ejemplo, se muestra cómo crear un elemento indexable único.

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 es un tipo de ApiOperation que realiza la acción IndexingService.indexItem().

También puedes usar setRequestMode() de la RepositoryDoc.Builder para identificar la solicitud de indexación como ASYNCHRONOUS o SYNCHRONOUS:

ASYNCHRONOUS
El modo asíncrono da como resultado una latencia de indexación a entrega más prolongada y admite una gran cuota de capacidad de procesamiento para solicitudes de indexación. El modo asíncrono es Se recomienda para la indexación inicial (reabastecimiento) de todo el repositorio.
SYNCHRONOUS
El modo síncrono reduce la latencia de indexación a entrega y se adapta a una cuota de capacidad de procesamiento limitada. Se recomienda el modo síncrono para la indexación de actualizaciones y cambios en el repositorio. Si Si no se especifica, el modo de solicitud predeterminado es SYNCHRONOUS.

Coloca los ID secundarios en la cola de indexación de Cloud Search

El siguiente fragmento de código muestra cómo incluir los ID secundarios, para el elemento principal que se procesa actualmente, en la cola para su procesamiento. Estos ID se procesan después de que se indexa el elemento principal.

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

Próximos pasos

Aquí hay algunos pasos que puedes seguir:

Crea un conector de contenido con la API de REST

Las siguientes secciones explican cómo crear un conector de contenido con la API de REST.

Determina tu estrategia de recorrido

La función primaria de un conector de contenido es recorrer un repositorio y luego indexar sus datos. Debes implementar una estrategia de recorrido en función del tamaño y diseño de los datos en tu repositorio. Las siguientes son tres estrategias de recorrido comunes:

Estrategia de recorrido completo

Una estrategia de recorrido completo analiza todo el repositorio e indexa a ciegas cada elemento. Esta estrategia se usa comúnmente cuando tienes un repositorio pequeño y puedes permitirte la sobrecarga de realizar un recorrido completo cada vez que indexas.

Esta estrategia de recorrido es adecuada para repositorios pequeños con datos mayormente estáticos y no jerárquicos. También puedes usar esta estrategia de recorrido cuando la detección de cambios es difícil o no es compatible con el repositorio.

Estrategia de recorrido de lista

Una estrategia de recorrido de lista analiza todo el repositorio, incluidos los nodos secundarios, y determina el estado de cada elemento. Luego, el conector realiza una segunda pasada y solo indexa elementos que son nuevos o que se actualizaron desde la última indexación. Esta estrategia se usa comúnmente para realizar actualizaciones graduales en un índice existente (en lugar de tener que hacer un recorrido completo cada vez que actualizas el índice).

Esta estrategia de recorrido es adecuada cuando la detección de cambios es difícil o no es compatible con el repositorio, cuando tienes datos no jerárquicos y cuando estás trabajando con conjuntos de datos muy grandes.

Recorrido de grafos

Una estrategia de recorrido de grafos analiza todo el nodo principal y determina el estado de cada elemento. Luego, el conector realiza una segunda pasada y solo indexa elementos en el nodo raíz que son nuevos o que se actualizaron desde la última indexación. Por último, el conector pasa cualquier ID secundario e indexa elementos en los nodos secundarios que son nuevos o que se actualizaron. El conector continúa recursivamente a través de todos los nodos secundarios hasta que se hayan abordado todos los elementos. Este recorrido se usa normalmente para los repositorios jerárquicos donde no es práctico hacer una lista de todos los ID.

Esta estrategia es adecuada si tienes datos jerárquicos que deben ser rastreados, como una serie de directorios o páginas web.

Implementa tu estrategia de recorrido y los elementos de índice

Cada elemento indexable para Cloud Search se conoce como un elemento en la API de Cloud Search. Un elemento puede ser un archivo, una carpeta, una línea en un archivo CSV o un registro de base de datos.

Una vez que se registra tu esquema, puedes propagar el índice de las siguientes maneras:

  1. Usa items.upload (opcional) subir archivos de más de 100 KiB para indexarlos. Para archivos más pequeños, inserta el contenido como inlineContent mediante items.index

  2. Usa media.upload (opcional) subir archivos multimedia para indexarlos.

  3. Usa items.index para indexar el elemento. Por ejemplo, si tu esquema usa la definición del objeto en la película esquema, una solicitud de indexación para un solo el elemento se vería así:

    {
  "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. Usa items.get (opcional) llamadas para verificar un elemento se indexó.

Para realizar un recorrido completo, deberías volver a indexar periódicamente el repositorio completo. Para realizar un recorrido de grafo o de lista, debes implementar código para controlar los cambios del repositorio.

Controla cambios de repositorio

Periódicamente, puedes reunir y además indexar cada elemento de un repositorio para realizar una indexación completa. Si bien es efectiva para garantizar que tu índice esté actualizado, una indexación completa puede ser costosa cuando se trata de repositorios jerárquicos o más grandes.

En lugar de usar llamadas al índice para indexar un repositorio completo de vez en cuando, también puedes usar la cola de indexación de Google Cloud como un mecanismo para hacer un seguimiento de los cambios y solo indexar aquellos elementos que han sido modificados. Puedes usar la items.push de envío de elementos a la cola para sondearlos y actualizarlos más tarde. Para ver más para obtener más información sobre la cola de indexación de Google Cloud, consulta Cola de indexación de Google Cloud.

Para obtener más información sobre la API de Google Cloud Search, consulta API de Cloud Search.