Quantité maximale de données pouvant être traitées par le message ICM MDS

Introduction

Ce document décrit la quantité maximale de données qui peut être traitée via un message MDS (Intelligent Contact Management) ICM (Message Delivery Service) et l'architecture derrière.

Informations générales

Lors des recherches de base de données avec ICM (en utilisant dbworker.exe comme processus pour fournir l'interface entre le routeur et la base de données externe), il y a une quantité maximale de données qui peut être traitée par un message MDS.

La quantité totale de l'en-tête Réponse du langage de requête structuré (SQL) + DBW (db worker process) ne peut pas dépasser 4 096 octets. Il s'agit d'une limite codée en dur pour un message MDS.

Components Used

Les informations de ce document sont basées sur ICM version 11.6

Problème

Si trop de données ont été retournées à dbw à partir de SQL Server et que dbw ne peut pas les transmettre au routeur (RTR), une condition d'erreur est générée, similaire à celle-ci :

06:33:38:639 ra-dbw Trace : Mettre en file d'attente une demande de recherche

06:33:38:644 ra-dbw Trace : Thread DBWorker 4 (tableau ID 5612 : Stores_Reception_BT.SRDB_NEW) : Demande reçue : ID de transaction 14583170

06:33:38:658 ra-dbw Trace : DBWorker Thread 4 (ID 5612), TransactionID 14583170, Tentative de lecture de l'enregistrement :

06:33:38:679 ra-dbw Trace : DBWorker Thread 4 (ID 5612), transactionID 14583170, Succès.(..)

06:33:38:735 ra-dbw Trace : ID transaction DBWorker 14583170, échec ! résultat=10

06:33:38:745 ra-dbw Trace : Mettre en file d'attente une demande de recherche

“ 10 ” : signifie que trop de données ont été retournées à dbw à partir de SQL Server et que dbw ne peut pas les transmettre à RTR.

Afin d'imprimer l'erreur, ce niveau de suivi est utilisé :

dbw trace-level to 3 via Portico (le niveau de trace 3 doit être utilisé uniquement sur recommandation du TAC Cisco) , et ce niveau de trace pour RTR via l'outil rtrtrace(c:\icm\bin) :

Voici un exemple de la façon dont un message MDS est formé par le processus DBW :

02:22:01:273 ra-dbw Trace : Thread DBWorker 2 (tableau ID 15100:ICM_lookup_1) : Demande reçue : ID de transaction 3

02:22:01:273 ra-dbw Trace : DBWorker Thread 2 (ID 15100), TransactionID 3, Tentative de lecture de l'enregistrement :

02:22:01:273 ra-dbw Trace : DBWorker Thread 2 (ID 15100), TransactionID 3, Succédé.

02:22:01:273 ra-dbw Trace : MDS : Saisie de MDSAllocBuffer

02:22:01:273 ra-dbw Trace : SQLConnection::SetupColumnData: Données de colonne pour la colonne 1 Longueur = 5

02:22:01:273 ra-dbw Trace : SQLConnection::SetupColumnData: Données de colonne pour la colonne 2 Longueur = 0

02:22:01:273 ra-dbw Trace : SQLConnection::SetupColumnData: Données de colonne pour la colonne 3 Longueur = 0

02:22:01:273 ra-dbw Trace : MDS : Saisie de MDSSendInput02:22:01:273 ra-dbw Message Trace : Client : dbw envoyant un message au processus MDS. 

EMT : class=2 type=1 taille corporelle=116 

MDS : rsrvd=0 hdrsize=16 carrosseries=100 src=56 dst=1 priority=high 

MDS : flags=02 { side_a } vtime=0006f03b seqno=0000 class=4 type=16

0000 03 00 00 00 00 00 00 00 00 00 |........|

00008 03 00 00 00 8e 13 00 00 |........|

00010 02 00 00 00 00 00 00 00 00 |........|

00018 00 00 00 00 00 00 00 00 00 |........|

00020 00 00 00 00 05 00 38 30 |......80|

00028 31 30 34 00 8c 13 00 00 |104.....|

00030 02 00 00 00 00 00 00 00 00 |........|

00038 00 00 00 00 00 00 00 00 00 |........|

00040 00 00 00 00 00 00 00 00 00 |........|

00048 8d 13 00 00 02 00 00 00 |........|

00050 00 00 00 00 00 00 00 00 00 |........|

00058 00 00 00 00 00 00 00 00 00 |.......

00060 00 00 00 00      

Dans cet exemple, il y a 3 colonnes suite à une requête SQL vers une table configurée, toutes les colonnes ont un type VARCHAR(50) dans la base de données.

La réponse contient 5 octets de données de la 1ère colonne et 0 octet dans les 2 autres colonnes.

Sur la base de cette réponse, dbw forme le message MDS où chaque colonne est compressée dans un champ composé d'un en-tête de 24 octets + 2 octets de longueur + PAYLOAD + OFFSET.

Si la colonne ne contient pas de données, par exemple Longueur = 0, elle continuera à occuper : 24 octets en-tête + 2 octets en longueur + 2 octets OFFSET = 28 octets. 

Solution

Pour contourner ce scénario, vous devez supprimer les colonnes inutilisées des tables/config, réduire les noms de colonnes ou réduire la taille des données de colonnes.

Documents connexes :

https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-enterprise/116215-configure-dblookup-00.html