ArcFM: What Happened to My AutoUpdaters?

Have you ever had the experience of one day having your ArcFM AutoUpdaters working fine, saving your users time from performing tedious but necessary tasks and automatically maintaining the integrity of your Geodatabase and then *POW!* the next day they’re not?

We have.

But first, let’s be clear – it’s not that nothing happened between “working” and “not working.” AutoUpdaters (often referred to as “AUs”) don’t stop working for no reason. You just may not be aware of the reason when you’ve discovered they’ve stopped.

This post will describe a few cases where this can happen so you’ll be equipped should you ever find this in your Geodatabase. And we’ll discount the case where the configuration has actually gotten changed – as in, someone went into ArcCatalog and removed the AutoUpdater assignment from the class, though this would probably be the first thing to check for.

With that, here goes.

1. Un-ArcFMification

This is this simplest condition that would cause AutoUpdaters to stop working without actually changing your configuration. AutoUpdaters only work for classes that are ArcFM feature classes (or Designer feature classes, which inherit from ArcFM classes). If for whatever reason you, or your system administrator, convert the definition of your class from an ArcFM class to an Esri class, then any AUs assigned to that class will not fire.

Why would you ever change an ArcFM class to an Esri class? Well, besides by mistake, probably the most likely reason you’d consider this would be to make the class available to ArcMap users who do not have the ArcFM software installed. If you don’t have ArcFM you can’t query, edit view – you basically can’t do anything with – a class that has been ArcFM-ified.

So you might be tempted to convert to ESRI objects to support these users… but don’t. The better way to support them is to get the free object reader software from Schneider Electric. This allows users without ArcFM to view and query the data, and keeps AutoUpdaters intact for users that do.

2. Building/Re-Building the Geometric Network

A by-product of building a geometric network is that all classes in the network will, if previously defined as ArcFM classes, revert to becoming Esri classes. So this is really a special case of condition number 1.

Why does this happen? Well, if you look at the Geodatabase class model you’ll see that network features are sub-classed off of simple features. And ArcFM classes are sub-classed off of those. The ArcGIS network build process doesn’t know about ArcFM classes. It takes in classes with simple features and converts them to simple or complex junctions and edges. From there one can convert to ArcFM objects – at which point they become ArcFM “Simple Junction Features”, “Simple Edge Features,” or “Complex Edge Features.”

Conversely, when you delete a geometric network the ArcGIS process takes network classes – including network classes that have been converted to ArcFM Network Classes – and reverts them to simple features.

3. Adding/Changing Subtypes

This one is subtle and probably the hardest to track down. But it’s easy to replicate and easy to describe.

And, you can try this at home.

Start with a feature class that has subtypes and one or more subtype codes assigned. Now open the ArcFM properties for the class and click the Object Info tab. With Subtypes set to “All” assign an AutoUpdater. For example we’ll use the basic ArcFM OnCreate AutoUpdater “ArcFM User Name”. (In practice you might be better off using Esri Editor Tracking for meta-data logging as we had discussed in an earlier post – but this is an easy example.) If you look at each of the subtypes you’ll see that the AU is assigned for each.

Now, re-open Properties (not ArcFM properties, just ArcGIS Properties) for the same class and add a new subtype. Click OK on the form.

Now open ArcFM properties for the class and click the Object Info tab. Select the subtype you just added. Is the AutoUpdater assigned?

Clearly not.

This is by design. ArcFM doesn’t assume that just because an AutoUpdater was assigned to all subtypes originally that it should be “inherited” by new subtypes added to the class.

And it makes really good sense. Say your originally assigned AU evaluated a property that only applies to “Wood Poles” – maybe it tests a value in the TreatmentType field that really only applies to wood poles – we wouldn’t want that automatically applied to other types of poles that are not wood.

Summary

There you have it. If you ever find that your auto-updaters have stopped, now you have at least some places to look to discover why.