Often times we have the need to piggyback on someone else’s efforts, not because of laziness but because of reusability and time saving. Why re-invent the wheel, right?
Schneider Electric's Geodatabase Manager™ (GDBM) is a tool that many utilities rely on for the posting of their versions. These versions can be Session Manager, Designer™ or plain Esri versions.
During the processing of each version, GDBM can be configured to performed different actions, such as e-mailing a supervisor if there are reconcile errors, transitioning the version to a QA State if there are validation errors, notifying other systems once the version has been posted successfully, etc.
This article will focus specifically on the data validation event, mainly because this is an area where we could piggyback on GDBM’s work. I’m not saying this is the only area - I’m sure we could benefit from the results of other events - but for the sake of this article we will focus on data validation.
If your workflow lets GDBM perform the data validation, then you must have some sort of an action configured if errors are found. Most likely there will be an e-mail notification sent to someone in your GIS department and the version will be removed from the queue and transitioned to a state such as QA State, QA Errors or simply the state it had before it was submitted for posting.
Whatever your workflow might be, the user in charge of fixing the errors has to open the version and “re-run” the validation rules to see what sort of errors were found. But why re-run it again when GDBM has already done the work? Some of our clients have claimed that re-running the validation rules was causing downtime to their users due to the length of time it took to complete.
We thought…why not take advantage of GDBM’s work and save the errors to a table? Then when the user opens the version, instead of running the validation rules again, we would simply load them to the QAQC Tab. The user does not have to wait for anything and can simply start fixing the errors.
Big time saver! The best part about it is that it only requires a custom action handler, a custom subtask and a non-version table to have this functionality up and running.
Let us know if you would like to take advantage of this functionality.