| >Ciao,
>the customer likes the product ROBOMON by Heroics and the customer asked me to
>evaluate and to test the integration with the PCM.
>The integration was ok and reasonable easy as each event coming from ROBOMON
>has been mapped to one PCM event. Defining the right filters and scan profiles
>I was able to get all the messages coming from ROBOMON and the customer was
>happy. No programs and code were written to integrate the two products.
>During the integration I got some questions:
>1. HOW TO CHANGE THE CONTENT OF A FIELD INTO THE ENS LIST
>One of the field of the ENS list is "source" and this field reports the
>source of the event: console, watchdog, Oscint,... As ROBOMON send messages to
>the OPCOM, the PCM gets all the ROBOMON event coming from the source "console".
>Is it possible (I mean for the final user as the customer system manager) to
>put the word "robomon" instead of "console" into the field "source" of the ENS
>list? If yes, how it is possible?
The source really is the "console" because the text was read from the
"console" port by a line controller daemon. The other products that
you mention utilize the PCM API routine CMUserSendEvent and they
specify the source field explicitly. You can do what you want but you
would have to write some code namely an "event preprocessor". The
"event preprocessor" would receive the event and scan the event name to
see if it's one of the Robomon events. If it is, you can change the
"source" field in the event packet and then pass the event back to ENS.
ENS would then send the packet to all the action routines .
If you can live without this string being in the "source" field, you
could create a class of events call "Robomon" and then have the
Eventlist application display the class field. Alternatively you
could do the same thing with the "subsystem" field.
>2. HOW USE PARAMETER VALUES INTO THE PCM EVENT DEFINITION
>I will use an example to explain what I would like to realize with
>ROBOMON. Look at the event as "check for disk near full".
>Who has used the OSCint to integrate PCM with PSW knows that the field
>"Information" of the ENS list event line reports the name of the disk near full.
>As I defined the ROBOMON event as a PCM event, the field "information" of the
>PCM event definition is displayed to the field "information" of the ENS list.
>At the time of the definition of the ROBOMON event into the PCM database I
>obviously do not know the name of the disk near full and then during the
>definition of the event I must insert a generic text to be displayed into the
>ENS list.
>When the event "disk near full" will occur on the system I get the name of
>the disk near full clicking twice on the line reporting the event. The double
>clik shows me the full context of the message sent by ROBOMON to the PCM and
>then the name of the disk.
>If the event "disk near full" occurs to many disk of the system, on the ENS
>list a lot of lines reporting a generic message of "disk near full" will be
>displayed but no line will reports which is the disk in fault.
This does not make sense. The event context should not be effected by
the number of events being reported unless the individual lines are
being jumbled together becuase the application that sends them uses
$BRKTHRU instead of $SNDOPER. You implied above that OPCOM was being
used so each OPCOM message should be displayed intact before the
next OPCOM message is started.
>Then, what I would like to do is to put a sort of parameter (or variable) into
>the "information" field at the PCM event definition level to make general the
>definition for each disk of the system and to get the name of the disk near
>full directly to the field "information" of the ENS list. More or less I would
>like to create an output similar to the output got using OSCint integrating
>PSC and PSW.
>Any idea or suggestion?
It would help to see one or more complete OPCOM messages generated by
Robomon. If the disk in question is part of the same line that contains
the string "disk near full" the solution will be as simple as changing
the event to a regular expression and slightly modifying the event
text. We can discuss this after you post one of the messages.
Regards,
dan
|
| Anna,
what you see here is the limitation of using the ROBMON 'integration' with PCM
and why the PSW/OSCint approach is better.
As Dan said, the reason you see Console is because it comes from the console
As for you wanting to use variables, well - you could still use OSCint for the
OXF functionality. This will let you do things like manipulate the message that
gets sent to ENS. So the event is picked up by the Daemon and sent to the
pre-processor (OXF), there you do manipulation on the event text and can
generate particular information based upon the event text.
One of the other problems with the RoboMon interface is that they prioritise
their events them selves in the scan profile they provide. With their solution,
it is not possible to differentiate between a system disk becoming full or a
data disk, on a development system, becoming full.
To really integrate the two I would have a Robomon 'server' on the PCM system
receiving events from around the enteprise and 'poking' them into ENS directly.
You could then choose to use the OXF facility, or not, depending on if you want
event correlation with Console messages as well. This will mean writing code,
but it does give a better, and tighter, integration.
Shaun
|