ELO Documentation

Actions

Actions in ELOxc are the set of available processing rules or patterns. They are designed to allow you to create modular and hierarchical actions with as few interdependencies as possible. Whereas the configurations for an instance and its action trees affects which messages are selected, the configuration for actions constitute the rules that define how the selected messages are processed. The hierarchical order of actions within an action tree results from the fact that an action can have a maximum of two results, successful ("TRUE") or not successful ("FALSE"), and from the fact that the action tree evaluates an action result and dynamically determines the follow-up action.

Action

Information: Refer to the

The remaining and unavoidable dependencies between the actions result from the need to be able to use processing data in different actions. This is largely dependent on the properties selected, which determine the scope of selection of an action tree and are determined automatically by ELOxc before a message is selected.

However, the pseudo-properties defined by ELOxc, which contain special data that are not Exchange messages, are also added. An example of this is "EloGuid", which is generated during archiving ("CheckinDef") and can also be used in other actions such as Delete ("DeleteDef") or Exists ("ExistsDef"). This can be illustrated by assuming that a validated, secure deletion has been configured and the responsible action tree selects messages that have not yet been archived. In this case, secure deletion, which requires the existence of an "EloGuid", would automatically fail because non-archived messages cannot have an "EloGuid".

Another type of action dependency is the "intention of an action tree": If you want to archive a message, you need the corresponding action ("CheckinDef"), which performs the archiving. However, this can only work if messages have already been exported, which is also an independent action ("ExportDef") that only reads message data from the mailbox in document form. In this case, export and archiving actions are inextricably linked. As a rule, however, in addition to this minimum configuration, you will also want to define the keywording and the repository path, which is why the export action is assigned a keywording template and the archiving action additionally determines the configured filing path. The filing path is also an independent action that can be used as often as required and can use its own keywording templates.

Each message that is processed contains its own working data, which can be collected in the context of an action tree and used for processing after successful message selection. If actions that generate this internal working data are executed multiple times in a tree, the most recently retrieved values are applied when the data is used.

However, there is one exception that applies here: Permissions ("ItemSecurityDef") are set or removed cumulatively for each message in order to be able to compile the complete list of ACLs about possible case distinctions in the action tree.

ELOxc provides two additional levels for mailbox properties that are used. These are distinguished as follows: One level defines whether to transfer changes that are made when saving messages ("CommitDef") to the mailbox, which changes the messages themselves. The other level defines whether changes to data are used as copies, i.e. action-only data, meaning that their values are not stored in the mailbox. ELOxc uses the property value "propname" in all places that directly use the message data, while the property copies are defined with "cachedname". By default, actions in ELOxc assume that all data changes are to be saved, meaning that the properties are used and changed.

Before you create the first action, click an action tree in ELOxc Workspace and then click the lightning icon.

Action, add

A drop-down menu with all available actions appears.

Before we go on to explain each of the available actions in this section, let us take a look at their roles:

Action, roles

Action	Schema	Description
Filing path	ArcPathDef	Specifies all the filing paths used
Archive	CheckinDef	Archives processed messages
Property export	ExportPropsDef	Exports message properties
Permissions	ItemSecurityDef	Defines the permissions to archived messages
Result	ResultDef	Specifies a constant for the result of the executing action tree
Exists	ExistsDef	Checks whether messages exist in the repository
Export	ExportDef	Performs a data export of the message
External call	CallExternalDef	Makes an asynchronous external call
Delete	DeleteDef	Deletes messages or attachments in the mailbox
Tag	TagDef	Uses properties to tag messages
Message stubbing	StubbingDef	Stubs the body of processed messages
Save	CommitDef	Saves all changes to a message in the mailbox
Call subtree	CallDef	Calls another action tree that is configured as a subtree
End processing	FinishDef	Sets an internal tag to exclude a message from further processing
Match/Replace	MatchReplaceDef	Matches properties and can also replace property values
Move	MoveDef	Moves messages within the folder hierarchy of a mailbox

Filing path

The action for creating the filing path applies the following configuration structure:

Filing path actionAction, filing pathArcPathDef

ArcPathDef: Action = { path1, path2, path3, …, pathn }
ArcPathDef.Path: Pathi = { Sordi,1, Sordi,2, Sordi,3, …, Sordi,m }
ArcPathDef.Path.Part: Sordi,j = { parti,j,1, parti,j,2, parti,j,3, …, parti,j,k }

In other words, a filing path action defines a list of paths, each of which defines a list of path components (or SORDs). In addition, it is possible to string together multiple list entries to build the path components, which is exactly what occurs when a part (k+1) is not separated from the predecessor part (k) (ArcPathDef.Path.Part.Separator=false). In this case, the SORD is generated by both parts (k and k+1), although only the keywording template of the first part can be used, since the SORD that is to be generated can only have one keywording. However, the standard assumption is that each path component also defines its own SORD.

Path components can be defined with a constant value (SourceType="constant"). Alternatively, properties can be used (SourceType: "propname", "cachedname"). The Filing path action can use predefined action variables ("SimpleTypesDef.PathPartVarType"), which differ depending on the type of mailbox (see following table):

Variable	Meaning	Exchange
DeliveryTime	Time of receipt	X
JobStart	Start time of the current processing job	X
BoxName	displayName of the mailbox owner	X
BoxAccount	SAMAccountName of the mailbox owner	X
BoxUPN	UserPrincipalName of the mailbox owner	X
BoxAlias	SMTP of the mailbox	X
SndName	Sender name	X
SndAddr	Sender address	X
SndDomain	Sender domain	X
RcptName	Recipient name	X
RcptAddr	Recipient address	X
RcptDomain	Recipient domain	X
BoxAddr	Mailbox address	X
AccessUrl	Access URL
RootPath	Path in the mailbox	X
ParentName	Name of the parent folder	X

You can also modify the values or character strings determined for the path components by using consistent uppercase and lowercase and/or transferring subsets of the values determined to the path. Please note that the database can limit the lengths of the SORD names. ELOxc handles these special cases for an instance in the same way by using the function "TruncateStrings" ("InstanceDef.IX.TruncateStrings") for ELOix interface calls. If "TruncateStrings" is set in the instance configuration, SORD names (and index field values) are shortened to the appropriate length. However, if it is not enabled, this leads to processing errors, meaning that the corresponding messages cannot be archived.

The rule for using the filing path action is to determine the filing path of a message that is prepared in the export action. This action is therefore necessary to allow messages to be archived. The first path defined is therefore also interpreted as the main path. You can also define additional paths (from the second path) that you could use if you want to create logical references in these paths as well as in the main one. You need to distinguish between whether the existence of these referencing paths is forced (="true"), meaning they may be created during the archiving process, or whether a logical reference to the archived message is only created if the referencing path already exists. The main path is always created.

Property export

Unlike "true to format" exports (ExportDef), you can create a text file along with the property export, which is then filed to the repository with CheckinDef. During the process, you also select a keywording template, which is assigned index values when the text file is archived.

ExportPropsDefMapping actionAction, mappingProperty export

In Exchange, you must explicitly configure property data to be exported by name. If you select "propfile" from the drop-down menu for Property export mode, a simple format (name-value pairs) is written. The value "jsonfile" ensures that the content of the text file is JSON-compatible.

Permissions

The Permissions action (ItemSecurityDef) sets access rights.

Permissions actionAction, permissionsItemSecurityDefAccess rights, set

The access rights for SORDs and documents, which ELOxc transfers to a repository, are usually determined by the keywording form, evaluated by ELOix, and set at the time of archiving. This default behavior is generally the best option.

However, if you do not want this to occur by default, "ItemSecurityDef" is used to define the access rights within the processing logic of an action tree. Keep in mind that this action gradually changes the target ACL of the message being processed. This means that one of these actions leaves a result in the workspace of the processed message after completion, which can be modified further or changed by another one of these actions. Not even the "CheckinDef" action, which applies the cumulative ACL, resets the generated ACL in the workspace. Therefore, two consecutive versions of "CheckinDef" would use the same ACL modifications.

Result

The Result action enables you to specify that the result of the executing action tree is a constant. It makes sense to use this action if you want to reverse the last action result or generate a specific result message for the log.

Result actionAction, resultResultDef

Exists

The Exists action performs two tasks: The first checks whether a message has already been filed to the connected repository. The second task reads the GUID of the archived message and saves it to the workspace of the message.

ExistsDefExists actionAction, exists

Export

The Export action (ExportDef) reads the message data from the mailbox, determines which documents are to be stored in ELO, and defines a keywording template. It is also possible to configure filters for file attachment names and sizes if the messages are to be split and stored in ELO, which is determined using the export mode.

Export actionAction, exportExportDef

External call

The External call action makes an asynchronous external call.

External call actionAction, external callCallExternalDef

First, set the type of service in the "Action type" parameter. This provides the configuration for the "Target address" parameter. The following service types are available via the drop-down menu in the "Action type" field:

http: An HTTP interface is the default setting.
ix: This type of call requires a registered ELOix function ("Registered function"). The function names always starts with "RF_".
wf: The "Target address" parameter contains the name of a workflow template. This calls a new active workflow. The name of this workflow consists of the name of its template and the SORD GUID. In addition, "EloGuid" or "EloAttachmentGuids" must be added to the parameter list.
feed: This is used to configure the creation of an ELO feed entry. The transfer parameters are converted into a JSON buffer before the call. As with the "WF" type, a SORD GUID must also exist for the "FEED" type to work.

In the "Call parameters" area, you can configure the transfer parameters for the call. These are transferred to the external service based on the type of call used. If "EloGuid" or "EloAttachmentGuids" are used to uniquely identify the elements in the repository, you must have executed one of the actions "Archive" or "Exists" in the corresponding action tree prior to their initialization.

Please note: Where possible, all calls are executed immediately. If the call does not work, the action will fail. However, if the external function call is successful, ELOxc does not wait for the result, because ELOxc processes large quantities of messages. External calls can lead to unwanted wait times and unforeseeable errors. To ensure stable processing with ELOxc, the service must run as independently as possible from external function interfaces.

Delete

The Delete action (DeleteDef) physically deletes the selected messages.

Delete actionAction, deleteDeleteDef

By default, the action performs a secure deletion (Secure) of the messages. Secure deletion means that ELOxc checks whether the message is marked as "archived" and uses the "EloGuid" to find the message in the repository. The message can only be deleted if it has already been archived.

Secure deletion

You can also configure deletion based on the message name (this is the subject line in Exchange). If, for example, you enter the value "RE:" in the Matching pattern parameter, messages are only deleted if the name starts with "RE:".

This action can also be used to permanently delete file attachments.

Attachment, delete

To do this, set the Item parameter to "attachment", which deletes all file attachments without having to make any other entries. As with deleting whole messages, you can also configure filters to additionally check the name of a file attachment, but it is only possible to delete those file attachments that correspond to the configured patterns.

The first task, i.e. the Exists action, can be performed with the GUID in the property "EloXcArchivedExt", which requires a previous application of CheckinDef, or in Exchange archiving, can also be performed with the property "PidTagSearchKey". The latter is only possible if "PidTagSearchKey" was transferred to an index field in the keywording at the time of archiving.

If the message is found with either of these tasks, the GUID of the SORD is automatically transferred to the workspace of the message and can be processed with CallExternalDef, for example. Previously determined GUIDs in the workspace are overwritten.

Tag

You set message markers with the Tag action.

Tag actionAction, set markersTagDef

This action allows you to create a new property containing the configured text or overwrite an existing property of the same name with this value. As an alternative to a text constant, you can also copy the value from another property into this field. You can also use this action to set an Outlook category or to remove existing tags.

Message stubbing

This action stubs the body of processed messages.

Message stubbing actionAction, message stubbingStubbingDef

In Exchange, this is the message body. This depends on whether you select "html" and "text" for the value "BodyType" in the stubbing template ("TemplateStubDef"). The template, which must be stored as a corresponding document in the Message stubbing parameter, is stored with its XML name in Action name.

Save

Changes to properties that occur as a result of actions are only stored in the process memory until you perform a Save action (CommitDef) to save the processed messages.

Save actionAction, saveCommitDef

By default, the CommitDef action forces the saving of messages (ForcedCommits). This means that ELOxc will attempt to enforce its own changes to messages over simultaneous changes that may be caused by users. If a message was not changed during this action, ELOxc does not attempt to save the message.

The following actions can result in changes to messages and require CommitDef to save the changes:

CallDef depending on the actions of the subtree called
CheckinDef by default if the item is marked as "archived"
DeleteDef does not make any changes to properties, but marks the message internally so that it is physically deleted when CommitDef is called
FinishDef sets the tag "finished"
MatchReplaceDef is the action used to change property values
StubbingDef replaces the main content. In Exchange, this is the message body.
TagDef sets a user-specific tag

The MoveDef action is an exception, since it moves a message straight to another folder. The result is therefore permanent.

If you use the Reload parameter, ELOxc reloads the data of the corresponding message from the server immediately after saving. However, this action is rarely necessary and should only be used in exceptional cases, since the messages can be transferred to new states during processing by an action tree, which may invalidate some assumptions which the configuration of an action tree is based on.

Call subtree

Action trees to be used as modular templates for frequently recurring processing logic and that are therefore marked as "subtrees" are called with this action.

Call subtree actionAction, call subtreeCallDef

The call itself is configured via the unique name of the template tree. However, this may mean that additional configured parameters (e.g. catalogs or folder filters) of the tree definition are ignored, since users should not be able to select messages in a template tree or child tree. Instead, ELOxc continues processing with the first action. The last action that was processed determines the overall result of the template tree, which is used after returning to the calling action (CallDef) as the result of the active action tree. This enables you to configure tried and tested active action trees as processing templates simply by changing the action tree type from "active" to "subtree".

An active tree can have an unlimited number of template trees. However, template trees are not allowed to nest and call other template trees, since ELOxc does not check for mutual calls or call cycles.

End processing

The "End processing" action is used to determine whether a message can still be processed.

End processing actionAction, end processingFinishDef

ELOxc uses the predefined properties "EloXcFinishedBase" and "EloXcFinishedExt" for this action. In addition, you can enter any text to be applied as the property value for "EloXcFinishedExt" in the Comment parameter.

Please note: Messages marked with this action are ignored by ELOxc in subsequent selections.

Match/Replace

The "Match/Replace" action can be used to search properties for specific contents. You can also configure the action to change the property contents that are found. You can configure the action for any number of properties. You can specify a sequence of checks for each property.

Match/Replace actionAction, Match/ReplaceMatchReplaceDef

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

The abbreviation "CNF" describes the basic conjunctive normal form of the propositional logic. The action is successful if the "AND of ORs" is successful. A logical OR is used to link the reference sequences of a property. The partial results of a property are then linked by a logical AND with the partial results of all other properties, which determines the overall result of the action.

CNF, logicLogic, CNF

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

DNF, logicLogic, DNF

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 properties and therefore on the overall result. In this mode, therefore, it must be possible to perform a replace action following a successful match.

You need to set "replace" in the Action type field in order to be able to change the subject line. The underlying Evaluation logic "cnf" is "AND of ORs".

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

The property name is "PidTagSubject" (see determining property names in the "Tools" area of ELOxc Workspace). The "item" data level (Destination) of the result is always the property 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 message has been processed.

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

You can select any value for the Match 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 Match mode needs to be "regex", since the property contents are to be determined and used in the replacement.

The Regex options allows you to make further modifications to the regex match, which is not relevant in this example.

The pattern entered to the Matching pattern parameter above ensures that the entire property contents are stored temporarily as a regex group for the match.

The desired replacement pattern in Replace generates output with"[ELO]" followed by the original property contents determined with the parameter Matching pattern.

The parameter Interval separator 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.

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

The replacement pattern in Replace ensures that the output indicates that the property 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 property 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 not empty at the same time, because the basic form "DNF" means that the configured operation sequences of a property must always all be successful, which is impossible in this use case. 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 property is also a material factor in this action. The allowed data types for processing Exchange server messages are strings, numbers, times, and Boolean expressions. Multi-line data types cannot be processed, nor can binary fields or currency amounts.

Match mode	Matching pattern	Replace	Interval separator
constant	1:1, not case-sensitive	Constant	Yes
simple	1:1 plus "*" at the end	Constant	No
regex	Regex	Regex	No
propname	Property match, not case-sensitive	Constant	No

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.

Move

The Move action allows you to move messages within the folder hierarchy of a catalog.

Move actionAction, moveMessages, moveMoveDef

Please note: If the action is completed successfully, the message is automatically reloaded. This means that unless you carry out a "Save" action prior to this action, any changes you made to the message previously will be discarded.