This section is an unusual but important one: it tells you where IBM Replication can be used, but where it is recommended that care be taken in designing the system. The scenarios described in this section are complicated and difficult to implement as first replication projects.
IBM Replication supports update-anywhere replication, in which multiple copies (or replicas) of the same source table are synchronized and each replica can be a source of updates to the source table and the other replicas. This scenario allows you to set up circular subscriptions, where Table A updates Table B and Table B updates Table A. Customers can have a global database that updates and is updated by multiple replica target tables at multiple sites, such as bank branches or a mobile sales force.
Update-anywhere replication scenarios work best when transaction conflicts between the global database and the replicas can be avoided, such as when replicas can update only key ranges at specific sites, or when sites can make updates during certain time periods.
Conflict detection is provided at three levels and can be a data integrity and performance issue that should be well planned. See "Update-Anywhere Replication" for more planning information.
IBM Replication can capture both before and after images of any update captured and the correlation ID (if using Capture for MVS) or the authorization ID of the user that performed the update. Using this information, it is possible to write some code that can "undo" updates that have been made to a given table. This approach could prove useful in the event of a rogue batch application incorrectly updating data. You may want to undo its updates but not the updates of any other application. However, care is required as the integrity of the database could be jeopardized if the application processing is not fully understood.
There are occasions when the data transformation required between source and target tables is so complex that IBM Replication cannot provide an end-to-end solution. In general, if the manipulation can be achieved with SQL, then IBM Replication can perform the translation for you. The use of SQL extends to procedural logic on some database platforms. DB2 Universal Database triggers and user-defined functions and triggers can be a part of the SQL invoked to perform the transformations.
Alternatively, it is reasonably easy to develop user code to read CCD tables populated by IBM Replication, perform any transformations required, and then apply the changes to the target tables. See "Defining SQL Statements or CALL Procedures for the Replication Subscription" for more information about using stored procedures before or after the changes are applied to the target tables.