Cisco Cisco Customer Voice Portal Downloads 开发者指南
![Cisco](https://files.manualsbrain.com/attachments/7380d0050044647c30f5c24bbbf5d0c0b6d9bb84/common/fit/150/50/faa183d287233c52228cfea3dbc2a127fe780f60564fcb0955d9c3d1cd23/brand_logo.png)
C
HAPTER
13:
L
OGGERS
V
OICE
XML
P
ROGRAMMING
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
66
Chapter 13:
Loggers
The mechanism used by Cisco Unified CVP VoiceXML Server to record information about
activities taken by callers to deployed applications or administrators is by using loggers. Loggers
collect this information and can do any number of tasks with it, from aggregating it for reporting
purposes, to sending that information to external systems for managing, to simply storing the
information in log files. A developer can produce a logger to supplement or replace the
functionality the loggers included with the VoiceXML Server provide. Due to the complexity of
integrating with Unified CVP VoiceXML Server, loggers can be built only by using the Java
API.
activities taken by callers to deployed applications or administrators is by using loggers. Loggers
collect this information and can do any number of tasks with it, from aggregating it for reporting
purposes, to sending that information to external systems for managing, to simply storing the
information in log files. A developer can produce a logger to supplement or replace the
functionality the loggers included with the VoiceXML Server provide. Due to the complexity of
integrating with Unified CVP VoiceXML Server, loggers can be built only by using the Java
API.
This chapter describes in detail how to create custom loggers and integrate them with Unified
CVP VoiceXML Server. For more detail on the loggers included with the VoiceXML Server ,
refer to the VoiceXML Server User Guide for Cisco Unified Customer Voice Portal Chapter 5 in
the section entitled Application Logging.
CVP VoiceXML Server. For more detail on the loggers included with the VoiceXML Server ,
refer to the VoiceXML Server User Guide for Cisco Unified Customer Voice Portal Chapter 5 in
the section entitled Application Logging.
Unified CVP VoiceXML Server Logging Design
Before discussing the design of an individual logger, it is warranted to introduce the design of
the logging mechanism within Unified CVP VoiceXML Server. Knowledge of this design will
help the logger developer create loggers that work harmoniously with the system.
the logging mechanism within Unified CVP VoiceXML Server. Knowledge of this design will
help the logger developer create loggers that work harmoniously with the system.
The mechanism by which information is passed to a logger is through an event object. This
object will encapsulate information about what just occurred, including a timestamp. Event
objects are created by the VoiceXML Server in many different situations that belong to two
levels: related to an application and related to a call session. The event object will contain all the
information accessible to the logger for the particular event as well as information about the
environment. For application-level events such as an administration event, the environment
consists of application data and global data (not call data since this event is not affiliated with a
call). For call-level events such as a call start event, the environment consists of information
about the call such as the ANI, element and session data, default audio path, etc. Since the
purpose of a logger is to report information, loggers are limited to obtaining environment
information and cannot change any value. Loggers may still need to store session-related
information for its purposes so to accommodate this Unified CVP VoiceXML Server provides
loggers “scratch” data that is stored in the session and will be available to the logger only for
those events associated with the session.
object will encapsulate information about what just occurred, including a timestamp. Event
objects are created by the VoiceXML Server in many different situations that belong to two
levels: related to an application and related to a call session. The event object will contain all the
information accessible to the logger for the particular event as well as information about the
environment. For application-level events such as an administration event, the environment
consists of application data and global data (not call data since this event is not affiliated with a
call). For call-level events such as a call start event, the environment consists of information
about the call such as the ANI, element and session data, default audio path, etc. Since the
purpose of a logger is to report information, loggers are limited to obtaining environment
information and cannot change any value. Loggers may still need to store session-related
information for its purposes so to accommodate this Unified CVP VoiceXML Server provides
loggers “scratch” data that is stored in the session and will be available to the logger only for
those events associated with the session.
An application designer can define any number of loggers to use in an application. The designer
defines logger instances with unique names and can pass configurations to them. They can even
define multiple instances of the same logger class with a different configuration for each. Unified
CVP VoiceXML Server will then create a separate instance of the logger class for each instance
referenced in the application’s settings. The instances are created when the individual
applications are initialized and are maintained for the lifetime of the application. All events for
the application, both application-level events as well as call-level events, are handled by this
defines logger instances with unique names and can pass configurations to them. They can even
define multiple instances of the same logger class with a different configuration for each. Unified
CVP VoiceXML Server will then create a separate instance of the logger class for each instance
referenced in the application’s settings. The instances are created when the individual
applications are initialized and are maintained for the lifetime of the application. All events for
the application, both application-level events as well as call-level events, are handled by this