In our current 10.x world we make significant use of ArcFM AutoUpdaters to perform important business logic (like many utilities).
We're implementing the UN and now considering how to replace that logic. (Quite a bit is not accounted for out of the box.)
On the one hand it seems that ArcFM XI supports handling of edit events on feature services through their Server Object Extension -- though I don't at the moment know how extensible this is.
One the other hand ArcGIS Pro exposes Edit Events, not unlike the way ArcMap does, which we could handle to provide similar capabilities to what we have now.
I'm *very* curious to hear thoughts from others who have already gone down this path.
Thanks in advance for any feedback.
Ed
@EdwardBlair - It depends on how complicated the actions are that your AutoUpdaters perform.
Some of the functionality of the AutoUpdaters is taken over by Connectivity Rules, Attribute Rules, Subnetwork Management Functionality.
Attribute Rules can fill some of these gaps. Some common examples include
1) automatically creating associations based on "contains" or distance
2) auto assigning terminals
3) create non-spatial items / related devices when the main device is created. (example - Voltage regulator and Arrestors)
4) Generate IDs
5) Split lines when devices are inserted mid line
If you want something complex like "when a device is created; trace upstream and grab the first protection device" then this will need to be managed outside of the UN.
Could be webhook->REST trace ->write back
Maybe a nightly script that traverses the network to fill in the blanks.
We have never used ArcFM so I can't speak to the specifics but if there were any particular use cases you wanted to talk about then we can do that.
@gis_KIWI4 Thanks much for the feedback.
I'm particularly interested in the "complex" case where, on an edit event, we walk the network to discover what is upstream or downstream and perform some operation with the results. There are important aspects of our implementation that rely on this logic, and it generally works pretty well within the GN.
We've attempted some preliminary steps than handle ArcGIS Pro edit events, which kind-of work, but sometimes get tripped up when encountering dirty areas. My current thought is that we keep going down this path...but am interested to hear from others if there is a better way.
Ed
Hi Ed,
@gis_KIWI4 has mentioned - some network elements such as phase propagation and update subnetwork are handled within the UN itself. We use ArcFM Editor XI and the product team is working to build out new AutoUpdaters pretty consistently. If you have someone in house who is already developing complex updaters then I would imagine some of them can transfer over. I would recommend a solid look/dig into your network categories to see what tracing functions you might be able to leverage with a script. We employ both contingent values and attribute rules to ensure data is populated correctly. I would reach out to the ArcFM Editor XI product team, through your account rep, to see if they've planned for requests similar to yours. I think all of those updaters are programmed in Csharp - so theoretically you can customize however you want. As far as dirty areas are concerned, you probably just need to validate prior to your updates. If that doesn't resolve the issues, then you might have an error - which needs resolved either through fixing the data or updating UN rules.
Hi @jennsmith_ElectricUN Thanks for the feedback. We're talking with SE now and see that what we're looking for is not yet present. I'm just wondering what folks who have already gone through a UN implementation have done about this. I didn't think we were actually "early adopters", but maybe we are.
We've been on the Electric UN since 2023, but we didn't have a GN to start so ArcFM wasn't an option for us prior to our UN build. You may be unique in how you're employing those auto updaters. Aligning the software to work with UN has been a significant and ongoing process - especially given the consistent upgrade cycles and network management release cycles.