Esri’s version 10.2.1 was released right around the end of last year and Schneider Electric’s 10.2.1 has been released and patched over the course of Q1 2014. At this point we have a pretty solid release with a lot of performance improvements from both Esri and Schneider that were covered in a previous article.
But for this post I wanted to focus on another area of major improvement in 10.2.1 that will impact every single one of our customers – conflict management. Before I jump in, if you are interested in getting more familiar with versioned conflicts and how they work, there’s a pretty good article on that subject here.
While we have the occasional customer that only manages a small number of versions on a daily basis, many of our customers are Schneider Electric Designer™ users, which almost guarantees a significant amount of long transaction versions that are prone to being impacted by conflicts. In past versions of the software some of the most troublesome areas with conflicts were caused by:
- Mass data updates – if you needed to initialize or update a field across an entire feature class it would definitely have the potential to cause significant conflicts. Especially if you didn’t turn off your Schneider update user/date AU’s!
- Feeder Manager Updates – most electric utilities use Feeder Manager to manage their electric networks and when a permanent switching order, phase swap or other similar update was made, it had the potential to trigger updates to hundreds of additional downstream features.
- Geometric Network Updates – the trouble with updating records in your geometric network (gas, electric, water, etc.) is that there are edits occurring to the network tables (N_ in the database) that the user isn’t even aware of. Network edits can cause additional conflicts because of conflicting edits to the logical network records for the same record and often even affect changes to the adjacent records in the network at the logical level. This just increases your exposure to conflicts because of the additional edits occurring behind the scenes.
- Relationship Updates – when you create relationship classes in your geodatabase you can specify notification directions. This can allow an update to one feature in the relationship to notify related records of the update. This can be helpful functionality for keeping your system updated but that additional edit notification can also generate conflicts in the system based on those related records.
When you combine these updates with a Designer™ system that has hundreds or even thousands of existing edit versions, you will likely have many conflicts in a given day and occasionally even end up with a HUGE list of conflicts resulting from single large data update. Just about every GIS administrator I know is familiar with receiving that (hopefully automated) dreaded notification that they have a large percentage of the system in conflict.
Over the years many utilities have implemented automated systems to help with the reconcile process. Schneider’s Geodatabase Manager™ is a great tool that manages version posting queues during the day and can also reconcile all of your versions. And SSP’s Nightly Batch Suite will do a full state tree reconcile of the entire system with a single conflict report each night along with your SDE geodatabase compress, statistics, indexing, and performance analysis.
These tools give a GIS administrator everything they need to have a good handle on their system health, including where the conflicts are and how the system is performing. BUT they don’t directly help to reduce conflicts…
And that’s where the new Esri 10.2.1 release comes into play. So what did Esri do to help with conflicts?
- Reduced propagation due to relationship classes – as mentioned above relationship classes can cause additional edits and therefore additional conflicts. Esri has added specific logic to better review these changes to reduce propagating edits that don’t need to occur.
- Filtering out false update-update conflicts – if you’ve been working with conflicts for any length of time you have inevitably run into the case where you review the conflicts in the conflict dialog only to say, “What the heck, there’s not even a conflict on these records?!?” or perhaps some other choice language. Well Esri has heard your plea and they have added additional checks so that many of those cases won’t even be flagged as conflicts in the first place.
- Allow users to only see fields that are in conflict in the conflict dialog – does anyone have classes with a TON of attributes? Have you ever spent too much time searching for the conflict at the attribute level? Well now you can click a filter button that will ONLY show the fields that are in conflict. This is a simple but powerful change that should make your conflict review process faster.
- Conflict filters available in the product! – This is definitely one of the most exciting items for me because we have built custom conflict filters for customers in the past. This is a great add to the product… basically you will be able to configure specific fields within your data model to NOT cause conflicts. For example, those pesky update user/date fields that are updated every time you make an edit.
You can now add a conflict filter to those fields so they NEVER cause a conflict again. Very useful stuff… conflict filters can also be applied temporarily when you have to make a mass update to a specific field. Just post your mass update, reconcile all the versions, and finally remove the conflict filter.
The combination of these conflict management changes will be HUGE for the utility industry. The result will be less time spent on managing conflicts which will drive a healthier and better performing geodatabase. This doesn’t change the need for tools like Geodatabase Manager™ or the SSP Nightly Batch Suite but it will result in those processes operating more effectively and efficiently.
One final major benefit comes from the Schneider Electric release of Feeder Manager 2.0. If you switch to only using FM 2.0, the application will no longer update ALL of those downstream features during circuit initialization, switching orders, etc. This is because the new feeder id and feeder info fields are now tracked by the application in memory as opposed to being stored as attributes on the individual features. This results in a huge reduction in feature edits being applied to your versions which directly reduces the potential for conflicts.
There have been a few concerns around moving to Feeder Manager 2.0 due to challenges supporting existing business processes & integrations but Schneider is doing a nice job of listening to those concerns and will continue to add functionality to Feeder Manager 2.0 like the Feeder Synchronization tool in the next release this summer. But that’s a topic for another article! We have our first Feeder Manager 2.0 systems in production and so far the benefit of the new functionality has heavily outweighed the challenges.
All in all these changes are a huge win for users of Esri versioning. It’s taken a while for them to be added to the product but it’s been worth the wait – a huge shout out to Esri’s Larry Young who spearheaded the effort to get these enhancements included for utilities! It should also be noted that some of these enhancements have and/or are being ported back to previous releases at 10.1, 10.0, and perhaps even 9.3.1. If you need more info on that let us know… otherwise best of luck pushing toward 10.2.1!