Dieser Praxistipp enthält ein Konfigurationsbeispiel, das ELOxc befähigt, den aktuellen Postfachpfad einer bereits archivierten Nachricht immer auch im Archiv entsprechend anzupassen.

Beispiel

Eine Nachricht befindet sich im Postfachpfad Posteingang des Postfachs „xc191“. Das verwendete Pfadmuster ist dabei als Sync Test/<SMTP>/<Postfachpfad> definiert. Die Nachricht wird im Archiv also im Pfad Sync Test/xc191@xc.local/Posteingang abgelegt.

Wenn zu einem beliebigen Zeitpunkt nach der Archivierung diese Nachricht dann in den Ordner Posteingang\O1 verschoben wird, soll ELOxc mit der nächsten Postfachverarbeitung die archivierte Nachricht automatisch in den Archivordner Sync Test/xc191@xc.local/Posteingang/O1 verschieben.

Dieses Konfigurationsbeispiel verwendet dabei anwendungsspezifische Nachrichtenattribute, interne Arbeitsvariablen und spezielle Aktionen für die Archivprüfung, Aufrufe externer Schnittstellen (ELOas) und den Pfadvergleich. Erst durch die richtige Anordnung der Aktionen entstehen Aktionsbäume, welche die Anforderung der Synchronisation von Postfachordnern umsetzen.

Information: Zum Betrieb des ELOas ohne Ticketübergabe ist der Proxy-Modus erforderlich.

Die Aktionsbäume werden folgendermaßen konfiguriert (siehe folgender Screenshot):

Der erste Aktionsbaum „Archivierung und Speicherung des Postfachpfads“ ist eine gängige Standardarchivierung, die um eine Markierungsaktion erweitert wird, in welcher der aktuelle Postfachpfad als Attribut der verarbeiteten Nachricht gesetzt wird. Beim abschließenden Speichern werden die Markierung „archiviert“, der geänderte Betreff und dieses anwendungsspezifische Attribut, das den aktuellen Postfachpfad enthält, dauerhaft in der Nachricht festgehalten.

Im zweiten Aktionsbaum werden nur archivierte Nachrichten selektiert. Nachdem ihre Existenz im Archiv sichergestellt wird, findet ein Vergleich des aktuellen Postfachpfads mit dem in der Nachricht gespeicherten Pfad statt. Falls eine Ungleichheit festgestellt wird, findet der Aufruf des extern vorliegenden ELOas statt, woraufhin dann der neue Postfachpfad im anwendungsspezifischen Nachrichtenattribut gespeichert wird.

Die nennenswerten Aspekte dieser Konfiguration sind die folgenden Aktionen:

• Ablagepfad festlegen
• Postfachpfad in der Nachricht speichern
• Vergleich der Postfachpfade (alt/neu)
• Existenzprüfung (Suche der archivierten Nachricht im Archiv)
• Aufruf von ELOas (effektive Änderung des Ablagepfads)

Ablagepfad festlegen (ArcPathDef)

„ArcPathDef“ gehört zu den notwendigen und dabei auch komplexeren Aktionen von ELOxc. Sie ist so aufgebaut, dass mehrere Ablagepfade definiert werden können, von denen stets der erste Pfad als Hauptpfad der Ablage verwendet wird. Weitere Pfade werden als Referenzpfade interpretiert und während der Verarbeitung entsprechend dieser Konvention ausgewertet. In diesem Beispiel werden keine Referenzpfade benötigt.

Ein Pfad wird aus Segmenten zusammengesetzt, wobei definiert werden kann, wie viele Segmente im Archiv ein SORD bestimmen. Im Standardfall entspricht ein Segment genau einem SORD, aber Segmente können auch so definiert werden, dass sie gemeinsam als eine beliebige Sequenz das SORD bilden. In diesem Beispiel entsprechen alle Segmente genau einem SORD.

Im folgenden Screenshot sehen Sie einen exemplarischen Aufbau der Aktion:

Das erste Pfadsegment taucht automatisch auf oberster Archivebene auf, daher wählen Sie hierfür idealerweise eine beliebige Konstante aus:

Daher setzen Sie den Segmenttyp auf constant und legen über den Segmentwert den Wunschnamen des SORDs fest.

Das Segmentende bestimmt, dass mit diesem Segment die Erzeugung der aktuellen Kurzbezeichnung beendet wird. „ArcPathDef“ sammelt über alle Segmente hinweg die Kurzbezeichnungen der SORDs, sodass dieses Häkchen ELOxc signalisiert, dass die SORD-Definition beendet wird und danach möglicherweise die Kurzbezeichnung eines neuen SORDs erzeugt wird.

Das zweite Pfadsegment soll das verarbeitete Postfach repräsentieren. Definieren Sie daher ein Pfadsegment, dass die Postfachadresse in den Ablagepfad aufnimmt.

Da die Postfachadresse variabel ist, dürfen Sie nicht den Segmenttypconstant verwenden. Stattdessen weist die Definition von var ELOxc an, den Segmentwert als eine der sogenannten Pfadvariablen auszuwerten. In diesem Fall müssen Sie die Variable BoxAddr (Postfachadresse) einsetzen.

Das dritte Pfadsegment ist die maßgebliche Segmentdefinition dieses Beispiels. Darin soll der Postfachpfad erzeugt werden, der als Pfadvariable immer die nötige Anzahl an SORDs gemäß des Postfachpfads erzeugt:

Beachten Sie: Um die Anforderungen zu erfüllen, müssen Sie diese Aktionen in beiden Aktionsbäumen identisch definieren.

Postfachpfad in der Nachricht speichern (TagDef)

Die Aktion „TagDef“ ist dafür zuständig, anwendungsspezifische Nachrichtenattribute zu erzeugen. Sie werden beim Speichern einer Nachricht („CommitDef“) als sogenannte „Named Properties“ der Nachricht dauerhaft angehängt. Der Wert dieser Attribute bestimmt die gespeicherte Zeichenfolge:

Dieses Beispiel erzeugt das Attribut StoredPath. Anhand dieses Namens kann der Attributwert später jederzeit verwendet werden. Der Attributwert ist mit EloArcPath der ermittelte Wert aus der Aktion Ablagepfad festlegen (ArcPathDef). Das kann nur dann ausgewertet werden, wenn Sie zusätzlich den Typ auf prop („property“ stellvertretend für Attribute) setzen.

Neben den gängigen Exchange-Definition für Attribute, die Sie am Präfix „PidTag“ erkennen, definiert ELOxc eine Reihe von Pseudo-Attributen, die während der Verarbeitung verwendet werden können. Manche dieser Attribute sind jedoch nur dann verfügbar, wenn vor ihrer Verwendung eine Aktion ausgeführt wurde. In diesem Beispiel ist es das Pseudo-Attribut „EloArcPath“. Dieses Attribut kann aber nur dann existieren, wenn im Aktionsbaum mindestens einmal die Aktion „ArcPathDef“ erfolgreich ausgeführt wurde.

Vergleich der Postfachpfade (alt/neu)

Die Aktion „Vergleichen/Ersetzen“ („MatchReplaceDef“) ist wie „ArcPathDef“ eine zentrale und zugleich komplexe Aktion. Mit ihr können Sie Nachrichtenattribute auswerten und bei entsprechender Konfiguration auch ändern. Die Komplexität dieser Aktion entsteht aber nicht nur dadurch, dass sie damit zwei unterschiedliche Betriebsarten unterstützt, sondern auch durch die Auswahlmöglichkeit einer Datenquelle, durch die technische Vergleichsform, die Auswertungslogik und auch mögliche Auswertungsalternativen.

In diesem Beispiel muss das anwendungsspezifische Attribut „StoredPath“ mit dem aktuell gültigen Ablagepfad verglichen werden.

Der Zielbereich ist auf element (Standardeinstellung) eingestellt. Das bedeutet, dass die Vergleiche/Ersetzungen unmittelbar auf Nachrichtendaten zielen. Würden Sie den Wert cache verwenden, würden die geänderten Werte beim Speichern nicht an Exchange übermittelt werden. Das kann nützlich sein, um die Nachrichtenattribute unverändert zu lassen, während Sie eine Nachricht mit ihren Werten verarbeiten möchten.

Die eigentliche Aktion ist folgendermaßen definiert:

Sie müssen den Vergleichsmoduspropname und das Vergleichsmuster passend zur Markierung verwenden. Dass der Name der Markierung hier nun zwischen „Elo“ und „Ext“ eingebettet werden muss, liegt am internen Namensformat auf Attributebene. Eine Markierung (TagDef) erzeugt immer zwei interne Attribute (siehe „Ausführung“ weiter unten).

Existenzprüfung (Suche der archivierten Nachricht im Archiv)

Diese Existenzprüfung-Aktion („ExistsDef“) prüft, ob eine Nachricht im Archiv vorhanden ist. Abhängig von ihrer Parametrierung kann dabei zwischen zwei Fällen unterschieden werden:

• 1. Ist ein Exemplar der Nachricht bereits im Archiv?

Bei Nachrichten, die an mehrere Postfächer gesendet werden, tritt der Fall auf, dass für jedes dieser Postfächer ein Exemplar archiviert wird. Um zu prüfen, ob überhaupt ein Exemplar im Archiv vorliegt, genügt es, das Indexfeld zu konfigurieren, in welches das Attribut „PidTagSearchKey“ beim Archivierungsvorgang geschrieben wurden. Das setzt natürlich voraus, dass Sie dieses hier verwendete Indexfeld in der entsprechenden Verschlagwortungsvorlage auch entsprechend setzen.

• 2. Ist genau diese Nachricht bereits im Archiv?

Dieser Fall ist für dieses Beispiel doppelt relevant, da einerseits damit geprüft wird, ob die Archivierungsmarkierung eine ELO GUID enthält, die noch gültig ist, und andererseits sichergestellt wird, dass bei erfolgreicher Durchführung dieser Aktion die ELO GUID im Arbeitsbereich der Verarbeitung als Pseudo-Attribut „EloGuid“ verfügbar ist. Letzteres ist notwendig, um beispielsweise in „CallExternalDef“ diese ELO GUID an den ELOas zu übergeben.

Die Existenzprüfung-Aktion benötigt ansonsten nicht viele Parameter:

Ähnlich wie beim „Sicheren Löschen“ (siehe „DeleteDef“) hängt auch hier der Erfolg maßgeblich davon ab, dass die zuvor archivierte Nachricht in der Zwischenzeit nicht aus dem Archiv gelöscht wurde.

Aufruf von ELOas (effektive Änderung des Ablagepfads)

Die „Externer Aufruf“-Aktion („CallExternalDef“) erlaubt die Aufrufe externer Dienste. Die Standardeinstellung und auch in diesem Beispiel notwendige Variante ist der Wert „http“ im Eingabefeld Aktionstyp. Mit „ix“ rufen Sie eine registrierte Funktion des Indexservers auf. Mit „wf“ rufen Sie einen Workflow anhand der konfigurierten Vorlage auf. Mit dem Wert „feed“ wird ein neuer Eintrag in einen ELO Feed geschrieben.

Die Konfiguration für dieses Beispiel sieht folgendermaßen aus:

Die Zieladresse ist der „Wert“ des externen Aufrufs. Für den Aktionstyp „http“ ist das ein URL-Muster, in das während der Verarbeitung die ermittelten Werte als Parameter injiziert und dann als vollständige URL über einen HTTPS-Aufruf an ELOas übergeben werden. Das Muster enthält mit {%P0} bis maximal {%P9} deshalb auch die Variablen, welche durch die konfigurierten Aufrufparameter ersetzt werden. Die erforderlichen Parameter sind die ELO GUID und der Ablagepfad – beide als Pseudo-Attribut spezifiziert und durch die Ausführungen der Aktionen „ExistsDef“ und „ArcPathDef“ in dieser Aktion verfügbar.

Die zugehörige Regel „ELOxcMoveAsync“ von ELOas muss im Pfad // ELOas Base // Direct abgelegt werden und wird folgendermaßen angegeben:

<ruleset>

<base>

<name>ELOxcMoveAsync</name>

<search>

<name>"DIRECT"</name>

<value>""</value>

<mask>(E10E1000-E100-E100-E100-E10E10E10E32)</mask>

<max>1</max>

</search>

<interval>0H</interval>

</base>

<rule>

<name>Rule1</name>

<condition></condition>

<script>

log.info("ELOxcMoveAsync");

log.info("First param=" + EM_PARAM1);

log.info("Second param=" + EM_PARAM2);

var dstpath = String(EM_PARAM2).split("\\").join("\u00b6");

bt.moveTo(EM_ACT_SORD, dstpath);

EM_WRITE_CHANGED = true;

</script>

</rule>

<rule>

<name>Global Error Rule</name>

<condition>OnError</condition>

<script></script>

</rule>

</ruleset>

Ausführung

Lässt man ELOxc diese Konfiguration ausführen, werden Nachrichten nach dem ersten Durchlauf intern so markiert:

Sie sehen zwei neue Attributpaare. Ein Attributpaar besteht dabei aus einem Attribut für den Zeitpunkt seiner Erzeugung/Aktualisierung („Base“) und einem Attribut, das den Wert bestimmt („Ext“). Es wird deutlich, dass ELOxc die Markierungen immer als Attributpaar erzeugt.

Verschieben Sie nun die Nachricht in den Ordner Posteingang\O1 und führen die Konfiguration erneut aus, sehen Sie, dass sich das Attribut, das den Ablagepfad enthält, geändert hat.

Damit passt ELOxc den Ablagepfad im Archiv von jenen Nachrichten an, die bereits archiviert wurden und im Postfach mittlerweile verschoben wurden.