Enable option to retain attribute table configurations across distributed collaboration

Y_Maree

I'm using distributed collaborations to share copies of hosted feature layers from ArcGIS Enterprise to ArcGIS Online.

When I update the field alias (display name), field description and field value type of the portal item in ArcGIS Enterprise (using the data tab), only the field alias persists in the copied item in ArcGIS Online if I share it to the collaboration group.

I would like for all the configurations (field aliases, descriptions and value types) in the portal item in ArcGIS Enterprise, to persist in the copy in the receiving portal.

• Is it possible to make this an optional enablement so that all the changes carry over, not just the field alias?

Table view in ArcGIS Enterprise

For items already shared via distributed collaboration:

• Ideally, this would work for items that already participate in a distributed collaboration. I've noticed that the field alias passes through to the item in the receiving portal (ArcGIS Online) when I add an item to the collaboration group. However, this is not the case if the item is already shared.

 

• For items that are already shared via distributed collaboration, not even the field aliases carry over if I add them to the portal item in the sending group. For example:
  • I have a hosted feature layer that is collaborated from my Enterprise portal to my ArcGIS Online organization using distributed collaboration.
  • I update the attribute table in the version in ArcGIS Enterprise (sending group) with field aliases, descriptions and value types.
  • No change appears in the corresponding item in ArcGIS Online (receiving group).
  • I try editing the item details e.g. description in the ArcGIS Enterprise version. The updated description appears in the corresponding item in ArcGIS Online but the attribute table does not reflect any of the changes I made.
  • The only way I've been able to get the field alias to pass through is to un-share the item and re-share it through the distributed collaboration. I would prefer not to do this since my item has dependencies.
  • Ideally, I would also like the field descriptions and value types to also pass through in this case, too, not just the field alias.

Below is the table view in ArcGIS Online 

Table view in ArcGIS Online

Previous post about this: Field descriptions and value types do not persist ... - Esri Community

CalvinHarmin

I suppose the key phrase here is schema changes. This includes field changes (add, delete, alter fields), any domain changes, etc.

These are not replicated after the Enterprise (Portal) hosted feature layer is shared, if initially shared with distributed collaboration workspace that is not set to 'reference' the Portal hosted feature layer, but rather creating a replicated copy of the hosted feature layer in ArcGIS Online. Does that sound correct? I guess it can be confirmed by looking at the service URL of the hosted feature layer item on AGOL side.

If that's correct, I wonder if it is possible to simply 'reference' the Portal hosted feature layer rather than make a copy on AGOL side? Or do you need the AGOL to have a copy for purposes of external users hitting the AGOL servers, rather than users directly hitting your local Portal/Enterprise Server (through the AGOL reference)?

I imagine having the option of replicating schema changes to between a source Portal hosted feature layer and an AGOL copy through distributed collaboration would be a significant change. If we think about it as a hosted feature layer being essentially a feature class in a postgres database in the backend, analyzing every sync for schema changes would entail more computes to do comparisons of every field, every domain, etc, every time it syncs. As it stands, I think globalid's of features are the primary key for the replication process and I have to assume edit/update/delete checks for features... I guess that's still fairly compute-intensive... but I also assume database indexing of just two or three fields makes it pretty efficient, and it doesn't care if your source schema doesn't match the replicated schema, it'll just append the values that it has matching fields for and ignore the rest. Schema change analysis may be less efficient and entail a wholly different set of processes when it does find changes? I'm just thinking out loud about the rationale that while schema updates can be done, it might entail a lot more compute power en masse for this part of the AGOL cloud infrastucture and maybe that's why it hasn't been implemented?

I'm kind of rambling... all that said, I would absolutely welcome this capability, and in my case I am interested in replicating schema changes from Feature Services in Portal as well (that create a hosted feature layer copy on AGOL). Removing a share and re-sharing to recreate the hosted feature layer copy is not ideal, however I did notice from brief testing that, fortunately, the AGOL hosted feature layer service URL does not change and the item ID's match between Portal and AGOL. So if you focus on only making metadata changes on the Portal side (summary, description, tags, etc), then you wouldn't have to recreate them on the AGOL side.