Appendix: Regular expressions

Regular expressions are used to parse large amounts of data to find matching patterns and validate a predefined pattern. For example, in SPP, regular expressions are used for:

  • Account Discovery rules (Property Constraints, Name Ranges and Group Ranges). Partial matches are acceptable (unless the regular expression itself is defined to only return exact matches).
  • Ticket numbers when an external ticketing system is not used. Matches must be exact.

For details, see these Microsoft resources:

Best practices for ticketing not tied to external ticket system

These best practices are for adding a regular expression for ticketing not tied to an external ticket system. For more information, see Ticket systems.

If you use an alternation construct (“|” which is “or”), the longest matching expression is defined first to the least matching expression because Windows.Net regular expression (regex) stops after finding the first match.

For example: A{3}[0-9]{5}ZZZ|A{3}[0-9]{5} is advised instead of the reverse order. Sample entry results follow for the A{3}[0-9]{5}ZZZ|A{3}[0-9]{5} expression:

User entry: Match?  
AAA12345 Yes. Matched on the second regex  
AAA12345Z No. There is no exact match.  
AAA12345ZZZ

Yes. Matched on the first regex.

If the expression were reversed (A{3}[0-9]{5}|A{3}[0-9]{5}ZZZ) there would be a partial match on the first expression and the entry would be returned as invalid.

 

You may want to wrap each expression in an alternation construct with the anchors ^ and $ when using alternation constructs. An example follows: ^A{3}[0-9]{5}ZZZ$|^A{3}[0-9]{5}$.

The ? lazy quantifier should be avoided, especially at the end of the expression. For example, if the regex is A{3}[0-9]? and the user enters AAA12345, AAA1 is returned as a matched string which is not an exact match of AAA12345.

If the greedy quantifier (*) is used against AAA12345 then the matched string will be AAA12345 and be an exact match.