Hello everyone,
I'd like your opinions on the integration between asset data from a utility network and maintenance data.
Generally, the simple approach is to create a maintenance table associated with asset features using a relationship class. This is what is proposed, for example, in the "Water Utility Hydrant Inspections" solution.
It gets more complicated when it comes to the utility network solution. Indeed, the data is versioned, and any table participating in a relationship class must also be versioned and be part of the same UN web service. Furthermore, standard practice dictates that the Default version be protected so that it cannot be easily updated from the web or mobile.
Here are two possible scenarios, with their advantages and disadvantages:
1- Keep the maintenance tables linked to the network objects
Advantages: Benefit from the features associated with relationship classes (links between features and their maintenance items, direct editing or adding maintenance items from a feature, statistics)
Disadvantages: Editing is required in a version, which is complicated on the web (use of the version management widget, users' ability to create versions or capacity to set a specific version directly in the webmap's services), or even impossible (in 11.3, it seems that the map viewer and ExB don't allow editing a linked element in a named version). Version management in field maps is also an issue.
2- Create standalone, non-versioned tables
Advantages: No more versioning issues; you can publish a separate web service containing only part of the UN asset (e.g., hydrants) + the standalone table in a non-versioned service. You could then easily add maintenance items to the table on mobile or web. Disadvantage: You have to manually maintain the associations (hydrant GIDs / Hydrant_GUIDs for maintenance), which makes them difficult to use in different environments (dashboards, field maps, etc.). You'd have to pass the GIDs as URL parameters and use Arcade to ultimately replicate the behavior that's supposed to be standard with relationship classes.
I'm open to your use cases and suggestions regarding this issue.