Changing hosted Feature layers with Power automate and Rest APIs

2255
3
Jump to solution
02-15-2022 03:08 PM
by Anonymous User
Not applicable

This isn't a question, but during my creation of this hydrant meter solution I found there wasn't a lot of helpful documentation on REST APIs through power automate using addFeature, updateFeature, and update Geometry and even querying features. I want to explain why things are the way they are because I had to piece all of this from various sources and even just plug and chug to figure all of this out.

This will go through how the field workers do a simple survey to update where the hydrant meter is and how it automatically updates the hydrant meter location on the map on the correct fire hydrant. 

  1. the first thing that we did was create a survey on survey123 which will end up getting the hydrant meter number, the number fire hydrant, the usage
  2. In power automate create a new flow that is triggered when a survey response is submitted.                      AnnaBonczynski1_0-1644966410251.png

     

  3. The first thing you need to do in the flow is generate a token. This essentially logs you into your GIS every time you run the flow so you can access your data. You need to add a HTTP to the flow. This will be needed any time you want to use a rest api in power automate. The method is Post, the URI will be https://www.arcgis.com/sharing/rest/generateToken, the Headers will be “Content-Type” and “application/x-www-form-urlencoded”, and the Body will be username={your username}&password={your password}&f=json&referer=http://www.arcgis.com    AnnaBonczynski1_1-1644966410253.png

     

  4. In order for this to be useable in the dynamic content later we have to add parse json to the flow. The Content will be the body of the HTTP for the token and the Schema will be

{

    "type": "object",

    "properties": {

        "token": {

            "type": "string"

        },

        "expires": {

            "type": "integer"

        },

        "ssl": {

            "type": "boolean"

        }

    }

}

AnnaBonczynski1_2-1644966410255.png

5. The survey told us which Fire hydrant number the hydrant meter is at, so in order to figure out the lat and long of the fire hydrant we have to do another HTTP step. This time the method will be Get since we are just getting the geometry of the queried fire hydrant. The first portion of the URI, “https://services5.arcgis.com/KkzTh8g0dTwlw3DH/ArcGIS/rest/services/Fire_Hydrants/FeatureServer/0” is the first part of the feature service url. The “query?where= “ is indicating you want to query that Feature and immediately after is the field you are searching by. Im not sure why you need the +%3D+ but you do, and then what you are looking for. My flow is searching the fire hydrant number that was in the survey. Note: if you it is a text field you need ‘’ if it is a text field but you don’t need it if it is a number field. &returnGeometry=true since we are trying to locate the lat and long of the fire hydrant and it always needs &f=json&token= and then the token generated from the parse json from the previous steps in the dynamic content.AnnaBonczynski1_3-1644966410257.png

 

  6.Again we need to parse the query in order to get a useful lat and long that we can use in the dynamic content. First you need to save and test the flow. Then copy the body of the query. Go back into editing the flow and add another parse json. The body of the query HTTP will be in the Content and then press the “generate from sample” button. Paste the body that you copied form the test and press done. It should automatically put the schema needed.AnnaBonczynski1_4-1644966410258.png

7. Next we query the Hydrant meters to depermine what the objectID is for hydrant meter they submitted the survey for. The last two steps were repeated but with the meter number instead of the fire hydrant.

8. Now to update the hydrant meter feature. This will be another HTTP step, but this method is POST. The URI is again the first part of the feature service url of the feature you are updating with /updateFeatures at the end. Headers will again be “Content-Type” and “application/x-www-form-urlencoded”, and the Body will always start with f=json&token={the token}&rollbackOnFailure=true&features={. Since we are updating the geometry is being updated we start with "geometry":{geometry dynamic content from the fire hydrants},

"spatialReference":{"wkid":102100},

NOTE: if you are not wanting to change the geometry you can skip straight to the “attributes”:

the features will only be able to update by using the objectID, just make sure that is it exactly how the field is named. Additonally you only need the fields you will be changing. The rest of the field will stay the same. Again if the field is a text field you need a ‘’ around it and if it’s a number field you don’t

it will most likely add an APPY TO EACH once you add some of the dynamic content, just leave it.

 

AnnaBonczynski1_5-1644966410261.png

9. This wasn’t in this flow but if you wanted to add a feature instead of updating a feature you would do the same thing as number 8 but it would be /addFeatures and you wouldn’t need to put the object ID.

I hope this was clear and helpful for anyone else who is trying to do something similar but is having a hard time finding documentation!!

1 Solution

Accepted Solutions
DavidMcClennen
New Contributor III

Very well done Anna, this will be tremendously helpful to our organization and can be applied to other workflows as well!

View solution in original post

0 Kudos
3 Replies
DavidMcClennen
New Contributor III

Very well done Anna, this will be tremendously helpful to our organization and can be applied to other workflows as well!

0 Kudos
JamesWilson2
New Contributor III

This has been driving me nuts for week. I could get data out and could not get it back in. I have tried passing a bearer token in the header and got a 'Token Required' error.
I used your syntax on the HTTP POST and it works like a dream. Thank you for finding a solution and writing about it so clearly!
@IsmaelChivite can you add this information to your No-Code workflow automation with ArcGIS Survey123 (Directions Magazine) (esri.com)?

0 Kudos
ctalleygreenville
New Contributor III

Thank you for posting this.  Items 3,4, and 5 helped tremendously in solving my issue with attempting to download .pdfs from a public Survey123 in our flow using HTTP in the "Apply to Each" to download the .pdf attachments.  

What was happening was that the token returned using the PortalInfoToken in the HTTP action was returning and empty string for public users (no AGOL permissions) but would work perfectly for someone who was actively logged into our organization when running the survey.  The result was that the .pdf would not download. The output of the HTTP indicated "there are no attachments to download".  However, the flow would show as "succeeding" in PA.  It wasn't until a user told us the .pdfs downloaded didn't work that we found the issue.  

Solution - Adding the items in 3-4 and using the "token" output  from the "Parse JSON" action in the Apply-To-Each's embedded HTTP action worked (at least after the first 5 tests).   

Thanks again.

 

 

0 Kudos