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:

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 Services Gatekeeper 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 include the 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

State

Indicates where the EDR was dispatched:

  • ENTER_AT: upon entering the AT layer, southbound

  • ENTER_NT: upon entering the NT layer, southbound

  • ENTER_NET: upon entering the network layer, southbound

  • EXIT_AT: upon exiting the AT layer, northbound

  • EXIT_NT: upon exiting the NT layer, northbound

  • EXIT_NET: upon exiting the network layer, northbound

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

AppInstanceId

Current application instance ID. If current traffic is Oauth enabled and the EDR is triggered by AT, the value is "OAuth_User".

TransactionId

Transaction Id. Correlates completed traffic among all three EDR states

Facade

The facade, either "REST" or "SOAP"

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

URL

The URL of the current web service

WebAppName

Name of the current web application

HttpMethod

HTTP request method. For example "POST", or "GET".

RequestContext

Attributes in the request context map. (Name/Value pairs)

InterceptorChain

List of all of the interceptors that are triggered

SubscriberId

Subscriber identifier (using route address)


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. Table A-4 lists information that each CDR in the database contains.

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