当前位置:Gxlcms > mysql > TIBCOESB实战系列:TIBCO数据库适配器双向数据同步解决方案

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

时间:2021-07-01 10:21:17 帮助过:57人阅读

作者:任成钢 来源: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生成的发布表、异常表和触发器的脚本。

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

人气教程排行