The bullets below are some concerns about branch versioning summarized after talking to some RHUG members.
- Implementation of Quality Control (QC) via Branch Versioning
The process for editing routes by some R&H clients relies on a three-tier versioning model as below that is based on traditional versioning.
- Tier 1: Default Version
- Tier 2: Quality Control (QC) Version; Child of Tier 1
- Tier 3: Editor Version; Child of Tier 2 or Grandchild of Tier 1
At Tier 3 multiple editors can simultaneously perform edits to the networks managed in R&H; at Tier 2 there are at least one person performing QC and then posting and reconciling; additional QC may also occur at Tier 1 or the Default version.
This three-tier or plus versioning model is a typical configuration for the R&H User Group (RHUG) members that had deployed R&H before the ArcGIS Pro based R&H extension became available and functionally ready.
A workaround solution for implementing the complete set of requirements for QC in the ArcGIS Pro based R&H environment will simplify the process for such RHUS members to migrate and speed up the migration.
- System Integration in ArcGIS Pro based R&H environment
Current efforts to implement system integration are based on traditional versioning. The AgileAssets’ LRS Gateway is a typical example.
Without traditional versioning in the ArcGIS Pro based R&H environment, those RHUG members that are working on system integration may have to extend their effort tweaking and testing their solutions in the new environment, which is a risk that the members may have to take. It may further delay the migration from ArcGIS Desktop to ArcPro for such RHUG members.
- Integration with Other Esri ArcGIS Applications
In the ArcGIS Desktop platform, such ArcGIS products as Workflow Manager and Data Reviewer can integrate well with R&H so certain workflows can be set up and executed in a seamless way. Some RHUG members (for example, West Virginia DOT) have their R&H editing workflow configured with the three applications integrated.
In the ArcGIS Pro platform, the R&H extension is service oriented, so how will it integrate with Workflow Manager, Data Reviewer, and other ArcGIS applications?
The branch versioning in the ArcGIS Pro based R&H environment means that there are only two levels of versions. In the case that there are many concurrent child versions or simultaneous editing activities (we don’t know yet what the breakpoint would be before a chaos should happen), the likelihood for mistakenly committing a change by any of the child versions to the default version, which must be set to public, would increase considerably. This may imply an unexpected increase in the roll back of the R&H transactional database.
To reduce the risk, RHUG members will probably have to increase the frequency of backing up the R&H transactional database and be prepared to redo those impacted editing jobs.
Some RHUG members may have implemented certain business processes that depend on the concept of traditional versioning in the ArcGIS Desktop based R&H environment (it’s up to the members to report). The switch from traditional versioning to branch versioning and the change in database schema may require such RHUG members to revisit, update, and reimplement the processes.
One example is how to utilize a script to read the default version data from the R&H transactional database. Compared to the ArcGIS Desktop based R&H environment, in the ArcGIS Pro environment there does not have Add/Delete tables anymore; all changes occur in the base table; all user edits are in one table with the BRANCH_ID defining which branch version is being edited. The example illustrates the script should be updated before it can function properly again.
Yueming Wu @ West Virginia Department of Transportation
