作为近期 使用变更数据捕获和流处理构建审计日志 博客文章的后续，我们希望通过管理功能扩展此示例，使其能够捕获和修复任何缺失的事务数据。
在上述博客文章中，有一个日志增强服务，用于将“Vegetable”数据库表中插入或更新的数据与事务上下文数据（例如
-
事务 ID
-
执行操作的用户名
-
实际更改背后的用例，例如“创建蔬菜”
只要所有更改都通过蔬菜服务进行，这一切都能很好地工作。但情况总是如此吗？
那么维护活动或直接在数据库级别执行的迁移脚本呢？仍然存在大量此类活动，无论是故意的，还是因为这是我们正在努力改变的老习惯……
数据库级别的维护
因此，我们假设需要对库存数据库进行一些维护，这些维护将对存储在 vegetable 表中的数据进行更改。为了简单起见，我们只需在 vegetable 表中添加一个新条目。
insert into inventory.vegetable (id, name, description) values (106, ‘cucumber, 'excellent');添加此条目后，您会发现日志丰富器服务开始打印出不少日志消息……而且是持续不断地打印。
log-enricher_1 | 2019-10-11 10:30:46,099 INFO [io.deb.dem.aud.enr.ChangeEventEnricher] (auditlog-enricher-c9e5d1bb-d953-42b4-8dc6-bbc328f5344f-StreamThread-1) Processing buffered change event for key {"id":106}
log-enricher_1 | 2019-10-11 10:30:46,106 WARN [io.deb.dem.aud.enr.ChangeEventEnricher] (auditlog-enricher-c9e5d1bb-d953-42b4-8dc6-bbc328f5344f-StreamThread-1) No metadata found for transaction {"transaction_id":611}
log-enricher_1 | 2019-10-11 10:30:46,411 INFO [io.deb.dem.aud.enr.ChangeEventEnricher] (auditlog-enricher-c9e5d1bb-d953-42b4-8dc6-bbc328f5344f-StreamThread-1) Processing buffered change event for key {"id":106}
log-enricher_1 | 2019-10-11 10:30:46,415 WARN [io.deb.dem.aud.enr.ChangeEventEnricher] (auditlog-enricher-c9e5d1bb-d953-42b4-8dc6-bbc328f5344f-StreamThread-1) No metadata found for transaction {"transaction_id":611}
log-enricher_1 | 2019-10-11 10:30:46,921 INFO [io.deb.dem.aud.enr.ChangeEventEnricher] (auditlog-enricher-c9e5d1bb-d953-42b4-8dc6-bbc328f5344f-StreamThread-1) Processing buffered change event for key {"id":106}查看日志，您可以确定它实际上是指我们刚刚插入的条目（id 106）。此外，它还提到了缺失的事务上下文数据，而这些数据是找不到的。这是因为直接在数据库级别手动进行操作，而不是通过 vegetable 服务。`dbserver1.inventory.transaction_context_data` Kafka 主题中没有相应的条目，因此日志丰富器无法进行关联，也无法合并/丰富这些条目。
Kogito 来帮忙
如果能有一种管理服务来帮助解决这类问题，那将是一个非常好的功能（或者如 Gunnar 所说的，一个巧妙的功能）。主要是因为如果添加了这样一个条目，它将阻塞整个丰富活动，因为第一个缺失的消息将导致所有其他消息被挂起。
而 Kogito 来了——一个云原生业务自动化工具包，用于构建基于久经考验的功能的智能业务应用程序。换句话说，它带来了业务流程和规则来解决特定的业务问题。在这种情况下，业务问题是日志丰富被阻塞，这可能导致一些（各种类型的）机会损失。
Kogito 帮助我们定义逻辑，以了解可能出现什么问题，需要做什么来解决它，以及导致问题和解决方案的条件是什么。
在这种特定情况下，我们同时使用了流程和规则，以确保我们获得正确的上下文并对 vegetable 服务背后的事件做出反应。为了能够发现错误情况，我们需要监视两个主题：
-
`dbserver1.inventory.vegetable` - vegetable 数据更改事件
-
`dbserver1.inventory.transaction_context_data` - 来自 vegetable 服务的事件，包含附加的上下文数据
因此，我们定义了两个业务流程，每个流程都将根据传入的消息（来自不同的 Kafka 主题）启动。
如上图所示，这两个流程都基于传入的消息启动。然后，后续的逻辑会有显著不同。
“事务上下文数据”流程负责仅检索事件并将其推入处理阶段——这本质上意味着将其插入用于规则评估的所谓“工作内存”中。此时，它就完成了。
“Vegetable 事件”流程以类似的方式启动……它检索消息，然后（首先像日志丰富器服务一样忽略快照消息）等待预定义的时间（2 秒），然后匹配 vegetable 和事务上下文事件。一旦匹配成功，它将简单地完成执行。但如果找不到匹配项，它将创建一个用户任务（这是一项需要人工提供数据才能让流程继续进行的任务）。
这是通过管理员用户界面（https://:8085/）完成的，该界面可以轻松地发现此类实例并处理它们以修复缺失的数据。
一旦提供了 `Use case` 和 `User name` 属性，该流程将创建一个新的事务上下文事件，将其推送到 Kafka 主题，然后完成自身。
将缺失的事务上下文数据事件推送到主题后，日志丰富器将恢复其操作，您将在日志中看到以下行：
log-enricher_1 | 2019-10-11 10:31:00,385 INFO [io.deb.dem.aud.enr.ChangeEventEnricher] (auditlog-enricher-c9e5d1bb-d953-42b4-8dc6-bbc328f5344f-StreamThread-1) Processing buffered change event for key {"id":106}
log-enricher_1 | 2019-10-11 10:31:00,389 INFO [io.deb.dem.aud.enr.ChangeEventEnricher] (auditlog-enricher-c9e5d1bb-d953-42b4-8dc6-bbc328f5344f-StreamThread-1) Enriched change event for key {"id":106}通过这种方式，您可以轻松地管理审计日志，确保任何错误情况都能迅速得到解决，以免影响其他活动。
如果您想观看这一切的演示，请观看此视频：
或者通过运行 审计日志示例 来亲自尝试。
关于 Debezium
Debezium 是一个开源的分布式平台，可以将现有数据库转变为事件流，使应用程序能够几乎即时地看到并响应数据库中已提交的每个行级更改。Debezium 构建在 Kafka 之上，并提供了 Kafka Connect 兼容的连接器，用于监控特定的数据库管理系统。Debezium 将数据更改的历史记录在 Kafka 日志中，这样您的应用程序可以随时停止和重新启动，并可以轻松地消费在未运行时错过的所有事件，确保所有事件都被正确且完整地处理。Debezium 在 Apache 许可证 2.0 下是 开源 的。
