Webhooks are an ArcGIS Enterprise capability that automatically provide webhook receivers or other applications with event driven information. ArcGIS Enterprise supports two types of webhooks:
- Organization webhooks—Administrators can subscribe to event triggers pertaining to an organization's users, groups, and items.
- Service webhooks—Administrators can subscribe to webhooks for geoprocessing and feature services.
- Geoprocessing webhooks—Administrators can set geoprocessing service webhooks to be invoked when a geoprocessing service job is completed.
- Feature service webhooks—Administrators can subscribe to event triggers pertaining to an organization's feature services.
All ArcGIS Enterprise webhooks follow a similar process. Once the webhook is triggered, event information is delivered in a JSON schema containing relevant information, specific to each webhook type. Each webhook type has specific events that they can subscribe to. For example, organization webhooks can be invoked when an item was published or when a new user account was created. Feature service webhooks can be triggered when a feature layer's schema has been modified. Geoprocessing service webhooks only deliver event information when a geoprocessing service job has completed.
With the event information delivered, the receiver platforms perform a specific action that notifies organization members and administrators of the event. Depending on the needs of the organization, this can be sending emails to specified members or messaging administrators in Slack.
Because webhooks provide notifications once an event occurs, it can be more effective than polling. Unlike polling, webhooks do not require applications to keep checking the system to see if a specific event has occurred.
Scenario: Organization webhooks
Consider a scenario where an ArcGIS Enterprise organization has a set of specific standards that each item must meet before it can be shared publicly. Administrators in this organization want to create a workflow that allows them to respond in real time when an item has been shared that doesn't meet their standards. They want to leverage webhooks to notify them when an item owner has shared their item publicly, and use the event information in the payload as part of a script that will message the administrators specifically if that item doesn't meet their standards, giving administrators a chance to update the item or unshare it from the public.
The list below outlines how webhooks can be leveraged by the organization administrators to create this workflow:
- The organization administrators set up the webhook receiver to write incoming payloads as local text files.
- The administrators create a Python script that parses the payload text file to extract relevant information about the item and the operation performed. The same script allows administrators to respond to this information by sending a notification to a designated Slack channel. If an item is shared publicly but doesn't meet public standards, the script uses the Slack API to send a message outlining the missing or incorrect information to organization administrators.
- Once the script is created, administrators create a webhook that will trigger when an item owner shares their item.
- When an item is shared, the script will parse the payload text file and determine if the item was shared publicly or within the organization. If shared within the organization, no additional action is taken. If the item is shared publicly, the script will grade the item based on the organization's set standards. If the grade is low (meaning that public standards aren't met), administrators will be notified in their Slack channel about which item was shared and which of its metadata isn't currently meeting standards.
- An administrator for the organization can then respond by either updating the metadata to meet standards, choosing to unshare the item, or messaging the item owner to have them make the needed changes, directly from Slack.