JDBC 适配器客户定制入站事件流程

最新推荐文章于 2025-08-09 18:20:04 发布

phantomhu

最新推荐文章于 2025-08-09 18:20:04 发布

阅读量336

点赞数

分类专栏： java 文章标签： jdbc websphere object 数据库 function ibm

java 专栏收录该内容

113 篇文章

订阅专栏

本文介绍如何使用WebSphere Adapter for JDBC的定制入站事件功能，以处理客户自定义的事件表，支持灵活的查询条件及封装业务逻辑。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

引言

本文将使用 WebSphere Adapter for Java Database Connectivity 配置一个带有客户定制的事件表的入站 (inbound) 事件流程，用以介绍通过利用数据库触发器 (trigger) 来实现的 JDBC 适配器的客户定制入站事件功能，该功能是 WebSphere Adapter for JDBC 6.0.2 版本提供的新功能。本文的目标读者是对关系型数据库有一定了解，熟悉 JDBC 驱动程序，并对 WebSphere Adapter for Java Database Connectivity 有一个初步了解，需要使用 IBM WebSphere Adapter 来进行设计 / 开发的编程人员。

适配器简介

IBM WebSphere 适配器是基于 J2EE 的符合 J2EE 连接器体系结构 (Java Connection Architect 1.5) 标准的新一代适配器，也被称作资源适配器或 JCA 适配器。IBM WebSphere 适配器实现了在企业信息系统 (Enterprise Information System) 和 WPS(WebSphere Process Server)/WebSphere Enterprise Service Bus(WESB) 等应用服务器支持的 Java Enterprise Edition (Java EE) 组件之间进行双向连接和数据交换。WebSphere Adapter for JDBC 是专门针对主流的关系型数据库进行开发的，支持所有 JDBC2.0 以上标准兼容的 JDBC 驱动，并对 DB2/Oracle/SQL Server 等主流的关系型数据库做了定制优化。

IBM WebSphere 适配器主要分为两类：Application 适配器和 Technology 适配器；Application 适配器包括针对 SAP, Siebel, JDE,People Soft 等应用程序系统的适配器，Technology 适配器则是对标准技术接口开发的，包括为 JDBC 规范，文件传输 (File Transportation Protocol) 协议，E-Mail 相关协议 (SMTP,POP3,iMap)，文件系统 (FlatFile) 。

先决条件

为了开发这个循序渐进的示例应用程序，应考虑下列先决条件：

WebSphere Integration Developer 6.0.2。您将同时需要开发环境和 WebSphere Process Server 集成测试环境，后者是开发环境安装过程中的一个选项。该集成测试环境包括完整的 WebSphere Process Server 运行时环境，我们将使用它来测试本文中的示例。 WebSphere Adapter for JDBC 6.0.2。请参见 参考资料 以获得官方 WebSphere Adapter for JDBC IBM 网站地址。 DB2 Universal Database V8.2。该示例使用 DB2；不过，可以使用任何兼容 JDBC2.0 驱动的数据库，只要您习惯使用它来创建触发器并熟悉其 JDBC 驱动程序。

JDBC 适配器的入站事件流程

JDBC 适配器的入站事件流程提供了一种数据库驱动的业务处理机制。该机制的优点在于可以利用原有遗留系统的数据库资源，并能够根据遗留系统内部的数据变化处理相应的业务流程，而不需要深入的了解原有的遗留系统本身或者对遗留系统进行很大的改动。 JDBC 适配器的入站事件流程还可以用来保证服务的质量。WebSphere Adapter for JDBC 可以与您的业务流程一起参与全局事务。如果某个业务流程失败，则会回滚该全局事务，包括适配器已在该事务期间执行的任何数据库交互。

总之，JDBC 适配器的入站事件流程提供了一种数据库驱动的业务驱动机制，该机制可以可以帮助客户更快更有效的利用已有的数据资源，快速整合旧有的遗留系统到整个业务流程之中，并能提升服务的可靠性。JDBC 适配器会在数据的转换过程中带来一定的额外开销，服务的可靠性保障也是需要额外的成本的，因此 JDBC 适配器并不适用于对于实时性能要求很高的业务系统。

什么是标准的入站事件流程

JDBC 适配器推荐用户使用标准的用户入站事件处理流程。当应用数据库中的数据发生变化的时候，用户可以通过对相应的表建立触发器（trigger）来监控这些变化，每一条数据变化的记录（我们称之为入站事件）都将被存储在一个具有特定结构的标准的事件表（Event Store）中，其结构如表 A 所示。在运行时环境中，JDBC 适配器被设定为定期处理该表中的事件，并根据表结构生成业务对象分发给适当的终端（End Point）进行相应的创建、删除、更新等处理，最终根据处理成功与否更新事件表中的状态信息。从上述的描述不难看出，一个标准的入站事件处理流程包括以下三个重要的特点：第一，提供一个标准的事件表用以记录企业信息系统中数据的变化历史。标准的事件表是 JDBC 适配器的入站事件处理模型中典型的特征。它具有特定的结构。

event_id：是该标的主键，也就是事件的唯一标识符；

object_key：记录了发生变化的表的主键，用以定位被监控的数据； object_name：业务对象名称；它并不是用来记录数据库中的发生变化的数据对应的表名，而是用来关联 JDBC 适配器中定义的业务对象。该对象亦可以是带有层级结构的复杂对象； object_function：事件所对应的操作类型；同样地，该属性也关联了终端系统对数据的操作类型； event_priority：用以标识处理优先级的属性； event_time：事件产生的时间； event_status：事件被处理的状态 -0 表示待处理，1 表示处理成功，-1 表示处理失败； event_comment：用户自定义的说明信息。其中，object_name, object_function 是 JDBC 适配器特定的属性，需要配置为与企业应用中业务对象相同的名称。第二，每一个入站事件都直接反映了企业信息系统中数据的变化。由于采用触发器监控指定的数据表，企业信息系统中的任何数据变化都被直接当作需要被处理的入站事件插入事件表。第三，事件的处理完全交由 JDBC 适配器接管并派发给终端。

为了处理企业信息系统中时时变化的数据，JDBC 适配器被设定为监控该事件表内的所有入站事件。一旦有入站事件发生，该事件在下一个处理周期（Poll cycle）内即被 JDBC 适配器捕获，并依据标准表中提供的 object_name 构建完整的业务对象，object_key 定位发生变化的数据，object_function 来记录数据发生了诸如创建、删除、更新等操作。

什么是定制化的入站事件流程

除了上面提到的可以通过使用事件表外，JDBC 资源适配器还支持客户定制处理入站事件。其主要功能表述如下：用户可以为系统的入站事件配置定制化的查询条件，JDBC 资源适配器将自动处理用户定制查询的结果，产生对应的业务对象，并派发给终端系统进行处理。其中，上面提到的查询方式包括三种：标准 SQL 命令，存储过程以及存储函数。为了统一接口，JDBC 适配器规定所有上述三种查询方式都具有统一的输入和输出，如下表 1- 表 3 所示：

表 1 ：定制入站事件查询命令的输入参数

输入参数	处理数量（Poll Quantity）
数据类型	整型（Integer）
含义	在一个处理周期内可以处理的事件数量
设置方式	该参数由 JDBC 资源适配器在运行时自动提供

表 2 ：定制入站事件查询命令的输出参数

输出参数	多条记录的集合
数据类型	结果集（RESULTSET）
含义	符合查询条件的所有事件记录
数据结构	每条记录都按顺序包含以下 4 个条目：event_id, object_key, object_name, object_function

表 3： 存储过程和存储函数 的 调用语法：

`类型`	调用语法	参数 1	参数 2
存储过程	call <SPName> (?, ?)	处理数量	返回的结果集
存储函数		返回的结果集	处理数量

另外，JDBC 资源适配器也允许用户设置其他参数，但是参数值必须预先指定，如：

call <SPName>(‘IBM’,?,?);
? = call <FunctionName> (‘IBM’,?);
Select event_id, object_key, object_name, object_function from cust_eventstore 
where event_status=0;

配置查询命令的入口可以在开发周期完成，也可以在应用服务器端通过管理控制台（Admin Console）进行，具体的配置方法请参见本文后面章节的示例。下面介绍需要配置的属性： EventQueryType：该属性是用户选择入站事件处理方式的开关。Static- 表示标准入站事件处理方式；Dynamic- 表示定制的入站事件处理方式。仅当用户选择 Dynamic 的时候，下面三个属性才允许用户使用。 customEventQuery：定制事件查询规则，允许用户采用 SQL command 或存储过程或存储函数的方式设置需要处理的事件条目。要求必须带有一个输入参数：PollQuantity，返回符合查询规则的结果集，参见表一说明。 customUpdateQuery：定制事件更新准则，允许用户在每次处理结束后根据是否处理成功来标志数据，用来防止同样的数据被重复处理。 customDeleteQuery：定制事件删除准则，允许用户在每次处理结束后删除被处理的事件。

为什么要使用 JDBC 适配器客户定制的入站事件功能？

表结构可自由扩充，有利于对遗留的企业信息系统的兼容 从前文对 JDBC 适配器所支持的两种入站事件的功能描述我们可以知道，标准的入站事件处理流程帮助客户定义并实现了一个非常简单、高度自动化的业务处理流程。在这套流程中，用户一旦配置好 EIS 系统（在这里就是数据库），完全不需要做任何干预，EIS 系统中的任何数据变化都会自动被 J2EE 入站处理应用程序捕获，并定时发送给终端系统进行深度处理。不难看出这套业务流程的关键就是该事件表。但是由于该表是 JDBC 适配器入站应用程序得以顺利运行所依赖的重要基础，其结构已经被预先定义，无法进行结构上的调整。对于已经上线的企业信息系统来说，要想平滑的引入 JDBC 适配器的入站事件处理功能，必须引入一种机制使得系统中已有的事件处理机制能够转移到标准的事件表中。这就要求在标准的入站事件流程中增加一个事件处理方式转换的环节，这就是客户定制的事件表。为了直观的理解这两种业务流程的差别，请参见下图 1，图 2 所示。

图 1.JDBC 入站事件业务流程

图 2. 客户定制的 JDBC 入站事件业务流程

查询条件灵活，满足多种运行时的处理需求 标准的 JDBC 入站事件处理方式对于事件的处理方式基本上以入站先后顺序依次处理，同时也提供了一些排序方式：例如 orderedbyKey，根据监控对象的主键进行排序。而定制化入站事件流程允许用户依据业务的需要，开发出更多更复杂的查询条件并交给后端应用处理。

便于封装业务逻辑而不影响现有的业务流程 由于存储过程的引入，使得 JDBC 入站事件可以满足业务逻辑相对复杂的客户需求。存储过程较之于 SQL 命令有以下优势：接口简单：只需要关心输入输出，大大简化了命令的复杂性；封装完整：存储过程中可以封装大量 SQL 命令，在调用时作为一个整体被执行；支撑复杂的操作逻辑：使用标准的 PL-SQL 可以结构化指令集，引入分支、循环、判断等复杂的操作，支持更加复杂的客户需求；

容易移植：经过封装后的过程调用允许用户在更新业务逻辑的时候仅仅对企业信息系统中的存储过程进行调整，编译通过后即可直接替代旧有的过程参与业务流程，而不需要频繁修改 JDBC 入站应用程序。

怎样使用 JDBC 适配器定制的入站事件流程：

让我们考虑以下客户应用情景：某企业应用系统中，已实现一套数据监听处理流程：

1．用户监听 Customer 表中数据的变化，所有插入，删除，修改等操作记录在事件表中 CUST_JDBC_EVENTSTORE。表 4 具有如下结构：
表 4：CUST_JDBC_EventStore 表结构

`列属性`	`描述`
`EVENT_ID`	`事件序号`
`OBJECT_KEY`	`发生变化的数据的键值，用以唯一定位数据`
`OBJECT_NAME`	`受监控的表名`
`OBJECT_FUNCTION`	`操作类型（插入 / 删除 / 修改）`
`EVENT_TIMESTAMP`	`数据变化的时间记录（YYYY-MM-DD HH:MM:SS）`
`EVENT_PRIORITY`	`事件处理优先级`
`EVENT_STATUS`	`事件状态（0- 待处理；1- 处理成功；-1- 处理失败）`

可通过为该表 4 建立设置如下触发器来实现：

CREATE TRIGGER event_create AFTER INSERT ON CUSTOMER

REFERENCING NEW AS N FOR EACH ROW MODE DB2SQL

INSERT INTO cust_jdbc_eventstore (object_key, object_name ,

object_function, event_priority, event_status)

VALUES (N.pkey, ' Customer ' , ' Create ' , 1 , 0 );

CREATE TRIGGER event_udpate AFTER UPDATE ON CUSTOMER

REFERENCING NEW AS N FOR EACH ROW MODE DB2SQL

INSERT INTO cust_jdbc_eventstore (object_key, table_name,

operation, event_priority, event_status) VALUES (N.pkey, ' Customer ' , ' Update ' , 1 , 0 );

CREATE TRIGGER event_delete AFTER DELETE ON CUSTOMER

REFERENCING OLD AS O FOR EACH ROW MODE DB2SQL

INSERT INTO cust_jdbc_eventstore (object_key, table_name,

operation, event_priority, event_status) VALUES (O.pkey, ' Customer ' , ' Delete ' , 1 , 0 );

2. 用户的后台应用服务轮询该事件表，从中挑选出待处理的事件（select event_id, object_key, object_name, object_function from cust_jdbc_eventstore where event_status = 0），并根据数据操作类型自定义业务逻辑。在上面简单的客户应用实例中，我们可以发现，该操作流程与 JDBC 适配器的工作流程非常相似，差别在于用于中转事件的事件表的结构（或命名规则）与标准的事件表 WBIA_JDBC_EVENTSTORE 不同。因而无法采用标准的 JDBC 适配器入站事件处理的功能。但是，有了可定制的入站事件处理的功能后，我们只需要稍加改造，客户的应用环境就可以引入 JDBC 适配器来完成事件处理的流程，而用户只需要全心专注于后台业务逻辑的开发就可以了。改造方法如下：设置 customEventQuery 处理命令，用来筛选需要处理的时间，为了简单起见，可采用 SQL 命令：

SELECT event_id, object_key, object_name , object_function FROM cust_jdbc_eventstore

WHERE event_status = 0

设置 customUpdateQuery 处理命令 :

update cust_jdbc_eventstore set event_status = 1 where event_id = ?

customDeleteQuery: delete cust_jdbc_eventstore where event_status = 1

设置 JDBC 事件表为：WBIA_EVENTSTORE 注意：这里的 WBIA_JDBC_EVENTSTORE 表与默认的事件表稍有不同，参见如下 Script

CREATE TABLE WBIA_JDBC_EventStore (

event_id INTEGER NOT NULL ,

xid VARCHAR ( 200 )

object_key VARCHAR ( 80 ) NOT NULL ,

object_name VARCHAR ( 40 ) NOT NULL ,

object_function VARCHAR ( 40 ) NOT NULL ,

event_priority INTEGER NOT NULL ,

event_time TIMESTAMP

default CURRENT TIMESTAMP NOT NULL ,

event_status INTEGER NOT NULL , event_comment VARCHAR ( 100 ));

JDBC 适配器的入站事件配置界面：客户定制入站事件的使用与标准的 JDBC 适配器入站事件相比较，需要在 Enterprise Service Discovery 的最后一个 wizard 界面进行一些额外的配置。将配置好的 JDBC 适配器定制入站事件程序导出并且部署至 WebSphere Process Server 并启动 JDBC 适配器入站事件程序即可以使用定制入站事件功能。