|
|
 
0 |
An interesting (and not entirely infrequent) question came up in the forums this week and a quick explanation of how to work around the limitation.
Can I include the overrideable parameters in the alert description for my custom rule or monitor?
The answer to this is generally “no”. However, as with many situations in OpsMgr, there are always exceptions. This was pointed out by OpsMgr MP authoring guru Stefan Koell (code4ward.net) in a forum thread (HERE). Let’s take a look at an example of his suggested solution to this problem. I was recently developing a custom script-based file size monitor in which I need to solve this problem.
My workflow looked like this:
The Challenge
In this case, the workflow I created accepted two inputs from the user as overrideable parameters:
1) The name of the file to check
2) the maximum size
To make the alert description as useful as possible to the operators, I wanted to include the following text:
“The current file size for <FileName> is <ActualFileSize> is larger than the user-defined threshold of <FileSizeThreshold>.”
The problem is that there is no XPath replacement variable is available to include the used-provided values of the overrideable parameters in the alert description. Since the only value in the data source module output of the data source module passed to the next module in the workflow is the ActualFileSize, it is not a surprise really.
The Solution
The key point to finding a solution is contained in a portion of that last statement. If you want to include the values of FileName and FileSizeTheshold overrideable parameters, you need to find a way to pass those values in the data source module output. The solution is simple really. The PropertyBag (shown in the figure above) is a set of one or more name/value pairs passed to the data source output to next module in the workflow. Since in this example I was only interested in comparing the ActualFileSize to the user-defined FileSizeThreshold, ActualFileSize was all I put into the PropertyBag initially. However, the PropertyBag in this case has a secondary purpose that you can advantage of; as the vehicle to pass any value of interest to the next module in the workflow.
Think of the PropertyBag as a virtual container that will carry multiple name/value pairs that we can use in any way the product allows. In this example, since the parameters are values assigned to variables in a VBScript anyway, it’s only two lines of code to add FileName and FileSizeTheshold to the PropertyBag resulting in a big payoff. We can now add the values of these parameters supplied by the user into the alert description (as shown in the figure below)
XPath Syntax
To can add any value in the PropertyBag to the alert description using the following the XPath syntax.
$Data/Context/Property[@Name='YourPropertyName']$
In this example, the value in alert description would look like this in the monitor definition.
“The current file size for $Data/Context/Property[@Name='FileName']$ is $Data/Context/Property[@Name='ActualFileSize']$ is larger than the user-defined threshold of $Data/Context/Property[@Name='FileSizeThreshold']$.”
When an alert is raised, we’ll now see the parameter values supplied by the user through overrides in the alert generated by the monitor inserted as part of the XPath variable replacement that occurs
Conclusion
Hopefully you found this tip useful. Since I was shooting for a quick example, I’ve not attached a management pack to this post. If you’d like to see the XML to demonstrate the concept, leave a comment on this post.