During a recent installation of the SSP All Edits Report for another large U.S. utility, we had the opportunity to apply some significant enhancements to the functionality.
If you’re an All Edits user or have followed the updates to the software over the years, you’re likely familiar with our ability to save versioned edits into our own All Edits schema. This allows us to then recreate the All Edits Report, including visualization even AFTER the version has been posted. Dennise Ramirez wrote a nice post on this a couple of years ago if you don’t know what I’m talking about!
The new enhancements focus on providing better control over accessing those saved versions. The versions can be viewed in ArcMap using the SSP Retrieve All Edits tool which was a major focus of the enhancements. Here’s the new form:
Several of our utility users have extrememly high throughput of edits on any given day – up to posting several hundred versions in a 24 hour period. The All Edits Report can be run in an automated fashion via a Schneider Electric PX Subtask, Geodatabase Manager™ Action Handler, or even via your own custom batch reconcile and post (BRP) application via our public API.
Any of these approaches will allow you to export and catalog your versioned changes into our very intuitive and usable format for later review by your QA team, management, or even the GIS end users. BUT this can result in a lot of data being saved to the All Edits schema. Most existing users truncate those tables for data that has passed an expiration date. For example any versions posted over 6 months ago may be deleted from the system.
The first new enhancement provides a recommended pattern for archiving your versioned edits from the standard All Edits schema to a secondary All Edits Archive schema. These tables still exist in the same geodatabase but you can allow your older data to accumulate there without impacting the real time performance of the active All Edits schema. Then the above form will allow you to search either your active or your archive tables for the edits by simply toggling a radio button:
This will allow you to keep your most recent data in the active tables (~6 months) and then to move that data to the archival tables on a scheduled basis. The benefit of keeping that archived data around will likely outweigh the slower performance when loading older reports.
The second enhancement is a new configurable attribute search which will allow you to search your edits for records matching specified field values. This is great for searching all edits applied to a certain work order, service request, etc. but could also be used for object ids, facility ids, or other intelligent values:
My favorite part about this search is that it is completely configurable. In our configuration file you can specify the alias of the field you want to search (i.e. “SR Number” above) and then you can specify multiple attribute/field names to search against. For example you might specify the SR Number to be searched against three attribute fields: InstallSRNumber, RetireSRNumber, and plain old SRNumber. This gives your users maximum flexibility in finding the edits they are looking for. Oh, and you can use wildcards via the % sign anywhere in the field values!
The third enhancement now allows you to configure the usage of the Version Name on the retrieval form either to be an existing drop down control (picklist) that will show ALL available version names OR to be a text box where you can type in any part of a version name.
This probably isn’t as useful for out-of-the-box Schneider users who have their version names automatically named by the process framework. But for other utilities who have intelligence built into their version names, this will add some key functionality. For example, if your version name contains the work order number, you can now easily search the All Edits reports for any versions related to that work order number. The value you type in is automatically searched using a wildcard format of %versionname% for maximum flexibility.
The fourth and final enhancement will allow you to configure version name keywords to cause the Auto All Edits Report to skip specified versions. For example, you might configure “NoAllEdits” and the automatic report would then skip versions named both “SPERRY.NoAllEdits_MassUpdates” and “SPERRY.AwesomeEditsNoAllEdits”. This will provide a useful way to keep the All Edits Report from running on any mass update / cleanup versions that might be posted by your GIS support team.
We’re excited about these new changes and we hope you are too. If you want to hear more about them or the All Edits tool in general, give us a shout.