CN103020147B - 数据集成系统和数据集成方法 - Google Patents

Abstract

本发明提供了一种数据集成系统和数据集成方法，数据集成系统包括：第一事务适配器，用于在第一系统进行业务操作时，调用事务运行引擎装置和事务补偿装置；事务运行引擎装置，为业务操作建立业务流程，若业务流程被配置为支持全局事务，则为业务流程创建全局事务上下文；事务补偿装置，用于记录全局事务的状态，以及根据第二事务适配器捕获的调用情况更新全局事务的状态；第二事务适配器，针对每一个业务操作，提供第二系统的服务，捕获调用情况并根据调用情况在本地事务中记录调用结果。本发明通过事务适配器收集每一个事务型操作的事务状态和执行结果，及时发现不一致的数据记录，给予自动补偿，以保证多个系统集成时数据的一致性。

Description

数据集成系统和数据集成方法

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种数据集成系统和一种数据集成方法。

背景技术

随着企业业务的不断发展，企业规模不断扩大，经营策略不断深化改进，企业对信息化系统的要求越来越高，信息化所覆盖的领域也越来越广，企业的信息化建设从核心财务系统、供应链及生产制造系统，发展到资产管理、预算管理、资金管理、HR管理等，并逐渐延伸到侧重企业间协同的电子商务系统建设。

企业在建设这些系统的过程中，为了控制IT系统建设的风险（不能将鸡蛋放在一个篮子里），也因为市场上任何一家软件供应商都很难提供覆盖企业经营活动全生命周期的产品，往往会在各自领域相应选择具备独特优势的IT系统供应商。这样选择的结果就是企业内会出现多个独立的信息系统。

即便某个企业因各种原因短时间内在所有领域均选择使用同一厂商的系统，往往也会因为不同业务系统更新换代的频率不同，比如财务系统往往不用频繁升级，而电子商务系统为了快速响应市场变化往往需要快速的改进业务流程或发布新的功能，从而导致同一厂商开发的系统也会出现版本差异，需要独立的开发和维护多个系统（各自配置独立的数据源和运行环境）。另外一种情况就是由于企业内经营业务不同，地理位置限制，即使同一厂商的产品，往往也会采用异地分布式部署的方案。

还有一些企业结构庞大，管理关系复杂（重组、并购、加盟等等），企业内本身就存在各种已经投产的IT系统。另外有一些企业的分支机构往往还根据自身需要而采用贴近本组织业务需要的特定软件解决方案。

以上众多原因都会导致企业内出现多个独立部署的信息系统。不同的应用系统虽然满足了企业在各个领域及局部范围内的需求，但往往随着时间推移，会在企业内形成信息孤岛。信息孤岛使得企业内的数据无法被有效共享，无法从企业全局范围内挖掘有效信息，业务功能重复建设，业务流程不通畅（如订单系统和供应链、财务系统间往往需要集成以满足企业财务业务一体化的要求，能够管理到从下单到订单从发货、到出库、签收、到财务对账的全流程，再比如WMS系统的库存和供应链系统库存的统一管理等等），无法根据经营需要快速变更业务流程。如何快速、灵活的实现各种异构系统互联互通，有效整合现有软件资产，构建随需应变的跨系统业务流程是企业面临的巨大挑战。

要实现系统间的集成，目前有很多较为成熟的技术，例如消息中间件、EAI平台及SOA集成平台等。其中基于SOA（Service-OrientedArchitecture，面向服务的体系结构）的集成类平台，通过SCA服务组件技术，将服务、流程、规则、协议进行分离，真正可以达到随需应变的整合目标，已经成为目前集成的主流技术。无论使用哪种技术，都会面临一个无法回避的问题，那就是：多个系统间如何保证数据一致性？与一个系统一个数据源时的事务管理不同，多个具有自己独立数据源的系统交互时，我们无法通过传统的如EJB容器管理事务或者通过JDBC事务接口自行管理事务的方式来保证事务的一致性。

目前解决分布式系统事务一致性最典型的做法就是通过两阶段提交技术（Java体系基于此，相应的提出了JTA的分布式事务接口）。要实现两阶段提交，首先全局事务的数据源必须支持XA特性，也就是说如果某个业务流程处于一个全局事务内，而且对多个系统有事务操作（资源变更），则需要实现和配置所涉及系统的数据源（事务适配器、JMS或JDBC连接池）以支持XA。而且与本地事务相比，XA协议的系统开销相当大，因而在很多生产系统中应当慎重考虑是否确实需要分布式事务。

还有些系统在集成时，不做分布式事务配置和控制，完全依靠事后对各系统数据做人工校验和补偿，这样的校验往往工作量巨大，效率很低。有些专利技术或工程实践则是针对特定系统特定业务，专门开发数据核对工具或者界面，把技术问题转化为业务解决，虽然在某些场景下是很好的解决方案，但面对纷繁复杂的业务，这种做法毕竟不是一个通用的做法，一旦出现新的集成流程，往往就需要投入新的开发资源，开发成本很高；另外一些专利技术侧重容错及状态恢复，尝试通过简单方式保证分布式系统间数据的可靠性，但缺乏整个事务控制的概念，无法灵活定制事务控制策略，应用场景有限。

发明内容

本发明正是基于上述问题，提出了一种数据集成技术，可有效解决多系统集成时事务一致性的问题。

有鉴于此，根据本发明的一个方面，提供了一种数据集成系统，用于第一系统和第二系统之间的数据同步，包括：事务运行引擎装置、事务补偿装置、第一事务适配器和第二事务适配器，其中，第一事务适配器，安装于所述第一系统处，用于在所述第一系统进行业务操作时，调用所述事务运行引擎装置和所述事务补偿装置；所述事务运行引擎装置，为所述业务操作建立业务流程，若所述业务流程被配置为支持全局事务，则为所述业务流程创建全局事务上下文；事务补偿装置，用于记录所述全局事务的状态，以及在所述业务流程运行结束时，根据所述第二事务适配器捕获的调用情况更新所述全局事务的状态；第二事务适配器，安装于所述第二系统处，针对所述全局事务中的每一个业务操作，提供所述第二系统的服务，捕获所述调用情况并根据所述调用情况在创建的本地事务中记录调用结果。

因此，在保证数据一致性的前提下，本发明不做全局事务的锁控制，不需要参与全局事务的资源必须支持XA协议，同时避免了全局事务在两阶段提交时加锁所带来的性能损耗。

在上述技术方案中，优选的，事务运行引擎装置还用于为所述全局事务创建全局事务标识；所述事务补偿装置还用于新增对应于所述全局事务标识的状态记录，所述状态记录包括所述全局事务的状态和所述全局事务中每一业务操作的状态，所述全局事务中每一业务操作的状态来自所述第二事务适配器。

该事务适配器可嵌入每个第三方系统中，并可准确收集每一个事务型操作的事务状态和执行结果，以供事务补偿装置处理。

在上述技术方案中，优选的，所述事务补偿装置还用于在所述全局事务中所有业务操作的状态不一致时，对处理失败的业务操作进行补偿处理。

事务补偿装置可根据一个全局事务中各事务型操作的结果，进行对比，准确及时地发现不一致的数据记录，给予自动补偿，在自动补偿不能完整恢复数据一致性的情况下，还可预警给系统管理员，系统管理员可根据提示进行批量补偿操作，从而保证多个系统集成时数据的一致性。

在上述任一技术方案中，优选的，所述第二事务适配器还用于在接收到来自所述第一事务适配器的调用请求后，根据所述调用请求新建所述本地事务，在所述本地事务被成功提交后，开启另一个本地事务。

在上述任一技术方案中，优选的，所述第二事务适配器还用于在所述另一个本地事务外围监测异常情况，在出现异常情况时，回滚所述另一个本地事务，并新建其他本地事务，根据异常情况的类型更新所述调用结果以及提交所述其他本地事务。

根据本发明的另一方面，还提供了一种数据集成方法，用于第一系统和第二系统之间的数据同步，包括：步骤1202，在所述第一系统进行业务操作时，通过安装于所述第一系统处的第一事务适配器调用事务运行引擎装置和事务补偿装置，通过所述事务运行引擎装置为所述业务操作建立业务流程，若所述业务流程被配置为支持全局事务，则为所述业务流程创建全局事务上下文，通过事务补偿装置记录所述全局事务的状态；步骤1204，针对所述全局事务中的每一个业务操作，调用所述第二系统通过第二事务适配器提供的服务，所述第二事务适配器安装于所述第二系统处，捕获调用情况，由所述第二事务适配器在创建的本地事务中记录调用结果；步骤1206，在所述业务流程运行结束时，所述事务补偿装置根据所述调用情况更新所述全局事务的状态。

因此，在保证数据一致性的前提下，本发明不做全局事务的锁控制，不需要参与全局事务的资源必须支持XA协议，同时避免了全局事务在两阶段提交时加锁所带来的性能损耗。

在上述技术方案中，优选的，所述步骤1202还包括：通过事务运行引擎装置为所述全局事务创建全局事务标识，在所述事务补偿装置中新增对应于所述全局事务标识的状态记录，所述状态记录包括所述全局事务的状态和所述全局事务中每一业务操作的状态，所述全局事务中每一业务操作的状态来自所述第二事务适配器。

事务补偿装置可根据一个全局事务中各事务型操作的结果，进行对比，准确及时地发现不一致的数据记录，给予自动补偿，在自动补偿不能完整恢复数据一致性的情况下，还可预警给系统管理员，系统管理员可根据提示进行批量补偿操作，从而保证多个系统集成时数据的一致性。

在上述任一技术方案中，优选的，在所述全局事务中所有业务操作的状态不一致时，对处理失败的业务操作进行补偿处理。

在上述任一技术方案中，优选的，在所述第二事务适配器接收到来自所述第一事务适配器的调用请求后，根据所述调用请求新建所述本地事务，在所述本地事务被成功提交后，开启另一个本地事务。

在上述任一技术方案中，优选的，在所述另一个本地事务外围监测异常情况，在出现异常情况时，回滚所述另一个本地事务，并新建其他本地事务，根据异常情况的类型更新所述调用结果以及提交所述其他本地事务。

本发明通过嵌入在每个第三方系统的适配器准确收集每一个事务型操作的事务状态和执行结果，然后事务补偿装置可根据一个全局事务中各事务型操作的结果，进行对比，准确及时地发现不一致的数据记录，给予自动补偿，在自动补偿不能完整恢复数据一致性的情况下，还可预警给系统管理员，系统管理员可根据提示进行批量补偿操作，从而保证多个系统集成时数据的一致性。

附图说明

图1A示出了根据本发明的实施例的全局事务示意图；

图1B示出了根据本发明的实施例的SCA组件结构图；

图2示出了根据本发明的实施例的业务流程示意图；

图3示出了根据本发明的实施例的SCA组件组合与调用关系示意图；

图4示出了根据本发明的实施例的数据集成系统的框图；

图5示出了根据本发明的实施例的数据集成系统的框架图；

图6示出了根据本发明的实施例的数据集成系统中各装置之间的交互流程图；

图7示出了根据本发明的实施例的全局事务处理过程的流程图；

图8示出了根据本发明的实施例的事务型操作本地事务内部结构图；

图9示出了根据本发明的实施例的事务适配器工作原理图；

图10示出了根据本发明的实施例的事务补偿装置的工作流程图；

图11示出了根据本发明的实施例的数据集成系统的原理图；

图12示出了根据本发明的实施例的数据集成方法的流程图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明并不限于下面公开的具体实施例的限制。

在说明本发明的技术方案之前，首先结合图1至图3详细解释在下文中出现的一些关键名词：

1)事务（Transaction）

事务是并发控制的基本单位，事务定义了一个工作单元范围，在这个工作单元内可对资源进行一系列的操作，这些操作要么都做，要么都不做。事务应该具有四个特性：原子性、一致性、隔离性、持续性。这四个属性通常称为事务的ACID特性。

2)事务型操作

事务型操作是指那些在一个事务工作单元中对事务型资源进行变更的操作，如数据库增删改、文件写入、消息队列发送、第三方系统服务调用等等。相应的非事务型操作指的是那些声明不加入到全局事务或者无事务资源变更的操作。

3)全局事务

全局事务指的是在一个工作执行单元内操作多个事务资源，或者说包含了多个事务型操作（如图1A中的操作2、操作3及操作4），并保证整个工作单元的事务满足ACID特性，多个事务型操作能够保证统一提交或者回滚，可以在一个统一的全局事务下协同工作。如图1A所示，一个全局事务里包含多个事务型操作。

从理论角度上说，全局事务的目的是为了保证对多个事务资源的操作能够像操作单一事务资源一样也可以实现事务的ACID特性。实际上，真正要实现跨数据源的全局事务是很困难的，要保证实时绝对一致性，性能就不可避免受到影响。这也是本发明所提供方案所希望进一步解决的问题，在一致性和性能之间到达一个新的平衡。

4)全局事务号（TID）

本发明对每一个全局事务都会有一个唯一的编号，简写为TID。

5)本地事务

如果一个事务工作单元内所有操作关联的都是单一的事务资源，则称该事务为本地事务。

6)服务组件框架SCA

SCA全称Service Component Architecture，即服务组件框架。服务组件体系结构（SCA）是一个规范，它描述用于使用SOA构建应用程序和系统的模型。SCA可大大简化使用SOA进行的应用程序开发和实现工作，以成为SOA体系架构中最总要的规范之一。

7)SCA组件

如图1B所示，在SCA的世界中，一个SCA组件是由接口、服务实现和引用（可选）三个部分构成。其中接口部分表示该组件能提供的业务能力；实现则是实现了该接口的组件；而引用则表示在服务实现中需要调用到的其他服务。

8)业务流程

本发明中的业务流程指的是事务范围内一系列的操作集合，包括事务型操作及非事务型操作。注意：这里的业务流程不仅仅只是大家通常理解的工作流产品中的由多个活动节点构成的图形化配置出来的流程，本发明中的业务流程也可以是包含一系列服务调用的代码集合、一段XML配置等等。因为SCA组件框架里组件是可以通过各种技术实现的。

本发明中所描述的业务流程，无特殊说明，均指那些需要支持全局事务的流程，且整个业务流程基于SCA组件组合而成。

如图2所示，例如需要设计一个业务流程F1，内部包含3个活动，活动1到活动2到活动3，活动2，活动3均加入到全局事务里，活动2对应的业务操作为调用组件C提供的服务，活动3对应的业务操作为调用组件D提供的服务。相应的SCA组件组合方式如图3所示。

9)SCA事务模型

在事务方面，SCA通过在三个部分（接口、服务实现和引用）分别提供不同的限定符来完成事务的定制。通过这三个部分的组合就可以实现细粒度的事务控制。SCA提供的事务描述比传统EJB的事务粒度更细。因此在SCA编程模型中可以对各个组件实现更为精确的事务控制。

举例来说，前面所述的SCA组件C，发布服务S1，调用服务RS1，有如下的事务需求：

1．在运行时候需要有全局事务但不能加入到已有的全局事务中；

2．该组件需要调用到其他的服务RS1，希望RS1也能加入到自己的事务中。

那么在设计组件时，需要配置为：

1．组件C对外提供服务接口S1的事务限定符应该设置为jointransaction=false，这样就防止了该组件加入到上游的事务中。

2．组件C实现上的事务限定符应该设置为transaction=global，这样SCA容器在调用该实现之前就会启动一个全局事务。

3．组件C引用服务RS1上的事务限定符应该设置为suspendtransaction=false，这样，组件实现的事务就被允许传播到被调用的服务。

接口和实现的事务属性一起决定了组件运行时的事务特征。

10)业务异常

业务异常指的是每个第三方系统在通过操作事务型资源时，通过业务校验发现不合法的数据或者不被允许的操作，从而有意抛出的异常。比如在转账时提醒金额不足，在下单时提示库存短缺等等。业务异常在事务处理中的特点是，一旦出现这类异常，无法通过自动重试来解决异常问题，往往需要开发或者实施人员修改配置或者流程。

11)非业务异常

非业务异常指的是SOA平台在发起事务型操作调用的过程中，包括SOA平台和第三方系统通过环节，第三方系统执行事务型操作环节中出现的各种运行时异常，如网络中断、服务器宕机、磁盘空间满、内存溢出等等。非业务异常可以通过重试解决，即一次或多次重试后可以保证原来出现非业务异常的事务型操作执行成功。

图4示出了根据本发明的实施例的数据集成系统的框图。

如图4所示，根据本发明的实施例的数据集成系统400，用于第一系统和第二系统之间的数据同步，包括：事务运行引擎装置402、事务补偿装置404、第一事务适配器406和第二事务适配器408，其中，第一事务适配器406，安装于所述第一系统处，用于在所述第一系统进行业务操作时，调用所述事务运行引擎装置402和所述事务补偿装置404；所述事务运行引擎装置402，为所述业务操作建立业务流程，若所述业务流程被配置为支持全局事务，则为所述业务流程创建全局事务上下文；事务补偿装置404，用于记录所述全局事务的状态，以及在所述业务流程运行结束时，根据所述第二事务适配器408捕获的调用情况更新所述全局事务的状态；第二事务适配器408，安装于所述第二系统处，针对所述全局事务中的每一个业务操作，提供所述第二系统的服务，捕获所述调用情况并根据所述调用情况在创建的本地事务中记录调用结果。

因此，在保证数据一致性的前提下，本发明不做全局事务的锁控制，不需要参与全局事务的资源必须支持XA协议，同时避免了全局事务在两阶段提交时加锁所带来的性能损耗。

在上述技术方案中，优选的，事务运行引擎装置402还用于为所述全局事务创建全局事务标识；所述事务补偿装置404还用于新增对应于所述全局事务标识的状态记录，所述状态记录包括所述全局事务的状态和所述全局事务中每一业务操作的状态，所述全局事务中每一业务操作的状态来自所述第二事务适配器408。

该事务适配器可嵌入每个第三方系统中，并可准确收集每一个事务型操作的事务状态和执行结果，以供事务补偿装置404处理。

在上述技术方案中，优选的，所述事务补偿装置404还用于在所述全局事务中所有业务操作的状态不一致时，对处理失败的业务操作进行补偿处理。

事务补偿装置404可根据一个全局事务中各事务型操作的结果，进行对比，准确及时地发现不一致的数据记录，给予自动补偿，在自动补偿不能完整恢复数据一致性的情况下，还可预警给系统管理员，系统管理员可根据提示进行批量补偿操作，从而保证多个系统集成时数据的一致性。

在上述任一技术方案中，优选的，所述第二事务适配器408还用于在接收到来自所述第一事务适配器406的调用请求后，根据所述调用请求新建所述本地事务，在所述本地事务被成功提交后，开启另一个本地事务。

在上述任一技术方案中，优选的，所述第二事务适配器408还用于在所述另一个本地事务外围监测异常情况，在出现异常情况时，回滚所述另一个本地事务，并新建其他本地事务，根据异常情况的类型更新所述调用结果以及提交所述其他本地事务。

图5示出了根据本发明的实施例的数据集成系统的框架图。

如图5所示，本发明的数据集成系统400主要可应用但不局限于面向系统集成和整合的SOA运行平台。主要由四个装置构成，分别为事务运行引擎装置、事务适配器装置、事务补偿管理装置及数据预警装置，其中事务适配器装置及事务补偿管理装置为核心装置，事务运行引擎装置及数据预警装置为外围装置，可被替换。图中的SOA平台配置中心主要负责事务配置，只是为了更好描述本发明的整体应用环境，不作为本发明的必要构成部分。

1）事务运行引擎装置402

根据SCA事务模型配置（如全局事务的范围，哪些操作需要加入全局事务等），负责这个事务模型的解析和运行，进行异常处理，管理事务边界，在各异构系统及异构数据源间传递事务号，并且针对每个事务型操作，通过事务补偿装置404记录事务操作的执行状态。

2）事务适配器502

此装置可安装到每个参与集成的、有事务一致性要求的系统中，并在针对该系统数据源的某个事务型操作被调用时，加入到该系统的本地事务中，从而准确的记录事务型操作的调用结果。该装置还提供可供外部查询状态的服务接口，并负责为补偿管理装置提供服务以便可以发起重试或进行服务回滚操作。

3）事务补偿装置404

负责维护全局事务的运行状态，包括全局事务自身的状态及全局事务内部各个事务型操作的状态，各事务型操作的状态从事务适配器收集而来。根据全局事务状态记录，对于那些状态不一致的全局事务，可根据事务控制策略，进行自动补偿操作，比如重复执行某个失败的操作，或者回滚那些成功的操作。

如图6所示，一个典型的分布式事务从配置、到执行、到预警、到补偿的过程如下：

1)按照SCA组件事务模型，配置一个完整的业务流程中哪些操作为事务型操作(加入到全局事务里)，按要求配置各组件的服务接口、实现及引用。

2)业务流程随组件被部署到组件运行环境，业务流程被调用时，事务运行引擎装置发现该流程支持全局事务，则开始构建全局事务上下文，并将该全局事务上下文加入到流程运行上下文中。

3)事务补偿管理装置负责维护全局事务状态记录，首先会记录当前全局事务TID及初始状态为“正在处理”，然后事务运行引擎装置针对全局事务里的每一个事务型操作，发起相应的调用（默认为请求-响应模式），每个调用都会引起对事务型资源的操作，在这些操作对应的本地事务里，调用事务适配器装置，更新当前操作的状态，具体状态控制将在事务补偿管理装置一节详细描述。

4)整个业务流程运行结束时，如果整个全局事务成功(每个事务型操作均无任何异常出现)，则事务补偿管理装置根据全局事务TID删除第三步持久化的记录；如果发现事务失败(出现异常)，则事务补偿管理装置根据全局事务TID到各个补偿装置收集各事务操作的状态；如果在运行过程中宕机，则全局事务状态记录一直处于“正在处理”状态。

5)针对出现不一致状态的全局事务，如果业务流程事务一致性控制策略配置为自动处理，则由事务补偿管理装置自动调用重试或补偿操作，如果补偿失败，则更新记录状态为“补偿失败”，系统管理员可以方便查询补偿失败的业务流程，人工处理。如果事务一致性控制策略为手动处理，则不进行自动重试或补偿操作。

下面依次介绍数据集成系统中各装置的工作原理。

1.事务运行引擎装置402

事务运行引擎装置402根据SCA事务模型的配置（如全局事务的范围，哪些操作需要加入全局事务等），负责这个事务模型的解析和运行，管理事务边界，进行异常处理，在各异构系统及异构数据源间传递事务号，并且针对每个事务型操作，通过补偿管理装置记录事务操作的执行状态。图7展示了一个全局事务的处理全过程。

如图7所示，一个业务流程被部署后，如果被配置为支持全局事务，事务运行引擎装置402则会为该业务流程创建新的事务上下文，生成新的全局事务标识TID。然后事务补偿装置404会新增一条全局事务状态记录。接着开始执行业务流程里的每一个操作，对于声明为加入全局事务的事务型操作，事务运行引擎装置402会构建事务传播上下文，根据操作对应服务绑定协议，传播TID信息到第三方系统内的事务适配器，由事务适配器在系统本地事务中记录状态信息。并对操作级调用过程中可能出现的异常，整个业务流程过程中可能出现的异常进行处理，确保数据的一致性。

关于如何在通过不同协议调用异构系统时传播TID，可以参考另一篇专利《一种支持多协议多数据格式的服务绑定方法》，上述流程中异常的处理很关键，需要针对调用结果来记录每个事务型操作的状态，具体异常处理的流程请参考关于事务补偿装置404的详细说明（参考图10）。

2.事务适配器502

此装置可安装到每个参与集成的、有事务一致性要求的系统中，并在针对该系统数据源的某个事务型操作被调用时，加入到该系统的本地事务中，从而准确的记录事务型操作的调用结果（有记录表示成功、无记录表示失败）。例如若对于常见的EJB容器管理事务，则将更新事务型操作最终状态的服务也声明为容器管理事务即可。如果采用spring声明式事务，则将更新事务型操作最终状态的服务和实际操作事务型资源的服务声明在一个本地事务内部即可。

参考图8，为了能够保证在同一个本地事务内，事务适配器502记录所存储的数据源必须与被操作的事务资源保持一致。比如某个事务型操作是更新人力资源系统的人员信息，而人员信息是人力资源系统是通过数据库保存的，那么事务适配器502将事务型操作的状态也保存到同一个数据库中。

因为上述的要求，事务适配器装置会根据特定的第三方系统或数据源进行开发，但装置内部关键信息结构及处理流程是一致的。其中操作性事务状态的记录信息如下表所示：

请参考图9，每个事务型操作都是通过统一的事务适配器装置进行调用的，事务适配器装置接受到一个调用请求后，先通过新建的本地事务T1插入一条新的状态记录，状态为0:正在处理。该事务成功提交后，开启另一个本地事务T2，进行事务资源的操作，在本地事务T2提交前，通过通用的插件技术或者AOP（Aspect Oriented Programming）技术调用更新状态记录的服务，修改状态为2：成功。同时在事务T2外围捕获异常，如果有异常发生，则区分是业务异常还是非业务异常，通过新的事务T3更新相应记录状态为3：处理失败-业务异常或者4：处理失败-非业务异常。图9详细描述了事务适配器的工作流程。

需说明的是，如果第三方系统在T1事务提交后，在T2事务处理过程中出现当机，或者在出现异常后的处理过程中宕机，此时T2事务并没有被提交，应该认为是处理失败，但事务记录的状态一直为“正在处理”。解决方法为在服务器重启时，通过预警任务将表里所有状态为“正在处理”的记录更新为4：处理失败-非业务异常。针对这种状态，按照图8：全局事务内的异常处理流程，事务运行引擎装置会根据配置的重试策略发起重试，如果此时第三方系统及时恢复，则当前的事务型操作可以被成功处理的。

事务适配器502还提供可供外部查询状态的服务接口，并负责为事务补偿装置提供服务，以便可以发起重试或进行服务回滚操作。这些服务和接口基于各个参与集成的系统不同，可通过SOA集成平台发布为SCA组件，通过不同的协议绑定后供事务补偿装置调用，这里不再详细说明。

3.事务补偿装置404

事务补偿装置404的工作流程在事务运行引擎装置402里已经有描述，本节补充描述前述没有详细讲解部分的工作原理。

事务补偿装置404第一个关键部分为全局事务状态记录，在本实施例中设计的全局事务状态记录存储信息如下表所示：

另外需要记录每个全局事务内多个事务型操作的状态：

事务补偿装置404后续的自动补偿就是基于上面的状态记录，全局事务记录里事务一致性状态为“一致”的说明整个事务是完成的，事务里涉及到所有事务型资源状态是一致的。如果全局事务一致性状态为“不一致”，则说明事务里涉及到所有事务型资源状态是不一致的，需要进行自动或者手动补偿。事务补偿装置404详细的工作原理及异常处理流程如图10所示。

从图10中可以看出，全局事务状态是从事务型操作子记录收集而来的。子记录的状态均为成功，或者均为失败才能保证全局事务内所有事务型资源是一致的。在极少数情况，当出现一些非业务异常时，子记录状态可能会在一段时间内出现“正在处理”，此时全局事务状态为“未知”。但如前所述，正在处理状态都是暂时的，事务补偿装置404会以定时更新的方式通过事务适配器去查询事务型操作子记录的状态，确保最终所有全局事务状态要么是一致，要么是不一致。

举例说明，对于全局事务TID1，内部调用了两个事务型操作TP1及TP2，事务补偿装置通过事务适配器最终收集到的状态如下表所示：

对于记录状态为不一致的全局事务，则需要进行补偿操作，补偿可分为自动补偿及人工补偿，一般优先考虑自动补偿。自动补偿行为又分两种：重试和回滚，重试即重新发起事务型操作调用，回滚由各系统在注册服务时自行提供相应的反向事务型操作实现并以SCA组件服务形式注册到SOA平台上，由事务补偿装置进行调用。人工补偿是指系统管理员通过事务补偿装置发现不一致的全局事务记录后，可针对性的在各系统进行数据操作，将各系统的数据恢复到一致状态，相对传统方式，本发明可帮助系统管理员快速定位不一致的数据。

下面结合图11说明本发明的一个应用场景。

如图11所示，在A系统上进行业务操作时，通过SOA平台，相应的调用B系统的业务服务，实现数据同步和业务协同。分解步骤：

1）A系统在业务插件里发起调用；

2）A系统通过事务适配器A1调用SOA平台上相应服务组件提供的服务；

3）SOA平台上的组件通过事务适配器B 1调用B系统提供的业务服务。

需要重点解决的不一致问题有两种情况：

1.A系统执行成功，但B系统服务运行失败

这种场景下，主要原因是B系统服务出错，但异常没有返回给A系统的业务插件。只要确保异常不丢（通过完善程序逻辑及采用支持持久化的消息队列），就可以解决此类问题。

2.A系统执行失败，但B系统执行成功。

这是本发明重点要解决的场景，进一步细分为两种情况：

1)SOA平台调用B系统服务成功，但SOA平台后续出现异常，如断点，网络中断等，导致A系统调用B系统失败，A业务所在事务回滚；

2)A系统调用SOA平台服务成功，但后续出现业务或非业务异常，导致A系统响应业务服务所在事务回滚。

通过本发明的数据集成技术，可有效解决上述原因导致数据不一致的问题。

图12示出了根据本发明的实施例的数据集成方法的流程图。

如图12所示，根据本发明的实施例的数据集成方法，用于第一系统和第二系统之间的数据同步，包括：步骤1202，在第一系统进行业务操作时，通过安装于第一系统处的第一事务适配器调用事务运行引擎装置和事务补偿装置，通过事务运行引擎装置为业务操作建立业务流程，若业务流程被配置为支持全局事务，则为业务流程创建全局事务上下文，通过事务补偿装置记录全局事务的状态；步骤1204，针对全局事务中的每一个业务操作，调用第二系统通过第二事务适配器提供的服务，第二事务适配器安装于第二系统处，捕获调用情况，由第二事务适配器在创建的本地事务中记录调用结果；步骤1206，在业务流程运行结束时，事务补偿装置根据调用情况更新全局事务的状态。

因此，在保证数据一致性的前提下，本发明不做全局事务的锁控制，不需要参与全局事务的资源必须支持XA协议，同时避免了全局事务在两阶段提交时加锁所带来的性能损耗。

在上述技术方案中，优选的，步骤1202还可以包括：通过事务运行引擎装置为所述全局事务创建全局事务标识，在所述事务补偿装置中新增对应于所述全局事务标识的状态记录，所述状态记录包括所述全局事务的状态和所述全局事务中每一业务操作的状态，所述全局事务中每一业务操作的状态来自所述第二事务适配器。

事务补偿装置可根据一个全局事务中各事务型操作的结果，进行对比，准确及时地发现不一致的数据记录，给予自动补偿，在自动补偿不能完整恢复数据一致性的情况下，还可预警给系统管理员，系统管理员可根据提示进行批量补偿操作，从而保证多个系统集成时数据的一致性。

在上述任一技术方案中，优选的，在所述全局事务中所有业务操作的状态不一致时，对处理失败的业务操作进行补偿处理。

在上述任一技术方案中，优选的，在所述第二事务适配器接收到来自所述第一事务适配器的调用请求后，根据所述调用请求新建所述本地事务，在所述本地事务被成功提交后，开启另一个本地事务。

在上述任一技术方案中，优选的，在所述另一个本地事务外围监测异常情况，在出现异常情况时，回滚所述另一个本地事务，并新建其他本地事务，根据异常情况的类型更新所述调用结果以及提交所述其他本地事务。

以上结合附图详细说明了根据本发明的技术方案，本发明基于SCA分布式事务模型，但不做全局事务的锁控制，不需要参与全局事务的资源必须支持XA协议，同时避免了全局事务在两阶段提交时加锁所带来的性能损耗。本发明通过嵌入在每个第三方系统的适配器准确收集每一个事务型操作的事务状态和执行结果，然后事务补偿装置可根据一个全局事务中各事务型操作的结果，进行对比，准确及时地发现不一致的数据记录，给予自动补偿，在自动补偿不能完整恢复数据一致性的情况下，还可预警给系统管理员，系统管理员可根据提示进行批量补偿操作，从而保证多个系统集成时数据的一致性。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种数据集成系统，其特征在于，用于第一系统和第二系统之间的数据同步，包括：事务运行引擎装置、事务补偿装置、第一事务适配器和第二事务适配器，其中，

第一事务适配器，安装于所述第一系统处，用于在所述第一系统进行业务操作时，调用所述事务运行引擎装置和所述事务补偿装置；

所述事务运行引擎装置，为所述业务操作建立业务流程，若所述业务流程被配置为支持全局事务，则为所述业务流程创建全局事务上下文；

事务补偿装置，用于记录所述全局事务的状态，以及在所述业务流程运行结束时，根据所述第二事务适配器捕获的调用情况更新所述全局事务的状态；

第二事务适配器，安装于所述第二系统处，针对所述全局事务中的每一个业务操作，提供所述第二系统的服务，捕获所述调用情况并根据所述调用情况在创建的本地事务中记录调用结果。

2.根据权利要求1所述的数据集成系统，其特征在于，事务运行引擎装置还用于为所述全局事务创建全局事务标识；

所述事务补偿装置还用于新增对应于所述全局事务标识的状态记录，所述状态记录包括所述全局事务的状态和所述全局事务中每一业务操作的状态，所述全局事务中每一业务操作的状态来自所述第二事务适配器。

3.根据权利要求2所述的数据集成系统，其特征在于，所述事务补偿装置还用于在所述全局事务中所有业务操作的状态不一致时，对处理失败的业务操作进行补偿处理。

4.根据权利要求1至3中任一项所述的数据集成系统，其特征在于，所述第二事务适配器还用于在接收到来自所述第一事务适配器的调用请求后，根据所述调用请求新建所述本地事务，在所述本地事务被成功提交后，开启另一个本地事务。

5.根据权利要求4所述的数据集成系统，其特征在于，所述第二事务适配器还用于在所述另一个本地事务外围监测异常情况，在出现异常情况时，回滚所述另一个本地事务，并新建其他本地事务，根据异常情况的类型更新所述调用结果以及提交所述其他本地事务。

6.一种数据集成方法，其特征在于，用于第一系统和第二系统之间的数据同步，包括：

步骤1202，在所述第一系统进行业务操作时，通过安装于所述第一系统处的第一事务适配器调用事务运行引擎装置和事务补偿装置，通过所述事务运行引擎装置为所述业务操作建立业务流程，若所述业务流程被配置为支持全局事务，则为所述业务流程创建全局事务上下文，通过事务补偿装置记录所述全局事务的状态；

步骤1204，针对所述全局事务中的每一个业务操作，调用所述第二系统通过第二事务适配器提供的服务，所述第二事务适配器安装于所述第二系统处，捕获调用情况，由所述第二事务适配器在创建的本地事务中记录调用结果；

步骤1206，在所述业务流程运行结束时，所述事务补偿装置根据所述调用情况更新所述全局事务的状态。

7.根据权利要求6所述的数据集成方法，其特征在于，所述步骤1202还包括：通过事务运行引擎装置为所述全局事务创建全局事务标识，在所述事务补偿装置中新增对应于所述全局事务标识的状态记录，所述状态记录包括所述全局事务的状态和所述全局事务中每一业务操作的状态，所述全局事务中每一业务操作的状态来自所述第二事务适配器。

8.根据权利要求7所述的数据集成方法，其特征在于，在所述全局事务中所有业务操作的状态不一致时，对处理失败的业务操作进行补偿处理。

9.根据权利要求6至8中任一项所述的数据集成方法，其特征在于，在所述第二事务适配器接收到来自所述第一事务适配器的调用请求后，根据所述调用请求新建所述本地事务，在所述本地事务被成功提交后，开启另一个本地事务。

10.根据权利要求9所述的数据集成方法，其特征在于，在所述另一个本地事务外围监测异常情况，在出现异常情况时，回滚所述另一个本地事务，并新建其他本地事务，根据异常情况的类型更新所述调用结果以及提交所述其他本地事务。