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.