Cisco Cisco Customer Voice Portal Downloads Betriebsanweisung
C
HAPTER
5:
V
OICE
XML
S
ERVER
L
OGGING
V
OICE
XML
S
ERVER
U
SER
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
63
recognized. This most likely will occur if the voice browser refers to an application that does
not exist. The last description is error, indicating that some other error occurred.
not exist. The last description is error, indicating that some other error occurred.
Note that the error log is not designed to be parsed, even though the columns are separated with
commas. This is because when the error log reports a Java-related error, it may include what is
called a “Java stack trace”, which contains multiple lines of output.
commas. This is because when the error log reports a Java-related error, it may include what is
called a “Java stack trace”, which contains multiple lines of output.
Error! Reference source not found. Error! Reference source not found. provides a reference for the
user to find descriptions and workarounds for some errors that can be seen in the call error log.
user to find descriptions and workarounds for some errors that can be seen in the call error log.
The VoiceXML Server Administration History Log
Whenever a VoiceXML Server-specific administration script is run, a log file is updated with
information on the script that was run. The administration log file names begin with
“admin_historyYYYY-MM-DD.txt” where YYYY, MM, and DD are the year, month, and day
when the administration log was first created and can be found in the
information on the script that was run. The administration log file names begin with
“admin_historyYYYY-MM-DD.txt” where YYYY, MM, and DD are the year, month, and day
when the administration log was first created and can be found in the
logs
directory of the
VoiceXML Server. VoiceXML Server administration history log files are rotated daily. Note that
if no administration activity occurred on a particular day, no VoiceXML Server administration
history log will be created. The file contains three columns: the time, what script was run, and its
result, separated by commas. The result is usually “success” and if not, contains the description
of the error encountered. The possible values are:
if no administration activity occurred on a particular day, no VoiceXML Server administration
history log will be created. The file contains three columns: the time, what script was run, and its
result, separated by commas. The result is usually “success” and if not, contains the description
of the error encountered. The possible values are:
server_start
- Listed when the Java application server starts up.
deploy_all_new_apps
- Listed when the
deployAllNewApps
script is run.
flush_all_old_apps
- Listed when the
flushAllOldApps
script is run.
suspend_server
- Listed when the
suspendServer
script is run.
resume_server
- Listed when the
resumeServer
script is run.
Note that running the
status
script does not update the history log.
Application Logging
Unified CVP VoiceXML Server handles application-level logging through the use of loggers.
Loggers are plugins to the VoiceXML Server that listen for certain logging events and handle
them in a custom manner, from storing the information in log files, sending the information to a
database, or even to interface with a reporting system. The application designer can choose any
number of loggers they wish to listen to events for a particular application, giving each instance a
name. A logger may or may not require a configuration that will allow the designer to customize
how the logger performs. Additionally, certain loggers may have a requirement that the system
pass all logging events for a call to it in the order in which they occurred in the call. The
application designer can choose to do so even for loggers that do not explicitly require it in order
to have logs appear orderly (though there is some performance degradation as a result).
Loggers are plugins to the VoiceXML Server that listen for certain logging events and handle
them in a custom manner, from storing the information in log files, sending the information to a
database, or even to interface with a reporting system. The application designer can choose any
number of loggers they wish to listen to events for a particular application, giving each instance a
name. A logger may or may not require a configuration that will allow the designer to customize
how the logger performs. Additionally, certain loggers may have a requirement that the system
pass all logging events for a call to it in the order in which they occurred in the call. The
application designer can choose to do so even for loggers that do not explicitly require it in order
to have logs appear orderly (though there is some performance degradation as a result).