create_view works in ArcGIS Online, not from ArcPro

RandyMcGregor_BMcD

I have a notebook that creates views from user-specified hosted feature layers. The notebook works fine and until I updated to 3.4, the notebook could be downloaded and run from ArcPro. I have also made a python script tool with ArcGIS API for Python code that included create_view and until I updated to ArcPro 3.4 worked fine.

So, it appears as though this particular functionality will not work when run from an ArcPro project, either from a notebook or a script tool. It still works fine run from an ArcGIS Online-hosted notebook. Has anyone else experienced this? Is this a bug?

Creating services and applying metadata and settings does work from ArcPro. Again, appears to be a problem with create_view.

The error message is error:(unkown error), unfortunately. Three people have gotten the same error when activating this functionality from ArcPro (either as a downloaded notebook or python script tool). It's pretty consistent.

This is the code that creates the view. Pretty straightforward.

#
# 2. Create the view.
#--------------------------------------------------------------------------------------------------
new_view_name = Service_Title+"_View"
new_view_name = View_Name
arcpy.AddMessage("> Creating view "+new_view_name+"...")
new_view = flc.manager.create_view(new_view_name)

RandyMcGregor_BMcD

One more detail. A view is created. But it is incomplete. The next line in the code is an arcpy.AddMessage line, which does not run, so nothing after the create_view line is causing the problem.

NanaeAubry

You might have different versions of the Python API in each notebook environment. The best way to check what version you are running is:

```

import arcgis

arcgis.__version__

```

RandyMcGregor_BMcD

Yes. They are different. ArcPro is a higher number (2.4.0). I'm assuming I need to check with IT about updating the AGOL Python API version.

BobBooth1

If it works fine in an existing, older notebook in ArcGIS online, it is probably because the older notebook has an older runtime. Recent changes to the Python API would not be present in the older runtime.

The new version of Pro installed with a newer version of the API, so that's probably why the code doesn't work in Pro any more.

RandyMcGregor_BMcD

Thanks. I'm pretty sure that's what happened. I'm not well-versed in this aspect of notebooks. Do we need to update the Python API in ArcGIS Online? It's not 2.4. Our ArcPro is.

BobBooth1

If you want the notebook to keep working, do not update the runtime for the notebook.

If you want to make updates to the code so that it will work in Pro and the notebook, I'd suggest making a copy of the notebook in ArcGIS Online, updating the runtime for that copy, and then make your code edits.

That way you have a working version to use while the updated code is in development.

To change the runtime of a notebook, go to its item details page in your ArcGIS Online org.

Click the Settings tab.

Scroll down the page and click the drop-down list to choose a runtime. The latest version of the Python runtime for ArcGIS Online notebooks is 11.0

Click Save.

The new runtime will be applied.

RandyMcGregor_BMcD

Thank you. I do not get notifications for responses for some reason, even though I have set the setting to receive them. Sorry for the delayed response. I muddle through notebooks and get them to work through trial and error but am not knowledgeable about all areas of the system.

Sounds like my current notebooks are working because both the code and the runtime is out of date but when the same code is run from ArcPro the code is failing because the out of date code being run in the current version of ArcGIS API for Python (3.4).

I'll make a new '3.4' notebook, get it to work and then put that code into my arcpro python script tools.

I would like to give you credit for answering but I haven't verified yet. I'm 99% sure this is right. I'll give you credit as soon as I confirm this works.

Thank you very much,

Randy McGregor

RandyMcGregor_BMcD

in ArcGIS API version 2.4, 'preserve_layer_ids' defaults to 'True' and this is what was causing the problem. All I had to do was ADD 'preserve_layer_ids = False' to the code. We don't set create unique ids when we publish so when preserve_layer_ids defaulted to True, it broke.