TIBCO ESB实战系列：TIBCO数据库适配器双向数据同步解决方案

作者：任成钢 来源：TechTarget中国 原文：http://www.searchsoa.com.cn/showcontent_48908.htm 【TechTarget中国原创】 首先声明，我不是某个厂商的托儿，只是就自己目前从事的咨询工作经验，希望能为大家提供一种参考。下面就给大家介绍一下一个基于TIBCO

作者：任成钢 来源：TechTarget中国
原文：http://www.searchsoa.com.cn/showcontent_48908.htm

【TechTarget中国原创】首先声明，我不是某个厂商的托儿，只是就自己目前从事的咨询工作经验，希望能为大家提供一种参考。下面就给大家介绍一下一个基于TIBCO数据库适配器的双向数据同步解决方案。

　　工作原理

　　TIBCO数据库适配器(TIBCO Adapter for Active Database)，简称ADB，是一款非常优秀的关系型数据库数据发布与订阅适配器产品，结合TIBCO的其他应用集成产品(比如TIBCO BusinessWorks、TIBCO EMS等)，能够通过简单的配置，就能够实现同构或者异构数据库之间的数据同步应用。TIBCO ADB的工作原理如下：

　　ADB数据发布：

　　ADB在源数据表的数据库中，根据源表的格式建立发布表，并在源表上建立触发器，监测源表的数据变化（增删改），并将变化的数据插入到发布表中，ADB Agent会定时查询发布表（表中有一个发布状态标志，未发布的数据，即新数据状态为N），并将新插入发布表的数据发布出去(数据发布后，发布状态变为C)。发布的数据将由ADB Agent转换成消息发送给订阅方(TIBCO BW或者ADB订阅服务)。

　　ADB数据订阅：

　　ADB在目的数据表的数据库中，根据目的表的格式建立异常表，ADB Agent接收到发布方（TIBCO BW或者ADB发布服务）发送的消息，将其转换为数据，并根据数据中的操作标识（增删改），直接写入目的表中。当出现数据操作异常时，比如主键重复，数据类型错误等，造成目的表更新失败，会将错误的数据记录到异常表中。

　　在配置ADB发布和订阅过程中，建立的表和触发器都由ADB自动完成，并提供脚本，用户可以根据需要进行修改。

　　双向数据同步

　　在进行数据同步类应用的实施过程中，经常会遇到双向同步的问题，比如两个数据库，任意一个数据库中的数据发生变化，都需要将数据同步给另一个库。这种情况下如果不进行限制，可能会出现数据同步循环问题，两边的数据不断的更新，不断的触发新的数据发布。幸运的是ADB提供了循环监测功能(Loop Detection)，防止这种循环更新的发生。循环监测的原理如下：

　　ADB在源表中增加了一个的特定字段(ADB_SOURCE)，触发器会监测这个字段，如果该字段是由ADB的订阅服务更新的，则触发器不会将更新的数据插入发布表；如果该字段在数据更新时没有更新，则此数据是应用更新的，触发器会将数据插入到发布表，由发布服务进行发布。如下所示：

以下是引用片段：
CREATE OR REPLACE TRIGGER TRI_P_FILE AFTER INSERT OR DELETE OR UPDATE ON TAB_FILE
FOR EACH ROW
DECLARE
updating_key_fields EXCEPTION;
BEGIN
IF :NEW.ADB_SOURCE = 'T' THEN return;
END IF;
IF INSERTING THEN
INSERT INTO P_STD_FILE_BACK VALUES (
:NEW.FILE_ID,
:NEW.FILE_NAME,
……
END TAB_FILE;
/

　　利用这个新增的字段，限制触发器对发布表的更新，有效的限制了数据的循环更新问题。

　　新的挑战

　　但是在最近的一次实施中，遇到了新的问题。一家大型集团，有很多相对独立的子部门（公司），集团总部推广了一套系统，这套系统是各个单位（包括集团总部和子部门）独立部署的，并要求各个单位之间实现数据的实时/准实时同步，数据的更新可能发生在任何一个单位，其他的单位都需要接收到更新的数据并写入自己的数据库，形成双向同步。这种场景非常适合使用应用集成产品，我们向客户推荐了TIBCO BusinessWorks、TIBCO ADB，并使用TIBCO EMS作为消息服务器。但是在处理数据双向同步问题上，客户提出了更高的要求，这套系统已经开发并在部分单位运行了多年，按照TIBCO ADB默认的在源表增加字段的方式来处理双向同步情况，目前的系统可能会出现问题，他们也不想对现有的系统进行修改，所以要求不能修改源表的表结构。

　　解决方案

　　为了解决这个问题，我们提出了如下的解决方案：

　　客户使用的数据库为Oracle数据库，基于Oracle的一些特性，我们不再使用增加字段的方式进行循环监测，改成采用区分用户的方式。即ADB操作Oracle数据表采用与业务系统不同的数据库用户，比如业务系统使用的数据库用户为business，ADB使用tibco。
然后对ADB生成的触发器脚本进行修改，加入如下(红色字体)的判断：

以下是引用片段：
CREATE OR REPLACE TRIGGER TRI_P_FILE AFTER INSERT OR DELETE OR UPDATE ON TAB_FILE
FOR EACH ROW
DECLARE
updating_key_fields EXCEPTION;
BEGIN
IF USER = 'TIBCO' THEN RETURN;
END IF;
IF INSERTING THEN
INSERT INTO P_STD_FILE_BACK VALUES (
:NEW.FILE_ID,
:NEW.FILE_NAME,
……
END TAB_FILE;
/

　　由此判断如果更新数据的用户是tibco，则当前数据时由ADB订阅服务进行更新的，不需要插入发布表进行发布（因为所有ADB订阅服务的数据来源都是其他的ADB发布服务）；如果是非tibco用户，则数据是由业务系统进行更新的，需要插入发布表进行发布。

　　通过上述方法，即可以不必修改数据结构实现双向数据同步的中的循环监测，避免循环更新。

　　使用此种解决方案，要注意如下几个问题：

　　首先要为ADB使用的数据库用户赋予CONNECT和RESOURCE角色，并赋予CREATE ANY TRIGGER权限

　　其次要为ADB使用的用户赋予业务表的操作权限，比如：

以下是引用片段：
　　grant select, insert, update, delete on TAB_FILE to TIBCO;

　　该操作由业务系统用户执行

　　然后为了更方便的再业务表上建立触发器，要为业务表建立同义词，比如：

以下是引用片段：
　　create synonym TAB_FILE for BUSINESS. TAB_FILE;

　　该操作由ADB操作用户执行

　　最后使用ADB操作用户执行由ADB生成的发布表、异常表和触发器的脚本。

　　至此，双向数据同步解决方案就此完成，完美的解决了客户提出的问题。