Can we use portal collaboration to update existing hosted features

591
5
06-06-2023 09:02 AM
Labels (1)
Ken_Doman
New Contributor II

We have open data content published as hosted feature services through ArcGIS Online. The data is generated through a notebook script and uploaded periodically. A year after setting up that workflow, we recently upgraded our ArcGIS Enterprise system to 10.9.1. We have experimented a bit with setting up collaborations between the two environments.

We would like to generate our open data within our enterprise environment, and use a collaboration to sync the data to ArcGIS Online, where it would be published as a read-only hosted feature layer. Is there a way to set up or modify a collaboration sync so that a new item on the guest portal updates a pre-existing item on the host portal? We don't want to lose the usage history for the existing open data.

0 Kudos
5 Replies
DavidColey
Frequent Contributor

Hi Ken - When you ask - 'Is there a way to set up or modify a collaboration sync so that a new item on the guest portal updates a pre-existing item on the host portal? " - The short answer is yes, but it depends on the type of collaboration you want to use and that's based on your data update workflows.

For us, editors update SDE layers, those layers are extracted to a file gdb each week.  The file gdb layers are shared to our enterprise portal as hosted feature layers from the arcpro sharing module / api.

Each week python scripts overwrite the service definition files, updating the hosted feature layers in portal. The layers are then shared to groups that make up the guest portal workspaces for by-reference collaborations, where our guest portal sends the layers to our agol host.

On our agol host, the groups (workspaces) that receive the content from portal are shared with Open Data, and in this way we update data in Portal, it is seen in Open Data.

In fact, once the layers are in place, the by-reference collaborations don't even need to sync in order to see data updates to the layers in the host org because they are just pointing back to our Portals' hosted server site.

There is an 'as-copies' method too that works best with send-receive types of workflows to keep the data updated.  In this case, you would share a view of the agol layer with an Open Data group....

Hope this helps-

David

0 Kudos
Ken_Doman
New Contributor II

The workflow you describe is the one I want to set up, except I want AGOL to have copies of the data instead of references to our portal server, to reduce network traffic on our servers. 

My issue is that the copied data on AGOL existed before we set up the collaboration between it and our production portal. When I create the file geodatabase on portal using the collaboration, can I tell AGOL to use the portal data to update an existing AGOL item in the collaboration, or will it always create a new AGOL item?

The existing AGOL items have usage history attached to them that I don't want to lose.

0 Kudos
DavidColey
Frequent Contributor

Well, to me its about your editing workflows.  If you are only going to be editing your portal layers as portal-hosted feature layers where edits to layers aren't coming from SDE, then you could set up the collaboration type 'as-copies' and the mode as 'send'.  This way, the edits will appear in your AGOL host at whatever interval you define.  

That being said, if I were setting up 'as-copies' collaborations, it would be because I want to support two-way editing of my feature layers.  But again, it really depends on the scenario:

 https://enterprise.arcgis.com/en/portal/latest/administer/windows/understand-collaborations.htm

I also think that layers as-copies requires more management overhead:

https://enterprise.arcgis.com/en/portal/latest/administer/windows/about-sharing-feature-layer-data-a...

If you are worried about the agol usage history, delete the layer from portal.  Then set up a send-receive collaboration with the layer from agol 'as-copies'. When the workspaces sync, the agol layer will be sent to portal as a new copy.  But the portal copy won't retain the agol usage, it can't but the usage history will still show in the agol 'source'.

0 Kudos
VanessaPocock
New Contributor III

Can I ask either of you, as I'm having trouble getting information about this online. For your hosted feature layers (HFL) (either in portal or AGOL) are you publishing every feature class to its own HFL, or are you publishing a group of feature classes together to a single HFL and then serving that up to the Open Data Content group? I ask because that latter doesn't allow for layer level metadata in Portal/AGOL, which means we'd have to make hosted views of every individual layer in an HFL with many layers. 

I realize I'm piggy-backing off this chat so any help would be great. 

Thank you,
Vanessa

Ken_Doman
New Contributor II

I don't mind the piggyback. For some of our layers that group together logically, we currently group those together in a file geodatabase and publish them as a single hosted feature layer. For instance, we have fire station locations, and boundaries on the same hosted feature layer. It works if the data is parts of a whole, and you don't expect it to be picked apart.

There's a possibility we need to re-evaluate our metadata standards, to make sure we're not missing anything important. We're not publishing separate hosted views on each individual layer right now, but that time could come.

0 Kudos