Available with Standard or Advanced license.
To synchronize replicas in a disconnected environment, you must exchange messages manually. This is achieved by exporting a message from one replica to a file and importing the message from the file to the relative replica. In disconnected systems, files can be transported on media, such as CDs or DVDs, and sent via a distribution agent such as a private courier, USPS, and so on.
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 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 in the Replica Manager in ArcMap. See A quick tour of replica management for information on Replica Manager.
It is important for the data receiver to export 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 those changes are acknowledged. 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.
The following shows the parent replica sending changes to the child replica and receiving an acknowledgment message from the child. Here, the parent is the data sender, and the child is the data receiver.
In two-way replicas, the data sender and data receiver can also switch roles. The switch is initiated by the data sender when it sends a final 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.
The following diagram shows the parent replica sending a data change message with instructions to switch roles. When the parent replica exports the message, it becomes the data receiver. When the child receives the message, it becomes the data sender. The child replica then sends a data change message to the parent.
As mentioned previously, two-way replicas use data change and acknowledgment messages and can switch roles. With one-way replicas, however, you cannot switch roles. For one-way parent to child replicas, the parent is always the data sender. For one-way child to parent replicas, the child 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 is always the data sender, and no acknowledgment messages are needed. For more information on types of replicas, see Replication types.
So far, this topic has described a basic message exchange 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 properly and even correct itself if messages are lost. However, you may also want to consider the following specific message exchange scenarios.
Resending unacknowledged messages
The system allows replicas to resend unacknowledged data changes. You may want do this when, as a data sender, you either know or suspect that an earlier data change message has been lost and 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 resend unacknowledged data changes. Here, the parent sends a data change message and switches from sender to receiver. The message, however, gets lost, leaving both the parent and the child as data receivers. To solve this issue, the option to re-export unacknowledged messages is available to the data receiver that has just switched roles. In this case, it allows the parent to resend the message to switch roles to the child.
Acknowledging changes after switching roles
After switching roles in a two-way replica, the option to export an acknowledgment message is available for the data sender to acknowledge the message that switched the roles. Another option is to send a data change message, since it will implicitly acknowledge this message. If you don't plan on sending a data change message in the near future, however, you should send an acknowledgment message.
In the following diagram, the parent sends a data change message that switches roles. When the child receives the message, it becomes a data sender, but since it has just switched, the system still allows it to send an acknowledgment message.
Switching 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 Exporting a data change message for more information on sending a message to switch roles without sending any data.
Bypassing 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 might 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 manager 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 must uncheck the option to Include unacknowledged data changes the next time he or she sends data changes.
- 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 previous changes truly 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. The log also provides instructions on how to recover when appropriate.