topic Re: Utility Network Bulk Tracing (Looping Records) with Python in ArcGIS Utility Network Questions

Utility Network Bulk Tracing (Looping Records) with Python

Andy_Morgan — Sat, 13 Dec 2025 16:35:12 GMT

After reading through various documentation and searching the Community board, I have yet to find a summary that thoroughly explains - with full examples - what's possible for bulk tracing a UN.

I'm on Enterprise 11.3, UN version 7, Pro 3.3.3.

My goal is to use either Python API or ArcPy for the following:

While looping through each of our water UN's ~77,000 line features...

Run an isolation trace on each feature, one at a time, and process the results for each trace. All I need are the "elements", no geometry.
For each starting water line segment ObjectID, extract the isolated valve ObjectIDs and isolated line ObjectIDs and then insert them into a SQL table as comma delimited for easy database retrieval (e.g. "3815, 3940, 9914, 2147"). In this way, I merely run a database query instead of executing an actual trace in the front end application/script: "...where ObjectID In (3815, 3940, 9914, 2147)"
This script would be run every so often (~ 4 times / year, maybe?)

Benefits of this approach:

No worries about dirty areas preventing the UN trace from executing for end users. Tracing ahead of time assures me that nobody will see an error saying that trace cannot run. Our Technicians post to Default throughout the day. Even though they are in the habit of Validating the Default to clear out everything including the harmless "Feature has been modified" dirty areas, they may forget or there may be a real error that isn't resolved at any given moment.
Lightning fast results for the front end application - for a single level isolation alone, but with this type of arrangement I could perform a double-level isolation very quickly which could be really beneficial in cases of a large main break so the crew knows for sure what all valves to close to guarantee water flow is blocked. Double level isolation may be rare, but it almost assures you that if the GIS data is off at least you have a safety net for identifying critical valves to close.
The results can now be used for other asset management scripts/workflows that would not otherwise be feasible if you were analyzing the entire system and had to execute a trace for each feature. It could take days to run continuously, which is unrealistic, when a simple database query for each line segment would require a tiny fraction of that time.

What works, what doesn't, where I lack knowledge:

Before going into specifics, my frustration is centered around the fact that it's hard to find a method that allows me to dynamically define my starting point (as a mid-point of each water main) for each iteration and then retrieve results in memory...preferably while running against a no dirty area version that is free from interruptions.

ArcPy Trace "arcpy.un.Trace(...)" - currently the only method that works well enough, if not ideal. I reference a starting points FileGDB (on C:\...) as the template. It has a single point feature. Using UpdateCursor I simply set the FeatureGlobalID of the current water main. It successfully completes the trace on a small scale so far, but I have to output the results to a physical JSON file where I then pull the "elements" properties and then delete the file...continue with looping.

In ArcPy I cannot seem to reference a version other than SDE.Default. I've tried appending syntax like this "?gdbversion=MyUser@Domain.TraceTesting" (both with and without forward slash before the "?") to the URL for the UN layer, but it doesn't seem to take.

ArcGIS Python for API - (arcgis.features.managers module) - either I cannot get the syntax right or even if I could I'm not sure it'll handle the per feature input as with the arcpy trace (using a FGDB point). I'm fairly confident my input parameters are fed in correctly with the "trace" method:

TraceLocations = [{ "traceLocationType": "startingPoint", "globalId": GlobalID, ## example: "{288D22C3-301A-44D1-81BA-E66F094413D9}" }] traceConfiguration = { "includeContainers": True, "includeContent": False, "includeStructures": False, "includeBarriers": True, ...etc. } resultTypes=[{"type":"elements","includeGeometry":False,"includePropagatedValues":False,"networkAttributeNames":[],"diagramTemplateName":"", "resultTypeFields":[]}] trace_results = UtilNetMgr.trace(locations=TraceLocations, trace_type="isolation", configuration=traceConfiguration, result_types=resultTypes)

It's supposed to produce a dictionary with {"traceResults": {"elements": list,}"success": bool}

Here's how it looks when my trace completes. With all the variations I've tried, I never see "traceResults" or "elements" returned.

REST API requests.post(service_url, data=payload, headers=headers) - it doesn't allow me to define a starting point dynamically while looping through my water line features. I can get it to run from REST endpoint using a Global ID of a water valve (device), but I cannot seem to get this approach to work as explained above. Can I reference local data? I don't want to store starting points in my enterprise geodatabase, since they change all the time with continual edits to our system.

BatchTrace (Utility-Data-Management-Support-Tools) isn't a viable solution if you're trying to handle results for each feature. In theory it sounds good, but practically speaking it's highly inefficient and unrealistic. The tracing still takes 15 - 20 seconds per feature, which would mean many days of running.

---------------

Here's my strategy to be most efficient: Instead of having to trace all 77,000 features, what I'll actually trace will be much less - perhaps as little as 1/10 of this total. For each line traced, I'm capturing all the lines being isolated from that run. Therefore, I already know that full group of lines is covered by a certain combination of barriers (valves). So I can then insert all those rows into my SQL table before moving on to a new isolation area, if that makes sense. I really just need to trace one line segment for each isolation area/group. It could entail 2 lines total or it could entail 18 lines, but it cuts down on a lot of processing.

Re: Utility Network Bulk Tracing (Looping Records) with Python

MikeMillerGIS — Sat, 13 Dec 2025 17:54:26 GMT

Batch trace can use the resulting lines and remove them from the trace starting points to reduce the number traces required. Now doing this may lead to some inaccurate results. Such as a larger area isolates pipes that could be isolated with a different set of valves.

Each trace result is stored in its own file, so you would just process the results after complete.

The only way we thought to reduce it was to skip calling gp trace and call the trace rest end point directly, which eliminates the gp overhead and multithreading the traces.

Re: Utility Network Bulk Tracing (Looping Records) with Python

MikeMillerGIS — Sun, 14 Dec 2025 12:47:17 GMT

Also very interested in why Batch Trace is taking 15 seconds a feature. If you turn on debug mode, we can get a better idea of what is going on.

Open ArcGIS Pro

Open the UtilityDataManagementSupport toolbox

Open any tool in the tool box. This loads the udms module from inside that toolbox into python/memory

Open a python command prompt

enter the follow:

import udms
udms.logger.setLevel('DEBUG')

Run Batch Trace

Re: Utility Network Bulk Tracing (Looping Records) with Python

MikeMillerGIS — Sun, 14 Dec 2025 13:04:09 GMT

I reviewed the code for Batch Trace and I take back this statement"Batch trace can use the resulting lines and remove them from the trace starting points to reduce the number traces required. "

Batch trace does not have this skip logic, but Build Starting Points does. So you could run Build Starting Points and an Isolation trace to build out the starting points to trace the system. Then run Batch Trace with that reduced set.

I will add an issue to expose that logic in Batch Trace too.

Re: Utility Network Bulk Tracing (Looping Records) with Python

Andy_Morgan — Sun, 14 Dec 2025 14:27:30 GMT

Hi Mike. I do see BatchTrace has the capability to reduce trace runs by taking advantage of "Group By" field from the output isolation starting points created by BuildStartingPoints. That may help for what I'm hoping to accomplish.

First, here is the output produced with debug enabled. Secure paths are obviously obfuscated in the text below. You can see it's not 15 sec this time but 30 sec.

I currently have my own arcpy.trace routine going. It's about half way through (~40,000 traces) since starting yesterday. Maybe it'll finish in under 36 hours with a somewhat complete set of trace results. (At least a few hundred had a giant set of results which I skip and move on, but making a note.)

I'll get back with more soon, if possible, but I still don't think BatchTrace is an optimal method if I want to have the ability to restart where I left off if a connection is broken midstream. My looping routine will check what's already entered into my SQL table and keep going, so it's pretty safe in that regard.

Start Time: Sunday, December 14, 2025 8:16:53 AM

ArcGIS Pro 3.3.3.52636

udms 3.3.4

Executing from ArcGIS Pro, 9 map(s), activeMap = True

****PARAMETERS****

Input Utility Network: Network Utility Network

Trace Locations: Iso_Pts

Result Types: ['ELEMENTS']

Trace Configuration Name or Field: Trace Config:: Isolate Lines and Valves

Expression: None

Output Folder: C:\\my_network_path_here\\WaterTraceIsolationResults\IsolateLinesValves_Output_2

Group Field: GroupBy

Store Summary Information on Starting Points: None

Fields to update: None

Calculate on Starting Point Features: None

JSON Result file folder: None

Aggregated GDB: None

Historical Date Field: None

Stat Table: None

Default Terminal ID: None

Code Block: None

****ENVIRONMENTS****

udms.logic.batch_trace(

utility_network=<arcpy._mp.Layer object at 0x0000021D2A6EEC10>,

trace_locations=<arcpy._mp.Layer object at 0x0000021D2A6EF490>,

result_types=['ELEMENTS'],

output_folder='C:\\my_network_path_here\\WaterTraceIsolationResults\\IsolateLinesValves_Output_2',

summary_store_field=None,

field_mapping=None,

key_field='GroupBy',

expression=None,

trace_config='Trace Config:: Isolate Lines and Valves',

calc_on_start=None,

history_field=None,

default_terminal_id=None,

user_code=None,

)

In Path: Network Utility Network

URL: https://domain/UN_service/FeatureServer

workspace: https://domain/UN_service/FeatureServer

Path: https://domain/UN_service/FeatureServer

UN Loaded

Collecting Trace Configs

Validating the inputs

Trace Config:: Isolate Lines and Valves

Setting up parameters

Opening Data Element

Verifying calc fields

Verifying Lookup Fields and Target Tables

Getting Starting Points

Getting Trace Info

Tracing

dict_keys(['Isolate Lines and Valves', 'Isolation, PP Tier, Select Valves', 'Connected, all valves including dead-ends, mains only'])

Tracing 1/2

Trace 141_::_Isolate Lines and Valves about to be run

[{'element': 'table', 'data': [['Function', 'Network Attribute', 'Filter', 'Operator', 'Filter Value', 'Result']], 'elementProps': {'striped': 'true', '0': {'align': 'left', 'pad': '30px'}, '1': {'align': 'left', 'pad': '30px'}, '2': {'align': 'left', 'pad': '30px'}, '3': {'align': 'left', 'pad': '30px'}, '4': {'align': 'left', 'pad': '30px'}, '5': {'align': 'right', 'pad': '30px'}}}]

Trace 141_::_Isolate Lines and Valves completed in 29.701016500010155 seconds

Tracing 2/2

Trace 5706_::_Isolate Lines and Valves about to be run

Trace 5706_::_Isolate Lines and Valves completed in 32.126651099999435 seconds

udms.logic.batch_trace 67.6632496000093

Succeeded at Sunday, December 14, 2025 8:18:05 AM (Elapsed Time: 1 minutes 11 seconds)

Re: Utility Network Bulk Tracing (Looping Records) with Python

MikeMillerGIS — Sun, 14 Dec 2025 14:59:26 GMT

Would be interested in seeing the same batch trace run from a script, outside pro. 30 secs a trace is not good. Nothing batch trace can do about that. I think it is the gp tool overhead of running inside pro. You have 9 maps and one active. The trace is communicating with those maps. Try it in pro with no maps, you will see a huge improvement

Re: Utility Network Bulk Tracing (Looping Records) with Python

RobertKrisher — Sun, 14 Dec 2025 16:02:02 GMT

The fastest way I've found to do this on Enterprise is to use the ArcGIS API for Python. That's a weird response your getting, and my guess is you should be getting an error instead (check the server logs). The problem is that your starting locations are missing required fields. You're only providing a type and globalid, but you need to provide at least one additional value, depending on whether the starting location is a point or line:

If you're running isolation traces from lines that can get tricky, because you aren't required to split lines at valves so you could potentially be missing out on results. This is why I'll usually try to pick some piece of equipment like a meter or a corp stop as my starting points, but put in skip logic to ensure I don't process the same area multiple times.

If you are open to using a community sample written in C#, there is a batch trace community sample available that does all of this (including the skip logic). You just need to compile and run it. You would partition your network using your mains, then set up a named trace configuration to run a connectivity trace that stops at isolation devices. In fact ... there are already sample configuration files that do this for the standard naperville model, so you'd just need to adjust them to account for any schema changes you've made (Partition_Water_Isolation).

You can use the link in the partition markdown page to access them:

Re: Utility Network Bulk Tracing (Looping Records) with Python

Andy_Morgan — Mon, 15 Dec 2025 22:45:18 GMT

Thanks, I had to fix my input parameters in a few places, including add "percentAlong" for my line features (midpoints) as starting points which I mistakenly removed while experimenting. Now my same general workflow (Python script) is working with API for Python to insert rows into a database one at a time, but it's enhanced in that I can point to a version that is free of dirty areas.

VersionMgr = arcgis.features._version.VersionManager(url=urlVersionMgmtServer, gis=gis, flc=restFeatLyrWaterUtilityNetwork) VersionForTracing = VersionMgr.get(version=BranchVersionName) VersionForTracing.start_reading() UtilNetMgr = arcgis.features._utility.UtilityNetworkManager(url=urlWaterUN, version=VersionForTracing, gis=gis) ... ... trace_results = UtilNetMgr.trace(locations=TraceLocations, trace_type="isolation", configuration=traceConfiguration, result_types=resultTypes)

Lots to say still. I don't want to take up your valuable time. It seems like ESRI could dedicate a white paper to this topic of bulk network tracing: different strategies, when it makes sense to do so, optimization, etc.

In his reply above, @MikeMillerGIS seems surprised by the 15 - 30 sec execution time for my traces. Yes, this is the most depressing part. It's takes equally long per trace if I run through API for Python (UtilityNetworkManager) or even directly from the server at the REST end point page (.../UtilityNetworkServer/trace) by plugging in a trace config ID and a water main Global ID as starting point. Maybe our geodatabase needs some fine tuning since our deployment 2 months ago?

As for skip logic, I think I'm able to handle this fine while inserting into my SQL table. My script didn't finish after ~ 36 hours, but it got pretty far along. The problem is that more than a few hundred traces interspersed throughout the iterations were giving results with nearly all water lines included! That slowed it down a lot, no doubt. I'll have to figure out what's going on there.

As for @MikeMillerGIS's caution about "a larger area isolates pipes that could be isolated with a different set of valves.", again I think that can be resolved with my output database by simply looking at duplicates for a given input Water Line ObjectID and choosing the one with the longest or shortest value (depending on what makes the most sense).

I will check into the Pro SDK batch tracer. I'm open to whatever tool works the fastest. So that leads me to ask, would it really perform any better than a direct REST endpoint trace or Python API? I suspect not, and that in the end I'm still dealing with the limitation on the server/GDB side of things.

Maybe you have some final thoughts? Otherwise, I'll close this as answered, although others may find their way to this thread and have more to say.

Re: Utility Network Bulk Tracing (Looping Records) with Python

MikeMillerGIS — Tue, 16 Dec 2025 01:16:26 GMT

Are you using the pressure zone tier? If so, running your isolation trace on that tier could speed things up.

How many controllers do you have on the system tier?

Re: Utility Network Bulk Tracing (Looping Records) with Python

Andy_Morgan — Tue, 16 Dec 2025 16:48:54 GMT

Glad you asked these questions.

I have been using System tier, thinking it wouldn't really make much of a difference for tracing performance. I was clearly wrong.

Tracing times

"Water System" tier	"Pressure Plane" tier
[ObjectID]: [Time to Trace]	[ObjectID]: [Time to Trace]
723: 18 sec	723: 8 sec
771: 19 sec	771: 9 sec
11705: 19 sec	11705: 6 sec
3333: 19 sec	3333: 6 sec

The main reason I stuck with System tier until now is because I was erring on the side of caution: what if our pressure plane divider valve features (the only parameter for defining condition barrier for pressure subnetworks: Is_PP_Divider is equal to Yes) were modified by a Technician and it messed up the pressure plane boundaries so as to not be sealed anymore. I'm pretty sure tracing would fail with "Multiple subnetwork controllers with different subnetwork names found."

I suppose it's safe enough to rely on Pressure Plane tier for isolation tracing. This drop in execution time seems worth the low risk of a rare edit made to pressure plane valves (marked with a PP_Divider field). We'll need to work out how best to handle significant edits for pressure plane expansion projects which we've only had one or two in the last 10 years.

As for controllers, again glad you brought this up. I hadn't made it around to adding more than the bare minimum to define each subnetwork on each tier. I'll keep going with adding more controllers for storage towers, as there are a 3-4 more each that I could add to the two largest pressure planes. This would likely help as well, eh? We have another treatment plant that I could add on the system tier.

This will only put in me a better place for bulk tracing. Thanks!

Re: Utility Network Bulk Tracing (Looping Records) with Python

RobertKrisher — Wed, 17 Dec 2025 15:10:40 GMT

@Andy_Morgan You can mitigate the risks of pressure zone boundaries breaking if you have editors work in a version, instead of defaulting directly, and ensure they validate all their dirty areas, fix all their edits, and trace or update their subnetworks before posting their versions. This will flag any inconsistent subnetworks before they are posted to default and become everyone's problem.

Re: Utility Network Bulk Tracing (Looping Records) with Python

Andy_Morgan — Wed, 17 Dec 2025 18:03:08 GMT

Right, definitely an important workflow for editors. While that's applicable for typical edits to lines and valves, sometimes a pressure plane expansion could mean a slow motion updating of features as the construction project and engineering discussions go on for weeks or months. In such rare cases where a broken boundary in GIS is going to be intentional (and of course temporary), I suppose we could create a no-edit/static version on the side before breaking the boundaries -- a snapshot while the pressure planes are still sealed -- and use it for re-tracing if an updated bulk trace was needed.

Hopefully there wouldn't be a need to run an isolation trace for that small expansion/modification area under construction, but otherwise for everywhere else at least this once again shows the value of having a pre-traced system that you don't have to worry about the Default version having issues at any given moment.

Re: Utility Network Bulk Tracing (Looping Records) with Python

Andy_Morgan — Mon, 22 Dec 2025 20:37:42 GMT

@RobertKrisher and @MikeMillerGIS:

One last question as it relates to my bulk tracing solution.

I made some good progress but now hit a wall. For roughly 70,000 water main features, it may take around 24 - 36 hours to trace everything and store ObjectIDs of all the isolated lines. However, I also need isolating valves. I cannot find any way to perform a single trace and extract the valves that are actually isolating + the full set of water mains being isolated.

Here's the reason I want both sets. Besides knowing which valves to turn off in case of an emergency, having all isolated lines will allow me to essentially trace one more level out, i.e. a "double isolation trace". This is nice to offer the field crews for critical situations like a busted 24" main. Having the second layer of isolating valves will potentially save the crews time if they cannot shut of water based on the immediate (1st level) of valves to close. So rather than run a bunch of isolation traces from all the results of the first initial trace, I could use the database row to quickly and easily return isolating valves for those secondary lines.

Here's a visual that may help to explain. My starting trace point is the green point in the middle. The valve on the south end is the only isolating valve. The other two circled in red are what I wish to exclude...yet include all those isolated line elements that are selected in the map.

Is it possible to capture this combination in one run, or am I forced to trace the entire system twice if I want to be able to select double isolation valves directly from my database table of pre-traced lines?

The two valves circled above should not be included in my results.

Update after posting

It looks like this question has already been answered:

https://community.esri.com/t5/arcgis-utility-network-questions/identify-isolating-valves/m-p/1649732#M5753

Is there any way to take advantage of a Connected trace or some other type of faster trace than a second Isolation? That's the main concern, avoiding two isolation traces for the same feature.

Re: Utility Network Bulk Tracing (Looping Records) with Python

MikeMillerGIS — Tue, 23 Dec 2025 12:12:39 GMT

Two isolation traces are the only way that I know how to achieve this.

Re: Utility Network Bulk Tracing (Looping Records) with Python

RobertKrisher — Mon, 29 Dec 2025 15:00:42 GMT

Option 1- It should be faster to do the isolation trace to get the valves, then run a connected trace with the valves as barriers. The connected trace ignore terminal connections and subnetwork controllers, so there is the possibility for it to produce different results.

The reason why it is faster is because a subnetwork trace must analyze the entire subnetwork to determine flow. If you run a connected trace it will only consider the portion of the network bounded by barriers.

Option 2 - If you're willing to parse the JSON for the export, or manually inspect the results, you could run 1 trace then parse the results to find features that match your condition barriers (i.e. closed valves). This is something that the Batch Tracing CoreHost application that I linked to earlier does. Also, because it uses the Tracing API directly it bypasses the GP overhead and should be able to perform that analysis in a fraction of the time. For reference, doing this analysis for Naperville using raw GP takes about 8 hours, using the Pro SDK it takes a few minutes.

Re: Utility Network Bulk Tracing (Looping Records) with Python

Andy_Morgan — Mon, 29 Dec 2025 15:50:49 GMT

Yes, I have already tried...and ditched...Option1, hoping the Connected trace approach might work for round 2 (to get double isolation valves). The problem there is that if the round 1 trace gets all isolated features (lines and valves being isolated) then I don't have the isolating valve(s) defined yet. It's the inverse for getting only isolating valves in round 1 trace: I won't have all the isolated lines, which would be best for cost of outage analysis later on, i.e. how many and which type of customers would be impacted.

So basically, without having isolating valves in round 1 I cannot go further. A connected trace would go inside and outside the isolating group, selecting more valves than I want.

It will take 2 - 3 traces to accomplish what I want: isolated valves/lines, isolating valves, 2nd outer layer of isolating valves. With my SQL Server table capturing valve OIDs for both isolated and isolating, it looks like only 2 rounds of tracing could be enough, with the rest of the output dependent on selecting rows from the SQL table in a particular way. No matter what, though, your Option 2 may be worth starting over with the Pro .NET SDK. At least I have most of the general logic worked out. The Python / GP time for execution is my worst headache right now.

Thanks. I hope to report back with a final solution eventually.

Re: Utility Network Bulk Tracing (Looping Records) with Python

RobertKrisher — Mon, 29 Dec 2025 21:48:36 GMT

@Andy_Morgan

In option 1 you get the Isolating valves, which is the slower isolation trace. Once you've done this, you use the faster connected trace to get all the isolated features. You're still doing two traces, but one isolation trace and one connected trace will always be faster than two isolation traces. The larger the subnetwork that contains the area being isolated, the faster it will be.

Option 2 allows you to do it all with a single trace (choosing include isolated features gives you the isolated features and the isolating valves) but requires the tedious effort of digging through the complete trace result JSON to manually identify the isolating valves. You'll also need to make sure you filter out any false positives when doing this (valves 3972 and 3973 in your example above). Filtering out false positives is a bit tricky, but you'll want to exclude any valves that are barriers (i.e. closed) but still contain results on either side. These are uncommon, but possible. Option 2 can be done with either Pro SDK or Python.

When talking about this with people (where I don't have the luxury of using bolded text) I usually refer to the results as the contents and barriers for the trace instead isolated/isolating.

Re: Utility Network Bulk Tracing (Looping Records) with Python

Andy_Morgan — Tue, 30 Dec 2025 14:42:58 GMT

The terms "contents" vs "barriers" are easier to write. Got it.

As for Option 2, I have the Core Host tracing solution downloaded and have been trying to plug in my own UN connection properties. I can somewhat follow along with what the C#.NET code is doing. I borrowed the example json files to create my own config file (see below). Originally, the error was about geodatabase not being found, but now it's failing on "dataset was not found". I've tried all variations imaginable.

I realize you were pointing me to the Partition_Water_Isolation" json example, but I think for my workflow and the ultimate goal it'll requires me to use "type": "Trace" like the Trace_Electric_Customers.json example.

I don't meant to go too far with troubleshooting here, so unless you have a quick suggestion I'm wondering if there is any example from ESRI that shows how to connect to a UN feature service using .NET Pro SDK. All of the examples I've seen so far use File Geodatabases. Surely, I don't use a .sde file path, since there is mention of portal URL and user/password. The documentation for OpenDataset doesn't help me.

Once I can properly connect, I should be able to figure out the rest in the trace looping and working with the json response to inspect elements.

My current Water_Trace.json file (with sensitive domains/paths and user/pwd values removed)

{ "analysisName": "Isolation Trace", "type": "Trace", "networkSourceName": "UtilNet", "assetGroupCode": 1, "domainNetworkName": "Water", "tierName": "Water Pressure", "definitionQuery": "", "namedTraceConfigurtion": "Isolate Lines and Valves", "inputWorkspace": "https://myserver.domain/arcgis/rest/services/.../Water_UN/FeatureServer", "sourceUtilityNetwork": "UtilNet", "outputFile": "C:\\UtilityNewtorkTracing\\ArlWaterTraceResults.csv", "outputWorkspace": "C:\\UtilityNewtorkTracing\\BatchTracing.gdb", "outputPoints": "Pressure_Points", "outputPolylines": "Pressure_Lines", "outputPolygons": "Pressure_Polygons", "outputTable": "Pressure_Analysis", "portalUrl": "https://portalserver.domain/agsportal", "portalUser": "Domain\\username", "portalPassword": "password" }

Full error message:

12/30/2025 7:50:58 AM: Reading configuration file: D:\OtherProjects\BatchTracingCoreHost\JSON Configurations\Trace_Water.json
12/30/2025 7:50:58 AM: Isolation Trace - Performing analysis
ArcGIS.Core.Data.Exceptions.GeodatabaseDatasetException: The dataset was not found.
---> System.Runtime.InteropServices.COMException (0x80040301): 0x80040301
at ArcGIS.Core.Internal.IGeodatabaseIOP.Geodatabase_GetUtilityNetwork(IntPtr workspaceHandle, String name)
at ArcGIS.Core.Data.GeodatabaseCore.OpenDatasetCore[T](String name)
--- End of inner exception stack trace ---
at ArcGIS.Core.Data.GeodatabaseCore.OpenDatasetCore[T](String name)
at ArcGIS.Core.Data.GeodatabaseCore.OpenDataset[T](String name)
at ArcGIS.Core.Data.Geodatabase.OpenDataset[T](String name)
at BatchTracingCoreHost.Classes.BatchTrace.BatchTraceUsingPaths(String inputWorkspacePath, String utilityNetworkClassName, String networkSourceName, Int32 assetGroupCode, String definitionQuery, String sourceFieldName, String outputWorkspacePath, String polygonClassName, String polylineClassName, String pointClassName, String outputTableName, Int32 functionFieldCount, String analysisName, String namedConfigurationName, String terminalName) in D:\OtherProjects\BatchTracingCoreHost\Classes\BatchTrace.cs:line 78
12/30/2025 7:52:17 AM: Isolation Trace - Analysis complete
12/30/2025 7:52:17 AM: All analysis complete

Re: Utility Network Bulk Tracing (Looping Records) with Python

RobertKrisher — Tue, 30 Dec 2025 15:19:07 GMT

Because it is a service, try using the layer ID or layer name of the utility network as it appears in the rest endpoint for the service.

The Pro SDK can read branch versioned data through an SDE connection, but we don't allow you to trace or edit data. So, for enterprise this process requires a service.

Re: Utility Network Bulk Tracing (Looping Records) with Python

Andy_Morgan — Fri, 02 Jan 2026 19:13:30 GMT

The .NET Batch Tracing Core Host method appears to be no faster than the Python / GP execution. I'm pointing to my production Enterprise feature service for UN and starting points (mid-points of water mains), rather than the Naperville (FGDB). You can see in my screenshot below it's returning elements just fine. No different than how it would look in Python, except Python is a little easier to watch/debug and I've already invested time into the custom actions around the tracing.

Using the same trace configuration (pointing to water pressure tier) it takes ~7 seconds (sometimes barely a second) per trace. Unless you suspect something isn't configured correctly in my .NET solution, I have to assume Python is still just as good as anything. Running the trace directly from REST endpoint is the same time as well.

As for manually inspecting results, I don't think I'm able to parse the results to handle it all in one trace. My condition barriers are defined by a single field in our valves feature class ("Is_PP_Divider" = Yes), not relying on a closed vs open status, and our filter barriers are Category IS_EQUAL_TO SPECIFIC_VALUE Isolating. So there is no way to further dissect the results when this is all I have available. No properties that help me pick out the barrier (isolating) vs contents (isolated).

elements (networkSourceId, globalId, objectId, terminalId, assetGroupCode, assetTypeCode)
sourceMapping
resultTypes

I think I'll abandon the .NET method and return to my Python solution...which still seems to require multiple traces.