Вебхуки - это функциональность ArcGIS Enterprise, которая автоматически предоставляет приемникам вебхуков или другим приложениям информацию, управляемую событиями. ArcGIS Enterprise поддерживает два типа вебхуков:
- Вебхуки организации - администраторы могут подписаться на триггеры событий, относящиеся к пользователям, группам и элементам организации.
- Вебхуки сервиса - администраторы могут подписаться на вебхуки для геообработки и сервисов объектов.
- Сервисы геообработки - администраторы могут установить вебхуки сервиса геообработки, которые будут инициированы по завершении работы сервиса геообработки.
- Вебхуки сервиса объектов - администраторы могут подписаться на триггеры событий, относящиеся к сервисам объектов организации.
Примечание:
В этой версии вебхуки сервисов являются бета-функцией. Во время бета-тестирования эти функции могут быть не полными, иметь известные проблемы с производительностью или качеством и не будут поддерживаться технической поддержкой Esri. Документация бета-API для вебхуков сервиса доступна в Руководство по API администратора вебхуков сервиса PDF. Дополнительную информацию о функциях ArcGIS Enterprise в стадии бета-тестирования см. в разделе Бета-функции.
Все вебхуки ArcGIS Enterprise работают схожим образом. После инициализации вебхука информация о событии доставляется в схему JSON, содержащей соответствующую информацию, специфичную для каждого типа вебхука. У каждого типа вебхука есть определенные события, на которые они могут подписаться. Например, вебхуки организаций могут быть инициированы при публикации элемента, либо при создании новой учетной записи пользователя. Вебхуки сервиса объектов могут быть инициированы при изменении схемы векторного слоя. Вебхуки сервиса геообработки доставляют информацию о событии только после завершения работы сервиса геообработки.
С доставленной информацией о событии принимающие платформы выполняют определенное действие, которое уведомляет членов организации и администраторов о событии. В зависимости от потребностей организации это может быть рассылка e-mail определенным участникам или уведомление администраторов в Slack.
Так как вебхуки отправляют уведомления только после того, как событие произошло, они могут быть более эффективными, чем опрос. В отличие от опроса, вебхуки не требуют, чтобы приложения постоянно проверяли систему, чтобы увидеть, произошло ли конкретное событие.
Сценарий: Вебхуки организации
Рассмотрим сценарий, в котором организация ArcGIS Enterprise имеет набор определенных стандартов, которым должен соответствовать каждый элемент, прежде чем его можно будет опубликовать. Администраторы в этой организации хотят создать рабочий процесс, который позволит им реагировать в режиме реального времени, когда общий доступ к элементу не соответствует их стандартам. Они хотят использовать вебхуки, чтобы получать уведомления, когда владелец элемента публично поделился своим элементом, и использовать информацию о полезной нагрузке события как часть скрипта, который будет специально сообщать администраторам, если этот элемент не соответствует их стандартам, давая администраторам возможность обновить элемент или удалить его из общего доступа.
В списке ниже показано, как администраторы организации могут использовать вебхуки для создания такого рабочего процесса:
- Администраторы организации настроили приемник вебхука для записи входящих полезных данных в виде локальных текстовых файлов.
- Администраторы создали скрипт Python, который анализирует полезные данные текстового файла, чтобы извлечь соответствующую информацию об элементе и выполненной операции. Такой же скрипт позволяет администраторам реагировать на эту информацию, выслав уведомление в настроенный канал Slack. Если элемент является общедоступным, но не соответствует общедоступным стандартам, сценарий использует Slack API для отправки сообщения с обозначением отсутствующей или неверной информации администраторам организации.
- После написания скрипта администраторы создают вебхук, который срабатывает, когда владелец элемента делится своим элементом.
- Когда к элементу предоставляется общий доступ, сценарий анализирует полезные данные текстового файла и определяет, был ли элемент опубликован в общем доступе или внутри организации. Если доступ предоставлен внутри организации, дополнительных действий не будет. Если к элементу предоставлен общий доступ, скрипт будет оценивать элемент на основе установленных стандартов организации. Если оценка низкая (это означает, что общедоступные стандарты не соблюдены), администраторы будут уведомлены в своем канале Slack о том, какой элемент был опубликован и какие его метаданные в настоящее время не соответствуют стандартам.
- Затем администратор организации может отреагировать, либо обновив метаданные в соответствии со стандартами, либо закрыв общий доступ к элементу, либо отправив сообщение владельцу элемента, чтобы он внес необходимые изменения непосредственно из Slack.