Now you want to look at where the data changes will originate and where these changes need to be sent to allow users to access.
- Will the changes only be made at one site?
- At what sites will data changes be made?
- Are these sites where changes are not allowed at the site, but will receive changes from other sites?
- Will a site have to pass changes that it receives from an originating site to other sites?
- Are there any special handling rules at each individual site depending on what data is received and from where?
Part of this step is also to determine if the change flow is unidirectional or bidirectional. A unidirectional change flow means that between two sites, changes are only made at one site and sent to the other site. A bidirectional change flow means that changes can be made at either of the two sites and are sent to the other site.
Network pathing is also essential to your design. In many systems, there may not be a direct network connection between the source and target database. The network topology may require routing the Propagation through an intermediate database. This is known as a directed network environment. While the intermediate database may be used to route the change, you may or may not need or want to apply the change at that database. If the change is not applied but "passed" to another database; this is known as a "pass-through" transaction.
Again, understanding where changes are being made, sent, and applied will help you determine how much configuration work you will have ahead of you. You will identify any special handling rules that will need to be defined at each site. This step dictates which sites must be configured for capture, which sites to configure propagation, and which sites must be configured for apply. You also take it down a level by determining any special tagging and/or transformation and handling rules that need to be defined and coded for each of the capture/propagate/Apply processes and directed networks.