There are a few places in Operations Center where you can utilize Regular Expressions (AKA: RegEx, see more here: This Link ) to set up views, specify matching criteria, etc. For this blog I will cover some basics of RegEx.
One of the most common places to use RegEx is within a “Match” when setting up a view. To follow along with this blog, under your Service Model, create an element called “Match Testing”. We will focus on different RegEx settings you can use under the Properties, Elements tab, Match tab.
Point the “Element to match under” to Administration\Automation\Repository. This contains a list of elements that are named based on users and groups defined in your system. Turn on “Display as children” so it is easier to see if your RegEx match worked. I usually have the element (Match Testing) highlighted with the Summary view shown. I then have the Properties dialog up slightly to the right. As I hit apply, I can stay on that dialog but still be able to see what did or did not happen.
NOTE!!! When you press the Apply button after entering a RegEx, if after several seconds (IE: 10 seconds) it is still depressed, most likely you have entered a match criteria that is pulling back ja’zillion elements. You probably forgot (or pointed it) at a wrong branch along with a very wide open RegEx rule. It is probably best to rip the client out of memory, log back in and fix it quickly.
The first thing to understand with Element Match rules when building views is that your goal is to set up a regular expression that will return only the elements you are interested in. The RegEx is evaluated against the full DName (unique name) of the elements. For instance, this is what one looks like: user=admin/repository=Repository/Automation=Automation/root=Administration
To break it down, it reads right to left and is broken up with the forward slash. The first part is root=Administration which is the top level location of where the element is located. The left side (root) is the class name and the right side (Administration) is the element name. So based on this dname, there is an element of class “user” called “admin” that is located under the Administration, Automation, Repository branch.
Suppose you wanted to match on the element called “admin”, the most basic (and probably wrong) RegEx would be: .*admin.*
What that RegEx would do is look at every element dname under the Repository element and if “admin” is anywhere (due to wildcard of .* in front and back) in the dname, it will match on your testing element. While this might be what you are looking for, most of the time it isn’t. The problem is, it grabs to many elements (admin and admins), it also grabed any/all children below admin and admins. If you only wanted the admin branch parent, then you would need to be more precise such as: user=admin.*
To be even more specific, RegEx uses the ^ sign to say: starts with, so it would be: ^user=admin.* Both seem to work fine, just be aware just in case.
RegEx has many options, such as looking at ranges of specific characters and numbers as well as doing Boolean searches such as: user=admin.*|user=guest.*
Meaning, find any element of class user that is named admin or guest. A more advanced (and probably more correct way) to write it would be: ^user=(admin|guest).*
The other Boolean option is “not”, meaning, if I used the example above and reversed it, it should bring back all elements that are NOT named admin or guest: ^user=(?!admin|guest).*
There are many options, ? + | , etc, etc, etc. It really depends on what you are trying to do. My goal here was to get your started.
As usual, have fun and only play on Development systems.
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.