数据管理

从报告数据到呼叫列表，联系中心处理大量数据。您可能需要在 CXone 之间传输数据，并且可能需要使用 CXone 内的数据。您如何处理 Studio 脚本或 API 中的数据会影响系统的性能和交互的质量。此页面可帮助您有效管理数据。

适用于正确工作的恰当工具

Studio 的主要目的是控制联系人路由。您在 Studio 脚本中执行的任何操作都应以联系人为中心。您需要的与联系人无关的任何数据处理都应在 Studio 之外进行。Studio 不是为处理大量数据而设计的，因此其数据限制为 32KB。在处理联系人时这已经足够了，其可使服务器保持高效运行。

下面是一个需要数据管理的任务，以及完成该任务的两个示例。

示例任务：每天分析坐席数据，以确定潜在问题，例如过长的休息时间或非计划休息。

不适当的解决方案：创建每天运行的已计划 Studio 脚本。该脚本首先进行 API 调用以提取当天的坐席列表，然后提取当天的坐席状态历史记录。然后，该脚本会检查是否有任何坐席的休息时间超过 30 分钟且为非计划休息。它还会搜索任何明显的长时间休息，例如四个小时的上厕所时间。该脚本还确定哪些坐席在不可用状态下花费最多时间，以及哪些坐席在特定技能关闭 用于根据坐席的技能、能力和知识自动传递交互上花费最多时间。

为什么这个方法不好：

  • 此任务未关注单个联系人；Studio 不是适合该工作的恰当工具。

  • Studio 不适用于处理大量数据，它主要用于通话处理。您的租户关闭 用于管理 CXone环境的技术支持、计费和全局设置的高级组织分组可能会遇到性能问题，因为内存中的大量数据会导致服务器性能不佳。

  • Studio 的数据限制为 32KB。此方法要求您将数据分成多个小块以保持在该限制以下。因此，该脚本可能会运行很长一段时间，这需要大量资源。

  • 此任务最好由可以使用 CXone API（而不是 Studio 脚本）的工程人员来解决。

  • Studio 通过识别诸如以下信息来达到最佳效果：哪个坐席在某个状态下花费最多时间，或者哪个坐席处理的呼叫数量最少。在外部服务器上处理这些数据可使您生成更有价值的指标。


好的解决方案：这只是解决该任务的一种潜在方法。针对您场景的解决方案可能需要不同的方法。

解决此任务的一种方法是在 AWS 服务器上运行 Python，其可提供更多的处理能力。从该服务器中进行相同的 API 调用，以便提取当天的坐席列表和坐席状态历史记录。将这些数据放入表或者数组中。数据库表将是首选，其可使您在未来更轻松地比较和分析这些数据。返回的数据可能以兆字节为单位，这对于数据库来说没有问题，但却超出了 Studio 中的数据限制。您可以将每个坐席的完整状态历史记录都放在内存中；您可以在一个地方使用完整的数据集，而不是 Studio 脚本中的多个小块数据。

现在，您可以开始使用这些数据来生成所需的指标，例如根据在某些状态下花费的时间生成有序的坐席列表。数据库可以帮助您按照您认为合适的方式呈现这些数据，而不是受制于 Studio 脚本的限制。

以下说明举例说明了为创建具有已定义列映射的新调用列表，您可以执行的步骤和 API 调用。

  1. 验证：
    1. 执行身份验证发现 ，以获取令牌链接。可以缓存生成的令牌。
    2. 从上一步中发现的令牌端点请求令牌：
      1. 使用 x-www-form-urlencoded 正文创建对 https://cxone.niceincontact.com/auth/token 的 POST 请求。
      2. 检索五个键值对，例如 client_secret 和 client_id。
  2. 执行 API 端点发现：
    1. 从以上步骤 1 返回的令牌中提取 tenantId。
    2. 向 https://cxone.niceincontact.com/.well-known/cxone-configuration?tenantId={YOUR TENANT ID} 发出 GET 请求。示例回复：
      {
	"private": false,
	"area": "na1",
	"cluster": "B32",
	"domain": "niceincontact.com",
	"acdDomain": "nice-incontact.com",
	"uhDomain": "nice-incontact.com",
	"ui_endpoint": "https://na1.nice-incontact.com",
	"auth_endpoint": "https://na1.nice-incontact.com",
	"api_endpoint": "https://api-na1.niceincontact.com",
	"tenantId": "11eb0358-724b-3970-97e5-0242ac110003"
}
    3. Extract the "area" and "domain" fields from the reply.
    4. Construct a base URI in the form of: https://api-{area}.{domain}.

  3. 使用 POST /lists/call-lists 创建呼叫列表映射。

    此 API 会创建一个使用 {listId} 标识的调用列表。每次调用都会更新源列名称到 CXone 字段的数据映射。一般来说，只有当这些数据中的列标题发生变化时，您才会这样做。对于此 API，您必须将值定义为查询参数，然后提供一个包含 destinationMappings 对数组的 JSON 正文，每个对均由 fieldName 和 fieldValue 组成。这些用于映射在以下步骤 4 中上传的数据。

    您可以在在线帮助中查找 CXone 定义的字段名称。字段值是源数据中要映射到 CXone 字段的列名称。

    POST 示例为：https://api-{area}。{domain}/incontactapi/services/v27.0/lists/call-lists? {listname}&externalIdColumn={fieldValue}，带有 JSON 正文。预计返回将是带有响应正文的 200 代码：

    {
	"listId": 0
}

  4. 将 POST /lists/call-lists/{listId}/upload 与在步骤 3 中创建的 listId 结合使用来上传呼叫列表数据。listId 是在 API 调用的路径中指定的，实际调用列表数据是在请求正文中提供的。

    一个重要细节是该文件的格式。listFile 参数是 base64 编码文件形式的调用列表数据。

    此外，您可以选择通过将 "startSkill" 标志设置为 "true" 以作为请求正文的一部分，在上传完成时启动拨号器技能。

    POST 示例为： https://api-{area}。{domain}/incontactapi/services/v27.0/lists/call-lists/{listId}/upload。

在活动呼叫过程中，The Jungle 联系中心希望从其他们 CRM 中提取客户数据并将其显示在 坐席应用程序 中。在 Studio 中，他们首先捕获联系人的基本识别信息，例如帐号。然后，该脚本向他们的 CRM 发出 GET 请求，从而检查这些信息是否与客户记录匹配。如果记录存在，它将返回所有客户数据。The Jungle 不想显示所有客户数据，并且 API 不允许他们指定返回的内容。

他们的解决方案是构建一个存在于 Studio 与 CRM 之间的中间件。API 将 JSON 返回给该中间件，该中间件解析出所需的客户详细信息。然后，它将这些详细信息传递到 Studio 中。这也使得 The Jungle 能够保持在 32KB 的数据限制之内。

推送与轮询

一般来说，您希望使用基于推送的架构。通过轮询等待某些事情发生本来就需要消耗资源，而推送数据则是按需进行的；当不需要时，它不会消耗资源。推送数据通常可使您处理较小的数据块。推送数据通常是为了满足实时需求，例如单个活动联系人。轮询通常用于集成，其不能被如此大地细分或分段。

例如，您可能希望在使电话置于暂候状态时更新坐席的 UI。如果您在脚本中使用了 /get-next-event API 来侦听（或轮询）来自坐席客户端的暂候事件，这将不断阻塞线程。而您希望在单个实例中推送数据，以避免不断使用服务器资源。在类似情况下，也许通过 CRM 集成，您无需等待请求返回，而是进行 API 调用来推送数据并释放线程。然后，使用信号 API 将这些数据发送回脚本。您还可以进行 API 调用，以查看该请求是否已完成，如果是，则发送这些数据。

处理大量数据

如果您想要管理大型数据集，例如整个联系中心的历史数据，请使用 CXoneAPI 或 CXone 质量管理。在大规模情况下，您可以使用 Snowflake 为您的业务单位提取所有数据；CXone 质量管理 为您提供获得联系中心数据的直接管道，因此您不会受制于进行 API 调用来提取数据。在小规模情况下，以上解释的示例任务可能是最佳的。没有大量数据的小型企业或想要查找特定指标的企业可为类似任务构建小应用程序。例如，您可以构建一个应用程序，在有员工在某种状态下花费了太多时间时，向其经理发送电子邮件。

避免在脚本中使用大型数据集的示例

以下举例说明了可以避免在您的 Studio 脚本中使用大型数据集的常见场景。您还可以参考以上示例，这可避免将过多的客户数据从 CRM 传输到 Studio。

  • 按字段筛选 API 响应：

    某些 API 能够筛选返回的信息。例如，如果您请求 CRM 返回某个案例的信息，则某些 CRM API 可使您准确指定要返回的信息字段。如果您正在使用的 API 具有此功能，您可以仅使用您需要的信息，从而避免产生大型数据集。如果供应商的 API 没有此功能，您可能需要与供应商合作来添加该选项，或者您可以构建一个中间件。中间件可以接收 Studio 之前的数据，您可以筛选掉不需要的数据，然后将数据返回给 Studio。

  • 按时间筛选 API 响应：

    如果 API 可使您按时间量进行筛选，则使用此功能来最大限度地减少数据量。如果您只需要一天或一周的数据，则务必筛选响应，以便仅包含该时间范围内的数据。

  • 筛选单个联系人的数据：

    Studio 不是数据管理工具，它是联系人管理工具。Studio 和 Studio 操作的功能可使您处理主要针对单个联系人的数据。您可以使用多种方法使您的数据特定于单个联系人，例如通过 IVR 收集信息，或者一次提取一条记录或一个案例的 CRM 数据。

数据存储

您有多个存储数据的选项。如果您有 Snowflake 帐户，则可以使用 Studio 将联系中心数据从 CXone 移动到 Snowflake。NICE 会将您的数据存储 24 个月，您可以从 Snowflake 检索这些数据。您还可以使用 云存储服务 来存储呼叫录音或聊天记录等文件，或者将它们移动到您自己的服务器。有关更多信息，请联系您的 CXone 支持代表。

意外成本

一般来说，您不会因进行过多的 API 调用或类似操作而产生额外费用。但是，存储某些数据的方式可能会产生成本。以下是不正确的数据存储导致意外计费的示例：

  • 创建许多脚本变量并将它们存储在针对每个联系人的文本文件中，而没有包含清理这些文件的过程。

  • 将 IVR 发布路径信息存储到文件中以供以后使用。也许您希望未来将这些信息用于报告目的。

  • 将 API 结果存储在一个文件中，该文件会随着新结果的添加而不断扩展。随着时间的推移，以及当该文件的大小增加时，这会产生存储成本。

  • 将文件存储在 CXone 云储存 上。如果您使用 云储存，请确保您了解有关存储的任何参数。您可以参考 云储存 的帮助内容，或者联系支持代表。

来自 Studio 的 API 调用

API 可帮助您高效地处理数据。您可以通过下列操作从 Studio 进行 API 调用。以下列表解释了使用不同操作之间的技术差异：

  • SNIPPET：可使您将自定义代码添加到脚本中。您可以使用此操作进行 API 调用、准备有效负载、解析动态数据对象等。使用此操作进行 API 调用时，注意响应速度。此操作在线程处于活动状态的整个时间内都使用该线程。如果响应缓慢，这意味着线程始终被阻塞，从而可能对服务器性能产生负面影响。例如，如果同时使用所有线程，呼叫者可能会听不到声音。

  • REST API：可使您进行 REST API 调用并使用更少的服务器资源。您应尽可能使用此操作进行 API 调用，但它专门接受 JSON。如果 API 不返回 JSON，您可能需要使用 SNIPPET 操作。根据您的任务，您可能需要将此操作与 SNIPPET 结合使用，因为 SNIPPET 可执行诸如准备有效负载等操作。

  • ConnectAuth：验证在 Integration Hub 中创建的连接器。Integration Hub 是一个集中的源，用于构建、管理和执行从 CXone 到第三方平台的集成。此操作不会阻塞线程。

  • ConnectRequest：经过身份验证后触发 Integration Hub 请求。此操作不会阻塞线程。

其他数据相关 Studio 操作

Studio 有几个操作可以临时存储和检索数据库表中的少量数据，以便其他脚本可以访问这些数据。这些操作的行为类似于字段或值的列表。使用它们来存储多个值或在其他脚本中进一步需要的值。完整的操作列表为：PUTVALUE、GETVALUE、REMVALUE、GETLIST 和 CLEARLIST。

这些操作使用唯一的数据类型，而这种数据仅能通过此组 Studio 操作来访问。无法以任何其他方式来访问数据。无论用户拥有何种权限，他们都无法访问并使用此数据库。

如同在 PUTVALUE 操作的 TTL hrs（存活时间）属性中所配置的，这些值在限制了时间的数据集表格中列出。默认值为 24 小时，但可以设为 1 小时到 168 小时（7 天）。您可以使用 REMVALUE 操作删除 TTL 时间之前的数据。这样您就可以完全控制脚本中的数据。最佳做法是当值不再使用时将其删除，并将 TTL 保留默认的 24 小时。

注意：

  • 如果其他脚本或联系人需要访问多个变量，数据库通常是最好的解决方案。
  • 在设置这些变量的脚本的整个生命周期中，其他脚本或联系人可以共享非持久性公共变量。变量会在释放后自动清除。
  • 这些操作在该“列表”中的项目数限制为 1000 个。单个项目或一条数据也有 5KB 的限制。