JMS message filtering

Overview

A JMS client subscription to an NFM-P topic must include a simple filter that specifies the event messages of interest to the client. A simple JMS message filter is based only on the JMS message header properties and uses SQL syntax. See Simple JMS message filters in this section.

A JMS client that subscribes to the 5620-SAM-topic-xml-filtered topic can define advanced filters based on the JMS message header properties, and the properties of the event object. See  Advanced JMS message filters in this section.

An NFM-P GUI operator can apply alarm filters to active OSS clients. See Assigning OSS alarm filters from the NFM-P client GUI for information.

Note: It is recommended that you create filters that are as restrictive as possible so that only the required events are sent. If the filter is not restrictive enough, additional events must be queued and processed, which may cause the following:

The SOAP header and footer are shown in code examples only when required to provide context.

JMS message header properties

The following table lists and describes the JMS event message header properties that are included in all event messages

Table 4-2: Event header properties, all events

Property

Values

Description

ALA_allomorphic

Allomorphic class

The allomorphic class of the object type, if applicable

ALA_category

ACCOUNTING—accounting statistics

CPAM—events related to CPAM topology management

DATABASE—database state messages

EQUIPMENT—physical equipment events

FAULT—fault management events (alarms)

GENERAL—events that are not in another category

STATISTICS—statistics, except accounting statistics

SERVICE—service-related events

SOFTWARE—not currently used

The event category

ALA_clientId

OSS client ID, or empty

The client ID associated with the event, if applicable

ALA_isVessel

false

true

Whether the message is an event vessel

ALA_OLC

0 (object has no OLC state)

1 (maintenance)

2 (in service)

OLC state. Applies to the creation, attribute changes, and deletion for objects that have an OLC state

ALA_routeManager

Application name of the route manager

Present if the message contains a managed-route change

ALA_span

List of control IDs

The OSS user span of control ID list

ALA_topic

JMS topic name

The JMS topic of the message

ALA_vesselSize

0 to 250

Size, in messages, of the event vessel; present only if ALA_isVessel value is true

eventName

See Table 4-5, Filterable event classes .

The JMS event class name, for example, ObjectDeletionEvent.

MTOSI_NTType

ALA_OTHER

NT_OBJECTDELETION

NT_OBJECTCREATION

NT_ATTRIBUTE_VALUE_CHANGE

NT_STATE_CHANGE

NT_ALARM

NT_HEARTBEAT

ALA_RELATIONSHIPCHANGE

The type of notification

MTOSI_objectName

Object name

The name of the associated object

MTOSI_objectType

KeepAliveEvent

AlarmStatusChangeEvent

DBActivityEvent

DBProxyStateChangeEvent

DBErrorEvent

DBConnectionStateChangeEvent

StateChangeEvent

FileAvailableEvent

DeployerEvent

TerminateClientSession

Any network object names in the form of packageName.ClassName for the following events:

  • AttributeValueChangeEvent

  • ObjectCreationEvent

  • ObjectDeletionEvent

  • RelationshipChangeEvent

  • StatsEvent

The type of associated object

MTOSI_osTime

Time, in ms, since January 1, 1970

The server system time at event creation

Alarm-specific header properties

Most JMS message header properties apply to all events. However, some alarm-related properties, for example, ALA_alarmType, apply only to specific events. The filter shown in the following figure includes all events except equipment alarms; the filter also excludes events that do not include the ALA_alarmType property.

Figure 4-2: Filter example, all events except equipment alarms
ALA_clientId in ('JMS_client@n', '') and ALA_alarmType not in ('equipmentAlarm')

Alarm-specific properties do not apply to all alarm events; when you create a filter on a non-fault topic using alarm-specific properties, you must include the “is null” case. The filter shown in the following figure excludes events with an ALA_alarmType of equipmentAlarm, but includes all other events:

Figure 4-3: Filter example, all events except equipment alarms
ALA_clientId in ('JMS_client@n','') and (ALA_alarmType is null or ALA_alarmType not in ('equipmentAlarm'))

The following table lists properties that are included in some alarm-related events.

Table 4-3: Event header properties, alarm events

Property

Values

Description

ALA_alarmType

Alarm type

The type of alarm

ALA_isCorr

True, if alarm is correlated

Whether the alarm is correlated, that is, caused by another alarm. See “Correlated alarms” in the NSP NFM-P Classic Management User Guide for information about correlated alarms.

MTOSI_aliasNameList

Alarm name

The alarm name

MTOSI_perceivedSeverity

Severity

The alarm severity

MTOSI_probableCause

Probable cause

The probable cause associated with the alarm

MTOSI_serviceAffecting

True if service-affecting

Whether the alarm is service-affecting

The Boolean example shown in the figure below is a filter that suppresses correlated alarms, but also includes events that do not have the ALA_isCorr property. See Troubleshooting using network alarms in the NSP Troubleshooting Guide for information about correlated alarms.

Figure 4-4: Filter example, non-correlated alarms
ALA_clientId in ('JMS_client@n','') and (ALA_isCorr is null or ALA_isCorr = false)
Mandatory events

You must ensure that the following JMS events that a client must monitor are not inadvertently filtered:

The following figure shows a filter example that includes all mandatory events.

Figure 4-5: Filter example, all mandatory events
ALA_clientId in ('JMS_client@n', '')
  AND ( 
   (<filter_for_specific_event_types>)
   OR
   MTOSI_objectType in ('KeepAliveEvent', 'StateChangeEvent', 'TerminateClientSession')
   )
Simple JMS message filters

A simple JMS message filter is defined during subscription to a topic, and is a string of up to 3000 characters that uses the syntax of a WHERE clause in an SQL query. To change a filter, a client must unsubscribe from a topic and then resubscribe to the topic using the new filter. The following figure shows a simple JMS message filter.

Figure 4-6: Simple JMS filter example
ALA_clientId in ('JMS_client@n', '')

The filter includes all of the events in the topic that are intended for the client called ossname@1, and all events in the topic that are intended for all subscribers.

Note: A subscription must filter on the client ID; otherwise, the subscription is rejected.

A simple filter can include any JMS header properties. Some common properties used for filtering include the following:

See Table 4-2, Event header properties, all events for a complete list of header properties, and Table 4-3, Event header properties, alarm events for header properties that are specific to alarm events. Each property is defined in the xmlApiJmsHeader.xsd file in the Schema Reference.

The following table contains simple JMS message filter examples.

Table 4-4: Simple JMS filter samples

JMS filter

Description

ALA_clientId in ('JMS_client@n', '')

To send general messages, and messages qualified with a client ID, directly to the specified client. This filter blocks messages sent to other clients. You must specify this information in all XML topic-based filters.

ALA_clientId in ('JMS_client@n', '') and ALA_category = 'FAULT' and MTOSI_perceivedSeverity = 'Warning'

To filter fault messages with a warning severity class. The filter excludes some mandatory events; see Mandatory events in this section.

ALA_clientId in ('JMS_client@n', '') and ALA_category not in ('STATISTICS', 'ACCOUNTING')

To stop client statistics, accounting, and keep-alive messages

ALA_clientId in ('JMS_client@n', '') and (MTOSI_NTType in ('NT_ATTRIBUTE_VALUE_CHANGE', 'NT_OBJECTDELETION', 'NT_OBJECTCREATION') and MTOSI_objectType in ('equipment.PhysicalPort', 'equipment.DaughterCard', 'equipment.BaseCard'))

To include only object creation, object deletion, and attribute changes for cards and ports. The filter excludes some mandatory events; see Mandatory events in this section.

ALA_clientId in ('JMS_client@n', '') and (MTOSI_NTType in ('NT_OBJECTDELETION', 'NT_OBJECTCREATION') and MTOSI_objectType like 'equipment.%')

To include only object creation and deletion for objects in the equipment package. The filter excludes some mandatory events; see Mandatory events in this section.

Advanced JMS message filters
CAUTION 

CAUTION

Service Disruption

The registerNotification method entry in the General Methods/Types page of the XML API Reference defines the maximum allowed number of leaf elements in a filter.

To avoid degraded system performance, Nokia recommends that you consider the current NFM-P system load, as well as this limit, before you construct a filter with a large number of leaf elements.

A JMS client that subscribes to the 5620-SAM-topic-xml-filtered topic can use advanced filters to additionally reduce the number of JMS event messages. An advanced JMS message filter specifies the following:

Note: If an OSS client registers a filter but does not subscribe to the 5620-SAM-topic-xml-filtered topic within 10m, the filter is deregistered.

If a JMS client unsubscribes from the 5620-SAM-topic-xml-filtered topic, the NFM-P automatically deregisters the associated filter. If a non-durable OSS client connection drops, the filter is deregistered after two minutes; durable client filters are not deregistered.

The following table lists the event classes that support advanced filtering based on the event properties, the properties of the objects associated with the event, or both.

Table 4-5: Filterable event classes

Event

Event properties

Object properties

AlarmStatusChangeEvent

AttributeValueChangeEvent

DeployerEvent

ExceptionEventXMLFormat

FileAvailableEvent

IncrementalRequestEvent

LogFileAvailableEvent

LogRemoteFileAvailableEvent

ObjectCreationEvent

ObjectDeletionEvent

RelationshipChangeEvent

ScriptExecutionEvent

StatsEvent

Event vessels

To further reduce the volume of JMS traffic, most event messages for the 5620-SAM-topic-xml-filtered topic are sent in containers called event vessels. An event vessel is a type of JMS message that contains multiple events and by default, only one JMS header.

Note: Although the JMS headers of individual events are not sent in an event vessel, you can filter the properties of the headers by specifying "class=jmsEvent" in a filter. See Class-based filtering in this section.

You can configure the NFM-P to return only specific attributes of the event bodies in the JMS message by including the resultFilter-Set tag in a registration message. See Result filters in this section.

The following events are sent on the 5620-SAM-topic-xml-filtered topic but are not sent in an event vessel:

  • DBActivityEvent

  • DBConnectionStateChangeEvent

  • DBProxyStateChangeEvent

  • EventVessel

  • KeepAliveEvent

  • StateChangeEvent

  • TerminateClientSessionEvent

  • XMLFilterChangeEvent

Figure 4-7, Event vessel message example is an example of an EventVessel message that contains the following:

Figure 4-7: Event vessel message example
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Header>
      <header xmlns="xmlapi_1.0">
         <eventName>EventVessel</eventName>
         <ALA_category>GENERAL</ALA_category>
         <ALA_vesselSize>4</ALA_vesselSize>
         <ALA_isVessel>true</ALA_isVessel>
         <MTOSI_osTime>1308318280367</MTOSI_osTime>
         <MTOSI_NTType>ALA_OTHER</MTOSI_NTType>
         <ALA_clientId>JMS_client@n</ALA_clientId>
         <ALA_eventName>EventVessel</ALA_eventName>
      </header>
   </SOAP:Header>
   <SOAP:Body>
      <jms xmlns="xmlapi_1.0">
         <eventVessel>
            <attributeValueChangeEvent>
               <fullClassName>fm.AlarmObject</fullClassName>
               <objectFullName>faultManager:network@192.168.183.13|alarm-31-4-24
</objectFullName>
               <attribute>
                  <attributeName>numberOfOccurencesSinceClear</attributeName>
                  <newValue>
                     <long>3</long>
                  </newValue>
                  <oldValue>
                     <long>2</long>
                  </oldValue>
               </attribute>
            </attributeValueChangeEvent>
            <statsEvent>
               <MTOSI_osTime>1311602579077</MTOSI_osTime>
               <state>begin</state>
               <networkElement>192.168.183.13</networkElement>
               <statsType>accounting</statsType>
               <time>1308256029287</time>
            </statsEvent>
            <statsEvent>
               <MTOSI_osTime>1311602582098</MTOSI_osTime>
               <state>end</state>
               <networkElement>192.168.183.13</networkElement>
               <statsType>accounting</statsType>
               <time>1308256029302</time>
            </statsEvent>
            <ExceptionEventXMLFormat>
               <className>aengr.Policy</className>
               <operation>distribute on node 10.168.1.91</operation>
               <objectName>Access Egress:2100</objectName>
               <requestID>JMS_client@n</requestID>
               <errorMessage>[ app: autoconfigChild ] [ class: aengr.Policy ] [ instance: network:10.168.1.91:Access Egress:2100 ] [ descr: invalid action bitmask: 3 : Object deletion is in progress, the object cannot be configured :Parent = network:10.168.1.91:Access Egress:2100: child = queue-1 ]
               </errorMessage>
            </ExceptionEventXMLFormat>
         </eventVessel>
      </jms>
   </SOAP:Body>
</SOAP:Envelope>
Filter elements

An advanced filter can contain leaf and composite filter elements. Leaf elements define an arithmetic or string function and do not have child elements. Composite filters use Boolean expressions to evaluate child elements, which can be leaf or composite elements. An empty filter returns all objects that match the XML request or JMS subscription criteria.

Note: Nokia recommends that you create filters that have a top-down hierarchical structure to make them as restrictive as possible. This means that a filter lists the higher-level object properties before the lower-level properties, as defined in the NFM-P object hierarchy. See the XML API Reference for object hierarchy information.

The following table lists the available leaf filter elements.

Table 4-6: Leaf filter elements

Filter element

Description

Example

equal

Return true if the value is the same as the specified value.

<equal name="localAS" value="20"/>

notEqual

Return true if the value is not the same as the specified value.

<notEqual name="localAS" value="20"/>

greater

Return true if the numeric value is greater than the specified value.

<greater name="localAS" value="20"/>

greaterOrEqual

Return true if the numeric value is greater than or equal to the specified value.

<greaterOrEqual name="localAS" value="20"/>

less

Return true if the numeric value is less than the specified value.

<less name="localAS" value="20"/>

lessOrEqual

Return true if the numeric value is less than or equal to the specified value.

<lessOrEqual name="localAS" value="20"/>

anyBit

Return true if an AND operation on the value bit and the specified value does not return 0. The filter is true if any of the "1" bits in the specified value are enabled in the property value. The function applies only to non-negative numeric types and bitmask types.

<anyBit name="parameter" value="3"/>

allBits

Return true if an AND operation on the value bit and the specified value returns the specified value. The filter is true if all of the "1" bits in the specified value are enabled in the property value. This applies only to non-negative numeric types and bitmask types.

<allBits name="parameter" value="5"/>

wildcard

Compares values using wildcards. The % character specifies 0 or more characters of any type, and the _ character specifies one character of any type.

<wildcard name="SiteId" value="1.%.%.%.%"/>

in

Return true if a numeric or string value equals one of the values in the specified comma-separated list.

<in name="parameter" value="[Edge_14, Aggregation_14, Core_14]"/>

subset

Return true if a string value is a subset of the specified string.

<subset class="service.Site" name="tier" value="123"/>

superset

Return true if a string value contains the specified string.

<superset class="service.Site" name="siteName" value="Core_"/>

notSuperset

Return true if a string value does not contain the specified string.

<notSuperset class="service.Site" name="siteName" value="Edge_"/>

between

Return true if the numeric value is between the first and second specified values.

<between name="preference" first="150" second="200" />

past

Return true if the time value is between (current time) and (current time - specified time interval).

<past time="300000" /> means find all items from the past 5 minutes (300000 ms)

empty

Match everything; this is the same as specifying nothing between the <filter> and </filter> tags.

<empty />

Advanced filter registration

A client specifies a filter using the registerNotification method, which has the following parameters:

Figure 4-8, Registration message example with filter shows a registration message example that contains an advanced filter. The filter elements are leaf filters that are evaluated using the Boolean OR function. The NFM-P sends only JMS events for objects that match one or more of the following criteria:

Figure 4-8: Registration message example with filter
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Header>
      <header xmlns="xmlapi_1.0">
         <security>
            <user>username</user>
            <password>password</password>
         </security>
         <requestID>XML_API_client@n</requestID>
      </header>
   </SOAP:Header>
   <SOAP:Body>
      <registerNotification xmlns="xmlapi_1.0">
         <jmsClientId>JMS_client@n</jmsClientId>
         <filter-Set>
            <filter>
               <between class="service.Service" name="serviceId" first="150" second="200"/>
            </filter>
            <filter>
               <wildcard class="netw.NetworkElement" name="outOfBandAddress" value="192.168.101%"/>
            </filter>
            <filter>
               <equal class="jmsEvent" name="ALA_category" value="FAULT"/>
            </filter>
         </filter-Set>
      </registerNotification>
   </SOAP:Body>
</SOAP:Envelope>

The registrationNotification response contains the complete filter definition, which includes the filter defined in the request and any other filter applied using the GUI.

Note: To obtain all attributes of a particular class or abstract class, the following example using the service.AccessInterface abstract class shows how to define the filter:

<filter-Set>
    <filter class="service.AccessInterface">
        <and>
            <notEqual name="eventName" value="" class="jmsEvent"/>
        </and>
    </filter>
</filter-Set>
Advanced filter deregistration

To deregister a filter, a JMS client uses the deregisterNotification method, which requires only the JMS client ID. The following figure shows a deregistration message example.

Figure 4-9: Deregistration message example
<SOAP:Body>
   <deregisterNotification xmlns="xmlapi_1.0">
      <jmsClientId>JMS_client@n</jmsClientId>
   </deregisterNotification>
 </SOAP:Body>

The NFM-P returns an XMLFilterChangeEvent with an empty filter-Set element in response to a deregisterNotification message, as shown in the following figure.

Figure 4-10: XMLFilterChangeEvent message example
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Header>
      <header xmlns="xmlapi_1.0">
         <eventName>XMLFilterChangeEvent</eventName>
         <ALA_category>GENERAL</ALA_category>
         <ALA_OLC>0</ALA_OLC>
         <ALA_isVessel>false</ALA_isVessel>
         <ALA_allomorphic/>
         <MTOSI_osTime>1308255929252</MTOSI_osTime>
         <MTOSI_NTType>ALA_OTHER</MTOSI_NTType>
         <MTOSI_objectName/>
         <ALA_clientId>JMS_client@n</ALA_clientId>
         <MTOSI_objectType>XMLFilterChangeEvent</MTOSI_objectType>
         <ALA_eventName>XMLFilterChangeEvent</ALA_eventName>
      </header>
   </SOAP:Header>
   <SOAP:Body>
      <jms xmlns="xmlapi_1.0">
         <xmlFilterChangeEvent>
            <filter-Set />
         </xmlFilterChangeEvent>
      </jms>
   </SOAP:Body>
</SOAP:Envelope>
Class-based filtering

A class= tag in a filter element specifies the object type to evaluate. You can specify the jmsEvent class to indicate that the filter element is for the event. If a class value is not specified or if the class value is jmsEvent, class-based filtering is not performed. See Chapter 13, Inventory management for information about working with classes.

When you specify jmsEvent as the class value, you can filter on the following JMS header properties:

  • ALA_alarmType

  • ALA_allomorphic

  • ALA_application

  • ALA_category

  • ALA_eventName

  • ALA_isCorr

  • ALA_OLC

  • ALA_routeManager

  • ALA_span

  • eventName

  • fullClassName

  • MTOSI_aliasNameList

  • MTOSI_NTType

  • MTOSI_objectName

  • MTOSI_objectType

  • MTOSI_osTime

  • MTOSI_perceivedSeverity

  • MTOSI_probableCause

  • MTOSI_serviceAffecting

Note: The OSS client user span of control defines the objects that are sent to the client. Using ALA_span in a filter is not required unless you want to restrict the returned objects to a subset of the objects within the span of control, or to a specific span such as the Edit span.

When you specify jmsEvent as the class, you can also filter on event detail properties. The following table lists the jmsEvent detail properties that are filterable.

Table 4-7: Filterable jmsEvent class detail properties

Event detail

Properties

DeployerEvent

successList

failedList

ExceptionEvent

objectName

operation

taskName

errorMessage

FileAvailableEvent

fileName

IncrementalRequestEvent

incrementalAction

serviceType

LogFileAvailableEvent

serverIpAddress

neId

LogRemoteFileAvailableEvent

serverIpAddress

neId

fileName

RelationshipChangeEvent

changeType

fromObjectName

fromObjectClass

toObjectName

toObjectClass

ScriptExecutionEvent

targetScriptResultFullName

fileName

failedCommands

systemInvokationId

StatsEvent

networkElement

statsType

Using extraTags element to include header properties

By default, JMS event vessel messages do not include the JMS header properties of the contained events. In order to return event header properties, you must specify the properties in an extraTags element during filter registration. The header properties are then included in the body of each associated event that has the header property.

The properties are specified using the following syntax:

<tag name="JMS_header_property" eventName="JMS_event_class" />

where

JMS_header_property is a JMS header property described in Class-based filtering in this section

JMS_event_class is one of the event classes listed in Table 4-5, Filterable event classes

If a JMS event does not have a specified header property, the property is excluded from the event body. If an eventName value is omitted, the specified JMS header property is returned for each event that has the property.

Figure 4-11, Filter registration example with extraTags element is an example of a filter registration message with an extraTags element that specifies the following.

Figure 4-11: Filter registration example with extraTags element
<SOAP:Body>
   <registerNotification xmlns="xmlapi_1.0">
      <jmsClientId>JMS_client@n</jmsClientId>
      <filter-Set>
         <filter>
            <or>
               <equal class="jmsEvent" name="networkElement" value="192.168.101.145" /> 
               <equal class="jmsEvent" name="MTOSI_objectType" value="StatsEvent" /> 
            </or>
         </filter>
      </filter-Set>
      <extraTags>
         <tag name="MTOSI_osTime" eventName="StatsEvent" />
         <tag name="fullClassName" />
      </extraTags>
   </registerNotification>
</SOAP:Body>
Figure 4-12: Event vessel example with extraTags properties
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Header>
      <header xmlns="xmlapi_1.0">
         <eventName>EventVessel</eventName>
         <ALA_category>GENERAL</ALA_category>
         <ALA_vesselSize>3</ALA_vesselSize>
         <ALA_isVessel>true</ALA_isVessel>
         <MTOSI_osTime>1308318280367</MTOSI_osTime>
         <MTOSI_NTType>ALA_OTHER</MTOSI_NTType>
         <ALA_clientId>JMS_client@n</ALA_clientId>
         <ALA_eventName>EventVessel</ALA_eventName>
      </header>
   </SOAP:Header>
   <SOAP:Body>
      <jms xmlns="xmlapi_1.0">
         <eventVessel>
            <attributeValueChangeEvent>
               <fullClassName>fm.AlarmObject</fullClassName>
               <objectFullName>faultManager:network@192.168.101.145|alarm-31-4-24</objectFullName>
               <attribute>
                  <attributeName>numberOfOccurencesSinceClear</attributeName>
                  <newValue>
                     <long>3</long>
                  </newValue>
                  <oldValue>
                     <long>2</long>
                  </oldValue>
               </attribute>
               <attribute>
                  <attributeName>lastTimeDetected</attributeName>
                  <newValue>
                     <long>1308318277307</long>
                  </newValue>
                  <oldValue>
                     <long>1308318115170</long>
                  </oldValue>
               </attribute>
               <attribute>
                  <attributeName>numberOfOccurences</attributeName>
                  <newValue>
                     <long>3</long>
                  </newValue>
                  <oldValue>
                     <long>2</long>
                  </oldValue>
               </attribute>
            </attributeValueChangeEvent>
            <statsEvent>
               <MTOSI_osTime>1311602579077</MTOSI_osTime>
               <state>begin</state>
               <networkElement>192.168.183.13</networkElement>
               <statsType>accounting</statsType>
               <time>1308256029287</time>
            </statsEvent>
            <statsEvent>
               <MTOSI_osTime>1311602582098</MTOSI_osTime>
               <state>end</state>
               <networkElement>192.168.183.13</networkElement>
               <statsType>accounting</statsType>
               <time>1308256029302</time>
            </statsEvent>
         </eventVessel>
      </jms>
   </SOAP:Body>
</SOAP:Envelope>
Result filters

Figure 4-13, registerNotification message example with result filter shows a registerNotification example using a result filter. The result filter specifies that only ObjectCreation events are sent to JMS_CLIENT@4. The resultFilter elements define the following filter criteria:

Figure 4-13: registerNotification message example with result filter
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Header>
      <header xmlns="xmlapi_1.0">
         <security>
            <user>username</user>
            <password>password</password>
         </security>
         <requestID>XML_API_client@n</requestID>
      </header>
   </SOAP:Header>
   <SOAP:Body>
      <registerNotification xmlns="xmlapi_1.0">
         <jmsClientId>JMS_client@n</jmsClientId>
         <filter-Set>
            <filter>
               <equal class="jmsEvent" name="ALA_eventName" value="ObjectCreation" />
            </filter>
         </filter-Set>
         <resultFilter-Set>
            <resultFilter>
               <attribute>objectFullName</attribute>
            </resultFilter>
            <resultFilter class="equipment.Port">
               <attribute>objectFullName</attribute>
               <attribute>operationalState</attribute>
               <attribute>administrativeState</attribute>
            </resultFilter>
            <resultFilter class="fm.AlarmObject">
               <attribute>operatorAssignedUrgency</attribute>
               <attribute>additionalText</attribute>
               <attribute>severity</attribute>
               <attribute>affectedObjectFullName</attribute>
            </resultFilter>
         </resultFilter-Set>
      </registerNotification>
   </SOAP:Body>
</SOAP:Envelope>

After a successful registration, the XMLFilterChangeEvent message shown in the following figure is sent to the JMS client.

Figure 4-14: XMLFilterChangeEvent message example
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Header>
      <header xmlns="xmlapi_1.0">
         <eventName>XMLFilterChangeEvent</eventName>
         <ALA_category>GENERAL</ALA_category>
         <ALA_OLC>0</ALA_OLC>
         <ALA_isVessel>false</ALA_isVessel>
         <ALA_allomorphic/>
         <MTOSI_osTime>1335291140845</MTOSI_osTime>
         <MTOSI_NTType>ALA_OTHER</MTOSI_NTType>
         <MTOSI_objectName/>
         <ALA_clientId>JMS_client@n</ALA_clientId>
         <MTOSI_objectType>XMLFilterChangeEvent</MTOSI_objectType>
         <ALA_eventName>XMLFilterChangeEvent</ALA_eventName>
      </header>
   </SOAP:Header>
   <SOAP:Body>
      <jms xmlns="xmlapi_1.0">
         <xmlFilterChangeEvent>
            <filter-Set>
               <filter>
                  <equal name="ALA_eventName" value="ObjectCreation" class="jmsEvent"/>
               </filter>
            </filter-Set>
            <resultFilter-Set>
               <resultFilter>
                  <attribute>objectFullName</attribute>
               </resultFilter>
               <resultFilter class="equipment.Port">
                  <attribute>administrativeState</attribute>
                  <attribute>operationalState</attribute>
                  <attribute>objectFullName</attribute>
               </resultFilter>
               <resultFilter class="fm.AlarmObject">
                  <attribute>operatorAssignedUrgency</attribute>
                  <attribute>additionalText</attribute>
                  <attribute>severity</attribute>
                  <attribute>affectedObjectFullName</attribute>
               </resultFilter>
            </resultFilter-Set>
         </xmlFilterChangeEvent>
      </jms>
   </SOAP:Body>
</SOAP:Envelope>

The following three figures show ObjectCreationEvent event vessel message examples based on the result filters specified in the previous figure.

Figure 4-15: Event vessel example, physical port
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Header>
      <header xmlns="xmlapi_1.0">
         <eventName>EventVessel</eventName>
         <ALA_category>GENERAL</ALA_category>
         <ALA_vesselSize>50</ALA_vesselSize>
         <ALA_isVessel>true</ALA_isVessel>
         <MTOSI_osTime>1334951029044</MTOSI_osTime>
         <MTOSI_NTType>ALA_OTHER</MTOSI_NTType>
         <ALA_clientId>JMS_client@n</ALA_clientId>
         <ALA_eventName>EventVessel</ALA_eventName>
      </header>
   </SOAP:Header>
   <SOAP:Body>
      <jms xmlns="xmlapi_1.0">
         <eventVessel>
            <objectCreationEvent>
               <equipment.PhysicalPort>
                  <operationalState>portInService</operationalState>
                  <administrativeState>portInService</administrativeState>
                  <objectFullName>network:198.51.100.24:shelf-1:cardSlot-1:card:
daughterCardSlot-1:daughterCard:port-1</objectFullName>
               </equipment.PhysicalPort>
            </objectCreationEvent>
            <objectCreationEvent>
               <equipment.PhysicalPort>
                  <operationalState>portInService</operationalState>
                  <administrativeState>portInService</administrativeState>
                  <objectFullName>network:198.51.100.24:shelf-1:cardSlot-1:card:
daughterCardSlot-1:daughterCard:port-2</objectFullName>                  
               </equipment.PhysicalPort>
            </objectCreationEvent>
            <objectCreationEvent>
               <equipment.PhysicalPort>
                  <operationalState>portInService</operationalState>
                  <administrativeState>portInService</administrativeState>
                  <objectFullName>network:198.51.100.24:shelf-1:cardSlot-1:card:
daughterCardSlot-1:daughterCard:port-3</objectFullName>
               </equipment.PhysicalPort>
            </objectCreationEvent>
         </eventVessel>
      </jms>
   </SOAP:Body>
</SOAP:Envelope>
Figure 4-16: Event vessel example, alarm
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Header>
      <header xmlns="xmlapi_1.0">
         <eventName>EventVessel</eventName>
         <ALA_category>GENERAL</ALA_category>
         <ALA_vesselSize>1</ALA_vesselSize>
         <ALA_isVessel>true</ALA_isVessel>
         <MTOSI_osTime>1335291256665</MTOSI_osTime>
         <MTOSI_NTType>ALA_OTHER</MTOSI_NTType>
         <ALA_clientId>JMS_client@n</ALA_clientId>
         <ALA_eventName>EventVessel</ALA_eventName>
      </header>
   </SOAP:Header>
   <SOAP:Body>
      <jms xmlns="xmlapi_1.0">
         <eventVessel>
            <objectCreationEvent>
               <fm.AlarmInfo>
                  <severity>critical</severity>
                  <affectedObjectFullName>network:198.51.100.24</affectedObjectFullName>
                  <additionalText>N/A</additionalText>
                  <operatorAssignedUrgency>indeterminate</operatorAssignedUrgency>
               </fm.AlarmInfo>
            </objectCreationEvent>
         </eventVessel>
      </jms>
   </SOAP:Body>
</SOAP:Envelope>
Figure 4-17: Event vessel example returning only objectFullName
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Header>
      <header xmlns="xmlapi_1.0">
         <eventName>EventVessel</eventName>
         <ALA_category>GENERAL</ALA_category>
         <ALA_vesselSize>1</ALA_vesselSize>
         <ALA_isVessel>true</ALA_isVessel>
         <MTOSI_osTime>1335291361323</MTOSI_osTime>
         <MTOSI_NTType>ALA_OTHER</MTOSI_NTType>
         <ALA_clientId>JMS_client@n</ALA_clientId>
         <ALA_eventName>EventVessel</ALA_eventName>
      </header>
   </SOAP:Header>
   <SOAP:Body>
      <jms xmlns="xmlapi_1.0">
         <eventVessel>
            <objectCreationEvent>
               <rtr.VirtualRouterIpAddress>
                  <objectFullName>network:198.51.100.24:router-1:ip-interface-2:TP-1</objectFullName>
               </rtr.VirtualRouterIpAddress>
            </objectCreationEvent>
         </eventVessel>
      </jms>
   </SOAP:Body>
</SOAP:Envelope>