From time to time there is a need to open a ticket, send an email, run a commandline utility, etc either based on a user issuing a right-click and/or an automation. For this blog I will go over the skeleton of the script(s) to get you headed in the right direction.

For the first part, the thought is that we want the commandline util or the ticket opened to occur in the context of the actual Operations Center server. Sometimes due to limited apps installed on the client PC and/or traversing firewalls, it makes more sense for the actual “action” to happen from the Operations Center server as opposed to the client PC.

For this requirement, I leveraged an adapter setting to start up my main script. Each adapter has a property such as Script.onStarted, Script.onStopped. The idea is, when the adapter “starts”, it will run whatever is in the Script.onStarted setting. While there are several other options for starting and running the script, I used the Script.onStarted as an example. For my example, on the adapter I used, I had the following in Script.onStarted:

load( "SOS.fs" );

Next I needed to put together a script that does the work. I need a way for a script to run on the server, but I need to be able to add/pass things from a right-click and/or an automation. The first part of the script leverages a server side global variable feature in Operations Center called “state variables”. For my state variable, I created a LinkedList, essentially a way that I can add things to this queue and then pull them off the queue. There are several ways this can be done, I just used LinkedList for this example.

The next section of code is a for-loop that runs forever. I’d like the script to check the queue (LinkedList) for work, sleep a bit, then check for more work. In case I need to make changes to my script, since it runs forever regardless of the adapter running or not, I also made the for-loop leverage the adapter status (running vs stopped) to end my script.

Attached below is the Script.onStarted script. The script is only the skeleton of setting up the state variable and the for-loop to process items, it only logs items to the log file for now. Add your code to expand functionality such as inserting rows into a database.

/* Script On Started for an adapter */

if( !state.myQueue )
{
	// If the state (server side global) variable does not exist, create it
	var myQueue = new java.util.LinkedList();
	state.myQueue = myQueue
}

// Grab the current status of the adapter, ie: running, stopped, reconnecting.  
// Keep in mind that status may be different per adapter
var adapterStatus = adapter.status();

// While loop that runs forever... mostly
while( !adapterStatus.equals( "stopped" ) ){

	// re-grab adapter status, want the script to stop/end if the
	// adapter is stopped.
	adapterStatus = adapter.status();

	formula.log.info( "myQueue size: " + state.myQueue.size() );

	// if there is something in the queue, process it	
	if( state.myQueue.size() > 0 )
	{
		var item = state.myQueue.remove();
		formula.log.info( "item: " + item );

		// Add code here to update a database, send email, run a commandline util, etc
	}

	// sleep for 10 seconds before looping again
	try{

		java.lang.Thread.sleep( 10000 )
	}catch( Exception ) {
	}
}
formula.log.info( "ending SOS.fs" );

Next to test my script on started script, I created a right-click that runs as a serverscript. Since I need access to the state variable to add things to the queue, the right-click must run in context of serverscript. Below is the script associated to the serverscript operation.

The script first ensures that the state variable exists, if it does, it adds the “element” to the queue and adds the element name to the queue. Typically you would only add one item such as the element name or even the entire element, I was just trying to fill the queue quicker and showing multiple examples.

if( state.myQueue ){

	state.myQueue.add( element );

	state.myQueue.add( element.name );

	formula.log.info( "myQueue size: " + state.myQueue.size() );
}

That pretty much covers it. There are many ways that this can be done, but this is a common approach we have done over the years. Hopefully this will be of use to you and as always… develop and test these on a Dev/QA system and NOT production :)

– Tobin

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Loading...Loading...

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

No Comments
Tobin Isenberg
Nov 2, 2011
9:40 am
Reads:
1,330
Score:
Unrated