Table Of Contents
Alcatel ASAM - Physical Object
Specifying the Retrieved IMO Types
Excluding IMO Types and Properties
Format/Syntax Retrieval Specification
Specifying Properties vs. Aspects
Required Aspects vs. Excluded Aspects
Registrations and Notifications
IMO Specification
IMO Format/Syntax
The general XML format of an IMO object is as follows:
IMO OIDs
An IMO OID (Object Identifier) is the unique identifier of every IMO instance in the system. The OID uniquely identifies every IMO object, by providing a cascaded structure that describes the location of the entity. For example, the OID of a specific port in a typical NE will be formatted by cascading the NE IP address, Shelf number, Module number and Port number.
Different device types may have different OID schemas. For example, a port OID in some NE may also include submodules, subslots, and so on.
Format/Syntax
OID Example
The OID of Port 3 on module 1, subslot C of the NE "London5" will be:
{[ManagedElement(Key=London5)][PhysicalRoot][Chassis] [Slot(SlotNum=1)][Module][Slot(SlotNum=C)][Module] [Port(PortNumber=3)]}The hierarchy of this OID is illustrated below.
Figure 3-1 OID Hierarchy
Sample OID Hierarchies
As described above, each NE type may have its own IMO schema, that is different object types and a tree hierarchy. In order to be able to specify the correct OID for each NE, the client application has to be familiar with the OID hierarchy of the relevant NE. Following are some examples of IMO hierarchies.
Alcatel ASAM - Physical Object
The OID of a port of an Alcatel ASAM is encoded as
{[ManagedElement(Key=ASAMLab)][PhysicalRoot][Chassis] [Shelf(ShelfNum=1)][Slot(SlotNum=NTA)][Module] [Port(PortNumber=1)]}The physical hierarchy represented by this OID is illustrated below.
Figure 3-2 Alcatel ASAM Port OID
Lucent CBX - Physical Object
The OID of a port of a Lucent CBX is encoded as
{[ManagedElement(Key=CBX500Lab)][PhysicalRoot][Chassis] [Slot(SlotNum=12)][Module][Port(PortNumber=6)]}The physical hierarchy represented by this OID is illustrated below.
Figure 3-3 Lucent CBX Port OID
Redback SMS - Physical Object
The OID of a port of a Redback SMS is encoded as:
{[ManagedElement(Key=RB1)][PhysicalRoot][Chassis] [Slot(SlotNum=7)][Module][Port(PortNumber=1)]}The physical hierarchy represented by this OID is illustrated below.
Figure 3-4 RedBack SMS Port OID
Redback SMS - Logical Object
The OID of a logical object (IP interface) of a RedBack SMS is encoded as:
{[ManagedElement(Key=RB1)][LogicalRoot] [Context(ContextName=cyberworks.net.sg)][RoutingEntity] [IpInterface(IPAddress=10.254.253.37)]}The logical hierarchy represented by this OID is illustrated below:
Figure 3-5 RedBack SMS Logical OID
IMO Primitives
When encoding an IMO object, each of its properties may be either a primitive (that is, basic type) or another IMO. The simplest case is when all the properties of the IMO are primitives, as in the following example:
<IManagedElement><ID type="Oid">{[ManagedElement(Key=CBX500Lab)]}</ID><CommunicationStateEnum type="Integer">3</CommunicationStateEnum><DeviceName type="String">CBX500Lab</DeviceName><ElementCategoryEnum type="Integer">2</ElementCategoryEnum><ElementTypeEnum type="Integer">22</ElementTypeEnum><IP type="com.sheer.types.IPAddress">192.168.2.70</IP><InvestigationStateEnum type="Integer">2</InvestigationStateEnum><SoftwareVersion type="String">04.02.01.00</SoftwareVersion><VendorEnum type="Integer">6</VendorEnum></IManagedElement>The following table describes the primitive types that can be used for IMO object properties:
IMO Constructs
IMO constructs support recursive nesting of IMO objects as well as arrays of IMO objects. First, we will describe how to how to nest an IMO object within another IMO object. We will then describe how to aggregate several IMO objects into an IMO objects array, and finally, we will describe how to combine both to create complex IMO constructs.
Nesting IMO Objects
Each of the properties of an IMO object can be an IMO object by itself. In this case, the type of the property is one of the existing IMO types. For example:
<technologies.IAtm><Bandwidth type="technologies.IAtmBandwidthTrafficDescriptor"><TxMaxBandwidth type="com.sheer.types.Speed">0.0 bps </TxMaxBandwidth><TxUbrAllocBandwidth type="com.sheer.types.Speed">13.86 Mbps </TxUbrAllocBandwidth></Bandwidth></technologies.IAtm>In this example, the IMO object of type technologies.IAtm contains a property called Bandwidth, which is an IMO object of the type technologies.IAtmBandwidthTrafficDescriptor.
Following is another example, which combines both primitives and nested IMOs:
<technologies.IAtm><Bandwidth type="technologies.IAtmBandwidthTrafficDescriptor"><TxMaxBandwidth type="com.sheer.types.Speed">0.0 bps </TxMaxBandwidth><TxUbrAllocBandwidth type="com.sheer.types.Speed">13.86 Mbps </TxUbrAllocBandwidth></Bandwidth><VcsTableSize type="Integer">50</VcsTableSize><VpVcRange type="String">[VP: 0..4096, VC: 0..65536]</VpVcRange></technologies.IAtm>IMO Object Arrays
The general format of the encoding of an IMO array is:
<IMObjects_Array>IMO1IMO2...</IMObjects_Array>Following is an example of an IMO construct, which includes an array of two IMO objects of the type IManagedElement:
<IMObjects_Array><IManagedElement><ID type="Oid">{[ManagedElement(Key=CBX500Lab)]}</ID><DeviceName type="String">CBX500Lab</DeviceName><CommunicationStateEnum type="Integer">3 </CommunicationStateEnum></IManagedElement><IManagedElement><ID type="Oid">{[ManagedElement(Key=CBX_Iftach)]}</ID><CommunicationStateEnum type="Integer">3 </CommunicationStateEnum><DeviceName type="String">CBX_Iftach</DeviceName></IManagedElement></IMObjects_Array>Complex Constructs
In the next example, we combine the properties of type IMO with IMO arrays to create a nested construct of IMO objects:
<IVrf><ID type="Oid">{[ManagedElement(Key=DallsPE)][LogicalRoot] [FWComponentContainer(Type=3)][Vrf(VrfName=ACME)]}</ID><Name type="String">ACME</Name><RouteDistinguisher type="IRouteDistinguisher"><ID type="Oid">{[ManagedElement(Key=DallsPE)][LogicalRoot] [FWComponentContainer(Type=3)][Vrf(VrfName=ACME)] [RouteDistinguisher]}</ID><RouteDistinguisher type="String">3603:1</RouteDistinguisher></RouteDistinguisher><VrfTable type="IMObjects_Array"><technologies.IVrf><ID type="Oid">{[ManagedElement(Key=DallsPE)][LogicalRoot] [FWComponentContainer(Type=3)][Vrf(VrfName=ACME)] [VrfEntry(IP=172.16.101.0)]}</ID><BGPNextHop type="">Null</BGPNextHop><InnerLabel type="">Null</InnerLabel><NextHop type="IPAdderss">172.16.101.254</NextHop><RouteDest type="IPAdderss">172.16.101.0</RouteDest><RouteMask type="IPAdderss">255.255.255.0</RouteMask><RouteProtocolTypeEnum type="Integer">14 </RouteProtocolTypeEnum><TypeEnum type="Integer">3</TypeEnum></technologies.IVrf><technologies.IVrf><ID type="Oid">{[ManagedElement(Key=DallsPE)][LogicalRoot] [FWComponentContainer(Type=3)][Vrf(VrfName=ACME)] [VrfEntry(IP=192.168.107.207)]}</ID><BGPNextHop type="">Null</BGPNextHop><InnerLabel type="">Null</InnerLabel><NextHop type="">Null</NextHop><RouteDest type="IPAdderss">192.168.107.207</RouteDest><RouteMask type="IPAdderss">255.255.255.255</RouteMask><RouteProtocolTypeEnum type="Integer">14 </RouteProtocolTypeEnum><TypeEnum type="Integer">3</TypeEnum></technologies.IVrf></VrfTable></Vrf>Retrieval Specifications
The Retrieval Specification (RS) defines the scope of information to be retrieved by a GET or FIND command. It describes the IMO objects that will be returned as well as the properties that will be returned in each IMO object. The retrieval specification allows us to specify the inclusion or exclusion of every element in the result.
The RS also allows registering for change notifications to be sent whenever a property changes within the specified data scope. Registration for changes enables, for example, receiving notifications on port or module status change, or any changes in the configuration of the network.
The retrieval specification has another section that refers to Aspects. For more information, see Aspects.
Defining the Retrieval Scope
The retrieval specification is a XML string that represents the scope and structure of the result of a GET query. It defines what IMO objects should be included in the answer and what properties should be included for each IMO object type. Consider, for example, the following simple retrieval spec:
<param name="oid"><value>{[ManagedElement(Key=DallasPE)]}</value></param><param name="rs"><value><key name="RS1"><key name="requiredProperties"><key name="com.sheer.imo.IManagedElement"><entry name="*"/></key></key></key></value></param>The above retrieval spec defines that:
•
The answer will contain only objects of type IManagedElement
•
The name of the retrieval spec (RS1) is an optional string identifier that is used only for readability of the XML and ignored when the query is processed.
The following example demonstrates the general format of retrieval specification. It lists the IMO types and the properties within each IMO type that will be included in the reply:
<param name="rs"><value><key name="RS_name"><key name="requiredProperties"><key name=IMO_TYPE_A><entry name=PROPERTY_1/><entry name=PROPERTY_2/>...</key><key name=IMO_TYPE_B><entry name=PROPERTY_1/><entry name=PROPERTY_2/>...</key></key></key></value></param>To include all IMO types in the result use "*" as the IMO type. Similarly, to include all properties of a given IMO type use "*" as the property name:
<param name="rs"><value><key name="RS1"><key name="requiredProperties"><key name="* "><entry name="*"/></key></key></key></value></param>In this example, we specified the "*" wildcard twice. First to indicate that we are interested in all IMO types, and then to indicate that we want all properties in the objects. If we were specifying only the IMO type wildcard, then we would have received empty IMO objects with no properties.
Specifying the Retrieved IMO Types
BQL determines what IMO types to retrieve, by recursively traversing the containment (nesting) references between the IMO objects in the ANA information model, starting from the root object OID (specified as part of the GET command). During the recursive traverse, each object that is found is tested against the IMO types in the RS, and is retrieved only if it matches any of these types. Consider again the example:
<param name="rs"><value><key name="RS_name"><key name="requiredProperties"><key name=IMO_TYPE_A><entry name=PROPERTY_1/><entry name=PROPERTY_2/>...</key></key><key name=IMO_TYPE_B><entry name=PROPERTY_1/><entry name=PROPERTY_2/></key></key></value></param>Assume that IMO_TYPE_A contains IMO_TYPE_C as one of its properties. Since we requested in the answer all properties of IMO_TYPE_A, then, IMO_TYPE_C will appear in the result (since it is a property of IMO_TYPE_A). However, it will appear empty (that is, without properties, except for its OID), since IMO_TYPE_C is not included in the retrieval spec.
To demonstrate this, look at the following RS example:
<param name="oid"><value>{[ManagedElement(Key=DallasPE)]}</value></param><param name="rs"><value><key name="RS1"><key name="requiredProperties"><key name="com.sheer.imo.IManagedElement"><entry name="*"/></key></key></key></value></param>In this example, the RS specifies the inclusion of the IMO type IManagedElement, with all its properties. Since the root object (the NE) is of type IManagedElement, the NE object is returned with all its properties. However, some of the NE properties are by themselves IMO objects,for example, PhysicalRoot and LogicalRoot (of the IMO types IPhysicalRoot and ILogicalRoot, respectively). Since the RS does not specify these IMO types in the "includedProperties" section, they will appear empty (that is, appear as properties of the IManagedElement object, with their OID only).
However, had we included IPhysicalRoot or ILogicalRoot in the required IMO types, BQL would have traversed these objects as well, retrieve their properties (and then continue to test their contained objects against the included IMO types, and so on recursively).
The above examples demonstrate the recursive nature of the retrieval spec. BQL browses through all the nested IMO objects in the ANA information model, and tests them against the specified IMO types in the RS.
An important factor of the recursive nature of the retrieval spec is to have a stopping criterion for information retrieval. When retrieving an IMO object, the system recursively traverses all properties of the retrieved IMO, and for each property, which is a nested IMO object it continues to traverse it. Hence, the included IMO types in the RS should be designed in a way that controls the depth of the returned data.
IMO Type Inheritance
IMO objects are defined through an inheritance scheme. For example, CTP objects, such as IAtm, IAdsl for example. are all derived from (children of) a common base type, IConnectionTerminationPoint. It is enough to specify a base type in the RS to have all the derived types implicitly included.
Consider the following example. Assume we have two IMO types (IMO_TYPE_A and IMO_TYPE _B), where IMO_TYPE_B inherits from (is the child of) IMO_TYPE _A. Now assume we execute a GET command in which the root object is of type IMO_TYPE_B, with the following retrieval spec:
<param name="oid"><value>{Some-object-of-type-B)]}</value></param><param name="rs"><value><key name="RS3"><key name="requiredProperties"><key name=IMO_TYPE_A><entry name=PROPERTY_1/><entry name=PROPERTY_2/></key></key></key></value></param>When processing the properties of the root object, the system inspects the retrieval spec and detects that its IMO type (IMO_TYPE_B) is not included. However, it detects that its ancestor (IMO_TYPE_A) is included in the retrieval spec, and the object is qualified for retrieval (with the properties PROPERTY_1 and PROPERTY_2). In other words, to specify the retrieval spec of an object it is sufficient to specify the retrieval spec for any of its ancestors.
On the other hand, if we specify IMO_TYPE_B, it will override any specification of its ancestors (in this case, IMO_TYPE_A). For example, if we modify the RS as follows:
<param name="oid"><value>{Some-object-of-type-B)]}</value></param><param name="RS4"><value><key name="RS_name"><key name="RequiredProperties"><key name=IMO_INTERFACE_A><entry name=PROPERTY_1/><entry name=PROPERTY_2/></key><key name=IMO_INTERFACE_B><entry name=PROPERTY_3/></key></key></key></value></param>In this case, we will get in the result IMO only PROPERTY_3, although its ancestor (IMO_TYPE_A) specified in the retrieval spec also PROPERTY_1 and PROPERTY_2. This means that specifying a retrieval spec for an interface overrides any retrieval spec defined for its ancestors.
The inheritance schemes enable us to simplify and generalize the retrieval spec. For example, in the case of CTPs, it is enough to specify the base type IConnectionTerminationPoint in the retrieval spec. This ensures that the whole CTP containment chain (all network layers) will be retrieved.
The specific details and inheritance scheme of all IMO objects are described in the IMO reference manual.
Excluding IMO Types and Properties
Similarly to the requiredProperties key, which specifies which IMO types and properties to include in the answer, there is the key excludedProperties, which describes what properties to exclude from the answer. This modifier is useful for filtering unneeded properties from the answer. For example:
<param name="oid"><value>{[ManagedElement(Key=Fore251Lab)]}</value></param><param name="rs"><value><key name="RS2"><key name="requiredProperties"><key name="com.sheer.imo.IManagedElement"><entry name="*"/></key></key><key name="excludedProperties"><key name="com.sheer.imo.IManagedElement><entry name="PhysicalRoot"/></key></key></key></value></param>In this case, the whole IManagedElement object will be retrieved, including all properties, except for PhysicalRoot.
The include and exclude sections are AND-ed, that is, if the same property appears both in the requiredProperties and in the excludeProperties sections, the excludeProperties will prevail and the property will be discarded.
Format/Syntax Retrieval Specification
The XML layout of the Retrieval Specification is as follows:
<param name="rs"><value><key name="[rs name]"><entry name="register">[true/false]</entry><key name="requiredProperties"><key name=[* or IMO type]><entry name=[* or property name]/><entry name=[* or property name]/>. . .</key></key><key name="excludedProperties"><key name=[* or IMO type]><entry name=[* or property name]/><entry name=[* or property name]/>. . .</key></key><key name="requiredAspects"><key name=[* or oid type]><entry name=[* or aspect oid type]/><entry name=[* or aspect oid type]/>. . .</key></key><key name="excludedAspects"><key name=[* or oid type]><entry name=[* or aspect oid type]/><entry name=[* or aspect oid type]/>. . .</key></key></key></value></param>•
•
•
•
•
Aspects
Aspects are persistent information from the ANA DB, such as alarm history or business information entities that can be dynamically attached to any IMO object. The Cisco ANA fabric models only auto-discovered network information, and therefore it does not maintain any historical or business information. Examples for such business information are administrative details of the configured subscribers (name, phone number), descriptive labels for network objects, alarm history for example. The aspects mechanism allows to couple network information with persistent information of this type.
We can attach aspects to every IMO object, by specifying the required Aspects in the requiredAspects and excludedAspects sections in the RS. For example:
<command name="Get"><param name="oid"><value>{[Snapshot]}</value></param><param name="rs"><value><key name="RS5"><entry name=\"register\">false</entry><key name=\"requiredProperties\"><key name=\"com.sheer.imo.IManagedElement\"><entry name=\"*\"/></key><key name=\"com.sheer.imo.IAlarmList\"><entry name=\"*\"/></key><key name=\"com.sheer.imo.ICompiledAlarm\"><entry name=\"*\"/></key></key><key name="excludedProperties"><key name="com.sheer.imo.topology.ISnapshot"><entry name="Links"/></key></key><key name="requiredAspects"><key name="com.sheer.imo.keys.IManagedElementOid"><entry name="com.sheer.imo.keys.IAlarmListOid"/></key></key></key></value></param></command>This GET command retrieves the network snapshot, excluding links (that is,, retrieves the list of devices). The aspects section of the retrieval specification is given by
<key name="requiredAspects"><key name="com.sheer.imo.keys.IManagedElementOid"><entry name="com.sheer.imo.keys.IAlarmListOid"/></key></key>This aspects specification specifies the GET command to attach to each returned ManagedElement IMO object the list of its corresponding alarms. The alarm list for each NE in the snapshot is an example of information that resides in the ANA DB, and cannot be inferred from the network.
The Aspects section in the retrieval spec is processed as follows:
•
ANA then inspects each IMO in the result, including IMOs that are properties of other IMOs. For each such IMO it checks if its OID matches any of the OIDs in the Aspects section in the retrieval spec. If so, it executes an internal GET command for the respective Aspects.
ANA then attaches all Aspects to their respective IMO object (according to the OID) and returns the combined output. The Aspects are attached in the XML response under a key called Aspects of type IMObjects_array (even if the array contains only one element)
Example
By executing the command in the previous section, we shall receive the following reply, which is a list of the NEs in the network, each with its related alarms (in this case we have one NE):
<IManagedElement><ID type="Oid">{[ManagedElement(Key=ASAMSim)]}</ID><CommunicationStateEnum type="Integer">3 </CommunicationStateEnum><DeviceName type="String">MINIRAMSim</DeviceName><ElementCategoryEnum type="Integer">1</ElementCategoryEnum><ElementTypeEnum type="Integer">27</ElementTypeEnum><InvestigationStateEnum type="Integer">2 </InvestigationStateEnum><SysContact type="String">Alcatel</SysContact><SysDescription type="String">ASAM</SysDescription><SysLocation type="String">Alcatel Bell-Antwerpen </SysLocation><SysName type="String">ASAM</SysName><SysUpTime type="java.util.Date"> Mon Feb 03 11:32:28 IST 2003</SysUpTime><VendorEnum type="Integer">2</VendorEnum></IManagedElement><Aspects type="IMObjects_Array"><IAlarmList><ID type="Oid">{[ManagedElement(Key=ASAMSim)] [AlarmList]}</ID><Alarms type="IMObjects_Array"><ICompiledAlarm><ID type="Oid">{[CompiledAlarm(Id=969)]}</ID><AckStatusEnum type="Integer">0</AckStatusEnum><ActiveAlarmCount type="Integer">3 </ActiveAlarmCount><AffectedSncNum type="Integer">53</AffectedSncNum><AlarmType type="Integer">1</AlarmType><CategoryEnum type="Integer">0</CategoryEnum><Description type="">Null</Description><EventTime type="java.util.Date"> Mon Feb 03 17:05:47 IST 2003</EventTime><LatestModificationTime type="java.util.Date"> Mon Feb 03 17:09:47 IST 2003 </LatestModificationTime><PerceivedSeverityEnum type="Integer">2</PerceivedSeverityEnum><RemoveApproved type="Boolean">false </RemoveApproved><RootCause type="String">Link Up</RootCause><Source type="Oid"> {[TopologicalLink(LinkIdentifier=10.10.12.14- 10.10.12.22_168430606_5365972917668516095_ 168430614_5365493598785573887_bi_)]}</Source></ICompiledAlarm></Alarms></IAlarmList></Aspects>Specifying Properties vs. Aspects
The Aspects section is used only for the attachment of the DB object OID to the Network IMO object. The actual data contents of the DB IMO construct is specified in the requiredProperties section (same as for the network IMO objects). In the above example, we can see that in the requiredAspects section we extended the ManagedElement IMO object (the NE) to include the DB IMO object of type IAlarmListOid (which is the OID of the alarm container). However, in order to retrieve the actual alarms information, we have to specify it in the in the requiredProperties section, as follows:
<key name=\"com.sheer.imo.IAlarmList\"><entry name=\"*\"/></key><key name=\"com.sheer.imo.ICompiledAlarm\"><entry name=\"*\"/></key>This instructs BQL to retrieve the AlarmList container, and all of its contained alarm objects (of type ICompiledAlarm).
Required Aspects vs. Excluded Aspects
As described above, the section is used only for defining the attachment of DB objects to network IMO objects, whereas the data retrieval scope in these DB objects is still specified in the requiredProperties section. Similarly, the excludedAspects section is used only for fine-tuning the attachment definition, and not for specifying the retrieved data scope. An example of the relationship between requiredAspects and excludedAspects, can be demonstrated in the case of IMO inheritance. Assume we have a generic DB IMO type A, and an inherited (more-specific) IMO type B, which is derived from A. We can specify the attachment of objects of type A in the requiredAspects section, while specifying object type B in the excludedAspects section. The result will be that all objects of type A (and their derivatives) will be attached, except for objects of type B (and their derivatives).
Registrations and Notifications
This section includes the following:
•
Registering for Notifications
When setting the register flag in the retrieval spec to "true", the system returns the IMO construct that matches this retrieval spec and registers for changes of the data, that is, registering for changes always performed as "Get and Register". Any change detected in any of the data items will be notified in an unsolicited message to the BQL client.
When the BQL session is closed, the system clears all registrations associated with this session. Therefore, there is no need to explicitly unregister before closing the BQL session.
When registering for notifications, the user may optionally specify a registration ID for each registration. This registration ID may be used later for unregistering. Note that the registration ID should be unique and it is up to the client application to ensure uniqueness. If the user performs two registrations with the same ID the second registration will override the first one. The first registration will still be active and will send notifications, but the user will not be able to unregister it. In such case, the only way to unregister the first registration is by issuing an "unregister all" command.
To specify a command ID in a register command append commandId=ID to the beginning of the Get command.
For example:
commandId=5<command name="Get"><param name="oid"><value>{[ManagedElement(Key=RB1800Sim)]}</value></param><param name="rs"><value><key name="RS6"><entry name="register">true</entry><key name="requiredProperties"><key name="com.sheer.imo.ICompiledAlarm"><entry name="*"/></key></key></key></value></param></command>Unregistering
To unregister a specific registration ID send an unregister command with the command ID as a parameter. For example:
<command name="unregister"><param name="commandId"><value>5</value></param></commands>To unregister from all previous registrations use "all" as the command ID:
<command name="unregister"><param name="commandId"><value>all</value></param></commands>When the system detects a change in a registered object it responds with an unsolicited notification message, which is described in the next section.
Notifications
A notification is an IMO object that describes the change in another IMO. For example:
commandId=7<IMObjects_Array><IScalarNotification><ID type="Oid">{[Notification(SequenceNumber=249) (Time=1052903741029)]}</ID><PropertyName type="String">RemoveApproved</PropertyName><NewIMO type="ICompiledAlarm"><ID type="Oid">{[CompiledAlarm(Id=7)]}</ID><RemoveApproved type="Boolean">true</RemoveApproved></NewIMO><OldIMO type="ICompiledAlarm"><ID type="Oid">{[ManagedElement(Key=RB1800Sim)] [AlarmList][CompiledAlarm(Id=7)]}</ID><RemoveApproved type="Boolean">false</RemoveApproved></OldIMO></IScalarNotification></IMObjects_Array>In this example, the notification describes that the in an IMO object of type ICompiledAlarm the property RemoveApproved changed its state from "false" to "true". The notification is always of type IMObjects_Array and contains an IMO object for each notification. In this example it contains only a single notification of type IScalarNotification, which indicates a change in a single property. The notification includes the registration ID, and (for each change object) the type of the changed property, the time & sequence number, and the new & old values.
IScalarNotification
IScalarNotification describes changes in one or more properties of an IMO object. Consider the example:
commandId=7<IMObjects_Array><IScalarNotification><ID type="Oid">{[Notification(SequenceNumber=249) (Time=1052903741029)]}</ID><PropertyName type="String">RemoveApproved</PropertyName><NewIMO type="ICompiledAlarm"><ID type="Oid">{[CompiledAlarm(Id=7)]}</ID><RemoveApproved type="Boolean">true</RemoveApproved></NewIMO><OldIMO type="ICompiledAlarm"><ID type="Oid">{[ManagedElement(Key=RB1800Sim)] [AlarmList][CompiledAlarm(Id=7)]}</ID><RemoveApproved type="Boolean">false</RemoveApproved></OldIMO></IScalarNotification></IMObjects_Array>The notification has four elements:
In the example above, the scalar notification describes a change in the property RemoveApproved for a specific alarm of the device RB1800Sim.
IAddNotification
IAddNotification means that an IMO object was added to the system. For example:
commandId=alarms1<?xml version="1.0" encoding="UTF-8"?><IMObjects_Array><IAddNotification><ID type="Oid">{[Notification(SequenceNumber=253) (Time=1052903750795)]}</ID><PropertyName type="String">Alarms</PropertyName><NewIMO type="IAlarmList"><ID type="Oid">{[ManagedElement(Key=RB1800Sim)] [AlarmList]}</ID><Alarms type="IMObjects_Array"><ICompiledAlarm><ID type="Oid">{[CompiledAlarm(Id=7)]}</ID></ICompiledAlarm></Alarms></NewIMO></ IAddNotification ></IMObjects_Array>This example shows that a CompiledAlarm with id 7 was added to the Alarms table.
IRemoveNotification
IRemoveNotification is sent by a containing object, to notify that one of its internal IMO objects was deleted. For example:
commandId=alarms1<?xml version="1.0" encoding="UTF-8"?><IMObjects_Array><IRemoveNotification><ID type="Oid">{[Notification(SequenceNumber=253) (Time=1052903750795)]}</ID><PropertyName type="String">Alarms</PropertyName><NewIMO type="IAlarmList"><ID type="Oid">{[ManagedElement(Key=RB1800Sim)] [AlarmList]}</ID><Alarms type="IMObjects_Array"><ICompiledAlarm><ID type="Oid">{[CompiledAlarm(Id=7)]}</ID></ICompiledAlarm></Alarms></NewIMO></IRemoveNotification></IMObjects_Array>The OID of the removed element is always given under the NewIMO key.
The notification IRemoveNotification is comprised of three elements:
IObjectDeleteNotification
IObjectDeleteNotification is sent by an object when it is deleted. For example:
<?xml version="1.0" encoding="UTF-8"?><IMObjects_Array><IObjectDeleteNotification><ID type="Oid">{[Notification(SequenceNumber=1201) (Time=1052837316305)]}</ID><Oid type="Oid">{[ManagedElement(Key=RB1)][LogicalRoot] [Context(ContextName=cyber.net)]}</Oid></IObjectDeleteNotification></IMObjects_Array>This example demonstrates the notification in the case that a context was deleted from the NE named RB1. IObjectDeletedNotification reports the OID of the deleted element.
Note the difference between IRemoveNotification and IObjectDeletedNotification. IRemoveNotification is generated for a containing object when one of its elements is removed. For example, when registering on a Virtual Circuit (VC), we shall receive this notification from the table anytime a VC is removed. However, if we would have registered on the specific VC, we would receive an IObjectDeletedNotification notification when the VC is removed.
