How to determine Version Name from OnPost WebHook

[geovolve]

Hi all,

This post is an extension to the following post, but creating a new one as the topic has changed

https://community.esri.com/t5/arcgis-utility-network-questions/un-and-onpost-event-webhooks-should-t...

We have implemented a process that identifies the edits from an OnPost Webhook from a branch version and we're able to successfully extract the data from the webhook. However, how do we determine what version name was used to generate the OnPost trigger?

We want to identify the version name (which aligns with an as-built edit process) so that we can follow workflow processes.

Cheers,

[gis_KIWI4]

@geovolve - Haven't found a way of finding out which versions the changes are originating from. The webhook payload doesn't expose that.

You can use differences capability to compare different versions to find out what the changes are but this needs to be done before posting. Once posted, the information about versions is lost.

Which got me thinking, you could have a attribute rule that writes the version details against the object that was changed. This should be available as an attribute via the webhook->extract changes process in the previous post.

GdbVersion($feature)

https://community.esri.com/t5/attribute-rules-videos/use-gdbversion-to-return-the-current-version-be...

It looks like it returns the Name of the version not the GUID. You might need to make another to version management endpoint to get the version GUID if needed. 

[geovolve · Accepted solution]

Yeh thanks @gis_KIWI4 that was the workaround that we had implemented but its not very elegant.

Looking at Robs comment below, I guess we'll raise it as a feature request.

[RobertKrisher]

If you haven't already, log an issue for this. Its either a bug or something that would be a good feature. Not including the version name in the on post message to the web hook seems like a good idea.

[geovolve]

Thanks @RobertKrisher  I'll log a feature request.

[RobertKrisher]

Ok, having talked to a few people internally about this I see what's happening. The FeaturesPosted web hook doesn't trigger whenever a version is posted, instead is uses the schedule associated with the web hook to identify all the features that have been modified in default since the last time the web hook was run. This means that it can include edits from multiple versions being posted (or edits made directly against default). While this has its own important use cases, it is not what you're looking for, and it explains why we can't include the version name.

Having a web hook that includes the version name would require us to create a new EventTrigger that fires every time a version is posted (which is why the naming of the existing trigger is unfortunate). The upside is that you would get the version name, the downside is that you wouldn't have a way to detect other changes made to default (i.e. direct edits).