Share This:

EUEM makes extensive use of filters. These are used in the following manners to name a few:


1) To include or exclude subsets of your traffic data with regards to what gets processed by EUEM

2) To control what gets included into the data for specific Watchpoints

3) To control where to apply rules.


While one could write filters completely from scratch, the Filter Expression Builder makes the work far easier by allowing you to make selections from dropdown boxes to unlock the full power of the filter expressions. Filters can be quite generic, using a single condition or very specific relying on a series of conditions to be met. With regards to Watchpoints, a complex, multi-condition filter can be handled either by a single complex filter or by several independent filters where one can control whether all or any of the filters must be met for traffic data in question to be included or the rule in question to be acted upon.


Single filter rule:


Multiple filter rules:


Next, we can focus on how breaking up a URI into its components allows us to capture multiple matches by leveraging the various string operators and how to use them most efficiently. For matters of simplicity, we are going to focus on strings and the parts of the URI.


A URI such as: can be broken down as follows:


URI Host = (This is the name of the application in question)


URI Stem = /wonder/access_form.aspx (This is the name and path to the specific resource in question)


Query Parameters = ?q1=test&q2=blue (Query parameters are a way to pass information in the URI call that may affect the details of the resource that is returned)


By focusing on say just the URI Host, we can grab all of the traffic related to the application in question. If we instead focus only on the URI stem, we can grab data related to a specific resource that may exist on multiple applications that we might be monitoring.


Because the paths to the location might not be the same from application to application, that's where the string operators come in. We'll start with the simplest of these operators:


  • Is equal to (=) This means that the part in question in the traffic must exactly match what is in the filter
  • Starts With This means that the part in question in the traffic must start with the same characters defined in the filter
  • Ends With This means that the part in question in the traffic must end with the same characters defined in the filter
  • Contains This means that the part in question in the traffic must contain the string defined in the filter
  • Is in comma-seperated list means that the string in the traffic must match one of the strings in the comma-separated list defined in the filter.


For example if one application has the access_form.aspx resource here in one application: /wonder/access_form.aspx and here in another application: /glue/membership/access_form.aspx we could capture this same resource in both applications using (url.stem_string endswith "access_form.aspx" ignorecase).


In the same way, if we wanted to focus only on the web servers for our multiple applications, we could use something like ( startswith "www").


The operator that requires the least amount of resources is the Is equal to operator because the comparison is very straightforward. The string for the part in question either is or is not what is defined in the filter. For operators like Contains, EUEM must search through the part in question.


Sometimes we might want to match more than one condition, hence the Grouping & Chaining Operators: AND, OR & NOT


AND is used when multiple conditions must exist simultaneously in the traffic. OR is for when at least one of the conditions in question must be true. For example, a single request can only be addressed to a single URI Host, so if we are looking for traffic to either Application A, B or C, this is where the OR operator is used. NOT is used to exclude traffic where the string in question is seen.


When creating a complex filter expression with more than one condition, we can choose to add the new conditions to the expression using: AND, OR, AND NOT, OR NOT.


Lastly, we can create filter expressions where say the URI Host must be one of three choices while at the same time, the URI Stem must match a specific string condition. In order to make this happen, the conditions and arguments must be grouped. For this example, the filter expression might look like this:


(( is "")  OR  ( is "")  OR  ( is ""))  AND  (url.stem_string endswith "qualities.html" ignorecase)


The additional brackets make it clear where the choice is and where the conditions (or groups of conditions) must both be true.


Creating efficient filters means reducing repetition and fully leveraging the string operators in question. By creating efficient filters, we free up resources to handle more traffic volume.


Please feel free to rate this blog or leave us any questions or comments as we are always looking to improve our documentation.


To see more blogs like this, see:

TrueSight App Visibility Manager