Allow standard database replication with Branch Versioned data

[MichaelSnook]

We have been using database replication with the older, traditional database versioning for many years now.  It provides a simple way to manage syncing data that might need to be disconnected from the original source -- pushing data out for external web app data access for instance.  We would like to implement Branch Versioning on our master editing database to take full advantage of feature service editing capabilities including version management and validation.  It seems that Branch Versioning DOES NOT support the typical replication of old.  It would be rather helpful to see this implemented.

The, not-desirable, workaround for this is to create a schema copy of a database, and use scripting to truncate/append data out to these external databases -- this is a bit of a data management problem. 

Thanks!

[RussellBrennan]

Hi @MichaelSnook 

Are you looking for geo-database replication or standard database replication? It would be helpful for us to make sure we  are understanding what you are looking for.

Would you be able to contact me via PM? I have some more follow up questions about your workflows that I would like to ask you in order to get a better understanding of your constraints.

[JerryOrnelas]

Hello Michael/???

We have several national datasets that we replica from on-premise to other locations including AWS RD's.    

We depend on Traditional Versioning to do replica's, can you tell me Branched Versioning has some sort of Source To Target Sync/Replica functionality.   

It doesn't have to be a two way replica, mainly from one Parent to another disconnect Child using SDE PostGreSql Branched Versioning.

Any feedback would be apprecated.

[VanessaSimps]

I realize this is an old post, but I am hoping someone can help me out here. 

our current set up is a production gdb where editors edit. Nightly, these edits are pushed to a publication gdb using a one way geo-database replication. Not only is the publication database where we publish our data from, it is also where we have several sql query/views written with our GIS data that was replicated over from our production database. 

We are currently in the process of migrating to Trace Network/UtlityNetwork. Which means we have to use Branch versioning in our production database. BUT, I am reading here that we can't use branch versioning and geodatabase replication together. 

What is the suggested workflow supposed to look like now? Am I missing something here? Am I supposed to use and ETL like FME or Python to move the data I need from one gdb to another?

Thanks in advance for any clarification that can be provided here!

Vanessa

[DasheEbra]

Hi @VanessaSimps ,

I've encountered a similar challenge with a previous employer, and while there were potential solutions, they didn't quite meet production standards. Let's explore some options together:

1. Offline Editing:

   • While offline editing allows for data manipulation without direct network access, it's not ideal for Utility Network situations. Downloaded maps have a simplified schema, lacking full Utility Network functionality.

2. FME/ArcGIS Data Interoperability:

   • This option supports editing in a disconnected environment, particularly with child branch versions. However, thorough testing is needed to ensure seamless synchronization with the production environment.

Mohamed El-Saket
Esri Certified Professional

[VanessaSimps]

@DasheEbra - thanks for the reply. I started to think about this a bit more after posting. I think the ETL- FME process might work for what I will test out. I could pull the portal item from the branch versioned data down nightly using FME and continue with my existing publication database set up. This may not be the final process, but it will buy me and staff time to rework the SQL query views we have built to instead use the ArcGIS REST API 

I am going to test this out over the next few months and see how things go. I will try to report back here if I remember to let folks know what we came up with. I am sure we aren't the only ones in this predicament.