Monitoring Gateway件のサブスクリプション

コンタクトセンターの健全性および監視データに直接アクセスできます。 Monitoring Gatewayサブスクリプションにより、このデータをCXone Mpowerから引き出したり、独自の監視プラットフォームに取り込んだりすることができます。独自のプラットフォームでは、このデータを必要に応じて視覚化し、コンタクトセンターの健全性をより詳細に制御して把握することができます。このようなサブスクリプションにより、次の2種類のデータにアクセスできます。

パケット損失、ジッター率、MOSスコアなど、Voice Quality Metricsで提供されるすべての情報。
StudioスクリプトからのAPI呼び出しと応答に関する情報。

CXone MpowerはWebhook経由でこのデータを生成します。スクリプトAPI応答や音声品質データなど、特定の種類のデータをサブスクライブできます。サブスクリプションとプラットフォームの監視との接続を設定すると、CXone Mpowerは継続的にプラットフォームにデータをプッシュします。これにより、リアルタイムのアラートと分析が可能になり、問題が発生した場合にも情報に基づいた意思決定を行うことができます。また、傾向やパターンを特定して、コンタクトのエクスペリエンスに影響を与える前に品質の問題を予測し、積極的に防止するのにも役立ちます。これはMonitoring Gatewayとのネイティブ統合であるため、追加のオーバーヘッドや遅延なしに、これらのインサイトをすぐに使い始めることができます。

実際のシナリオでさらに詳しく学ぶ

シナリオ1: 音声品質の閾値違反に対する即時アラートのトリガー

状況:

通話品質の低下による中断を最小限に抑えたい。システムの健全性とアラートを監視するエンタープライズ監視プラットフォームをすでに使用しており、音声品質メトリックのリアルタイムの可視性が必要です。

アクション:

IT チームは、Monitoring Gateway サブスクリプションを設定して、CXone Mpower からの音声品質データを監視プラットフォームにストリーミングします。次のような主要なしきい値に対するアラートを構成します。

パケット損失: > 2%
ジッター: > 30 ミリ秒
MOSスコア: < 3.5

通話がこれらのしきい値のいずれかを超えると、監視プラットフォームは直ちにネットワーク運用チームにアラートを送信します。

結果:

ピーク時間帯には、複数の通話でジッターが高くなるとアラートが発せられます。チームは、障害が発生しているネットワークセグメントを迅速に特定し、広範囲にわたる通話品質の低下が発生する前にトラフィックを再ルーティングします。この積極的なアプローチにより、顧客への影響を防ぎ、インシデントの再発を減らします。

シナリオ 2: Studio スクリプト API 呼び出しにおける遅延と障害パターンの特定

状況:

通話ルーティングや IVR 音声応答システム(IVR)。音声またはキー入力を使用して情報を取得したり、着信音声通話を振り分けたりする自動化された電話メニュー。応答などの自動化されたワークフローで断続的な遅延が発生していることに気付きました。これらの遅延は顧客エクスペリエンスに影響を与え、通話処理時間を増加させます。

アクション:

技術チームは、Monitoring Gateway サブスクリプションを設定して、Studio スクリプト API 呼び出しと応答データをエンタープライズ監視プラットフォームにストリーミングします。ダッシュボードとアラートを構成して、次のものを追跡します。

API応答時間
エラー率
スクリプト間の失敗パターン

監視プラットフォームは、数時間以内に、トラフィックのピーク時に特定のスクリプトで繰り返し発生するレイテンシの急上昇を強調表示します。

結果:

チームは調査を行い、スクリプト内の非効率的な API 呼び出しシーケンスを発見しました。冗長な呼び出しを減らし、エラー処理を改善することでワークフローを最適化します。その結果、応答時間が大幅に短縮され、自動化されたプロセスがスムーズに実行されます。このプロアクティブな監視により、将来の中断を防ぎ、システム全体のパフォーマンスが向上します。

Monitoring Gatewayサブスクリプションを設定する

Webhookをサブスクライブするには、CXone Mpowerとプラットフォームの監視の両方で設定を行う必要があります。これにより、2 つのサーバー間でWebhookを確立できます。

前提条件

この監視データを受信できる独自のサーバーをセットアップする必要があります。このサーバーの要件は次のとおりです。

署名またはMTLS認証方式のいずれかを実装します。 CXone Mpowerインターフェイスでサブスクリプションを登録するときに、必要なキーや証明書の入力など、認証方式の詳細を追加します。

CXone Mpowerがイベントペイロードを送信できるエンドポイントを公開します。エンドポイントは、パブリックにアクセス可能なURLであり、POSTリクエストを受信できる必要があります。受信するデータのタイプごとに一意のエンドポイントが必要です。

Voice Quality Metricsペイロードの例を見る

以下は、スクリプトAPIレスポンスのJSONペイロードの例です。このペイロードを使用すると、次のことが可能になります。

{
	\"ContactId\":8675309,
	\"DataSource\": "SBC EXMS",
	\"MasterContactId\":86753099,
	\"BusinessUnit\":1337,
	\"SkillId\":4,
	\"SkillName\":\"Mysteries Report\",
	\"TeamId\":1010,
	\"TeamName\":\"Mysteries\",
	\"AgentId\":1174,
	\"Agent\":\"Sherlock Holmes\",
	\"DbKey\":null,
	\"StartDateTime\":\"2024-03-26T13:57:41.727Z\",
	\"EndDateTime\":\"2024-03-26T13:57:47.009Z\",
	\"From\":\"+18018675309\",
	\"To\":\"1174\",
	\"Direction\":null,
	\"AvgJitter\":null,
	\"AvgPktLoss\":null,
	\"AvgMos\":null,
	\"AvgRFactor\":null,
	\"CallScore\":null,
	\"Poc\":\"MysteriesReportLine\",
	\"LineType\":\"webRTC\",
	\"DisconnectReason\":\"1\",
	\"Disposition\":\"Very Mysterious\",
	\"Callduration\":561,
	\"Ringtime\":null,
	\"Disconnecttime\":null,
	\"Cluster\":\"L69\",
	\"SipResponseCode\":null,
	\"SipFailureCode\":null,
	\"SipIsDroppedCode\":null,
	\"SipAbandonedByOriginator\":null,
	\"AvgBitrate\":0.0,
	\"AvgRtt\":0,
	\"IspProvider\":\"London Speed\",
	\"CallSetupTime\":898.0,
	\"OperatingSystem\":\"Windows\",
	\"OsVersion\":\"10\",
	\"LocationCountry\":\"England\",
	\"LocationCity\":\"London\",
	\"SdkVersion\":\"1.30.9\",
	\"Browser\":\"Firefox\",
	\"ConnectionType\":\"TURN\",
	\"MediaTransport\":\"udp\",
	\"AgentConsoleType\":\"MAX\",
	\"AgentConsoleVersion\":\"24.2\",
	\"spearlineAnalysis\":null
}

スクリプトAPIペイロードのサンプルを表示すること

以下は、スクリプトAPIレスポンスのJSONペイロードの例です。このペイロードを使用すると、次のことが可能になります。

成功したAPIレスポンスとエラーAPI応答を追跡すること。
エラーが発生したタイミングを把握するため、APIメッセージにアクセスすること。
同時呼び出し、スクリプト、アクションのボリュームを表示すること。
APIレイテンシデータを表示すること。
次の分布を表示すること：
- 最も頻繁に使用されるスクリプト。
- 最も頻繁に使用されるアクション。
- APIエラー。

{
	"source":"NICE",
	"event":"SCRIPT_API_MONITORING ",
	"timestamp":"4/20/2024 06:13:37 AM",
	"metadata":"[{
		\"busNo\":\"4600000\",
		\"messageId\":\"123ed4d5-06bc-78a9-bf0-0f12345eb678\",
		\"contactId\":\"460000000000\",
		\"masterContactId\":\"460000000000\",
		\"scriptId/version\":\"130000000\",
		\"scriptName\":\"sub_webservice\",
		\"actionId\":\"40\",
		\"actionName\":\"Snippet\",
		\"actionLabel\":\"Do RESTful web service API call\",
		\"dateTime\":\"4/21/2023 11:20:20 AM\",
		\"apiEndpoint\":\"https://callbackurl.com",
		\"apiResponseCode\":\"200\",
		\"apiResponseMessage\":\"SUCESS\",
		\"responseTime\":\"1.000000\"
	}]” 
}

サブスクリプション登録を作成する

必要な権限: ゲートウェイサブスクリプション > 作成

CXone Mpowerで、ゲートウェイサブスクリプションに移動します。
1. アプリセレクターをクリックして、次を選択します：Monitoring Gateway。
2. ゲートウェイサブスクリプションをクリックします。
[作成]をクリックします。

認証方法として、MTLSまたはSIGNATURE AUTHのいずれかを選択します。これは、CXone Mpowerとプラットフォームの監視との間の認証です。

このステップのフィールドの詳細については、

認証タイプ	詳細
MTLS	相互TLS (MTLS)認証を参照してください。相互に承認されたキーを使用してサーバーとクライアントの両方を認証することにより、安全な通信が保証されます。 CXone MpowerWebhookサービスは、受信サーバーから求められると、キーを使用して自身を認証します。
Signature	Signature認証は、Webhookのペイロードを検証します。 Webhookプロデューサーとコンシューマーの両方が知っているシークレットキーが必要です。コンシューマー(サーバー)はシークレットキーを使用して署名を計算し、それをプロデューサー(CXone Mpower)から送信された署名と照合します。

認証タイプ

詳細

MTLS

相互TLS (MTLS)認証を参照してください。相互に承認されたキーを使用してサーバーとクライアントの両方を認証することにより、安全な通信が保証されます。

CXone MpowerWebhookサービスは、受信サーバーから求められると、キーを使用して自身を認証します。

Signature

Signature認証は、Webhookのペイロードを検証します。 Webhookプロデューサーとコンシューマーの両方が知っているシークレットキーが必要です。コンシューマー(サーバー)はシークレットキーを使用して署名を計算し、それをプロデューサー(CXone Mpower)から送信された署名と照合します。

サーバーに実装したエンドポイントのCALLBACK URLを入力します。

受信するデータの選択ドロップダウンから、受信するデータを選択します。

このステップのフィールドの詳細

データタイプ	詳細
スクリプトAPIモニタリング	これは、Studioスクリプト内で行われたAPI呼び出しに対するリクエストまたはレスポンスです。
音声品質メトリック	これはエージェントのクライアントで追跡されるWebRTCデータです。このタイプのデータはVoice Quality Metricsインターフェイスでも利用できます。

追加をクリックします。
オプションで、同じサブスクリプションに複数のデータタイプを追加できます。さらにデータタイプを追加する場合は、それぞれに固有のコールバックURLが必要です。他のデータタイプを追加するには、前の手順を繰り返します。

認証の詳細を設定します。表示されるフィールドは、このタスクで以前に選択した認証方法によって異なります。

MTLS

フィールド	詳細
証明書データをアップロード	を選択した場合、これはパブリックキー、発行者情報、有効期限を含むTLS証明書です。
キーを入力	サーバーのプライベートキーです。 CXone Mpowerは各通信ごとにこのキーと証明書をサーバーに提示します。

署名の認証

フィールド	詳細
コンシューマーID	を選択した場合、リクエストを行うクライアントまたはコンシューマーを参照するために使用される一意の識別子。このIDは認証プロセスの重要な部分であり、リクエスト者のアイデンティティを確立し、そのアイデンティティを特定の暗号化キーにリンクするのに役立ちます。
プライベートキー	デジタル署名を作成するために使用されるプライベートキー。デジタル署名を作成するプロセスでは、通常、メッセージまたはデータのハッシュを生成します。そのハッシュは送信者のプライベートキーで暗号化されます。結果として得られるデジタル署名は、メッセージと、その生成に使用されたプライベートキーの両方に対して一意になります。
キーバージョン	デジタルデータの署名に使用される暗号化キーの特定のバージョンまたはイテレーション。キーのバージョン管理は、セキュリティ上の目的で暗号化キーを定期的にローテーションまたは更新する必要がある環境では特に重要です。
署名URL	デジタル署名を生成するために使用されるURL。これは通常、プロトコル、ホスト名、パス、およびリクエストのクエリ文字列パラメータを含む完全なURLです。このURLは、デジタル署名を生成するときにデータ入力の一部として使用されます。リクエストの整合性と信頼性を確保するために、URLとヘッダーまたは本文を使用して文字列が作成されます。次に、文字列は暗号化アルゴリズムを使用して署名されます。この署名は、クエリ文字列またはヘッダーとしてリクエストに追加されます。
更新レート	キーが更新される頻度 (5分ごとなど)。

オプションで、この統合についてCXone Mpowerに連絡してもらいたい担当者のEメールアドレスを追加できます。 Webhookがペイロードの配信に失敗した場合、CXone MpowerはここにあるアドレスにEメールを送信します。
[送信]をクリックします。