Missing topology association when EventAdmin model is created in CA Spectrum via REST API


Article ID: 141480


Updated On:


CA eHealth CA Spectrum


We tried creating an EventAdmin model under a Network topology using rest API


The model got created but when a test trap is sent from the source, the event never gets raised on the model.

However, when creating the same EventAdmin model again manually from the Spectrum OneClick console using the same values as in the rest API, the test trap is successfully raised.

Why does this occur and how can it be fixed?


The problem is that if the model's topology location is not defined via associations, then the newly, REST API created EventAdmin model goes to Lost & Found. In OneClick, on the other hand, you automatically set its place in the topology depending on where you are when you create it.


Spectrum 10.x



To fix this, an association to a topology model needs to be created. When you create that association, the TopologyModelNameString should be automatically populated. The association required here is the "Contains" relation.

When a device is discovered and a model is created in the SpectroSERVER database, associations are created linking it to the various views that the device is a member of.

For example, a "Contains" association for the Topology container and the Global Collection containers using its hex identifier (0x10002). So this is what you would have to add to complete the creation of the EventAdmin model. So in this case, a Contains association between the new EventAdmin model and the container/GC that contains it needs to be created, using;



You can find out what the current Relation Model_Handles (RMHandle) are by using the VNM shell (vnmsh) command line. For example:

[[email protected]:/usr/Spectrum/vnmsh] $ ./connect
[[email protected]SpectroSERVER:/usr/Spectrum/vnmsh] $ ./show associations mh=0x100565

LMHandle    LMName                            Relation                         RMHandle    RMName
0x100004    Universe                          Collects                         0x100565    Sim34327:JIL-OPN-CSA37-01.intern
0x100565    Sim34327:JIL-OPN-CSA37-01.intern  PossPrimApp                      0x100566    Sim34327:JIL-OPN-CSA37-01.intern
0x100565    Sim34327:JIL-OPN-CSA37-01.intern  Manages                          0x103493    Sim34327:JIL-OPN-CSA37-01.intern
0x100565    Sim34327:JIL-OPN-CSA37-01.intern  Has_Relay_Function               0x100577    Sim34327:JIL-OPN-CSA37-01.intern
0x100565    Sim34327:JIL-OPN-CSA37-01.intern  Has_Relay_Function               0x100665    Sim34327:JIL-OPN-CSA37-01.intern
0x100565    Sim34327:JIL-OPN-CSA37-01.intern  RTM_HAS_TEST_HOST                0x10056a    Sim34327:JIL-OPN-CSA37-01.intern
0x100565    Sim34327:JIL-OPN-CSA37-01.intern  HASPART                          0x100674    Sim34327:JIL-OPN-CSA37-01.intern
0x100565    Sim34327:JIL-OPN-CSA37-01.intern  Contains                         0x100659    Sim34327:JIL-OPN-CSA37-01.intern
0x10002a    Cisco IOS - SSH Capable           NCM_Family_Has_Device            0x100565    Sim34327:JIL-OPN-CSA37-01.intern
0x1034a7    New Devices                       staticGlobalCollects             0x100565    Sim34327:JIL-OPN-CSA37-01.intern
0x1034a9    Test                              Connects_to                      0x100565    Sim34327:JIL-OPN-CSA37-01.intern
0x1034a9    Test                              Is_Adjacent_to                   0x100565    Sim34327:JIL-OPN-CSA37-01.intern

In the above example, is a Cisco Catalyst 37xx device. From the above, it can be seen that the Catalyst device model (Model_Handle = 0x100565) is in the Universe container, which Collects it. Also, it is shown that the device model Contains other models, such as Apps, interfaces etc..

Additional Information

If you look at the following link, it describes how to create an association relation via RESTful API:

Broadcom TechDocs : CA Spectrum 10.4 - Associations

The "Contains" association relation, as described in the TechDocs:

Broadcom TechDocs : CA Spectrum 10.4 - Relation Descriptions