Joule 的核心架构概述

Joule 作为 SAP 的官方对话助手，天然具有对接 SAP 应用的能力，但其背后的架构是怎么设计的呢？今天我们一起来一探究竟

用户界面与背后的架构

首先明确一个观点，用户感受到的 Joule 目前主要是嵌入在各个 SAP 应用中的，点击应用右上角的钻石图标即可唤出 Joule

但真实接收到用户指令的 Joule 大脑，却是部署在 BTP 上的，同时结合 BTP 提供的各项能力（比如知识图谱，RAG 向量数据库，身份中心）来真正执行工作。

核心架构如下图

调用一次 Joule 时背后发生的事情

以 Success Factors（SF）内嵌的 Joule 为例，当你问 Joule"帮我查看团队的考勤情况"时：

1.用户的指令会由 SF 发送到 BTP 上独属于该企业的 Joule 后台

2.Joule 会自行判断是否需要额外能力来满足用户

3.如果需要额外能力，Joule 会查询 BTP 中的服务，以确定可用的额外能力，然后具体执行动作

4.结合额外能力的结果后，回答用户指令

这里提到的额外能力就包括了额外的历史对话记忆库，知识库，文档库，工具库，Agent 库，业务语义库等，这些能力都是构建在 BTP 上的，具体情况会在其他文章详述

Joule 调用额外能力的方式详解

从架构图中可以看出，Joule 的额外能力就是一个个 BTP 上的服务，但 Joule 在调用能力之前，

1.首先需要知道自己有哪些服务可以调用

所以 SAP 将已经对接上 Joule 的应用，例如 SF 的可用能力列表包装成了 CDM，可以理解为一本带有说明书的工具清单，Joule 会自行判断能力的用途，并根据说明书确定如何调用能力

2.然后需要知道当前用户有权限调用哪些能力

然后所有应用和 BTP 都是打通了身份的，Joule 可以获取到当前用户在不同系统的权限，进而根据权限来判断可用能力列表，例如根据“部门经理”角色，判断可以调取团队考勤数据

3.需要安全的完成能力调用

最后，Joule 会基于用户的身份权限来调用系统能力，这样即使遇到最坏情况，Joule 尝试调用超过权限的数据，应用也会拒绝访问

总结

从用户点击钻石图标的那一刻起，到最终得到回答，整个过程涉及了前后端分离、服务调用、权限验证等多个环节。SAP 在设计这套架构时考虑得很周全——既要保证功能的强大，又要确保安全可控。

对于企业级应用来说，这种稳妥的设计思路是必要的。当然，随着技术的发展，这套架构肯定还会继续演进。但至少目前看来，它已经为 Joule 提供了一个相当坚实的技术基础。

文章作者：Arthur Yang

文章来源：https://mp.weixin.qq.com/s/cJLTQwcwRiGaw6QJLZNw_Q