Does CA permit modifications in Nimsoft database schemas. i.e. creation of newer tables/triggers with custom information fetched using info inside the box & applying various logics.
As an example I wish to read some file (that is parsing specific alarms' hostnames) and insert that data in a new table in the NimsoftSLM database. Is this permissible? and does it affect/violate the product guidelines?
And if yes, how do we make it reflect in the UMP too?
If what you want is use the UIM database to create tables for organizing data which won't be used by UIM and making sure they will not affect the integrity of its schema, I believe there shouldn't be a problem. But, if I correctly understand your question, you want to have this data available through UMP. In this case I don't think this is possible/supported. Maybe someone else can correct me if I'm wrong.
Please take a look at the following article on best practices for the UIM database: Knowledge Base Articles. You may find it useful.
My proposed approach was to fetch the information from a perl script, create the new table from within the perl script, keeping the new table within the NimsoftSLM hierarchy. What we do with data in the new table can be the later part.
I don't foresee any problems for having any custom tables or any custom objects within UIM. The problem will only arise if any native objects within UIM schema have been changed.
This is NOT supported.
There is no way to tell that a table created in the database will not cause a problem with an upgrade in the future or that an upgrade may cause harm to this data structure.
For this reason it is not supported for clients to make changes to the UIM database schema as there will be no way for support to trouble shoot help if this is done.
If you need to create and store additional data please create a new database schema and add your data there.
You then can create views in your new instance if you need to pull in the data from another database and in UIM reports point to the new schema as a data source.
I hope this helps clarify why this is not supported.
"Supported" is always a touchy subject. I am pretty sure that there's nothing in the documentation that says you can't do what you want but to Gene's point, once you do, it will always create the question and possibility that what you did is the source of future problems.
That said, you leave out the goal of your request. There are a couple probes that are designed out of the box to read files and import them - file_adapter for instance. Your app coulr process the data then drop the requisite file for the file_adapter probe to pick up. Or why not have your perl application put the data on the bus as QoS instead of doing the database inserts yourself?
And again, depending on the data, the nas LUA scripting has the concept of persistent variables that wind up being stored in the local nas database.