Hi Utility Network,
We are trying to understand the best practice advice for handling field visibility in the Web for Utility Network Services.
In ArcGIS Pro we have configured our data into subtype group layers and as part of this have altered the field visibility inside of the subtypes in order to only show applicable fields for our network assets (a number of fields are set to not visible).
We have noticed that when publishing a hosted version of our service with branch versioning that this results in an error that prevents publishing: 00302: All fields in datasets with <value> must be visible: field <value> in layer <value> is not
Ideally we want any client working with the hosted service to be able to inherit the correct field visibilities from the service, otherwise we will need to configure every location where the service is used to re-set this information which is a major configuration overhead….
Has anyone encountered this issue? Is there any guidance on how best to handle field visibility?
We have encountered this issue as well when trying to publish. Our "work around" is to publish the service with all fields visible and then use the Editor Template that comes with the Esri solution to control field visibility. The real push needs IMO needs to be for the ability to publish subtype group layers--that limitation is indeed huge. We have also published services based off the UN for field editing and spent a tremendous amount of time configuring the individual services after they were published. We also encountered issues when building a def query to limit asset groups/types -- the web map doesn't display domain descriptions--just the codes.
I wish I had a better answer--I hope someone does. We have seen this and always plan for a sufficient amount of time to configure pop ups and field visibility in the web map/service.
Thanks Randall, its useful to know that this is a challenge that others share! It would be useful if the ArcGIS Pro publishing process could ignore field visibilities, but store them somewhere in the hosted service that is created.
After posting this I had a look at a semi-programmatic solution to the issue. I built a simple script that parses an ArcGIS Pro map file (which is essentially a json file) and extracts out all of the field visibility settings for the fields in each of my subtype group layers. I then apply this to a webmap/application definition and overwrite the portal item data.
The process has some manual parts due to the requirement due to having to physically match up some of my map file layers and the layers that are in the portal item.
Your question is quite valid and there is no easy answer. With the under-normalised data model prescribed for the Utility Network, there should be some tools available to configure field visibility etc. Ideally, applicable fields should be configurable at the subtype (assetgroup) level just like domain names and default values. e.g. it is logically incorrect to display "Winding Type" for all devices when it is applicable only to a "Transformer" device. Other option is to provide relationship table at a subtype level e.g. TransformerAttributes as a related table only for Transformer subtype/assetgroup. We can then keep bare minimum attributes at Device/Line/Junction/Assembly level and all other attributes can be set as related tables for specific subtype.
Your question is not unusual, Jonathan. Working with UN services is a bit of a paradigm shift with respect to how we look at geospatial services. As you discovered, you must expose all of the fields with your UN service if your intent is to access the service with Pro. If your intent is to publish without the UN service, the restrictions are lessened. The link below is very informative about this topic:
Could you please post the link that talks about hosted services having branch versioning capabilities. This sounds really interesting. Thanks
I think this is what you are looking for https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/publish-branch-versioned-da... .