NetIQ Operations Center - invoking right-clicks from javascript

NetIQ Operations Center - invoking right-clicks from javascript

From time to time, installation of NetIQ Operations Center needs a custom action put into place such as a custom right-click, an automation or even a scheduled job.  These actions can make connections to database to read or write data, put data into a log file or email administrators.  We have even had customers over the years automatically close alarms when the corresponding help desk ticket is closed.   Regardless of the reason, the main purpose of this blog is to discuss how to kick off a element right-click operation from a java script.  Keep in mind, that these are server based scripts, not client based.  What that means is, the java script you are running must be running in context of the server such as an Automation Server event, a serverscript Right-Click or a Job (jobs are always server based).

In order to kick off a right-click, you must have some type of context such as the element that you want to run the right click.  For example, if you are starting from a Job or a Automation, then you must first locate the element.

Elements have two main pieces.  The name of the element such as Server1.NetIQ.com, SalesForce, CRM, etc.  The second thing is more under the covers and is referred to as the DName, otherwise known as the Distinguished Name.  The DName is the thing that makes each element unique.  If you are familiar with DName, feel free to skip the next section and go down to section titled: Blog Continued.

DNames Discussed:

The DName is a combination of the class of the element and the element name, along with the parent class and name.  In the client you noticed that there are four main areas; Administration, Elements, Service Level Agreements and Services.  The "Services" one has changed over the years, the original name was "Organizations".  I'll get back to that in a minute.

Just to sync us up, I'll start with a standard element/dname that is on every implementation of NOC.  First is the Administration element.  If you pull up the properties on Administration, you will see in the title bar root=Administration.  The name of the element is "Administration" and the class is "root".  All of the main branches are class "root".  Under Administration there is element called Adapters.   If you pull the properties up for "Adapters", you now see adapters=Adapters/root=Administration.  What this means is the that element called "Adapters" is of class "adapters" and is under the element called "Administration" which is the class of root.   As you drill down each layer gets added to the beginning of the DName.

The Administration branch is out of the box and is handled for you.  Under Elements where adapters run, the class and name of the elements are handled by each integration.  In some cases you have an ability to control how elements are named, the class, etc (such as Netcool, Data Integrator) and in other cases, it is completely up to the underlying tool you are integrating with (IE: AppManager).

Now the Services branch is a bit different.  Remember how I said it used to be called "Organizations", the DName was root=Organizations.  The "Organizations" element has been a) renamed and b) moved.  Under "Services", the element called "Service Models" is (under the covers) "Organizations".  Confused? Don't worry, it will make more sense in a second.  Since we made a topology change in the product when we renamed "Organizations" and we knew that it would impact nearly all our customers, under the covers, we made elements under "Service Models" look like they were still under Organizations.  For old customers this was a good thing, for new customers, we provided you confusion at no extra charge 🙂

If you create an element under "Service Models" named "server1" with class of "host", the dname would be... wait for it... host=server1/root=Organizations.   Notice how it doesn't have anything to do with the parent element named "Service Models" and/or "Services'.

The depth of the explanation is only required because for this blog, I am going to use an element under Service Models as the example and in order to actually try this out on your system, you need to understand why there is a DName that doesn't make complete sense to the flow of the topology.

Blog Continued:

For this example, suppose you have an element under your Service Models called "MyView" with a class of applications.  The Dname of this element would be:   applications=MyView/root=Organizations.   The first step is to locate this element within the java script.
var myElement = formula.Root.findElement( "applications=MyView/root=Organizations" );

 

If found, the myElement variable will be an actual element.  It has an element.name, a element.condition, etc.

Once you have the element, you can then kick off a right-click action as if you were doing it within the Operators client.  One common example is the Service Configuration Management job.  (AKA: SCM, BSCM).  The next tidbit of information is, that SCM used to be called BSCM, before that it was called ViewBuilder.  Under the covers (in the source code), when you start an SCM job, it refers to that as ViewBuilder.  It was renamed to BSCM because ViewBuilder is actually a completely different feature of the NOC.  If you look in the documentation, View Builder is actually an XML file that describes a view.  you can run View Builder jobs (look under Administration\Server\View Builder Repository).

Anyways, now that we have an element (myElement from above), you can kick of the SCM job with the following syntax:
myElement.perform( session, "ViewBuilder|Run", [], [] );

Sure that makes total sense 🙂   myElement is the "MyView" element you created.   Perform is the way to kick off a right-click.   Each time you run a right-click, the session variable is required in order to enforce security.   "ViewBuilder|Run" is the name under the covers for the SCM Generate Now right-click.   This right-click does not require parameters so [] is sent meaning, an empty array).

So the short answer is that you are able to call a right-click from a java script in two lines!  The longer answer is, it really should be a longer script.
var myElement = formula.Root.findElement( "applications=MyView/root=Organizations" );

myElement.perform( session, "ViewBuilder|Run", [], [] );

 

I would recommend that you put a try/catch around it just in case the element does not exist. This way the script ends more gracefully. Also, you should probably add some logging so you know what is going on. Also, if you just created this element to follow along, you MUST have a SCM job defined for this to work.

For example, I would probably write the basic script this way.
try{
// declare variable to hold the DName of the element
// the encodeURL cleans up spaces and special characters in the element name
var elementDname = "applications=MyView/root=Organizations";

formula.log.info( "Locating element: " + elementDname );

// find the element. If the element is not found, an exception is thrown
// and the perform() method will not be executed
var myElement = formula.Root.findElement( elementDname );

if( myElement != null )
{
formula.log.info( "Element: " + myElement.name + " found, starting SCM Job..." );

// Some right-clicks are called and will return to the script right away,
// some don't. In the case of SCM, the code will sit on the line below
// until the actual SCM job is done.

myElement.perform( session, "ViewBuilder|Run", [], [] );

formula.log.info( "SCM Job complete on element: " + elementDname );
}else{
formula.log.error( "Element NOT found: " + elementDname );
}

}catch( Exception ){
formula.log.error( "Exception running SCM Job: " + Exception )

}

You can do other things such as making an array of DNames, running that through a for/loop in order to kick off multiple SCM jobs one at a time. Maybe even starting adapters before the SCM job and stopping them afterwards.  There are probably some other things such as using formula.util.encodeURL() to clean up spaces in the name or other special characters in the DName.  As always, play around in a development environment, not production.   Use this blog as tips and not the final answer on how things should be done each and every time.

 

- Tobin
Labels (1)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
8 of 8
Last update:
‎2020-01-22 22:47
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.