Synchronize disconnected replicas

Available with Standard or Advanced license.

Disconnected synchronization is the process of manually synchronizing replicas to transfer data in a disconnected environment. This manual process of exchanging messages is achieved by exporting a message from one replica to a file and importing the message from the file to the relative replica.

See the disconnected synchronization workflow.

Note:

All aspects of disconnected replication and synchronization can be performed by exchanging files containing messages between the replica pairs. These messages can be used to perform several tasks and can be exchanged using either a file geodatabase (.gdb) format or an XML file (.xml) format:

• Replica creation (.gdb or .xml)
• Data change (synchronization) messages (.gdb or .xml)
• Acknowledgement messages (.xml)

In disconnected environments, .gdb or .xml files can be transported on media such as external storage devices (for example, USB drives, SD and memory cards, external hard drives, and CDs or DVDs) and sent using a distribution agent such as email, a private courier, or parcel delivery services.

At any time, a replica can be either a data sender or a data receiver. A data sender exports data change messages to delta files that contain changes to be applied to the relative replica. A data receiver imports data change messages and exports acknowledgment messages to acknowledgment files to confirm what it has received. You can determine whether a replica is a data sender or a data receiver by checking the replica status located on the replica card in the Manage Replicas pane. See Access the Manage Replica pane for an overview of the Manage Replicas pane.

Disconnected synchronization workflow

For replicas in a disconnected environment, synchronization is achieved through a process of manually exchanging messages between replicas. This manual process of exchanging messages is accomplished through the use of a combination of several geoprocessing tools and follows a basic disconnected synchronization workflow pattern, which is described and illustrated below.

1. Edits are completed.

   Edits are completed and saved in the geodatabase (Geodatabase 1).

   

2. Export data changes from the data sender.

   In this workflow example, an orange triangle, also referred to as a delta, is used to represent the data changes or differences.

   

   The data sender uses the Export Data Change Message geoprocessing tool to export all new data edits from the parent replica to a data change message that can be stored either in a file geodatabase (.gdb) or an XML file (.xml) format.

   Note:

   In disconnected environments, .gdb or .xml files can be transported on media such as external storage devices (for example, USB drives, SD and memory cards, external hard drives, and CDs or DVDs) and sent using a distribution agent.

   For more information on using this tool, see Export a data change message.

3. Data receiver imports the data change message.

   The data receiver uses the Import Message geoprocessing tool to import the data change message file stored either in a file geodatabase (.gdb) or XML file (.xml) format to the data receiver replica (Geodatabase 2).

   

   For more information on using this tool, see Import a data change message.

   Importing a data change applies data changes from the relative replica and also updates the replica's metadata.
4. Export an acknowledgement message.

   Once the data receiver imports the data change message, the data receiver uses the Export Acknowledgment Message geoprocessing tool to send an acknowledgment message back to the data sender (Geodatabase 1).

   

   Note:

   Because the data sender is not in a connected environment with the data receiver, the data sender does not know that the data change was received and imported by the data receiver. Therefore, it is important for the data receiver to export and send acknowledgment messages as often as possible. If no acknowledgment messages are received, the data sender resends changes by default and maintains the information needed to resend changes until it receives an acknowledgement that those changes were received by the relative replica. As a result, the data sender's geodatabase can become large, and subsequent data change messages can also become large.

   An ideal, although not required, practice is for the data receiver to send an acknowledgment message after receiving each data change message. It is also important to note that one acknowledgment message acknowledges all data change messages. For example, if a replica receives three data change messages and imports each, it can send a single acknowledgment message to acknowledge all three.

   For more information on using this tool, see export an acknowledgement message.

5. Import the acknowledgement message.

   The data sender uses the Import Message geoprocessing tool to import the acknowledgment XML message and updates the data sender replica's metadata (Geodatabase 1) so that it knows what changes to include in the next export.

   

   For more information on using this tool, see Import a data change message.

Tip:

Use the generation information on the Advanced tab of the Replica Properties dialog box to determine if messages have been exported and imported to the related replicas.

So far, this topic has described a basic disconnected synchronization workflow pattern in which messages are sent back and forth between the parent replica and the child replica. If you continue with this pattern, the system will function efficiently and even correct itself if messages are lost.

However, you may also want to consider the following specific message exchange scenarios described in the sections below.

Switch roles

In two-way replicas, the data sender and data receiver can switch roles. The switch is initiated by the data sender when it sends a data change message that includes instructions to switch roles. Once the message has been imported by the data receiver, the roles are switched, and the system is ready to send data in the opposite direction.

With one-way replicas, however, you cannot switch roles as edits and data changes flow in one direction only. For one-way parent to child replicas, the parent replica is always the data sender. For one-way child to parent replicas, the child replica is always the data sender. In either case, it is still important for the data receiver to send acknowledgment messages. For checkout replicas, the child replica is always the data sender, and no acknowledgment messages are needed. For more information on the various types of replicas, see Replication types.

The following steps and diagrams show the parent replica sending a data change message with instructions to switch the role of the relative replica to that of the data sender.

1. Ensure you are connected to a two-way replica.

   

2. To switch roles, the data sender uses the Export Data Change Message geoprocessing tool to export a data change message with the switch to receiver once the message has been exported option checked.

   When the parent replica exports the data change message containing these instructions to switch roles, it then becomes the data receiver.

   

   Note:

   When using the Export Data Change Message tool to switch roles, there is an additional option that can be checked, Don't include any data change messages, that is useful for sending a message to switch roles without sending any data. For more details on this option, see Switch roles without sending data changes.

3. The data receiver uses the Import Message geoprocessing tool to import the data change message file containing the instructions to switch roles.

   Once the import has completed, it becomes the data sender.

   

Switch roles without sending data changes

It is possible to send a data change message with instructions to switch roles but without any data changes. You may want to do this if, as the data sender, you need to get changes from the data receiver but are not ready to send data changes. See Export a data change message for more information about sending a message to switch roles without sending any data.

Acknowledge changes after switching roles

After switching roles in a two-way replica, there are two options available for the new data sender to acknowledge the message that switched the roles.

• The new data sender can export an acknowledgement message—In the following diagram, the parent replica sent a data change message that switched roles. When the child replica received the message, it became a data sender, but since it had just switched roles, the system still allows it to send an acknowledgment message using the Export Acknowledgment Message geoprocessing tool.

  

• The new data sender can send a data change message—In the following diagram, the parent replica sent a data change message that switched roles. When the child replica received the message, it became a data sender. Using the Export Data Change Message geoprocessing tool, the child replica can now send a data change message, which implicitly acknowledges the previous data change message from the parent replica. If you don't plan on sending a data change message in the near future, you should send an acknowledgment message.

  

Reexport an unacknowledged data change message

The system allows replicas to resend unacknowledged data changes. You may want to do this when, as a data sender, the data change message either was not imported by the data receiver, was lost in transit, or needs to be resent. Another option is to wait until the next time you send data changes, since by default, this includes both new changes and any unacknowledged changes.

The following diagram shows a case where you need to reexport an unacknowledged data change message. Here, the parent replica sends a data change message and switches from sender to receiver. The message, however, gets lost, leaving both the parent replica and the child replica as data receivers. To solve this issue, the data receiver that has just switched roles uses the Re-export Unacknowledged Messages geoprocessing tool. In this case, it allows the parent replica to resend the unacknowledged data change message along with the switch roles to the child replica.

Bypass the acknowledgment message file

When sending data changes, all new data changes and unacknowledged data changes are sent by default. New changes are any inserts, updates, and deletes applied to the replica version since the last data change message was exported. Unacknowledged data changes include previously exported changes for which you have not received an acknowledgment. If you have sent several data change messages for which you have not received an acknowledgment, the data change files can become large.

The best solution is for the data receiver to send an acknowledgment message file. However, depending on the communication system, this may not always be possible. For example, if the replicas are disconnected and sending an acknowledgment file requires shipping media to exchange files, you may prefer to send an email to the person managing the data sender replica stating that you received and imported the data changes.

Be aware, though, that bypassing the acknowledgment message file complicates synchronization management.

• Importing acknowledgment messages is the only way for the system to drop system versions required to resend changes for a replica. Undropped system versions can hinder compression over time, make the sender's geodatabase large, and potentially slow geodatabase performance. For this reason, it is still important to at least periodically use acknowledgment messages.
• Bypassing the acknowledgment message file results in the need for more manual intervention on the part of both the person managing the data sender replica and the person managing the data receiver.

  You can use the replica card on the Geodatabase Replicas tab in the Manage Replicas pane to determine what changes have been sent and received by a replica. To keep from sending a needlessly large data change message, the data sender can uncheck the Include unacknowledged data changes option the next time data changes are sent.

• When you bypass the use of the acknowledgment message file, your synchronization workflow is more prone to error.

  New changes can be imported by the data receiver only if the previous changes were imported. If the system detects that previously sent changes have not been imported, an error is returned and the current set of changes cannot be imported. If several data change messages are sent at once, they must be imported in the correct order. The system will return an error if you attempt to import in an incorrect order. When errors occur, error messages are provided. However, if using an automated system, you may not be present to see the errors. In this case, you can use the replica activity log to detect whether errors have occurred during synchronization.