Dirty Areas in Utility Network with Experience Builder but not Pro

382
3
11-03-2022 07:58 AM
CarlSunderman
Occasional Contributor

I am trying to create a Utility Network app in Experience Builder and have come across something weird. In Experience Builder, when I close a valve (edit the valve featureclass to close) and try to run a trace, I receive a dirty areas error, yet if I do the same thing in Pro, with the published Feature service, I get no errors.

I am doing it this way, since I am creating custom popup's based on if particular valves are closed or not. 

Why would the area be dirty in an Experience Builder app, but not in Pro using the same process on the same data?

 

0 Kudos
3 Replies
AnthonyRyanEQL
Occasional Contributor III

Carl,

Can you please provide some more information & screenshots of what you are doing?

Changing a Network Attribute and saving those edits would cause a dirty area in any application (eg Experience Builder, ArcGIS Pro, ETL/script)

0 Kudos
CarlSunderman
Occasional Contributor

No it doesn't in Pro, I've done it multiple times, without issues, but in EB, it throws an error. I have a valve that has device status is open, when i change it to close, I can run a connected trace in Pro without errors and it stops at the closed valve, but when i run it through experience builder, it fails with dirty areas. Using the same web layer in both

0 Kudos
RobertKrisher
Esri Regular Contributor

This sounds like it may be related to validate consistency and dirty area management. You can read more about this topic here: https://www.esri.com/arcgis-blog/products/utility-network/data-management/dirty-area-management-with...

Anthony is correct in that both systems will create a dirty area whenever a network attribute is edited. If you are receiving an error in EB but not in Pro, then the most likely scenario is that your Pro Trace configuration is not validating consistency but the name trace configuration configured for your web map is validating consistency. The Validate Consistency option will throw an error when a dirty area is encountered during tracing, which prevents in consistent trace results. In the case you outlined above, even though Pro isn't throwing an error it will not respect the change in the network attribute until the edit is validated.

0 Kudos