Создание соединителя содержимого

Коннектор контента — это программа, используемая для просмотра данных в корпоративном репозитории и заполнения источника данных. Google предлагает следующие варианты разработки коннекторов контента:

  • Content Connector SDK. Это хороший вариант для тех, кто программирует на Java. Content Connector SDK — это оболочка для REST API, позволяющая быстро создавать коннекторы. Чтобы создать коннектор контента с помощью этого SDK, см. статью Создание коннектора контента с помощью Content Connector SDK .

  • Низкоуровневый REST API или библиотеки API. Используйте эти варианты, если вы не программируете на Java или если ваша кодовая база лучше подходит для REST API или библиотеки. Чтобы создать коннектор контента с помощью REST API, см. статью Создание коннектора контента с помощью REST API .

Типичный коннектор контента выполняет следующие задачи:

  1. Считывает и обрабатывает параметры конфигурации.
  2. Извлекает отдельные фрагменты индексируемых данных, называемые « элементами », из стороннего репозитория контента.
  3. Объединяет списки контроля доступа, метаданные и данные контента в индексируемые элементы.
  4. Индексирует элементы в источнике данных Cloud Search.
  5. (необязательно) Принимает уведомления об изменениях из стороннего репозитория контента. Уведомления об изменениях преобразуются в запросы на индексацию для синхронизации источника данных Cloud Search со сторонним репозиторием. Коннектор выполняет эту задачу только в том случае, если репозиторий поддерживает обнаружение изменений.

Создайте коннектор контента с помощью Content Connector SDK

В следующих разделах объясняется, как создать коннектор контента с помощью Content Connector SDK.

Настройка зависимостей

Для использования SDK необходимо включить определённые зависимости в файл сборки. Нажмите на вкладку ниже, чтобы просмотреть зависимости для вашей среды сборки:

Maven 

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

Грейдл 

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

Создайте конфигурацию вашего коннектора

У каждого коннектора есть файл конфигурации, содержащий используемые им параметры, такие как идентификатор вашего репозитория. Параметры определяются парами «ключ-значение» , например, api.sourceId= 1234567890abcdef .

Google Cloud Search SDK содержит несколько параметров конфигурации, предоставляемых Google, используемых всеми коннекторами. В файле конфигурации необходимо указать следующие параметры, предоставляемые Google:

  • Для коннектора контента необходимо объявить api.sourceId и api.serviceAccountPrivateKeyFile , поскольку эти параметры определяют местоположение вашего репозитория и закрытый ключ, необходимый для доступа к репозиторию.
  • Для коннектора удостоверений необходимо объявить api.identitySourceId , поскольку этот параметр определяет расположение вашего внешнего источника удостоверений. При синхронизации пользователей необходимо также объявить api.customerId как уникальный идентификатор вашей корпоративной учётной записи Google Workspace.

Если вы не хотите переопределять значения по умолчанию других параметров, предоставляемых Google, вам не нужно объявлять их в файле конфигурации. Дополнительную информацию о параметрах конфигурации, предоставляемых Google, например, о том, как генерировать определённые идентификаторы и ключи, см. в разделе «Параметры конфигурации, предоставляемые Google» .

Вы также можете определить собственные параметры, специфичные для репозитория, для использования в файле конфигурации.

Передать файл конфигурации в коннектор

Настройте config системных свойств для передачи файла конфигурации в коннектор. Вы можете задать это свойство, используя аргумент -D при запуске коннектора. Например, следующая команда запускает коннектор с файлом конфигурации MyConfig.properties :

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

Если этот аргумент отсутствует, SDK попытается получить доступ к файлу конфигурации по умолчанию с именем connector-config.properties .

Определите свою стратегию обхода

Основная функция коннектора контента — обход репозитория и индексация его данных. Необходимо реализовать стратегию обхода, основанную на размере и структуре данных в репозитории. Вы можете разработать собственную стратегию или выбрать одну из следующих стратегий, реализованных в SDK:

Стратегия полного обхода

Стратегия полного обхода сканирует весь репозиторий и индексирует каждый его элемент вслепую. Эта стратегия обычно используется, когда у вас небольшой репозиторий и вы можете позволить себе полный обход при каждой индексации.

Эта стратегия обхода подходит для небольших репозиториев с преимущественно статическими, неиерархическими данными. Вы также можете использовать её, когда обнаружение изменений затруднено или не поддерживается репозиторием.

Стратегия обхода списка

Стратегия обхода списка сканирует весь репозиторий, включая все дочерние узлы, определяя статус каждого элемента. Затем коннектор выполняет второй проход и индексирует только новые или обновлённые с момента последнего индексирования элементы. Эта стратегия обычно используется для выполнения инкрементных обновлений существующего индекса (вместо того, чтобы выполнять полный обход при каждом обновлении индекса).

Такая стратегия обхода подходит, когда обнаружение изменений затруднено или не поддерживается репозиторием, данные не являются иерархическими и вы работаете с очень большими наборами данных.

Обход графа

Стратегия обхода графа сканирует весь родительский узел, определяя статус каждого элемента. Затем коннектор выполняет второй проход и индексирует только те элементы в корневом узле, которые являются новыми или обновленными с момента последней индексации. Наконец, коннектор передает все дочерние идентификаторы, а затем индексирует элементы в дочерних узлах, которые являются новыми или обновленными. Коннектор продолжает рекурсивно проходить по всем дочерним узлам, пока не будут обработаны все элементы. Такой обход обычно используется для иерархических репозиториев, где перечисление всех идентификаторов нецелесообразно.

Эта стратегия подходит, если у вас есть иерархические данные, которые необходимо сканировать, например, ряд каталогов или веб-страниц.

Каждая из этих стратегий обхода реализуется классом-шаблоном коннектора в SDK. Вы можете реализовать собственную стратегию обхода, но эти шаблоны значительно ускоряют разработку коннектора. Чтобы создать коннектор с использованием шаблона, перейдите к разделу, соответствующему вашей стратегии обхода:

Создайте полный обходной соединитель, используя шаблонный класс

В этом разделе документации содержатся ссылки на фрагменты кода из примера FullTraversalSample .

Реализуйте точку входа коннектора

Точкой входа в коннектор является метод main() . Его основная задача — создать экземпляр класса Application и вызвать его метод start() для запуска коннектора.

Перед вызовом application.start() используйте класс IndexingApplication.Builder для создания экземпляра шаблона FullTraversalConnector . FullTraversalConnector принимает объект Repository , методы которого вы реализуете. Следующий фрагмент кода показывает, как реализовать метод 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();
}

В фоновом режиме SDK вызывает метод initConfig() после того, как метод main() вашего коннектора вызывает Application.build . Метод initConfig() выполняет следующие задачи:

  1. Вызывает метод Configuation.isInitialized() чтобы убедиться, что Configuration не инициализирована.
  2. Инициализирует объект Configuration с помощью пар «ключ-значение», предоставленных Google. Каждая пара «ключ-значение» хранится в объекте ConfigValue внутри объекта Configuration .

Реализовать интерфейс Repository

Единственная цель объекта Repository — обход и индексация элементов репозитория. При использовании шаблона для создания коннектора контента достаточно переопределить лишь некоторые методы в интерфейсе Repository . Переопределяемые методы зависят от используемого шаблона и стратегии обхода. Для FullTraversalConnector переопределите следующие методы:

  • Метод init() . Для настройки и инициализации репозитория данных переопределите метод init() .

  • Метод getAllDocs() . Чтобы обойти и индексировать все элементы в репозитории данных, переопределите метод getAllDocs() . Этот метод вызывается один раз для каждого запланированного обхода (согласно конфигурации).

  • (необязательно) Метод getChanges() . Если ваш репозиторий поддерживает обнаружение изменений, переопределите метод getChanges() . Этот метод вызывается один раз для каждого запланированного инкрементного обхода (согласно вашей конфигурации) для извлечения изменённых элементов и их индексации.

  • (необязательно) Метод close() . Если вам нужно очистить репозиторий, переопределите метод close() . Этот метод вызывается один раз при завершении работы коннектора.

Каждый из методов объекта Repository возвращает объект ApiOperation определённого типа. Объект ApiOperation выполняет действие в виде одного или нескольких вызовов IndexingService.indexItem() для фактического индексирования вашего репозитория.

Получить пользовательские параметры конфигурации

В рамках настройки коннектора вам потребуется получить все необходимые параметры из объекта Configuration . Эта задача обычно выполняется в методе init() класса Repository .

Класс Configuration содержит несколько методов для получения различных типов данных из конфигурации. Каждый метод возвращает объект ConfigValue . Затем вы используете метод get() объекта ConfigValue для получения фактического значения. Следующий фрагмент кода из FullTraversalSample показывает, как получить одно пользовательское целочисленное значение из объекта Configuration :

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

Чтобы получить и проанализировать параметр, содержащий несколько значений, используйте один из парсеров типов класса Configuration для разделения данных на отдельные фрагменты. В следующем фрагменте кода из коннектора руководства используется метод getMultiValue для получения списка имён репозиториев GitHub:

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

Выполнить полный обход

Переопределите метод getAllDocs() для полного обхода и индексации репозитория. Метод getAllDocs() принимает контрольную точку. Контрольная точка используется для возобновления индексации с определённого элемента в случае прерывания процесса. Для каждого элемента в репозитории выполните следующие действия в методе getAllDocs() :

  1. Установите разрешения.
  2. Задайте метаданные для индексируемого элемента.
  3. Объедините метаданные и элемент в один индексируемый RepositoryDoc .
  4. Упаковываем каждый индексируемый элемент в итератор, возвращаемый методом getAllDocs() . Обратите внимание, что getAllDocs() фактически возвращает CheckpointCloseableIterable , который представляет собой итерацию объектов ApiOperation , каждый из которых представляет собой API-запрос, выполненный к RepositoryDoc , например, его индексацию.

Если набор элементов слишком велик для обработки за один вызов, включите контрольную точку и установите hasMore(true) чтобы указать, что для индексации доступно больше элементов.

Установить разрешения для элемента

Ваш репозиторий использует список контроля доступа (ACL) для определения пользователей или групп, имеющих доступ к элементу. ACL — это список идентификаторов групп или пользователей, которые могут получить доступ к элементу.

Необходимо продублировать список контроля доступа (ACL), используемый вашим репозиторием, чтобы гарантировать, что только пользователи, имеющие доступ к элементу, смогут увидеть его в результатах поиска. Список контроля доступа (ACL) для элемента должен быть включен при индексировании элемента, чтобы Google Cloud Search имел необходимую информацию для предоставления корректного уровня доступа к элементу.

Content Connector SDK предоставляет богатый набор классов и методов ACL для моделирования списков ACL большинства репозиториев. Вам необходимо проанализировать ACL для каждого элемента в репозитории и создать соответствующий ACL для Google Cloud Search при индексации элемента. Если в ACL вашего репозитория используются такие концепции, как наследование ACL, моделирование такого ACL может быть сложным. Для получения дополнительной информации о списках ACL Google Cloud Search см. статью Google Cloud Search ACL .

Примечание: API индексирования Cloud Search поддерживает однодоменные списки контроля доступа (ACL). Он не поддерживает кроссдоменные списки контроля доступа (CCL). Используйте класс Acl.Builder для настройки доступа к каждому элементу с помощью ACL. Следующий фрагмент кода, взятый из полного примера обхода, позволяет всем пользователям или «принципалам» ( getCustomerPrincipal() ) быть «читателями» всех элементов ( .setReaders() ) при выполнении поиска.

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

Вам необходимо понимать принципы работы списков контроля доступа (ACL), чтобы правильно моделировать их для репозитория. Например, вы можете индексировать файлы в файловой системе, использующей модель наследования, при которой дочерние папки наследуют разрешения от родительских. Для моделирования наследования списков контроля доступа (ACL) требуется дополнительная информация, изложенная в статье «Списки контроля доступа (ACL) Google Cloud Search».

Установить метаданные для элемента

Метаданные хранятся в объекте Item . Для создания Item необходимы как минимум уникальный строковый идентификатор, тип элемента, список контроля доступа, URL-адрес и версия. В следующем фрагменте кода показано, как создать Item с помощью вспомогательного класса IndexingItemBuilder .

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

Создать индексируемый элемент

После настройки метаданных для элемента вы можете создать индексируемый элемент, используя класс RepositoryDoc.Builder . В следующем примере показано, как создать один индексируемый элемент.

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

RepositoryDoc — это тип ApiOperation , который выполняет реальный запрос IndexingService.indexItem() .

Вы также можете использовать метод setRequestMode() класса RepositoryDoc.Builder для определения запроса на индексацию как ASYNCHRONOUS или SYNCHRONOUS :

ASYNCHRONOUS
Асинхронный режим приводит к увеличению задержки между индексацией и обслуживанием и обеспечивает большую квоту пропускной способности для запросов на индексацию. Асинхронный режим рекомендуется для первоначальной индексации (обратной заливки) всего репозитория.
SYNCHRONOUS
Синхронный режим обеспечивает более короткую задержку от индексации до обслуживания и позволяет использовать ограниченную квоту пропускной способности. Синхронный режим рекомендуется для индексации обновлений и изменений в репозитории. Если режим запроса не указан, по умолчанию используется SYNCHRONOUS .

Упаковать каждый индексируемый элемент в итератор

Метод getAllDocs() возвращает Iterator , а именно CheckpointCloseableIterable , объектов RepositoryDoc . Для создания и возврата итератора можно использовать класс CheckpointClosableIterableImpl.Builder . В следующем фрагменте кода показано, как создать и вернуть итератор.

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

SDK выполняет каждый вызов индексации, заключенный в итераторе.

Следующие шаги

Вот несколько следующих шагов, которые вы можете предпринять:

Создайте соединитель обхода списка, используя шаблонный класс

Очередь индексации Cloud Search используется для хранения идентификаторов и необязательных хэш-значений для каждого элемента в репозитории. Коннектор обхода списка отправляет идентификаторы элементов в очередь индексации Google Cloud Search и извлекает их по одному для индексации. Google Cloud Search поддерживает очереди и сравнивает их содержимое для определения статуса элемента, например, был ли элемент удалён из репозитория. Подробнее об очереди индексации Cloud Search см. в статье «Очередь индексации Cloud Search» .

В этом разделе документации содержатся ссылки на фрагменты кода из примера ListTraversalSample .

Реализуйте точку входа коннектора

Точкой входа в коннектор является метод main() . Его основная задача — создать экземпляр класса Application и вызвать его метод start() для запуска коннектора.

Перед вызовом application.start() используйте класс IndexingApplication.Builder для создания экземпляра шаблона ListingConnector . ListingConnector принимает объект Repository , методы которого вы реализуете. В следующем фрагменте кода показано, как создать экземпляр ListingConnector и связанный с ним Repository :

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

В фоновом режиме SDK вызывает метод initConfig() после того, как метод main() вашего коннектора вызывает Application.build . Метод initConfig() :

  1. Вызывает метод Configuation.isInitialized() чтобы убедиться, что Configuration не инициализирована.
  2. Инициализирует объект Configuration с помощью пар «ключ-значение», предоставленных Google. Каждая пара «ключ-значение» хранится в объекте ConfigValue внутри объекта Configuration .

Реализовать интерфейс Repository

Единственная цель объекта Repository — обход и индексация элементов репозитория. При использовании шаблона для создания коннектора контента достаточно переопределить лишь некоторые методы в интерфейсе Repository . Переопределяемые методы зависят от используемого шаблона и стратегии обхода. Для ListingConnector переопределите следующие методы:

  • Метод init() . Для настройки и инициализации репозитория данных переопределите метод init() .

  • Метод getIds() . Чтобы получить идентификаторы и хэш-значения всех записей в репозитории, переопределите метод getIds() .

  • Метод getDoc() . Чтобы добавить новые, обновить, изменить или удалить элементы индекса, переопределите метод getDoc() .

  • (необязательно) Метод getChanges() . Если ваш репозиторий поддерживает обнаружение изменений, переопределите метод getChanges() . Этот метод вызывается один раз для каждого запланированного инкрементного обхода (согласно вашей конфигурации) для извлечения изменённых элементов и их индексации.

  • (необязательно) Метод close() . Если вам нужно очистить репозиторий, переопределите метод close() . Этот метод вызывается один раз при завершении работы коннектора.

Каждый из методов объекта Repository возвращает объект ApiOperation определённого типа. Объект ApiOperation выполняет действие в виде одного или нескольких вызовов IndexingService.indexItem() для фактического индексирования вашего репозитория.

Получить пользовательские параметры конфигурации

В рамках настройки коннектора вам потребуется получить все необходимые параметры из объекта Configuration . Эта задача обычно выполняется в методе init() класса Repository .

Класс Configuration содержит несколько методов для получения различных типов данных из конфигурации. Каждый метод возвращает объект ConfigValue . Затем вы используете метод get() объекта ConfigValue для получения фактического значения. Следующий фрагмент кода из FullTraversalSample показывает, как получить одно пользовательское целочисленное значение из объекта Configuration :

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

Чтобы получить и проанализировать параметр, содержащий несколько значений, используйте один из парсеров типов класса Configuration для разделения данных на отдельные фрагменты. В следующем фрагменте кода из коннектора руководства используется метод getMultiValue для получения списка имён репозиториев GitHub:

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

Выполнить обход списка

Переопределите метод getIds() для получения идентификаторов и хэш-значений всех записей в репозитории. Метод getIds() принимает контрольную точку. Контрольная точка используется для возобновления индексации с определённого элемента в случае прерывания процесса.

Затем переопределите метод getDoc() для обработки каждого элемента в очереди индексации Cloud Search.

Отправка идентификаторов элементов и хэш-значений

Переопределите getIds() для извлечения идентификаторов элементов и связанных с ними хэш-значений контента из репозитория. Пары идентификаторов и хэш-значений затем упаковываются в запрос на отправку в очередь индексации Cloud Search. Обычно сначала отправляются корневые или родительские идентификаторы, а затем дочерние, пока не будет обработана вся иерархия элементов.

Метод getIds() принимает контрольную точку, представляющую последний индексируемый элемент. Контрольную точку можно использовать для возобновления индексации с определённого элемента в случае прерывания процесса. Для каждого элемента в репозитории выполните следующие действия в методе getIds() :

  • Получите каждый идентификатор элемента и соответствующее ему хэш-значение из репозитория.
  • Упакуйте каждую пару идентификатора и хэш-значения в PushItems .
  • Объедините каждый PushItems в итератор, возвращаемый методом getIds() . Обратите внимание, что getIds() фактически возвращает CheckpointCloseableIterable , который представляет собой итерацию объектов ApiOperation , каждый из которых представляет собой запрос API, выполненный к RepositoryDoc , например, для помещения элементов в очередь.

В следующем фрагменте кода показано, как получить идентификатор каждого элемента и его хэш-значение и вставить их в PushItems . PushItems — это запрос ApiOperation на добавление элемента в очередь индексации Cloud Search.

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

В следующем фрагменте кода показано, как использовать класс PushItems.Builder для упаковки идентификаторов и хэш-значений в одну ApiOperation push ApiOperation.

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

Элементы помещаются в очередь индексации Cloud Search для дальнейшей обработки.

Извлечь и обработать каждый предмет

Переопределите getDoc() для обработки каждого элемента в очереди индексации Cloud Search. Элемент может быть новым, изменённым, неизменённым или может отсутствовать в исходном репозитории. Извлеките и проиндексируйте каждый новый или изменённый элемент. Удалите из индекса элементы, которых больше нет в исходном репозитории.

Метод getDoc() принимает элемент из очереди индексации Google Cloud Search. Для каждого элемента в очереди выполните следующие действия в методе getDoc() :

  1. Проверьте, существует ли идентификатор элемента в очереди индексации Cloud Search в репозитории. Если нет, удалите элемент из индекса.

  2. Опросить индекс на предмет статуса элемента и, если элемент не изменился ( ACCEPTED ), ничего не делать.

  3. Изменённый индекс или новые элементы:

    1. Установите разрешения.
    2. Задайте метаданные для индексируемого элемента.
    3. Объедините метаданные и элемент в один индексируемый RepositoryDoc .
    4. Верните RepositoryDoc .

Примечание: Шаблон ListingConnector не поддерживает возврат значения null в методе getDoc() . Возврат значения null приводит к исключению NullPointerException.

Обработка удаленных элементов

В следующем фрагменте кода показано, как определить, существует ли элемент в репозитории, и, если нет, удалить его.

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

Обратите внимание, что documents — это структура данных, представляющая репозиторий. Если documentID не найден в documents , верните APIOperations.deleteItem(resourceName) , чтобы удалить элемент из индекса.

Обрабатывать неизмененные элементы

В следующем фрагменте кода показано, как опрашивать статус элемента в очереди индексации Cloud Search и обрабатывать неизмененный элемент.

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

Чтобы определить, не был ли элемент изменён, проверьте его статус, а также другие метаданные, которые могут указывать на изменение. В этом примере хеш метаданных используется для определения того, был ли элемент изменён.

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

Установить разрешения для элемента

Ваш репозиторий использует список контроля доступа (ACL) для определения пользователей или групп, имеющих доступ к элементу. ACL — это список идентификаторов групп или пользователей, которые могут получить доступ к элементу.

Необходимо продублировать список контроля доступа (ACL), используемый вашим репозиторием, чтобы гарантировать, что только пользователи, имеющие доступ к элементу, смогут увидеть его в результатах поиска. Список контроля доступа (ACL) для элемента должен быть включен при индексировании элемента, чтобы Google Cloud Search имел необходимую информацию для предоставления корректного уровня доступа к элементу.

Content Connector SDK предоставляет богатый набор классов и методов ACL для моделирования списков ACL большинства репозиториев. Вам необходимо проанализировать ACL для каждого элемента в репозитории и создать соответствующий ACL для Google Cloud Search при индексации элемента. Если в ACL вашего репозитория используются такие концепции, как наследование ACL, моделирование такого ACL может быть сложным. Для получения дополнительной информации о списках ACL Google Cloud Search см. статью Google Cloud Search ACL .

Примечание: API индексирования Cloud Search поддерживает однодоменные списки контроля доступа (ACL). Он не поддерживает кроссдоменные списки контроля доступа (CCL). Используйте класс Acl.Builder для настройки доступа к каждому элементу с помощью ACL. Следующий фрагмент кода, взятый из полного примера обхода, позволяет всем пользователям или «принципалам» ( getCustomerPrincipal() ) быть «читателями» всех элементов ( .setReaders() ) при выполнении поиска.

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

Вам необходимо понимать принципы работы списков контроля доступа (ACL), чтобы правильно моделировать их для репозитория. Например, вы можете индексировать файлы в файловой системе, использующей модель наследования, при которой дочерние папки наследуют разрешения от родительских. Для моделирования наследования списков контроля доступа (ACL) требуется дополнительная информация, изложенная в статье «Списки контроля доступа (ACL) Google Cloud Search».

Установить метаданные для элемента

Метаданные хранятся в объекте Item . Для создания Item необходимы как минимум уникальный строковый идентификатор, тип элемента, список контроля доступа, URL-адрес и версия. В следующем фрагменте кода показано, как создать Item с помощью вспомогательного класса IndexingItemBuilder .

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

Создать индексируемый элемент

После настройки метаданных для элемента вы можете создать индексируемый элемент с помощью RepositoryDoc.Builder . В следующем примере показано, как создать один индексируемый элемент.

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

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

RepositoryDoc — это тип ApiOperation , который выполняет реальный запрос IndexingService.indexItem() .

Вы также можете использовать метод setRequestMode() класса RepositoryDoc.Builder для определения запроса на индексацию как ASYNCHRONOUS или SYNCHRONOUS :

ASYNCHRONOUS
Асинхронный режим приводит к увеличению задержки между индексацией и обслуживанием и обеспечивает большую квоту пропускной способности для запросов на индексацию. Асинхронный режим рекомендуется для первоначальной индексации (обратной заливки) всего репозитория.
SYNCHRONOUS
Синхронный режим обеспечивает более короткую задержку от индексации до обслуживания и позволяет использовать ограниченную квоту пропускной способности. Синхронный режим рекомендуется для индексации обновлений и изменений в репозитории. Если режим запроса не указан, по умолчанию используется SYNCHRONOUS .

Следующие шаги

Вот несколько следующих шагов, которые вы можете предпринять:

Создайте соединитель обхода графа, используя шаблонный класс

Очередь индексации Cloud Search используется для хранения идентификаторов и необязательных хэш-значений для каждого элемента в репозитории. Коннектор обхода графа отправляет идентификаторы элементов в очередь индексации Google Cloud Search и извлекает их по одному для индексации. Google Cloud Search поддерживает очереди и сравнивает их содержимое для определения статуса элемента, например, был ли элемент удалён из репозитория. Дополнительную информацию об очереди индексации Cloud Search см. в статье «Очередь индексации Google Cloud Search» .

Во время индексирования содержимое элемента извлекается из хранилища данных, а идентификаторы всех дочерних элементов помещаются в очередь. Коннектор продолжает рекурсивно обрабатывать идентификаторы родительских и дочерних элементов, пока не будут обработаны все элементы.

В этом разделе документации содержатся ссылки на фрагменты кода из примера GraphTraversalSample .

Реализуйте точку входа коннектора

Точкой входа в коннектор является метод main() . Его основная задача — создать экземпляр класса Application и вызвать его метод start() для запуска коннектора.

Перед вызовом application.start() используйте класс IndexingApplication.Builder для создания экземпляра шаблона ListingConnector . ListingConnector принимает объект Repository , методы которого вы реализуете.

В следующем фрагменте показано, как создать экземпляр ListingConnector и связанный с ним Repository :

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

В фоновом режиме SDK вызывает метод initConfig() после того, как метод main() вашего коннектора вызывает Application.build . Метод initConfig() :

  1. Вызывает метод Configuation.isInitialized() чтобы убедиться, что Configuration не инициализирована.
  2. Инициализирует объект Configuration с помощью пар «ключ-значение», предоставленных Google. Каждая пара «ключ-значение» хранится в объекте ConfigValue внутри объекта Configuration .

Реализовать интерфейс Repository

Единственная цель объекта Repository — обход и индексация элементов репозитория. При использовании шаблона для создания коннектора контента достаточно переопределить лишь некоторые методы в интерфейсе Repository . Переопределяемые методы зависят от используемого шаблона и стратегии обхода. Для ListingConnector переопределяются следующие методы:

  • Метод init() . Для настройки и инициализации репозитория данных переопределите метод init() .

  • Метод getIds() . Чтобы получить идентификаторы и хэш-значения всех записей в репозитории, переопределите метод getIds() .

  • Метод getDoc() . Чтобы добавить новые, обновить, изменить или удалить элементы индекса, переопределите метод getDoc() .

  • (необязательно) Метод getChanges() . Если ваш репозиторий поддерживает обнаружение изменений, переопределите метод getChanges() . Этот метод вызывается один раз для каждого запланированного инкрементного обхода (согласно вашей конфигурации) для извлечения изменённых элементов и их индексации.

  • (необязательно) Метод close() . Если вам нужно очистить репозиторий, переопределите метод close() . Этот метод вызывается один раз при завершении работы коннектора.

Каждый из методов объекта Repository возвращает объект ApiOperation определённого типа. Объект ApiOperation выполняет действие в виде одного или нескольких вызовов IndexingService.indexItem() для фактического индексирования вашего репозитория.

Получить пользовательские параметры конфигурации

В рамках настройки коннектора вам потребуется получить все необходимые параметры из объекта Configuration . Эта задача обычно выполняется в методе init() класса Repository .

Класс Configuration содержит несколько методов для получения различных типов данных из конфигурации. Каждый метод возвращает объект ConfigValue . Затем вы используете метод get() объекта ConfigValue для получения фактического значения. Следующий фрагмент кода из FullTraversalSample показывает, как получить одно пользовательское целочисленное значение из объекта Configuration :

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

Чтобы получить и проанализировать параметр, содержащий несколько значений, используйте один из парсеров типов класса Configuration для разделения данных на отдельные фрагменты. В следующем фрагменте кода из коннектора руководства используется метод getMultiValue для получения списка имён репозиториев GitHub:

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

Выполнить обход графа

Переопределите метод getIds() для получения идентификаторов и хэш-значений всех записей в репозитории. Метод getIds() принимает контрольную точку. Контрольная точка используется для возобновления индексации с определённого элемента в случае прерывания процесса.

Затем переопределите метод getDoc() для обработки каждого элемента в очереди индексации Cloud Search.

Отправка идентификаторов элементов и хэш-значений

Переопределите getIds() для извлечения идентификаторов элементов и связанных с ними хэш-значений контента из репозитория. Пары идентификаторов и хэш-значений затем упаковываются в запрос на отправку в очередь индексации Cloud Search. Обычно сначала отправляются корневые или родительские идентификаторы, а затем дочерние, пока не будет обработана вся иерархия элементов.

Метод getIds() принимает контрольную точку, представляющую последний элемент, который будет представлен. Контрольная точка может использоваться для возобновления индексации по определенному элементу, если процесс будет прерван. Для каждого элемента в вашем репозитории выполните эти шаги в методе getIds() :

  • Получите каждый идентификатор каждого элемента и связанное с ним значение хэша из репозитория.
  • Упакуйте каждый идентификатор и хэш -значение в PushItems .
  • Объедините все PushItems в итератор, возвращаемый методом getIds() . Обратите внимание, что getIds() фактически возвращает CheckpointCloseableIterable , которая является итерацией объектов ApiOperation , каждый объект, представляющий запрос API, выполняемый в RepositoryDoc , например, подтолкнуть элементы в очередь.

Следующий фрагмент кода показывает, как получить каждый идентификатор элемента и значение хэша, и вставить их в PushItems . PushItems - это запрос ApiOperation , чтобы выдвинуть элемент в очередь индексации поиска в облачном поиске.

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

Следующий фрагмент кода показывает, как использовать класс PushItems.Builder для упаковки идентификаторов и значений хэша в единое push ApiOperation .

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

Элементы выдвигаются в очередь индексации по поиску облачного поиска для дальнейшей обработки.

Получить и обрабатывать каждый элемент

Переопределите getDoc() , чтобы обрабатывать каждый элемент в очереди индексации поиска в облаке. Предмет может быть новым, измененным, неизменным или больше не может существовать в хранилище источника. Получить и индексировать каждый элемент, который является новым или измененным. Удалите элементы из индекса, которые больше не существуют в хранилище источника.

Метод getDoc() принимает элемент из очереди индексации поиска. Для каждого элемента в очереди выполните эти шаги в методе getDoc() :

  1. Проверьте, существует ли идентификатор элемента в очереди индексации поиска, существует в репозитории. Если нет, удалите элемент из индекса. Если предмет существует, продолжайте следующий шаг.

  2. Индекс изменился или новые элементы:

    1. Установите разрешения.
    2. Установите метаданные для предмета, который вы индексируете.
    3. Объедините метаданные и элемент в один индексируемый RepositoryDoc .
    4. Поместите идентификаторы детей в очередь индексации поиска в облаке для дальнейшей обработки.
    5. Вернуть RepositoryDoc .

Обрабатывать удаленные предметы

Следующий фрагмент кода показывает, как определить, существует ли элемент в индексе, а не удалить его.

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

Установите разрешения на элемент

Ваш репозиторий использует список контроля доступа (ACL) для идентификации пользователей или групп, которые имеют доступ к элементу. ACL - это список идентификаторов для групп или пользователей, которые могут получить доступ к элементу.

Вы должны дублировать ACL, используемый вашим хранилищем, чтобы гарантировать, что только те пользователи, имеющие доступ к элементу, могут увидеть этот элемент в результате поиска. ACL для элемента должен быть включен при индексации элемента, так что Google Cloud Search имеет информацию, необходимую для предоставления правильного уровня доступа к элементу.

Content Connector SDK предоставляет богатый набор классов ACL и методов для моделирования ACL большинства репозиториев. Вы должны проанализировать ACL для каждого элемента в вашем репозитории и создать соответствующий ACL для поиска Google Cloud, когда вы индексируете элемент. Если ACL вашего репозитория использует такие понятия, как наследование ACL, моделирование этого ACL может быть сложным. Для получения дополнительной информации о Google Cloud Search ACL см. ACLS Google Cloud Search .

ПРИМЕЧАНИЕ. API индексации облачного поиска поддерживает однодоменные ACLS. Он не поддерживает междоменные ACL. Используйте класс Acl.Builder , чтобы установить доступ к каждому элементу, используя ACL. Следующий фрагмент кода, взятый из полной выборки, позволяет всем пользователям или «принципалам» ( getCustomerPrincipal() ) быть «читателями» всех элементов ( .setReaders() ) при выполнении поиска.

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

Вы должны понимать ACL для правильного моделирования ACL для репозитория. Например, вы можете индексировать файлы в файловой системе, которая использует какую -то модель наследования, в которой дочерние папки наследуют разрешения от родительских папок. Моделирование наследования ACL требует дополнительной информации, описанной в Google Cloud Search ACLS

Установите метаданные для предмета

Метаданные хранятся в Item . Чтобы создать Item , вам нужен как минимум уникальный идентификатор строки, тип элемента, ACL, URL и версия для элемента. Следующий фрагмент кода показывает, как создать Item используя класс Helper IndexingItemBuilder .

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

Создать индексируемый элемент

После того, как вы установили метаданные для элемента, вы можете создать фактический индексируемый элемент, используя RepositoryDoc.Builder . В следующем примере показано, как создать один индексируемый элемент.

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

RepositoryDoc - это тип ApiOperation , который выполняет фактический запрос IndexingService.indexItem() .

Вы также можете использовать метод setRequestMode() класса RepositoryDoc.Builder для определения запроса индексации как ASYNCHRONOUS или SYNCHRONOUS :

ASYNCHRONOUS
Асинхронный режим приводит к более длинной задержке индексации к проведению и вмещает большую квоту пропускной способности для запросов индексации. Асинхронный режим рекомендуется для начальной индексации (засыпания) всего репозитория.
SYNCHRONOUS
Синхронный режим приводит к более короткой задержке индексации к проведению и вмещает ограниченную квоту пропускной способности. Синхронный режим рекомендуется для индексации обновлений и изменений в хранилище. В случае неопределенности режим запроса по умолчанию SYNCHRONOUS .

Поместите идентификаторы детей в очередь индексации поиска в облаке

Следующий фрагмент кода показывает, как включить идентификаторы дочерних идентификаторов для в настоящее время обработки родительского элемента в очередь для обработки. Эти идентификаторы обрабатываются после того, как родительский элемент проиндексирован.

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

Следующие шаги

Вот несколько следующих шагов, которые вы можете предпринять:

Создайте контент -разъем, используя API REST

В следующих разделах объясняется, как создать контент -разъем, используя API REST.

Определите свою стратегию обхода

Основная функция контента -разъема состоит в том, чтобы пересечь репозиторий и индексировать его данные. Вы должны реализовать стратегию обхода в зависимости от размера и макета данных в вашем репозитории. Ниже приведены три общие стратегии обхода:

Полная стратегия обхода

Полная стратегия обхода сканирует весь репозиторий и слепо индексирует каждый элемент. Эта стратегия обычно используется, когда у вас есть небольшой репозиторий и может позволить себе накладные расходы на полное прохождение каждый раз, когда вы индексируете.

Эта стратегия обхода подходит для небольших репозиториев с в основном статическими, не иерархическими данными. Вы также можете использовать эту стратегию обхода, когда обнаружение изменений затруднено или не поддерживается репозиторием.

Список стратегии обхода

Стратегия пересечения списка сканирует весь репозиторий, включая все узлы дочерних узлов, определяя статус каждого элемента. Затем разъем берет второй проход и только индексирует новые элементы, которые являются новыми или были обновлены с момента последней индексации. Эта стратегия обычно используется для выполнения инкрементных обновлений существующего индекса (вместо того, чтобы делать полное прохождение каждый раз, когда вы обновляете индекс).

Эта стратегия обхода подходит, когда обнаружение изменений затруднено или не поддерживается репозиторием, у вас есть не иерархические данные, и вы работаете с очень большими наборами данных.

График обход

Стратегия обхода графика сканирует весь родительский узел, определяющий статус каждого элемента. Затем разъем берет второй проход, и только элементы индексов в корневом узле являются новыми или были обновлены с момента последней индексации. Наконец, разъем проходит любые идентификаторы дочерних идентификаторов, а затем индексирует элементы в узлах дочерних узлов, которые являются новыми или были обновлены. Разъем продолжает рекурсивно через все дочерние узлы, пока все элементы не будут рассмотрены. Такое обход обычно используется для иерархических репозиториев, где список всех идентификаторов не является практичным.

Эта стратегия подходит, если у вас есть иерархические данные, которые необходимо заполнить, такие как серийные каталоги или веб -страницы.

Реализуйте свою стратегию обхода и индексы

Каждый индексируемый элемент для облачного поиска называется элементом в облачном поиске API. Элемент может быть файлом, папкой, строкой в файле CSV или записи базы данных.

Как только ваша схема зарегистрирована, вы можете заполнить индекс:

  1. (необязательно) Использование items.upload для загрузки файлов более 100 киб для индексации. Для небольших файлов встройте контент как InlineContent с использованием items.index .

  2. (необязательно) Использование media.upload для загрузки медиа -файлов для индексации.

  3. Использование items.index для индексации элемента. Например, если ваша схема использует определение объекта в схеме фильма , запрос индексации на один элемент будет выглядеть так: 

    {
  "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. (Необязательно) Использование элементов. Получить вызовы для проверки элемента был проиндексирован.

Чтобы выполнить полное обход, вы периодически переоцените весь репозиторий. Чтобы выполнить список или график, вам необходимо внедрить код для обработки изменений репозитория .

Обрабатывать изменения репозитория

Вы можете периодически собирать и индексировать каждый элемент из репозитория для выполнения полной индексации. Несмотря на то, что он эффективен в обеспечении актуального индекса, полная индексация может быть дорогостоящей при работе с более крупными или иерархическими репозиториями.

Вместо того, чтобы использовать индексные вызовы для индексации всего репозитория, вы также можете использовать очередь индексации Cloud Google в качестве механизма для отслеживания изменений и индексации только те элементы, которые изменились. Вы можете использовать ements.push Запросы, чтобы выдвигать элементы в очередь для последующего опроса и обновления. Для получения дополнительной информации о очереди индексации Google Cloud, см. В очереди индексации облака Google .

Для получения дополнительной информации об API поиска Google Cloud, см. API облачного поиска .