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
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 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:
-
the types of event notifications that are to be sent to the client
-
a set of object properties as criteria for messages sent to the client
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:
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:
-
-
result filter criteria, to refine the information per event body; see Result filters in this section
-
extraTags tag, which specifies the JMS header properties to return; see Using extraTags element to include header properties in this section
-
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:
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.
-
Each StatsEvent message is to include the MTOSI_osTime property.
-
Each message is to include the fullClassName property; however, a StatsEvent message does not have a fullClassName property, so the property is not included in the StatsEvent message body, as shown in Figure 4-12, Event vessel example with extraTags properties .
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:
-
the objectFullName, operationalState, and administrativeState properties of each ObjectCreation event associated with an equipmentPort object
-
the affectedObjectFullName, severity, operatorAssignedUrgency, and additionalText properties of each ObjectCreation event associated with an fm.AlarmObject object
-
the objectFullName property of all other ObjectCreation events
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> |
© 2024 Nokia. Nokia Confidential Information
Use subject to agreed restrictions on disclosure and use.