Webhooks dans ArcGIS Enterprise

Un webhook est une fonctionnalité de ArcGIS Enterprise qui fournit à des récepteurs de webhook ou d’autres applications des informations liées à des événements. ArcGIS Enterprise prend en charge deux types de webhooks :

• Webhooks d’organisation : les administrateurs peuvent s’abonner à des déclencheurs d’événement liés à des utilisateurs, des groupes et des éléments d’une organisation.
• Webhooks de service : les administrateurs peuvent s’abonner aux webhooks de services de géotraitement et d’entités.
  • Webhooks de géotraitement : les administrateurs peuvent définir des webhooks de service de géotraitement à appeler une fois qu’une tâche de service de géotraitement est terminée.
  • Webhooks de service d’entités : les administrateurs peuvent s’abonner à des déclencheurs d’événement liés aux services d’entités d’une organisation.

Tous les webhooks ArcGIS Enterprise suivent un traitement similaire. Une fois le webhook déclenché, les informations liées à l’événement sont livrées dans une structure JSON qui contient les informations pertinentes, propres à chaque type de webhook. Chaque type de webhook comporte des événements spécifiques auxquels il peut s’abonner. Par exemple, les webhooks d’organisation peuvent être appelés à la publication d’un élément ou à la création d’un nouveau compte utilisateur. Les webhooks de service d’entités peuvent être déclenchés lorsque la structure d’une couche d’entités est modifiée. Les webhooks de service de géotraitement livrent uniquement les informations liées à un événement une fois qu’une tâche de service de géotraitement est terminée.

Une fois les informations liées à l’événement livrées, les plateformes de récepteur effectuent une action spécifique qui avertit les administrateurs et les membres d’organisation que l’événement a eu lieu. En fonction des besoins de l’organisation, il peut s’agir d’e-mais envoyés à des membres spécifiés ou de messages envoyés aux administrateurs via Slack.

Étant donné que les webhooks envoient des notifications une fois que l’événement s’est produit, ils peuvent être plus efficaces que l’interrogation. Contrairement à l’interrogation, les webhooks ne demandent pas à des applications d’interroger le système pour savoir si un événement spécifique s’est produit.

Scénario : webhooks d’organisation

Prenons l’exemple d’un scénario dans lequel une organisation ArcGIS Enterprise possède un ensemble de normes spécifiques que chaque élément doit satisfaire avant de pouvoir être partagé publiquement. Les administrateurs de cette organisation souhaitent créer un processus qui leur permet de répondre en temps réel lorsqu’un élément est partagé alors qu’il n’est pas conforme à ces normes. Ils souhaitent utiliser des webhooks pour être avertis lorsque le propriétaire d’un élément partage un élément publiquement, et utiliser les informations de l’événement de la charge utile dans un script qui envoie un message aux administrateurs si cet élément ne répond pas à leurs normes, afin de pouvoir mettre à jour l’élément ou d’annuler son partage public.

La liste ci-dessous indique comment les administrateurs d’une organisation peuvent tirer parti des webhooks pour créer ce processus :

• Les administrateurs de l’organisation configurent le récepteur de webhook de telle sorte qu’il écrive les charges utiles entrantes sous forme de fichiers texte locaux.
• Les administrateurs créent un script Python qui analyse le fichier texte de charge utile afin d’extraire les informations liées à l’élément et à l’opération effectuée. Ce même script permet aux administrateurs de répondre à ces informations en envoyant une notification à un canal Slack désigné. Si un élément partagé publiquement ne répond pas aux normes relatives au partage public, le script utilise l’API Slack pour envoyer un message indiquant les informations manquantes ou incorrectes aux administrateurs de l’organisation.
• Une fois le script créé, les administrateurs créent un webhook qui se déclenche lorsque le propriétaire d’un événement partage son élément.
• Une fois l’élément partagé, le script analyse le fichier texte de la charge utile et détermine si l’élément a été partagé publiquement ou au sein de l’organisation. Si le partage a eu lieu au sein de l’organisation, aucune action supplémentaire n’est effectuée. Si l’élément a été partagé publiquement, le script attribue une note à l’élément en fonction des normes définies par l’organisation. Si la note est basse (ce qui signifie que les normes publiques ne sont pas respectées), les administrateurs sont notifiés via leur canal Slack ; l’élément partagé est identifié, ainsi que les métadonnées associées qui ne répondent pas aux normes.
• Un administrateur de l’organisation peut alors répondre en mettant à jour les métadonnées afin de les mettre en conformité avec les normes, en annulant le partage de l’élément ou en envoyant un message au propriétaire de l’élément lui demandant d’effectuer les modifications nécessaires, directement à partir de Slack.