Latest Contributions by KevinHibma

Interesting. If I use your URL, I get the same error. I did a little debugging/comparing to a PA url I have and outside of the webhooks, they function exactly the same, so I'm not sure what is different between the URL you have and the one I have. Inside PA, what does your request body JSON schema look like? Can you set it to something very basic, like: {     "type": "object",     "properties": {} } And ensure the method is either blank or set to POST? ... View more

If it's on, I've seen this happen once before and can't explain how it "fixed" itself. My suggestion is to turn the flow on / off (maybe Microsoft-Power Automate is in a bad state accepting incoming connections). If that doesn't allow you to create it, delete your When an HTTP request is received from the Flow and bring a new one in, save, make sure it's on, and get a new URL.   In both cases, take the URL and paste it into a browser and see that it returns some response, probably like  {"error":{"code":"TriggerRequestMethodNotValid","message":"The HTTP method for this request is not valid: expected 'POST' and actual 'GET'."}} ... View more

Make sure the Flow has been turned on. If the Flow is off, the receiver is unreachable, thus you cannot connect to it. ... View more

Thanks. That's sort of good news / bad news. I'm still skeptical the patch has caused the issue, but if you've only had the errors since applying the patch, it's now a question of how the communication was interrupted. I'll talk to a couple of colleagues and see if it's reproducible.  Unfortunately, you'll see the messages once a minute as Server attempts to re-establish the connection. Please respond back with the result of restarting Server. ... View more

Hi @DavidColey  I don't have much knowledge of that particular patch, but I'm doubtful that it caused the problem. The message is indicating that GIS Server is failing to connect to the required components for webhooks. Are you able to restart the GIS Server? A restart will sometimes fix this problem. Is there any chance the problem was there before you applied the patch and you didn't notice the logs? If so, we'd need to figure out what might be in the way of the connection. (closed ports perhaps) ... View more

Kim, I've attached a zip file with my progress on this. I'll note it's not quite complete, but offers the code you'll need to perform extract changes. (Specifically, I didn't complete the authentication to ArcGIS.com, the code assumes the service is publicly accessible). I'm trying to support both Online FS webhooks and Enterprise FS webhooks in the same script, so it needs to handle connecting to both. You'll want to start in the agol_receiver.py -- all this does is grabs a JSON value and launches the workflow. In production, this would act as the webhook receiver and handle requests in real-time, but for this, it's just the entry way to test. Inside extractChanges.py you'll see the basic workflow (start at the bottom).  I hope this helps. When I get it finished up, I'll add it to the previously mentioned github repo. ... View more

I'm getting webhooks sent from a couple of different Orgs/FeatureServices I have on arcgis.com. From your screen shot, you have Active:True and accepting any changes ("*"). So everything looks good.  ... View more

One other thing - would it be helpful if I added a Python sample for the Extract Changes workflow? Every so often I hear about this want, and I'd like to do it, but it falls off my priority list. It's possible someone has already written the code (so a matter of finding it), but either way, if it would be useful, I'd try to get it created as a sample in the mentioned repo. ... View more

@RogerAsbury  to answer your first question about getting the information from Extract Changes -- I'm not aware of any changes coming to this workflow. The webhook is purposely sent with what has been termed as a "skinny payload". Basically, a small payload without sensitive information inside. This is grounded in both performance and security reasons. I do sympathize that it takes a few steps to go back and grab what actually happened via the API. I'm glad you and @BlueBunnies have found the github samples. Debugging Azure can be challenging sometimes, but it looks like you found the real time console. My suggestion if things aren't making sense in Azure, switch the payload URL to some place like https://webhook.site/ This is a great resource for quick tests. It takes the code and complexity out of grabbing those payloads. ... View more

Hi Jack, I was working on this today and cannot reproduce the error you're seeing. I have my receiver setup to return "true" - you can note my copy/paste results below where the time stamps are all in the same second. I tried testing in a couple of ways -  1) Multiple browser tabs and setup to click save real quickly. 2) I put a breakpoint on my receiver, essentially it's up and running, but forced it to stop short of responding. I sent off a few triggers before cleaning the break point. I looked through our error messages, and I don't see something where we throw peer not authenticated. (I'm not saying it's impossible that's from Portal, I however couldn't find an instance of when/why we throw it). Is there any chance this is a message coming from your receiver? Do you get this with other receivers? Any chance you could setup a different one, or even a 3rd party service and perform the test. Reference: https://github.com/Esri/webhooks-samples    2022-06-10 09:04:03   true   {"success":"true"}       2022-06-10 09:04:03   true   {"success":"true"}       2022-06-10 09:04:03   true   {"success":"true"}       2022-06-10 09:03:42   true   {"success":"true"}       2022-06-10 09:02:51   true   {"success":"true"}       2022-06-10 09:02:51   true   {"success":"true"}       2022-06-10 09:02:33   true   {"success":"true"}       2022-06-10 08:57:20   true   {"success":"true"}       2022-06-10 08:57:20   true   {"success":"true"} ... View more

Hi - I'm trying to understand the workflow. Do you have more than 1 webhook created that would be listening to groups? Or is there just a single webhook, but your receiver is responding to the webhook and performing actions on the group which cause that same webhook to fire again.  If you have a 2nd webhook configured, what events is it listening for? Just group, or "*", or? I haven't seen the error you've mentioned, nor did I have any luck trying to reproduce it. However, I'm not sure I've set my test up in the same way you have yours. ... View more

Ok, that gets us somewhere. I'm guessing its probably a licensing issue. One more test? The following will capture and exception caused by trying to import arcpy. Hopefully this provides a helpful message to see whats going on. f = open("c:/temp/output.txt", 'w') f.write("this is before arcpy \n") try: import arcpy f.write("arcpy imported\n") except Exception as e : f.write(str(e)) f.close() ... View more

Hi Shelby, I was made aware of the fact that yes, indeed there is a difference between 1.4 and the upcoming release of 2.0. You cannot perform the export from a scheduled task. This is documented here: “ If you create a task to run when the user is logged off of the Windows machine, then the Layout Class export functions (for example, exportToPDF) and the Bookmark Class updateThumbnailfunction will not work. These functions require a user to be logged on to Windows in order to work”   http://pro.arcgis.com/en/pro-app/arcpy/mapping/guidelines-for-arcpy-mapping.htm They've overcome this for 2.0, thus you should be able to export from a scheduled task. Now that said...the fact you can't run the test script I gave you (of running a gp tool)...that narrows down the problem a little bit. Could you update it to run this? If this does not create a text file with anything, not even "this is before arcpy"...then this has nothing to do with licensing or arcpy and its something to do with running python through your scheduled task. If it creates the textfile and outputs some lines...well depending how far it gets, that tells something else. f = open("c:/temp/output.txt", 'w') f.write("this is before arcpy \n") import arcpy f.write("this is after arcpy \n") p = arcpy.mp.ArcGISProject("C:\\arcgisserver\\documents\\GPService\\ProGPPDS.aprx") maps = p.listMaps()[0] layers = maps.listLayers()[0] f.write("this is before the tool\n") gc = arcpy.GetCount_management(layers) f.write(gc.getMessages()) f.close() I realize your final goal is to export from a scheduled task. As mentioned, unfortunately you wont be able to do that in 1.4. But we can continue to troubleshoot and try to figure out why you cant run a simple scheduled task. If you get that figured out, then once Pro 2.0 is available you'll be set to export. ... View more

Being in the administrators group should be enough - that is how I do it. You've said "it doesn't work". Maybe we need to explore what that means - whether the task is being run and failing, or whether the task doesn't run at all. Could you take the following code and turn this into a schedule task? You'll need to update the path to a project that exists, with a map and has a single layer. The thought here is, you'll get a text file with the messages from the get count tool. If that works, you know there is no license problem and the schedule task work - its a problem with the export. Otherwise if this fails to produce a txt file, then it could still be a license problem. At that point I'd check to see what messages you have in the event viewer or the task scheduler itself. import arcpy p = arcpy.mp.ArcGISProject("C:\\arcgisserver\\documents\\GPService\\ProGPPDS.aprx") maps = p.listMaps()[0] layers = maps.listLayers()[0] gc = arcpy.GetCount_management(layers) f = open("c:/temp/output.txt", 'w') f.write(gc.getMessages()) f.close() ... View more