Die ermittelten Werte bzw. Zeichenketten der Pfadbestandteile können Sie zusätzlich modifizieren, indem Sie eine konsequente Groß- und Kleinschreibung festlegen und/oder Teilmengen der ermittelten Werte in den Pfad übernehmen. Beachten Sie, dass die Längen der SORD-Namen durch die Datenbank beschränkt werden können. ELOxc behandelt diese Randfälle für eine Instanz immer auf dieselbe Weise, indem "TruncateStrings“ („InstanceDef.IX.TruncateStrings“) für die Schnittstellenaufrufe am ELOix Anwendung findet. Ist "TruncateStrings" in der Instanzenkonfiguration gesetzt, so werden SORD-Namen (und auch Indexfeldwerte) auf die passende Länge gekürzt. Ist es jedoch nicht gesetzt, so führen derartige Randfälle zu Verarbeitungsfehlern, was sich dadurch äußert, dass die betroffenen Nachrichten nicht archiviert werden können.

Der Regelfall für die Verwendung der Ablagepfad-Aktion ist die Ermittlung des Ablagepfads einer Nachricht, welche in der Exportaktion vorbereitet wird. Somit ist diese Aktion notwendig, damit die Nachrichten archiviert werden können. Der dabei definierte erste Pfad wird deshalb auch als Hauptpfad interpretiert. Zusätzlich können Sie weitere Pfade (ab dem zweiten Pfad) definieren, die dann verwendet werden könnten, wenn zusätzlich zum Hauptpfad logische Referenzen in weiteren Ablagepfaden zu erzeugen sind. Hierbei muss unterschieden werden, ob die Existenz dieser referenzierenden Pfade mit Force=“true“ erzwungen wird, womit sie beim Archivierungsvorgang gegebenenfalls erzeugt werden. Oder ob eine logische Referenz auf die archivierte Nachricht nur dann erzeugt werden soll, falls der referenzierende Pfad bereits existiert. Der Hauptpfad wird dagegen immer erzeugt.

Archivieren

Die Archivieren-Aktion überträgt gesammelte Nachrichtendaten (z. B. Dokumente, Metadaten, Ablagepfade) nach ELO. Die Konfigurationsanforderungen sind dabei sehr gering.

Der wichtigste Parameter ist hierbei die Kennzeichnung der Nachricht als „archiviert“ („CheckinDef.Tag“). Setzen Sie das Häkchen im Kontrollkästchen Tag, wird die Nachricht als "archiviert" ("CheckinDef.Tag") gekennzeichnet. Wird die Nachricht als "archiviert" gekennzeichnet, werden die Attribute "EloXcArchivedBase" (Zeitstempel) und "EloXcArchivedExt" ("EloGuid") erzeugt und mit der Nachricht gegebenenfalls über das Speichern („CommitDef“) dauerhaft festgelegt.

Attributexport

Im Gegensatz zum „formatgetreuen“ Export (ExportDef) können Sie mit dem Attributexport eine Textdatei vorbereiten, die dann mit CheckinDef im Repository abgelegt wird. Dabei wählen Sie auch hier eine Metadatenvorlage aus, die beim Archivieren der Textdatei mit Indexwerten befüllt wird.

Zu exportierende Attributdaten müssen Sie für Exchange ausdrücklich per Namen konfigurieren. Wählen Sie als Attributexportmodus über das Drop-down-Menü den Wert „propfile“ aus, wird ein einfaches Format (Name-Wert-Paare) geschrieben. Der Wert „jsonfile“ sorgt dafür, dass der Inhalt der Textdatei JSON-kompatibel ist.

Berechtigungen

Die Berechtigungen-Aktion (ItemSecurityDef) setzt Zugriffsrechte.

In der Regel werden die Zugriffsrechte für SORDs und Dokumente, die von ELOxc in ein Repository übertragen werden, durch die Maske festgelegt, von ELOix ausgewertet und zum Zeitpunkt der Archivierung gesetzt. Dieses Standardverhalten ist im Regelfall wünschenswert.

Ist dieses Standardverhalten nicht erwünscht, wird "ItemSecurityDef" verwendet, um die Zugriffsrechte im Rahmen der Verarbeitungslogik eines Aktionsbaums zu setzen. Beachten Sie dabei, dass diese Aktion die Ziel-ACL einer verarbeiteten Nachricht sukzessive anpasst. Das bedeutet, dass eine dieser Aktionen nach Abschluss ein Ergebnis im Arbeitsbereich der verarbeiteten Nachricht zurücklässt, welches durch eine weitere dieser Aktion weiter angepasst bzw. geändert werden kann. Selbst die Ausführung von "CheckinDef", welche die kumulierte ACL anwendet, setzt die generierte ACL im Arbeitsbereich nicht zurück. Deshalb würden zwei aufeinanderfolgende Ausführungen von "CheckinDef" dieselben ACL-Modifikationen verwenden.

Ergebnis

Mit der Ergebnis-Aktion können Sie ein konstantes Ergebnis des ausführenden Aktionsbaums festlegen. Die Verwendung dieser Aktion ist dann sinnvoll, wenn Sie das letzte Aktionsergebnis invertieren oder zu Reproduktionszwecken eine spezifische Ergebnismeldung erzeugen möchten, die im Protokoll wiedergefunden werden kann.

Existenzprüfung

Die Existenzprüfung erfüllt zwei Aufgaben: Die erste davon ist die Prüfung, ob eine Nachricht bereits im verbundenen Repository abgelegt wurde. Die zweite Aufgabe besteht darin, die GUID der archivierten Nachricht zu lesen und im Arbeitsbereich der Nachricht vorzuhalten.

Export

Die Export-Aktion (ExportDef) liest die Nachrichtendaten aus dem Postfach, bestimmt die Dokumente, welche im ELO abgelegt werden sollen, und legt eine Metadatenvorlage fest. Außerdem können Filter für Namen und Größen der Dateianhänge konfiguriert werden, wenn die Nachrichten aufgetrennt im ELO abgelegt werden sollen, was mithilfe des Exportmodus bestimmt wird.

Externer Aufruf

Die "Externer Aufruf"-Aktion führt einen asynchronen, externen Aufruf aus.

Legen Sie im Parameter „Aktionstyp“ zuerst die Art des unterstützten Dienstes fest. Daraus ergibt sich die Konfiguration des Parameters „Zieladresse“. Über das Drop-down-Menü im Feld „Aktionstyp“ stehen folgende Diensttypen zur Verfügung:

• http: Der Aufruf einer HTTP-Schnittstelle ist die Standardeinstellung.
• ix: Dieser Aufruftyp erfordert eine registrierte Funktion des ELOix ("Registered Function"). Die Funktionsnamen beginnen stets mit „RF_“.
• wf: Im Parameter "Zieladresse" steht der Name einer Workflow-Vorlage. Der Aufruf erzeugt einen neuen aktiven Workflow. Der Name dieses Workflows setzt sich aus dem Namen seiner Vorlage und der SORD-GUID zusammen. Zusätzlich muss "EloGuid" oder "EloAttachmentGuids" in die Parameterliste aufgenommen werden.
• feed: Mit diesem Typ wird die Erzeugung eines ELO Feed-Eintrags konfiguriert. Die Übergabeparameter werden dazu vor dem Aufruf in einen JSON-Puffer umgewandelt. Wie bei der Verwendung des Typs „WF“ muss auch für „FEED“ eine SORD-GUID bekannt sein.

Im Teilbereich "Aufrufparameter" können Sie zusätzlich die Übergabeparameter des Aufrufs konfigurieren. Diese werden dem verwendeten Aufruftyp entsprechend an den externen Dienst übergeben. Sollten "EloGuid" oder "EloAttachmentGuids" verwendet werden, um die Elemente im Repository eindeutig identifizieren zu können, müssen davor zu deren Initialisierung entweder die Aktionen "Archivieren" oder "Existenzprüfung" im betroffenen Aktionsbaum zwingend ausgeführt worden sein.

Beachten Sie: Alle Aufrufe werden – sofern möglich - sofort ausgeführt. Ist der Aufruf selbst nicht erfolgreich, scheitert die Aktion. Kann der externe Funktionsaufruf dagegen erfolgreich abgesetzt werden, wartet ELOxc dennoch nicht auf das Aufrufergebnis, da mit ELOxc große Mengen an Nachrichten verarbeitet werden. Externe Aufrufe können zu unerwünschten Wartezeiten und möglicherweise auch unvorhersehbaren Fehlern führen. Der Anspruch einer stabilen Nachrichtenverarbeitung durch ELOxc erfordert ein hohes Maß an Entkopplung des Dienstes von externen Funktionsschnittstellen.

Löschen

Die Löschen-Aktion (DeleteDef) löscht die selektierten Nachrichten physikalisch.

Zum Standardverhalten der Aktion gehört, dass ein „sicheres Löschen“ ( Secure) der Nachrichten verwendet wird. Das „sichere Löschen“ besteht dabei darin, die Nachricht auf die Markierung „archiviert“ hin zu prüfen und die darin enthaltene "EloGuid" dazu zu verwenden, die Nachricht im Repository zu finden. Das Löschen können Sie nur dann durchführen, wenn die Nachricht zuvor bereits archiviert worden ist.

Darüber hinaus können Sie auch ein Löschen in Abhängigkeit des Nachrichtennamens (für Exchange ist das die Betreffzeile) konfigurieren. Tragen Sie beispielsweise im Parameter Vergleichsmuster den Wert „AW:“ ein, werden Nachrichten nur dann gelöscht, wenn der Name mit „AW:“ beginnt.

Alternativ zum Löschen von Nachrichten können Sie die Aktion auch dazu verwenden, Dateianhänge dauerhaft zu löschen.

Hierzu setzen Sie den Parameter Element auf den Wert „attachment“, wodurch ohne weitere Angaben alle Dateianhänge gelöscht werden. Wie beim Löschen ganzer Nachrichten können Sie auch hierfür Filter konfigurieren. Diese prüfen zusätzlich den Namen eines Dateianhangs, wodurch nur jene Dateianhänge gelöscht werden dürfen, die den konfigurierten Mustern entsprechen.

Die erste Aufgabe, also die Existenzprüfung, kann mit der GUID im Attribut „EloXcArchivedExt“, was eine vorherige Anwendung von CheckinDef erfordert, oder im Falle einer Exchange-Archivierung auch mit dem Attribut „PidTagSearchKey“ durchgeführt werden. Letzteres ist nur dann möglich, wenn zum Zeitpunkt der Archivierung eine entsprechende Übertragung von „PidTagSearchKey“ in ein Feld der Metadaten stattgefunden hat.

Wenn die Nachricht auf eine dieser beiden Weisen gefunden werden kann, wird die GUID des SORD automatisch in den Arbeitsbereich der Nachricht übernommen und steht zur weiteren Verarbeitung, wie z. B. für CallExternalDef zur Verfügung. Zuvor ermittelte GUIDs im Arbeitsbereich werden dabei überschrieben.

Markieren

Nachrichtenmarkierungen setzen Sie mit der Tag-Aktion.

Mit dieser Aktion erzeugen Sie ein neues Attribut mit dem konfigurierten Text oder überschreiben ein bereits vorhandenes, gleichnamiges Attribut mit diesem Wert. Alternativ zu einer Textkonstanten können Sie auch den Wert eines anderen Attributs in dieses Feld kopieren. Zusätzlich können Sie auch eine Outlook-Kategorie setzen. Bereits gesetzte Markierungen können Sie mit dieser Aktion auch wieder entfernen.

Rumpfersetzung

Die Rumpfersetzung-Aktion führt eine Rumpfersetzung verarbeiteter Nachrichten durch.

Bei Exchange ist der Hauptinhalt der Nachrichtenrumpf. Welches Ausgabeformat erzeugt wird, hängt davon ab, welcher Wert für „BodyType“ in der Ersetzungsvorlage („TemplateStubDef“) konfiguriert ist. Sie können zwischen „html“ und „text“ wählen. Die Vorlage, die als entsprechendes Dokument im Parameter Rumpfersetzung hinterlegt sein muss, wird in Aktionsname mit ihrem XML-Namen hinterlegt.

Speichern

Alle Änderungen von Attributen durch Aktionen werden nur im Arbeitsspeicher des Prozesses durchgeführt, solange verarbeitete Nachrichten nicht ausdrücklich gespeichert werden. Erst bei Verwendung der Speichern-Aktion (CommitDef) werden die Nachrichtenänderungen dauerhaft.

Folgende Aktionen können Nachrichtenänderungen verursachen und erfordern CommitDef, um die Änderungen dauerhaft zu speichern:

• CallDef in Abhängigkeit der Aktionen des aufgerufenen Teilbaums
• CheckinDef im Standardfall, wenn die Markierung „archiviert“ gesetzt wird
• FinishDef setzt die Markierung „erledigt“
• MatchReplaceDef ist die Aktion, die dafür bestimmt ist, Attributwerte zu ändern
• StubbingDef ersetzt den Hauptinhalt. Für Exchange ist das der Nachrichtenrumpf
• TagDef setzt eine anwenderspezifische Markierung

Ausnahmen bilden die Aktion MoveDef, da mit ihr eine Nachricht sofort in einen anderen Ordner verschoben wird und die Aktion DeleteDef, da mit ihr eine Nachricht sofort gelöscht wird . Das Ergebnis ist damit auch sofort dauerhaft.

Teilbaumaufruf

Aktionsbäume, die als Vorlagen häufig wiederkehrender Verarbeitungslogik modular verwendet werden sollen und deshalb als „subtree“ gekennzeichnet sind, werden mit der Teilbaumaufruf-Aktion aufgerufen.

Den Aufruf selbst konfigurieren Sie über den eindeutigen Namen des Vorlagenbaums. Dabei werden jedoch möglicherweise zusätzlich konfigurierte Parameter (zum Beispiel Kataloge oder Ordnerfilter) der Baumdefinition ignoriert, da eine Nachrichtenselektion in einem Vorlagenbaum bzw. untergeordnetem Baum nicht wünschenswert ist. Stattdessen setzt ELOxc die Verarbeitung mit der ersten Aktion fort. Die zuletzt durchlaufene Aktion bestimmt das Gesamtergebnis des Vorlagenbaums, welches nach Rückkehr in die aufrufende Aktion (CallDef) als Ergebnis des aktiven bzw. Nachrichten selektierenden Aktionsbaums weiter verwendet wird. Auf diese Weise können auch erprobte aktive Aktionsbäume nachträglich auf einfache Weise als Verarbeitungsvorlagen konfiguriert werden, indem der Typ des Aktionsbaums von „active“ auf „subtree“ geändert wird.

Ein aktiver Baum kann beliebig viele Vorlagenbäume aufrufen. Vorlagenbäume selbst dürfen jedoch keine weitere Schachtelung vornehmen und weitere Vorlagenbäume aufrufen, da ELOxc keine Prüfung auf gegenseitige Aufrufe bzw. Aufrufzyklen durchführt.

Verarbeitung beenden

Die "Verarbeitung beenden"-Aktion wird dafür verwendet, um zu erkennen, ob eine Nachricht noch verarbeitet werden darf.

Hierfür setzt ELOxc die vordefinierten Attribute „EloXcFinishedBase“ und „EloXcFinishedExt“ ein. Zusätzlich können Sie im Parameter Kommentar einen beliebigen Text als Attributwert von „EloXcFinishedExt“ eintragen.

Beachten Sie: Nachrichten, die mit dieser Aktion markiert werden, werden bei nachfolgenden Selektionen von ELOxc nicht mehr berücksichtigt.

Vergleichen/Ersetzen

Mit der "Vergleichen/Ersetzen"-Aktion können Sie Attribute auf bestimmte Attributinhalte hin überprüfen. Zusätzlich können Sie die Aktion so konfigurieren, dass sie bei positiver Überprüfung die Attributinhalte verändert. Die Aktion können Sie für eine beliebige Anzahl von Attributen konfigurieren. Dabei können Sie für jedes Attribut eine Sequenz von Prüfungen angeben.

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

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 Attributs untereinander durch ein logisches ODER verknüpft. Die dabei entstehenden Teilergebnisse eines Attributs werden anschließend durch ein logisches UND mit den Teilergebnissen aller anderen Attribute verknüpft, womit das Gesamtergebnis der Aktion ermittelt wird.

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

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 Attribute und bestimmt damit auch das Gesamtergebnis. In diesem Modus muss also eine Ersetzung bei erfolgreicher Musterprüfung erfolgen können.

Der Aktionstyp muss auf „replace“ eingestellt werden, da die Betreffzeile verändert werden soll. Die zugrundeliegende Auswertungslogik „cnf“ ist die „Ver-UND-ung von Ver-ODER-ungen“.

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

Der Attributname ist „PidTagSubject“ (siehe Ermittlung von Attributnamen im Bereich "Werkzeuge" in ELOxc Manager). Die Datenebene (Zielbereich) „element“ des Ergebnisses ist zwangsläufig das Attribut 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 Nachrichtenverarbeitung verloren gehen.

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

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

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

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

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

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

Der Parameter Intervalltrennzeichen 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.

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

Das Ersetzungsmuster in Ersetzen gibt das wieder, indem eine Ausgabe produziert wird, die das vorherige Fehlen des Attributinhaltes 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 Attributs 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 Attributs 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 Attributs spielt für die Ausführbarkeit dieser Aktion ebenfalls eine entscheidende Rolle. Die erlaubten Datentypen zur Verarbeitung von Exchange-Server-Nachrichten sind Zeichenketten, Zahlen, Zeiten und boolesche Ausdrücke. Mehrzeilige Datentypen können ebenso nicht verarbeitet werden wie Binärfelder oder Währungsbeträge.