Flowable业务处理之KAFKA EVENTS（上）
Flowable业务处理之KAFKA EVENTS（上）
上个月，我们引入了Flowable Event Registry。我们展示了如何在流程中使用事件，如何使用注册表为事件建模以及如何在Flowable Task Application中使用事件。
现在，我们通过创建一个更复杂的场景，使多个微服务之间相互通信，进一步向前迈进了一步。
如果您还不熟悉Flowable Event Registry，我们强烈建议您先阅读Flowable Event Registry介绍博客，然后再继续。可以在flowable-kafka示例中找到此博客文章的完整代码和示例。
让我们从用例开始。我们有一家虚构的电动踏板车创业公司，其第一要务是客户满意度。我们将构建一个软件解决方案，使用户可以对自己的旅程满意程度进行评分。踏板车使用完毕并退回后，客户便可以通过我们的网站进行评论。然后，通过一个简单的反应式应用程序将该评论发送到Kafka主题。在我们的主要客户应用程序中，每个客户都有一个CMMN案例。这使我们可以对特定客户的所有评论进行分组，启动情绪分析流程（这是另一个使用AWS Comprehend进行分析的独立应用程序）。如果我们收到不好的评价，我们将为其中一名员工启动任务，以便他们与客户之间的关系得以补救。
我们系统的架构如下所示：
在底部，我们有一个Kafka Event Stream，它负责传输所有事件。然后有一个针对我们客户的React UI，它将事件提交给我们的评论服务。
- 评论服务–使用Spring WebFlux从我们的UI接收评论并将其传输到Kafka的反应式Spring Boot应用程序。
- 客户关系服务–主要应用程序，这是一个可流动的应用程序，我们的客户案例以及客户的流程将在其中运行。这是一个使用Postgres作为数据库的Spring Boot应用程序。它将接收“审查和分析结果”事件并发出分析请求。
- 情绪分析服务–一个可流动的Spring Boot应用程序，它使用一个过程来执行情绪分析。
- Flowable Task Application –与客户关系服务连接到相同的数据库，员工可以在其中与客户案例进行交互。
- Spring Cloud API网关–用于将流量从UI重定向到适当的微服务。
审查服务
评论服务是一个简单的Spring WebFlux应用程序，可从我们的自定义React UI接收来自客户的评论。该应用程序显示来自伦敦桑坦德自行车系统的开放数据的地图。地图上的每个点都是客户可以放下我们的踏板车并单击并填写表格进行评论的点。
查看应用程序用户界面
该审查具有以下结构：
{
"userId": "John Doe",
"stationId": 5,
"rating": 5,
"comment": "Really great service"
}
然后，此评论将发送到reviewsKafka主题。
客户关系服务
客户关系服务是在其中创建客户案例的Flowable Spring Boot应用程序。客户案例的模型如下所示：
每当有新客户签约时，我们都会创建案例。这种情况将从“活动订阅”阶段开始，并等待相关的可能事件：
- 收到评论
- 收到客户支持请求
- 计时器事件
- 收到停用
对于我们的演示，我们仅实现了“已收到审阅”事件，其他情况则更有意义。此事件侦听器已配置为侦听“审阅事件”。
在显示如何配置“已收到审阅事件”之前，让我们对审阅服务发送的“审阅事件”进行建模。
在下面的屏幕截图中，为了方便起见，我们将使用企业Flowable Design 3.6.0（在撰写本文时尚未发布，但很快就会发布；如果您有兴趣自己尝试，请查看在flowable测试页）。您可以使用开源Modeler应用程序和配置来完成所有这些操作。
该事件（如我们之前在JSON中看到的）具有，，和和userId用作关联参数。发生此事件后，我们可以通过以下方式配置“收到已审核”事件：stationIdratingcomment
接收事件配置
让我们遍历此配置以了解发生了什么。我们需要为事件定义相关参数。由于此案例实例适用于的客户userId，因此我们只想userId在事件中的from匹配案例中的一个实例时激活它。因此，所需的相关参数为${userId}。如果我们将其保留为空，则将为所有审阅事件触发它。一旦配置了相关参数，就需要配置数据映射。我们仅在此处将事件负载中的参数复制到案例实例中。
太好了，因此我们现在配置了事件，当接收到事件时，它将触发情感分析过程任务，并将userId和comment作为输入参数传递给它。让我们看一下该模型：
