It is true that dealing with custom KMs in BPPM 9.6 is not one of the strong points of the platform. Unfortunately there is no other way to use the custom KMs in the BPPM 9.6 without preparing the metadata of the KM. Basically, you will need to teach CMA about your custom KMs structure using the KM XML files.
There is a procedure for generating the KM XML files using the patrol developer for adding the metadata information to the application classes and parameters ( attributes ). I can't find the procedure at the moment.
Please review the below documentation to get a better idea on how to modify the KMs metadata:
i'm aware of the procedure to convert custom km. I'm wondering how it's possibile that without applying this procedure, i was able to display the graphs from my custom km on proactivenet!
Besides, converting is not the only option: you can always tell the agent to send only the events and not the data.
Hi, a little update on this topic.
It turned out that older custom kms, developed with very old versions of the patrol classic console, lacked the necesssary xml files and km/kml headers. So for these km only we had to apply part of the procedure to convert custom km, which is the part related to enabling the data collection.
This procedure (which mainly means generating the xml files or using a newer patrol classic console to let it generate them itself and adding headers to the km and kml files) made it possibile for Proactivenet to display monitors replicating the km structure shown in the old PCO and their related graphs.
Newer custom km developed with newer patrol classic console already had the xml files and headers and everything.
Regardless of these procedures, all custom kms were by default enabled to send events to proactivenet. (these patrolagents didn't receive any other policy that could filter out events/data).
I didn't tried to apply the full procedure to create a proactivenet package out of a custom km solution and related policies yet, but i'm satisfied with the result for the moment.
Through Query Agent feature in proactivenet console i can also manually set parameters on custom kms to make them generate alarms for testing purpouses.
1 of 1 people found this helpful
I have developed several custom KMs in a new BPPM/TrueSight environment and also have converted some of my old KMs. Here are a few tips:
The extra stuff that your KMs must have under the new 'management' of BPPM/TrueSight:
1) Meta data: You need meta data at both application class level and parameter level. If you are using newer version of PATROL Classic Console such as V3.6.00, you should see the 'Meta Data' tab when editing application class and parameter.
2) Release info: You need to add a few lines of text including release info to your kml file and all your km files. I have been doing this using a text editor as I am not aware of any way to do this automatically with PATROL classic console. If you are developing a KM using PATROL Classic Console, every time you save your KMs, all these release info you manually added using text editor in your KM file will be wiped out. It is a pain to keep adding them back manually.
3) XML files to pair with KM files: For each application class KM file, you must have a XML file. This XML file is automatically generated by newer version of PATROL classic console. However, the 'release info' part must be manually added in as you do with each KM file. If you are developing a KM using PATROL Classic Console, every time you save your KMs, all these release info you manually added in XML file using text editor will be wiped out. Again, it is a pain to keep adding them back manually.
4) XML input to configure KM in CMA: If you want to use GUI to configure your KM like using response functions in the old days, you need to write them using XML. In newer version of PATROL Classic console, you should see 'Input' tab when editing application class. The input tab should contain your XML code to configure KM in CMA.
5) PCIG packaging utility: After all the above addition, you can use pcig utility to package your KM and create a tar or zip file. Then you can import this tar or zip into CMA repository. After the import, you should see your data displayed in BPPM operations console in the hierarchy you want.
If you want to make changes, you repeat these steps all over again.
I expect to wrap up my current custom project soon. If any of you need a consultant to speed up your custom KM development or conversion process, I appreciate you for keeping me in mind.
thanks for the tips. I didn't realize that saving the kms would wipe out the release info, this is really annoying ! Besides i've noticed that xml are not getting committed along with kms from patrol classic console, which is another pain point.
One thing i didn't understand: what's the benefit of being able to package the km ?
I'm already receiveing data/graphs/events just with xml and release stuff and monitors are shown in the same way tree they would under patrol classic.
Is the packaging needed to have custom km attributes in proactivenet so that global/instance thresholds can be set ? Or is it just for distributing the km along with its needed xml files ?
The answer is both. You obviously need the package in CMA in order to create deployable packages for distribution purpose if you need to install your custom KMs on hundreds or thousands of servers.
You also need the package in CMA in order to set global thresholds and create CMA policies (monitor configuration server threshold, agent threshold, agent configuration for polling interval, monitor type level data/event filter, etc.). In CMA, most configuration starts with solution name. This solution name is given only during packaging process.