Using Deployment Hooks in VertiGIS Studio Web and Mobile Designers
Featured
Web and Mobile Designers have the ability to invoke a webhook when deploying an application to a deployment environment. This can be any webhook service you desire.
This article will use VertiGIS Studio Workflow Server to receive the webhook request; a common pattern for VertiGIS Studio customers.
To begin, we create a new VSWF server workflow using the Receive Webhook Request sample
This sample takes care of retrieving the workflow inputs and parsing the JSON inputs into a structure that is ready to use.
Once saved, this workflow is accessible at an endpoint that includes your workflow server name and the workflow ID.
https://<server>/vertigisstudio/workflow/service/webhook/survey123/<workflow-id>
e.g.
https://qabugzoo.com/vertigisstudio/workflow/service/webhook/survey123/737b8bdc87d146cb941dc2ea80d40812
This VSWF server pattern for receiving webhook requests was originally created for Esri’s Survey 123 product. See docs. In the future a more generalized URL will be provided.
In VSW Designer setup the Deployment hooks to use this new URL.
Once configured, every time you deploy an application to Testing or Production this webhook will be invoked with a JSON data payload
{
eventType: "mobile.deployment" | "web.deployment",
createdDate: ISODate
portalInfo?: {
url: string,
token: string
},
data: {
comment?: string,
sourceItemId: string,
targetItemId: string,
sourceEnvironment: "dev" | "test" | "staging" ,
targetEnvironment: "test" | "staging" | "prod",
deployedBy: {
fullName: string,
userName: string,
},
dependencyChanges: {
addedDependencies: string[]
removedDependencies: string[]
updatedDependencies: string[]
},
}
}
In our example, the Server VWSF can now use this data to perform whatever tasks are desired.
Here is an example that extracts some of the data in the parsed JSON object and writes it back out as text.
Text*
=`Event Type: ${$parseJson1.result.eventType}
Created Date: ${$parseJson1.result.createdDate}
Portal Info: ${$parseJson1.result.portalInfo.url}
Source Environment: ${$parseJson1.result.data.sourceEnvironment}
Source Item ID: ${$parseJson1.result.data.sourceItemId}
Destination Environment: ${$parseJson1.result.data.targetEnvironment}
Target Item ID: ${$parseJson1.result.data.targetItemId}
Deployed by: ${$parseJson1.result.data.deployedBy.userName}
Comment: ${$parseJson1.result.data.comment}`
When output to a file, or a log:
Event Type: web.deployment
Created Date: 2022-07-26T21:09:51.520Z
Portal Info: https://www.arcgis.com
Source Environment: dev
Source Item ID: 4279a9e818b840229f27eeed951d24a2
Destination Environment: test
Target Item ID: 65c5bb35bc40463b8ed7740ff3c0feed
Deployed by: cbarnard
Comment: test comment changelog abc
-
Mike Diss-Torrance ... you asked about this, put together some additional information for you.
1 -
Thanks for sharing this, Cam!
Tangential to this topic, while at the EUC I had a customer ask whether we could integrate a VSW deployment pattern with a git repository. I don't have direct experience with this, though I've noted that there is a well-documented github webooks API that may serve well for that use case.
0 -
Now that you have these 'hooks' on application deployment events, the portal information, and the item ids, you can fulfill a number of use cases that have come up.
- Updating server-side resources like databases
- Creating a persistent changelog for your app
- E-mail notifications about updates to apps
- ... and yes if you mix in the Esri python API you could grab items from the portal and stash them in alternate locations for backup or source control like git
1 -
Can I suggest having a Tech Tip video on the use of deployment hooks? It would be very useful to see how these could be set up and used.
1
Please sign in to leave a comment.
Comments
4 comments