Webhook は、異なるエンタープライズ システム間のほぼリアルタイムな接続ニーズから生まれたテクノロジーです。 ETL プロセス、データのエクスポートとインポート、またはエンタープライズ サービス バスなどは長年にわたって存在してきましたが、Webhook はこれらのシステム間を統合する新しいパターンであり、さまざまな種類のソフトウェアで導入が進んでいます。
Webhook は、アクションまたはイベントがデータ管理システムまたはアプリケーションで発生したかどうかに関係なく、特定のアクション (トリガー) が発生した後に送信されるシステム間のメッセージ (ペイロード) として、最も簡単に定義できます。 これらのペイロード メッセージはサイズ、内容、またはスコープが異なる場合がありますが、一般的には送信元システムと送信先システムのパターンがあり、送信元に設定された Webhook が情報を送信先へ送る仕組みになっています。 Webhook は時間ベースのスケジュールではなく、フォームの編集、ファイルの削除、ユーザーの作成など、特定のイベントが発生したまさにそのタイミングでトリガーされます。
技術レベルでは、Webhook は通常、HTTPS エンドポイントへの POST リクエストとして定義されます。匿名でアクセス可能であるか、単純なトークンまたはキーによって保護され、コンテンツの本文が JSON である場合があります。 POST の内容は、発生したばかりのイベント (以下の例を参照) に関連し、宛先はそのメッセージを受信し、独自のロジックに基づいてこれを処理します。 これらのメッセージは多くの場合、JSON ドキュメント (慣例であり、定義ではありません) であり、設計方法に応じて、情報の内容は限定的な場合もあれば、広範な場合もあります。
Webhook は一般的に効果的であると考えられていますが、絶対確実な統合方法ではありません。 これらは宛先エンドポイントに疎結合されているため、送信元システムからのメッセージが宛先に到達する保証はありません。 ネットワークの停止、エンドポイントの障害、メッセージ本文の構成が不適切であるなどの問題により、そのメッセージが届かなくなる場合があります。 つまり、Webhook は完全に信頼できるわけではありませんが、同じ信頼性の課題に悩まされる可能性のある他の REST API やエンドポイントと大きく異なるわけではありません。
機能としての Webhook は、通常、すべてのリクエストやインターフェイスの基本機能やプロセスとしてではなく、特定の目的のためにシステムやアプリケーションに追加されるのが一般的です。 これらは、Power Automate や Zapier など、通知または自動化に重点を置いた他のシステムに情報やイベントベースのメッセージを取り込むためによく使用されます。 Webhook リクエストは、カスタム Web サービスやエンドポイント、ArcGIS ジオプロセシング ツールに送信することも可能です。
Webhook に関連するその他の推奨事項や、Webhook の受信と処理のサンプル コードについては、Esri の webhook-samples Github リポジトリーをご参照ください。
Webhook 機能は、ArcGIS システムのいくつかの異なる部分で使用でき、ワークフローの関連付け、他のシステムへの統合、Webhook に含まれるデータを操作する関連イベントのトリガーに使用できます。 次のようないくつかの ArcGIS アプリケーションまたはシステムが Webhook をネイティブに使用しています。
ArcGIS Online の Webhook は、フィーチャ サービスのコンテキストで利用され、新しいフィーチャの作成や編集などの異なる条件に基づいて複数の宛先に Webhook を送信するように構成できます。たとえば、異なるエンドポイントが編集ではなく新しいフィーチャを受信することができます。 このブログ記事では、Webhook の作成方法と使用方法の例をいくつか紹介します。 Webhook の本文には、編集されたフィーチャのセットに関する情報が含まれており、リモート システムはこの情報を使用して ArcGIS Online にクエリーを送り返し、実際のトランザクションの変更内容を取得することができます。
ArcGIS Enterprise の Webhook は、ArcGIS Online と非常によく似た方法でフィーチャ サービスベースの Webhook もサポートしていますが、他のいくつかのパターンのも対応しています。 これらのフィーチャ サービスベースの Webhook は、ArcGIS Server Administrator Directory から構成されます。 フィーチャ サービスベースの Webhook を構成する方法の詳細については、Webhook の作成をご参照ください。
ジオプロセシング サービス Webhook は、ジオプロセシング サービス ジョブの完了時に実行され、ジョブの完了をリモート システムに通知し、ジョブの結果 (成功、失敗、または取り消し) とともに、リモート システムがステータスを取得するために使用できる URL を含めるように構成できます。 ジオプロセシング サービスの Webhook の内容については、ArcGIS Enterprise のドキュメントで詳しく説明しています。
このブログ記事では、フィーチャ サービスとジオプロセシング サービスの Webhook を併用して、作業管理システムで市民の報告ワークフローを自動化する方法の例について説明します。
ArcGIS Enterprise は、ArcGIS Enterprise デプロイメントのユーザー、グループ、コンテンツの変更によってトリガーされる組織の Webhook もサポートしています。 これらの Webhook は、特定のイベントの種類 (新しいグループの作成など) または多くのイベントの種類 (リモート システムがイベントを個別に解析して処理できるようにする) で実行されるように定義できます。
ArcGIS Survey123 と ArcGIS Field Maps はどちらも Webhook 機能をサポートしています。
Field Maps は、ArcGIS Online のホスト フィーチャ サービスを使用する Field Maps ワークフローの統合を容易にする Make.com 用モジュールを備えています。 詳細については、Field Maps の自動化をご参照ください。
Survey123 では、Make.com と ArcGIS Power Automate の両方に同様のワークフローが存在しますが、Webhook を手動で構成して、フィールド アプリケーション (データ収集時) または Survey123 Web フォーム (ブラウザー経由でデータを送信する場合) から宛先に送信できます。 詳細については、Survey123 Web サイトでの Webhook の構成をご参照ください。
他のシステムやワークフローとの統合をサポートするために、ArcGIS Workflow Manager では、Webhook を受信するエンドポイントを簡単に作成でき、外部情報に基づいてジョブを作成することが一般的です。 詳細については、Webhook を使用したジョブの作成をご参照ください。
Webhook がソリューションまたはワークフローで重要な役割を果たすシステムまたは統合を設計するときは、Webhook が正常に機能するための機能要件と非機能要件のいくつかを検討することが重要です。 これらの検討事項により、システム ユーザーと利害関係者は、システム内の Webhook の役割と、存在するあらゆる制約事項を適切に理解できます。