Disconnected geodatabase replication

03-07-2014 08:17 AM
New Contributor III
Hi all,

I need to synchronize an SDE database (ArcSDE 10.2) on my server with a file geodatabase on a client server on a daily basis.

My simplistic design is as follows:
1.  create a replica locally on my server using python or arcobjects
2. Copy the replica  to the client server using FTP.
3. Import data from replica to file geodatabase on client server using python or arcobjects

Has anyone got experience implementing similar design. Any problems encountered.
O are there other options I could explore for disconnected replication?

Many Thanks
0 Kudos
1 Reply
MVP Regular Contributor
You do need disconnected replication, and your design is correct at a high level.  From what you are indicating, it seems like your server and your client server are not on the same network and can only exchange information via FTP.  My recommendation is that you set up one-way, parent-to-child replication where your child is a file geodatabase.  Using the disconnected replication tools, you will be able to produce an XML document to build your initial replica, then create data messages (e.g., change packets) from the parent, ship them to your client server via FTP, apply them to your child replica thereafter, and send back acknowledgements from the child to the parent.  Eventually, parts of this workflow (or all of it depending on our FTP capabilities) can be automated once you feel comfortable with everything. 

If I have your configuration generally correct, then here's how I would approach things:

1. Identify the feature classes that you would like to have participate in the replica, then add Global IDs to them via ArcCatalog.  If any of those feature classes exist in a feature dataset, you'll have to add global IDs at the feature dataset level.  Add global IDs to any tables that will need to participate as well, all of which need to be registered with the geodatabase.  Every object class participating in replication must be registered as versioned, and every object class must be editable (in other words, the owner of the replica... the user account in the SDE connection file you use to pick your participating data... must have RW privileges on the base tables and any delta tables).  Also, make sure your SDE connection file uses the transactional version from which you want to create the replica to begin with, typically SDE.DEFAULT is sufficient for most organizations. 

2. Create an empty file geodatabase (it needs to exist beforehand) and then use the Create Replica Wizard from the Distributed Geodatabase toolbar in ArcGIS Desktop in order to produce an XML document:

3. Once the XML document is created, move it from your server to your client server via FTP (you may want to zip it depending on its size) and import it into your empty file geodatabase:

4. After versioned edits are made in the parent and then reconciled and posted, you can export a data message on your server which is essentially an XML change packet containing attribute and geometry edits (also, some very basic schema changes are allowed depending on how you have created and configured your replica):

5. Copy or move the XML data message from your server to your client server via FTP. 

6. From ArcGIS Desktop on your client server, import the data message XML file into your child replica:

7. From ArcGIS Desktop on your client server, export an acknowledgement XML file which is what will be used to tell your parent replica that the child replica now matches and contains the correct generation number:

8. Copy or move the XML acknowledgement file from your client server to your server via FTP.

9. From ArcGIS Desktop on your server, import the acknowledgement XML file from the client server:

This completes a full round of the replication process and synchronization process. 

I actually see this being eventually automated into three (possibly two) scripts:

Script A: Uses Python (arcpy) and basic FTP commands via command prompt to achieve steps 4 and 5, and runs on your server possibly as a scheduled task. 
Script B: Uses Python (arcpy) and basic FTP commands via command prompt to achieve steps 6 through 8, and runs on client server possibly as a scheduled task. 
Script C: Uses Python (arcpy) to achieve step 9, and runs on your server possibly as a scheduled task. 

Scripts A and C might be able to be combined into one script.  Also, steps 1 through 3 are manually performed one time and aren't part of the repetitive workflow thereafter. 

If your FTP server only accepts SFTP (different than FTPS), you will need a third-party SFTP utility that can handle scripted commands.  There are some free ones out there.
0 Kudos