DX Infrastructure Manager

Expand all | Collapse all

Adding Origin to OC

  • 1.  Adding Origin to OC

    Posted 9 days ago
    Like in UMP the "view-scope" of alarms is based on the origin.
    Is there a official way to add an origin to that list.

    e.g. I have customers who should see a specific type of alarm, but no others. So I simply switch the origin via PreProcessing from Orgin "A" to Origin "B".
    Now... well Origin "B" is not listed in in the Ownership-Choose-Table of the Account.
    Is there an official-way/-tool to generate a Origin?

    At the moment I would try to switch one of my robots from his Origin to Origin "B" send some Alarms, so that the spooler of this robot puts the Origin "B" in the message and the discovery_server (or who ever) detects it and inserts into the DB, following crossing fingers that it doesnt vanishes if I put the Robot back to its original Orgin.

    Or any other Ideas?

  • 2.  RE: Adding Origin to OC

    Posted 9 days ago
    Edited by Luc Christiaens 9 days ago
      |   view attached
    In attachment a small test perl that can overwrite almost any alarm value
    This makes it easier to create an alarm for a specific origin.


    create_alarm.txt   998 B 1 version

  • 3.  RE: Adding Origin to OC

    Posted 9 days ago
    I don't think that an alarm will add an origin in the origin table.
    I think that a simple qos with the correct origin set by a qos_processor rule/script will do the trick.

  • 4.  RE: Adding Origin to OC

    Posted 9 days ago
    Hi Luc!

    Great hint! Thanks a lot, I'll try that



    Matthias Gruber
    IT-Infrastruktur & -Betrieb

    B. Metzler seel. Sohn & Co.
    Kommanditgesellschaft auf Aktien
    Untermainanlage 1
    60329 Frankfurt am Main
    Telefon (0 69) 21 04 - 43 30
    Telefax (0 69) 21 04 - 40 40


  • 5.  RE: Adding Origin to OC

    Posted 9 days ago
    ARGH.....found it.
    My initial Stuff worked :-)
    Receive the alarm via REST, start a preproc which switches the origin.
    temporary switch the origin of a robot to that rest-PreProc-Destination-Origin, so that it exists in the db, create a alarm, and switch it back
    Give access-right in the account for that origin
    And now (<sarcasm>) the "tricky"-Part  (</sarcasm>)
    Use the right login to check that :-(((((
    Had a look into the alarmviewer-api.log (thanks Broadcom for that log), and be irritatet, that in "where (nas.origin IN ('.....))" the origin was missing....
    And voila.... login mgitop2 isnt equal mgitop-2  :-) changed the Account of one and tried with the other, and had therefore the conclusion it wasnt working
    Hahaha I even set up a new Linux-Server with a wasp and only a uimapi in it :-)))

    Conclusion....too much test-logins which looks equal but resides in different accounts :-)
    But most important it works initially