基于事件的数据库集成

使用 数据库输入 节点对数据库中的事件作出响应。 例如，集成节点可以通过在数据库中的数据发生更改的情况下便向目标系统发送更新来保持外部系统与数据库同步。

数据库必须记录数据在事件存储器（通常是数据库表）中已更改的事实。 事件存储器与应用程序数据不同。 下图显示数据库、事件存储器和集成节点之间的交互。

此图像在其后面的文本中进行了描述。
  1. 数据库应用程序更改数据库表。
  2. 数据库管理系统 (DBMS) 记录事件存储器中的更改。
  3. 集成节点在经过轮询时间间隔配置设置中指定的时间间隔后轮询事件存储器。
  4. IBM® Integration Bus 将检索新数据或已更改的数据，并更新事件存储器，以便仅处理一次数据。
  5. IBM Integration Bus 会处理数据，并最终将其提供给目标应用程序 (例如 SAP， Web Service 或 CICS® Transaction Server for z/OS®)。 如果需要，可以采用不同的逻辑和物理格式来提供数据。

实现

实施此方案涉及以下步骤：
  1. 配置数据库以记录事件。
  2. 确定目标系统从这些新事件接收数据必须使用的格式。
  3. 配置集成节点以通过使用 数据库输入 节点来检测这些事件。 要配置 数据库输入 节点，请参阅 配置 DatabaseInput 节点。
  4. 配置消息流的其余内容以使用正确的格式向目标系统呈现数据。

数据库输入 节点

下图显示了 数据库输入 节点的工作方式。

当过程启动时，ReadEvents 检查事件存储器以查找新事件，这些事件随后供 BuildMessage 用于构建消息。 此消息传播到消息流，然后 EndEvent 更新事件存储器以确保无法再次处理事件。

当过程启动时，ReadEvents 检查事件存储器以查找新事件，这些事件随后供 BuildMessage 用于构建消息。 此消息传播到消息流，然后 EndEvent 更新事件存储器以确保无法再次处理事件。 处理所有事件后，集成节点将调用 ReadEvents 以检索自从上次检查以来添加的任何事件。 如果事件存储器为空，那么集成节点将等待直至轮询时间间隔到期，然后再次调用 ReadEvents。 为避免争用，事件存储器的检查是单线程的。

对于由 ReadEvents 读取的每个事件，BuildMessage 构建传播到消息流的消息。 构建消息通常使用事件数据来查找应用程序表中的数据。 应用程序表中的数据随后用于构建消息。 当 BuildMessage 结束时，消息自动传播到消息流。 传播消息时，集成节点将开始处理消息所需的任何下游节点。

消息传播到消息流之后，EndEvent 更新事件存储器以确保无法再次处理刚处理的事件。

ReadEvents、BuildMessage 和 EndEvent 的详细操作通过 ESQL 代码进行控制。 数据库输入 节点包含具有样本代码和注释的 ESQL 模块，您必须进行修改以满足您的需求。 ReadEvents 使用从事件表读取的事件数据来填充 NewEvents 结构。 生成的每个事件数据行都具有Key和 aUsr字段名称;NewEvents.Event[].Key和NewEvents.Event[].Usr.Key字段包含用于事件的唯一键，并且用于防止重复事件处理。 Usr字段通常是一个子树，它包含与事件关联的用户定义数据。 有关修改 ESQL 的信息，请参阅 配置 DatabaseInput 节点。

事务和缩放

由 数据库输入 节点完成的流程将拆分为多个单独的事务。 当 ReadEvents 启动时，将启动新事务。 当 ReadEvents 结束时，将落实此事务并将新事件标记为要进行处理。 通过落实此事务，将解除通过从 ReadEvents 运行的 ESQL 代码置于数据库上的任何锁定。 然后，对于 BuildMessage 接收到的每个事件，将启动新事务。 此新事务在 EndEvent 完成后落实。

要针对许多事件扩展 数据库输入 节点，请将 实例 选项卡上的 其他实例 属性从其缺省值 0 更改为您需要的实例数。 如果使用的是附加实例，那么必须配置数据库，以便多个应用程序可以同时读取应用程序表中不同的行。 ReadEvents 始终以单线程方式运行以避免数据库争用，即使使用附加实例也如此。 要提高性能，ReadEvents 可以在其每次运行时读取多个事件，并且可以通过 BuildMessage 的多个实例同时处理这些事件。 事件存储器必须具有供 ReadEvents 用于识别当前处理的事件的主键。 不必在 ReadEvents 中编写 ESQL 即可滤除消息流当前处理的事件。

失败和重试机制

  • 如果 ReadEvents 期间发生错误，那么会将错误记录到系统日志中。 它将在轮询时间间隔下次到期之后重试。 不会将任何消息传播至 Failure 终端。
  • 如果在 BuildMessage 处理期间发生错误，那么会将异常传播至 Failure 终端（如果已连接）。 如果未在 Failure 终端上处理异常（即，此终端未连接或者从 Failure 终端抛出异常），那么会回滚此事务。 否则，会落实此事务。 无论是否处理异常，都不会将此消息传播至 Out 终端，并且也不会调用 EndEvent。
  • 如果从 Out 终端下游抛出异常，那么 Catch 终端未处理的任何异常都将导致回滚此事务，并且不会调用 EndEvent。 如果在 Catch 终端处理了异常，那么会调用 EndEvent，并落实此事务。
重试处理允许应用程序开发者处理下游节点中发生的 Catch 处理尚未成功处理的瞬时错误。 可使用三种重试机制中的任何一种来配置输入节点：
  1. Failure
  2. Short retry then failure
  3. Short then long retry

如果 'Failure' 那么事件将移动到 "Failed' 并且事务已回滚。 在分派任何处于 Ready 状态的事件之前会检测并解决失败的事件。 失败事件会传播至带有异常列表的 Failure 终端（如果已连接）。

对于 "Short retry then failure"，消息流执行与 重试阈值 属性相等的重试次数，并将消息向下传播到 Out 终端，每次重试之间的时间间隔等于"Short retry interval"。 如果在未成功完成事务的情况下达到重试阈值，那么会将消息传播到 Failure 终端。

对于 "Short then long retry"，那么重试逻辑与"short retry then failure' 直到达到重试阈值为止。 然后，它将继续无限重试，而不是结束重试尝试并传播到 failure 终端，但现在在每次重试之间有一个等于 "Long retry interval'.

TheEndEvent如果事务已回滚，或者消息已传播到故障终端，那么不会自动调用该操作。 在上述各种情况下，如果用户希望阻止重新处理事件，那么由用户决定在事件存储器中除去事件还是更新事件。

TheEndEvent如果事务成功完成 (包括在数据库输入节点下游发生异常，但该异常已在 Catch 终端上成功处理) ，那么将自动调用该操作。