UN + ArcGIS Online: Stable View-Only Layer Workflow?

[jsarthur]

Has anyone cracked the code on creating stable view-only Utility Network layers in ArcGIS Online?

Our current setup publishes view-only services using a definition query (so the UN object itself isn’t exposed). I’ve tested a few approaches:

• Distributed Collaboration to copy the layers into AGO — functional, but the sync errors have been relentless.
• Referenced (non-hosted) AGO layers pointing directly to the AGE service URL — cleaner architecture, but ArcGIS Monitor is showing a lot of service instability and performance noise.

At this point I feel like I’m choosing between “sync chaos” and “ArcSOC roulette.” 😅

Would love to hear if anyone has found a more reliable pattern or workaround for supporting AGO apps / Hub sites with UN-related data without introducing constant maintenance headaches.

[RobertKrisher]

If you're interested in a view only copy, and your data is small enough, have you considered just copying the feature dataset out to a file or mobile geodatabase and uploading that?

If you're seeing specific errors with synchronizing/collaboration with a one-way collaboration, please open issues with support so we can get the process improved.

[jsarthur]

That's a great idea, thank you. I'll give this a try next. I have opened numerous cases with support when we run into the sync errors. The error I have seen the most is that the item already exists. We end up having to delete the item in AGO and resyncing, like @gis_KIWI4 mentioned, but that isn't sustainable for us.  We also see issues every time there is an AGO update. This issue tends to self resolve, but it usually takes a week or so, and we need more dependability.

[gis_KIWI4]

@jsarthur - We use distributed collaboration to send data to AGOL. It's been working well for us.
Our collaboration is set up one way (Portal -> AGOL). We send layers as copies. 
We didn't remove the UN layer or create any views, we just found that AGOL remove/hides it.
All other layers/tables show up on the other side ElectricDevice, ElectricLine, etc.

This is then used by our WebApps/FieldMaps and public facing maps.

We decided to use "copies" over "references" for 2 reasons - performance and accessibility (our enterprise is not exposed to the public) 

We have one workspace that copies the UN layers only. For other sources we left the UN one untouched and created other workspaces.

We had some teething sync issues but we found the best way to deal with them was to delete the layer in AGOL and run a manual sync to recreate the layers. The good thing with this is that it keeps the ID the same so if the layer is used in any maps/apps then it shouldn't require re-adding. 

Things that have caught us out in the past - 

1) changing schema in Enterprise/Portal breaks the collaboration
2) needs to have sync turned on
3) This one is weird, but we encountered adding other feature layers to the collaboration would break it even if one of the layers failed to sync. So we split the collaboration up into multiple workspaces. 

I wonder if there is anything in the logs you might be able to pull or there is any specific errors in the sync workspace. 

[jsarthur]

Thanks, @gis_KIWI4 for the detailed reply. I'm glad to hear it is more stable for you. I wonder if our experience is different because we are using the Water and Wastewater network domains as opposed to Electric. We recently upgraded to UN7, and the OID change to 64 bit was our final straw. We haven't been able to get ANY syncs to work since that upgrade, so I abandoned distributed collaboration, unfortunately. I have a support ticket open for that problem, but it just seems like something new always pops up to break our collab. 

[gis_KIWI4]

@jsarthur - I wouldn't have thought it would be the domains that would cause this. But your point around 64bit OIDs was interesting. We are using UNv6 and I think that could be the differentiating factor.