Dit document beschrijft een probleem dat u hebt ondervonden wanneer u de Cisco Unified Contact Center Express (UCCX)-systemen naar versies 8 en later upgrades uitvoert en een groot aantal reserveonderdelen naar het systeem wordt geüpload of wanneer u in versies 8 en later een groot aantal reserveonderdelen naar het systeem probeert te uploaden.
UCCX versies 7.x en gebruikt later Microsoft SQL (MSSQL) als de databases. MSSQL maakt in termen van gegevensopslag geen onderscheid tussen gegevens van verschillende typen. Wanneer het gegevens in een 3 GB gegevensbestand opslaat, slaat MSSQL alle gegevens, ongeacht het type, op in één 3 GB blok.
Daarentegen maakt Informix, de databases die bij UCCX versies 8.0 en hoger worden gebruikt, een onderscheid tussen gegevens van verschillende typen wanneer deze op de schijf worden opgeslagen. De typische gegevens van de gegevensbank (zoals Kiekjes, Tekens, en Integers.) worden opgeslagen in een schijfbrok gewijd aan de gegevensbank, terwijl de gegevens van de BLOB (Binary Large Object), als om het even welke in de gegevens van de gegevensbank lijst bestaat, in een afzonderlijk gedeelte van de schijf opgeslagen wordt, die een sbspace wordt genoemd. Een sbspace is een logische eenheid die bestaat uit een of meer schijfeenheden die BLOB gegevens opslaan. Informix slaat traditionele gegevens en BLOB gegevens afzonderlijk op om de prestaties van het lezen en schrijven van BLOB gegevens van en naar de database en schijf te verbeteren. Wanneer een database wordt gecreëerd die BLOB gegevens bevat, moet de beheerder de grootte van de diskgroepen voor de database (om traditionele gegevens op te slaan) en de grootte van de ruimte afzonderlijk specificeren.
Voor gegevensopslagmechanismen plaatst MSSQL alle gegevens in één emmer van grootte N, terwijl Informix de opslag van deze gegevens in twee emmers verdeelt: één emmer voor de contextuele informatie over BLOB-gegevens van grootte X, en een ander emmer voor de BLOB-objecten zelf van grootte Y.
In UCCX heeft de beheerder de optie om positieartikelen te uploaden die uit claims, documenten, grammatica's en scripts bestaan. De inhoud van deze items wordt opgeslagen in de corresponderende database-tabellen als BLOB-gegevens en contextuele informatie over deze items, zoals bestandsnaam, map, laatst aangepaste tijd, laatste aangepaste gebruiker, lengte en checksum.
Bewaarposten worden opgeslagen in de UCCX database db_cra_cache. In UCCX versies 7.x en eerder die MSSQL gebruiken, is db_cra_cache 3 GB in grootte en bevat zowel de contextuele als de BLOB-informatie. In UCCX versies 8.0 en hoger die Informix gebruiken, is de opslagkit die aan de db_cra_opslagplaats is gekoppeld, 10,2 MB groot en slaat alleen de contextuele informatie over de positieartikelen op. De inhoud van de positieobjecten wordt in BLOB formaat opgeslagen in een ruimte genaamd uccx_sbspace. In UCCX versies 8.0 en hoger is de uccx_sbspace 3 GB groot.
De uitvoer van de CD-serverschijf van show op een UCCX versie 8.0+ server onthult het onderscheid tussen deze twee datastores:
Afhankelijk van de mix van gegevens in de MSSQL database is het mogelijk dat de grootte van de BLOB gegevens die opgeslagen zijn in de MSSQL database de gedefinieerde grootte van de sbspace in Informix overschrijdt wanneer migratie of upgrade wordt geprobeerd. Op dezelfde manier is het mogelijk dat de contextuele informatie over de BLOB gegevens die opgeslagen zijn in de MSSQL database de administratief gespecificeerde grootte voor die gegevens in de Informix database chunk overschrijdt.
Wanneer dit gebeurt, zal upgrade of migratie van UCCX versie 7.x naar UCCX Versie 8.x mislukt, omdat ofwel de db_cra_cache of de uccx_sbspace niet groot genoeg is om dezelfde informatie te verwerken die in MSSQL is opgeslagen. Dit is meestal een probleem in een UCCX-systeem dat een groot aantal oproepen bevat. Contextual Prompt and BLOB data moeten de db_cra_cache en de uccx_sbspace delen met documenten, grammars en scripts, maar deze andere Repository types zijn doorgaans klein in omvang en aantal.
Neem bijvoorbeeld een UCCX versie 7.x-systeem met tienduizenden oproepen in acht, elk met slechts een paar seconden audio. In UCCX versie 7.x die MSSQL gebruikt, worden de snelle inhoud en contextuele informatie opgeslagen in dezelfde 3-GB unk. Omdat er veel kleine propjes zijn, kan de database 50 MB contextuele informatie over de propts opslaan, maar slechts 2 GB BLOB data die de audio van de propts representeert. Daarom hebben de Prompts in de Repository ruim 2 GB van de 3 GB-limiet die bij het creëren van een database is ingesteld.
Wanneer u probeert om dit systeem te migreren naar UCCX versie 8.x en Informix, mislukt de migratie omdat de 50 MB aan contextuele informatie de 10,2 MB limiet van db_cra_repostiory overschrijdt ook al past de 2 GB aan Prompt content goed onder de limiet van de uccx_sbspace.
Omgekeerd, denk aan een UCCX versie 7.x systeem met minder, maar nog steeds veel, lange Prompts. Met minder snelle maar grotere hoeveelheden is de verhouding tussen snelle inhoud en contextuele informatie anders. In UCCX versie 7.x en MSSQL kan de Prompt-inhoud 2,8 GB van de db_cra_opslagplaats innemen en de contextuele informatie 3 MB. Dit systeem werkt met succes, aangezien 3 MB past in de db_cra_cache en de 2,8 GB past in de uccx_sbspace toegewezen.
Meestal, wanneer u probeert te migreren naar UCCX versies 8.x en later, overschrijden de contextuele gegevens over de Prompts die naar de UCCX versies 7.x of eerder systeem zijn geüpload de groothandelsgrens van db_cra_storage voordat de vroege inhoud de groottegrens van de uccx_sbspace overschrijdt. Bovendien is de echte vrije ruimte die beschikbaar is voor op maat gesneden bewaarinstellingen 6,9 MB, omdat de standaardconfiguratie 3,4 MB van de db_cra_cache verwerkt.
Wanneer u nieuwe positieartikelen (documenten, grammofoons, benaderingen, scripts) probeert te uploaden naar een UCCX-systeem met versies 8 of hoger, ontvangt u deze foutmelding:
The files uploaded are not valid or not structured
according to languages. Please check the help
documentation for more details.
De migratie van UCCX versies 7.0(2) en eerder naar versies 8.0 en wijzigt later het besturingssysteem en de databases waarop de toepassing draait. De databases die bij UCCX versies 8.0 worden gebruikt, slaan later gegevens op een andere manier op dan die bij UCCX versies 7.x en hoger. Dit heeft gevolgen voor de migratie van UCCX, omdat databases die grote datasets in UCCX versie 7.x bevatten, mogelijk niet correct naar UCCX versie 8.x migreren.
Voordat u naar UCCX versie 8.x migreert, moet u de hoeveelheid db_cra_cache en uccx_sbspace schatten die nodig is om de huidige reserveonderdelen in het UCCX versie 7.x-systeem op te slaan, om eventuele toekomstige groei op te nemen.
Bepaal om te beginnen het aantal rijen in elk van de tabellen van de Repository die informatie bevatten over zowel de items van de Repositor als de mappen.
Gebruik Microsoft SQL Query Analyzer om het aantal rijen van de tabellen van de Bewaarmap met deze opdrachten op te nemen:
Informix maakt een boekhouding van de grootte-op-schijf in termen van pagina's. Bepaal het aantal pagina's dat in gebruik is van de inhoud van de tabellen voor de map Repository met deze formule en vervang het aantal rijen voor de tellingen die zijn verkregen met de eerder genoemde opdrachten. Bereken deze formule voor elke tabel en voeg het aantal pagina's toe. Het is niet mogelijk het aantal pagina's nauwkeurig te bepalen als het aantal rijen van elke tabel eerst wordt toegevoegd en dan wordt het resultaat van de formule berekend.
# pagina's documentsfoldertbl + # pagina's grammaticale - omslagvoud + # pagina's souvendertbl + # pagina's scriptsfoldertbl = Totaal aantal pagina's voor tabellen met mappen
Voltooi dezelfde berekening om het totale aantal pagina's voor de bestandstabellen te bepalen die de eigenlijke positiebestanddelen bevatten. Voer deze opdrachten in met Microsoft SQL Query Analyzer:
Bepaal het aantal pagina's dat door de inhoud van de tabellen op het bestand van de afbeelding wordt bezet met deze formule en vervang het aantal rijen met de tellingen die zijn verkregen uit de eerder genoemde opdrachten. Bereken de formule voor elke tabel en voeg het aantal pagina's toe.
# pagina's documentaires + # pagina's grammarsfiletbl + # pagina's loketten loketten + # pagina's scriptsfiletbl = Totaal aantal pagina's voor bestandstabellen
Voer deze berekeningen uit om de huidige schatting van de grootte van de reservegegevens te voltooien:
Als uit de berekeningen blijkt dat de contextuele informatie over de reserveonderdelen en mappen die momenteel geüpload worden in UCCX versie 7.x meer dan 3,4 MB bedraagt, wordt het aanbevolen het ontwerp van de reserveoptie opnieuw te bekijken. Hoewel de beschikbare vrije ruimte voor de contextuele informatie over reserveposten in db_cra_cache 6,9 MB is, wordt aangeraden om 50% beschikbaar te laten voor toekomstige groei. De groeiramingen en de maximaal toegestane bezette ruimte worden berekend per inzet, op basis van verwachte groeifactoren.
Omdat Prompts doorgaans de grootste verbruiker van de Repository-ruimte zijn, worden de methoden die worden gebruikt om het aantal Prompts in de Repository te verminderen in de rest van dit artikel besproken.
Als de Prompts die momenteel in de UCCX versie 7.x worden geüpload een belangrijk deel van de algehele opslagruimte voor opslagruimte voor opslagruimte voor opslaglocatie beslaan, dan dient u het juiste ontwerp, de opslag en het ophalen te herhalen voordat u naar UCCX versie 8.x gaat. Wanneer u probeert het juiste ontwerp opnieuw te activeren, bekijkt u deze opties:
VXML wordt gebruikt om Prompts op bestelling van een off-box locatie op te halen en af te spelen. Als u grote hoeveelheden Prompts op een afzonderlijke webserver opslaat, kunt u:
Hoewel er veel opties zijn om de aanpassing van Interactive Voice Response (IVR) in VXML te instrumenteren, worden het UCCX-script en de VXML-toepassing gebruikt om een Prompt van een off-box webserver op te halen en aan de beller af te spelen, als basis voor verdere ontwikkeling gebruikt. Net als andere aangepaste scripting in UCCX, worden de scripts die in deze sectie worden geboden als richtlijn en worden niet ondersteund door het Cisco Technical Assistance Center (TAC).
De stap Voice browser verbruikt een VXML document. Dit document moet worden gemaakt na de stap URL-document maken en moet worden gehost op een webserver die niet aan UCCX is gekoppeld. Hoewel de VXML-toepassing is geschreven om de invoer van de beller te accepteren via Dual Tone Multi Frequency (DTMF), is deze toepassing alleen ontworpen om een prompt te spelen die buiten de box wordt gehost. Het kan echter worden uitgebreid om aanvullende functionaliteit in te bouwen. Aangenomen wordt dat de rest van het UCCX script, voordat de Voice browser stap wordt opgeroepen, de benodigde logica heeft om te bepalen welke prompt wordt weergegeven en een String variabele op de Prompt filename is ingesteld.
Aangezien het VXML document statisch is, maar de Prompt door het wordt gespeeld dynamisch is, wordt een server-side scripting taal gebruikt om het VXML document te maken. Dit kan elke server-side scripting taal zijn die de mogelijkheid heeft om de Content-type header van de XML GET Application response in te stellen. In dit voorbeeld wordt PHP gebruikt.
De PHP pagina is geschreven om een URL parameter te accepteren in een GET aanvraag die de audio Prompt naam representeert die wordt afgespeeld. De PHP pagina schakelt de VXML sjabloon aan met de Prompt filename die is doorgegeven in de URL-parameters van GET Aanvraag om het volledige VXML-document te vormen. Het stelt dan de Content-type header van de respons op XML in en stelt de inhoud van de reactie in op de VXML-inhoud.
<?php
$wav_filename = $_GET['wav'];
$xml_string = '<?xml version="1.0"?>
<vxml xmlns="http://www.w3.org/2001/vxml" version="2.0">
<form>
<block>
<prompt bargein="true">
<audio src="http://<Servername or IP Address>/
<Path>/'.$wav_filename.'.wav" />
</prompt>
</block>
</form>
</vxml>';
header('Content-type: text/xml');
echo $xml_string;
?>
Om een goed gevormd VXML document te produceren, moet de voorbeeldpagina van PHP benaderd worden met een GET aanvraag die een parameter wav en een String waarde bevat, in de veronderstelling dat de voorbeeldpagina generatevxml.php genoemd wordt:
http:///path/generatevxml.php?wav=MenuPrompt
Zorg ervoor dat het MenuPrompt.wav zich bevindt op de locatie op de externe webserver zoals gespecificeerd in de VXML sjabloon in de PHP pagina.
Gebruik in het UCCX-script de stap URL-document maken om een GET aanvraag van generatevxml.php uit te voeren door de basisURL van http://<Server,naam of IP Address>/path/generatevxml.php?wav= met de Prompt bestandsnaam die is afgeleid van de vorige scripting logica, aan te passen en plaats het resultaat in een documentvariabele.
Maak een stap Voice die de documentvariabele verwerkt.
Wanneer dit script wordt aangeroepen, mits zowel generatevxml.php als MenuPrompt.wav toegankelijk zijn op de webserver vanaf UCCX, speelt de Prompt.wav Prompt/Prompt aan de beller.
Als VXML toepassingen worden gebruikt om Prompts off-box op te slaan, zodat ze alleen toegankelijk zijn wanneer ze nodig zijn om ze aan de beller af te spelen, maakt het een grotere efficiëntie, beheersbaarheid en bruikbaarheid mogelijk. Dit is een probleem dat in overweging moet worden genomen als een UCCX versie 7.x-systeem is geüpgraded naar een UCCX versie 8.x-systeem en het aantal aanvragen zo is dat de inhoud van de contextuele informatie groter is dan de db_cra_opslagplaats of de uccx_sbspace.