nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Najděte více příspěvků označených jako

Accepted answers

All comments

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.

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

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.

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.

jsarthur

@RobertKrisher - I plan to follow your advice and set up a read-only copy of the UN database. I have a few questions for you:

For a read-only copy of Utility Network database, would you recommend keeping the data non-versioned since no editing will occur?
What is the preferred method for keeping the data synchronized with production: geodatabase replication, delete/append, or another approach?
If the database will only be used for map display and not Utility Network analysis or tracing, is there any reason to copy the Utility Network object itself, or would it be acceptable to only maintain the feature classes needed for visualization?

Thank you!

RobertKrisher

@jsarthur There is a lot of nuance, pro/cons to the questions you are asking that you're going to have to work through. The easiest, most reliable, and often fastest way to move a whole dataset is by doing a database backup/restore. This creates a 1:1 duplicate of your database.

You can also use feature services to synchronize data, python scripts, FME workbenches, etc. But you'll need to find the right approach that meets your requirements of complexity to implement/maintain, performance (of transfer and final system), and functionality of the final system.

As you pointed out, if you are just trying to view and query data in this other system, you don't need to bring over the utility network. But if you do bring over the utility network, the data will need to be versioned.

jsarthur

@RobertKrisher Great, thank you so much. I was also thinking of deleting all of the attribute rules in the view only version of the database to keep the data as simple as possible. Do you know any reasons why this would not be a good practice? I don't think it would create any issues, since we aren't editing this new copied dataset, but just wondering if you had any experience with this. Thanks so much for your feedback!

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.