資料管理

聯絡中心負責處理大量資料，從報告資料到呼叫清單。您可能需要在 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 指令碼的限制。

了解在 CXone 中建立和配對呼叫清單的一個很好的範例：

以下為建立具有定義欄配對的新呼叫清單的步驟和 API 調用範例。

驗證：
1. 執行驗證發現以獲取權杖連結。可存快取的生成權杖。
2. 從上一個步驟中發現的權杖端點請求權標：
  1. 使用 x-www-form-urlencoded 正文建立對 https://cxone.niceincontact.com/auth/token 的 POST 請求。
  2. 檢索五個鍵值對，如您的client_secret和client_id。

執行 API 端點發現：

從上面步驟 1 返回的權杖中提取 tenantId。

向 https://cxone.niceincontact.com/.well-known/cxone-configuration?tenantId={您的租戶 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"
}

Extract the "area" and "domain" fields from the reply.
Construct a base URI in the form of: https://api-{area}.{domain}.

使用 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
}
```
使用 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。

在活動通話期間，Jungle 聯絡中心希望從其 CRM 中提取客戶資料並將其顯示在客服專員應用程式中。在Studio中，它們首先從聯絡人那裡擷取基本的識別資訊，例如帳號。然後，指令碼向其 CRM 發出 GET 請求，核實資訊是否與客戶記錄相符。如果記錄存在，它將返回所有客戶資料。Jungle 不想顯示所有客戶資料，而且 API 不允許它們指定返回的內容。

其解決方案是建立一個存在於 Studio 和 CRM 之間的中介軟體。API 將 JSON 返回中介軟體，中介軟體將解析出所需的客戶詳細資料。然後，它將詳細資訊傳遞到Studio。這也使得 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 天）。在達到 TTL 之前，您可使用 REMVALUE 動作刪除資料。這可讓您透過指令碼完全掌控資料。最佳做法是在不再使用值時將其刪除，並將 TTL 保留為預設的 24 小時。

注釋：

如果有幾個變數需要由其他指令碼或聯絡人存取，則資料庫通常是最好的解決方案。
在設定這些變數的指令碼的生命週期中，其他指令碼或聯絡人可以分享非持續性公用變數。這些變數釋放後會自動清除。
這些動作「清單」中的項目限制為 1000 個。單個項目或資料也有 5KB 的限制。