This best practice tip contains a configuration example that enables ELOxc to modify the current mailbox path of an archived message in the repository accordingly.

Example

A message is in the Inbox of the mailbox "xc191". The path pattern is defined as Sync Test/<SMTP>/<mailbox path>. The message's path in the repository is Sync Test/xc191@xc.local/Inbox.

If this message is moved to the folder Inbox\O1 at a later time, ELOxc should automatically move the archived message to the repository folder Sync Test/xc191@xc.local/Inbox/O1 the next time the mailbox is processed.

This configuration example uses application-specific message properties, internal work variables, and special actions for the repository check, calls to external interfaces (ELOas), and the path comparison. These actions need to be arranged into action trees, which implement the requirements for synchronizing the mailbox folders.

Information: Proxy mode is required to run ELOas without transferring a ticket.

The action trees are configured as follows (see following screenshot):

The first action tree "Archiving and storage of the mailbox path" is a standard archiving method with an additional tagging action that sets the current mailbox path as the processed message property. When you save the action, the "archived" tag, the changed subject, and this application-specific property, which contains the current mailbox path, are stored permanently in the message.

Only archived messages are selected in the action tree. Once the messages have been verified to exist in the repository, the current mailbox path is compared with the path stored in the message. If they are not the same, the external ELOas is called and the new mailbox path is stored in the application-specific message property.

The important aspects of this configuration are the following actions:

• Define filing path
• Save mailbox path in the message
• Compare mailbox paths (old/new)
• Exists (search for archived message in the repository)
• Call ELOas (effectively changing the filing path)

Define filing path (ArcPathDef)

"ArcPathDef" is a complex, necessary action in ELOxc. In this action, you are able to define multiple filing paths, the first of which is always used as the main filing path. Other paths are interpreted as reference paths and are evaluated according to this convention during processing. Reference paths are not required in this example.

A path is made up of segments, and you can define how many segments in the repository correspond to a SORD. In the default case, a segment corresponds to exactly one SORD, but any sequence of segments can also be defined to form a SORD. In this example, all segments correspond to one SORD.

The following screenshot shows an example of how the action can be structured:

The first path segment automatically appears at the top repository level, so you should ideally select any constant for this:

Set the Segment type to constant and specify the name of the SORD in the Segment value parameter.

The parameter Segment end specifies that the creation of the current short name ends with this segment. "ArcPathDef" collects the short names of the SORDs across all segments, so that enabling this option tells ELOxc that the SORD definition is completed and that the short name of a new SORD can be generated.

The second path segment represents the processed mailbox. You should therefore define a path segment that includes the mailbox address in the filing path.

As the mailbox address is variable, you must not use the Segment typeconstant. Instead, the definition var tells ELOxc to evaluate the Segment value as one of the path variables. In this case, you need to enter the variable BoxAddr.

The third path segment is the important segment definition in this example. This is where you create the mailbox path that uses the path variable to create the required number of SORDs according to the mailbox path:

Please note: To meet the requirements, you must define these actions identically in both action trees.

Save mailbox path in the message (TagDef)

The action "TagDef" is responsible for creating application-specific message properties. When saving a message ("CommitDef"), they are permanently attached to the message as named properties. The value of these properties determines the stored string:

This example creates the property StoredPath. You can use this property value at any time later. The Property valueEloArcPath is the value determined as a result of the action Define filing path(ArcPathDef). This can only be evaluated if you also set the Type to prop ("property").

Besides the common Exchange definition for properties, which you can recognize by the prefix "PidTag", ELOxc defines a number of pseudo-properties, which can be used during processing. However, some of these properties are only available if an action has been done before they were used. In this example, the pseudo-property is "EloArcPath". However, this property can only exist if the action "ArcPathDef" was successfully executed at least once in the action tree.

Compare mailbox paths (old/new)

Like "ArcPathDef", the "Match/Replace" action ("MatchReplaceDef") is a central and complex action. It enables you to evaluate message properties, and change them if configured accordingly. This action is not only complex due to the fact that it supports two different operating modes, but also because of the option to select a data source, the technical match type, the evaluation logic, and possible evaluation alternatives.

In this example, the application-specific property "StoredPath" needs to be compared with the currently valid filing path.

The Destination parameter is set to element (default setting). This means that match or replace actions target message data directly. If you were to use the value cache, the changed values would not be transmitted to Exchange on saving. This can be useful for leaving the message properties unchanged while processing a message with its values.

The actual action is defined as follows:

You must use the Match modepropname and the Matching pattern to match the tag. The fact that the name of the tag must now be embedded between "Elo" and "Ext" is due to the internal name format at property level. A tag (TagDef) always creates two internal properties (see "Execution" below).

Exists (search for archived message in the repository)

The Exists action ("ExistsDef") checks whether or not a message already exists in the repository. Depending on the parameters, there are two possible cases:

• 1. Is there a copy of the message in the repository?

If messages are sent to multiple mailboxes, one copy is archived for each of these mailboxes. To check whether a copy exists in the repository, you only need to configure the index field that the property "PidTagSearchKey" was written to during the archiving process. You must have set this index field in the corresponding keywording template for this to work.

• 2. Does exactly this message exist in the repository?

This case is twice as relevant for this example as it checks whether the archiving tag contains a valid ELO GUID and ensures that if this action is successful, the ELO GUID is available as a pseudo-property "EloGuid" in the processing workspace. The latter is required to pass this ELO GUID to ELOas in "CallExternalDef", for example.

Otherwise, the Exists action does not require many parameters:

As with secure deletion (see "DeleteDef"), this action can only be successful if the archived message has not been deleted from the repository in the meantime.

Call ELOas (effectively changing the filing path)

The "External call" action ("CallExternalDef") enables you to call external services. The default setting and the variant required in this example is the value "http" in the "Action type" input field. The value "ix" calls a registered Indexserver function. The value "wf" calls a workflow based on the configured template. The value "feed" writes a new entry in the ELO feed.

The configuration for this example looks like this:

The Target address is the "value" of the external call. With the Action type "http", this is a URL pattern in which the determined values are injected as parameters during processing and then passed to ELOas via HTTPS as a whole URL. The pattern contains {%P0} to maximum {%P9}, therefore also the variables, which are replaced by the configured call parameters. The required parameters are the ELO GUID and the filing path, both specified as pseudo-properties and available by executing the "ExistsDef" and "ArcPathDef" actions in this action.

The corresponding ELOas rule "ELOxcMoveAsync" must be stored in the path //ELOas Base//Direct and is specified as follows:

<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>

Execution

If you let ELOxc run this configuration, messages are tagged internally after the first run as follows:

You see two new pairs of properties. A pair of properties consists of a property for the time it was created/updated ("Base") and a property that determines the value ("Ext"). It is evident that ELOxc always creates the tags as pairs of properties.

If you now move the message to the Inbox\O1 folder and run the configuration again, you will see that the property that contains the filing path has changed.

ELOxc changes the filing path in the repository of messages that have already been archived and that have since been moved in the mailbox.