Subnetworks are updated to ensure attributes and network features are current and valid in a network. Updating a subnetwork also exposes errors and inconsistences in a subnetwork, such as invalid features, disjointed or inconsistent subnetworks, incorrect numbers of subnetwork controllers, or dirty areas that have not been validated. The update subnetwork operation is run from the Update Subnetwork tool or Find Subnetworks pane to update subnetworks that are marked as dirty after edits have been made and validated.
Subnetworks are marked as dirty when they're created and when validating the network topology after features and objects in the subnetwork are edited. When a subnetwork is updated with no errors, it's marked as clean. When validate consistency failures or subnetwork errors are discovered during the update subnetwork operation, the operation fails and the subnetwork is marked as invalid. This is tracked by the Is dirty attribute in the Subnetworks table and displayed in the Status column for each subnetwork in the Find Subnetworks pane. See Subnetwork life cycle to learn more.
The update subnetwork operation can be broken down into the following steps:
- Identify and validate the consistency of subnetwork controllers.
- Perform a subnetwork trace.
- Validate the trace result to determine whether invalid features or objects were discovered.
- Update the subnetwork name attributes, is connected, and propagated field attributes on network features.
- Create or update records in the SubnetLine feature class for the subnetwork.
- Update associated subnetwork controller records in the Subnetworks table.
- Create or update subnetwork system diagrams.
Inspect and validate subnetwork properties
When you run an update subnetwork operation, subnetwork controllers are validated and a subnetwork trace is performed to determine whether invalid features or objects were discovered. The tier's subnetwork definition defines the subnetwork's behavior requirements as well as what constitutes valid features and objects in the subnetwork.
The following subsections include information about the tier properties that are inspected and attribute fields updated on network features when a subnetwork is updated.
Valid features and objects
As specified in the subnetwork definition, certain asset groups and asset types for each class are defined as valid for each tier in a domain network. Features and objects that violate the subnetwork definition are discovered when updating the subnetwork by inspecting the attributes of traversable features in the subnetwork. If invalid network features are discovered when updating a subnetwork, an error is created and the subnetwork is marked as invalid. To learn more about errors specific to updating subnetworks, see Update subnetwork errors.
When updating subnetworks, the valid devices property for the subnetwork definition is not evaluated for boundary features that connect multiple subnetworks. Boundary features are devices that act as a barrier between two subnetworks, or subnetwork controllers that participate in more than one subnetwork, for example, a pump in a water network that receives pressure in one subnetwork and increases the pressure in another.
The following valid features and objects are specified in the subnetwork definition of each tier:
- Valid Devices
- Valid Device Subnetwork Controllers
- Valid Lines
- Valid Junctions
- Valid Edge Objects
- Valid Junction Objects
- Valid Junction Object Subnetwork Controllers
Inconsistent and disjoint subnetworks
The Subnetwork name attribute is used to track which subnetwork network features belong to. The value populated in this attribute field is derived from the subnetwork name of features that are set as a subnetwork controller. Additionally, features in the domain network have Supported subnetwork name and Supporting subnetwork name attributes. These attributes help track the subnetwork that a container or structure feature supports and the subnetwork that supports a content feature, respectively.
To learn more, see Supported subnetwork name and Supporting subnetwork name.
The update subnetwork process ensures that the subnetwork name is consistent for features in a subnetwork. Errors are generated for inconsistencies. The following situations outline cases in which errors may be encountered:
Inconsistent subnetworks—When a subnetwork has multiple subnetwork controllers that are traversable and the Subnetwork Name attribute does not match, the subnetwork is considered inconsistent. For example, in a mesh network with five subnetwork controllers, four of the subnetwork sources have the correct subnetwork name, while the fifth has a different name. If inconsistent subnetworks are discovered when updating subnetworks, a warning is returned in the Update Subnetwork tool and errors are created for the subnetwork controllers that have inconsistent subnetwork names. The specific subnetwork names found to be inconsistent are returned and can be inspected using the Modify Subnetwork Controller pane and the Subnetworks table.
Disjoint subnetworks—For partitioned domain networks, subnetworks with controllers that have the same subnetwork name and are not traversable are considered disjoint subnetworks. When updating subnetworks, errors will be generated for disjoint subnetworks if the subnetwork definition does not allow for this. This setting is defined within the subnetwork definition for the tier. Check the network properties to review the Tiers subsection of the specific domain network.
If any of the neighboring subnetworks are found to be inconsistent when checking the consistency of boundary features, a warning is returned during the update process listing the conflicting subnetwork names. To determine how to resolve the warning, neighboring subnetworks can be inspected using the Modify Subnetwork Controller pane and the Subnetworks table. Once the neighboring subnetworks are edited, the update subnetwork operation can be run again.
To learn more, see Subnetworks.
Updating features and objects in a subnetwork
When a subnetwork is updated in the default version, the geometry, subnetwork name attributes, Is connected attribute, as well as the substitution and propagated values, are updated for all features and objects in the subnetwork. If the update subnetwork operation is run in a named version using the default edit mode option, these same updates are limited to features and objects that are edited within the version.
Dive-in:
The default eventing behavior for named versions can be modified as part of the update subnetwork policy with the Edit Mode for Named Version parameter in the Set Subnetwork Definition geoprocessing tool for utility networks of version 4 or later.Updates to the SubnetLine feature class and Subnetworks table
As with edits to features and objects in the subnetwork, the SubnetLine feature class and Subnetworks table are modified when the update subnetwork operation is run.
If the subnetwork definition for the tier defines aggregated lines for the SubnetLine feature class or has summaries configured, the update operation creates or updates a record for the subnetwork in the SubnetLine feature class and updates the Last update subnetwork attribute, the Is dirty attribute, as well as the editor tracking attributes. Summaries that are configured in the subnetwork trace configuration are also updated and written to the summary attributes. A successful update operation changes the status of the subnetwork to Clean (isDirty = false). If the update operation fails, only the editor tracking fields are updated.
In the Subnetworks table, the Last update subnetwork, Is dirty, and editor tracking attributes are also updated for associated subnetwork controllers. A successful update operation changes the status of all its controllers to Clean (isDirty = false) in the table. If the update operation fails, only the editor tracking fields are updated.
Is dirty attribute
The Is dirty attribute is used to track the status of a subnetwork in the Subnetworks table and SubnetLine feature class, and impacts the consistency of network diagrams. This status of Is dirty is managed primarily through the update subnetwork operation and the disable, enable, and validate network topology tools and is configured using the Manage IsDirty option for the tier's subnetwork definition.
To learn more, see Subnetwork life cycle.
Update subnetwork policy
When the update subnetwork process is run, there are several options that control what network features are updated and how the edits are performed for the network features in the geodatabase. These options are configured as part of the subnetwork definition for a tier in the Update subnetwork policy section, using the Set Subnetwork Definition tool.
Review your workflows and determine whether changes are needed to the default update subnetwork policy. The Update Structure Network Containers and Update Domain Network Containers options can be modified in the subnetwork definition to control whether you want to see the subnetwork name attributes on containers. This can also be used to prevent issues in which the supported subnetwork name field may be overloaded for structure and domain network containers. This can be helpful in situations in which there is nested containment.
If there is a workflow that requires triggering geodatabase behavior when attribute edits are made during the update subnetwork process, the edit modes can be configured to use With Eventing edit mode.
Options to set for Update subnetwork policy are as follows:
- Manage IsDirty—Specifies whether the Is dirty attribute in the Subnetworks table is managed by the update subnetwork operation. This also impacts the consistency of network diagrams and the methods used to remove deleted controllers from the Subnetworks table. When this option is enabled, the IsDirty attribute is managed by the update subnetwork operation and updated in the Subnetworks table and SubnetLine feature class.
Note:
If the tier is configured to not manage the Is dirty attribute, the subnetwork will always appear as Dirty whether an update subnetwork operation succeeds or fails.
When this option is not enabled, the update subnetwork operation can be used in the default version to delete rows from the Subnetworks table in the default version where the Is deleted attribute is set to true.
When there are no subnetwork controllers defined for a tier, the Manage IsDirty option is disabled.
To learn more about subnetwork status and the Is dirty attribute, see Subnetwork status.
- Update Structure Network Containers—Specifies whether the update subnetwork process will update the supported subnetwork name attribute for structure network containers. This option is checked by default.
- Update Domain Network Containers—Specifies whether the update subnetwork process will update the supported subnetwork name attribute for domain network containers. This option is checked by default.
Edit Mode for Default Version and Edit Mode for Named Version—During the update subnetwork process, various attribute edits are made to subnetwork features. The Edit Mode determines how the attribute edits are performed. Two options are available to control this behavior: With Eventing and Without Eventing.
- Without Eventing—This is the default for both the default and named versions as well as when working in a single-user deployment. When using this edit mode in an enterprise deployment, geodatabase contracts are not honored during update subnetwork. This means that events do not trigger updates to editor tracking, attribute rules, or related objects when features are updated. This also means that changes made to features without events do not write geodatabase history for later review. This approach is taken to optimize the performance of update subnetwork.
- When using this edit mode in the default version or a single-user deployment, the subnetwork name and propagated values are updated for all features and objects in the subnetwork.
- When using this edit mode in named versions, the subnetwork name and propagated values are updated only for features edited by the user in the version.
- With Eventing—This option enables users to trigger geodatabase behavior when updating subnetworks in the default and named version as well as when working in a single-user deployment. With this edit mode, cursor updates are used to update the subnetwork name and propagated values for all features traversed by the operation.
Using With Eventing respects all geodatabase contracts. This means that attribute rules fire and have their validation status reset, editor tracking is updated, related objects are updated when applicable, and changes are recorded as actual edits in the history of the geodatabase. This edit mode should be considered for users who require attribute rules to fire during the update subnetwork operation.
Caution:
This option may adversely impact performance and should not be used with larger subnetworks when a large number of attribute rules or related objects such as feature-linked annotation classes, are present in your data.
The example below illustrates the impact of running update subnetwork in a named version on the RMT001 subnetwork following the creation of a line, while using the default Edit Mode for Named Version, which is Without Eventing. Notice that the subnetwork name is updated for only the feature that was edited in the version.
This example illustrates the impact of running update subnetwork on the RMT001 subnetwork following the creation of a line, when the tool is run in the default version, or when the tool is run in a named version and the Edit Mode for Named Version is set to With Eventing. Notice that while only one feature is edited, all features in the subnetwork are updated with the subnetwork name.
Note:
Certain parameters require a minimum Utility Network Version. Refer to the Set Subnetwork Definition tool for more information.
- Without Eventing—This is the default for both the default and named versions as well as when working in a single-user deployment. When using this edit mode in an enterprise deployment, geodatabase contracts are not honored during update subnetwork. This means that events do not trigger updates to editor tracking, attribute rules, or related objects when features are updated. This also means that changes made to features without events do not write geodatabase history for later review. This approach is taken to optimize the performance of update subnetwork.