Using Export Asset Package after first successful Utility Network

[BrandoCrozier]

We have created our first successful iteration of a Utility Network for an Electric Utility using an existing Asset Package. This is our first iteration; only one Subnetwork (circuit). Our plan is to do new iterations with more subnetworks. We had to add a bunch of rules, Asset Types, and even one Subnetwork Controller type to the Asset Package. As we prepare for the next iteration we want to avoid redoing that work.

Should we use the Export Asset Package tool, take that Asset Package, then start our next iteration that will include the successful subnetwork and our next subnetwork on our list?

If not, can you please explain why this is a bad idea. Or, suggest another way to avoid re-adding all the information into the original Asset Package with each iteration?

[gis_KIWI4 · Accepted solution]

@BrandoCrozier - Exporting the Asset Package from your working UN and using that as the baseline is not only valid but is recommended. There are many advantages to doing this - additive changes, Asset package version management etc. 

Just make sure to select the "include data" option when exporting the asset package. 

Load Data when applying the asset package.

Edit - Upon reading your question clearly I see that you are wanting to add AssetTypes and Rules. 
I would like to point out these can be added to existing UN without exporting to Asset Package.
for example adding an AssetType is adding a new coded value to the field and then optionally adding connectivity rules.

In fact, most changes can be made directly to the UN apart from a few operations like Removing Terminals. 

But a good practice when it comes to development work is to Export to Asset Package -> make Changes ->Apply Asset Package. 

[RobertKrisher]

My preference is to stick with the original asset package and backport the configuration into the asset package. Why?

1. The D_Rename and D_Configuration tables are consumed when you deploy the asset package. This means that once you export back to a new asset package you lose all the original configuraiton. Why is this important? Because no matter what model you're using you should be using the D_Configuration to streamline removing unused elements from the model. Using this approach, instead of physically removing them from the model, gives you the flexilibility to restore the unused elements from your model without needing to recreate things from scratch.
2. This makes comparing schemas between releases much easier, because everything is based on the exact same geodatabase.

[BrandoCrozier]

@RobertKrisher  - At this stage we have never used D_Rename or D_Configuration and don't see those in our original Asset Package. We are struggling to understand their purpose. We found docs, including, but not limited to, "Create Rename Table (Utility Network Package)" , but still couldn't understand why we would apply this solution.

Can you point us to any docs that will help clarify the why? 

[RobertKrisher]

If you're using something like the expanded model you would to create and use a D_Configuration table to withhold unused configuration, fields, etc from your final model without needing to physically remove them from your asset package. If you've already tidied up your model to remove this extra stuff, then you're fine. Why would you remove this extra stuff? Because it has an impact on performance.

Using the D_Rename table allows you to alias things in the asset package without needing to alter any of the downstream configuration tables that would typically be affected by that change (Rules, Terminal Configurations, etc).

Article on D_Configuration

Article on D_Rename