Events are handled differently in the Access Tier and the Network Tier.
Event handling in the Access Tier
The Access Tier runs in the WebLogic Server’s Web Services Container, so events or alarms that are raised there can be monitored through standard JMX mechanisms or by using the WebLogic Diagnostics Framework.
In the Network Tier, much of the functionality comes from the interaction between communication services and Oracle Communications Services Gatekeeper’s Container Services. To capture this specialized level of information, and other pertinent information about the status of the tier, Oracle Communications Services Gatekeeper has developed specific mechanisms to record the data.
In standard communication services, all status information generated by the Network Tier - events, alarms, charging data, and usage statistics - begins as an event, which is fired whenever designated methods are called or exceptions are thrown. These events are then sent to the EDR Service. In the EDR Service, events are processed through XML-based filters, which provide the criteria by which the events are classified into types. The filters can also be used to transform the data in the original event, including adding other useful information. When the information has been processed by the filters, it is delivered to type-specific listeners. Out of the box, there are three types of filters that are all found in the file wlng-edr.xml. They produce three distinct types of data: Event Data Records (EDRs), Charging Data Records (CDRs), and Alarms. All three of these filters can be customized as desired, using the Administrative Console. These filters can also deliver desired event-based information to external JMS-based listeners. Such listeners are set up as standard JMS topic subscribers and can be anywhere on the network. See
Orac
le Communications Services Gatekeeper - System Administrator’s Guide for more information on setting up these filters.
Note:
For the purposes of backwards compatibility, events, alarms, and charging records can be published and delivered to 2.2 style, as well as standard style, listeners, but this mechanism has been deprecated since version 3.0.
Each EDR always includes the following data:
Element
Represents
ServiceName
The service type (SMS, Call Handling, etc.) that produced the event
ServerName
The name of the WLS host
Timestamp
The time at which the event was triggered (in milliseconds from midnight 1 January 1970)
ContainerTransactionID
The transaction ID from WebLogic Server, if available. This identifies the thread on which the request is executed
Class
The name of the class that logged the event
Method
The name of the method that logged the event
Source
The kind of event. There are two possible values for this field:
Method: the event was fired in relation to a method call
Exception: the event was fired in relation to an exception being thrown
In addition, most events include:
Element
Represents
Direction
The direction in which the request is traveling. There are two possible values for this field:
South: traveling toward the network node
North: traveling toward the application
Position
The position of the EDR relative to the method that logged the EDR. There are two possible values for this field:
Before: the event occurred before the method
After: the event occurred after the method
Interface
The interface at which the EDR is logged. There are three possible values for this field:
North: the event was logged at the north plug-in interface
South: the event was logged at the south plug-in interface
Other: the event was logged someplace other than the north or south interfaces
Exception
The name of the exception that triggered the EDR
SessionId
The application’s session identifier
ServiceProviderId
The service provider account identifier
ApplicationId
The application account identifier
AppInstanceGroupId
The authentication user name of the Application Account. This is a string that is equivalent to the 2.2 value: Application Instance Group ID
OrigAddress
The originating address with scheme. For example: tel:12123334444
DestAddress
The destination address. If this is a send list, the first address will be listed here. Additional addresses are stored in the AdditionalInfo field.
AdditionalInfo
Variable information depending on the communication service. Stored as “key=value\n” pairs.
PluginID
The unique ID of the plug-in instance.
Alarms
Network Tier alarms are those events that are of immediate interest to the operator. They are EDRs that are defined via filters created in the internal configuration file. While each alarm begins as an EDR, not all the information available in the EDR is stored when the alarm is written to the database (although that information can be retrieved using an external listener). Each alarm entry in the database includes the following information:
Element
Represents
alarm_id
A unique sequential identifier
source
The name of the software module that raised the alarm and the IP address of the server in which the module runs. This is not the same as the Source field in the event
timestamp
The time at which the event was triggered (in milliseconds from midnight 1 January 1970)
severity
The importance of the alarm. There are four possible values for this field:
4 for warning
3 for minor
2 for major
1 for critical
identifier
The alarm type
alarm_info
Information provided by the module that raised the alarm
additional_info
This field includes:
Service Provider ID
Application ID
Application Instance ID
Plug-in instance ID
Other information depending on context
Management integration
Oracle Communications Services Gatekeeper supports integration of its alarm and event mechanisms with external management tools.
OSS
An Operation Support System (OSS) can integrate with Oracle Communications Services Gatekeeper alarm and event services through the creation of external JMS listeners. As well, integration can be managed by OAM scripts through the use of JMX-based tools.
SNMP
Oracle Communications Services Gatekeeper also supports the sending of alarms as SNMP traps to SNMP managers. The alarms sent to the SNMP managers can be filtered on alarm severity.
Charging Data Records
CDRs originate as filtered EDRs. While each CDR begins as an EDR, not all the information available in the EDR is stored when the CDR is written to the database (although that information can be retrieved using an external listener). Each CDR entry in the database includes the following information:
Element
Represents
transaction_id
The Oracle Communications Services Gatekeeper transaction sequence number
service_name
The communication service whose use is being tracked
service_provider
The Service Provider ID
application_id
The Application ID
application_instance_id
The user name of the Application Account. This is a string that is equivalent to the 2.2 value: Application Instance Group ID
container_transaction_id
The transaction ID from WebLogic Server, if available. This identifies the thread on which the request is executed
server_name
The name of the server in which the CDR was generated
timestamp
The time at which the event was triggered (in milliseconds from midnight 1 January 1970)
service_correlation_ID
An identifier that allows the usage of multiple service types to be correlated into a single charging unit
charging_session_id
An ID correlating related transactions within a service capability module that belong to one charging session. For example, a call containing three call legs will produce three separate transactions within the same session
Note:
In installations where sessions are not used, this field contains only a placeholder value.
start_of_usage
The date and time the request began to use the services of the underlying network
connect_time
The date and time the destination party responded. Used for Call Control traffic only
end_of_usage
The date and time the request stopped using the services of the underlying network
duration_of_usage
The total time the request used the services of the underlying network
amount_of_usage
The used amount. Used when charging is not time dependent, as in, for example, flat rate services
originating_party
The originating party’s address
destination_party
The destination party's address. This is the first address in the case of send lists, with all additional addresses placed in the additional_info field.
charging_info
A service code added by the application or by policy service
additional_info
If the communication service supports send lists, all destination addresses other than the first, under the key destinationParty. In addition any other information provided by the communication service
