Matches Regex in Condition Builder

[gtke]

I'm trying to build a condition which matches a string to a regular expression. Matches Regex is a default option in the condition builder for String-type fields, per the wiki Condition Builder - ServiceNow Wiki. However I can't seem to figure out the proper syntax. I did find this community thread: RegEx in condition builder which was helpful but didn't solve the problem. I'm trying to match a field when it has 11 or fewer characters (large text field, used for descriptions etc). From research, the regex I should use is .{0,11}$ -- any character from 0 to 11 occurrences, followed by string end. I know for a fact there are records matching this condition, but the query returns nothing.

[sebastian_g_snc]

Update:

I tried many different things to get a report source working using "matches regex" - impossible.

There is still a problem ticket open with ServiceNow.

I checked it in Helsinki as well and there also this error appears: "Syntax Error or Access Rule Violation detected by database (You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'MATCH_RGX 'INC[0-9]{7}' GROUP BY timeref ORDER BY timeref' at line 1 Query is:..."

So unfortunately Development hasn't fixed this one yet.

[t_nehir]

I tried with many ways to but didn't work.

[sebastian_g_snc]

Not being able to use RegEx is really limiting.

So I created a workaround that I'd like to share: it is a simple example of a report source where I employ a script include to process my regex.

High level overview

1. Report Source calls Script Include
2. Script Include returns a regex-validated comma separated list

I used the baseline report source Incidents.Open and added a condition

NUMBER is one of

javascript:new global.RprtSrcHlpr().testThisRegEx('incident'

'number'

'INC001007\\d');

Notes:

a) the parameters are passed into the function "testThisRegEx" without a separating comma. The platform actually removes them when saving.

b) I am looking for incidents with number INC001007x. The regex must be passed as a string - hence the backslash has to be masked. 'INC001007[0-9]' does the same job

Script Include

Name:

RprtSrcHlpr

Client callable:

True

Description:

RprtSrcHlpr takes a regular expression from the condition builder and test a defined column.

Has to be used with "is one of".

Script:

var RprtSrcHlpr = Class.create();

RprtSrcHlpr.prototype = {

  initialize: function() {

  },

  /*_________________________________________________________________

  * Description: test a certain column using regular expression,

  * because the ServiceNow "matches regex" is not working

  * -in this example we are testing the incident number-

  * Parameters: tbl - system table to get the column from

  * col - column to test without leading and leading slash

  * expr - regular expression

  * Returns: a comma separated list of values (csl)

  ________________________________________________________________*/

  testThisRegEx: function(tbl,col,expr) {

  var resultArray = [];

  var csl = "";

  var rex = new RegExp(expr, 'g');

  var gr = new GlideRecord(tbl);

  // gr.addQuery("name", "value");   // add your query here

  gr.query();

  while (gr.next()) {

  var val = gr.getValue(col);

  var result = val.search(rex);

  if (result==0) {   // 0 is the position

  resultArray.push(val);

  }

  }

  csl = resultArray.toString();

  return csl;

},

type: 'RprtSrcHlpr'

};

Maybe that helps. (Done on Helsinki - hence the global scope)

[johnnyjava]

I'll have to try this, however I'm running against the Running Process table - which is rather large - so I wanted to try to run this in the Process Classifier for Discovery so that it's not an entire table that is evaluated.

Also I'm trying to match regex on "^.{4666}$" which is to say that the start of line and end of line are full of chars, which is a bug with some RedHat kernels where the process table can't hold the entire command line. I find this to be a security risk since we can't actually see what is being ran.

The issue stems from java classpath arguments being built by passing in entire directories of jar files to the point that the command line is rather lengthy.

It's possible that doing this in a report is actually a great idea since I plan on showing this to our leadership anyway.

Abhinay I'm fairly certain from working on this that the ^ symbol breaks the condition builder since the encoded queries use it as a placeholder for AND.