Вебхуки — это технология, которая возникла в ответ на потребность в соединениях между отдельными корпоративными системами в режиме, близком к реальному времени. Хотя процессы ETL, экспорт и импорт данных или корпоративные сервисные шины существуют уже много лет, вебхуки представляют собой новую модель интеграции между этими системами и все чаще внедряются в различные типы программного обеспечения.
Вебхуки проще всего определить как сообщение между системами (полезная нагрузка), которое отправляется после того, как происходит определенное действие (триггер), независимо от того, происходит ли действие или событие в системе управления данными или в приложении. Эти сообщения с полезной нагрузкой могут различаться по размеру, содержанию или области действия, но в целом существует шаблон исходной системы и целевой системы с настроенными в источнике веб-перехватчиками, которые отправляют информацию в пункт назначения. Вместо того чтобы работать по расписанию, основанному на времени, вебхуки обычно запускаются точно в срок, например, когда происходит определенное событие, в том числе при редактировании формы, удалении файла, создании пользователя и т.д.
На техническом уровне вебхук обычно определяется как POST-запрос к конечной точке HTTPS, которая может быть анонимно доступна или защищена простым маркером или ключом, с телом содержимого в виде JSON. Содержимое POST относится к только что произошедшему событию (см. примеры ниже), а получатель получает сообщение и обрабатывает его на основе собственной логики. Чаще всего эти сообщения представляют собой документы JSON (по соглашению, но не по определению) и могут содержать узкие или широкие наборы информации в зависимости от того, как они были разработаны.
Вебхуки обычно считаются эффективным, но не надежным методом интеграции. Поскольку они слабо связаны с конечной точкой назначения, нет гарантии, что сообщение из исходной системы достигнет пункта назначения. Такие проблемы, как сбои в работе сети, сбой конечной точки или плохо составленное тело сообщения, могут привести к сбою доставки сообщения. Это означает, что вебхуки не являются абсолютно надежными, хотя и не сильно отличаются от любого другого REST API или конечной точки, которые могут страдать от тех же проблем с надежностью.
Вебхуки как возможность обычно добавляются в систему или приложение по определенным причинам, а не как базовая возможность или процесс для всех запросов или интерфейсов. Их часто используют для передачи информации или сообщений о событиях в другие системы, ориентированные на уведомления или автоматизацию, такие как Power Automate или Zapier. Запрос вебхука также может быть отправлен на пользовательский веб-сервис или конечную точку либо отправлен в инструмент геообработки ArcGIS.
Дополнительные рекомендации, связанные с вебхуками, а также примеры кода для получения и обработки вебхуков можно найти в репозитории Esri webhook-samples на Github.
Возможности вебхуков доступны в нескольких различных частях системы ArcGIS и могут использоваться для объединения рабочих процессов, интеграции с другими системами и запуска связанных событий, которые работают с данными, содержащимися в вебхуке. Несколько приложений и систем ArcGIS используют вебхуки по умолчанию, в том числе:
Вебхуки в ArcGIS Online доступны в контексте сервисов объектов, которые можно настроить для отправки вебхуков на основе различных условий, таких как новый объект или редактирование, а также в несколько мест назначения; например, разные конечные точки могут получать новые объекты, а не изменения. В этой записи блога приведены некоторые примеры того, как можно создавать и использовать вебхуки. Тело вебхука будет содержать информацию о наборе отредактированных объектов, которую удаленная система может использовать для обратного запроса к ArcGIS Online и получения фактических транзакционных изменений.
Вебхуки в ArcGIS Enterprise также поддерживают вебхуки на основе сервисов объектов, что очень похоже на ArcGIS Online, но также поддерживают несколько других шаблонов. Эти вебхуки на основе сервисов объектов настраиваются в директории администратора ArcGIS Server. Дополнительные сведения о настройке вебхука на основе сервиса объектов см. в статье Создание вебхуков.
Вебхуки ссервиса геообработки можно настроить на запуск по завершении задания сервиса геообработки, уведомляя удаленную систему о завершении задания и включая результаты задания (успешно, неудачно или отменено) вместе с URL-адресом, который удаленная система может использовать для получения статуса. Содержимое вебхука сервиса геообработки более подробно описано в документации ArcGIS Enterprise.
В этой записи блога описан пример совместного использования вебхуков сервиса объектов и сервиса геообработки для автоматизации рабочего процесса отчетности граждан с помощью системы управления работой.
ArcGIS Enterprise также поддерживает организационные вебхуки, которые активируются при изменении пользователей, групп и ресурса в развертывании ArcGIS Enterprise. Эти вебхуки можно настроить для запуска при определенном типе событий (например, создании новой группы) или при многих типах событий (что позволит удаленной системе анализировать и обрабатывать события независимо).
Как ArcGIS Survey123, так и ArcGIS Field Maps поддерживают функцию вебхука.
Field Maps предоставляет модуль для Make.com, который упрощает интеграцию рабочих процессов Field Maps, использующих размещенные сервисы объектов в ArcGIS Online. Подробнее см. Автоматизация Field Maps.
В Survey123 существуют похожие рабочие процессы для Make.com и ArcGIS Power Automate, но вебхуки также можно настроить вручную, чтобы они отправлялись в пункт назначения из полевого приложения (при сборе данных) или веб-формы Survey123 (при отправке данных через браузер). Подробнее см. Настройка вебхука на веб-сайте Survey123.
Для поддержки интеграции с другими системами и рабочими процессами ArcGIS Workflow Manager предоставляет простой способ создания конечной точки, которая получает вебхуки, как правило, для создания задания на основе внешней информации. Подробнее см. Создание заданий с помощью вебхуков.
При проектировании системы или интеграции, в которой вебхуки будут играть важную роль в решении или рабочем процессе, важно учитывать некоторые функциональные и нефункциональные требования, чтобы вебхуки были успешными. Эти соображения гарантируют, что пользователи системы и заинтересованные стороны правильно понимают роль вебхуков в системе и любые существующие ограничения.