Mit der "Finden und Ersetzen"-Aktion können Sie Elementfelder auf bestimmte Feldinhalte hin überprüfen. Zusätzlich können Sie die Aktion so konfigurieren, dass sie bei positiver Überprüfung die Feldinhalte verändert. Die Aktion können Sie für eine beliebige Anzahl von Elementfeldern konfigurieren. Dabei können Sie für jedes Feld eine Sequenz von Prüfungen angeben.

Bei Ausführung der Aktion werden für alle Elementfelder die konfigurierten Vergleichssequenzen entsprechend der eingestellten aussagenlogischen Form durchlaufen und ausgewertet. Der Parameter „Logik“ definiert die Grundform des aussagenlogischen Terms, der die Auswertung dieser Vergleiche bestimmt.

CNF (Standard)

Die Abkürzung der Logik „CNF“ beschreibt die Grundform einer „konjunktiven Normalform“ der Aussagenlogik. Die Aktion ist genau dann erfolgreich, wenn die „Ver-UND-ung von Ver-ODER-rungen“ erfolgreich ist. Dabei werden die Vergleichssequenzen eines Elementfeldes untereinander durch ein logisches ODER verknüpft. Die dabei entstehenden Teilergebnisse eines Elementfeldes werden anschließend durch ein logisches UND mit den Teilergebnissen aller anderen Elementfelder verknüpft, womit das Gesamtergebnis der Aktion ermittelt wird.

DNF

Die Abkürzung der Logik „DNF“ beschreibt die Grundform der „disjunktiven Normalform“ der Aussagenlogik. Dabei werden die Vergleichssequenzen für ein Elementfeld durch ein logisches UND verknüpft, während die Teilergebnisse für jedes Elementfeld durch ein logisches ODER untereinander in Beziehung stehen. Anschaulich formuliert ist diese aussagenlogische Grundform die „Ver-ODER-ung von Ver-UND-ungen“.

Logik und Modus

Verwenden Sie die Aktion nicht nur für Vergleiche, sondern auch für Ersetzungen, ist eine einzelne Operation nur dann erfolgreich, wenn nicht nur der Vergleich erfolgreich ist, sondern auch eine Ersetzung stattfinden konnte. Das wiederum hat direkten Einfluss auf die Teilergebnisse der Operationssequenzen der konfigurierten Elementfelder und bestimmt damit auch das Gesamtergebnis. In diesem Modus muss also eine Ersetzung bei erfolgreicher Musterprüfung erfolgen können.

Der folgende Konfigurationsausschnitt zeigt die Grundkonfiguration der Aktion für die Ersetzung einer Betreffzeile:

Der Wert für Name ist wie bei anderen Aktionen beliebig. Der Type muss auf „replace“ eingestellt werden, da die Betreffzeile verändert werden soll. Die zugrundeliegende Logik „cnf“ ist die „Ver-UND-ung von Ver-ODER-ungen“.

Im nächsten Schritt wählen Sie das richtige Feld aus, in diesem Beispiel für eine Exchange-Instanz:

Der Feldname ist „PidTagSubject“ (siehe Ermittlung von Feldnamen mit ELOxc Tools). Die Datenebene (Destination) „element“ des Ergebnisses ist zwangsläufig das Elementfeld selbst, da die Datenänderung später auch im Server gespeichert werden soll. Würden Sie hier „cache“ auswählen, würde das Resultat der Ersetzung nach Abschluss der Elementverarbeitung verloren gehen.

Nun müssen Sie den Vergleich und die gewünschte Ersetzung konfigurieren:

Als Id können Sie einen beliebigen Wert auswählen. Diese Einträge sind nur dann relevant, wenn ein „Match“ im Rahmen einer Verschlagwortung mit benutzerdefiniertem Ausgangsmuster verwendet wird (siehe TemplateKeywordingDef).

Der Modus muss „regex" sein, da der Feldinhalt ermittelt und in der Ersetzung verwendet werden soll.

Der Parameter Options erlaubt weitere Modifikation des Regex-Vergleichs, was in diesem Beispiel aber irrelevant ist.

Das obige Muster im Parameter Pattern sorgt dafür, dass der gesamte Feldinhalt als Regex-Gruppe für den Vergleich zwischengespeichert wird.

Das gewünschte Ersetzungsmuster in Replacement erzeugt Ausgaben mit „[ELO]“, gefolgt vom ursprünglichen Feldinhalt, der mit dem Parameter Pattern ermittelt wurde.

Der Parameter Delim ist nur für Intervallvergleich notwendig und kann in diesem Beispiel ignoriert werden.

Wenn Sie diese Konfiguration testen, stellen Sie fest, dass mit diesem „Match“ nur nicht-leere Betreffzeilen positiv geprüft werden. Da leere Betreffzeilen in der Praxis aber durchaus vorkommen können, ist noch ein zweiter „Match“ für diesen Fall erforderlich:

Pattern ist so konfiguriert, dass zwischen Zeilenanfang „^“ und Zeilenende „$“ kein Zeichen zu finden ist.

Das Ersetzungsmuster in Replacement gibt das wieder, indem eine Ausgabe produziert wird, die das vorherige Fehlen des Feldinhaltes anzeigt.

Die Wirkung der aussagenlogischen Grundform „CNF“ in diesem Beispiel:

Wenn Match 1 erfolgreich ist (nicht-leere Betreffzeilen), dann wird Match 2 nicht mehr berücksichtigt, da die Form „CNF“ die Operationssequenz eines Feldes abbricht, sobald ein positives Ergebnis vorliegt. Bei leeren Betreffzeilen scheitert Match 1, weshalb die Aktion mit Match 2 fortfährt (der dann zwangsläufig gelingen muss). Würden Sie in diesem Beispiel aber die Grundform „DNF“ konfigurieren, so würde die gesamte Aktion immer scheitern, da eine Betreffzeile nicht gleichzeitig leer und nicht-leer sein kann, denn die Grundform „DNF“ bedeutet, dass die konfigurierten Operationssequenzen eines Elementfeldes immer alle erfolgreich sein müssen, was im vorliegenden Anwendungsfall unmöglich ist. Die Verwendung der Grundform „DNF“ würde sich am Beispiel der Betreffzeile beispielsweise dann anbieten, wenn man mit der gesamten Aktion immer genau Betreffzeilen der Form „AW: <Betreffzeile> (Ticket: …)“ in „Ticket: … - <Betreffzeile>“ umformen wollte. Dazu müssten Sie in Match 1 „AW:“ identifizieren und durch eine leere Zeichenfolge ersetzen, während in Match 2 das Suffix „(Ticket: …)“ identifiziert wird und durch eine geeignete Ersetzung der ebenfalls gefundenen originalen Betreffzeile vorangestellt wird. Es müssen also beide Operationen erfolgreich sein, da ansonsten davon auszugehen ist, dass die Aktion Betreffzeilen verarbeitet, die von ihr nicht verarbeitet werden sollen.

Der Datentyp des Elementfeldes spielt für die Ausführbarkeit dieser Aktion ebenfalls eine entscheidende Rolle. Die erlaubten Datentypen zur Verarbeitung von Exchange-Server-Elementen sind Zeichenketten, Zahlen, Zeiten und boolesche Ausdrücke. Mehrzeilige Datentypen können ebenso nicht verarbeitet werden wie Binärfelder oder Währungsbeträge.

Anmerkungen zu der Tabelle:

Der Modus „simple“ ist die Standardeinstellung. Das Vergleichsmuster darf in diesem Modus das Wildcard „*“ am Ende stehen haben, aber es darf auch nur das Wildcard verwendet werden. Intern wird das Vergleichsmuster in diesem Modus in einen adäquaten Regex-Ausdruck konvertiert.

Die Groß-/Kleinschreibung wird bis auf den Modus „regex“ ignoriert.

Eine Intervallprüfung von Feldwerten ist nur im Modus „constant“ möglich. Dabei wird das Vergleichsmuster entsprechend formatiert.

Intervallprüfung

Eine Intervallprüfung wird nur für numerische und kalendarische Felddatentypen unterstützt und in der Form „[<untere Grenze><Trennzeichen><obere Grenze>]“ konfiguriert. Die obligatorischen eckigen Klammern bedeuten, dass die Angabe ein geschlossenes Intervall darstellt. Die Konfiguration offener Intervalle ist dagegen nicht möglich. Das Trennzeichen bestimmt der Parameter „Delim“. Wird dieser Parameter nicht angegeben, wird das Intervall nicht erkannt.

Die Angabe der Intervallgrenzen wird entsprechend des Felddatentyps ausgewertet. Numerische Felddatentypen bedürfen keiner weiteren Formatierung und können direkt eingegeben werden. Kalendarische Felddatentypen (bzw. Felder für Zeitangaben) können auf zwei verschiedene Arten formatiert werden, wodurch Feldwerte auf zwei unterschiedliche Arten geprüft werden:

1. Absolute Zeitprüfung: Die Intervallgrenzen werden als ISO-Datum formatiert. Dabei wird ein Kalenderwert wie beispielsweise „21.07.2017 10:03:25“ als „20170721100325“ (ISO-Standard) geschrieben.

2. Relative Zeitwertprüfung: Die Intervallgrenzen werden als „Age<Zeitspanne>“ angegeben. Die Zeitspanne hat das Format „dddhhmmss“, wobei „d“ die Stellen für Tage, „h“ für Stunden, „m“ für Minuten und „s“ für Sekunden sind. Wichtig ist aber auch, dass die Markierung „Age“ (exakt geschrieben) der Zeitspanne vorangestellt wird. Die Bezugszeit für die relative Zeitprüfung ist der Startzeitpunkt des Jobs.