设计实例

本页上的示例设计展示了将虚拟坐席与 CXone Mpower 集成的各种可能性。 它们基于真实世界的场景，但重要的是要明白，每个组织的环境都是不同的。 如图所示，这些设计可能不适用于您的环境。

设计 1：作为 Azure Web 服务托管的 .NET API 代理隧道

设计示例 1 包含一个作为 Azure Web 服务托管的 .NET API。 该架构的虚拟坐席机器人层设计为虚拟坐席和认知服务分别位于 Azure 的不同容器中。 代理隧道的每个请求需要三次不同的调用：

  1. 第一个调用将音频发送到语音到文本转换服务进行转录。
  2. 第二个调用将转录文本发送到虚拟坐席，虚拟坐席分析其意图关闭 联系人所说/输入内容背后的含义或目的；联系人想要沟通或完成的内容并返回响应。
  3. 第三个调用将虚拟坐席的响应发送到语音到文本转换服务，以便合成为音频响应。 合成的响应被发送回CXone Mpower。

代理隧道为其发送的每个请求对虚拟坐席端的服务进行三次调用的架构示例。

由于代理隧道在每次请求时调用的次数较多，因此该架构示例可能会导致交互过程中出现延迟。

设计 2：在 .NET gRPC 客户端内屏蔽代理隧道端点

本示例的架构在容器化 .NET gRPC 客户端服务中屏蔽了一个代理隧道端点。 gRPC 客户端以 Docker 容器的形式构建，该容器以 Web 服务的形式托管。 来自 CXone Mpower 的请求通过 API 网关传递到 gRPC 客户端内的代理隧道端点。

该示例还包含一项授权服务。 CXone Mpower Studio 脚本从授权服务获取授权令牌并将其返回给脚本。 然后，该脚本通过 API 网关发送请求。

架构示例，脚本在向虚拟坐席发送请求之前，会向授权服务器发送令牌请求。

设计 3：“API”网关伪装为代理

这种架构相对简单，API 网关伪装为代理。 它可以完成代理隧道支持 CXone Mpower 自定义端点所需的一切。 也就是说，它可以处理有效负载转换、音频对话和转码以及系统之间的中继输入和输出。

简单架构示例，其中 API 网关被伪装为代理隧道。