Best Practices: Managing a Utility Network Service
In our previous Utility Network best practices blogs, @SaranyaKesavan and I discussed topics pertaining to publishing a Utility Network service. Once the Utility Network service is published, it’s important to understand the steps needed to manage your service. While there are a variety of data model or network changes that could be made, in this blog I'll cover best practices for these 3 administrative tasks:
- Running GP tools that modify network schema
- When to republish (or overwrite) the Utility Network service?
- When to Disable/Enable Network Topology?
Running GP tools that modify network schema
Some Geoprocessing Tools modify your network schema. The access level of the DEFAULT version will impact the execution of the GP tool. In the branch versioning system used by the Utility Network, access to DEFAULT version can be either Public or Protected.
- Public — All portal users can edit the DEFAULT version directly and editors can post edits to it.
- Protected — Only users who are the version administrator (portal users with higher privileges) can edit or post edits directly to the DEFAULT version. Editors must create a named version to begin editing.
This technical article lists the GP tools that are impacted and the necessary workflow changes that need to be made.
As an example, I was adding a new network rule to my Utility Network and I got this error when running the Disable Network Topology GP tool.
Ultimately, I changed the workflow to include changing Default’s access level to Public before adding the network rule. Here are the steps:
- Stop the Utility Network service
- Kill all database connections
- Change DEFAULT to Public
- Run GP tool
- Change DEFAULT back to Protected
- Start the Utility Network service
When to republish the Utility Network service?
I was building a demo that included adding new fields and assigning attribute rules to Utility Network featureclasses. When I created the deployment plan, I had a step to republish the service but wasn’t sure it was needed. At the time, I assumed that the only way the service would recognize the new fields and attribute rules would be to republish. I have since learned that many data model changes don’t require republishing the service.
Here are some common tasks and whether they require republishing the service.
|
|
Description |
Republish Service |
|
1 |
Add a new layer to your Utility Network Service |
Yes |
|
2 |
Re-order existing layers in the Utility Network Service |
Yes |
|
3 |
Apply symbology in the Utility Network Service |
Yes |
|
4 |
Assign a new attribute rule |
No |
|
5 |
Update or delete an existing attribute rule |
No |
|
6 |
Add a new field |
No |
|
7 |
Create new coded value domain |
No |
|
8 |
Add a new domain value |
No |
|
9 |
Add a new network rule |
No |
|
10 |
Add a new contingent value |
No |
|
11 |
Add a new trace configuration |
No |
As a rule of thumb, making modifications to a layer (add, modify, remove, rename or re-order) in your publishing map will require republishing. Whereas making data model changes will not require republishing.
In ArcGIS Pro, follow these steps to republish the service. Click on the Share tab, click on Overwrite Web Layer option to begin republishing your service.
When to Disable/Enable Network Topology?
Another topic that was initially confusing to me was when to disable/enable network topology. I thought that any change to the Utility Network data model would require disabling network topology, but that wasn’t the case. Disabling network topology is needed on select administrative tasks that impact network connectivity and should only be executed when necessary. Examples include: Adding a network rule, altering a subnetwork definition or adding a new asset group.
Refer to the document Utility Network management tasks to see what the network topology state must be for many tasks. I recommend reviewing the "Modifying Components" section.
Conclusion
The purpose of this blog is to share the knowledge gained from my firsthand experience with managing a Utility Network service. I hope these insights help you understand the steps needed when building your maintenance workflows.
I look forward to sharing more of our findings in our upcoming blogs. Stay tuned!
