原文地址： https://debezium.io/blog/2019/10/22/audit-logs-with-kogito/
欢迎关注留言，我是收集整理小能手，工具翻译，仅供参考，笔芯笔芯.
使用 Kogito 进行审核日志的管理服务
十月 22, 2019 作者： Maciej Swiderski
讨论 示例 apache-kafka kafka-streams kogito
作为最近使用变更数据捕获和流处理构建审核日志博客文章的后续内容，我们希望使用管理功能扩展该示例，以便能够捕获和修复任何丢失的事务数据。
在上面提到的博客文章中，有一个日志丰富服务，用于将 Vegetable 数据库表中插入或更新的数据与事务上下文数据结合起来，例如
交易编号
执行该工作的用户名
实际更改背后的用例，例如“CREATE 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）。除此之外，它指的是它无法找到的丢失的事务上下文数据。这是在数据库级别手动执行而不是通过蔬菜服务的结果。Kafka 主题中没有相应的数据dbserver1.inventory.transaction_context_data，因此日志丰富器无法关联并通过合并/丰富它们。
小吉托来救援
如果我们能有某种管理服务来帮助解决这类问题，那将会是一个非常好的功能（或者像 Gunnar 所说的一个简洁的功能）。主要是因为如果添加这样的条目，它将阻止整个丰富活动，因为第一个丢失的消息将阻止所有其他消息。
Kogito来了——一个云原生业务自动化工具包，用于基于经过考验的功能构建智能业务应用程序。换句话说，它带来了解决特定业务问题的业务流程和规则。在这种情况下，业务问题是阻止日志丰富，这可能导致失去一些（各种类型的）机会。
Kogito 帮助我们定义我们的逻辑，以了解可能会出现什么问题、需要采取哪些措施来解决问题以及导致问题和解决方案的条件是什么。
在这种特殊情况下，我们使用流程和规则来确保我们获得正确的上下文并对蔬菜服务背后的事件做出反应。为了能够发现错误情况，我们需要监控两个主题：
dbserver1.inventory.vegetable- 蔬菜数据变更事件
dbserver1.inventory.transaction_context_data- 来自蔬菜服务的事件以及附加上下文数据
因此，我们定义了两个业务流程，每个流程都将根据来自各个 Kafka 主题的传入消息启动：
图片来自于原文
蔬菜事件流程定义
交易上下文数据流程定义
如上所述，这两个过程都是基于传入消息启动的。那么之后的逻辑就明显不同了。
“事务上下文数据”进程负责检索事件并将其推入处理阶段 - 这本质上意味着将其插入到用于规则评估的所谓“工作内存”中。在那一刻就完成了。
“蔬菜事件”过程以类似的方式开始…它检索消息，然后（首先以与日志丰富服务相同的方式忽略快照消息）将在匹配蔬菜和事务之前等待预定义的时间（2秒）上下文事件。一旦有匹配，它将简单地完成其执行。但是，如果没有找到匹配项，它将创建一个用户任务（该任务需要人类参与者在流程继续前进之前提供数据）。
这是通过管理用户界面（http://localhost:8085/）完成的，该界面允许轻松发现此类实例并对其进行修复以修复丢失的数据。
图片来自于原文
用于修复丢失的事务上下文数据的管理服务 UI
一旦提供了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}
通过此功能，您可以轻松管理审核日志，以确保快速解决任何错误情况，而不影响任何其他活动。
