The "Match and replace" action can be used to search element fields for specific field contents. You can also configure the action to change the field contents that are found. You can configure the action for any number of element fields. You can specify a sequence of checks for each field.

When the action is executed, the configured match sequences are run through and evaluated for all element fields according to the propositional logical form. The "Logic" parameter defines the basic form of the propositional terms, which determines how the matches are evaluated.

CNF (default)

The abbreviation "CNF" describes the basic conjunctive normal form of the propositional logic. The action is successful when the "AND of ORs" is successful and a logical OR is used to link the match sequences of an element field. The partial results of an element field are then linked by a logical AND with the partial results of all other element fields, which determines the overall result of the action.

DNF

The abbreviation "DNF" describes the basic disjunctive normal form of the propositional logic. A logical AND is used to link the match sequences of an element field, whereas the partial results for each element field are linked by a logical OR. In descriptive terms, this basic form of propositional logic is "AND of ORs".

Logic and mode

If the action is used to match AND replace, then each action is only successful if both a match and replace occurs. This in turn has a direct impact on the partial results of the action sequences of the configured element fields and therefore also on the overall result. In this mode, therefore, it must be possible to perform a replace action following a successful match.

The following configuration excerpt shows the basic configuration of the action for replacing a subject line:

As with the other actions, you can enter a value for Name according to your requirements. You need to set "Replace" in the Type field in order to be able to change the subject line. The underlying Logic "CNF" is "And of ORs".

In the next step, you need to select the correct field (for an Exchange instance in this example):

The Field name is "PidTagSubject" (see "Determining field names with ELOxcTools"). The "element" data level (Destination) of the result is always the element field itself, since we also want to save the changes on the server. If you select "cache" here, the result of the replace action would not be saved after the element has been processed.

Now you have to configure the match and the desired replacement:

You can enter any value for the Id. These entries are only relevant if a match is used in the context of keywording with a user-defined reference pattern (see TemplateKeywordingDef).

The Mode needs to be "REGEX", since the field contents are to be determined and used in the replacement.

The Options allows you to make further modifications to the REGEX match, which is not relevant in this example.

The pattern entered to the Pattern parameter above ensures that the entire field contents are stored temporarily as a REGEX group for the match.

The desired replacement pattern in Replacement generates output with"[ELO]" followed by the original field contents determined with the parameter Pattern.

The parameter Delim is only necessary for interval matching and can be ignored in this example.

If you test this configuration, you will notice that only non-empty subject lines are returned with this match. However, since empty subject lines can occur in practice, a second match is required for this case:

Pattern is configured so that there are no characters between "^" and "$".

The replacement pattern in Replacement ensures that the output indicates that the field contents were missing.

The effect of the basic form "CNF" in this example:

If match 1 is successful (non-empty subject lines), match 2 is ignored, since the form "CNF" cancels the operation sequence of a field as soon as a match is found. If the subject line is empty, match 1 fails, which is why the action continues with match 2. However, if you configured the basic form "DNF" in this example, the action would inevitably fail, since a subject line cannot be empty and non-empty at the same time, because the basic form "DNF" means that the configured operation sequences of an element field must always all be successful, which is impossible in this usage example. Using the example of the subject line, the basic form "DNF" would make sense if you always wanted to convert subject lines with the exact form "RE: <subject line> (ticket: ...)" into "ticket: ... - <subject line>" with the entire action, for example. In this case, you would need to identify "RE:" in match 1 and replace it with an empty string, while the suffix "(ticket:...)" is identified is match 2 and preceded by a suitable replacement of the original subject line that was also found. Both operations must therefore be successful, otherwise it is assumed that the action will process subject lines that it shouldn't.

The data type of the element field is also a material factor in this action. The allowed data types for processing Exchange Server elements are strings, numbers, times, and Boolean expressions. Multi-line data types cannot be processed, nor can binary fields or currency amounts.

Comments:

"simple" mode is the default setting. In this mode, you can have the wildcard "*" at the end of the matching pattern, but you can only use this wildcard. Internally, the matching pattern is converted into a suitable regex in this mode.

With the exception of "regex" mode, the modes are not case sensitive.

You can only run interval checks on field values in "constant" mode. The matching pattern is formatted accordingly.

Interval check

An interval check is only supported for numeric and calendar field data types and is configured in the form "[<lower threshold><separator><upper threshold>]". The mandatory square brackets denote a closed interval. You cannot therefore configure open-ended intervals. The "Delim" parameter determines the separator. If this parameter is not specified, the interval is not recognized.

The specification of the interval thresholds is evaluated according to the field data type. Numeric field data types do not require any further formatting and can be entered as they are. Calendar field data types (or fields for time specifications) can be formatted in two different ways, which means that field values are checked in two different ways.

1. Absolute time check: The interval thresholds are formatted as an ISO date. This means that a calendar value such as "21.07.2017 10:03:25" is converted to "20170721100325" (ISO standard).

2. Relative time check: The interval thresholds are specified as "age<time span>". The time span has the format "dddhhhmmss", (days, hours, minutes, and seconds). It is important that the "age" marker is set before the time span. The start time of the job is material for the relative time check.