A Events, Alarms, and Charging

This appendix describes the features common to the handling of events, alarms, and charging in Oracle Communications Services Gatekeeper.

Events

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.

For more information on how this works, see "Designing Manageable Applications" in Oracle Fusion Middleware Developing Manageable Applications With JMX for Oracle WebLogic Server at:

http://download.oracle.com/docs/cd/E15523_01/web.1111/e13729/designapp.htm

and Oracle Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server at:

http://download.oracle.com/docs/cd/E15523_01/web.1111/e13714/toc.htm

Event handling in the Network Tier

In the network tier, much of the functionality comes from the interaction between communication services and the Services Gatekeeper Container Services. To capture this specialized level of information, and other pertinent information about the status of the tier, 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. There are three types of filters that are all found in the wlng-edr.xml file. 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 System Administrator's Guide for more information on setting up these filters.

Each EDR always includes the data in Table A-1.

Table A-1 EDR 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 includethe data in Table A-2.

Table A-2 Event Data

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:[phone]
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 information described in Table A-3.

Table A-3 Alarm Data

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

Services Gatekeeper supports integration of its alarm and event mechanisms with external management tools.

OSS

An Operation Support System (OSS) can integrate with Services Gatekeeper alarm and event services through the creation of external JMS listeners. Integration can be managed by OAM scripts through the use of JMX-based tools.

SNMP

Services Gatekeeper 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 information described in Table A-4.

Table A-4 CDR Data

Element	Represents
transaction_id	The 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 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 destinationParty key. In addition any other information provided by the communication service